Hi Guys,

We have finished the conversion of the assembler modules in Mesa to 
separate NASM'able .asm files, that work correctly with our compilers 
for all the platforms we support (DOS, Win32, OS/2, Linux, QNX and 
embedded systems). We have some new changes that were checked in this 
week to get included, but all the code is converted and working 
properly. I will be submitting those changes to CVS as soon as the 
CVS server is back up.

I would like to re-open the issue of switching to using NASM 
exclusively for all the assembler modules used in Mesa. There are a 
number of important reasons for this:

 1. The current assyntax.h mechanism is simply not portable. This 
mechanism relies on the availability of a *working* C pre-processor, 
and this is unfortunately not a luxury available on the DOS, Windows 
and OS/2 platforms. Many compilers we use (Watcom C++ and Borland C++ 
specifically) do not handle C pre-processing very well, and did not 
work with the assyntax.h stuff. Visual C++ worked the best, and that 
is what we used to do the conversion.

 2. The current mechanism to get NASM'able assembler code simply did 
not work. We tried to use it, and modified the macros as much as we 
could to make it work, but the resulting assembler code would not 
build. Instead we had to hand modify the code from the Visual C++ pre-
processed variants, which is what we will be checking in.

 3. Using our freely available macro package (one file; scitech.mac) 
the NASM assembler code can use named function arguments, named local 
variables and clean interfacing to different C compilers (which have 
varying requirements for leading underscores for function names and 
variables, something not handled by the current incarnation of 
assyntax.h). Hence the existing code can be augmented to aid better 
understanding by using the power of a real macro assembler.

 4. NASM can produce debug information in the object files (currently 
only for Borland C++ and Watcom C++, but GNU support is in the 
works). This makes it a *lot* easier to debug assembler code modules 
than looking at plain old dissassembly.

 5. NASM is available in source form, and hence is available 
anywhere. We have pre-built binaries for DOS, Win32, OS/2, Linux and 
QNX, and we have never had a problem building the sources. Hence the 
NASM solution is entirely portable and will work on multiple 
platforms.

For the above reasons I am strongly recommending that the existing 
assyntax.h style assembler code be dropped in favour of the NASM 
versions.

NOTE: I am currently struggling with the CPP issues for the XFree86 
port to Win32, as the entire Imake system depends on a working C pre-
processor as well. For this task we will probably be building a pre-
built imake.exe program for all supported compilers that uses the GNU 
C pre-processor (the only one that seems to work reliably!).

Regards,

+---------------------------------------------------------------+
|   SciTech Software - Building Truly Plug'n'Play Software!     |
+---------------------------------------------------------------+
| Kendall Bennett          | Email: [EMAIL PROTECTED]    |
| Director of Engineering  | Phone: (530) 894 8400              |
| SciTech Software, Inc.   | Fax  : (530) 894 9069              |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |
+---------------------------------------------------------------+



_______________________________________________
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Reply via email to