[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal
Allen Baum
allen.baum at esperantotech.com
Fri Aug 9 19:11:45 BST 2019
On Thu, Aug 8, 2019 at 9:16 PM lkcl <luke.leighton at gmail.com> wrote:
>
> > Compiling for a specific platform means that support for required
> accuracy modes is guaranteed (and therefore does not need discovery
> sequences), while allowing portable code to execute discovery sequences to
> detect support for alternative accuracy modes.
>
> The latter will be essential for detecting the "fast_*" capability.
>
> Main point, I cannot emphasise enough how critical it is that userspace
> software get at the underlying hardware characteristics. This for Khronos
> Standards Compliance.
>
> Sensible proposal, Dan. will write it up shortly.
>
Well, one way to get at the underlying HW characteristics is an ECALL to a
higher priv mode; That will take a little longer, but I don't see why it
would be used more than once during the run of an applications, so that
should be OK.
But a similar issue has come up in several forums, and I've proposed a
standard discovery mechanism that will enable all kinds discovery using a
CSR interface.
Writing the CSR initializes a pointer into a discovery data structure, and
reading it will return the contents of the structure at that offset (with
optional autoincrement)
The data structure is a linked list of capabilities (ID, offset of next
capability) where the actual capability is implementation dependent (on the
ID).
So, a config string ID, debug capability ID, ISA capability ID can be
independently defined to be YAML, binary or ascii formats, as desired.
How that is implemented under the covers is implementation dependent: at
one end of the spectrum is a ROM whose interface is the CSR, and at the
other end all accesses trap to M-mode code that knows where to find the
information.
I think this is backwards compatible with the current architectural
definition of the configuration string; it just makes access more portable
(from a SW point of view), expands it to allow other kinds of capabilities
and formats that may be more easily parsable and enables future expansion.
More information about the libre-riscv-dev
mailing list