Re: [Nasm-devel] ORG /w/ Addressing & Optimization

[Brian R. <bre...@mu...>]

>> NASM's treatment of ORG differs from that of other x86 assemblers.
>> Instead of changing the location counter (aka $) it merely tells
>> the assembler where the code will be loaded at run-time. (This is
>> documented in the user manual, btw.)
>>
>> Personally I prefer the other behavior... so my local forked NASM
>> version implements that instead.
> 
> Why is this?  I am just wondering why NASM chooses to do so many things
> different?  I know a lot of things make sense, i.e. don't ASSUME anything
> =], etc. but, ORG seems to be something I would think would be more of a
> standard of assemblers.

What makes this funny is that, in this case, it's NASM that's adhering
to the "standard of assembler" (although "common practice" would
probably be a better term), and the other x86 assemblers that have
overloaded a pre-existing concept.

ORG is short for origin, and it used to be that assembler used it to
indicate the file's origin in memory -- i.e. its lowest address. One
file couldn't have multiple origins.

Of course, this common practice came about when executable file
formats were much simpler beasts than they are now. New directives and
extensions are necessary to accommodate modern executables. Instead of
introducing a new directive to "change" the current position in
memory, x86 assemblers chose to reuse ORG. (MASM happens to be the
first assembler I ever used that allowed ORG to appear anywhere other
than at the top of the source file. I expect that it wasn't the first,
although I've no doubt that other x86 assemblers mainly follow its
lead.)

I imagine that because Nasm supports a wide variety of output file
formats, including the completely unadorned "bin" format, the original
authors chose to use the older, primitive version of ORG, so that it
would have the same meaning in all the output formats that support it.

b