[Libre-soc-isa] [Bug 529] scheme for supporting 16/48-bit instructions on PowerPC LE with full backward compatibility

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=529

--- Comment #5 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #4)
> (In reply to Luke Kenneth Casson Leighton from comment #3)
> > https://libre-soc.org/openpower/sv/major_opcode_allocation/

The explanation on the wiki page seems quite a bit less general (limiting
alignment) than what I was envisioning:

I was thinking of conceptually the instruction stream would just be a stream of
aligned 16-bit chunks which are decoded into *totally-unaligned*
16/32/48/64-bit instructions by combining 1/2/3/4 chunks in the conceptual
sequence. All different instruction sizes can be arbitrarily interleaved.

The only twists are:
- that the 16-bit chunks are laid out oddly in LE mode for backward
compatibility.
- that jumps/branches/returns/calls can only branch to 32-bit aligned
addresses, so the branch targets need to be aligned by either using a larger
equivalent instruction (preferred) or inserting NOPs. interrupt/exception
returns *can* branch to 16-bit aligned addresses, however, since that's needed
for preemptive context switching.

> > it's complicated but quite elegant, i like it.  i am trying to think through
> > how mixed 16/32/48 would actually work.  it woukd be necessary i think to
> > pop 16 bit instructions out of bytes 2+3 and leave 0+1 still at the front of
> > the queue.
> 
> does this work? are there any cases where conceptually swapping bytes 0+1
> with 2+3 at the memory level would not work? mixing 16/32/48 together?

it would require some additional thought, but I think it probably would.

We would need to decide what to do for PC-relative instructions, do we include
the second-from-lsb in the visible PC or not?

-- 
You are receiving this mail because:
You are on the CC list for the bug.