From: anton@mips.complang.tuwien.ac.at
EricP writes:
>Thomas Koenig wrote:
>> Using a primitive Perl script to catch occurences, on a recent
>> My 66000 cmopiler, of the shape
>>
>> [op] Ra,Ra,Rb
>> [op] Ra,Rb,Ra
>> [op] Ra,#n,Ra
>> [op] Ra,Ra,#n
>> [op] Ra,Rb
>>
>> where |n| < 32, which could be a reasonable approximation of a
>> compressed instruction set, yields 14.9% (Perl), 16.6% (gnuplot)
>> and 23.9% (GSL) of such instructions. Potential space savings
>> would be a bit less than half that.
>>
>> Better compression schemes are certainly possible, but I think the
>> disadvantages of having more complex encodings outweigh any
>> potential savings in instruction size.
The RISC-V people brag about how little their compressed encoding
costs to decode; IIRC it's in the hundreds of something (not sure if
transistors or gates). Of course, with superscalar decoding the
compressed instruction set costs additional decoders plus logic to
select which decodings do not belong to actual instructions, but
that's true for any 16+32-bit encoding, however simple.
>So the % numbers you measured might just be coincidence and could be low.
>An ISA with both short 2- and long 3- register formats like RV where there
>is an incentive to do this optimization might provide stats confirmation.
I have done the following on a RV64GC system with Fedora 33:
objdump -d /lib64/lp64d/libperl.so.5.32|grep '^ *[0-9a-f]*:'|awk '{print
length($2)}'|sort|uniq -c
215782 4
179493 8
16-bit instructions are reported as 4 (4 hex digits), 32-bit
instructions are reported as 8.
If the actual binary /usr/bin/perl is meant, here's the stats for that:
objdump -d /usr//bin/perl|grep '^ *[0-9a-f]*:'|awk '{print lengt
($2)}'|sort|uniq -c
105 4
167 8
gnuplot is not installed, and GSL is not installed, either, whatever
it may be.
Just to widen the basis, here are a few more:
zstd:
129569 4
134985 8
git:
305090 4
274053 8
/usr/lib64/libc-2.32.so:
142208 4
113455 8
So the percentage of 16-bit instructions is a lot higher than for the
schemes that Thomas Koenig has looked at.
Another way to approach this question is to look at the current
champion of fixed instruction width, ARM A64, consider those
instructions (and addressing modes) that ARM A64 has and RISC-V does
not have, and look at how often they are used, and how many RISC-V
instructions are needed to replace them.
In any case, code density measurements show that both result in
compact code, with RV64GC having more compact code, and actually
having the most compact code among the architectures present in all
rounds of my measurements where RV64GC was present.
But code size is not everything. For ARM A64, you pay for it by the
increased complexity of implementing these instructions (in particular
the many register ports) and addressing modes. For bigger
implementations, instruction combining means additional front-end
effort for RISC-V, and then maybe similar implementation effort for
the combined instructions as for ARM A64 (but more flexibility in
selecting which instructions to combine). And, as mentioned above,
the additional decoding effort.
When we look at actual implementations, RISC-V has not reached the
widths that ARM A64 has reached, but I guess that this is more due to
the current potential markets for these two architectures than due to
technical issues. RISC-V seems to be pushing into server space
lately, so we may see wider implementations in the not-too-far future.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup,
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
