From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-22.smtpout.orange.fr [80.12.242.22]) by sourceware.org (Postfix) with ESMTPS id 79DF03858C53 for ; Fri, 25 Aug 2023 16:10:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 79DF03858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jacob.remcomp.fr Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jacob.remcomp.fr Received: from smtpclient.apple ([90.22.252.13]) by smtp.orange.fr with ESMTPS id ZZOjqQk9I7qfuZZOjqDq9M; Fri, 25 Aug 2023 18:10:58 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wanadoo.fr; s=t20230301; t=1692979858; bh=nzZFFWkoZMhlOLB8II4ThviHTvS0/jtE4inl320rUTQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=F+6kXb4WMSGxhFs6c9v2RALq2fzvkYkGftn7GQMTHzt6iup+NNOkpwEigtBQVsKH+ JrzVTy0zdEYjcqMF3flWehA8JDAgqcYxIZSUvo8hdyPTdxGbokJ+RuIiXVdsMzAwVc cjUDTaMg4b0PvmIP/jOWEtHS88lYmBPC0kiB8XUteIUcYBCroT+TJSzbj3vhNu695G xsk6JLs8bRxksh5MHKe0KfAbzlTnkHXlQn6FWoT3eI+7dQjaQQ7jmSXpk7uefApfbt FHhSl/6rZel62RMFsnW6xGAOoWAhzex18Xv3Lw/o3uh6znMbld8dTGKBr41Iw7Gic9 lGBmZr+NPBsYA== X-ME-Helo: smtpclient.apple X-ME-Date: Fri, 25 Aug 2023 18:10:58 +0200 X-ME-IP: 90.22.252.13 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: P.S. Follow up to my last post From: jacob navia In-Reply-To: Date: Fri, 25 Aug 2023 18:10:47 +0200 Cc: jbeulich@suse.com, binutils@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <502E2019-6C30-45ED-9EE4-A5ABAABBB750@jacob.remcomp.fr> References: To: Palmer Dabbelt X-Mailer: Apple Mail (2.3731.600.7) X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: OK. 1) We agree that the -march=3Drv64gc_zbb option is completely = undocumented and impossible for the user to know. 2) We agree that =C2=AB gnu gas =C2=BB is an assembler whose duty is to = assemble instructions. But =C2=AB gas =C2=BB will refuse to assemble = those instructions.=20 Why is that? It is the responsibility of the programmer or the = compiler to write the instructions that are present in this or another = machine.=20 Why the assembler thinks it is necessary to forbid some = instructions??? 3) Obviously what is needed is a libc routine that will return the = machine id. Then gcc and the user could use it to see which instructions = are present, and that was the intent of my post. 4) Speaking of documentation. Since there wasn=E2=80=99t any = documentation of the many small letters that are used by the GAS = opcodes, I wrote one, and sent it to this group on July 27th. Since then = there was ZERO answers to that message. Why should I write = documentation if none in this group cares? OK, We agree that I should stop complaining, and writing documentation, = and pointing out bugs. Have a nice time > Le 25 ao=C3=BBt 2023 =C3=A0 17:32, Palmer Dabbelt = a =C3=A9crit : >=20 > On Fri, 25 Aug 2023 07:12:39 PDT (-0700), jacob@jacob.remcomp.fr = wrote: >> OF COURSE =C2=AB march =C2=BB is mentioned. But -march=3Drv64gc_zbb = is NOT. >>=20 >> Where please give me a link) that option is mentioned? >>=20 >> It is NOT mentioned in >>=20 >> https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html=EF=BF=BC >=20 > The "-march" argument is documented int the "-march" section of the = argument documentation, specifically: >=20 > -march=3DISA-string > Generate code for given RISC-V ISA (e.g. =E2=80=98rv64im=E2=80=99)= . ISA strings must be lower-case. Examples include =E2=80=98rv64i=E2=80=99= , =E2=80=98rv32g=E2=80=99, =E2=80=98rv32e=E2=80=99, and = =E2=80=98rv32imaf=E2=80=99. > When -march=3D is not specified, use the setting from = -mcpu. > If both -march and -mcpu=3D are not specified, the = default for this argument is system dependent, users who want a = specific architecture extensions should specify one explicitly. >=20 > Pretty much every port has a "-march" argument to control the = subtarget to generate code for. It's true that the GCC docs for = RISC-V's -march should be improved (there's even an unfinished patch out = to do it, you're more than welcome to finish it), but the argument = itself is definately documented. >=20 > Those are all GCC problems, though. I suppose we could improve the = binutils -march documentation as well, it'd essentially just be a = duplicate of the GCC docs (aside from some quirks like Zihintpause). >=20 >> The idea that the compiler could figure out the processor it is = running on it is completely far fetched isn=E2=80=99t it? >>=20 >> Jacob >>=20 >>=20 >>=20 >>> Le 25 ao=C3=BBt 2023 =C3=A0 15:07, jacob navia = a =C3=A9crit : >>> OK, there is no bug, I didn=E2=80=99t expect anything else. >>> SO: >>> To use all the instruction of the processor he/she is running on, = the user should: >>> 1)Be aware that gcc doesn=E2=80=99t see crucial instructions of the = processor by verifying its assembler output. >>> 2) Be aware that there is an (undocumented) option -march=E2=80=A6 = that will enable the assembler and the compiler to generate all the = instructions of the current processor. >>> Well, there is NO BUG! >>> This is by design then. >>> Thank you very much. >>> Jacob >>>> Le 25 ao=C3=BBt 2023 =C3=A0 14:00, Jan Beulich = a =C3=A9crit : >>>> On 25.08.2023 13:52, jacob navia wrote: >>>>> The lack of the Ebb instructions is CRUCIAL for performance when = accessing tables / arrays! >>>>> This instructions allow to combine an addition and a shift by 1, 2 = or 3, to access tables of shorts, ints or doubles. >>>>> This speeds up the access to tables enormously and would allow gcc = to generate much better code. >>>> Since you're writing to binutils@, you may want to also mention = what gas >>>> bug you think you see. So far (also in the other mail) you've = talked of >>>> only gcc. If you meant to say that like in gcc you need to enable = use of >>>> the instructions in gas, then yes, that's the way the RISC-V = assembler >>>> works (like e.g. also the PPC one, but unlike e.g. the x86 one). >>>> Jan