There are a lot of requests lately for the Netwide Assembler to support reading C header files. I don't really see this feature being added anytime soon (despite various dev-team members positive outlook on the request) because there is way too much C code in the headers.
Okay, so maybe that doesn't make much since. What I mean by that is, once the headers are preprocessed, there is a ton of keywords like "typedef", "struct", etc. that are generated. In order to fully support the C headers, you'll basically have to support these C constructs (which goes against the core design of NASM).
If, however, you were to code your own C headers which you wanted to include in your NASM source, well that's all fine and dandy. In fact, you can already do it! Heh, don't believe me. Try this:
Code: (sample.asm) [Select]
/**
* Filename: sample.asm
* Developer: Bryant Keller (bkeller@asmcommunity.net)
* Created: Tue Aug 9, 9:45 PM EST 2011
* Purpose: This is NASM compatible source code using the
* C preprocessor.
* Build with:
* cpp -o sample.S sample.asm
* nasm -f elf -o sample.o sample.S
* ld -o sample sample.o
*/
#define __ASSEMBLY__
#include <asm/unistd.h>
/**
* When GNU AS includes any of the standard headers, it
* automatically generates a symbol called __ASSEMBLY__
* which lets the C preprocessor know it shouldn't include
* things wrapped in a preprocessor block like so:
#ifndef __ASSEMBLY__
...
#endif
* Unfortunately, this isn't upheld in many headers so
* those which don't abide by this construct (like stdio.h)
* cannot be used directly by the assembler. Check out the
* /usr/include/asm and /usr/include/asm-generic sub-directories
* for other files which are "more likely" compatible with
* assembly source.
*
* In this case, we are using the asm/unistd.h file which
* contains the specific __NR_* Linux system calls. What
* is even cooler, since the preprocessor will autodetect
* the target processor (ie. __i386__) we don't have to
* define it and it'll automatically pick the proper one.
*/
/** Lets make a C macro. */
#define SYS(x) __NR_ ## x
;--- Now lets do a little NASM ---
BITS 32
SECTION .data
strMessage DB "Hello, World!", 10
lenMessage EQU ($-strMessage)
SECTION .text
GLOBAL _start
_start:
mov edx, lenMessage
mov ecx, strMessage
mov ebx, 1 ; STDOUT_FILENO
mov eax, SYS(write)
int 0x80
xor ebx, ebx
mov eax, SYS(exit)
int 0x80
OMG! Did that just work! Heh, yep. GCC's preprocessor doesn't care about anything except the preprocessor code itself. Which means we can still make use of C style comments, C macros, and C preprocessor directives which can do some early binding stuff for us before handing off to NASM's preprocessor!
I hope this little snippet will help people in some way. It might at least put an end to the tired request for C preprocessor support in NASM. It might even spark a few of those people making requests to direct their anger over "_______ Assembler won't read my favorite C headers, will someone port it?" back onto the C community for not making use of the __ASSEMBLER__ directive like they are supposed to be doing.
[
Messages: 620
Topics in blog: 2
Categories
Views