[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 #27 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #25)
> (In reply to Jacob Lifshay from comment #23)
> > (In reply to Jacob Lifshay from comment #20)
> > > example encoding scheme (just complete enough to illustrate my point):
> > 
> > fleshed out as "alternative encoding (3)":
> > 
> > https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;
> > h=477eb56ba72f4c0538fe5fc23009a06b16c82828
> 
> i already said "no" to Rc=1 specialisation.
> 
> that was a huge amount of time wasted by going down a rabbithole
> where i had already said "no".

except that your reasons for saying no turned out to be no longer a problem,
and my reason for saying yes still applies -- basically everything already has
Rc in bit 31 and this allows us to use existing instruction forms for 32-bit
po9 instructions.

> appreciated - unless there is a really *really* good reason i am
not going to worry about it.  first reason: breaking up the 24-bits
of SVRM starts to interfere with XO (in other encodings).
second, there is precedent for Rc being in bit 21

repeating my reasoning:
1. where you say SVRM being broken up interferes with XO -- the encoding table
I wrote demonstrates that to not be an issue because SVRM doesn't exist when
all the possibly-conflicting XO fields exist (32-bit scalar po9).
2. precedent for Rc being in bit 21 -- there is waay more precedent for Rc
being in bit 31 and that will save a bunch of work for needing all the new
instruction forms, as well as other changes.

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