Re: [RFC PATCH v5] RISC-V: Add support for the Zfa extension

[Jeff Law <jeffreyalaw@gmail.com>]

On 6/29/23 18:47, Nelson Chu wrote:
> 
> 
> On Thu, Jun 29, 2023 at 11:52 PM Palmer Dabbelt <palmer@dabbelt.com 
> <mailto:palmer@dabbelt.com>> wrote:
> 
>     On Thu, 29 Jun 2023 08:49:16 PDT (-0700), jeffreyalaw@gmail.com
>     <mailto:jeffreyalaw@gmail.com> wrote:
>      >
>      >
>      > On 6/29/23 09:37, Palmer Dabbelt wrote:
>      >
>      >>>> > So my understanding is that this needs to wait for
>     ratification and is
>      >>>> > not blocked by the mentioned PR.
>      >>>> Is there something special about Zfa that makes it desirable
>     to wait for
>      >>>> ratification as opposed to standard practice of gating things
>     as the
>      >>>> specs get to a Frozen state?
>      >>>
>      >>> Not to my knowledge.
>      >>
>      >> Waiting for ratification is probably a bad idea, there's really
>     no way
>      >> to schedule around it.  That's a big part of the reason we've just
>      >> waited for frozen.
>      > Exactly.  ISTM that frozen is the right point to trigger.
> 
> 
> Okay, I never figured out the difference between ratified and frozen, 
> since both of them have examples that change the behaviors and syntaxes, 
> even encodings.  But anyway, thanks for clarifying the current rule that 
> we should commit when extension is frozen, not ratified.
Well as the newcomer to RISC-V I don't have the history.  In general I 
would expect very few changes from frozen to ratified and probably just 
things like semantic clarifications for issues that slipped through the 
prior states.  If things like encodings are still changing post-freeze, 
then that's a major failing of the process.

Also as the newcomer I tend to rely heavily on policies that other have 
set and the policy around this that has been drummed into my brain is 
freeze time :-)




> 
>      > And I think enough of it is settled that we can move forward. If RVI
>      > changes the set of forms allowed, then we can adjust.
> 
> 
> Does that mean we don't need to care about compatibility before the 
> ratified extensions?  That means we can simply change anything and don't 
> need to maintain the code even if it is frozen.  If that is so, then 
> Jim, Kito and I had agreed a very long time ago that we should accept 
> the experiment extension, which hasn't been frozen yet, with the 
> -experiment-extension option that is the same as LLVM.
If they were to change the forms of FP constants allowed, then we'd 
adjust.  If they add new allowed forms, then that's easy, we just need 
to build a suitable parser to recognize them.  The more interesting 
problem is if they remove allowed forms -- and as Palmer said, we'd try 
to keep the old forms for the sake of compatibility.



> I have looked and replied, Kito and Jan should also have looked.  The 
> special zfa syntax should be the same as LLVM when I looked.  But since 
> that is almost two month ago, it's good if someone helps to review it 
> again to make sure everything is on the line.
>  > I've looked at it earlier.  But I'll go over it again.
Last I heard the only issue was whether or not to allow an integer index 
into the table.  That's rough because one could easily confuse "2.0" 
with "2" though they'd have totally different meanings.  As a result 
LLVM removed the ability to use the table index IIRC.

> 
> Thanks, Jeff, it would be great to get your approval as well.
Happy to do so.  Hell, I wouldn't be comfortable merging it myself if I 
didn't.

jeff