Re: Canonical format for header files (was... who cares?)

From: Randall Hyde (randyhyde_at_earthlink.net)
Date: 02/21/04 

Date: Sat, 21 Feb 2004 21:50:51 GMT

<arargh402NOSPAM@NOW.AT.arargh.com> wrote in message
news:3ntc30l5thrvdkbci1hd9919lc6k1ljap7@4ax.com...
> On Fri, 20 Feb 2004 19:21:21 -0000, "Beth"
> <BethStone21@hotmail.NOSPICEDHAM.com> wrote:
>
>
>
> I just can't see that the extra conversion step is worth the bother.
> EVERY time the source header changes, you have to check the 'cf'
> (='canonical form') for changes. If you go from header to include,
> you can just add that step to the makefile, and not worry about
> changes. They get taken care of automagicly. (barring somebody
> having changed the names of things that are in use.)

First of all, compare that with what's going on today.
Even if there's only a little automation, it will be much better than
what we're doing now.

You also make the assumption that the only interesting path is
from C to some particular assembler. This is not the case.

The other issue is that you're not considering how *often* the
C header files change. While the interesting ones *do* change,
they don't change *that* frequently. Generally they change whenever
there is a new OS (or other system) release. You diff the old files
against the new files, see the differences (which usually aren't that
massive) and make the appropriate changes to the canonical files.
Even if this is done manually, it's not that big of a deal. And the
important thing is that it's only done once. Rather than having
each and every assembler user group repeat this work for their
particular assembler.

The alternative? Everyone continues doing all the work manually,
and the work gets repeated n times for n different assemblers.

BTW, an automatic conversion from C header to assembly include
file is as much of a pipe dream as Rene's perfect "automatic disassembler".
It would be nice to have a program that automatically converts from
C to a particular assembler, but it just isn't going to happen. As a result,
even if you went directly from C to a particular assembler, you'd *still*
have to go in an manually tweak the file. And you'd have to do it
*every* time you did one of these conversions. IOW, you'd wind up
makeing the *same* manual corrections each time you ran the
C->asm conversion program. I suspect that would be *far* more
work, in the long run, than making a few manual corrections to
a canonical file.

> The biggest problems that I see at the moment are things like nameless
> structs & unions and the fact that NASM has only one namespace.
> Windows include files have LOTS & LOTS of struct fields with the same
> field names. I don't about FreeBSD yet, but it probably does, also.
> Oh, and the '__P' macros in FreeBSD headers will be something of an
> annoyance, also. It means that I have to implement at least partial
> preprocessing, maybe all of it.

And don't forget unions and even classes.
Nonetheless, we *can* come up with a convention that will support
this. Or, at the very least, simply not translate the untranslatable to
NASM (or whatever). But you *still* want to keep that semantic
information around as more powerful assemblers like MASM, TASM,
and HLA fully support that stuff.

> VC 6 has 787 .h files, not counting the non .h include files. FreeBSD
> has 1093 .h files just in /usr/include. I didn't bother to count any
> others. Not all those would be needed, however, they are a large
> potential headache.

Yes, they are. And there are "n" assemblers out there, require "n"
conversions of all those header files. That's why a canonical form
would be nice. You only have to write "n" conversion programs
from canonical from to a particular assembler and only one
C->canonical form translator (which is the hard part). Likewise,
you only have to maintain *one* set of canonical files rather than
one set of include files for each assembler.
Cheers,
Randy Hyde

Quantcast