Re: C compiler, assembler and linker

[Riley Williams <rhw@InfraDead.Org>]

Hi Manuel.

>>> I don't know about small C, but I managed to get bcc to build
>>> itself for elks by omitting all the floating point related code.
>>> The preprocessor appears to work, but the code generator dies.
>>> I haven't had time to track down the problem(s).

>> Could you perhaps advise re the tweaks you have done so far? That
>> way, we can add a few more brain cells working on sorting the
>> problem out...

> Hopefully I'll have time this evening to sort out a patch to post. I
> found that dev86-0.16.3 has a number of build issues, so I had to
> modify some of the makefiles, etc. as well.

That I can certainly understand...

> Anyway, here's a list of my bcc tweaks (as best I recall):

> 1) #elif support.
>
> 2) #warning support (at least for non-continued lines).
>
> 3) Support asm() at file scope. This is to allow the equivalent
>    of #asm/#endasm in macros.
>
> 4) Limited support for things like "#define stdio stdio". Stock bcc
>    goes into an infinite loop when encounting this. The implementation
>    has flaws, but it does what I needed. You see this a lot in the
>    glibc headers we're using with uClibc (yes I'm working on a port).
>
> 5) Improved condition wrapping of the floating point related code in
>    the bcc source (working towards building bcc for elks). As I said,
>    the code generator dies... at least using elksemu.

Can I add some wish-list items:

  6) True support for the "signed" keyword. At the moment, any file
     using it has to include a "#define signed" line to remove it for
     bcc, and in some cases, even that isn't enough as the code stops
     working as a result.

  7) At least a warning message if any unrecognised options are given
     on the command line. At the moment, unrecognised options are just
     silently ignored!

Also, are there any plans to get these included in the primary bcc code?

Best wishes from Riley.