Re: smaller c preprocessor

[Paul Edwards]

https://groups.google.com/g/alt.os.development/c/3z0Achh5U7I/m/QW08T9kyAQAJ

On Monday, April 5, 2021 at 5:34:51 AM UTC+8, Alexei A. Frounze wrote:
> On Sunday, April 4, 2021 at 2:15:18 PM UTC-7, muta...@gmail.com wrote:
> > Ok, if the problem is that they need int = long = ptr then
> > how much change is required to make 64-bit int/long/ptr?

> Before we get to other things, there's one big question as to how to
> fill the type gap between 8 and 64 bits.
> char/byte = 8 bits
> short = 16 bits
> int/long/ptr = 64 bits
>
> Do we not have any standard C type for 32-bit ints?
> Or do we make short equal to 32 bits and drop 16-bit ints instead?
> Or introduce a non-standard type for one of those two sizes?
> Or what?

I now think that 32-bit integers are more useful
than 16-bit integers. So I would suggest dropping
16-bit.

> The other things being:
> - new, 64-bit file formats to support (PE, ELF, Mach-O)
> - new, 64-bit ABIs to support

Ok.

> - bootstrapping (I don't have an x86 compiler with plain ints being
64-bit)

I now believe I have this covered.

A chain of events involving a lot of work led me to get
my modified gcc 3.2.3 to allow flexible sizes.

So I created one with 32-bit shorts and 64-bit int and long,
called gccw64_s32.exe (it's an 80386 Win32 executable and
it uses pdpcrt.dll (like msvcrt.dll except 64-bit long)
from c:\dos in pdos.zip at http://pdos.org - and the
executable can be found in the same place or in customb.zip
(source in custom.zip - gcc-stage*).

I can assist in getting this executable built from source
if you start with some other C compiler (like another flavor
of gcc or Visual C or Watcom C).

> - possibly some issues w.r.t. addressing in 64-bit assembly code
> (there are different modes, AFAIR; I never used NASM/YASM/FASM
> for 64-bit code)

I have gas intel syntax code available. Only about 70
lines of code is required to support setjmp/longjmp.

BFN. Paul.