[Libre-soc-dev] svp64

[Luke Kenneth Casson Leighton]

On Friday, December 18, 2020, Jacob Lifshay <programmerjake at gmail.com>
wrote:

>>
>
> we can just use .long in an assembler macro for now...no binutils
> modification needed.

aw fer goodness sake, why on earth...  sigh ok yes i love it, why didn't i
think of that earlier :)


>> * still do not know what the best arrangement for CRs is.
>>
>
> I'm for the arrangement that mirrors the register layout I picked for
> FP/Int registers.

the problem is that it's not that simple.  it's been established that the
layout you picked doesn't allow scalar default behaviour.

also what i came up with is problematic as well.

also: starting from CR[6] isn't going to work from a hardware perspective;
moving the CRs to align at the hardware level to CR[6] is not going to fly
either.

we have to start by looking at some example assembler, and seeing if the
vectorisation of CRs can be accessed cleanly without too many CR mv
operations jamming up the works.  and if those vectorised CR ops are not
themselves hugely problematic.

for example if counting sequentially from CR[offset+i] in a VL for loop
near 100% overwrites CR0 thru 3 this will screw scalar operations.

the numbering cannot be arbitrarily picked and declared "final" without
justification is what i am saying.

so if you prefer a particular scheme, it needs to be accompanied by example
assembler code showing how it is efficient and effective.

then also i suspect that the same reasoning that went into the creation of
the original encoding may also apply to CRs.  but, again, this needs to be
verified by creating examples.

this may take time sigh.







>> the choices here are: abandon data-dependent ffirst or spend a huge
amount
>> of time reviewing the SPR layout.  neither are good choices when we are
>> under time pressure.
>>
>
> I think we should just go with the option that SPRs are relatively cheap,
> so we can just allocate 1 spr completely to VL (supporting 0 through 64
> inclusive for now), since on future versions we'd want to support VL>64
> anyway. This would also improve semantics for when we want to read VL
after
> a load ffirst or other non-setvl VL-adjustment instruction, avoiding the
> need to mask/shift to extract the VL value.

fortunately it is not unreasonable to have multiple ways to get at the same
underlying register.

in the original version if SV i thrrefore provifed *two* wats to set and
get VL a, MAXVL and SUBVL

* STATE CSR which contained them all.
* separate MAXVL CSR
* separate VL CSR

*all* of these were read/write, and the immediate CSR write instructions
could write up to 5 bits into a CSR using only a 32 bit instruction (values
1 to 32 for VL and MAXVL).

so that is no problem.  it's that the encoding for STATE was carefully
jammed into only 32 bits and that took about a *MONTH* to design and write
up.

we don't have a month to spend, abandoning that work and redoing it.

that said, yeah, sigh, dd ff is sufficiently compelling.

i'll reread the SVorig spec and see what can be done.

l.


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