Page 1 of 1

GAS: force move instead movea?

Posted: Sat May 05, 2018 7:40 am
by Miquel
Do you know any way to force the compiler to produce a "move" instead a "movea"? when the destination is an address register.

The point is I want the Z flag to be set.


And when we are at it: what's the motive of having move, movea and lea?

Re: GAS: force move instead movea?

Posted: Sat May 05, 2018 8:32 am
by flamewing
If you also look at pages 219 and 222 of M68000PRM, you can also see that move and movea use the same encoding; the only difference between them is that move does not accept destination address registers (page 220) but movea only accepts it.

Assemblers typically allow you to write move instead of movea, but this is syntactic sugar.

Finally, the difference between movea and lea: when the source (left-hand side operand) is one of the indirect memory addressing modes, movea reads form the resulting address and writes the value read into the address register. In contrast, lea writes the address itself on the address register.

The only way to set flags in this case is to write to a data register or do a explicit test.

Re: GAS: force move instead movea?

Posted: Sat May 05, 2018 8:45 am
by Miquel
flamewing wrote:
Sat May 05, 2018 8:32 am
Finally, the difference between movea and lea: when the source (left-hand side operand) is one of the indirect memory addressing modes, movea reads form the resulting address and writes the value read into the address register. In contrast, lea writes the address itself on the address register.
To be sure we are talking the same: what's the difference between... ?
move.l #0x12345678, %a0
and:
lea 0x12345678, %a0

In both cases 0x12345678 is a constant, not an address.

Re: GAS: force move instead movea?

Posted: Sat May 05, 2018 9:17 am
by flamewing
These two are identical, true; but note they use different addressing modes. Consider these differences:

move.l 0x12345678, %a0
Reads longword at address 0x12345678, and stores value read on a0

lea 0x12345678, %a0
move.l #0x12345678, %a0
Stores 0x12345678 into a0.

move.l 18(%a0, %d0.l), %a0
Computes a0+d0+18, reads longword at this location, and stores value read on a0

lea 18(%a0, %d0.l), %a0
Computes a0+d0+18, and stores this value on a0

There is a redundant combination, the one you pointed out; but it is the only case.

Re: GAS: force move instead movea?

Posted: Sun May 06, 2018 3:57 am
by Miquel
Ok, so:
- movea doesn't really exists, it's just that "move ?, %a?" doesn't set the Z flag (or any other).
- with lea you get low cost additions, but the syntax is quite confusing compared with all other instructions

Thanks flamewing!

Re: GAS: force move instead movea?

Posted: Sun May 06, 2018 5:24 am
by HardWareMan
Image

Re: GAS: force move instead movea?

Posted: Sun May 06, 2018 9:54 am
by Miquel
HardWareMan, your point is?

Re: GAS: force move instead movea?

Posted: Sun May 06, 2018 10:56 am
by Sik
That MOVEA is literally the encoding of MOVE when a0-a7 is the destination operand (just looked up, 001 is indeed what should be the addressing mode for those). Helps confirm it for those without the manual at hand, I guess :​v

Re: GAS: force move instead movea?

Posted: Sun May 06, 2018 3:16 pm
by HardWareMan
Yes. And usually all questions are resolved when you not just read the PM for CPU very carefully, but make some additional work with this info. For example, datasheet for AVR Mega claims that it have 135 instructions (opcodes), but analysis of AVR core gives only about 66 true different opcodes. Rest of them is just aliases for already claimed ones.

Almost 10 years ago I'd made this opcode table for M68000 (and only 68000, without any extended members of family) and have no any doubt now. And you should do this also, if you gonna use assembler instead of high level language (C for example).

Re: GAS: force move instead movea?

Posted: Mon May 07, 2018 2:19 am
by Miquel
Nice! we all agree.

Since flamewing already said that I was undecided on how to decode your picture between this two:
- I'm HardWareMan of many colors.
or
- I'm trying to tell you that Sik has posted a message encoded in several pictures with an even more complicated enigma.
(joke)