From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 3F2BD385770B for ; Fri, 30 Jun 2023 13:38:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F2BD385770B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1b82616c4ecso9579775ad.2 for ; Fri, 30 Jun 2023 06:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688132286; x=1690724286; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=kcWNE/8wjK+NlNKsNC/vSsoIc3zOL89Ms5cylguWlCs=; b=HxQpWAVj7WaA+fda6kbw0m+ikluIvIaNs3bZxNiE0i3tSh8KR0Sh49GXyzeVmwD7Ui NnevGwG9jcLvyiQRwiYqFmHhw9f9g6rk7DGdSd52o9UvepIc+2D1MntnFuLcBZONSs3m 0aDsRVvdCxfbXye718jfYl4e7IWp0c2pqGyGhjDri5Ue8Vyfpj/quRrfTYhr8gh6Q0zq +ZZodsQ6gtMuby2otGQucIKllUh5/Z3+JxUQooRDfyCRNF+QgrXR+zs3fEpR/odJUvQq 5PkR8pUUnEvV23R6bUcXRr3kTcuRw+FYUnOsYF1xcKZ7hxSRVx9Y9BIWl+9MdDPbsp4g OBcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688132286; x=1690724286; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kcWNE/8wjK+NlNKsNC/vSsoIc3zOL89Ms5cylguWlCs=; b=ir3/tEqYPsnvcDhWN3fhYELVKfwAF4i3NPvdodDpnf9+LuFtKMtAcThfDq7NnH7ZOX oVZ93KrtZMkO95DH4VMu7SDTaI0t7DexgWxC1viIpTjjzhv9shfPL2MkjCLquR2eXVSS qPuVxsPBWf/QkQjmBbcad12mL22Cpzdt5WHQSKfea3dorUoSfZWi0voLShGSX/JRvsdR fjPBbZuwqJAYecoQkqZ+IkMJHcilchOihhybuh+ifjwJGwPS/H2liIbhgPaV1/fgcubA sJjwyR58zUNdWOuwI6j+eZUsbfUHxTopUk+hfzm+2/DSTix1RYQL0shP+e2FV9IgAJ+9 xP6g== X-Gm-Message-State: ABy/qLYrwPP98US55mFwpunUi0htaS6Z2TDq2rto5e9FbFQBXXgU0JBy t5lHaHn5UuOdDHbOEDIELwA= X-Google-Smtp-Source: APBJJlHG5OUk4c4/zun6p3BVHKwcW/qywUD1M64SjM/umNBXvPWJ9nlsYVg5gZwE2IikujzmxF6KjQ== X-Received: by 2002:a17:902:c452:b0:1ad:b5b4:e424 with SMTP id m18-20020a170902c45200b001adb5b4e424mr1522360plm.38.1688132285932; Fri, 30 Jun 2023 06:38:05 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id be4-20020a170902aa0400b001b52891bd45sm10831970plb.57.2023.06.30.06.38.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jun 2023 06:38:05 -0700 (PDT) Message-ID: Date: Fri, 30 Jun 2023 07:38:03 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [RFC PATCH v5] RISC-V: Add support for the Zfa extension Content-Language: en-US To: Nelson Chu , Palmer Dabbelt Cc: christoph.muellner@vrull.eu, binutils@sourceware.org, Andrew Waterman , Jim Wilson , philipp.tomsich@vrull.eu, jbeulich@suse.com, Kito Cheng , research_trasio@irq.a4lg.com References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 6/29/23 18:47, Nelson Chu wrote: > > > On Thu, Jun 29, 2023 at 11:52 PM Palmer Dabbelt > 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. 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