回信： [openrisc] Re: 回信： [openrisc] insn decoder and COFF loader

[jimmy87@sunplus.com.tw]

1.)
1. fetch: h.2byteinsn  +  h.branch
2. fetch: h.2byteinsn + h.nop

In this case we have a nop that will never be executed and is just taking
code space.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not really!!! Of course, our link register should point to the location
of h.nop, so we don't need to worry about wasting code space.

2.)
1. fetch: h.branch + h.2byteinsn
2. fetch: one or two insn following branch

Do we fetch insns in fetch 2 or not? Delay slot insn is already fetched
together with branch.
^^^^^^^^^^^^^^^^^^^^^^^^^ In fact, neither code space nor performance
is wasted here. The link register still point to 2

3.)
1. fetch: h.branch + first part of h.4byteinsn
2. fetch: second part of previous 4 byte insn + (h.2byteinsn or first part
of h.4byteinsn)

Isn't this getting complicated. This is becoming CISC machine with so
complicated fetching.
^^^^^^^^^ That's what I mean at designing OR1601. Insn fetching is quite
tricky with h.bf(2byte) and h.jal(4byte). I need time to fix it.
Otherwise, I need two tag memories at this version.
---------------------------------
Also in the beginning when there was only one instruction set the meaning of
prefix was to distinguish between 2 and 4 byte insn. Noe when we have OR32
all insns in OR32 are 4 byte (so prefix is more or less meaningless) and in
OR16 all insns have h. prefix but a lot of insns are 4 byte. Should we fix
this or leave l. and h. prefixes to distinguis between OR16 and OR32? In
fact I don't see why we would need to distinguish between OR16 and OR32 code
since it will never be mixed together.
^^^^^^^^^ YES, we could let the 4byte insn named with prefix l.xxx if it
helps us clarify this.

> As to my point of view,
> I prefer only one insn in delay slot and the insn is only 2-byte wide in

I like this also. But what happens in case 1 (see above). You have a nop
after your 2byteinsn in the delay slot. Is this ok?
^^ Refer to what I siad in case 1.

Jimmy, you said you wouldn't have branch delay slots. Is this still valid
offer? ;-)
^^^^^^^^^^ NO!!! no delay slot has been fired long ago :)
Best regards, Jimmy