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

[Luke Kenneth Casson Leighton]

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.

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.


> 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