Author Topic: NASM EA syntax  (Read 11759 times)

nobody

  • Guest
NASM EA syntax
« on: October 14, 2005, 11:21:13 PM »
In the NASM manual I find this excerpt:

NASM is capable of doing algebra on these effective addresses, so that things which don't necessarily look legal are perfectly all right:

mov     eax,[ebx*5]             ; assembles as [ebx*4+ebx]
mov     eax,[label1*2-label2]   ; ie [label1+(label1-label2)]

The [label1*2-label2] syntax is confusing me with the [laebel1+(label1-label2)] explanation.  How would that work in an example?

- Rick C. Hodgin

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: NASM EA syntax
« Reply #1 on: October 15, 2005, 07:42:56 AM »
Hi Rick,

I'm not sure what you're asking. You "just do it". If you mean, "What's it good for?"... damned if I know! Doesn't seem like a very useful calculation, either as "size of code" or as an actual effective address.

Something like "lea ebx, [ebx * 5]" can be useful, but I prefer to write it so it "looks" legal. AFAIK, being able to do this nonsense is just a "side effect" of being able to process the "sensible" ones.

Best,
Frank

nobody

  • Guest
Re: NASM EA syntax
« Reply #2 on: October 15, 2005, 01:11:21 PM »
Frank,

Thanks for your response.  I guess it comes down to this:  Algebraically, "label1*2-label2" would not be evaluated as "label1+(label1-label2)", as is shown in the documentation, but rather "(label1+label1)-label2".  And, there is no corresponding x86 syntax to allow a negative immediate, so the assembler would really be adding the complement, resulting in "(label1+label1 + ~label2)", to produce the final result.

In reading through NASM's documentation I was very impressed with most everything I read (a few typos here and there), but the NASM features are rich.  Much more so than I remember from several years back.  In fact, I was very impressed.

However, I strongly believe there should be a "hard" form of the ORG statement (HORG??) which works as in other languages to dictate the now-current offset to be used/assumed.  Use of TIMES for that purpose is definitely confusing and out of place.  And, from what I read regarding $ and $$, wouldn't any interveining labels potentially throw off those computations since the $ and $$ are relative?  Or does use of $ and $$ by themselves, without an attached "-label", automatically result in the entirety of the thing?

- Rick C. Hodgin

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: NASM EA syntax
« Reply #3 on: October 16, 2005, 02:49:25 PM »
foxmuldr wrote:

> Thanks for your response.  I guess it comes down to this:  Algebraically,
> "label1*2-label2" would not be evaluated as "label1+(label1-label2)", as is
> shown in the documentation, but rather "(label1+label1)-label2".

That's true, but it evaluates the same.

> And, there
> is no corresponding x86 syntax to allow a negative immediate, so the assembler
> would really be adding the complement, resulting in "(label1+label1 + ~label2)",
> to produce the final result.

I don't see where you're getting that. True, if label1 is "above" label2, you'll get a negative result, but it'll be a "neg", not a "not". "label2 * 2 - label1" might make more sense... but still not useful for anything I can think of.

> In reading through NASM's documentation I was very impressed with most everything
> I read (a few typos here and there),

Yeah. Deb Wiles went over the manual and cleaned up a lot of errors, but there are still some known ones, and no doubt some "unknown unknowns".

> but the NASM features are rich.  Much more
> so than I remember from several years back.  In fact, I was very impressed.

Despite the rumors that Nasm development is "dead", there are some new features, and *lots* of bugs have been fixed. I'm glad someone appreciates it!

> However, I strongly believe there should be a "hard" form of the ORG statement
> (HORG??) which works as in other languages to dictate the now-current offset
> to be used/assumed.  Use of TIMES for that purpose is definitely confusing and
> out of place.

I really don't know what everyone's got against "times". It's very unpopular! Seems to me it's the "obvious" thing to use, if you intend "HORG" to pad the file to the new offset. If you don't want a new file offset, but just a new "assumed memory image offset" (code/data that will be moved from where it's loaded before it's executed, for example), "times" won't do it...

The fairly new (and still in flux) multi-section support for "-f bin" has "start" and "vstart", which serve those two purposes. If you can make separate sections where you'd put "HORG", perhaps you could use them.

> And, from what I read regarding $ and $$, wouldn't any interveining
> labels potentially throw off those computations since the $ and $$ are relative?
> Or does use of $ and $$ by themselves, without an attached "-label", automatically
> result in the entirety of the thing?

Well, '$' is "here", and "$$" is "beginning of section". Intervening labels won't interfere with it, but the calculation can only span the one section.

Is there something in particular you're trying to do? There are some things Nasm won't do - such as "backing up" (something Forth programmers would like, apparently). In most cases, something can be worked out... Maybe a "HORG" macro to hide away "times", if you don't like it :)

Best,
Frank