#33 Multiple ORGs...
Now wait, don't immediatly dismiss me as another idiot.
I know exactly how NASM's org works, and that's how I
like it. However, I still don't see why I can't use more
than one. Take the following code:
org 0x100
label1 nop
org 0x200
label2 nop
mov eax, label1
mov ebx, label2
All I'm suggesting is that the above code create a file
that contains two consecuative nop instructions, one
right after the other, followed by a mov eax, 0x100
followed by a mov ebx, 0x200. No modification of write
positions in files or any nonsense like that.
Although I currently have no use for this functionality, I
did need it some years ago when I was writing a boot
program. At the beginning was some code that was org
0x7c00 (or whatever that special address is), and it was
followed by some code that was org something else,
which was moved into place by the 0x7c00 code.
Something like this:
org 0x7c00
cld
mov si, label1
mov di, 0x8000
mov cx, 250
rep movsb
jmp 0x8000
label1
org 0x8000
[more code]
Logged In: YES
user_id=804543
Mmh.
Have a current location pointer. (Commonly known as $).
And a _separate_ current write position pointer. (Say @.)
Interesting. Let me think about it for a while...
Logged In: YES
user_id=804543
Mmh.
Have a current location pointer. (Commonly known as $).
And a _separate_ current write position pointer. (Say @.)
Interesting. Let me think about it for a while...
Logged In: YES
user_id=804543
My local forked version of NASM does support ORG
in a MASM-compatible way. That is, ORG can move
both forwards and backwards; prior code and data
gets over-written; non-sparse output formats do
use zero to pad the holes, whereas sparse output
formats do only contain the user's code or data.
So far, so good.
Now, on top of that I've just added experimental
support for two separate location pointers -- one
in the assembler, and another one in the output
module. As part of that work, I extended ORG. If
used with one operand, then both pointers will be
updated. If used with two operands separated by a
colon, then the 1st operand selects the desired
offset for the assembler's pointer, while the 2nd
operand selects the desired offset for the output
module's pointer. (For example, ORG 123h:678h.)
I could easily add support for @ as a means for
querying the current location pointer maintained
by the output module. However, doing this would
slow down stdscan() and ppscan() by a comparison
and a branch -- which doesn't sound much... but
do keep in mind that those two are called a lot.
Logged In: YES
user_id=804543
I've got working code in my local forked version.
description for $ and @ special tokens
description for ORG pseudo instruction
Logged In: YES
user_id=804543
I have attached a description of how things
work in my local forked version.
Logged In: NO
For compatability with existing code, I think that the single operand version
sould not modify @, otherwise source code for DOS .com files which always
starts with "org 0x100" is going to start getting an unnecessary 256 zero bytes
attached to the beginning.
Perhaps you could make a second version, call it 'morg' or something, short
for "masm org", for which a single operand causes both $ and @ to be
modified.