#18 C Header File Support

[Anonymous]

When doing assembly language under Linux you need to use a lot of constants which are available in header files such as "/usr/include/asm/mman.h". These contain a lot of lines like:

#define PROT_READ 0x1 /* some comment */

Obviously expecting NASM to understand C is too much, but if it could understand the #define lines like above, and simply ignore all that is too complicated, it would do a lot to simplify assembly under Linux.

This could be done with something like the following:

%partially_include_c "/usr/include/asm/mman.h"

Which would cause NASM to process the #define lines and ignore everything else that it doesn't understand.

I've thus far been copying things out of the header files and converting them to NASM format and putting them in one big file, which is currently 591 lines long. The reason those constants are in header files is so that they can be different on different systems. The header file I created will only work on systems exactly like mine. On other systems, if the program doesn't work, someone will have to search through it and figure out which constants are different on their system,

This isn't a very important feature, since changing those constants would require one to recompile every binary on their system, and no one wants to do that when upgrading their kernel, so the constants will likely always be the same, but it would be a nice feature to have just in case, and to save having to convert the files in the first place.

BTW, NASM totally rocks.

rot13 crnwnl@riboflavin.pbz

[Nobody/Anonymous]

Logged In: NO

It would be possible to add support for a new command
line option, which enables the conversion of any #define
into %define inside the preproc.c prepreproc() function.

However, we should determine whether that is the right
solution. After all, there are plenty of tools which can be
used to perform a search-and-replace operation on such
header files, before they are fed through NASM.

IMO turning NASM into a swiss army knife is a bad idea.

[Nobody/Anonymous]

Logged In: NO

I'd like to bring forth another reason for NOT adding
this functionality to NASM itself: performance.

Yes, this may sound nit-picky -- but I really care a
lot about it. Simply because I have a few really big
projects, which slow down every time NASM ends
up with yet another feature.

In this case we'd slow down code which is invoked
for each and every source line. So I'm concerned.

PS: I often wondered though, why NASM didn't go
with a "#" to denote preprocessor directives. Does
anyone know? I mean, who really needs "#" to be
a valid identifier character (i.e. for labels)? :-)

[Nobody/Anonymous]

Logged In: NO

I'm the person who submitted this item.

I think everyone else is right, this is something that would be better
done outside the assembler. After converting a few more header files,
I've realized that the process is just too complicated to be done
automatically. Also, supplying converted header files with assembly
programs eliminates the possibility of someone else's header files not
getting interpreted correctly at compile time. So as far as I'm
concerned, this feature request can go away.

> I mean, who really needs "#" to be
> a valid identifier character (i.e. for labels)? :-)

I don't need it for labels or anything, but I do use a preprocessor that
converts my code to NASM syntax, and since the semicolon in my
code is used to seperate multiple instructions on the same line, I have
to use something else for comments, the # character works nicely. If
NASM used the # character, I'd have to use something less nice, like
the % character.

[Frank Kotler]

Logged In: YES
user_id=68913

Johannes Kroll has recently announced this tool (a "work in
progress"):

http://qwertycode.virtualave.net/h2incn.html

Might be of interest...

Best,
Frank

[nasm64developer]

Logged In: YES
user_id=804543

resolution: use a third-party tool

[nasm64developer]

Logged In: YES
user_id=804543

Attached you can find changes which I made to my
local forked version, to make the '%' character
flexible. For the time being I'm restricting the
alternatives to '#' though.

With these changes I am able to include C header
files; however, obvisouly they have to be using
the least common denominator between NASM and C.
Read: mostly "#DEFINE name expansion".

I was concerned about the performance impact of
storing the first character in a memory variable
instead of having it be hard-coded; however, my
testing with a large, preprocessor-heavy codebase
has shown virtually no performance difference --
hence I'm fine with these changes.

[nasm64developer]