NASM lacks in some features
Quad
I'm working with NASM and there are some things I can't achieve with it. The
question is, is there anything I can do to get to the same result or am I
desesperately looking for something impossible?
The ORG pseudo instruction. We can only use it once in a source file;
putting two ORG makes all data references use the second one. This can be
very frustrating when you have to relocate your code somewhere else in
memory because any earlier memory references will use the relocated origin.
We can't concatenate text at assembly time. I hear you saying that this is
purposeless. Well, I've got a different opinion on that. Suppose I want to
do a %rep loop with a label in it so it will "declare" labels with the same
name and put a number at the end of each to differenciate them, like in the
following
%assign i 0
%rep 100
(Label & i): call function
%assign i i+1
%endrep
The result would be something like
Label0: call function
Label1: call function
Label2: call function
...
Label99: call function
And the last but not the least, when we assemble to .obj files and want to
compile with TLINK to produce a .COM file, it tells us that the program
starts at a "bad entry point for .com file".
If anyone has an answer or a way to achieve any of the above stated goals,
please tell me, I would really appreciate a hand! Thanks :)
Quad
qua...@videotron.ca
http://pages.infinit.net/quadid/sqos/
SQOS Homepage
H. Peter Anvin
By author: "Quad" <qua...@videotron.ca>
In newsgroup: comp.lang.asm.x86
>
> Hello,
>
> I'm working with NASM and there are some things I can't achieve with it. The
> question is, is there anything I can do to get to the same result or am I
> desesperately looking for something impossible?
>
> The ORG pseudo instruction. We can only use it once in a source file;
> putting two ORG makes all data references use the second one. This can be
> very frustrating when you have to relocate your code somewhere else in
> memory because any earlier memory references will use the relocated origin.
>
What would you expect it to *do* if you have more than one? If you
can provide a set of reasonable semantics for it (and I don't really
consider "jump around memory at random" to be reasonable semantics --
that's what ABSOLUTE is for) then perhaps we could make it work.
>
> We can't concatenate text at assembly time. I hear you saying that this is
> purposeless. Well, I've got a different opinion on that. Suppose I want to
> do a %rep loop with a label in it so it will "declare" labels with the same
> name and put a number at the end of each to differenciate them, like in the
> following
>
> %assign i 0
> %rep 100
> (Label & i): call function
> %assign i i+1
> %endrep
>
> The result would be something like
>
> Label0: call function
> Label1: call function
> Label2: call function
> ...
> Label99: call function
>
This is correct, and an annoying omission -- ran into it myself
recently. I will probably try to provide something like the C ##
operator in the next release -- if I ever end up doing any more NASM
releases.
>
> And the last but not the least, when we assemble to .obj files and want to
> compile with TLINK to produce a .COM file, it tells us that the program
> starts at a "bad entry point for .com file".
You *did* include a ..start: at org 0100h, didn't you?
>
> If anyone has an answer or a way to achieve any of the above stated goals,
> please tell me, I would really appreciate a hand! Thanks :)
>
-hpa
--
<h...@transmeta.com> at work, <h...@zytor.com> in private!
Al Leitch
I have no clue if this will work for your program, but it has always worked for
all of my codes.
--------------------------------------------------
Team2000 Palm Pilot/PC Programming Team (Win32/DOS ASM in NASM, C++ &
WordBasic):
http://ppilot.homepage.com
Quad wrote:
> Hello,
>
> I'm working with NASM and there are some things I can't achieve with it. The
> question is, is there anything I can do to get to the same result or am I
> desesperately looking for something impossible?
>
> The ORG pseudo instruction. We can only use it once in a source file;
> putting two ORG makes all data references use the second one. This can be
> very frustrating when you have to relocate your code somewhere else in
> memory because any earlier memory references will use the relocated origin.
>
> We can't concatenate text at assembly time. I hear you saying that this is
> purposeless. Well, I've got a different opinion on that. Suppose I want to
> do a %rep loop with a label in it so it will "declare" labels with the same
> name and put a number at the end of each to differenciate them, like in the
> following
>
> %assign i 0
> %rep 100
> (Label & i): call function
> %assign i i+1
> %endrep
>
> The result would be something like
>
> Label0: call function
> Label1: call function
> Label2: call function
> ...
> Label99: call function
>
> And the last but not the least, when we assemble to .obj files and want to
> compile with TLINK to produce a .COM file, it tells us that the program
> starts at a "bad entry point for .com file".
>
> If anyone has an answer or a way to achieve any of the above stated goals,
> please tell me, I would really appreciate a hand! Thanks :)
>
Thomas Junge aka LighTNing
H. Peter Anvin <h...@transmeta.com> schrieb in im Newsbeitrag:
7tuc9m$j6i$8...@autumn.news.rcn.net...
> What would you expect it to *do* if you have more than one? If you
> can provide a set of reasonable semantics for it (and I don't really
> consider "jump around memory at random" to be reasonable semantics --
> that's what ABSOLUTE is for) then perhaps we could make it work.
I could imagine it could be useful for a bootstrap code, something like:
ORG 0h
<actual bootstrap code>
ORG 510
BootSignature DB 55h,0AAh
Or if you want to create a GDT and a IDT, etc. at fixed locations.
BTW, I don't use NASM but TASM instead and I've been using multiple ORGs in
some cases.
> This is correct, and an annoying omission -- ran into it myself
> recently. I will probably try to provide something like the C ##
> operator in the next release -- if I ever end up doing any more NASM
> releases.
Do you plan to suspend it and if so, why? NASM has just become so good
(although I still prefer TASM because it does not use that C-ish syntax),
would be sad to see it die :-(
Best regards,
Thomas
Quad
> You *did* include a ..start: at org 0100h, didn't you?
>
Oh, also there's a problem about that ORG... When I write something like
SECTION .text
ORG 100h
mov ax, 4c00h
int 21h
END
and compile it to an obj file,
nasm -fobj test.asm
it gives me an error on line 2, where the ORG instruction lies, telling me
that
test.asm:2: parser: instruction expected
Hmm... NASM does not recognize this pseudo instruction while compiling to
object file (?) By the way I have version 0.97, if it matters in any way.
John S. Fine
> We can't concatenate text at assembly time.
I added limited support for that to NASM 0.98. I never
documented it well. I don't remember the usage details
myself. In my earlier reply to your later post, I claimed
it was shown in CHANGED.ASM; Now I can't find it even
there.
> %assign i 0
> %rep 100
> (Label & i): call function
> %assign i i+1
> %endrep
The simplest way to do that with the feature I added
would be
%macro cat_label 2
%1%2:
%endmacro
%assign i 0
%rep 100
cat_label Label,i
call function
%assign i i+1
%endrep
To the best of my recolection preprecessor concatenation works only
if the first token to be concatenated is a name or a number or anything
that has been replaced by a name or number before or during the
substitution of macro parameters, and the second must be a macro
parameter that is being replaced by a name or number.
When I actually use it, I almost always need to add an extra layer
of macro call to accomplish the concatenation. In the above example,
I think the extra layer is also required to cause "i" to be replaced
by its numeric expansion. Otherwise the concatenation would occur
before the substitution of "i".
> And the last but not the least, when we assemble to .obj files and want to
> compile with TLINK to produce a .COM file, it tells us that the program
> starts at a "bad entry point for .com file".
Start with
resb 0x100
..start:
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/
John S. Fine
> > The ORG pseudo instruction. We can only use it once in a source file;
> What would you expect it to *do* if you have more than one?
Most people expect ORG in NASM to do what ORG in TASM does.
I personally would like to have *both* of those features in
an assembler. If I had to pick just one, I might pick NASM's,
but then I never would have given the directive the same name
as a confusingly similar-but-different directive in existing
assemblers.
All that is too late to change now. Fixing the above design
error would do much more harm than good.
> If you can provide a set of reasonable semantics for it
Within the NASM meaning of ORG, there is a very reasonable
semantic that supports multiple ORG statements.
ORG in NASM creates a displacement between the offsets of
code and data in the generated image and their expected
offsets at load time. Currently, the last ORG controls the
displacent for everything in the file. Each ORG *ought* to
control only the things that follow it, up to the next ORG.
Even that change would break a lot of existing code; But
my best guess is that it is worthwhile to reduce the number
of times we must explain it current bizare behavior.
> (and I don't really
> consider "jump around memory at random" to be reasonable semantics --
> that's what ABSOLUTE is for)
"at random" is a very negative way of looking at TASM style
ORG, which has proven a very useful feature in TASM and would
be nice to have in NASM. ABSOLUTE does not address that need
at all.
> > We can't concatenate text at assembly time.
In NASM 0.98 I added a decent (not great) way to concatenate
at run time. I wish I had time to explain its use better. You
can extrapolate its use from the example in CHANGED.ASM
I think NASM needs even better ways to do these things, but
I haven't had time to figure out how to compatibly graft that
on top of all the complexity that existed in NASM preprocessor
before I started.
> This is correct, and an annoying omission -- ran into it myself
> recently. I will probably try to provide something like the C ##
> operator in the next release -- if I ever end up doing any more NASM
> releases.
If you work on that before I do, please send me an early
evaluation copy. There are some complex consequences to almost
any approach to the problem. If you release a "band-aid"
solution that makes it harder to ever fix it right.
> > And the last but not the least, when we assemble to .obj files and want to
> > compile with TLINK to produce a .COM file, it tells us that the program
> > starts at a "bad entry point for .com file".
>
> You *did* include a ..start: at org 0100h, didn't you?
Another big flaw in "ORG" is that it is not a NASM assembler
directive, it is a BIN format output directive. OBJ format
doesn't support it.
But even if OBJ format supported it, it wouldn't do so with
TASM semantics. To get the same result as a TASM "org 100h"
in NASM you need
John S. Fine
> In NASM 0.98 I added a decent (not great) way to concatenate
> at run time.
Now for my third try at this answer :(
I meant preprocessor time, not "run time". But even in NASM
0.97 concatenation occured at the boundary at the end of
preprocessor time. There are many cases in which that isn't
good enough but the enhanced version I put in 0.98 is better;
However, the example I posted in my second attempt to answer
this question is not an example of that. It is an example
of how concatenation can be used even in NASM 0.97
> %macro cat_label 2
> %1%2:
> %endmacro
> %assign i 0
> %rep 100
> cat_label Label,i
> call function
> %assign i i+1
> %endrep
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/
Quad
> What would you expect it to *do* if you have more than one? If you
> can provide a set of reasonable semantics for it (and I don't really
> consider "jump around memory at random" to be reasonable semantics --
>
I would expect that the memory reference does change at the point you issue
a new ORG. As in the code, for example,
ORG 100h ; Set base at 100h
jmp Begin
xyz dw 0
Begin:
mov ax, [xyz]
; would be translated into
; mov ax, [103h]
ORG 510h ; Set new base at 510h for further refs
mov ax, [xyz]
; would be
; mov ax, [50Dh]
Maybe you don't see the point there, but I can tell you that this would be a
lot handy when relocating a piece of code in memory so the refs will remain
good. Suppose that I want to move an interrupt handler from the kernel file
into extented memory so no V86 programs will be able to modify the code or
whatever. How could I do that? In the source file, to my knowledge, I would
write something like
ORG 0h
BITS 16
Start:
; bla bla bla for pmode init
cli
lgdt [GDTptr]
lidt [IDTptr]
mov eax, cr0
inc al
mov cr0, eax
o32 jmp CODE32:InPmode
InPmode:
BITS 32
; Place ourselves at 4mb
mov edi, 1024*1024*4
mov esi, [ourRmodeCSbase]
mov ecx, lengthOfKernel
rep movsb
; That would fix up the offset for following reference
; ORG 1024*1024*4
IntHandler:
; bla bla bla
; **** Here! the reference won't be 4mb further,
; but will remain the same as if it was
; compiled for real mode
mov eax, IntHandler
; some other code
iret
lengthOfKernel EQU $-Start
And adding an manual offset each time we reference a point in the program
would be too much, like "mov eax, IntHandler + 4mb". Now you see the point?
I just want to fix up my memory offsets after a relocation of the code. Any
way to do that? or another ORG would definitely be useful in such cases???
>
> This is correct, and an annoying omission -- ran into it myself
> recently. I will probably try to provide something like the C ##
> operator in the next release -- if I ever end up doing any more NASM
> releases.
>
Yes I would appreciate, and I'm sure many people would too :)
>
> You *did* include a ..start: at org 0100h, didn't you?
>
Are the dots really required? If so, this is my error I did not know this.
Otherwise, yes I did include a Start: label at the beginning but I guess
NASM looks at it as a any other normal label so TLINK don't know that it is
the entry point.
John Fine
>
> >
> > What would you expect it to *do* if you have more than one? If you
> > can provide a set of reasonable semantics for it (and I don't really
> > consider "jump around memory at random" to be reasonable semantics --
> > that's what ABSOLUTE is for) then perhaps we could make it work.
> >
>
> I would expect that the memory reference does change at the point you issue
> a new ORG. As in the code, for example,
>
> ORG 100h ; Set base at 100h
> jmp Begin
> xyz dw 0
> Begin:
> mov ax, [xyz]
> ; would be translated into
> ; mov ax, [103h]
Right.
> ORG 510h ; Set new base at 510h for further refs
> mov ax, [xyz]
> ; would be
> ; mov ax, [50Dh]
I hope you don't mean that. Otherwise, I think you
are proving HPA's point that the desired meaning is
not clear. What you are asking for would actually be
a much smaller change than what I think ORG should do
in NASM, and it would occasionally be a useful feature.
But I think it would confuse almost everyone who tried
to learn it. I also think my version would be useful
much more often.
> Maybe you don't see the point there, but I can tell you that this would be a
> lot handy when relocating a piece of code in memory so the refs will remain
> good.
That is exactly what I think it is for, and exactly
why the ORG should affect label defintion in its scope
rather than affect label use in its scope.
> ORG 0h
> BITS 16
> Start:
. . .
> ; That would fix up the offset for following reference
> ; ORG 1024*1024*4
> IntHandler:
> ; bla bla bla
> ; **** Here! the reference won't be 4mb further,
> ; but will remain the same as if it was
> ; compiled for real mode
> mov eax, IntHandler
> ; some other code
> iret
>
> lengthOfKernel EQU $-Start
>
> And adding an manual offset each time we reference a point in the program
> would be too much, like "mov eax, IntHandler + 4mb". Now you see the point?
> I just want to fix up my memory offsets after a relocation of the code. Any
> way to do that? or another ORG would definitely be useful in such cases???
I don't really follow the details of your example;
But going by the basic concepts, I think you really
didn't intend your initial example and you already
agree with what I think ORG should do. That still
leaves the little detail of someone making that
change to NASM.
> > You *did* include a ..start: at org 0100h, didn't you?
>
> Are the dots really required?
Yes.
I'm fairly sure the "resb 0x100" before it is also
required.
Johan Venter
news:7tvseq$71i$1...@autumn.news.rcn.net...
>
> I could imagine it could be useful for a bootstrap code, something like:
>
> ORG 0h
>
> <actual bootstrap code>
>
> ORG 510
> BootSignature DB 55h,0AAh
The way that this is done in NASM is with the times statement. For example, the
following lines:
times 510-($-$$) db 0
dw 0xAA55
tells NASM to put the boot signature at offset 510:
$ = current code position
$$ = start of section
$ - $$ = number of bytes so far used
510 - ($ - $$) = bytes to go till 510
db 0 = do this until it reaches 510
--
Johan Venter
ICQ 3643877 - jventer AT writeme DOT com
The TPU DJGPP Interest Group - http://surf.to/djgppig
The RSXNTDJ 1.5 HOWTO - http://surf.to/rsxntdj
Quad
> Within the NASM meaning of ORG, there is a very reasonable
> semantic that supports multiple ORG statements.
>
> ORG in NASM creates a displacement between the offsets of
> code and data in the generated image and their expected
> offsets at load time. Currently, the last ORG controls the
> displacent for everything in the file. Each ORG *ought* to
> control only the things that follow it, up to the next ORG.
Yes that is exactly what I wanted to mean, thanks for the clearer
explanation. This would definitely be a great feature for further NASM
versions.
> Even that change would break a lot of existing code; But
> my best guess is that it is worthwhile to reduce the number
> of times we must explain it current bizare behavior.
>
Maybe... but wouldn't be better to implement it late than never implement
it? For sure, some of you that are comfortable with the current meaning of
ORG would be a little confused at first but I'm quite sure this problem
won't be that disastrous. Anyway, in the way I see the change, issueing only
once the ORG directive would not affect any of the coders' normal habits.
And for those that will want to use it more than once, like me, would really
appreciate the change.
Quad
> The simplest way to do that with the feature I added
> would be
>
> %1%2:
> %endmacro
> %assign i 0
> %rep 100
> cat_label Label,i
> call function
> %assign i i+1
> %endrep
Thanks for this example, I will use it gladly :) It works just fine with
what I have to do so no problem about numbers and characters stuff. Thanks
again
>
> Start with
> resb 0x100
> ..start:
>
Works perfectly, of course. Yeah now I'll be able to write modules instead
of a long source file that would compile in one big .COM file.