[Libre-soc-isa] [Bug 924] potential major opcode allocation for SVP64

[bugzilla-daemon at libre-soc.org]

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

--- Comment #1 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #0)
> there are discussions and reasons that cannot be disclosed,
> there is an ISA WG meeting coming up tuesday 12th,
> a need has come up to find ways to allocate SVP64 and the
> 80+ scalar opcodes without using 75% of 3 major 32 bit opcodes.
> 
> * 75% (50%?) needed for SVP64, SVP64-Single (and SVP64-Reserved?)

Why are there 3 separate prefixes? I can understand reserving space for future
extensions [1] but I've never heard of SVP64-Single before (it's not on the
wiki), assuming it is for scalar ops, i'm inclined to say that it's unnecessary
since we can already use svp64 with all EXTRA2/3 fields set to scalar. 

[1]: future extensions other than increasing reg file size -- note that the
current svp64 prefix is 100% sufficient for future register file expansions, my
proposed plan is that new bits on sv.setvl would set some state in SPRs that
would change how the existing svp64 prefix's register fields are interpreted,
allowing accessing more registers. this retains backward compatibility because
programs have to opt-in to using the new reg field interpretations. this
doesn't need any new encoding space for additional prefixes.)

> * 75% for grevluti, crternlogi, ternlogi
> * 75% for xpermi, bmrevi, grevlut etc

imho ternlogi doesn't need Rc, it just takes up too much space.

imho grevluti/grevlut just takes up too much space for the benefit it gives,
imho we should just have grevi/grev and if you really want repeating load
immediates just use:
sv.li/elwid=16/subvl=4 rt, 0x5555

also bmrevi is unnecessary because bitreversed fields are very uncommon (i've
never seen code that uses them iirc) and there's a simple 2-instruction
sequence that does the same thing:
grevi rt, ra, 0b111111  # bit reverse
rldicl rt, rt, ...  # extract field, must use 63-x for bit positions

after cutting out all of the above stuff i mentioned, it should reduce the
space requirements by around 50%

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