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

[Jacob Lifshay]

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; I don't think LLVM will support switching
how sp is allocated without a very large amount of work. 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. 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
>