Re: Got dropped...

H. Peter Anvin wrote:
> H. Peter Anvin wrote:
>
> I would really like to deprecate 16-bit NASM formally at thing point. 
> That beast is giving us nothing but trouble, and keeps us from doing 
> sane things in the source, including but not limited to the ridiculous 
> memory allocation interfaces.

Amen!  Anyway, anybody who really needs that can continue to use the 
0.98.38 version in perpetuity.  It's not like they'll be needing the 
latest 64-bit stuff!

> Going from there, I see a few things as being absolutely criticial:
>
> - Saner backends, at least the ELF output is full of bugs.  Can we use 
> libbfd?

I would argue for cleaned up inter-module interface first and THEN saner 
backends.  My big pet peeve is the preprocessor's interface to the rest 
of the system, so I'll volunteer to take that on.

> - 64-bit support.  x86-64 has gained huge momentum.  This means new 
> backends!
> - On the note above, actually use portable types; use <inttypes.h> and 
> provide substitutes for those that don't have it, if those compilers 
> still matter.

I think we should handle those by exception -- move first and address 
complaints if they turn up.  Time marches on...

> On the subject of "compilers which still matter"... this is perhaps a 
> somewhat odd comment, but are there any x86 platforms which matter which 
> still don't have a working and well-maintained port of gcc?  DOS has 
> DJGPP, Win32 has MingW, and gcc is the native compiler for most of the 
> Unixy variants (except Solaris, but gcc runs fine on it, and the Sun 
> compiler is sane.)  If nothing else, it would let us raise the baseline 
> feature set expected by a compiler.  Perhaps it's not really that big of 
> a deal; after all most of the issues are library issues.  The #1 
> compiler issue, of course, is uint64_t support (one can write a C++ 
> class for it if one has to deal with a platform that has C++ but no 
> 64-bit integer support).

I think we should also clean up the code we've got.  I mentioned splint 
before; I'll go ahead and add just three lines to Makefile.in to allow 
one to do "make splint" (but I'm open to alternative names) and get a 
diagnostic dump of what that tool thinks is awry.

Ed



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/