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

arargh402NOSPAM_at_NOW.AT.arargh.com
Date: 02/21/04 

Date: Sat, 21 Feb 2004 16:26:30 -0600

On Sat, 21 Feb 2004 21:50:51 GMT, "Randall Hyde"
<randyhyde@earthlink.net> wrote:

>
><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.
True.

But, since I only program in assembler & Basic those are the only
interesting cases for me. However, the program I started to write is
not limited to just that.

>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.
You may well be correct. H2INC used to do a fair job of it, but it is
ten years out of date, and gets sick on a lot of current VC 6 header
files.

>
>> 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.
I did mention unions, and I meant to forget classes, at least for now.

>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
> 

-- 
Arargh402 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
Loading