680x0 opcode encoding - odd branches?

[NorthWay]

Is this summary correct and complete http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf ?

In the debate around the Vampire and suggestions for extending the instruction set I have been wondering about the branch instructions: Do all 680x0 variants trap when branching/jumping to an odd address?
Does branching to an odd address serve any other purpose than generating a trap?

Would it be an idea to have a supervisor-mode controlled setting that re-purposes odd branches for added opcodes? There are 127 of them for each 2-byte branch opcode from the top of my head (15*128 ?).

[meynaf]

Originally Posted by NorthWay

Is this summary correct and complete http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf ?

I wouldn't say it's complete as it's 68000 only.

Originally Posted by NorthWay

In the debate around the Vampire and suggestions for extending the instruction set I have been wondering about the branch instructions: Do all 680x0 variants trap when branching/jumping to an odd address?

Yes they all trap. But conditional branches trap only when the branch condition is true.

Originally Posted by NorthWay

Does branching to an odd address serve any other purpose than generating a trap?

No, unless you want to go to byte encoding.
This, however, was the initial plan from Moto : allow branching to odd address if some day some successor of the family does this - but this obviously never happened.

Originally Posted by NorthWay

Would it be an idea to have a supervisor-mode controlled setting that re-purposes odd branches for added opcodes? There are 127 of them for each 2-byte branch opcode from the top of my head (15*128 ?).

IIRC there has been a discussion long ago on the natami forum about this.
While in theory possible, value $FF (= 32-bit 020+ branch) comes in the way.

[grond]

Originally Posted by meynaf

Yes they all trap.

I believe you are right but I wonder about the 68008. Does it really behave exactly like a 68000 with cycle penalties for the halved memory bus? I think it is likely but I don't know.

[NorthWay]

Originally Posted by meynaf

While in theory possible, value $FF (= 32-bit 020+ branch) comes in the way.

Ok, but there is an ocean of pre-fixes or direct use 16-bit opcodes to pick from then that could be enabled by something like SetPatch / 680x0.library / per-task Exec call.

What was the verdict on the NatAmi forum on its feasibility?

[meynaf]

Originally Posted by grond

I believe you are right but I wonder about the 68008. Does it really behave exactly like a 68000 with cycle penalties for the halved memory bus? I think it is likely but I don't know.

Even 68020, which can access misaligned data, will trap for branching to odd address - so it looks logic and consistent that 68008 also does.

Originally Posted by NorthWay

Ok, but there is an ocean of pre-fixes or direct use 16-bit opcodes to pick from then that could be enabled by something like SetPatch / 680x0.library / per-task Exec call.

If it needs to be enabled then we'll end up with cpu "modes" that will be a mess when disassembling code. I don't like this.
If we accept having several incompatible encodings, it's be IMO better to build a completely new one.

Originally Posted by NorthWay

What was the verdict on the NatAmi forum on its feasibility?

Not usable (for the purpose of extending the range of short branches, which was the idea then).