[Libre-soc-isa] [Bug 1056] questions and feedback (v2) on OPF RFC ls010

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1056

--- Comment #66 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Paul Mackerras from comment #57)
> (In reply to Luke Kenneth Casson Leighton from comment #50)

> > https://libre-soc.org/openpower/sv/remap/?#svstate_remap_area
> > 
> > ```
> >     |32:33|34:35|36:37|38:39|40:41| 42:46 | 62     |
> >     | --  | --  | --  | --  | --  | ----- | ------ |
> >     |mi0  |mi1  |mi2  |mo0  |mo1  | SVme  | RMpst  |
> > ```
> 
> Hmmm, I think a user program will expect the REMAP SPRs not to change
> underneath it even if those SVSTATE bits are zero.

turns out that "if zero equals disabled" not just for SVme...
now i think about it *only* SVme=zero means "REMAP entirely off"
which is nice...

... if SVme=0 *or* if SVSHAPE0-3 are zero, REMAP is disabled.

this allows programs to set up SVSHAPEn confident that nothing bad
will happen, and only when SVme gets set *later* to nonzero does
REMAP activate.

> So it looks like the only way to avoid having to save/restore the REMAP SPRs
> is if there is a facility enable bit for SV (or something like that) that
> would cause an interrupt if the program accesses any SV SPR.

ahhh i love the concept, let me think it through.

first thought: in some way those 5 bits of SVme *are* the "facility
enable" bits (of REMAP rather than the whole of SV).

but in this case you really *do* want to be able to "establish"
SVSHAPE0-3 well in advance: particularly for Indexed-REMAP high
performance implementations want as "advance notice" as they can
possibly get, even to the extent in the chacha20 implementation
the svindex instructions are done *once* as part of "setup".

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_chacha20.py;h=0a0feac1e#l132


second thought, testing beforehand rather than just "mfspr r4, SVSTATE"
and be done with it may actually be more costly!  but five SPRs is a
bit much.

ahhh i know.  a Trap Offset.  instead of 0x700, jump to 0x720 if REMAP is
active (when SVme != 0b00000).  or, jump to an entirely new set:

     REMAP_BASE_SPR[0:48] || 0x0700

just like Raptor's KAIVP SPR. (must do that as an RFC btw)

hmmm it might have to be:

     REMAP_BASE_SPR[0:63] + (0x0700 or other Trap addr)

what do you think?

-- 
You are receiving this mail because:
You are on the CC list for the bug.