[libre-riscv-dev] evaluation of bit-witdh scoreboards

[Luke Kenneth Casson Leighton]

On Monday, December 17, 2018, Jacob Lifshay <programmerjake at gmail.com>
wrote:

> On Sun, Dec 16, 2018, 06:38 Luke Kenneth Casson Leighton <lkcl at lkcl.net
> wrote:
>
> > On Sunday, December 16, 2018, Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > > On Sat, Dec 15, 2018 at 3:51 AM lkcl <luke.leighton at gmail.com> wrote:
> > >
> > > > we need to evaluate whether to drastically cut down the number
> > > > of registers and use a 2k SRAM instead.
> > > >
> > > If the memory is shared between cores, it definitely won't be
> sufficient
> > in
> > > size and will be a total pain to implement since we will probably need
> to
> > > have at least a port for each core.
> > > It will work pretty well to have the 2k per-core sram treated by the
> > > compiler as extra registers that can be only accessed by special move
> > > instructions. Importantly, the SRAM will need to be not memory-mapped
> > since
> > > then we need to get the MMU involved and LLVM is designed to spill to
> the
> > > stack rather than to a special memory region.
> >
> >
> > One idea, set up regs with vector shortcut, predication can save batch to
> > mem address by redirecting SP. Code all same its just that eg r63 gets
> used
> > as SP! Points to SRAM, standard code of stack spill updates. 2k sounding
> > small though. Dont know.
> >
> > Allen Baum told me of idea where MMU TLB is special case for SRAM, it
> > doesnt go through L1, judt TLB. I quite like it.
> >
> The  problem is not with implementing the hw, the problem is that if the
> sram is treated like memory that the os has to manage, then the compiler
> has a much harder time automatically using it. It will be difficult to use
> it for stack memory because it's not big enough to support more than a few
> function calls and switching the sp register must be known to the compiler
> so it can keep track of which registers are free and keep track of the
> addresses of objects properly;


>
Hum of course. Otherwise it is a big LLVM redesign. We cant maintain that.


> I don't think LLVM will support switching
> how sp is allocated without a very large amount of work.


>
Its hypothetically transparently possible with SV register redirection. Yes
even SP is redirectable. Honestly it scares me to think about having stack
redirection


>  I think it will be
> better to treat it as a bunch of registers because then the compiler can
> much more easily manage the sram by just running it through the register
> allocator.


Oh what, treat the SRAM as if it was a virtual register, you mean? Or,
split into multiple virtual regs. Thats neat. Horribly slow latency, clean
concept.

Then each "reg" can have a special LLVM microcode preamble for "pop off
stack" and another for push, hmmm....

Needs more thought and followup


>  We can come up with more than one calling convention that
> describes how the different locations are saved on a function call: the
> default ABI can have all of the sram be caller-saved to allow shaders to
> not need to save any of it, the functions called by the shaders can have a
> portion of it be callee-saved and the rest caller-saved to achieve a good
> balance.
>
> >
> > However simpler idea that also achieves security is a context switch
> > tracker flag. When context switch requested or occurs flag is
> automatically
> > cleared. Userspace program must re-request it. We only grant 3D app
> access.
> > Other programs may do otherwise.
> >
> I'd have to check if we can implement it securely, but on x86 there was a
> spectre-style security hole caused by delaying context-switching the fp
> (sse) registers.
>
> >
> >
> > > Doing so allows us to shrink
> > > the register file to 64 64-bit registers, shrinking it to 32 is cutting
> > it
> > > a bit close.
> >
> >
> > Ok.
> >
> > Well the virtualisation table may be ok, just gave to see. Need options
> in
> > case its not
> >
> >
> >
> > >
> > > Jacob
> > > _______________________________________________
> > > 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
> > _______________________________________________
> > 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