>>>>> On Wed, 15 Nov 2017 08:03:06 +0000, Alex Bradbury <
a...@asbradbury.org> said:
| Do you have any thoughts on, for instance, representing cases where
| rdcycle/rdinstret/rdtime are not implemented?
| Or is the expectation that you'd describe such as a system as RV32I
| M-mode only (how to describe that in an ISA string? let's call it
| $M_mode_only_RV32I for now), and M-mode implementations that _did_
| provide those pseudoinstructions would be $M_mode_only_RV32I with
| ZirdcycleZirdinstretZirdtime? Do you imagine defining a Zi<foo>
| specifier to indicate that unaligned loads/stores trap, or would you
| imagine that information is specified through some other mechanism?
This name expansion is part of a drive towards ratifying the base
spec, which uncovers a few issues caused by not separating out the
different places where the supported instruction set needs to be
defined.
There are (at least) two different types of supported instruction-set
specification needed:
1) platform profiles: a description of what a real hardware platform
must actually implement (and what would be present in a hardware
advertisment).
2) EEBIs: (execution-environment binary interfaces) describing how
software should be encoded for a given execution environment, with
examples being the current ABI and SBI specs.
The Foundation needs to standardize both kinds of spec. Note that
multiple EEBIs can run on one hardware platform.
The current user ISA spec does not distinguish between these cases,
and also encodes some EEBI/platform mandates in the base
instruction-set specifications. For example, the current "user" ISA
spec cannot be used as an "unprivileged" ISA spec, as some features
(e.g., misaligned accesses) are assumed to be often emulated by an EE.
We do need to factor out platform and EEBI constraints from the
instruction-set specifications. The primary goal here is to allow a
given instruction specification to be usable in many different
platform and EEBI specs, and at different privilege levels.
The current ISA naming convention is a better fit for EEBI specs as it
is coarse-grained and glosses over whether a feature is emulated or
not at various privilege levels, which makes it less suitable to use
for detailed hardware platform specs.
Your questions above are actually mostly related to a hardware
platform spec. To indicate an M-only platform, the convention would
be to not include lesser-privilege-mode indicators (HSU) in the ISA
string for the hardware platform (and to include them when they are
supported). As we get into more detailed questions, like do misaligned
memory accesses trap, it will be very difficult to encode all the
hardware choices in a simple standard string (e.g.., they only trap
when crossing a 4KiB page boundary, or only when the TLB misses on any
part of the access etc.). At some point, this level of detail has to
be represented in a platform config string / device tree of some kind.
In practice, most software just needs to know whether to emit separate
code for misaligned accesses or not (so, "yes" if all misaligned
accesses trap, and "no" if only traps when TLB misses on a part).
Another concern is that we require extensions to only increase
capability not remove functionality, so we cannot add
"Zimisaligntraps" as a standard extension to the ISA string. Neither
do we want to remove "I" specifier from trap-on-misalign
implementations. I think for platform specs, we can treat the ISA
string as an approximation of the platform capabilities, where the
deciding line is whether trap-and-emulate is sufficient to provide the
expected functionality and performance level of each instruction such
that the common ABIs on the platform would run reasonably well. So, a
hardware platform should be able to claim to support F and D even if
subnormals cause traps.
But I don't think capturing detailed hardware platform specs is really
the main issue you're worrying about here. I think the important
issues relate to a) providing a compatible ABI across various M-only
systems and b) tuning M-only code for a given hardware platform. ISA
strings for EEBIs should be exact, as in exactly these instructions
can be used by code for this ABI, but an M-only ABI could state that
misaligned accesses are illegal for example, as most implementations
will not have hardware support and will trap, and most M-only
applications will not need or want misaligned accesses to be trapped
and emulated. An M-only ABI can also state that divide instructions
are supported, and so a given system lacking a hardware divider must
provide emulation for divide instructions, but is also free to use the
compiler flag to generate software divide function calls instead to
accelerate code for that target.
For the cycle/iret/time counters, the current user spec was written to
mandate these are present for user-mode code (i.e., the U-mode ABI).
We need to decide if these are mandatory for M-only hardware platforms
when we ratify for Foundation. Another complication is that we
removed these from RV32E, but then said RV32E could add U mode. My
inclination is to say the counters must be supported in U/S/H-mode
(including RV32EU), but are optional in M-only platforms.
Of course, this is all separate from EEBIs, where a M-only ABI spec
could mandate counters are present.
Similarly, we could say misaligned support was not mandatory for
M-only platforms and maybe add a Zimisalign extension to announce
where the hardware did support it. The confusing thing is that
Zmisalign could be implicit in a U ABI spec, but might be explicit in
an U-capable platform spec.
| Currently, implementers who support multiply instructions in the M
| extensions but not divide would pass -march=rv32im and -mno-div to the
| compiler. As I understand it, this proposal is trying to ensure that
| extensions remain purely additive, so you wouldn't have an RV32IM with
| Zmnodiv and platforms that don't provide divide instructions (either
| in hardware or trapped+emulated by the runtime) would best be
| described as something like RV32I with Zmmulinsts (defining Zmmulinsts
| to imply Zmmul, Zmmulh, Zmmulhsu, Zmmulhu). Is that right?
Right - though maybe use the shorter name Zmul (Zm + ul) to describe
that set (so, "RV32I_Zmul" would be a common configuration). But
staying compatible with other gcc targets is also important, so I
would propose we keep existing "-mno-div" flag.
It is worth discussing if we want to have negative extensions "Zno---"
to simplify compiler command strings.
In the current compiler command lines, the -mabi argument doesn't
actually specify the complete ABI, as the -march string separately
indicates which instructions to use.
Krste
| Best,
| Alex