"WTF?" issue - help

[thomas3]

Yo!

So I'm working on a sprite rout. All working fine - lovely.

I made some additions/revisions - suddenly my "dirty" background redraw goes wrong, even though I made no changes to it. Looks like the redraw is somehow screwing up by a few bytes, so is misaligned.

So I went back to an older version of the source without my changes. Assembled it - even though the changes are rolled back, the above bug is still there!!

So I compared the binaries between my working version, and the non-working version (remember, these should be identical).

There are only two words that are different. These both relate to a point in the code where I flip between two buffers that store the relevant bit of background prior to sprite draw.

In the working binary, these dissemble as:
lea $c(a1),a2
lea $10(a1),a3

... where a1 is a pointer to structure containing, amongst other things, pointers to the two buffers as above. (I then swap these round in following instructions). This is consistent with my source.

But in the non-working binary (with identical source), these disassemble as:
movea.l $c(a1),a2
movea.l $10(a1),a3

Now, my understanding is that the operation of these should essentially be the same (bar affecting flags). But this is the ONLY difference between the buggy binary and the working binary.

1) WTF? Does this make any fornicating sense to anyone?!
2) If this is the problem, how can I make Devpac go back to assembling these as lea again?!
3) If this isn't the problem, what the hell am I missing here??!

THANKS!

[Zippy]

It's been a long time since I did this stuff but I'm pretty sure that "lea $c(a1),a2" is not the same as "movea.l $c(a1),a2"

The first one will result in a2 = (a1+$c)
The second one will result in a2 = the longword stored at address (a1+$c)

No idea why GenST would be assembling an LEA instruction as a MOVEA though.

You could try it as:

move.l a1,a2
add.l #$c,a2
move.l a1,a3
add.l #$10,a3

or slightly more optimised:

move.l a1,a2
add.l #$c, a2
move.l a2,a3
addql.l #4,a3

[thomas3]

THANKS! I'll try this.

Further to the above - I went back to my updated source (the one with additions - where this problem first emerged), found and changed those two words back to LEA, and... it now works fine.

WT actual F?!

[Zippy]

Yes, the only problem is that the assembler is changing the LEA to a MOVEA for some reason, thus making the code do something entirely different and unintended.

[lp]

You can disable individual optimizations, but looking thought the manual I don't see where it lists that specific optimization. You can always add to the source: OPT O- ;all optimizations off for test purposes

[thomas3]

One of the most perplexing aspects of this is the instruction right before the movea above is a lea... Which DOES assemble as lea. And all of these were assembling as lea two days ago.

This is clearly my fault - I must have done something somewhere to cause this. I'd love to know what (and why the movea instructions cause that bug - still not sure, having read more on it).

Unless it's actual witchcraft? Perhaps I've been cursed, in a very specific and trivial way?

[lp]

Devpac certainly has its quirks. I had it complain about the IIF directive being on the same line as a label in an include that never changes. However it compiled fine for months, then suddenly it's a problem. It's done this to me twice. Very bizarre.

[Zippy]

I'd love to know what (and why the movea instructions cause that bug - still not sure, having read more on it).

It's not a bug, the movea and lea instructions are meant to do different things, the only strange thing is that the assembler is changing the lea to a movea.

Unlike other instructions, lea is effectively like an immediate addressing mode, so "lea $c(a1),a2" is really like "move.l #(a1+$c),a2" which is very different from "move.l $c(a1),a2"

[thomas3]

I'd love to know what (and why the movea instructions cause that bug - still not sure, having read more on it).

It's not a bug, the movea and lea instructions are meant to do different things, the only strange thing is that the assembler is changing the lea to a movea.

Unlike other instructions, lea is effectively like an immediate addressing mode, so "lea $c(a1),a2" is really like "move.l #(a1+$c),a2" which is very different from "move.l $c(a1),a2"

Aaaah, sorry for being slow. I finally get that movea is essentially the same as move, except exclusively takes an address reg as destination (right? ).

Thanks for the help... Relatively new to this, if you couldn't tell!!

[Zippy]

Yes, the "a" just means that the destination is an address, when I was doing a register move I'd just type it as "move" in the source code and let the assembler sort it out, only when you disassembled it would it appear as a move or movea as appropriate.

I think "lea" is unique in being basically like an immediate addressing mode without actually using the usual "#" identifier, so it can be confusing.

The description of the "lea" instruction in ST Internals sums it up:

"This often misunderstood instruction loads an address register not with the contents of the specified operand address as is normal for the other instructions, but WITH THE ADDRESS AS SUCH!".

[thomas3]

HAHAHA!

Guys, this is embarrassing.

I came back to this this morning, with a brain not "enhanced" with a few bottles of beer

And I saw that Devpac is doing nothing wrong at all. I was getting mixed up between old source files. The mistake was mine - I was just hallucinating that I'd used LEAs in the source! move.l is clearly there, plain as day

I must have fixed this for a working a build, forgotten to save the source, and then got mixed up last night when reviewing them.

The only "wtf" here in relation to my own idiocy but thanks for the help anyways!