[libre-riscv-dev] Instruction sorta-prefixes for easier high-register access

[Luke Kenneth Casson Leighton]

On Friday, January 18, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote:

> On Fri, Jan 18, 2019, 01:33 Luke Kenneth Casson Leighton <lkcl at lkcl.net
> wrote:
>
> > hi jacob, a brief thought / reply, more later:
> >
> > * prefixes on instructions gives an opportunity to do key-hole
> > analysis, assessing if the prefixes can be removed and use the CSR
> > stack instead.
> >
> Haven't heard of key-hole analysis before -- wikipedia didn't seem to have
> anything relevant
>
>
Peephole. Does local analysis and conversion. Prefixes can be removed,
replaced with CSR stack push ops pop.


> * thank you for explaining about predicate registers.
> > * one thought, have branch overwrite the src predicate.
> >
> that could work, but if we can specify a different dest I prefer to.


Concur... space really limited though. Also if cannot specify full range
for target, have to allocate 2 regs for x1-x31.

Can extend with 2nd prefix to do 2nd dest on branch.


> > * i like the VL multiplier idea.
> > * we don't want to go completely overboard, just the main uses.  CSR
> > stack can cover the "full" features
> >
> I actually think that having the prefixes implement everything


>
That is just not going to be possible. REMAP needs 32 bits per reshaper. It
is 16 bits per CSR Reg entry, and 16 per CSR Predicate entry.

I remembered for example that leaving out elwidth means that conversion
between widths will not be possible, and that setting elwidth has a side
effect of storing elements in the top bits of a register, instead of
sign/zero extending.

The design of SV CSRs is extremely interdependent on RV Base, and
exceptionally compact for what it does.

So this is why I said that we need to identify the subset of functionality
most needed.

I think we can barely get away with 20 bits to cover the full functionality
(minus REMAP), which would make every single op 64 bit (C 48 bit).

That would in turn mean double the I-Cache size, which I believe increases
power consumption by something well over 50%.



>  and have the
> compiler use prefixes instead of the rename table will greatly simplify the
> compiler since we don't have to come up with entirely new algorithms to
> handle the rename table.


Well it's software, so over time optimisations can be done.


> There are already existing architectures that have well-known compilation
> algorithms that are much more similar to the prefixed instruction approach
> than to the rename table approach.
>
>
Ok. Encouraging.


> > * am going to be relying on you to give feedback and insight on what
> > the main uses are!
> >
> will try my best
>
> >
> > l.
> >
> > _______________________________________________
> > libre-riscv-dev mailing list
> > libre-riscv-dev at lists.libre-riscv.org
> > http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
> >
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68