Hello (bra.w *+4)

Where did you find it? What game?

 

Branch to current program counter plus 4?

 

Wouldn't it be pc+4 though, then? Correct me if I'm wrong, here.

 

It basically just skips the next (word-wide) instruction. Dunno why one would do that with an unconditional branch, though.

That would work too, but pretty much every assembler takes * to mean "program counter".

 

Yeah, there's some really weird code in Sonic 2.

move.b 0(a0),d0

 

This sounds like a problem with the disassembly, though. How could the Sonic 2 ROM tell the disassembler that this branch instruction isn't allowed to use the normal syntax for going to a label?

 

The whole thing jumps to 2 bytes after the instruction (6 bytes after the start of it).

So, like:

60 00 00 04 XX XX ______

It jumps to _____ (4 bytes after the opcode, being 6000).

I'm not sure whether *+4 makes the operand 0004 or 0002, but that's how it works anyway.

In either way, this is caused by programming with macros. Programmers tend to use macros a lot, and they can't be arsed to check if there isn't a useless branch somewhere. Same with that move.b 0(a0) thing. What happened was that it was SOME_MACRO(a0) and SOME_MACRO got set to 0. That, or it's a disassembler bug.

 

No, Yuji is just a fag. :P

 

Yeah, it's a macro thing that didn't get optimized out. The actual object code for move.b 0(a0),d0 as it appears in the binary is $1028 $0000 (the extension word holds the index, in this case 0). One wonders why they turned off that particular optimization, since indexed addressing is quite a bit slower than plain indirect addressing.

The real problem is, AS DOES optimize zero-index addressing. To assemble the ROM into a (nearly) perfect replica of the retail version, I would have to turn off AS's optimization procedures, and Alfred Arnold tells me that this isn't possible, at least not at the moment.

 

Which is precicely what I need to do. So hah.