using the '*'-symbol in assembler - what do you expect?

[phx]

Hi,

as there are some 68k assembler coders on this board I would like to ask what output you expect to be generated, when assembling the following source:

        dc.l    *+4
x:      dc.l    *,*

There seem to be two variants:
1. All three pointers will refer to x. Generated by: A68k, Devpac.
2. First two refer to x, but the last pointer refers to x+4. Generated by: Barfly, PhxAss, SNMA.

I would like to make it right in vasm, but I'm unsure which solution *is* the right one?

[Leffmann]

Hi again Frank

I've never used the *,* construct but having * refer to the beginning of the line seems more intuitive to me and that's what I would expect initially, but now that I see your example the latter case with the exact address seems more correct. I'm split about this.

I checked with ASM-One and it also generates the exact address.

[Photon]

* is the address of the memory location where it is invoked.

In your example, the first line stores the address X in a longword, since it is invoked at a longword before x and adds 4 to it.

The second line stores the address X in a longword followed by address X+4 in a longword. (Since a longword is 4 bytes.)


Another example, both

bra.s *

and

loop: bra.s loop

results in an endless loop - but no label is necessary for the first one. Use it in macros or wherever you want to avoid double symbol errors.

[Photon]

If your assembler generates something else, it hasn't implemented the * directive correctly - even though assemblers for fixed-instruction-size CPUs might correctly make it point to "the next instruction" or similar.

Normally it's used only to counter this double symbol error in code, but it should be safe to use for any address calculation that each assembler supports. [Edit: in your example, making the dc.l *,* into two dc.l * lines should give the same behavior on all* assemblers]

It comes from late 1970s "assemblers on the computer that runs the program", where only the first three letters of each label were stored to save precious RAM, and double symbol errors therefore were common.

[StingRay]

Originally Posted by phx

        dc.l    *+4
x:      dc.l    *,*

dc.l *,* should refer to x and x+4 since * is current address. I never needed to use that though. But it is the "right" solution for me, i.e. it makes sense and it's what I would expect.

[phx]

Originally Posted by Photon

If your assembler generates something else, it hasn't implemented the * directive correctly

At the moment vasm behaves like PhxAss and AsmOne, and will generate "dc.l x,x+4" for "x: dc.l *,*". I always thought it is more logical, because splitting a "dc.l *,*" into two seprate dc.ls should generate the same code.

But I got very confused when I saw the output of Devpac, as I trust Devpac as the reference assembler for everything.

Hmm...ok, even the GNU-assembler seems to prefer the PhxAss-method, so I think I will keep it like that.

[StingRay]

Originally Posted by phx

I always thought it is more logical, because splitting a "dc.l *,*" into two seprate dc.ls should generate the same code.

Exactly what I think too! Also, keep in mind that Devpac has bugs too, i.e. it's not 100% either (then again, no Assembler is I guess).
However, if you can't decide how to handle it, how about having some kind of flag/directive so the user can decide which code should be generated?

[phx]

Originally Posted by StingRay

However, if you can't decide how to handle it, how about having some kind of flag/directive so the user can decide which code should be generated?

I'm thinking about it. There is already a -devpac flag for best Devpac-compatibility.

[mosfet]

Devpac is at least being consistent with its own definition of '*', which is "the value of the program counter at the start of the instruction or directive", with both longs on the second line belonging to the same dc directive. It's probably the easier way to implement too.

But the second way is more logical. Putting multiple values on one line is a formatting decision and should be equivalent to separate directives. Formatting shouldn't hide nasty surprises like that.

[Photon]

Agree.

ps. Being consistent with one's own definitions is not very hard, hehe The opposite is in fact a good definition of the word "bug".

[dalton]

the dc.l *,* situation seems very hypothetical.. If I wrote something like that I'd definitely disassemble to confirm the result.

Generally, I would expect * to be the address of the current row in the code.

[Photon]

Huh. Well, I'm glad most assemblers got it right tho.