Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: 80386 C compiler
Date: Sun, 24 Nov 2024 17:46:59 -0600
Organization: A noiseless patient Spider
Lines: 251
Message-ID: <vi0dtn$2ehti$1@dont-email.me>
References: <vhvbhf$28opb$1@dont-email.me>
 <cb7873a392cbcd3a9595ff0a4d534e7a2bd71040@i2pn2.org>
 <vhvpjt$2b2b5$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Nov 2024 00:47:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="958c23cc798a5c12695d725a3f118f3b";
	logging-data="2574258"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18HeF9Mwrpgqv4k7I3MMLKvW4Z5UMP5f3g="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ykbvYmqSJbdYdSs97DxH5TQJ83g=
In-Reply-To: <vhvpjt$2b2b5$2@dont-email.me>
Content-Language: en-US
Bytes: 11938

On 11/24/2024 12:00 PM, Bart wrote:
> On 24/11/2024 17:51, fir wrote:
>> Paul Edwards pisze:
>>> Hi.
>>>
>>> I have been after a public domain C compiler for decades.
>>> None of them reach C90 compliance. SubC comes the
>>> closest but was written without full use of C90, which
>>> makes it difficult to read. I'm after C90 written in C90.
>>>
>>> A number of people have tried, but they always seem
>>> to fall short. One of those attempts is pdcc. The
>>> preprocessor was done, but the attempt (by someone
>>> else) to add C code generation was abandoned.
>>>
>>> I decided to take a look at it, and it looks to me like
>>> a significant amount of work has already been done.
>>>
>>> Also, my scope is limited - I am only after enough
>>> functionality to get my 80386 OS (PDOS) compiled,
>>> and I don't mind short=int=long = 32 bits, I don't
>>> mind not having float. I don't use bitfields.
>>>
>>> Anyway, I have had some success in making enhancements
>>> to it, and here is one:
>>>
>>> https://sourceforge.net/p/pdos/gitcode/ 
>>> ci/3356e623785e2c2e16c28c5bf8737e72df
>>> d39e04/
>>>
>>> But I don't really know what I'm doing (I do know some
>>> of the theory - but this is a particular design).
>>>
>>> E.g. now that I have managed to get a variable passed to
>>> a function, I now want the address of that variable passed
>>> to the function - ie I want to do &x instead of x - and I am
>>> not sure whether to create a new ADDRESS type, or
>>> whether it is part of VARREF or what - in the original
>>> (incomplete) concept. Or CC_EXPR_AMPERSAND.
>>>
>>> I am happy to do the actual coding work - I'm just looking
>>> for some nudges in the right direction if anyone can assist.
>>>
>>> Thanks. Paul.
>>>
>>>
>> you mean there is no such a compiler? rise a fund for some to
>> write it and they will write it..and if few thousand of people
>> will give some money there it will be written
> 
> There are any number of open source C compilers. But they need to be 
> good enough (too many support only a subset, which may not be enough for 
> the OP) and they need to be public domain for the OP's purposes.
> 

I am more in the camp of MIT or BSD license should be good enough for 
most things.

Trying to go full public domain has a few of its own issues:
* Not always recognized as valid;
* Implicitly lacks "No Warranty" and "No Liability" protections for the 
author (say, if someone wanted to file a lawsuit over the code being 
buggy, etc).
* ...

There could almost be a "MIT Minus" or something, which could be, say, 
MIT with a clause saying one is allowed to discard the license terms for 
sake of derived works (but still offering protection from liability).



As for C compilers, I have a compiler for my own uses, but:
* MIT licensed;
* Doesn't target x86.
* Sorta implements C99 with various fragments of newer standards.
** Though, is a bit hit/miss on the now-optional parts.
** VLAs sorta exist but do not necessarily work correctly.
*** Currently unsupported in DLLs;
*** Seemingly may result in memory leaks if used.
*** Essentially, they are implemented via runtime library calls.
**** With memory provided indirectly via malloc.

Old target list (for which the code still exists):
* SH-4 (AKA: SuperH, most well known for SEGA Saturn and Dreamcast)
* BJX-1 (Was a highly modified version of SH-4)
* BTSR1 (a small SH inspired ISA, intended to be comparable to MSP430).
** Not maintained, RV32IC seems like a better option.

Currently active targets:
* BJX-2: Now a group of several closely related variants.
** All are 64-bit, most using a 48-bit VAS (some had a 32-bit VAS)
** Baseline: 16/32/64/96 bit instructions, 32 or 64 GPRs
** XG2: 32/64/96 bit, 64 GPRs
* RISC-V, RV64G + Custom Extensions
** Has some extensions which can help notably with performance.
** Can support plain RV64G as well.
** No current support for the 16-bit 'C' encodings.
* XG3RV
** Mostly a tweaked and repacked version of XG2 used alongside RV64G.
** The XG3 encoding space replaces the RV64 'C' (Compressed) extension.
** Both XG3 and RV64 instructions may be encoded at the same time.
** XG3 is used in a functionally-similar subset, just with 64 GPRs.


Not yet bothered with a target for RV32IC, GCC does this well enough.
* x86/x86-64/ARM: We generally have GCC and Clang.

Granted, GCC and Clang are both very large and slow/painful to rebuild 
from source. My compiler is at least a lot smaller and easy to rebuild.

Likely, far more of the total effort of my project has ended up going 
into my compiler than into the emulator or Verilog implementation though.



The BJX-2 register space had 64 registers and was split in half for the 
RV64G modes (32 GPRs and 32 FPRs), whereas XG3 and my jumbo-prefix 
extensions partly undo this split.

( Decided to try changing the way I write my ISA name as maybe adding a 
hyphen will get me less trouble... ).


Though, partly this is because for performance BGBCC seems to need a lot 
of registers (it could barely operate with the SH4's 16 GPRs, and still 
has a fairly high spill-and-fill rate with 32 GPRs).

Though, can note that with my compiler and XG3RV, despite not adding 
much over RV64+Jumbo, does beat both code density and performance of 
RV64G via "GCC -O3" (and also beats the code-density of RV64GC, as in 
this case, fewer instructions is better than smaller instructions).


A big part of the performance delta between the ISAs could be addressed 
by adding a few major features to RV64:
* Jumbo Prefixes: Prefix may extend 12-bit imm/disp fields to 33 bits;
** Also extends LUI, AUIPC, and JAL to 33-bit forms.
* Load/Store with a register index;
* Load/Store Pair.

With BGBCC vs GCC RV64G, this gives around a 30% speedup.
* It is closer to 70% if comparing against BGBCC with plain RV64G.
* BGBCC can't match GCC if both are targeting RV64G.
** I am not sure what GCC would do if it had my extensions.

The specific extensions here mostly targeting the dominant sources of 
inefficiency in the RV64G encodings as they exist (the ISA design deals 
poorly to exceeding what can be encoded directly in an immediate, ...).



The jumbo prefixes may also be used to merge the register space back 
into a 64 register space (at the cost of using 64-bit instruction 
encodings to do so), but this only extends the imm/disp fields to 23 
bits (except for LUI/AUPIC/JAL, which always have an expanded 6b 
register field with jumbo prefixes).

Note that J+AUIPC loads an address of PC +/- 4GB into Rd. Likewise, 
J+JAL is +/- 4GB (with LSB as MBZ).


The relative performance gains from the XG3RV vs extended RV64G were 
smaller, it mostly serves to improve code-density (makes Doom roughly 
16% smaller; and is around 44% smaller than plain RV64G).

Main thing it has (in theory) is access to a lot of the specialized SIMD 
instructions and similar that exist in my ISA but lack equivalents on 
the RV64G side of things.

There are a few instructions that exist here which are tempting to add 
as extended instructions to RV64:
* Compare Equal, Not-Equal, and Greater-Equal instructions (SEQ, SNE, SGE);
* Load/Store relative to GP with a larger displacement (TBD, 2).


Some notable features from BJX-2 were effectively made optional in XG3, 
such as support for an SR.T bit (originally carried over SuperH), and 
========== REMAINDER OF ARTICLE TRUNCATED ==========