[Libre-soc-dev] fantastically-weird regfile

Jacob Lifshay programmerjake at gmail.com
Mon Dec 14 03:49:39 GMT 2020


On Sun, Dec 13, 2020, 19:41 Jacob Lifshay <programmerjake at gmail.com> wrote:

> On Sun, Dec 13, 2020, 19:19 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
>> On 12/14/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
>> > On Sun, Dec 13, 2020 at 5:50 PM Luke Kenneth Casson Leighton
>> > <lkcl at lkcl.net> wrote:
>> >>
>> >> On 12/14/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
>> >> > That's very similar to what I already did for int and fp registers,
>> see:
>> >> >
>> >> > https://libre-soc.org/openpower/sv/svp_rewrite/svp64/
>> >> >
>> >> jacob once it's been documented the regfile stratification,
>> >> allocation, port numbering etc can be evaluated, as well as the Dep
>> >> Matrix layout
>> >
>> > Basic summary: they're conceptually organized differently, but
>> > microarchitecturally they are the exact same flat reg-file we always
>> > had.
>>
>> okaay, wheww :)
>>
>> > The purpose of the organization is to make it obvious how the standard
>> > 32 registers fit into the scheme, and how it can be expanded in the
>> > future (by adding more registers between each standard register,
>> > rather than adding more registers at the end, making instructions be
>> > automatically able to address all the new registers by just using a
>> > larger VL).
>>
>> can you illustrate / make a note of that with a piece of pseudocode
>> for-loop for i in range(VL) then how the mapping would work?
>>
>
> sure:
> setvli ..., VL=7
> add r20, r25, r30, elwidth=64, subvl=1
>
> where r20, r25, and r30 are standard OpenPower register names.
> Those names correspond to SVR20_00, SVR25_00, and SVR30_00.
>
> pseudocode:
> const STD_TO_SV_SHIFT = 2; // gets bigger as reg files expand to 256, 512,
> ... registers
>

The plan for future reg-file expansion is that setvl[i] has a field that
puts the processor in backward-compatibility mode for 128 registers
(field==0), 256 registers (field==1), 512 registers (field==2), and so on.
Our initial processor will only support 128 register mode, trapping on all
other field values, allowing emulation. later processors might only support
128 and 256 register mode, even later processors will also support 512
register mode and so on. For now, all we need to do is trap if the field !=
0, so it should have very low initial cost.

Jacob

>


More information about the Libre-soc-dev mailing list