SpritesMind.Net

After I discovered that the assembly rewrite of my 32X gameboy emulator isn't working in Fusion or on a real 32X I decided to try to find out why (I've done all the testing of it so far in gens KMod, since it's the only 32X emulator I know of with any meaningful debugging features).

I still haven't completely fixed my code, but at least I've found a few things that made me wonder how it ever could've worked in gens KMod:

At one place I had a jump-table with 16 LONG addresses, where I would branch to one of those addresses based on bits 12-15 of R0..
I could probably cut that down by one instruction by using a register-indexed mov.l, but anyway.. I'm shifting right by 10 since I want bits 12-15 of the register but I want them multiplied by 4. I had completely forgot to AND out the lowest two bits after the shifts though, which would cause me to get misaligned addresses for the mov.l in some cases. gens KMod seemed to be completely fine with that. Fusion - not so fine

I also realized that I have a lot of mov.l some_label,rn in places where I have no idea if the instruction is aligned on a 4-byte boundary. Again, gens KMod didn't seem to care, but Fusion does.


BTW, not related to gens, but does GNU AS/LD have some flag that gives warnings/errors when you're trying to do a PC-relative mov.l from an place where PC isn't 4-byte aligned? I know it complains when you place data on misaligned addresses, but those are much easier to find yourself.

mic_ wrote:I also realized that I have a lot of mov.l some_label,rn in places where I have no idea if the instruction is aligned on a 4-byte boundary. Again, gens KMod didn't seem to care, but Fusion does.

It's not the instruction that needs to be aligned, but the data at the label "some_lable" that needs to be aligned.

BTW, not related to gens, but does GNU AS/LD have some flag that gives warnings/errors when you're trying to do a PC-relative mov.l from an place where PC isn't 4-byte aligned? I know it complains when you place data on misaligned addresses, but those are much easier to find yourself.

You mean where you try to reference DATA that's not aligned... and no, I haven't seen anything like that. Just don't forget those align directives before the tables and variables.

Internally, the SH2 ANDs off the two lower bits when generating long addresses with indexing (PC relative only). LD/AS won't generate errors for unaligned targets because many people take advantage of this internal ANDing to NOT AND off the two lower bits to save time. As long as the target is aligned, you needn't worry about the bits in the reference.

Internally, the SH2 ANDs off the two lower bits when generating long addresses with indexing (PC relative only).

Ok, that makes sense. The other alignment issue (where PC-relative addressing wasn't used) is still valid though, but I've already fixed that (my code that is, not gens).

Still doesn't explain why Fusion barfs at my code while gens seems to think it's cool. If only Fusion had a disassembler..

mic_ wrote:I could probably cut that down by one instruction by using a register-indexed mov.l, but anyway.. I'm shifting right by 10 since I want bits 12-15 of the register but I want them multiplied by 4. I had completely forgot to AND out the lowest two bits after the shifts though, which would cause me to get misaligned addresses for the mov.l in some cases. gens KMod seemed to be completely fine with that. Fusion - not so fine

For this instruction: The address in r2 needs to be longword aligned otherwise an address error exception occurs. Gens automatically clears the lowest two bits so no misalignment, no exception. The same should apply for the register-indexed instruction.