[Libre-soc-bugs] [Bug 238] POWER Compressed Formal Standard writeup

[bugzilla-daemon at libre-soc.org]

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

--- Comment #167 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #164)
l
> me, I see no way to avoid also looking at Cmaj.m bits to tell whether M and
> N have the usual meaning, or whether we're looking at a '16b sub' insn,
> where the bit that usually holds N serves a different purpose.
> 
> I build my case on the following opcodes:
> 
> | 0111 | BA2 | | 001.1 | 0 BA | BB  | M | crnand
> | 1000 | BA2 | | 001.1 | 0 BA | BB  | M | crand

these are marked as 16bit only.  i.e. it is not possible to reach these without
first going through one 10bit insn and into 16bit mode.



> now, consider a 16-bit crand insn is to be followed by several uncompressed
> insns, so it has M=0

... here yes you are right, we need to nake a choice, should the return be to
v3.0B or to v3.0B-then-back-to-16



> is that really not so, i.e., are cr opcodes really to have their bit 0
> interpreted as N even though it's also part of the subopcode?

no not at all, that's why they don't have "N" in them.

i was looking for a way to jam cr ops into Compressed because they will be used
for common predication operations in SV.

we do not have enough info to say if the mode should be implicitly 3.0b or
3.0bthen16 when M=0

i will make a TODO note.

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