I'm trying to compile the following:

org 100h

%include "c16.mac"

%macro Exit 0
              mov al, 0h
              mov ah, 4ch
              int 21h
%endmacro

              proc _nearproc
%$i       arg
%$j       arg
              mov ax,[bp + %$i]
              mov bx,[bp + %$j]
              add ax,[bx]
              endproc

section .data
val        dw 50
val2      dw 90

section .text
             mov ax, val
             mov bx, val2
             call _nearproc
             Exit

The procedure comes out of the NASM documentation.  The assembler doesn't
like the arguments %$i and %$j.  The error message is something like
"instruction expected"

What am I doing wrong here?  I'm new to the NASM syntax, so please excuse my
ignorance if this is a really stupid question.  I'm using version .98 and
running in a dos prompt window.

Hello {*filter*}folk!

On Sat, 2 Feb 2002 22:27:35 +0000 (UTC), michelle spake thus:

I'm not sure why you are getting the error you are getting, but I can
see another error that you will not notice until you run the code.

It looks like you are trying to pass the arguments in registers, and
the proc macro expects them to be on the stack. The first argument
should be pushed last.....

I dont use many of the macro facilities in nasm, so hopefully someone
who does can help with that. If it's a bug, I'm sure Frank will tell
us (he does seem to know more of what's happening with nasm than most
of us....), but it's not something I remember being mentioned on the
nasm development mailing lists.

Can you post exactly what the error message, and show us which line(s)
the message refers to? It'll make it easier to track down....

Also, it might sound like a daft question, but have you got c16.mac in
the same directory as either your source code or nasm? If not, that
could explain the problem.... If you downloaded an executable without
the source code, you might not have the macro files (depends where you
downloaded from). If you haven't got it, and you need it, I'll give
you details of how to get it.

--
debs

----
Misspelled? Impossible! I have an error correcting modem.

I saw the run-time stack problem after I posted.  Thanks.  I moved the
procedure to the end of the file.  In another test program, I encountered a
starting point problem.  (The documentation says to use ..start:, but that
gave me a compiler error as well.)  So I guess a second question is how to
give the code an explicit starting point.

Yes, I copied c16.mac to the same directory as the test file.

Rummaging around the internet, I found a somewhat similar thread that gave a
problem using %$i in a macro.  The suggested solution was to use .i instead.
I compiled using the dot and I get no errors.  But does this mean the same
thing?  What I'm after is a locally defined variable (so I can use the same
identifier in another procedure).  I also want to do the same thing with
labels.  Using %DmyLab, for example, in the procedure generates an error as
well.

The exact error message is:
macrotest2.asm:24: error: parser: instruction expected
macrotest2.asm:25: error: parser: instruction expected

Lines 24 and 25 are
%$i    arg
%$j    arg

The source follows:

%include "c16.mac"

%macro Exit 0
         mov al, 0h
         mov ah, 4ch
         int 21h
%endmacro

section .data
          val dw 50
          val2 dw 90

section .text
          push word [val2]
          push word val
          call _nearproc
          pop bx
          pop ax
          Exit

proc _nearproc
%$i       arg
%$j       arg
          mov ax,[bp + %$i]
          mov bx,[bp + %$j]
          add ax,[bx]
endproc

If you're using "-f obj" format, "..start:" should work - it's
recognised *only* in "-f obj" format. Your code looks like it's intended
for "-f bin" format (no "mov ax, data"/"mov ds, ax"...). In "-f bin"
format, you can't specify a starting-point - it starts at the beginning
of your ".text" segment.

In some distributions of Nasm, there  are two sets of "c16/c32.mac"
files. The ones in the "misc" directory are broken - I think they work
with Nasm 0.97 - the set in the main source directory work (?). I think
that might be the problem, at least it would cause the problem you're
seeing. As debs said, I know a little about Nasm, but macros are not my
strong point - I hardly ever use 'em.

Try "%%DmyLab" - I *think* that's how macro-local labels are done. Nasm
uses the dot for local labels - ".label" actually becomes
"last_non_local_label.label" internally. I'm not sure if it will work
properly inside a macro or not. Try it. Use the "preprocess only" option
- "nasm -e -o myfile.pre myfile.asm" - to see what you're getting.

Not very helpful. It's not trivial to produce an intelligent
error-message when the problem, essentially, is that Nasm's confused.
Nasm isn't alone in having this problem, IMO, but it *is* something that
could use work.

I could be mistaken, but I think you're swapping "val" and "[val2]"
here, aren't you? As I interpret it, "i" is the "first variable up the
stack" - the offset of "val" - and you're putting that in ax...

But you've got to get the thing to assemble, before you worry about
that. I'm not the right one to educate you about Nasm's macros. I hope
someone who actually uses them can help. FWIW, here's the difference in
the macro files:

This is the "good" one...
---------------
%imacro arg 0-1 2               ; used with the argument name as a label

%00       equ %$arg

                                ; we could possibly be adding some

                                ; debug information at this point...?

%assign %$arg %1+%$arg

%endmacro
-----------------

And this is the "broken" one...
----------------------
%imacro arg 0-1 2               ; used with the argument name as a label
          equ %$arg
%assign %$arg %1+%$arg
%endmacro
---------------------

If that's the problem, you may be all set. I hope so - if I liked
punctuation that well, I'd be using Gas :)

Best,
Frank

That explains my problem, then.  I am using -f bin.

For c16.mac, the version I have corresponds to the "good" version that you
listed  (but it originally came out of the misc directory).  The one in the
main source directory gives the same results.

Yep.  That's my proud display of "I'm new to NASM and still fuddling with
the syntax."  I'm used to TASM.

Using the .DmyLab notation seems to be working.  The puzzle I'm still left
with, though, is creating a local variable.  Inside the proc I suppose I
could do something like
..local_var    equ    -2
for a word size variable and then access it via
[bp + .local_var]      ; bp is the stack frame bp
but this seems rather cumbersome.  Is there a better way?

Thanks.

My crystal ball tells me you're using a recent version of Nasm -
0.98.08+, right? I would have tried this sooner, but I really don't use
macros enough to really know what the *expected* results are going to be
(but I know what a proc with a stack-frame should look like...). It
seems that Nasm 0.98 or 0.98bf assembles your code as expected - worked
for me, anyway (I did add "org 100h" at the top of your code, since it's
a ".com" file). The "latest" versions of Nasm are broken, apparently,
and give the error-message you're seeing.

It's a shame I have to advise you to go back to an earlier version of
Nasm - I was hoping, since you're familiar with Tasm, that I could ask
you to check out the new "-t" switch, and see if it's good for anything
:)

Best,
Frank

Better's a matter of taste, I suppose. There are different ways. Don't
let my ignorance of macros turn you away from them.

Both:
http://www.phoenix.gb.net/x86/
and:
http://rs1.szif.hu/~tomcat/win32/
have packages for windows programming that include macro files quite a
bit nicer than c16.mac. Here's a teaser from the latter...

;----------Procedure Declarations
;Usage:
;PROC ProcName Parameter1, Parameter2, Parameter3...
;LOCALDD Dword_Variable [opt]
;LOCALDW Word_Variable [opt]
;LOCALDB Byte_Variable [opt]
;   ;procedure code here
;ENDP
;
;ENTRYPROC
    ;procedure code here
;ENDP
;
;Note that parameters are set up to EQU to ebp-x
;Note that locals are set up to EQU to ebp+x
;Note that neither LOCALS or Parameters are necessary, as in ENTRYPROC

%macro PROC 1-9
GLOBAL %1
%1:
 %assign _i 4
 %rep %0-1
    %2 equ [ebp-_i]
 %assign _i _i+4
 %rotate 1
 %endrep
    push ebp
    mov ebp, esp
 %push local
 %assign __ll 0
%endmacro

%macro ENDP 0
 %ifctx local
  %pop
 %endif
    pop ebp
%endmacro

%macro ENTRYPROC 0
PROC main
%endmacro

%macro LOCALVAR 1
    sub esp, 4
    %1 equ [ebp + __ll]
%endmacro

%macro LOCALDB 1
  %assign __ll __ll+1
  LOCALVAR %1
%endmacro

%macro LOCALDW 1
  %assign __ll __ll+2
  LOCALVAR %1
%endmacro

%macro LOCALDD 1
  %assign __ll __ll+4
  LOCALVAR %1
%endmacro
;----------------------

Macros are available to call procedures as well, of course (I assume
that's where you're headed) - Pascal, C, stdcall, fastcall, you name it,
and other high-level constructs - switch/case, for, repeat/until/,
do/while - I suppose you could write "begin/end" macros and write Nasm
that looked like HLA (then get HLA to output Nasm code - no, that would
cause an infinite loop :)

There's another set of macros available at:
http://www.linuxassembly.org

even if you're not interested in linux assembly, the macros are
impressive. They allow the same source code to be assembled for linux or
BSD or BeOS (?), with the correct syscalls produced for whichever is
defined on the command line. Then there's the "mov helpers" macro. You
know that "mov eax, 0" is "bloated" code, and you'd probably write "xor
eax, eax" instead. You might realize that something like "mov eax, 300h"
could be replaced with "xor eax, eax"/"mov ah, 3" and it would be
shorter, but you probably wouldn't write something like that unless you
were really desperate to save every possible byte. By including this
macro, you can write "_mov eax, 300h" and have it replaced with shorter
code "behind your back". This clobbers the flags, so it's not "exactly
the same", but it's an interesting concept.

I don't like to have things "hidden away" so I'm not much "into" macros.
They're almost indispensible for Windows programming - even I don't need
to see "push push call push push call push push call" :)

Sorry my unfamiliarity with macros caused me to miss that it was a bug
in Nasm that was causing your original problem.

Best,
Frank