Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 4 Sep 2024 04:20:17 -0500
Organization: A noiseless patient Spider
Lines: 74
Message-ID: <vb98ol$3plah$1@dont-email.me>
References: <vajo7i$2s028$1@dont-email.me>
 <memo.20240827205925.19028i@jgd.cix.co.uk> <valki8$35fk2$1@dont-email.me>
 <2644ef96e12b369c5fce9231bfc8030d@www.novabbs.org>
 <vam5qo$3bb7o$1@dont-email.me>
 <2f1a154a34f72709b0a23ac8e750b02b@www.novabbs.org>
 <vaoqcf$3r1u3$1@dont-email.me> <vavgq7$12u29$1@dont-email.me>
 <vb002r$156ge$1@dont-email.me> <vb7stc$3fn7b$1@dont-email.me>
 <vb85qa$3h0j0$1@dont-email.me> <2024Sep4.100551@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 04 Sep 2024 11:20:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8de94f8feec99f95a188a9107769a9f3";
	logging-data="3986769"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18aTCiGCxxFTr3m0eorOMipyfLHjLbRvpY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:fvIOo2b3ApeN9lamJxrlnkhDgg0=
In-Reply-To: <2024Sep4.100551@mips.complang.tuwien.ac.at>
Content-Language: en-US
Bytes: 4351

On 9/4/2024 3:05 AM, Anton Ertl wrote:
> BGB <cr88192@gmail.com> writes:
>> Otherwise, annoying:
>> Despite configuring GCC to use RV64G, it builds its C library as RV64GC
>> and is like "well, close enough".
> 
> This may be an artifact of bootstrapping.  At some point I built a new
> version of gcc for our Alphas.  We had machines without the BWX
> extensions and machines with the BWX extension.
> 
> Of course I built gcc on the fastest machine we had, one with BWX.
> And then I found out that the resulting compiler binary would not run
> on the machines without BWX.
> 
> Ok, so build it again, taking care to configure it to not use BWX in
> bootstrapping itself.  However, somehow libgcc got inherited from the
> previous build, so the resulting compiler would run on machines
> without BWX, but the binaries it produced would not.  My guess is that
> something similar happened for libgcc in your case.
> 
> I did another round of rebuilding, making sure that libgcc was rebuilt
> from scratch without BWX.  I don't remember all that was involved;
> maybe I just did this build on a machine that does not have BWX.
> 

../configure --prefix=/usr/local --with-arch=rv64g --with-abi=lp64 
--enable-multilib

I had done "make clean" before the build, partly as it had previously 
been configured for "rv64im" (and wanted everything to be consistent), 
but seemingly when configured for RV64IM, it did not build any C 
libraries (and I had since moved from RV64IM to RV64G).

I originally wanted "rv64gZba" but this confused the build process, 
seemingly because its process only works if one selects one from an 
already-known-but-unspecified list of known configurations.

None the less, was seeing 'C' instructions present.


> [Risc-V compressed instructions]
>> Which is annoying because seemingly nearly every instruction has its own
>> encoding scheme for the immediate fields.
> 
> It's designed for easy hardware decoding, so maybe you just need to
> discover the ideas behind that and put them into your decoder.
> 

I also need to support it in the emulator, and here it is a mess of 
shift-and-mask (might be at least slightly less annoying in Verilog).


But, kind of annoying when in a relatively short sequence of 
instructions they manage to come up with 15 different ways to encode the 
immediate fields.

So, 15 immediate field layouts for 51 instructions, only slightly over 3 
instructions per immediate field layout.

Many do manage to keep the same bits in the same relative positions, 
where keeping the same bit in the same position when possible was 
seemingly a design priority for RV (but, then every load/store scale 
gets its own layout for the immediate field, ...).


Not saying it is not cheap to decode, but more that its design is rather 
annoying in this area (and part of why I blew off 'C' initially).


....


> - anton