public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nelson Chu <nelson@rivosinc.com>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: jeffreyalaw@gmail.com, christoph.muellner@vrull.eu,
	 binutils@sourceware.org, Andrew Waterman <andrew@sifive.com>,
	 Jim Wilson <jim.wilson.gcc@gmail.com>,
	philipp.tomsich@vrull.eu, jbeulich@suse.com,
	 Kito Cheng <kito.cheng@gmail.com>,
	research_trasio@irq.a4lg.com
Subject: Re: [RFC PATCH v5] RISC-V: Add support for the Zfa extension
Date: Fri, 30 Jun 2023 08:47:00 +0800	[thread overview]
Message-ID: <CAPpQWtCmpFOzEFWvBU+AS2R_nxN9Oq=L6OGK854F8ZHkZbKpDw@mail.gmail.com> (raw)
In-Reply-To: <mhng-d76930ac-a02e-484b-b2c6-d7fe011bee09@palmer-ri-x1c9>

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]

On Thu, Jun 29, 2023 at 11:52 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:

> On Thu, 29 Jun 2023 08:49:16 PDT (-0700), 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.


> > 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.


> Presumably someone's actually looked at the code?  If not I can look
> over it...
>

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.

Thanks, Jeff, it would be great to get your approval as well.

Thanks
Nelson

  parent reply	other threads:[~2023-06-30  0:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13 13:36 Christoph Muellner
2023-06-29  7:52 ` Christoph Müllner
2023-06-29  8:33   ` Christoph Müllner
2023-06-29 15:07   ` Jeff Law
2023-06-29 15:10     ` Christoph Müllner
2023-06-29 15:37       ` Palmer Dabbelt
2023-06-29 15:49         ` Jeff Law
2023-06-29 15:51           ` Philipp Tomsich
2023-06-30 13:40             ` Jeff Law
2023-06-30 14:06               ` Jeff Law
2023-06-30 14:08                 ` Philipp Tomsich
2023-06-30 14:39                   ` Jeff Law
2023-06-29 15:52           ` Palmer Dabbelt
2023-06-29 16:03             ` Jeff Law
2023-06-29 16:12               ` Palmer Dabbelt
2023-06-30 14:07                 ` Philipp Tomsich
2023-06-30  0:47             ` Nelson Chu [this message]
2023-06-30  6:49               ` Kito Cheng
2023-06-30 13:38               ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPpQWtCmpFOzEFWvBU+AS2R_nxN9Oq=L6OGK854F8ZHkZbKpDw@mail.gmail.com' \
    --to=nelson@rivosinc.com \
    --cc=andrew@sifive.com \
    --cc=binutils@sourceware.org \
    --cc=christoph.muellner@vrull.eu \
    --cc=jbeulich@suse.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=kito.cheng@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=research_trasio@irq.a4lg.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).