org ignored

[johnshir]

I am trying to create a simple .com file, but can't get the org to work.

Here is an extremely simple test program taken from the documentation that I have tried in versions 2.9.10 and 2.10.0

Code: [Select]

org 0x100
dd lbl
lbl:

I assembled the above code with:
nasm -f bin test.asm -o test.com -l test.txt
and got the results listed below

Code: [Select]

     1                                  org 0x100
     2 00000000 [04000000]              dd lbl
     3                                  lbl:

org is such a simple concept, but I must be missing something.

Thanks,
John

[Frank Kotler]

Hi John,

The subtlety you may be missing is "linker".. You wouldn't expect a linkable object file to know where the linker's going to put things. In the case of "-f bin", Nasm serves as its own (rudimentary) linker. But this doesn't happen until the output driver. At the time the "list" file is generated, Nasm hasn't yet added in the "org".

Between you and me, I consider a "list" file almost completely useless. Some people swear by 'em, but it seems to me that it's mostly telling me something I already knew. Okay to show how the macros expand, if you didn't know, I guess.

I like to disassemble the mess to see what really happened.
"ndisasm -o 0x100 test.com > test.dis"

Code: [Select]

00000100  0401              add al,0x1
00000102  0000              add [bx+si],al
As you can see, ndisasm attempts to disassemble everything, whether it's an instruction or not, but if you look in the second column you can see what the bytes are.

Another option you might like - in the source code, not on the command line - is "[map]"...

Code: [Select]

[map all test.map]
org 0x100
dd lbl
lbl:


Code: [Select]


- NASM Map file ---------------------------------------------------------------

Source file:  test.asm
Output file:  test.com

-- Program origin -------------------------------------------------------------

00000100

-- Sections (summary) ---------------------------------------------------------

Vstart            Start             Stop              Length    Class     Name
             100               100               104  00000004  progbits  .text

-- Sections (detailed) --------------------------------------------------------

---- Section .text ------------------------------------------------------------

class:     progbits
length:                   4
start:                  100
align:     not defined
follows:   not defined
vstart:                 100
valign:    not defined
vfollows:  not defined

-- Symbols --------------------------------------------------------------------

---- Section .text ------------------------------------------------------------

Real              Virtual           Name
             104               104  lbl

Something more like a "map" file you'd get from a linker.

Nasm isn't really ignoring your "org", it just doesn't show in the "list" file...

Best,
Frank

[johnshir]

Frank,

Thanks for your reply.  I had assumed the output list reflected the code generated in the .com file and had not checked that.  Indeed, the correct value of 104 is in the .com file.  I'm afraid it still seems wrong to me, though, that the list file does not reflect the org value in the generated code, especially since a .com file is never linked (at least as I use them).  However, this sounds like a design feature of nasm rather than a bug, at least as you described it.  I'll have to think some more on that.

[Frank Kotler]

I think I'd call it a "design consequence" rather than a deliberate "feature". Nasm has a consistent interface with each of its output drivers. I agree that it would be useful to have this information available to the "list" file in the case of "-f bin", but I think it would take a lot of "special case" code. As a practical matter, I don't think it's going to change.

Best,
Frank