These are all important considerations.
However, what they have in common when considering
This discussion is
bringing up an issue that needs wider discussion about
extensions in general.
is that they
are all tactical considerations are in the context of
our current framework of instruction space allocation.
What we will find is that these trade-off considerations
will reinforce the dilemma that Allen raises. How do we
manage these conflicting "necessities/requirements" of
different target environments.
I have hinted
at it already, we need not only tactical analysis of
feature tradeoff in different domains but a strategic
approach to support them.
The concern is
nothing new. It has been raised, if only obliquely, many
times prior on the [google] groups.riscv.org
(-dev, -sw especially) and lists.riscv.org
group, especially, has grappled with it in the context
of current V encoding being a subset of a [hypothetical]
64 bit encoding.
proposals have been mentioned, but there was then no
political will or perhaps more fairly, no common
perception that there was a compelling reason to work
systematically to address it. The [then] common thinking
was that 48 and 64 bit instruction spaces will be used
as 32 and 16 bit are exhausted, and everyone will be
happy. Well, that naive hope has not materialized and
many are envisioning clashes that will hurt RISCV
progress, either fragmentation or stagnation, as
tactical approaches and considerations are implement or
major strategic approaches were hinted at, even if they
were not outright proposed.
Support - this has been explicitly proposed in many
flavours: and is currently in the minds of many.
is a mode shift analogous to
thumb and back and
myriad of operating modes: real, protected, virtual,
long and their disparate instantiations.
that implementations should have considerable freedom on
how to provide hardware select-able functionality.
proposed framework to support that should be provided by
discussion and document tweaks about misa (Machine ISA
register) suggest that this mechanism,
though valuable, is inadequate as robust support for the
explosion of features.
expanded framework will be necessary, perhaps along the
lines of the two level performance counters definitions.
conflict with overlapping mappings of groups of
instructions to the same encoding space is not easily
addressed by this mechanism.
which leads us
extensions are not mapped to a fixed exclusive universal
but rather to
appropriately sized [based initially off 32 isize] minor
[22-bit], major[25-bit] or quadrant [30-bit] encoding,
allocated to the appropriate instruction encoding at
link/load time to match the hardware [or hardware
dynamic configuration, as above].
the green field encodings.
could have a default minor/major/quadrant encoding
Brown field can
also managed, simply if the related co-encoded feature
is present, with more complexity, and perhaps extensive
opcode mapping if blended into other feature's
implementation method would be to have a fixed exclusive
universal prefix for each feature.
instruction would then be emitted by the compiler as a
[prefix]:[instruction with default encoding] pair.
If the initial
prefixes are also nops [most of which are currently
designated as hints],
then the code
would be executable on machines that use the default
link/load intervention [at lower performance granted].
is backward compatible for the other established extensions:
most notably F which consumes 7 major opcodes spaces
[and *only* 5 with Zfinx (Zifloat?)] and
AMO which also consumes the majority of a major
strategic change has a number of immediate and
1) custom reserved major op codes effectively become
unreserved as "standard" extensions can be mapped
The custom reserved nature will then only be the
designated default allocation, "standard extensions"
will not default to them.
2) as mentioned above, if the prefix is a nop then
link/load support is not needed for direct execution
support [only efficiency].
3) the transition to higher bit encodings can be
simplified. As easily as the compiler emmitting the
designated prefix for that feature that encodes for
64 bit instructions.
two assigned fixed exclusive encodings per feature may
be useful, one a 64bit encoding and one a nop.
I do not intent to stifle any of the
tactical discussions of co-usefulness of features and
These are meaningful and useful
Rather, I hope that by having a framework
for coexistance of features, that those discussions can
proceed in a more guided way;
that discovers can be incorporated into a
framework centric corpus of understanding of trade-offs
and cooperative benefits of features/profiles.
On 2020-10-23 11:45 p.m., Robert Chyla wrote:
I agree with Greg's statements. For me 'code-size' is
very important for small, deeply embedded/IoT-class
Work in other groups (bitmanip) will also benefit
code size, but it is not primary focus I think as these
will also improve code-speed.
Linux-like big processors usually have DDR RAM and
code size is 'unlimited'.
It should not hurt as code-size advances will benefit
such big systems, but we should not forget about 'cheap
to implement'='logic size' factors.
IMO 'code-size' and 'code-speed' will be pulling same
rug (ISA-space) into opposite directions. We must
balance it properly - having a rug in one piece is IMO
On 10/23/2020 5:11 PM, Greg Favor wrote:
It seems like a TG, probably through
the statement of its charter, should clearly define
what types or classes of systems it is focused on
optimizing for (if there is an intended focus) and
what types or classes of systems it does not expect
to be appropriate for. More concretely, it seems
like there are a few TG's developing extensions
oriented towards embedded real time systems and/or
low-cost embedded systems. These are extensions
that would probably not be implemented in full-blown
Linux-class systems. Those extensions don't need to
worry about being acceptable to such system designs,
and can optimize for the requirements and
constraints of their target class(es) of systems.
Unless I'm mistaken, this TG falls in that
category. And as long as the charter captures
this, then the extension it produces can be
properly evaluated against its goals and target
system applications (and not be judged wrt other
classes of systems). And key trade-off
considerations - like certain types of
implementation approaches being acceptable or
unacceptable for the target system applications -
should probably be agreed upon early on.
This discussion is
bringing up an issue that needs wider
discussion about extensions in general.
Risc-V is intended
to be an architecture that supports an
extremely wide range of implementations,
ranging from very
low gate count microcontrollers, to high end
superscalar out-of-order processors.
How do we evaluate
an extension that only makes sense at one end
or the other?
I don't expect a
vector, or even hypervisor extensions in a low
gate count system.
There are other
extensions that are primarily aimed at
specific applications areas as well.
A micro sequenced
(e.g. push/pop[int]) op might be fairly
trivial to implement in a low gate count
(e.g. without VM, but with PMPs) and have
significant savings in code size, power, and
They may have none
of those, or less significant, advantages in a
high end implementation --
and/or might be
very difficult or costly to implement in them,
(e.g. for TLB miss, interrupt, & exception
(I am not claiming
that these specific ops do, but just pretend
there is one like that)
Should we avoid
defining instructions and extensions like
Or just allow that
some extensions just don't make sense for some
class of implementation?
guidelines we can put in place to help make
This same (not
precisely the same) kind of issue is rearing
its head in other places, e.g. range based
Robert Chyla, Lead Engineer, Debug and Trace Probe
1211 Flynn Rd, Unit 104
Camarillo, CA 93012 USA
Office: +1 805 383 3682 x104