Including C.JAL with C.ADDIW in RV64C by taking one bit to discriminate

[Kelly Dean]

Andrew Waterman's dissertation [1], in tables 5.7 and 5.8 (p. 76 and 77) shows code size savings:
static dynamic
0.77% 1.26% C.ADDIW
0.59% 0.59% C.JAL

That's with a 5-bit register number and 6-bit immediate for C.ADDIW, and 11-bit immediate for C.JAL (± 2 kiB). But C.JAL is excluded from RV64C due to limited encoding space.

How about including both, by using one bit to select between C.ADDIW and C.JAL? To make space, reduce C.ADDIW's register number to 4-bit, allowing selection just of x0..x15, or reduce the immediate width to 5-bit. And reduce C.JAL's immediate to 10-bit (± 1 kiB).

Figure 5.5 (p. 54) shows that reducing C.ADDIW's immediate width from 6-bit to 5-bit would reduce the representable fraction by about 1/6. That reduces static savings to 0.64%. Dynamic impact is similar.

Figure 5.6 shows that reducing C.JAL's immediate width to 10-bit would reduce the representable fraction by about 10%, reducing static savings to about 0.52%. Dynamic impact is much less.

The combined savings of reduced C.ADDIW and reduced C.JAL is 1.16%, much higher than C.ADDIW's unreduced savings of 0.77% alone. The difference (0.39%) is higher than the savings for a lot of other instructions included in the C extension.

Arguments against: not worth the complication, and the spec is frozen.

[1] http://www.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-1.html

[lkcl .]

On Fri, Mar 16, 2018 at 10:38 PM, Kelly Dean <ke...@prtime.org> wrote:

> Andrew Waterman's dissertation [1], in tables 5.7 and 5.8 (p. 76 and 77) shows code size savings:
> static dynamic
> 0.77% 1.26% C.ADDIW
> 0.59% 0.59% C.JAL
>
> That's with a 5-bit register number and 6-bit immediate for C.ADDIW, and 11-bit immediate for C.JAL (± 2 kiB). But C.JAL is excluded from RV64C due to limited encoding space.
>
> How about including both, by using one bit to select between C.ADDIW and C.JAL?

> Arguments against: not worth the complication, and the spec is frozen.

kelly, hi,

long story, i was kinda hoping that something like this would come up
so that i could give an actual concrete example. what you propose
*could* theoretically be considered... *if* the UNIX ABI requirements
are *NOT* tied to RV64GC but are tied to RV64G instead.

if RV64G is the (lowest common denominator) UNIX base-line then any
"alternative" instruction encoding proposals and ideas *can* seriously
be considered, whilst multilib or multiarch can take care of selecting
the fastest / most appropriate, whether it the current C compression,
or whether it be the (future) proposed C idea that you suggest, or
even in the case of
blast-it-out-the-water-with-an-insane-memory-bus-bandwidth VLIW
implementations, stay on RV64G.

if however RV64GC is chosen then AUTOMATICALLY, i apologise for
pointing this out but you probably already knew it: any ideas that you
or anyone else have are excluded and might as well not even be
proposed: it will be far too late.

[note that various arguments were put forward including that
"software can always be recompiled": these arguments were all
comprehensively evaluted and were found not to hold up].

l.