[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> I think the insn in (h.bf, h.bnf) branch delay slot could be 2-byte or
4-byte
> wide.
> But if we want to design for simplicity or it's unnecessary
> to have the two choices(either performance or compiler),
> I think we can let it be 2-byte or 4-byte.
> But we still have to make sure that only one insn could exist in the delay
slot.
> As to unconditional jump, we can make it fixed if you want.
> What do you think?

Well OR32 has delay slot that can hold one insn (all insns are 4 bytes
long). But in case of OR16 insns can be 2 or 4 bytes long. And here can be a
problem. I also assume 4byte insn don't need to be aligned on a singleword
boundary (not naturally aligned).

So if you assume delay slot of one insn regardless of insn's size then you
can have the following scenarios:

h.2byteinsn is 2 byte insn but not branch/jump; h.4byteinsn is 4 byte insn
but not branch/jump; h.branch is 2 byte branch

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.

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.

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.

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.

> 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?
Jimmy, you said you wouldn't have branch delay slots. Is this still valid
offer? ;-)

regards,
Damjan