Hi all,


I am looking for a way to use the common header files for my nasm and C
code. the nasm syntax for defining macros is:

%define abc 1

where as in C:

#define abc 1

so I am facing a problem in using the same header file containing
macros in both.

If there is some way please let me know.


Thanks.

In article <1153727188.755605.154750@i3g2000cwc.googlegroups.com>
           spamtrap@crayne.org "hackkaush"  writes:

> I am looking for a way to use the common header files for my nasm and C
> code. the nasm syntax for defining macros is:
> 
> %define abc 1
> 
> where as in C:
> 
> #define abc 1
> 
> so I am facing a problem in using the same header file containing
> macros in both.
> 
> If there is some way please let me know.

I have no idea whether or not it would work but you could try 
putting lines like

DEFINE abc 1

in your header files and putting "-d DEFINE=#define" or some such 
on the cc command line, and "-d DEFINE=#define" on the NASM one.  
I don't use nasm so this could be a non-starter if such an option 
is not available...

Pete
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."

hackkaush wrote:
> Hi all,
> 
> 
> I am looking for a way to use the common header files for my nasm and C
> code. the nasm syntax for defining macros is:
> 
> %define abc 1
> 
> where as in C:
> 
> #define abc 1
> 
> so I am facing a problem in using the same header file containing
> macros in both.
> 
> If there is some way please let me know.

I don't know why assembler authors didn't think to make their assemblers 
accept "#define"... I think Gas will include .h files(?). But that won't 
help you with Nasm...

Johannes Kroll has written a "converter" from .h files to something Nasm 
will read. Won't read *everything* that you might find in an .h file, 
but if you can keep the "common" .h files within its capacities, you can 
run it on .h files as part of your build process. That's the closest I 
know of to what you'd like to do...

Site where I found it seems to not find it. Latest version I have is here:

http://home.comcast.net/~fbkotler/h2incn-0.5.tar.gz

Thanks, Johannes!!!

Best,
Frank

spamtrap@crayne.org wrote:
>
> I have no idea whether or not it would work but you could try
> putting lines like
>
> DEFINE abc 1
>
> in your header files and putting "-d DEFINE=#define" or some such
> on the cc command line, and "-d DEFINE=#define" on the NASM one.
> I don't use nasm so this could be a non-starter if such an option
> is not available...

Alas, and sadly, cpp will only do one level of text replacement. Don't
know about NASM.
Of course, one solution is to run your header file through a
preprocessor first (such as M4) or write your own preprocessor that
takes a generic input file and produces a C and a NASM header file.
Cheers,
Randy Hyde

Frank Kotler wrote:
>
> I don't know why assembler authors didn't think to make their assemblers
> accept "#define"... I think Gas will include .h files(?). But that won't
> help you with Nasm...

I was under the impression that GoAsm did this.
Then again, as a result of choosing to mimic the C preprocessor,
GoAsm's macro facilities tend to be much weaker than those found in
other assemblers.

>
> Johannes Kroll has written a "converter" from .h files to something Nasm
> will read. Won't read *everything* that you might find in an .h file,
> but if you can keep the "common" .h files within its capacities, you can
> run it on .h files as part of your build process. That's the closest I
> know of to what you'd like to do...
>
> Site where I found it seems to not find it. Latest version I have is here:
>
> http://home.comcast.net/~fbkotler/h2incn-0.5.tar.gz
>
> Thanks, Johannes!!!

Of course, the problem with the ".h"->".inc" translators is that they
only work with a tiny subset of the stuff that normally appears in an
..h file. Of course, if you're specifically writing the .h file for
assembly and C usage, this would work.
Cheers,
Randy Hyde

On 25 Jul 2006 17:21:02 -0700
"randyhyde@earthlink.net"  <spamtrap@crayne.org> wrote:

:Of course, the problem with the ".h"->".inc" translators is that they
:only work with a tiny subset of the stuff that normally appears in an
:.h file.

This may be true for specific translators which you have looked at, but my
experience is that the only thing which is particularly intractable is the
macro definitions.

-- Chuck

Charles A. Crayne wrote:
> On 25 Jul 2006 17:21:02 -0700
> "randyhyde@earthlink.net"  <spamtrap@crayne.org> wrote:
>
> :Of course, the problem with the ".h"->".inc" translators is that they
> :only work with a tiny subset of the stuff that normally appears in an
> :.h file.
>
> This may be true for specific translators which you have looked at, but my
> experience is that the only thing which is particularly intractable is the
> macro definitions.

Are we not talking about macro definitions in this thread?

It is *very* rare for a typical C header file to translate easily to
assembly language. First of all, too much C code and arithmetic
expressions tend to appear in the header files. Second, only a few
assemblers (e.g., MASM, TASM, and HLA) support things like structs,
unions, classes, and type definitions that allow easy translation from
the C/C++ types into assembly.

Sure, translating simple #defines that effectively define constants or
very simple text substitutions works okay, and converting *some*
external declarations usually works, but I've yet to see a serious .h
file go through one of these converters and produce an output file that
didn't need *major* modification to work.  For example, don't try this
with most of the Windows header files and try to create a NASM
equivalent.
Cheers,
Randy Hyde

On 26 Jul 2006 09:24:07 -0700
"randyhyde@earthlink.net"  <spamtrap@crayne.org> wrote:

:Are we not talking about macro definitions in this thread?

Not seeing any value in discussing the definition of a macro, let me
merely state that my usage of the term is consistent with the definition
found on Whatis.com, "A macro is a programming language statement that,
when processed, generates a sequence of more detailed language statements."

:It is *very* rare for a typical C header file to translate easily to
:assembly language.

This has not been my experience, which, as you know, is somewhat greater
than yours.

:For example, don't try this
:with most of the Windows header files and try to create a NASM
:equivalent.

For reasons which have nothing to do with this thread, I have no intention
of converting any Windows header files. However, I have converted portions
of several Linux header files to both NASM and FASM, and the results are
available on my web site, for all to see.

-- Chuck

And can you tell that what is you website?


Charles A. Crayne wrote:
> On 26 Jul 2006 09:24:07 -0700
> "randyhyde@earthlink.net"  <spamtrap@crayne.org> wrote:
>
> :Are we not talking about macro definitions in this thread?
>
> Not seeing any value in discussing the definition of a macro, let me
> merely state that my usage of the term is consistent with the definition
> found on Whatis.com, "A macro is a programming language statement that,
> when processed, generates a sequence of more detailed language statements."
>
> :It is *very* rare for a typical C header file to translate easily to
> :assembly language.
>
> This has not been my experience, which, as you know, is somewhat greater
> than yours.
>
> :For example, don't try this
> :with most of the Windows header files and try to create a NASM
> :equivalent.
>
> For reasons which have nothing to do with this thread, I have no intention
> of converting any Windows header files. However, I have converted portions
> of several Linux header files to both NASM and FASM, and the results are
> available on my web site, for all to see.
> 
> -- Chuck

"hackkaush" asked:
> The nasm syntax for defining macros is:
> %define abc 1
> where as in C:
> #define abc 1
> so I face a problem in using the same header file containing
> macros in both.
>
> If there is some way please let me know.

In regards to the OPs problem...

Does NASM support any sort of #ifdef so as to handle the
OPs problem? How does one tell if NASM is processing the
file as opposed to another compiler? Or is there a defined
compiler constant that can be checked?

-- 
Jim Carlock
Post replies to the group.

On 27 Jul 2006 01:05:54 -0700
"hackkaush"  <spamtrap@crayne.org> wrote:

:And can you tell that what is you website?

To begin with, let me apologize for aiding and abetting Randy to hijack
your thread. Next, I hope I didn't set any false expectations by my use of
the phrase "FASM and MASM". I did not, in fact, use the same include file
for both assemblers, but rather created separate include files for each.

With this understood, if you still wish to see my code, you can find it at
http://www.pacificsites.com/~ccrayne/download/. Under the nasm
subdirectory, you will find nxgame.tar, which untars to a nxgame
directory, and an include directory. Under the fasm subdirectory, the
axgame.tar.gz file contains only the code files, you also need the
include.tar.gz file.

If you have any questions about this code, or my development environment,
feel free to ask.

-- Chuck

Charles A. Crayne wrote:
> . However, I have converted portions
> of several Linux header files to both NASM and FASM, and the results are
> available on my web site, for all to see.

But the header files appearing in this game are particularly trivial.
Let's look at them:

;nxgame.inc
WINDOW_WIDTH	equ 400
WINDOW_HEIGHT	equ 300
FONT_SMALL	equ 1
FONT_MEDIUM	equ 2
FONT_LARGE	equ 3
MAX_IMAGES	equ 256
FRAME_LEN	equ 50000

;input.inc
MOUSE_PRESSED  equ 1
MOUSE_RELEASED equ 2
MOUSE_DRAGGED  equ 3
KEY_PRESSED    equ 4
KEY_RELEASED   equ 5

MOUSE_UNKNOWN  equ 0
MOUSE_LEFT     equ 1
MOUSE_MIDDLE   equ 2
MOUSE_RIGHT    equ 3

KEY_UNKNOWN equ 0
KEY_LEFT   equ 1
KEY_RIGHT  equ 2
KEY_UP     equ 3
KEY_DOWN   equ 4
KEY_SPACE  equ 5
KEY_Q      equ 6
KEY_ESCAPE equ 7
KEY_TAB    equ 8

;win.inc
;win.inc
	%include	'nxgame.inc'
	%include	'input.inc'
	%include	'../../include/clib.inc'
	%include	'../../include/X.inc'
	%include '../../include/cdecl.inc'
	%include	'../../include/nasm2.mac'
	global	get_color
	global	win_create
	global	win_eventloop
	global	win_close
	global	win_sync
	global	win_StringWidth
	global	win_StringHeight
	global	win_DrawText
	global	win_FillRectangle
	global	win_DrawRectangle
	global	win_DrawLine
	global	win_LoadImage
	global	win_DrawImage
	global	win_ClearImages
	global	win_DrawWindow
	global	win_alloc_color
	global	time_diff
	global	private_colormap
	global	pdisplay
	global	win
	global	cmap
	global	idx
	global	s_time
	global	r_time
	extern	game_ProcessKey
	extern	game_ProcessMouse
	extern	image_draw
	extern	image_create
struc	ColorTable
  .pixel	resd	1
  .r		resd	1
  .g		resd	1
  .b		resd	1
endstruc


Of these, only win.inc is particularly interesting. Imagining what the
original C header files look like, I would have no problems believing
an automated program would whiz through these headers with no problems
at all. However, if your vast amount of experience consists of
converting header files like these to assembly, then I'd suggest that
perhaps your claim that you have a lot more experience than me in this
area is a bit overrated.

Now as long as the OP sticks to simple constants, external function
declarations (with no issues concerning parameters and types, which is
reasonable for NASM), and simple struct definitions, I have no question
that h2inc could do the job. But for anything more complex, h2inc is
going to break.
Cheers,
Randy Hyde

On 29 Jul 2006 17:32:07 -0700
"rhyde@cs.ucr.edu"  <spamtrap@crayne.org> wrote:

:But the header files appearing in this game are particularly trivial.

You're looking at the wrong files. As you say, the header files which are
under the user's control can be, and were, kept simple. On the other
hand, the user has no control over the OS include files, and it is there
that one must go to test your claim that "It is *very* rare for a typical
C header file to translate easily to assembly language."

In this example, the test is to see how much of the Linux X.h and
Xlib.h files I was able to translate to X.inc.

X.h starts by setting up a number of typedef statements, which do not, by
themselves, generate any statements in X.inc, but which must still be
parsed, because their definitions will be needed later.

Next, we find definitions which assign numeric values to text strings. For
example:

#define KeyPress                2
becomes:
Keypress	equ		2

or, if an expression is more convenient,

#define KeyPressMask                    (1L<<0)
becomes:
%define KeyPressMask                    (1 << 0)

That's it for X.h, so let's move on to Xlib.h, which, since it is the
interface to the X library routines, has some additional types of
definitions.

extern Window XCreateSimpleWindow(
    Display*            /* display */,
    Window              /* parent */,
    int                 /* x */,
    int                 /* y */,
    unsigned int        /* width */,
    unsigned int        /* height */,
    unsigned int        /* border_width */,
    unsigned long       /* border */,
    unsigned long       /* background */
);
becomes merely:
extern XCreateSimpleWindow

while

typedef struct {
        int function;           /* logical operation */
        unsigned long plane_mask;/* plane mask */
        unsigned long foreground;/* foreground pixel */
        unsigned long background;/* background pixel */
        int line_width;         /* line width */
        int line_style;         /* LineSolid, LineOnOffDash, LineDoubleDash */
        int cap_style;          /* CapNotLast, CapButt,
                                   CapRound, CapProjecting */
        int join_style;         /* JoinMiter, JoinRound, JoinBevel */
        int fill_style;         /* FillSolid, FillTiled,
                                   FillStippled, FillOpaeueStippled */
        int fill_rule;          /* EvenOddRule, WindingRule */
        int arc_mode;           /* ArcChord, ArcPieSlice */
        Pixmap tile;            /* tile pixmap for tiling operations */
        Pixmap stipple;         /* stipple 1 plane pixmap for stipping */
        int ts_x_origin;        /* offset for tile or stipple operations */
        int ts_y_origin;
        Font font;              /* default text font for text operations */
        int subwindow_mode;     /* ClipByChildren, IncludeInferiors */
        Bool graphics_exposures;/* boolean, should exposures be generated */
        int clip_x_origin;      /* origin for clipping */
        int clip_y_origin;
        Pixmap clip_mask;       /* bitmap clipping; other calls for rects */
        int dash_offset;        /* patterned/dashed line information */
        char dashes;
} XGCValues;

turns into:

struc   GCValues
        .function       resd    1       ; logical operation
        .plane_mask     resd    1       ; plane mask
        .foreground     resd    1       ; foreground pixel
        .background     resd    1       ; background pixel
        .line_width     resd    1       ; line width
        .line_style     resd    1       ; LineSolid, LineOnOffDash,
                                        ; LineDoubleDash
	.cap_style      resd    1       ; CapNotLast, CapButt,
                                        ; CapRound, CapProjecting
        .join_style     resd    1       ; JoinMiter, JoinRound, JoinBevel
        .fill_style     resd    1       ; FillSolid, FillTiled,
					;FillStippled, FillOpaeueStippled
        .fill_rule      resd    1       ; EvenOddRule, WindingRule
        .arc_mode       resd    1       ; ArcChord, ArcPieSlice
        .tile           resd    1       ; tile pixmap for tiling operations
        .stipple        resd    1       ; stipple 1 plane pixmap for
					;stipping 
	.ts_x_origin    resd    1       ; offset for tile or stipple
					;operations 
	.ts_y_origin    resd    1
        .font           resd    1       ; default text font for text
					;operations 
	.subwindow_mode resd    1       ; ClipByChildren,
					;IncludeInferiors 
	.graphics_exposures  resd       1       ; boolean, should
					;exposures be generated 
	.clip_x_origin  resd    1       ; origin for clipping 
	.clip_y_origin  resd    1
        .clip_mask      resd    1       ; bitmap clipping, other calls for
					;rects 
	.dash_offset    resd    1       ; patterned/dashed line information
        .dashes         resb    1       ;
    endstruc

Which leaves only the macros such as:

#define BlackPixel(dpy, scr)    (ScreenOfDisplay(dpy,scr)->black_pixel)

On the one hand, these are non-trivial to automatically convert,
but the redeeming feature is that an assembly language programmer wouldn't
even think about using such a macro in new code.

In summary, I have demonstrated how I easily converted all of X.h and
about 90% of Xlib.h into assembly language.

QED

-- Chuck

On Di, 2006-07-25 at 01:33 -0400, Frank Kotler wrote:

> I don't know why assembler authors didn't think to make their assemblers 
> accept "#define"... I think Gas will include .h files(?). But that won't 
> help you with Nasm...
> 
> Johannes Kroll has written a "converter" from .h files to something Nasm 
> will read. Won't read *everything* that you might find in an .h file, 
> but if you can keep the "common" .h files within its capacities, you can 
> run it on .h files as part of your build process. That's the closest I 
> know of to what you'd like to do...
> 
> Site where I found it seems to not find it. Latest version I have is here:
> 
> http://home.comcast.net/~fbkotler/h2incn-0.5.tar.gz
> 
> Thanks, Johannes!!!

Thanks Frank for "mirroring" it :) The old server is down. I updated the
links on freshmeat, you can get h2incn here:
http://freshmeat.net/projects/h2incn/

It converts many things commonly used in .h files, including structs and
classes (partly).. It can also generate call macros, see --help. You
should check if the converted files are correct, eg. the size of struct
members is "guessed" when the data type is unknown. It assumes 32-bit
x86 (ie. int and pointers are 4 bytes long), which is OK because
"official" Nasm versions only support x86 anyway. With some hand
tweaking it is also possible to convert larger system header files (I
experimented with ddraw.h for example)... It doesn't do "C++ name
demangling" because every compiler implements that differently, even
different versions of GCC differ. Use extern "C" instead.

Of course complex C macros which generate runtime code do not translate
well to asm. :-) To translate these, you would have to write a parser
which "understands" C code, and then converts it to a Nasm %macro (which
creates all sorts of problems. Register usage?). h2incn doesn't try to
do that, it's intended for headers which are meant to be converted to
Nasm syntax.

All comments are stripped, too. This isn't easily corrected because they
are removed at the beginning when the file is read. I didn't think this
was important because normally you would keep the original .h file
anyway, for #includeing in your C code...