should loads to reg 0 actually do the load? (but not write a reg)?

[cinco...@gmail.com]

since doing the load has visible side-effects, this behavior matters. i couldn't find a reference.

[Allen Baum]

Unpriv spec: 2.6 Load and Store Instructions

RV32I is a load-store architecture, where only load and store instructions access memory and arithmetic instructions only operate on CPU registers.
RV32I provides a 32-bit address space that is byte-addressed.
The EEI will define what portions of the address space are legal to access with which instructions (e.g., some addresses might be read only, or support word access only).
Loads with a destination of x0 must still raise any exceptions and cause any other side effects even though the load value is discarded. 

On Mon, Jan 17, 2022 at 10:09 AM cinco...@gmail.com <cinco...@gmail.com> wrote:

since doing the load has visible side-effects, this behavior matters. i couldn't find a reference.

--
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 view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/4e981a1c-c235-4dd9-829e-54f7edc25ba6n%40groups.riscv.org.

[MitchAlsup]

In addition to Allen's argument:

In the Mc 88100, we actually did perform the load--AGEN--Cache--LD-Align

But, the R0 register was not allowed to be busy in the pipeline-sense of waiting for a result, and so, it was available to be written by the very next instruction without taking a pipeline delay of waiting for the LD to play out through the pipeline. In effect, a LD R0,[whatever] was a prefetch instruction, and R0 was still 0x0 to the very next instruction and without delay.

[Rishiyur Nikhil]

>    In effect, a LD R0,[whatever] was a prefetch instruction, and R0 was still 0x0 to the very next instruction and without delay.

Or, to put it another way, R0 can always be safely predicted to return 0 on a register read.

Nikhil

--

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 view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5e33f2c7-e5dc-4eb9-af16-2071a9caf40en%40groups.riscv.org.

[MitchAlsup]

On Saturday, January 22, 2022 at 5:13:40 PM UTC-6 nikhil wrote:

>    In effect, a LD R0,[whatever] was a prefetch instruction, and R0 was still 0x0 to the very next instruction and without delay.

Or, to put it another way, R0 can always be safely predicted to return 0 on a register read.

Nikhil

In the Mc 88100 we had a 32-bit vector of busy registers--rather than a pipeline-length vector of register comparators, and we used the same register file decoders to access the bit vector.

R0 was hardwired as a zero in both the register file and in the vector of busy registers but the cell area for the bits were the same as if the cell was a typical register, including the write select lines--these attached to nothing, and the cell would only produce a 0.

[Simon Jackson]

1. Maybe the reg could be side-effected in some algorithms such as random.

2. In days of old sub r0, r0 was a good zero r0, and even xor r0, r0 could have been said to be slightly more efficient in ALU carry non-usage. Never got why such a zero is necessary.

[Bruce Hoult]

Because there is a huge difference between being able to make a zero on demand, and being able to always simply assume that one is already there.

For the cost of  having "only" 31 registers instead of 32 (0.046 bits) -- and plenty of ISAs get away with only 16 or even 8 registers -- you get a large number of useful instructions for free, as special cases of other instructions, without having to reserve opcodes for them.

nop, li, mv, neg

snez, sltz, sgtz

beqz, bnez, blez, bgez, bltz, bgtz

j, jr, ret

csrr, csrw, csrs, csrc, csrwi, csrsi, csrci

--

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 view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0061d075-95ce-47b8-8fcc-0371fa50f9a5n%40groups.riscv.org.

[Philipp Tomsich]

POWER/PowerPC got away with a slightly lower cost than those 0.046
bits, as (depending on the instruction and operand) r0 will either
denote zero or register 0.
However, that came at the cost of a more irregular architecture (e.g.
there you could not perform an add-immediate with the register-value
of r0 as an operand — and an isel could not have r0 as its RA
operand).
And of course, their conditional branches use a condition-code register.

One could thus say that RISC-V gave up the ability to encode a 32nd
GPR in favor of a more regular ISA.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAMU%2BEky-e0755n%3Dzcg8%2BGZ%3DcjyfVgeYYYF9kgDPeRE4Yx8p4DQ%40mail.gmail.com.

[MitchAlsup]

Note: this is not really RISC-V relevant other than illustrating a different way to do things;

Nor is it a complaint in any form about how RISC_V got to where it is today::

On Friday, July 8, 2022 at 8:26:28 AM UTC-5 Bruce Hoult wrote:

Because there is a huge difference between being able to make a zero on demand, and being able to always simply assume that one is already there.

My 66000 ISA is RISC but does not have R0 hardwired to zero. Instead the ISA provides a means whereby exclusive either operand in a 2-operand instruction can be supplied a constant from the instruction stream. values in the range -16..+15 can be denoted within the 32-bit instruction. Thus, zero is available without blowing a register to contain zero.

But R0 still remains "special" in that it receives the return address upon a CALL, and when used as the base register in a memory reference R0 implies IP relative addressing, and when used as an index register it implies no indexing--[Rbase+Rindex<<scale+Displacement] is available in the encoding.

For the cost of  having "only" 31 registers instead of 32 (0.046 bits) -- and plenty of ISAs get away with only 16 or even 8 registers -- you get a large number of useful instructions for free, as special cases of other instructions, without having to reserve opcodes for them.

nop, li, mv, neg

snez, sltz, sgtz

beqz, bnez, blez, bgez, bltz, bgtz

j, jr, ret

csrr, csrw, csrs, csrc, csrwi, csrsi, csrci

While the above is true; My 66000 ISA gets rid of the need for many of those by allowing sign control as part of the instruction encoding::

MUL    Rd,Rs1,-Rs2

AND    Rd,~Rs1,~RS2

while providing immediates as either operand

DIV     Rd,0x1234567891011,Rs2

ST      0x3,[Rbase+Rindex<<scale]

FMAC Rd,Rs1,3.14159265358,Rs3

[Allen Baum]

This is not the first time it has been suggested that R0 just be a regular register, and have it loaded with zero if you want to use it that way.

That ship has sailed

It might be interesting in hindsight, but otherwise only really interesting if you want to go off and design something that 

isn't RISC-V compatible and won't run RISC-V binaries (e.g. Mitch's 66000). 

If you want to build a part with a mode for that, feel free to implement a custom extension; that's a beauty of an open, extensible architecture.

Then you can build the tools, recompile the firmware, OSes, drivers and apps, and measure what difference it makes in terms of program siz, dynamically executed instructions, etc., and get a conference paper out of it.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/546c9458-7bb0-410f-97e2-23802c4e317fn%40groups.riscv.org.

[Bruce Hoult]

Not quite equivalent because a good number of the pseudo-ops I listed depend not on r0 containing 0, but on writes to r0 being discarded.

AVR does the "r0 is a normal register but happens to always contain 0" thing. Except that (IIRC) a multiply writes some of the result there, so you then have to clear it again!

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DBmufrOLaKuUvtPOuDQ1dw%3D9__GiE7%3DOb%2BMWH-uxJAXwg%40mail.gmail.com.

[BGB]

On 7/9/2022 12:44 AM, Bruce Hoult wrote:
> Not quite equivalent because a good number of the pseudo-ops I listed
> depend not on r0 containing 0, but on writes to r0 being discarded.
>
> AVR does the "r0 is a normal register but happens to always contain 0"
> thing. Except that (IIRC) a multiply writes some of the result there, so
> you then have to clear it again!
>

Yeah. Changing the behavior of X0 seems like one of those "if you change
it, you break the ISA" things...


I guess I will note that I have an ISA where R0 and R1 are both used as
special registers in the encoding *and* can also hold values (with the
interpretation of these registers depending mostly on instruction type
and context). Whether or not this is a sane idea or not can be debated.

But, there is no dedicated zero register in this case, and in some cases
a dedicated zero register could have made sense. But, I am at the point
now that I am probably not going to change major parts of the design
without a compelling reason.

Well, and also I have added RISC-V (~ RV64IM, *1) essentially as an
"alternate mode", but it is pros/cons if comparing them.

( Will probably refrain from going into compare/contrast here. )


*1: Basically, the way my core worked internally, and the feature-set of
RV64I, were close enough that I was able to add an RV64I decoder onto
the existing pipeline with fairly minimal modification. But, things
diverge pretty quickly much past this point. Didn't initially plan to
have 'M', but then I went and a 64-bit MUL/DIV unit which could be used
to support 'M', ...

Haven't yet ran any "actual software" in this mode yet, more work is
still needed on this front (had originally hoped to use inter-ISA
thunking; but at this point it looks more likely that the software will
need to be able to self-host without the use of inter-ISA thunks, or at
least, they are used sparingly).

> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0061d075-95ce-47b8-8fcc-0371fa50f9a5n%40groups.riscv.org?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:isa-dev+u...@groups.riscv.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/546c9458-7bb0-410f-97e2-23802c4e317fn%40groups.riscv.org
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/546c9458-7bb0-410f-97e2-23802c4e317fn%40groups.riscv.org?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:isa-dev+u...@groups.riscv.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DBmufrOLaKuUvtPOuDQ1dw%3D9__GiE7%3DOb%2BMWH-uxJAXwg%40mail.gmail.com
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DBmufrOLaKuUvtPOuDQ1dw%3D9__GiE7%3DOb%2BMWH-uxJAXwg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:isa-dev+u...@groups.riscv.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAMU%2BEkzpzuxAeZoWtyrzJ%3DwBpLMMQjh8RqeZaFXn2cAJ2t%3DNtA%40mail.gmail.com
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAMU%2BEkzpzuxAeZoWtyrzJ%3DwBpLMMQjh8RqeZaFXn2cAJ2t%3DNtA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Allen Baum]

So, you're not adding a custom extension to RV, you're adding RV as a custom extension....

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/64988ef0-5d57-edd4-6669-396db6c29b26%40gmail.com.

[BGB]

On 7/10/2022 11:22 PM, Allen Baum wrote:
> So, you're not adding a custom extension to RV, you're adding RV as a
> custom extension....
>

Yes, essentially...


In my case, I have a core running an ISA that I created myself (approx 5
years thus far); but I figured there were use-cases where it might make
sense to be able to run RV code as well.

In terms of core functionality, the functional units could deal with
either ISA, so it was mostly a thing of having a different operating
mode, and RV decoder.

RISC-V could still make more sense as a "general purpose" ISA.
However, supporting it "well" without increasing CPU core costs too much
is harder.



The ISAs are in a slightly different category:
RISC-V is a RISC with 31 GPRs, ...
My ISA is, effectively, a VLIW.

My ISA (Currently named BJX2, *) is:
Is a VLIW with 32 or 64 GPRs (R32..R63 being an extension).
Mostly still uses 5-bit register fields.
R32..R63 were just sorta awkwardly hacked on as an optional feature.
It is designed to run up to 3 instructions per clock-cycle.
Bundles consist of 1x to 3x 32-bit instruction words.
It is vaguely similar in concept to the TMS320 in this area.
Uses a 6R3W register file (divided up based on bundle format).
It supports 16-bit instructions (for size-optimized cases).
However, 16-bit instructions can't be used in VLIW bundles.
It also supports 64 and 96 bit instructions
It supports 33 and 64 bit immediate values with these forms.
Encoded as a special-case of the VLIW bundle format.
Base ISA is 64-bit, with some 128-bit operations.
128-bit operations limited to 1 operation per cycle.
Uses paired GPRs for 128-bit types.
128-bit ops often used treat the 64x 64b GPRs as 32x 128-bit.
This allows them to still use a 5-bit register field.
Works OK if R32..R63 are mostly used for 128b SIMD.
These ops treat the register file as logical 3R1W.
Uses a single unified register file for everything:
FPU and SIMD also use the GPR file.
Nominally uses a 48-bit virtual address space.
There is another extension that expands this to 96 bits.
64b pointers give low 48-bits of address within the 96-bit space.
Conceptually similar to WDC65C816 style addressing.
High 16-bits of pointers used as type-tag bits or similar.
PC/LR: Used to capture/restore operating-mode bits.

*: TODO: Need to rename to something else eventually (turns out this
acronym was already in use in an unfortunate way).

Well, some ISA spec links (if curious):
https://github.com/cr88192/bgbtech_btsr1arch/blob/master/docs/2020-04-30_BJX2D.txt
https://github.com/cr88192/bgbtech_btsr1arch/blob/master/docs/2020-04-30_BJX2_IsaDescD.txt


Besides bundling, it also has predicated instructions (so small "if()"
branches don't need to use an actual branch).

I still have not solved "the compiler problem", so what I can get from
my C compiler is arguably still "not very good" (still pretty weak at
bundling instructions).


I am generally targeting Spartan-7 and Artix-7 FPGAs (was mostly testing
on an XC7A100T, via the Nexys A7 board), generally running the CPU core
at 50MHz.

For a few software ports:
Doom is around 15 to 25 fps typically;
Quake is often around 4 to 8 fps (C based software renderer).
GLQuake is often around 5 to 12 fps at present (320x200).
Custom software OpenGL rasterizer, partially written in ASM.
...

It deals reasonably well with workloads that have a large number of
variables and/or unrolled loops and similar. Code with "small tight
loops" generally performs poorly.


Regarding the core integer ISA, my ISA is functionally mostly a superset
of RV64IM.

One minor area where RV64IM sometimes has an advantage, is that it has
12-bit immediate and displacement fields, whereas my ISA uses 9-bit fields.

Though, my ISA takes less of a hit from "overflowing" the immediate or
displacement field, partly as it can then fall back to a 64-bit encoding
(Imm33/Disp33).

Well, and my ISA can encode a 64-bit constant load in 96-bits, as a 1
clock cycle operation.

Though, OTOH, when building it for my ISA, the Dhrystone score still
kinda sucks... (Also, partly, GCC's code generation is in some ways
"somewhat less awful" than what my compiler generates).


Much outside of RV64IM, things quickly diverge, as my FPU, MMU, SIMD,
etc, are almost entirely different (well beyond what I can easily gloss
over in the instruction decoder; or otherwise support "cheaply").

Ironically, in a lot of these areas, my ISA tends to be a lot more
minimalist.

A few differences:
Addressing Modes:
(Rb, Disp) (Direct Displacement)
(Rb, Ri) (Register Indexed)
Rb: R0=PC, R1=GBR, R15=SP, R2..R63: Normal Register
Ri: R0=R0, R1=R0(Byte), R2..R63: Normal Index
Scale: Element Size unless Rb=PC|GBR (Byte)
(Rb, Ri<<Sc, Disp) (Optional Extension, 64-bit encoding)
FPU Scalar ops only do Binary64;
Binary32 only exists via SIMD ops and similar.
The set of FPU operations is fairly limited.
FADD/FSUB/FMUL, Convert, Compare
Using GPRs allowed making the FPU cheaper.
MMU:
Uses a software-managed TLB
TLB misses trigger an interrupt to load PTE from page-table, ...
Interrupt: Cheap; Page Table Walker: Not Cheap.
Interrupt mechanism is a bit different:
Copy a few registers, twiddle some bits, and do a computed branch;
ISR manually saves/restores all registers to the stack or similar;
Basically, the cheapest option I could come up with...
Banked registers or similar would have added cost.
SIMD:
Types:
2x|4x Binary32
4x Binary16
2x|4x Int32
4x Int16
Vaguely similar to SSE or similar, just using GPRs
Skips Packed-Byte, Saturation, ..., mostly for cost reasons.
Mechanisms exist to fake some of this as-needed.
Reuses ALU ops frequently.
Doesn't bother with SIMD ops for what can be done via the ALU.
...



I was mostly trying to avoid flogging off my own stuff on here, as it
doesn't seem particularly relevant.

I had mostly imagined it for possible embedded style use-cases, and also
because I had realized pretty early on that I could fit something
"somewhat bigger" that a simple RISC style ISA onto something like an
XC7S50 or XC7A100T.

Have experimented with putting it on smaller FPGAs (eg: XC7S25 and
XC7A35T), but it "doesn't really make sense" for these FPGAs (even if
one can sort of awkwardly shoe-horn it in).


Decided to leave out stuff about why I went with a 3-wide pipeline and
what sorts of combinations of instructions are allowed within the
pipeline lanes and similar, as this seems a bit outside the scope of
what is relevant here...


While it could potentially be compared with something like the Itanium,
it is, IMHO, nowhere near as expensive to implement, nor anywhere near
as bad on the code-density front (typically smaller than x86-64 builds).

...

> > <mailto:allen...@esperantotech.com

> <mailto:isa...@groups.riscv.org <mailto:isa...@groups.riscv.org>>>

> >             <jacko...@gmail.com <mailto:jacko...@gmail.com>> wrote:
> >
> >                 1. Maybe the reg could be side-effected in some
> >                 algorithms such as random.
> >                 2. In days of old sub r0, r0 was a good zero r0, and
> >                 even xor r0, r0 could have been said to be
> slightly more
> >                 efficient in ALU carry non-usage. Never got why
> such a
> >                 zero is necessary.
> >
> >
> >                 On Monday, 17 January 2022 at 18:09:10 UTC

> > cinco...@gmail.com <mailto:cinco...@gmail.com> wrote:
> >
> >                     since doing the load has visible
> side-effects, this
> >                     behavior matters. i couldn't find a reference.
> >
> >                 --
> >
> >                 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 <mailto:isa-dev%2Bu...@groups.riscv.org>.

> >
> >                 To view this discussion on the web visit
> >

> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0061d075-95ce-47b8-8fcc-0371fa50f9a5n%40groups.riscv.org
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0061d075-95ce-47b8-8fcc-0371fa50f9a5n%40groups.riscv.org>
> >
>  <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0061d075-95ce-47b8-8fcc-0371fa50f9a5n%40groups.riscv.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0061d075-95ce-47b8-8fcc-0371fa50f9a5n%40groups.riscv.org?utm_medium=email&utm_source=footer>>.

> >
> >         --
> >         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

> <mailto:isa-dev%2Bunsu...@groups.riscv.org>
> >         <mailto:isa-dev+u...@groups.riscv.org
> <mailto:isa-dev%2Bunsu...@groups.riscv.org>>.

> >         To view this discussion on the web visit
> >
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/546c9458-7bb0-410f-97e2-23802c4e317fn%40groups.riscv.org
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/546c9458-7bb0-410f-97e2-23802c4e317fn%40groups.riscv.org>
> >

>  <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/546c9458-7bb0-410f-97e2-23802c4e317fn%40groups.riscv.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/546c9458-7bb0-410f-97e2-23802c4e317fn%40groups.riscv.org?utm_medium=email&utm_source=footer>>.

> >
> >     --
> >     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

> <mailto:isa-dev%2Bunsu...@groups.riscv.org>
> >     <mailto:isa-dev+u...@groups.riscv.org
> <mailto:isa-dev%2Bunsu...@groups.riscv.org>>.

> >     To view this discussion on the web visit
> >
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DBmufrOLaKuUvtPOuDQ1dw%3D9__GiE7%3DOb%2BMWH-uxJAXwg%40mail.gmail.com
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DBmufrOLaKuUvtPOuDQ1dw%3D9__GiE7%3DOb%2BMWH-uxJAXwg%40mail.gmail.com>
> >

>  <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DBmufrOLaKuUvtPOuDQ1dw%3D9__GiE7%3DOb%2BMWH-uxJAXwg%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DBmufrOLaKuUvtPOuDQ1dw%3D9__GiE7%3DOb%2BMWH-uxJAXwg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.

> >
> > --
> > 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

> <mailto:isa-dev%2Bunsu...@groups.riscv.org>
> > <mailto:isa-dev+u...@groups.riscv.org
> <mailto:isa-dev%2Bunsu...@groups.riscv.org>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAMU%2BEkzpzuxAeZoWtyrzJ%3DwBpLMMQjh8RqeZaFXn2cAJ2t%3DNtA%40mail.gmail.com
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAMU%2BEkzpzuxAeZoWtyrzJ%3DwBpLMMQjh8RqeZaFXn2cAJ2t%3DNtA%40mail.gmail.com>
>
> >

> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAMU%2BEkzpzuxAeZoWtyrzJ%3DwBpLMMQjh8RqeZaFXn2cAJ2t%3DNtA%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAMU%2BEkzpzuxAeZoWtyrzJ%3DwBpLMMQjh8RqeZaFXn2cAJ2t%3DNtA%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> --
> 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

> <mailto:isa-dev%2Bunsu...@groups.riscv.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/64988ef0-5d57-edd4-6669-396db6c29b26%40gmail.com
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/64988ef0-5d57-edd4-6669-396db6c29b26%40gmail.com>.
>