Base ISA Ratification

[Krste Asanovic]

We're going to start the public review period of the RISC-V base ISA
and standard extensions. The review period ends December 21, 2018.

The document is attached and is also available from the github repo:

https://github.com/riscv/riscv-isa-manual

The ISA spec version is 20181106-Base-Ratification.

Unlike other RISC-V Foundation Task Groups, the specification was
already mostly in place before the Foundation was created, and has
been heavily scrutinized and implemented multiple times, including via
multiple different formal models.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the base ISA task group.
Any minor and/or uncontroversial changes will be made without a second
review.

The task group will then run an internal ballot and gather votes for
approval. Any dissenting comments or other feedback will be discussed
and summarized together with results from the public review period to
form a report to be forwarded to the board of Directors for final
approval.

Krste Asanovic (Chair) and Andrew Waterman (Vice-Chair)

[Liviu Ionescu]

> On 7 Nov 2018, at 05:44, Krste Asanovic <kr...@berkeley.edu> wrote:
>
>
> We're going to start the public review period of the RISC-V base ISA
> and standard extensions.

on one side I noticed that now neither the CSRs nor the M-mode are mandatory.

on the other side, at page 2 it is stated that the 'unprivileged' specs are paired with the first privileged specs in volume 2, and possible other future privileged specs.


for me, after reading the paragraphs several times, it is still not clear if compliance with the base ISA in the first volume is enough or not.

in other words, if a design does not use M-mode at all, and uses some CSRs, but a different set compared to the current privileged specs, and the design is not yet specified in any official RISC-V foundation document, is it RISC-V compliant or not?

or, to phrase it bluntly, should all future 'privileged' specs be blessed by the Foundation?


regards,

Liviu

[Michael Clark]

I can’t answer authoritatively, but it has been stated several times that Privileged ISA compliance is not necessary for compliance with the Base ISA, however, profiles, such as an application processor (or “Linux profile”), will specify the Base ISA, a set of specific extensions, the Privileged ISA, and potentially other details such as early-boot firmware requirements and interfaces.

The Base ISA itself is modular; and if F and D are not implemented then the floating-point CSRs are not necessary, so one can implement a subset of the Base ISA and be compliant with that subset e.g. RV32I. This implies subsets can be compliant.

That said, there are issues with compliance testing, as one needs a trap mechanism to detect, for example, that misaligned jumps cause an exception. Exceptions are mentioned in the Base ISA, but there is no mechanism described to handle them.

[Andrew Waterman]

If you've got any base-ISA issues to report, we request that you use the github issue tracker (https://github.com/riscv/riscv-isa-manual/issues) and apply the "Base ISA Ratification" tag.

We acknowledge that some folks don't agree to github's terms, but we value the feedback regardless.  So we'll do our best to address it.  (But the github issue tracker remains the official arbiter.)

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/m2pnvhpn5e.fsf%40berkeley.edu.

[Rogier Brussee]

This is as good a moment to ask as any. 

Are there plans to fill in (more of) the remaining free slots in the C extension once the current version is ratified and now that more experience and statistics of use is available? 

Gratuitous suggestions:

C.JALRA  11imm       —>   JALR ra ra imm<<1                    #@ reserved full slot.         For long or absolute calls, see CALL macro 

C.NOT rsd’                 —>  XORI rsd rsd -1.                          #@ reserved C.op-imm 2, rs2' field 000. Because not is a basic op and fusion

C.NEG  rs2d’*            —>  SUB rs2d x0 rs2d                        #@ C.ADDI4SPN  rs2d’ 0.  Because negative is a basic op and fusion. rs2d' !=0.

C.LPC   rd                  —>  AUIPC rd 0                                  #@ C.LUI rd 0                     For pc rel addressing, see LA macro 

This leaves one little opcode in op-imm for an instruction of type OP2 rsd' rs2' en 7/8 th of an opcode for an instruction of type OP1 rsd'. 

Rogier

Op woensdag 7 november 2018 04:44:39 UTC+1 schreef krste:

[Liviu Ionescu]

> On 7 Nov 2018, at 12:21, Michael Clark <michae...@mac.com> wrote:
>
> ... it has been stated several times that Privileged ISA compliance is not necessary for compliance with the Base ISA

if it was agreed and stated so, why not make it clear in the specs?


the current base ISA specs, although greatly improved, are still biased towards the privileged specs.

the first example? the document title itself.

we all call it the 'Base ISA', but the document title is still 'unprivileged ISA', and on page 2 it is mentioned that the unprivileged specs are paired with some privileged specs. what is the purpose of this mention? a microcontroller profile might have nothing to do with modes and/or privileges, so strictly speaking it may not even be a new version of the 'privileged specs'.


my proposal is to name the document 'the Base ISA', and remove unnecessary references to modes, privileges, volume II, etc.

volume I can be free-standing, and specify only the instruction set(s) and extensions, without any other details related to profiles, platforms, etc.


regards,

Liviu

[Samuel Falvo II]

I also pre-date the foundation (barely), and I believe this has always
been the intention; I suspect making a pull request against any
verbiage you consider ambiguous would probably be approved.

I believe the reason why they chose "Unprivileged ISA" instead of
"Base ISA" is because it was always intended to represent the ISA
capable of being run in the lowest possible privilege level. This
could be, for example, a software emulator where emulator services
(not necessarily implemented in RISC-V!) are invoked via ECALL
instructions, or of course in hardware where U-mode dispatches to S or
M modes depending on the kernel and hardware support. In earlier
specifications, I remember reading mention of sandboxed
implementations as well, alluding to some aspirations of using RISC-V
as a common byte-code, similar to how WASM is currently being marketed
today. It seems that has fallen by the way-side, however.
Regardless, when looked at in that specific context, "unprivileged
ISA" makes more sense -- to make a fully functional (virtual or
tangible) processor, you'd need *more* than what the unprivileged
instruction set could give, so a firm basis would need both the
complete unprivileged ISA as well as some manner of privileged
capabilities.

To illustrate, my KCP53000 implements a small number of CSRs (most
important being mtvec), WFI, and some of the other features from the
privileged M-mode specs. (It is a proper subset of v1.9 of the
priv-spec; not everything is implemented.) The rest of the processor
is just the unprivileged ISA. PicoRV32 also requires privileged-like
support, but does so with a custom set of instructions unique to its
design. The point being, the unprivileged ISA is not sufficient to
build a functioning piece of hardware or even an emulator thereof.
But it *is* sufficient to run any kind of software you want *within* a
sandbox. Thus, a separation of concerns seems relevant and desirable.

Personally, I advocate for retaining the nomenclature as it stands
(privileged and unprivileged specifications), but I *do* advocate
having a minimalist "base" profile, something which can be taken as a
common subset of all other profiles, including the unprivileged specs
plus whatever minimum subset of M-mode functionality is required to
make a working piece of silicon.

> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/F971D593-0254-46E3-943E-41FA2F5C13D6%40livius.net.



--
Samuel A. Falvo II

[kr...@berkeley.edu]

>>>>> On Wed, 7 Nov 2018 03:15:31 -0800 (PST), Rogier Brussee <rogier....@gmail.com> said:
| This is as good a moment to ask as any. 

It might be a good moment, but it's not the right thread. Redirecting.

| Are there plans to fill in (more of) the remaining free slots in the C
| extension once the current version is ratified and now that more experience and
| statistics of use is available? 

Yes, but only after more thorough compiler and benchmarking work.

If anyone has realistic source code examples where code size is poor
to add to benchmarking database, this would be useful.

Krste

| --
| You received this message because you are subscribed to the Google Groups
| "RISC-V ISA Dev" group.
| To unsubscribe from this group and stop receiving emails from it, send an email
| to isa-dev+u...@groups.riscv.org.
| To post to this group, send email to isa...@groups.riscv.org.
| Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/
| .
| To view this discussion on the web visit https://groups.google.com/a/
| groups.riscv.org/d/msgid/isa-dev/

| 902e204b-2e6a-49c2-a955-c8df0451603b%40groups.riscv.org.

[kr...@berkeley.edu]

>>>>> On Wed, 7 Nov 2018 14:04:38 +0200, Liviu Ionescu <i...@livius.net> said:

|| On 7 Nov 2018, at 12:21, Michael Clark <michae...@mac.com> wrote:
|| ... it has been stated several times that Privileged ISA compliance is not necessary for compliance with the Base ISA
| if it was agreed and stated so, why not make it clear in the specs?

Because these are the instruction set specifications, not the
compliance suite manuals.

| the current base ISA specs, although greatly improved, are still biased towards the privileged specs.
| the first example? the document title itself.
| we all call it the 'Base ISA', but the document title is still
| 'unprivileged ISA', and on page 2 it is mentioned that the
| unprivileged specs are paired with some privileged specs. what is
| the purpose of this mention?

So people seeking the privileged ISA will see it is specified
elsewhere.

| a microcontroller profile might have
| nothing to do with modes and/or privileges, so strictly speaking it
| may not even be a new version of the 'privileged specs'.

A custom version of the ISA manual that only contains text relevant to
a single class of systems is something that is entirely possible given
the CC licence on the material. However, the Foundation specs are
supposed to be useful for all classes of system that use the spec.

| my proposal is to name the document 'the Base ISA', and remove unnecessary references to modes, privileges, volume II, etc.

The "Base ISA" already has a formal meaning of the mandatory integer
portion (e.g. , RV32I) to which extensions (privileged and/or
unprivileged) are added, even if sometimes the term base is used
informally for G or GC.


Krste

| volume I can be free-standing, and specify only the instruction
| set(s) and extensions, without any other details related to
| profiles, platforms, etc.




| regards,

| Liviu

| --
| You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
| To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
| To post to this group, send email to isa...@groups.riscv.org.
| Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

| To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/F971D593-0254-46E3-943E-41FA2F5C13D6%40livius.net.

[Bruce Hoult]

On Wed, Nov 7, 2018 at 4:54 PM, <kr...@berkeley.edu> wrote:

>>>>> On Wed, 7 Nov 2018 03:15:31 -0800 (PST), Rogier Brussee <rogier....@gmail.com> said:
| This is as good a moment to ask as any. 

It might be a good moment, but it's not the right thread.  Redirecting.

| Are there plans to fill in (more of) the remaining free slots in the C
| extension once the current version is ratified and now that more experience and
| statistics of use is available? 

Yes, but only after more thorough compiler and benchmarking work.

If anyone has realistic source code examples where code size is poor
to add to benchmarking database, this would be useful.

I know multiple people have complained about embedded code being big because of the lack of compressed byte loads and stores.

However no one has presented an example where this is significant in the context of an entire application (including whatever part of the C library is linked in) rather than an individual function.

[Guy Lemieux]

wild and crazy idea time — optimal code compression is obviously application specific. 

how about leaving these few opcodes as “loadable” by the application? the new state would have to change on a context switch of course.

a naive way would be a simple table lookup that produces a single 32b insruction. a better way, which would take some effort to specify, would allow bitfields like register specifiers to be transferred from the input instruction into the output instruction. for people worried about instruction decode time, a default set of compressed instructions could be specified, with a loadable opcode table being optional — but specifying it now allows forward compatibility as the context switcher can test if only the default set is used and not save the extra state. 

guy

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAP8PnuT5NLjOMkwLRdRM5D3OZDemUEXWmhwmr_OwPtGO_m8X5w%40mail.gmail.com.

[Liviu Ionescu]

> On 8 Nov 2018, at 03:11, kr...@berkeley.edu wrote:
>
> | my proposal is to name the document 'the Base ISA', and remove unnecessary references to modes, privileges, volume II, etc.
>
> The "Base ISA" already has a formal meaning of the mandatory integer
> portion (e.g. , RV32I) to which extensions (privileged and/or
> unprivileged) are added, even if sometimes the term base is used
> informally for G or GC.

> On 8 Nov 2018, at 17:28, Rishiyur Nikhil via Formalspec <forma...@workspace.riscv.org> wrote:
>
> If you've got any base-ISA issues to report, we request that you use the github issue tracker (https://github.com/riscv/riscv-isa-manual/issues) and apply the "Base ISA Ratification" tag.

given the above, what does "Base ISA Ratification" mean? only the 32I+64I portion? all IZMAFDQC extensions? (as tagged in Volume I with 'Ratification').


the point is that the terminology used by various persons is not consistent.


regards,

Liviu

[Luke Kenneth Casson Leighton]

On Wed, Nov 7, 2018 at 11:14 AM Andrew Waterman <and...@sifive.com> wrote:
>
> If you've got any base-ISA issues to report, we request that you use the github issue tracker (https://github.com/riscv/riscv-isa-manual/issues) and apply the "Base ISA Ratification" tag.
>
> We acknowledge that some folks don't agree to github's terms, but we value the feedback regardless. So we'll do our best to address it. (But the github issue tracker remains the official arbiter.)

appreciated.

so i have a question: given the persistent public bullying (the
latest incident being only yesterday), i'd like to know if the issues
that i've noted will be genuinely welcomed and addressed, or will the
bullying continue, making me feel like a 2nd rate citizen in the
RISC-V community?

l.

[Alex Bradbury]

On Wed, 7 Nov 2018 at 03:44, Krste Asanovic <kr...@berkeley.edu> wrote:
>
>
> We're going to start the public review period of the RISC-V base ISA
> and standard extensions. The review period ends December 21, 2018.
>
> The document is attached and is also available from the github repo:
>
> https://github.com/riscv/riscv-isa-manual
>
> The ISA spec version is 20181106-Base-Ratification.
>
> Unlike other RISC-V Foundation Task Groups, the specification was
> already mostly in place before the Foundation was created, and has
> been heavily scrutinized and implemented multiple times, including via
> multiple different formal models.
>
> During the public review period, corrections, comments, and
> suggestions, will be gathered for review by the base ISA task group.
> Any minor and/or uncontroversial changes will be made without a second
> review.

Reflecting my previous feedback, I've filed
https://github.com/riscv/riscv-isa-manual/issues/265 regarding the
number of FPRs for RV32EF and RV32EFD systems.

I'd also appreciate some guidance on how software is meant to react to
moving fence.i and CSR access out of the base ISA. Right now, passing
-march=rv32imac to the GNU or LLVM assemblers will support fence.i and
the CSR access instructions. Should we be encouraging toolchain users
to transition towards -march=rv32imac_zifencei_zicsr?

Best,

Alex

[Michael Chapman]

I believe that having a separate FP register file for embedded is
unnecessarily
expensive and makes light weight threads more expensive and less attractive
to use than they would otherwise be.

We find using the same 16 (really 15 as x0 is zero), 32 bit wide
registers for both
integer, single precision and double precision floating point works well
for deeply
embedded applications and reduces the context size of a thread enough to
make
a real difference for this class of applications where total available
SRAM is
extremely limited.

A double precision floating operand will use two adjacent aligned
registers (just
like a 64 bit integer operand).

Note that using the same register file for floating point and integer is
exactly what
happens when no floating point unit is present with the software
emulation API.

I.e. by not having separate floating point registers, we avoid having
another set of
calling conventions!

[Guy Lemieux]

Are you referring to only the E spec?

I believe current E code can run unmodified in non-E hardware. This breaks as soon as you treat FP instructions differently between E and non-E. Fixing it by constraining non-E ISA to behave the same way (sharing int and FP registers) is out of the question (the spec is frozen).

Is there another way to achieve a similar result? 

Guy

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/c7a24001-df3a-bf50-1130-a7123281a416%40gmail.com.

[Bruce Hoult]

I'm pretty sure supporting this has been on the "TODO" list for a long time.

As you say, it's easy to support within a compiler. Use the soft float ABI and register allocation and just emit actual FP instructions instead of calling a library function (and without copying to an FP register first as arch=rv32g abi=ilp32 does)

It can use the same FP instruction encodings as in a standard CPU, but they apply to integer registers instead of float. Some instructions become NOPs.

Of course the code becomes incompatable with CPUs without the "extension" but that's common for most extensions. However! If you do include appropriate FMV instructions and always shadow the same variable in the same-numbered integer and FP registers then the same code could run on both standard and float-in-int-registers processors, although not making full use of all the resources on the standard processor.  

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

[Kito Cheng]

Hi Krste:

Some comment about `ISA Subset Naming Conventions`:

1. Naming rule for prefix Z is not listed in that chapter.
2. Canonical order for Zifencei, Zicsr, Zam, Ztso? It should be listed
in Table 28.1?
3. Should we updater definition of 'G'? it was meaning imafd, it
should be imafd_zifencei_zicsr or other?
4. Meaning of version for G, G2p0 is equal to
I2p0_M2p0_A2p0_F2p0_D2p0, however `I` incremented to 2.1 and `F` and
`D` has incremented to 2.2, perhaps we can change the definition of G
version, let it related to version of unprivileged ISA? e.g. G2p0
meaning I2p0_M2p0_A2p0_F2p0_D2p0 and G2p2 meaning
I2p1_M2p0_A2p0_F2p2_D2p2 ?

>> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

>> To post to this group, send email to isa...@groups.riscv.org.
>> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/c7a24001-df3a-bf50-1130-a7123281a416%40gmail.com.
>
>

> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAP8PnuQ78LfTXeS4M5T%2BGbhFWA9VYkXsKYN90z6yvDNyQDUZEw%40mail.gmail.com.

[Michael Clark]

My POV. I don’t think so.

FENCE.I is only ever be used in inline assembler so it should not impact the compiler with respect to codegen.

Is the same true for CSRs? I can only imagine <fenv.h> is involved here. We don’t yet have any built ins for machine Intrinsics; and compiler flags shouldn’t affect availability of machine intrinsics anyway.

I have a draft about FENCE.I that I have not sent yet as i’m still working on the language (to try to make more concise and moderate out a tendency towards circumlocution).

Yes, ... the ISA extension strings are a little unwieldy when seen in context. They are not yet in device tree. So this is an area that needs more evolution perhaps. There is certainly a need for pages of related extensions, so structuring the data with respect for a base extension makes sense. a RDID instruction perhaps ... i’m sure folk will adapt as the path in this particular area becomes clear (and there is a pressing need for the functionality in question).

[Jim Wilson]

On Tue, Nov 13, 2018 at 10:04 AM 'Michael Clark' via RISC-V ISA Dev
<isa...@groups.riscv.org> wrote:
> FENCE.I is only ever be used in inline assembler so it should not impact the compiler with respect to codegen.

GCC emits fence.i when you have a nested function trampoline on the
stack and the target is not linux. This could instead be a library
call, if we defined an appropriate library interface for that. We
already have a library call for linux, that uses a syscall.

GCC also emits fence for some atomic sequences, but I think that is
something that will eventually be fixed when gcc is updated to handle
atomics as per the memory model.

> Is the same true for CSRs? I can only imagine <fenv.h> is involved here. We don’t yet have any built ins for machine Intrinsics; and compiler flags shouldn’t affect availability of machine intrinsics anyway.

Unordered/quiet fp compares must read/write fflags to avoid
accidentally signalling an exception. GCC also has built-in functions
that let you read/write fflags. fenv.h also reads/writes the entire
fcsr register.

Jim

[Alex Bradbury]

On Tue, 13 Nov 2018 at 18:04, Michael Clark <michae...@mac.com> wrote:
> > On 13/11/2018, at 1:21 AM, Alex Bradbury <a...@asbradbury.org> wrote:
> > I'd also appreciate some guidance on how software is meant to react to
> > moving fence.i and CSR access out of the base ISA. Right now, passing
> > -march=rv32imac to the GNU or LLVM assemblers will support fence.i and
> > the CSR access instructions. Should we be encouraging toolchain users
> > to transition towards -march=rv32imac_zifencei_zicsr?
>
> My POV. I don’t think so.
>
> FENCE.I is only ever be used in inline assembler so it should not impact the compiler with respect to codegen.

But we care about more than just codegen. Which instructions are
rejected or accepted by the inline assembler matters. Same when
invoking the assembler directly.

If we don't encourage users to switch to
-march=rv32imac_zifencei_zicsr (or a newly proposed shortcut),
software toolchain users are no longer using standard ISA strings as
defined in the manual because the toolchain is silently adding extra
options. Or else we do encourage the switch, and maintain the
equivalence between the ISA naming convention used by hardware
designers / IP providers and software implementers + users.

I think this is a more important issue than it might first appear, and
should be resolved as part of the ratification process.

Best,

Alex

[Frank Buss]

Chapter 1.5, "Exceptions, Traps, and Interrupts" is a bit better than the last official release, but I'm still missing a global overview how program flow works. By reading both specs carefully, the user level and privileged spec, I think I understand it now, but it wasn't easy for me. I needed both specs, because e.g. in the user level spec the description for ECALL doesn't say that the mpec register is set to the address of the ECALL instruction, this is only written in the privileged spec, where the ECALL description is mostly duplicated.

For reference, I think this is how it works, if I understood it correctly, and which might be a starting point for a general description:

ECALL: raises and exception:

- CSR register cause is set to 8, environment call

- CSR register mpec is set to the address of the ECALL instruction

- CSR register mtval is set to 0

- PC is loaded with CSR register mtvec

exception, e.g. illegal instruction etc.:

- CSR register cause: depends on the exception

- CSR register mpec is set to the address of the instruction that caused the exception

- CSR register mtval: depends on the exception, e.g. the instruction opcode for illegal instruction, or the target address for misaligned memory access

- PC is loaded with CSR register mtvec

mtime interrupt:

This interrupt is executed before the next normal instruction flow, if the following 3 bits are set:

- the global interrupt enable bit: MIE bit in mstatus register

- the timer interrupt enable bit: MTIE bit in the CSR register mie

- the timer interrupt pending bit: MTIP bit in the CSR register mip

The MTIP bit is set, whenever the CSR register mtimecmp is equal or greater than the CSR register mtime. When the IRQ is raised, the MIE bit is cleared, otherwise the interrupt would be raised in an infinite loop, because it is level triggered, not edge triggered. The MTIP is cleared, when writing to the CSR register mtimecmp. So in the interrupt routine, you have to first write to mtimecmp to clear the MTIP bit, otherwise the interrupt would be raised again after setting the MIE bit and leaving the interrupt. And after this, you have to set the MIE bit again, to re-enable global interrupts.

This happens when a timer interrupt is raised:

- CSR register cause: bit 31 is set to 1, to indicate an interrupt, bits 30 to 0 is set to 7, to indicate a machine timer interrupt. In case you are wondering why "7": Because the machine timer interrupt is signaled with bit 7, MTIP, in the mip register, if I understand this correctly.

- CSR register mpec is set to the address of the instruction that is going to be executed on interrupt exit. Note the difference compared to the previous ECALL and exception cases.

- CSR register mtval = 0

- MIE bit of CSR register status is cleared

- PC = CSR register mtvec

I didn't write all the details about the privileges and the additional complications with PLIC and vectored interrupts, just a first overview (enough for a working RISCV contest implementation of RV32I). Don't know if the spec would be the right place for it, maybe another document with examples would be nice. And it doesn't help, that there is a bit named "MIE", and a CSR register named "mie".

[kr...@berkeley.edu]

It is deliberate decision that the unprivileged manual does not go
into the mechanics of how a given privileged architecture takes a trap
when an exception is raised, so that the unprivileged ISA can be used
with a different privileged architecture.

But I agree that the privileged architecture could use more
explanatory material on how the current privileged architecture works
(and on many other matters). The RISC-V Reader has some text on this.

Krste

| --
| You received this message because you are subscribed to the Google Groups
| "RISC-V ISA Dev" group.
| To unsubscribe from this group and stop receiving emails from it, send an email
| to isa-dev+u...@groups.riscv.org.
| To post to this group, send email to isa...@groups.riscv.org.
| Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/
| .
| To view this discussion on the web visit https://groups.google.com/a/
| groups.riscv.org/d/msgid/isa-dev/

| 1bd43e4a-8376-427a-b296-cb42bacb2f93%40groups.riscv.org.

[Mark Hill]

On a related topic, there are no references to WFI in the unprivileged spec but the privileged spec says:

WFI is available in all of the supported S and M privilege modes, and optionally
available to U-mode for implementations that support U-mode interrupts. This instruction may
raise an illegal instruction exception when TW=1 in mstatus, as described in Section 3.1.10.

For consistency I think the WFI instruction should be mentioned in the N-extension description in the unprivileged spec (with a statement that WFI will cause an illegal instruction exception if N-extension is not supported).

Also the description of mstatus.tw needs updating to include the possibility of U-mode WFI support:

The TW (Timeout Wait) bit supports intercepting the WFI instruction (see Section 3.2.3). When
TW=0, the WFI instruction is permitted in S-mode. When TW=1, if WFI is executed in Smode,
and it does not complete within an implementation-specific, bounded time limit, the WFI
instruction causes an illegal instruction trap. The time limit may always be 0, in which case WFI
always causes an illegal instruction trap in S-mode when TW=1. TW is hard-wired to 0 when
S-mode is not supported.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/23537.57270.661820.212425%40KAiMac.local.

[Frank Buss]

On Sunday, November 18, 2018 at 10:55:08 PM UTC+1, krste wrote:

It is deliberate decision that the unprivileged manual does not go
into the mechanics of how a given privileged architecture takes a trap
when an exception is raised, so that the unprivileged ISA can be used
with a different privileged architecture.

I think then it shouldn't be at all in the unprivileged manual, at least not in chapter 2, which describes only RV32I. For example for instruction WFI it is right, this is only explained in the privileged manual, because it doesn't make sense without a concrete privileged architecture with interrupts. And the ricsv-compliance test for RV32I has to be changed as well and shouldn't test ECALL, because the implementation can change with different privileged environments.

The RISC-V Reader has some text on this.

Looks like a useful book. I don't mind buying it, but is there an e-book version of it? Always cumbersome to carry dead trees when I'm on the way.

[Liviu Ionescu]

> On Sunday, November 18, 2018 at 10:55:08 PM UTC+1, krste wrote:

> It is deliberate decision that the unprivileged manual does not go into the mechanics of how a given privileged architecture takes a trap when an exception is raised, so that the unprivileged ISA can be used with a different privileged architecture.

that's great!

> On 19 Nov 2018, at 13:53, Mark Hill <mark...@huawei.com> wrote:

> WFI... I think then it shouldn't be at all in the unprivileged manual

I think that WFI is a great power management feature that benefit from a generic definition, with a common encoding for all profiles; in principle suspending the current hart until an interrupt is triggered is independent on any privileged architecture; the details may not be, but the general picture is.

in RTOSes, WFI is commonly used in the Idle task, which is basically a forever loop; functionality is the same, just that with WFI the power consumption is lower.

from a microcontroller profile point of view, which has nothing to do with the current privileged specs, it would be better to have the WFI defined in the basic ISA, with the provision that devices which are not interested in low power features may implement it a simple NOP.

as a general remark, please do not assume that the 'unprivileged specs' (poor name choice) are always matched with the current unix profile, they may be matched with a profile that has nothing to do with any of the known privileged modes (M/S/U...).


regards,

Liviu

[kr...@berkeley.edu]

>>>>> On Mon, 19 Nov 2018 04:24:20 -0800 (PST), Frank Buss <programmer...@gmail.com> said:

| On Sunday, November 18, 2018 at 10:55:08 PM UTC+1, krste wrote:
| It is deliberate decision that the unprivileged manual does not go
| into the mechanics of how a given privileged architecture takes a trap
| when an exception is raised, so that the unprivileged ISA can be used
| with a different privileged architecture.

| I think then it shouldn't be at all in the unprivileged manual, at least not in
| chapter 2, which describes only RV32I. For example for instruction WFI it is
| right, this is only explained in the privileged manual, because it doesn't make
| sense without a concrete privileged architecture with interrupts. And the
| ricsv-compliance test for RV32I has to be changed as well and shouldn't test
| ECALL, because the implementation can change with different privileged
| environments.

ECALL is part of mandatory user ISA. The model is that unprivileged
implementations have to provide ECALL and it has to cause a precise
Requested Trap to outer execution environment. The actual
implementation of the EE can vary and have different privileged
architectures, but has to be able to report the precise PC and reason
for the trap somehow.

| The RISC-V Reader has some text on this.

| Looks like a useful book. I don't mind buying it, but is there an e-book
| version of it? Always cumbersome to carry dead trees when I'm on the way.

I thought so, but can't find on quick check.

Krste

| --
| You received this message because you are subscribed to the Google Groups
| "RISC-V ISA Dev" group.
| To unsubscribe from this group and stop receiving emails from it, send an email
| to isa-dev+u...@groups.riscv.org.
| To post to this group, send email to isa...@groups.riscv.org.
| Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/
| .
| To view this discussion on the web visit https://groups.google.com/a/
| groups.riscv.org/d/msgid/isa-dev/

| 867f2cd6-cbb1-4807-9ace-59fd79671dc0%40groups.riscv.org.

[Dmitri Pavlov]

среда, 7 ноября 2018 г., 6:44:39 UTC+3 пользователь krste написал:

We're going to start the public review period of the RISC-V base ISA
and standard extensions.  The review period ends December 21, 2018.

Dear all, we would like to re-iterate on the important, in our opinion, issue/omissions of the current spec and propose potential fix.

 

Copy operations between FPR and GPR are only defined for cases when XLEN >=FLEN. Therefore, the architectures with XLEN<FLEN do not have them, including very, in our opinion, practical RV32FD and RV64Q. In a sense, this makes copy operations asymmetrical and ISA inconsistent because a bit pattern cannot be copied from the one register file to another.

This issue had been briefly discussed before, but without acceptable resolution. We still believe this would be highly beneficial to address this drawback due to the following reasons:
1. There is currently no standard way to access to FPU registers from Debug module, except Load/Store instructions through the memory. This will require to reserve some memory for debug purpose which is limit to use standard debug module (in accordance with the debug spec, the debug memory is optional)
2. In some cases, through-memory-only FP loads and stores can become a critical drawback, some examples:

- The memory subsystem is not initialized yet (BIST during system boot)

- The memory reservation for the system debug may conflicts with the system memory map

- The load/store operations will change memory subsystem states: TLB, Caches may be changed during debug session

3. Additionally, FPU register file provides fast storage with a significant capacity which in many cases can be used to decrease pressure on general purpose registers (plus the opposite).
4. The current RISC-V Instruction Set Manual says: “the marginal hardware cost of moving from a 32-bit to a 64-bit integer datapath is low”(Section 12.5). We respectfully disagree, - the move from XLEN 32 to 64 considerably grows integer pipeline, control logic and execution units. We are estimating the increase area for practical implementations to be from about 40-50kG. The processing of the 32-bits data on the 64-bit machine also increases the code size: the compiler have to add extra instructions to control upper parts of the registers like sign extension or zero padding. For example, for the Coremark the 7.1 compiler increases execution code up to 20%.

We maintain RV32FD architectures are practical and useful, specifically in the embedded domain, where 64-bits addressing mode are often an overhead feature, but computations require a double float point precision.

Our proposal for discussion/inclusion in the spec:

1. moving the double-precision value from the floating-point register to integer registers:

We propose to read FPR by two instructions:
1. The currently existing instruction FMV.X.W copies less significant bits (LSB) of D register
2. Reuse opcode of FMV.X.D instruction for RV32 to copy the most significant bits (MSB) of register D
This approach provides generic mechanism and enables unified FPR access (mstatus.FS):

| funct7     |  rs2    |  rs1  | funct3 |  rd  | opcode  |
| 1110001 | 00000 |  rs1  |  000   |  rd  | 1010011 | FMV.X.D for RV64D
| 1110001 | 00000 |  rs1  |  000   |  rd  | 1010011 | FMVH.X.W for RV32D (new)

2. moving the double-precision value from integer registers to floating-point register

We propose to write FPR by a single instruction concatenating values of two X registers.
Instruction FMV.D.X has unused rs2 field (always equal to 0), which can be used to store the second integer operand.
| funct7    |  rs2     |  rs1  | funct3 |  rd  | opcode  |
| 1111001 | 00000 |  rs1  |  000   |  rd  | 1010011 | FMV.D.X for RV64D
| 1111001 |  rs2     |  rs1  |  000   |  rd  | 1010011 | FMV.D.X for RV32D (new)

Where
rs1 contains 32 MSB of FRD register,
rs2 contains 32 LSB of FRD register.
The result of "fmv.d.x  frd,rs1,rs2"  is frd = {rs1, rs2};

The same approach can also be applied to RV64Q.

 

We would like to put this proposal for discussion and potential inclusion in the coming 2.3 spec.

 

Correspondent pull request to spec#301 is published. 

[Luke Kenneth Casson Leighton]

On Mon, Dec 10, 2018 at 8:57 AM Dmitri Pavlov
<dmitri.pa...@gmail.com> wrote:
> Our proposal for discussion/inclusion in the spec:
>
> 1. moving the double-precision value from the floating-point register to integer registers:
>
> We propose to read FPR by two instructions:
> 1. The currently existing instruction FMV.X.W copies less significant bits (LSB) of D register

ok, so... where, ordinarily, this would be utilised to move a
*single-precision* 32-bit FP number from the 32-bit integer register
into the requested FP register, what you propose is that, *without*
modifications to the instruction (or even to pre-existing hardware
that is currently compliant with the current specification), the exact
same instruction be utilised, except the data being moved from the
32-bit integer register just happens to be the bottom 32-bits of a
double-precision FP number.

the key to this succeeding is that the data being transferred *must
not be modified*. from a discussion a few weeks ago, i believe it was
noted that there is a discrepancy here in the specification.

however, *unfortunately*, it looks like there's been some
modifications, since, as i have a vague recollection of raising the
discrepancy that FLD/FST did not require preservation of their
payloads (which would be extremely useful for unconventional use such
as memcpy without touching the *integer* register file). that seems
to have been fixed [can anyone confirm this? i can't recall the
details]

... however the section 12.2 of v20181221-public-review-draft says
that a *previous* version required "preservation of the value of a
narrower operand", and now it says "a narrower n-bit transfer, n <
FLEN, into the f registers will create a valid NaN-boxed value". more
on this below...

> 2. Reuse opcode of FMV.X.D instruction for RV32 to copy the most significant bits (MSB) of register D

so, let's assume compliance with the current spec: NaN-boxing is
basically, you sign-extend the upper bits of the value (which, if
using FMV.X.W as proposed contains the LSBs of a double-word, so the
sign-extension is likely to be garbage, but that's ok). then, because
you are now writing the *upper* bits, that sign-extension is now
overwritten.

basically, as long as it is done in this order (FMV.X.W FMV.X.D) i
think it will work. the other way round, it's going to fail.

damn i can't recall the exact details of the discrepancy i noted.
was it that F.MV.X.W (section 11.7) does not explicitly state that the
payload must be preserved unmodified? whilst FMV.W.X says that the
"bits are not modified", F.MV.X.W does *not* likewise specifically and
explicitly state, "the bits are not modified".

i think that's it. that's the bit - in section 11.7 - where, if it is
not explicitly made clear that the bits must not be modified, the
proposed scheme, dmitri, will fail. and, also, the idea of using the
FP regs for a memcpy will also fail. and, also, the use of FMV.X.W
for JIT compilers will also fail.

i have a vague recollection of someone mentioning that it is standard
practice for javascript JIT compilers to use non-canonical NaNs,
meaning that if FMV.X.W were permitted (through lack of clarity on
this point) to modify the payload, certain hardware will inexplicably
fail on JIT execution and others will not.

l.

[Jacob Lifshay]

On Mon, Dec 10, 2018 at 1:43 AM Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:

 so, let's assume compliance with the current spec: NaN-boxing is
basically, you sign-extend the upper bits of the value (which, if
using FMV.X.W as proposed contains the LSBs of a double-word, so the
sign-extension is likely to be garbage, but that's ok).  then, because
you are now writing the *upper* bits, that sign-extension is now
overwritten.

NaN-boxing is ones-extension (like zero-extension except the new bits are all ones), not sign extension.

So, C++14 code to do the conversion is:

uint64_t dest; // really double

uint32_t src; // really float

dest = src | 0xFFFF'FFFF'0000'0000ULL;

Jacob Lifshay

[Dmitri Pavlov]

Dear Luke,

After reviewing your comments (thank you for taking time to review, btw), I have impression you may be not understanding it correctly.

Maybe it would help if you review the related specification patch – available here:
https://github.com/riscv/riscv-isa-manual/pull/301/commits/8f684f2fdd346deb88270b57ff5ed1fee904fd50

BR, Dmitri

-----Original Message-----
From: Luke Kenneth Casson Leighton [mailto:lk...@lkcl.net]
Sent: Monday, December 10, 2018 12:43 PM
To: dmitri.pa...@gmail.com
Cc: RISC-V ISA Dev <isa...@groups.riscv.org>; base...@workspace.riscv.org; compl...@workspace.riscv.org

[Luke Kenneth Casson Leighton]

On Wed, Dec 12, 2018 at 7:40 PM Dmitri Pavlov
<dmitri.pa...@gmail.com> wrote:

> Dear Luke,
>
> After reviewing your comments (thank you for taking time to review, btw),

no problem. i like the idea.

> I have impression you may be not understanding it correctly.

possibly :)

the main point is: whilst the idea is good, i feel that there is a
prior issue with the spec which critically requires fixing *before*
this proposal should be considered, namely that there is a lack of
clarity on whether FMV.X.W *must* preserve intact without modification
the bottom 32 bits of the integer payload or whether implementations
are *permitted* to MODIFY the 32-bit single-precision number by
performing (unnecessary) NaN normalisation.

> Maybe it would help if you review the related specification patch – available here:
> https://github.com/riscv/riscv-isa-manual/pull/301/commits/8f684f2fdd346deb88270b57ff5ed1fee904fd50

hmmmm.... it removes the earlier (historical) commentary, which
probably needs discussion.

also, as i mentioned, the order of the instructions is critically
important. it *has* to be FMV.X.W {\em rdl, fs1} followed by FMVH.X.W
{\em rdh, fs1} (FMVH.X.W being an rv32-only alias for FMV.X.D) *not*
the other way round.

why?

because FMV.X.W will always, and must always, do 32-to-64-bit NaN boxing.

why?

because you simply do not know if the following instruction will be a
FMVH.X.W (aka rv32-only FMV.X.D) or not.

why does that matter?

because not all systems will have macro-op fusion.

so as stated in the proposed spec:

* FMVH.X.W: writes the 32-bit INT to the top bits 63..32 of the 64-bit FP number

* FMV.X.W: writes the 32-bit INT to the *BOTTOM* bits 31..0 of the 64
bit FP number *AND DESTROYS THE TOP 32 BITS with NaN boxing*

therefore, the order of usage *has* to be the other way round.

l.

[lkcl]

Dmitri I apologise for not following up to ensure that the reasoning that I gave was clear and fully understood.

To illustrate clearly, may I propose the following software emulation strategy:

* using an UNMODIFIED current version of spike, implement a software trap emulation of the proposed new instruction, in RV32 mode, placing the 32 bits into the HI word of the 64 bit FP number. This to be written as actual RISCV software, *NOT* by modifying or augmenting spike in any way. The trap may have to switch temporarily to RV64 Mode in order to be able to write to the top 32 bits of the register

* now call the two instructions, in RV32 mode, in the order in which you originally propose.

* note that the standard single precision FMV will DESTROY the top 32 bits by smashing NAN boxing 1s over it.

* now call the two instructions the other way round.

* note that whilst the standard single precision FMV also overwrites the top 32 bits with 1s, the following instruction (the new, emulated one) CORRECTLY overwrites the top 32 bits with the correct data, leaving the 64 bit result intact.

Is that now clear why the order has to be the other way round?

On a side note I did not receive a response regarding the ambiguity surrounding FMV. Has this been noted and taken care of?

L.

[Andrew Waterman]

The sentence that says "the bits are not modified" is meant to apply to both instructions in the paragraph.  But I can see how you interpreted the sentence as only applying to FMV.W.X.  We'll change it to be crystal clear that it applies to both instructions.

 

L.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/c3acc909-3bba-414f-aa62-e1a0f324e4d4%40groups.riscv.org.

[Andrew Waterman]

On Fri, Jan 18, 2019 at 10:38 AM Andrew Waterman <wate...@eecs.berkeley.edu> wrote:

On Fri, Jan 18, 2019 at 4:54 AM lkcl <luke.l...@gmail.com> wrote:

Dmitri I apologise for not following up to ensure that the reasoning that I gave was clear and fully understood.

To illustrate clearly, may I propose the following software emulation strategy:

* using an UNMODIFIED current version of spike, implement a software trap emulation of the proposed new instruction, in RV32 mode, placing the 32 bits into the HI word of the 64 bit FP number. This to be written as actual RISCV software, *NOT* by modifying or augmenting spike in any way. The trap may have to switch temporarily to RV64 Mode in order to be able to write to the top 32 bits of the register 

* now call the two instructions, in RV32 mode, in the order in which you originally propose.

* note that the standard single precision FMV will DESTROY the top 32 bits by smashing NAN boxing 1s over it.

* now call the two instructions the other way round.

* note that whilst the standard single precision FMV also overwrites the top 32 bits with 1s, the following instruction (the new, emulated one) CORRECTLY overwrites the top 32 bits with the correct data, leaving the 64 bit result intact.

Is that now clear why the order has to be the other way round?

On a side note I did not receive a response regarding the ambiguity surrounding FMV. Has this been noted and taken care of?

The sentence that says "the bits are not modified" is meant to apply to both instructions in the paragraph.  But I can see how you interpreted the sentence as only applying to FMV.W.X.  We'll change it to be crystal clear that it applies to both instructions.

Just realized I was looking at v2.2 of the spec, where the two instructions were described in the same paragraph.  Post-v2.2, the paragraph was split in two, but the crucial sentence wasn't duplicated.  So, it looks like an editing error.

[lkcl]

On Saturday, January 19, 2019, Andrew Waterman <wate...@eecs.berkeley.edu> wrote:

On a side note I did not receive a response regarding the ambiguity surrounding FMV. Has this been noted and taken care of? 

The sentence that says "the bits are not modified" is meant to apply to both instructions in the paragraph.  But I can see how you interpreted the sentence as only applying to FMV.W.X.  We'll change it to be crystal clear that it applies to both instructions.

Just realized I was looking at v2.2 of the spec, where the two instructions were described in the same paragraph.  Post-v2.2, the paragraph was split in two, but the crucial sentence wasn't duplicated.  So, it looks like an editing error.

 

Cool. Will git pull and take a look tomorrow. The only thing, have to hope that (in a frozen spec) no implementor assumed it was ok to modify (normalise) the dest result.

L. 

[lkcl]

On Wednesday, December 12, 2018 at 7:40:52 PM UTC, Dmitri Pavlov wrote:

Dear Luke,

After reviewing your comments (thank you for taking time to review, btw), I have impression you may be not understanding it correctly.

dmitri, hi,

with many apologies for taking so long to find the source of the confusion.  please see:

https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/LK0CLNXRtg0/NotCzJDnDwAJ

i *thought* you were proposing a FMVH.X.W, where my concerns were about the *opposite* conversion, FMVH.W.X.

which begs the really obvious question: why isn't FMVH.W.X part of the same proposal?  see link above for details.

also could someone please post the above link (and one to this discussion) on the github bugtracker, https://github.com/riscv/riscv-isa-manual/pull/301 which i cannot do because it would be total hypocrisy for a team that is funded under the NLNet "Enhanced Privacy" Programme (https://nlnet.nl/PET/) to use a proprietary service that's tracking and monetising its users (github).  a solution to that is proposed here: https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/LK0CLNXRtg0/3L_9LM8bEAAJ

l.