RV32E ideas

[Lars Rockstroh]

Hi,

IMHO, RV32I is small enough for ASIC designs. Reduced number of registers provides not much benefits for ASIC designs. RV32E could prove useful for FPGAs. Here, registers could be implemented in block ram. Required is a "compressed only; 16bit-only" instruction set with compiler support. This might or might not go hand in hand with a reduced number of registers in order to enable reduced bit widths of instructions. The "compressed only" instruction set might consist of current C instructions. An option with 16bit data bus should provide the same results as 32 bit data bus with 16bit data types. In particular, the binary code of the compiler should be identical.

Best regards,

Lars

[Jan Gray]

RV32I/RV64I is small enough for FPGA designs. :-)

 

For most scalar FPGA soft processors, reducing the register file depth from 32 to 16 entries saves nothing. In modern FPGAs, the min depth of LUT RAM is 32 entries (Xilinx RAM32M16, Altera MLAB, for example), and the various block RAMs are much deeper still.

 

But consider an area optimized design with a (multicycle) reduced width datapath. An 8b implementation might keep its 16 32b registers in a (single LUT delay) 64x8b LUT-RAM (e.g. Xilinx RAM64M8).

 

Multithreading? A 2-threaded RV32E core could fit both hart’s register contexts in a 32-entry LUT RAM; and 64 (vs. 32) contexts might fit in a 1Kx32b BRAM.

 

A 16-entry reg file could reduce the complexity of register metadata for microarchitectures that track things about registers. But then again these cores are not usually so area-constrained.

 

In summary, a 16 register ISA variant might have some utility, but let us not advance it on the basis of FPGA soft processor frugality or enablement.

 

(A hypothetical RV16 (XLEN=16) is another matter.)

 

Cheers,

Jan Gray | Gray Research LLC | Bellevue, WA

--
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/346a7770-9c76-442d-b1cb-11715cd8d5b4%40groups.riscv.org.

[Lars Rockstroh]

Hi Jan,

I guess, my question is: How about an extension that uses only “compressed” instructions?

In detail:

I agree that reducing the register file depth from 32 to 16 is not of much use for FPGAs. I tried to say the same thing in my initial post.

However, what are the use cases for a reduced register file depth? For ASICs? How much cost savings due to a reduced area could you have in relation to chip packaging, verification, ...? My uneducated guess is: not much. If this is wrong, please correct me. If this is true, why would the community develop and maintain compiler support for 16 registers? What is the purpose of RV32E (embedded)?

IMHO, a reduced number of registers has another advantage: With 16 registers, it is easier to design a 16bit “compressed only” ISA based on the C extension.

Regarding FPGAs:

Due to the FPGA overhead, the costs for resources/area are much higher than for ASIC. There are a lot of use cases, where a softcore with a 16 bit ISA is sufficient. However, there is a lot of fragmentation. There is no 16bit ISA softcore with a large community behind it.

> (A hypothetical RV16 (XLEN=16) is another matter.)

Does it have to be another matter? If RV32E was “compressed-only”, RV16 could be binary-code compatible.

Best regards,

Lars

[Rogier Brussee]

Op maandag 15 juli 2019 20:20:44 UTC+2 schreef Lars Rockstroh:

On the off-chance you are interested and want to have a basis to start from: I proposed a spartan but complete RV32E-like 16 bit 2 register form instruction set that can be used as an alternative to RVC (ie. _can_ be used in combination with full 32 bit instructions for RVC like compression) earlier. I then noted that it would be a natural fit for an hypothetical RV16E like processor.  I went through some hoops to allow a binary upgrade from RV32  to RV64 and or with minor modification from RV16 to RV32. Note that I deliberately didn't use 3 register form instructions, but that it might be useful to have a few (add, sub, and, perhaps slt of those with 3 bit registers). 

https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/SrujNcNc8RA/0mA-dATSBwAJ

 

See also my original Xcondensed proposal 

https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/iK3enKGb5bw/cuVAq0J8EAAJ

for similar ideas but closer to RVC (in particular that proposal uses some 5 bit register numbers).. 

See also Xan Phungs Xcompressed which he developed based on the Xcondensed proposal and  which goes in a different direction by proposing an alternative for RVC that fits in 2 rather than 3 major opcodes.

but with essentially the same reduction in code size. 

https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/SrujNcNc8RA/DRDyXTUHAgAJ

Rogier

[Andrew Waterman]

On Mon, Jul 15, 2019 at 11:20 AM Lars Rockstroh <Lars.Ro...@web.de> wrote:

Hi Jan,

I guess, my question is: How about an extension that uses only “compressed” instructions?

In detail:

I agree that reducing the register file depth from 32 to 16 is not of much use for FPGAs. I tried to say the same thing in my initial post.

However, what are the use cases for a reduced register file depth? For ASICs? How much cost savings due to a reduced area could you have in relation to chip packaging, verification, ...? My uneducated guess is: not much. If this is wrong, please correct me. If this is true, why would the community develop and maintain compiler support for 16 registers? What is the purpose of RV32E (embedded)?

In ASIC implementation of the tiniest RV32I cores, the 31 registers are often the largest single contributor to area. Some of these designs are very sensitive to cost, and the incremental value of the extra registers doesn’t justify their cost.

IMHO, a reduced number of registers has another advantage: With 16 registers, it is easier to design a 16bit “compressed only” ISA based on the C extension.

Regarding FPGAs:

Due to the FPGA overhead, the costs for resources/area are much higher than for ASIC. There are a lot of use cases, where a softcore with a 16 bit ISA is sufficient. However, there is a lot of fragmentation. There is no 16bit ISA softcore with a large community behind it.

> (A hypothetical RV16 (XLEN=16) is another matter.)

Does it have to be another matter? If RV32E was “compressed-only”, RV16 could be binary-code compatible.

Best regards,

Lars

--

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/8528b6de-890b-4cd0-be0a-c3cbdc147184%40groups.riscv.org.

[Bruce Hoult]

On Mon, Jul 15, 2019 at 12:33 PM Andrew Waterman <and...@sifive.com> wrote:
> In ASIC implementation of the tiniest RV32I cores, the 31 registers are often the largest single contributor to area. Some of these designs are very sensitive to cost, and the incremental value of the extra registers doesn’t justify their cost.

I suspect in some cases this might apply even more so to something
like a SiFive 2-series (or PULP Zero RISCY) RV64I.

[Peter Ashenden]

We develop ASICs using a small RISC-V core. The saving in going from 31
registers to 15 (not counting x0 as a register) is worth it for us. Each
register bit is a scan flop, and saving 512 of them is significant. Not
all ASICs are large SoCs. Many are small and very cost sensitive.

</$0.02>

PA

[lkcl]

On Monday, July 15, 2019 at 8:16:42 AM UTC+1, Lars Rockstroh wrote:

Hi,

IMHO, RV32I is small enough for ASIC designs. Reduced number of registers provides not much benefits for ASIC designs. RV32E could prove useful for FPGAs. Here, registers could be implemented in block ram. Required is a "compressed only; 16bit-only" instruction set with compiler support. This might or might not go hand in hand with a reduced number of registers in order to enable reduced bit widths of instructions. The "compressed only" instruction set might consist of current C instructions. An option with 16bit data bus should provide the same results as 32 bit data bus with 16bit data types. In particular, the binary code of the compiler should be identical.

lots of great answers, here, already.  rogier points out that he designed an RV16 ISA encoding because RVC is *not* stand-alone: it was never designed to be.  rogier's Xcondensed *is* designed to be stand-alone.

two things not yet mentioned:

* samuel falvo has pointed out a number of times that fitting even RV64I for compliance with the UNIX spec's "mandatory traps" on CSRS into an ultra-low-cost ICE40 FPGA requires a whopping *FIFTEEN PERCENT* of the resources of the ICE40 just to encode all the "zero" bits of the CSRs!

so when you say "RV64I is small enough for FPGA designs", jan, it depends on whether you want to conform to the Embedded platform sub-spec or the UNIX platform sub-spec.

* also in the past: RV32EIF has been mentioned, as was sharing of the regfile.  this was dismissed *before* things like jon dawson's excellent FSM-based FPU was discovered to exist. https://github.com/dawsonjon/fpu

the reason for the dismissal was because *pipelined* FP designs take up such vast resources that the resultant (pipelined) design absolutely dwarfs the size of the RV32EI core.

with careful design making sure that the FPGA's on-board DSP is utilised for multiply and addition, and as long as performance is not critical, jon dawson's FSM is an excellent starting point.  note: 32-bit DIV takes well over 50 cycles to complete, and that's fine.  at least it would fit into smaller FPGAs.

l.

[Lars Rockstroh]

Thanks @all for the information and feedback. There is some critique in this post. So I want to say beforehand that I appreciate the work that people spent on the ISA. The RV32I and 64 standards are good things to have. A motivational small talk for FPGAs is at the end of this post.

I wonder, if RV32E could bring benefits to FPGA softcores in comparison to RV32I. Yet, I don’t know the impact of the reduced register file depth.

Calling RV32E in its current form “a reduced version of RV32I designed for embedded systems” (quote from spec) is misleading and wrong from the perspective of a typical embedded engineer:

. Merely reducing the number of registers from 32 to 16 has no significant benefit for typical SoCs (as I mentioned before).

. It has no benefit for the growing number of FPGA designs with soft core (if registers are implemented in some sort of RAM).

. No improvement of RV32E regarding code size, on the contrary.

Currently, RV32E is not RV32 for embedded. RV32E is RV32 for ASIC. The difference is that today, “embedded” is much more than “a-single-Flipflop-costs-alot-ASIC”. 8Bit-MCU development is a niche already.

IHMO, the open source RISC-V organization should/could have an official stance on softcores: Should softcores use RV32I and nothing more optimized for softcores is planed or will ever be accepted? In terms of standard, this is still much better than what we had before. Surly, (size-optimized) softcores should not use the current RV32Embedded.

Limitation sounds like a bad thing, but having RV32E as well as RV32EC, is fragmentation. Another option or another extension would already be a third version. Can RISC-V do better?

I understand that the C extension was not meant to be used standalone. IMHO, some 16-bit dominated instruction set should be based on the frozen C extension.

Ideas:

a. Make the C extension mandatory for RV32E

b1. Reduce the number of 32bit instructions for RV32E

b2. Could be ok to replace one 32bit instruction with two 16bit instructions?

b3. Add instructions to RV32E that extent the C extension

c. Could there be a RV16 (XLEN=16) that has only a few 32bit instructions?

d. Only allow 16 bit instructions in RV32E

Motivation small talk:

Today, FPGAs are more useful for open-source, security, small business than ASICs. The number of FPGA designs with CPU will always be larger than those of ASIC designs. My guess is that this ratio is growing in favor of FPGAs.

The silicon is getting cheaper and silicon verification needs to be done only once per FPGA, not per design. However, the overhead due to the additional FPGA layer is large. This overhead will be less relevant in the future but is still an issue today in terms of cost. Many applications do not need 32 bit.

Best regards,

Lars

[Andrew Waterman]

On Wed, Jul 17, 2019 at 12:35 AM Lars Rockstroh <Lars.Ro...@web.de> wrote:

Thanks @all for the information and feedback. There is some critique in this post. So I want to say beforehand that I appreciate the work that people spent on the ISA. The RV32I and 64 standards are good things to have. A motivational small talk for FPGAs is at the end of this post.

I wonder, if RV32E could bring benefits to FPGA softcores in comparison to RV32I. Yet, I don’t know the impact of the reduced register file depth.

Calling RV32E in its current form “a reduced version of RV32I designed for embedded systems” (quote from spec) is misleading and wrong from the perspective of a typical embedded engineer:

. Merely reducing the number of registers from 32 to 16 has no significant benefit for typical SoCs (as I mentioned before).

In my experience, this observation is very often true, but not always so.  In a simpler world, RV32E would not exist, but it does because there is actual demand for it.

. It has no benefit for the growing number of FPGA designs with soft core (if registers are implemented in some sort of RAM).

. No improvement of RV32E regarding code size, on the contrary.

Currently, RV32E is not RV32 for embedded. RV32E is RV32 for ASIC. The difference is that today, “embedded” is much more than “a-single-Flipflop-costs-alot-ASIC”. 8Bit-MCU development is a niche already.

IHMO, the open source RISC-V organization should/could have an official stance on softcores: Should softcores use RV32I and nothing more optimized for softcores is planed or will ever be accepted? In terms of standard, this is still much better than what we had before. Surly, (size-optimized) softcores should not use the current RV32Embedded.

Limitation sounds like a bad thing, but having RV32E as well as RV32EC, is fragmentation. Another option or another extension would already be a third version. Can RISC-V do better?

I understand that the C extension was not meant to be used standalone. IMHO, some 16-bit dominated instruction set should be based on the frozen C extension.

Ideas:

a. Make the C extension mandatory for RV32E

b1. Reduce the number of 32bit instructions for RV32E

b2. Could be ok to replace one 32bit instruction with two 16bit instructions?

b3. Add instructions to RV32E that extent the C extension

c. Could there be a RV16 (XLEN=16) that has only a few 32bit instructions?

d. Only allow 16 bit instructions in RV32E

Motivation small talk:

Today, FPGAs are more useful for open-source, security, small business than ASICs. The number of FPGA designs with CPU will always be larger than those of ASIC designs. My guess is that this ratio is growing in favor of FPGAs.

The silicon is getting cheaper and silicon verification needs to be done only once per FPGA, not per design. However, the overhead due to the additional FPGA layer is large. This overhead will be less relevant in the future but is still an issue today in terms of cost. Many applications do not need 32 bit.

Best regards,

Lars

--
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/61b5da49-2c61-46ac-ad77-40ca0e6e0762%40groups.riscv.org.

[lkcl]

On Wednesday, July 17, 2019 at 8:35:55 AM UTC+1, Lars Rockstroh wrote:

Thanks @all for the information and feedback. There is some critique in this post. So I want to say beforehand that I appreciate the work that people spent on the ISA.

it's really nice to see that you recognise this.  welcome to the RISC-V community.

 

Limitation sounds like a bad thing, but having RV32E as well as RV32EC, is fragmentation. Another option or another extension would already be a third version. Can RISC-V do better?

one crucial aspect of RISC-V to appreciate is that there are different "Platform Specs", which are "augmentations" of the base specifications to suit very specific deployment areas.  there are two key areas:

(1) "embedded" platform

(2) "UNIX" platform.

others may be added in future [may even exist already, i've not looked or heard them discussed here].

the embedded platform is where binary-interoperability is not in the slightest bit required.  typically it would be something that goes into an SSD (Western Digital), or a Stepper Motor Driver (Trinamic).  the firmware for these types of applications *NEVER* sees the light of day, and there is not just no collaboration or cooperation or interoperability at the binary level, there is no *NEED* for collaboration, cooperation or interoperability at the binary level.

the UNIX platform is radically different.  collaboration and cooperation and binary interoperability is the absolute, top priority [hence why a lot of people were extremely pissed off when the UNIX Platform WG was formed as a secretive closed-doors list - this is just stating a fact.  moving rapidly on].

so looking at the "fragmentation" in the "embedded" arena, this is *very deliberate* and *by design*.  it allows implementors to cherry-pick features that will make-or-break profitability (or even whether the product can do the job at all, such as fitting into a cost-competitive FPGA).

where lack of consensus in the UNIX platform (decisions being made without a wider consultation) has already adversely impacted implementors is where a decision was made to change the default from RV64G to RV64GC.  IIT Madras in particular are now completely isolated from the UNIX Platform community, and will remain that way for at least another couple of years (unable to run debian or fedora distros), because their first chip was designed to the UNIX Platform Spec at the time (RV64G) and had already entered the Silicon Design / Layout Phase.

so i thought i'd just point these things out, to provide some context, so that you can appreciate better what might be driving decisions on adoption.  the point being: in the embedded space (even if it's RV64), you *want* as rich a suite of options as you can possibly get, whilst in the "UNIX" platform, it's absolutely crucial to get world-wide consensus (well beyond just the RISC-V Foundation Membership), and it's really important not to confuse the two.

warmest,

l.

[Lars Rockstroh]

On Wednesday, July 17, 2019 at 9:50:21 AM UTC+2, andrew wrote:

In my experience, this observation is very often true, but not always so.  In a simpler world, RV32E would not exist, but it does because there is actual demand for it.

I appreciate that profiteers of a reduced register file depth have the resources to drive the RISC-V standard forward. Nothing wrong with that. It is also fine to leave RV32E as it is in order to provide the flexibility that those use cases might need. But if so, let's not call this the "embedded version." At least, it fooled me.

On Wednesday, July 17, 2019 at 10:03:15 AM UTC+2, lkcl wrote:

 

so looking at the "fragmentation" in the "embedded" arena, this is *very deliberate* and *by design*.  it allows implementors to cherry-pick features that will make-or-break profitability (or even whether the product can do the job at all, such as fitting into a cost-competitive FPGA).

 

There is already too much cherry-pick. There are a lot of cores without license fee that can be used for ASIC and FPGA. In contrast, RISC-V is a standard and has a big community. There is no point in having a core so specialized that you need to maintain all the required environment yourself. You can already have that w/o RISC-V. Contributers have no interest in having their preferred version slowly die off due to a lack of compatibility or due to a lack of interest by the community (all the small contributions, in particular compiler). At least one of the two is required.

Best regards,

Lars

[Andrew Waterman]

On Wed, Jul 17, 2019 at 1:41 AM Lars Rockstroh <Lars.Ro...@web.de> wrote:

On Wednesday, July 17, 2019 at 9:50:21 AM UTC+2, andrew wrote:

In my experience, this observation is very often true, but not always so.  In a simpler world, RV32E would not exist, but it does because there is actual demand for it.

I appreciate that profiteers of a reduced register file depth have the resources to drive the RISC-V standard forward. Nothing wrong with that. It is also fine to leave RV32E as it is in order to provide the flexibility that those use cases might need. But if so, let's not call this the "embedded version." At least, it fooled me.

I'm not sure who the profiteer is (RVI is commercially dominant), but I agree the mnemonic is potentially misleading.  Embeddedness is a property of the platform, not of the ISA.

On Wednesday, July 17, 2019 at 10:03:15 AM UTC+2, lkcl wrote:

 

so looking at the "fragmentation" in the "embedded" arena, this is *very deliberate* and *by design*.  it allows implementors to cherry-pick features that will make-or-break profitability (or even whether the product can do the job at all, such as fitting into a cost-competitive FPGA).

 

There is already too much cherry-pick. There are a lot of cores without license fee that can be used for ASIC and FPGA. In contrast, RISC-V is a standard and has a big community. There is no point in having a core so specialized that you need to maintain all the required environment yourself. You can already have that w/o RISC-V. Contributers have no interest in having their preferred version slowly die off due to a lack of compatibility or due to a lack of interest by the community (all the small contributions, in particular compiler). At least one of the two is required.

Best regards,

Lars

--

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/d6aa3995-29dc-4c7a-8305-906eb6bbc53d%40groups.riscv.org.

[lkcl]

On Wednesday, July 17, 2019 at 9:41:24 AM UTC+1, Lars Rockstroh wrote:

On Wednesday, July 17, 2019 at 9:50:21 AM UTC+2, andrew wrote:

In my experience, this observation is very often true, but not always so.  In a simpler world, RV32E would not exist, but it does because there is actual demand for it.

I appreciate that profiteers of a reduced register file depth have the resources to drive the RISC-V standard forward. Nothing wrong with that. It is also fine to leave RV32E as it is in order to provide the flexibility that those use cases might need. But if so, let's not call this the "embedded version." At least, it fooled me.

ah you have a good point.  overuse of the word "embedded".  RV32I or RV64I or even RV64GC can have the "Embedded Platform Spec" applied to it... and the confusion results from the use of the same word "embedded" in "RV32E".

 

so looking at the "fragmentation" in the "embedded" arena, this is *very deliberate* and *by design*.  it allows implementors to cherry-pick features that will make-or-break profitability (or even whether the product can do the job at all, such as fitting into a cost-competitive FPGA).

 

There is already too much cherry-pick.

and the options will only get greater - not smaller - over the next 50 years.  this is just how it's going to be, and it's important to recognise and accept.

 

There are a lot of cores without license fee that can be used for ASIC and FPGA. In contrast, RISC-V is a standard

it's best to think of it as a suite of standards.  extensibility is part *of* the standard.

 

and has a big community. There is no point in having a core so specialized that you need to maintain all the required environment yourself.

that's precisely what many of these extremely large Corporations, many of them selling billions of units a year, are doing.  now, whether they do it *well* or not is an entirely different matter!

most of them will quite likely take a snapshot of whatever the current (stable) tools and environment are, and when the "next version" comes out they LITERALLY abandon the entire toolchain - duplicate the environment - and start from scratch.  they can do this precisely because the firmware goes into ROM (or NAND) and very very rarely changes.

i've seen this done in the extreme by Corporations such as Marvell and Allwinner: the results aren't pretty [those are two ARM examples, illustrating that this is a problem not isolated to or specific to RISC-V at all].

You can already have that w/o RISC-V. Contributers have no interest in having their preferred version slowly die off due to a lack of compatibility or due to a lack of interest by the community (all the small contributions, in particular compiler).

again, to emphasise: in the proprietary world it's really crucial to mentally separate the needs for any compatibility to exist *at all*.  what possible compatibility would be needed between say the RV32 binaries utilised and deployed in the *PROPRIETARY* RV32 core developed by Western Digital, and the *PROPRIETARY* RV32 core developed by Trinamic?

it doesn't make any sense, does it? :)  two different companies, two totally different products [btw it's exactly the same in the ARM world as well].

where sharing *does* make sense for these proprietary companies is in the cost-savings of the unit testing, development and maintenance of the compiler toolchains and so on.  RISC-V Members are required (section 2.3) to contribute financially to the libre/open community so as not to become "spongers", however that's as far as it goes, and as far as it needs to go.

beyond that, you have to ask *why* they would collaborate, cooperate, or limit their products to specific subsets of possible / potential functionality?

additionally, i don't know if you're aware of this, but ARM is a hugely disparate community with radically different needs in the embedded and UNIX/POSIX worlds, as well.  over 12 years ago there were over SEVEN HUNDRED separate licensees.  that must be well beyond double that number, by now.

l.

[Guy Lemieux]

On Wed, Jul 17, 2019 at 2:02 AM lkcl <luke.l...@gmail.com> wrote:
> ah you have a good point. overuse of the word "embedded". RV32I or RV64I or even RV64GC can have the "Embedded Platform Spec" applied to it... and the confusion results from the use of the same word "embedded" in "RV32E".

I've always thought of RV32E as "economy". As has already been
stated, it is only economy for ASICs, not FPGAs, but I don't think
that's a problem.

I believe we can create a new version that represents "FPGA economy"
or just "FPGA optimized". (Yes, there are some of us discussing such a
beast.) Since E and F are already taken... we need a new letter or set
of letters. Perhaps S for soft processor? Other letters that appear to
be available: H, O, R, U, W, X and Y.

Guy

[Andrew Waterman]

H and U are taken by the privileged architecture; X is custom; Y is reserved... R for Reconfigurable? :-)

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 view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CALo5CZxOOLMuwfoMKadUtqynJk_rqtDWUC219OSMpUCObrP%2Bug%40mail.gmail.com.

[Guy Lemieux]

ohhhhh, I like R. that’s sexy. 

guy

[Jacob Lifshay]

On Wed, Jul 17, 2019, 02:18 Andrew Waterman <wate...@eecs.berkeley.edu> wrote:

On Wed, Jul 17, 2019 at 2:15 AM Guy Lemieux <glem...@vectorblox.com> wrote:

I believe we can create a new version that represents "FPGA economy"
or just "FPGA optimized". (Yes, there are some of us discussing such a
beast.) Since E and F are already taken... we need a new letter or set
of letters. Perhaps S for soft processor? Other letters that appear to
be available: H, O, R, U, W, X and Y.

H and U are taken by the privileged architecture; X is custom; Y is reserved... R for Reconfigurable? :-)

Isn't S taken for supervisor mode?

Jacob

[Lars Rockstroh]

Here is an idea for translating RV32E assembly into 18bit ISA assembly.

Old instructions:
(4 bit) (4bit) (5bit) (4bit)
SLT   rs1, rs2, rd
SLTU rs1, rs2, rd
SLL   rs1, rs2, rd
SRL  rs1, rs2, rd
SRA  rs1, rs2, rd
ADD  rs1, rs2, rd
SUB  rs1, rs2, rd
XOR  rs1, rs2, rd
OR   rs1, rs2, rd
AND  rs1, rs2, rd
LOAD rs1, rs2, rd
STORE rs1, rs2, rd

todo: load/store for byte and halfword
todo: jumps (JAL, JALR, branches, ret)
todo: AUIPC

New instruction:
(4 bit) (12bit)
LLI immm    (load lower immediate into the new special register "R16")

The registers R17...R31 shall contain constants.
Useful values depend on the optimizer option.
For -O1, useful values are: 1,2,4,8,12,16,20,24,28,32,36,...
The constants can be selected in dependence of the program, while analyzing the RV32E assembly.


. Every RV32E instruction with an immediate (that is not in R17...R31) requires:
  -> an additional LLI (load lower imm)
  -> reg-reg instruction with rs2==17
. ADDI with zero is replaced by LLI.
. LUI with 20 bit is a problem.
. Offsets with 20 bit are also a problem, but not for small programs.
. "addi sp, sp, -32" should be replaced with "sub sp, sp, (register with constant 32)"
. if rs2>R15 for load and store, than the SP is automatically involved. Otherwise, the offset is 0.
. ...

I think, this will reduce the FPGA memory resources for instructions to almost 50%. Logic resources should also be reduced, if the registers are in RAM.

However, this might not worth a standard and is just an implementation.

Best regards,
Lars

[Lars Rockstroh]

On Friday, July 19, 2019 at 9:23:57 PM UTC+2, Lars Rockstroh wrote:

  -> reg-reg instruction with rs2==17

This should have been  "-> reg-reg instruction with rs2==16"

[Xan Phung]

I'd like to propose the following for RV32E (whilst retaining 32E or RVC16 as super-low end use cases):

(1) In addition to low end embedded, also target high end super-threaded or even GPU-like architectures

  eg. use cases presented by Mitch Hayenga

  Rogier & Lars: does making the instruction set "compressed-only" reduce gate counts?

    Won't 16 bit need to be expanded to 32 bit-like instructions as the first decode step anyway?

(2) Be more than just 32E, but in fact a binary compatible 32E, 64E (and even 128E), and have RVC instructions which are a self contained RVC16 (XLEN>=32, ILEN=16).

  * Can future big.LITTLE & operating system innovations optimise power consumption by having RV32 and RV64 (and even RVC16) all on the one SOC, running the same binary code?

  * It doesn't make sense to me that RV32/64/128I have 99% identical instruction sets, but don't go the full way to 100%.

     Making mode switching mandatory to go up/down XLEN seems to me to be solving the 1% knife-fight with a 100% bazooka

  * I get the argument the software ABIs are different anyway etc but this prematurely assumes software innovations can't solve this problem (eg. millicode save & restore / thunks?)

     Why not at least make the hardware be binary compatible first, and see where & how far software can take it?  I'm pretty sure overtime it will be taken much further than what is foreseeable today

(3) In view of the above, RV32E be renamed "RISC XV" (in recognition of it's core tenant of 15 registers, rather than 32 bit XLEN being the core feature)

(4) Have ***different governance*** to RV32/64I, so as to be more open to ideas that were promising, but didn't make the cut for RV32/64I

  This will allow RV32/64I to be the more mainstream "proven" ISAs, and RISC XV to incorporate broader ideas from researchers, hackers, virtual machine programmers, GPU developers, etc

  eg. this governance could put together a task group of people outside the normal RISC V Foundation commercial establishment, with a wide brief to put in the best ideas for RISC XV

  RVC16 comes to mind here, as it's only a tiny change from RVC (as previously documented by Rogier and myself - see below), but could open up a new surface for experimentation in unconventional architectures (eg, VLIW, bigLITTLE, bytecode-like/WebAssembly-like virtual machines, FPGAs, etc)

  Luke - you can have your transcendental opcode reservations to match widely mandated standards like Vulkan

(5) Not necessarily be frozen forever like RV32I/64I, but be amenable to evolution over the long term

[lkcl]

On Friday, August 16, 2019 at 12:02:15 AM UTC+1, Xan Phung wrote:

I'd like to propose the following for RV32E (whilst retaining 32E or RVC16 as super-low end use cases):

(1) In addition to low end embedded, also target high end super-threaded or even GPU-like architectures

hi Xan, great to hear you're still around.

this is only going to work if ISAMUX/ISANS is in place, first.  whether "accepted" by the RISC-V Foundation or not accepted by the RISC-V Foundation, ISAMUX/ISANS "extending of the OPxx decode space through a paging system" is absolutely essential.

only then can both experimentation, "official" and "de-facto industry-standard" opcodes *safely* be developed without fighting (or irreversible damage to the RISC-V ecosystem).

although it does "solve" the problem of ensuring that there are no opcode conficts, the current "complete stone-cold silence" from the RISC-V Foundation is not an acceptable solution (and is a violation of the responsibilities of a Trademark Holder, anyway).

due to the weird multi-issue vector architecture of the Libre RISC-V CPU/VPU/GPU, we have *LITERALLY* double the performance in 32-bit vectors than for RV64 and 64-bit vectors.

a 2x speed increase by being able to run 32-bit instructions *conveniently* (without the MISA sledgehammer) is clearly desirable.

anyway, to reiterate: i cannot emphasise enough how critically important it is, for absolutely everybody, for the entire RISC-V community, that ISAMUX/ISANS be firmly established in place *before* going ahead with deployment of ideas that conflict wiith - directly replace - RISC-V Standard opcodes.

l.

[Xan Phung]

Hi Luke, you raise an important question of whether opcodes in RV32E will be or need to be compatible with RV32I (this is what I assume by your term "RISC V ecosystem" below?).

My thinking is as follows:

(1) RV32E by definition will never be able to run RV32I binaries as it has fewer registers.

(2) The big question is whether RV32I will always be a super-set of RV32E, and I believe there are already significantly progressed proposals to RV32EC that will break this as well.

(3) So bottom line is RV32E and RV32I will be mutually incompatible forks.

  (Sure they will cross-fertilise ideas and maybe even entire standard extensions, but there is no point having identical opcodes if binary compatibility is broken)

If we don't have binary compatibility between RV32E and RV32I then RV32E should:

(1) Be differentiated from RV32I as much as possible (not as minimally as possible) so as to address distinct markets/needs

(2) To achieve #1, have different governance structures

(3) If RV32E is extended to 64 bits, then avoid further fragmentation.  Do this by retaining binary compatibility between RV32E and RV64E

     ie: in a reverse of how OP-32 works in RV64I, any new 64 bit instructions are to be added to an OP-64 major opcode and existing OP instructions remain 32 bit in RV32E.

(4) Have a different name entirely, eg hence my suggestion of "RISC VX"

[Xan Phung]

To further define what I mean by "differentiated from RV32I as much as possible" (below), I would still try to do this within the RISC V compiler and C library infrastructure as much as possible

ie:

(1) There would be no binary compatibility between RV32I and RV32E,

(2) Hence opcodes of RV32E and RV32I will diverge increasingly over time,

But: (3) source code level reuse of systems software (compilers, libraries, OS) will be preserved as much as possible between RV32E & RV32I, at least in the initial & medium term timeframes

[Jim Wilson]

On Fri, Aug 16, 2019 at 3:13 PM Xan Phung <xan....@gmail.com> wrote:
> (1) RV32E by definition will never be able to run RV32I binaries as it has fewer registers.

The plan for the EABI is to make all of the upper 16 registers saved
registers, so that RV32I and RV32E code will be ABI compatible, and
code compiled for RV32E can run on RV32I without problem.

> (2) The big question is whether RV32I will always be a super-set of RV32E, and I believe there are already significantly progressed proposals to RV32EC that will break this as well.

A while ago there were plans to redefine the FP compressed
instructions for RV32E because RV32E did not allow FP support. But
since then this restriction has been removed, and RV32E does allow FP,
and hence the FP compressed instructions can no longer be redefined
for RV32E.

> (3) So bottom line is RV32E and RV32I will be mutually incompatible forks.

RV32E is RV32I with 16-registers, and is expected to remain so.

Jim

[lkcl]

On Saturday, August 17, 2019 at 1:01:50 AM UTC+1, Jim Wilson wrote:

On Fri, Aug 16, 2019 at 3:13 PM Xan Phung <xan....@gmail.com> wrote:
> (1) RV32E by definition will never be able to run RV32I binaries as it has fewer registers.

The plan for the EABI is to make all of the upper 16 registers saved
registers, so that RV32I and RV32E code will be ABI compatible, and
code compiled for RV32E can run on RV32I without problem.

> (2) The big question is whether RV32I will always be a super-set of RV32E, and I believe there are already significantly progressed proposals to RV32EC that will break this as well.

A while ago there were plans to redefine the FP compressed
instructions for RV32E because RV32E did not allow FP support.  But
since then this restriction has been removed, and RV32E does allow FP,
and hence the FP compressed instructions can no longer be redefined
for RV32E.

jim: i have been on isa-dev for over 18 months, i did not see any such discussion.  could you refer everyone here to the publicly-accesible (unrestricted) location where that was publicly discussed?

i am sure that if it had been publicly discussed, the concern would have been raised that by making that decision, it penalises those implementors that do *not* want FP in RV32E.

l.

[Dan Petrisko]

i am sure that if it had been publicly discussed, the concern would have been raised that by making that decision, it penalises those implementors that do *not* want FP in RV32E.

To clarify, the change was that RV32EF is a valid configuration, whereas it was illegal before.  Implementors are free to use RV32E for a softfloat ABI.

From spec 2.2:

We do not intend to support hardware floating-point with the RV32E subset. The savings from reduced register count become negligible in the context of a hardware floating-point unit, and we wish to reduce the proliferation of ABIs.

Now the change to the latest spec:

RV32E can be combined with all current standard extensions. Defining the F, D, and Q exten- sions as having a 16-entry floating point register file when combined with RV32E was considered but decided against. To support systems with reduced floating-point register state, we intend to define a “Zfinx” extension that makes floating-point computations use the integer registers, removing the floating-point loads, stores, and moves between floating point and integer registers. 

Apologies if you meant the GCC maintainers, because yes, this does mean ABI changes.

Best,

Dan Petrisko

--

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/148bb967-2c65-47aa-ba6e-669043272ac7%40groups.riscv.org.

[lkcl]

On Saturday, August 17, 2019 at 4:28:34 AM UTC+1, Dan Petrisko wrote:

i am sure that if it had been publicly discussed, the concern would have been raised that by making that decision, it penalises those implementors that do *not* want FP in RV32E.

To clarify, the change was that RV32EF is a valid configuration, whereas it was illegal before.  Implementors are free to use RV32E for a softfloat ABI.

okaay, yes, i vaguely remember that.  thanks dan.

 

From spec 2.2:

We do not intend to support hardware floating-point with the RV32E subset. The savings from reduced register count become negligible in the context of a hardware floating-point unit, and we wish to reduce the proliferation of ABIs.

Now the change to the latest spec:

RV32E can be combined with all current standard extensions. Defining the F, D, and Q exten- sions as having a 16-entry floating point register file when combined with RV32E was considered but decided against. To support systems with reduced floating-point register state, we intend to define a “Zfinx” extension that makes floating-point computations use the integer registers, removing the floating-point loads, stores, and moves between floating point and integer registers. 

hmmm...  the opportunity for RV32E to use the FP RVC opcodes - which in embedded systems will be *really* precious and could make all the difference - seems to have been overlooked.

l.

[lkcl]

On Friday, August 16, 2019 at 11:37:15 PM UTC+1, Xan Phung wrote:

To further define what I mean by "differentiated from RV32I as much as possible" (below), I would still try to do this within the RISC V compiler and C library infrastructure as much as possible

ok, that's slightly different from an actual hardware-level difference, where the actual meaning of say ADD and ADD.W is properly fixed so that a program compiled for 32-bit could actually run (OS support permitting) on 64 bit hardware.

that is definitely desirable and has been mentioned several times.

 

ie:

(1) There would be no binary compatibility between RV32I and RV32E,

(2) Hence opcodes of RV32E and RV32I will diverge increasingly over time,

both these tend to imply actual hardware or at least RV spec differences, which would definiitely need to be documented.

l.

[Xan Phung]

On Saturday, 17 August 2019 10:01:50 UTC+10, Jim Wilson wrote:

> (2) The big question is whether RV32I will always be a super-set of RV32E, and I believe there are already significantly progressed proposals to RV32EC that will break this as well.

A while ago there were plans to redefine the FP compressed
instructions for RV32E because RV32E did not allow FP support.  But
since then this restriction has been removed, and RV32E does allow FP,
and hence the FP compressed instructions can no longer be redefined
for RV32E.

Hi Jim, thanks for the update!

I had the compressed FP opcodes in mind as a "sliding doors" moment that would have broken up the marriage of RV32E & RV32I.

But yes, like Gwynneth Paltrow & her boyfriend in the movie, looks like the alternate reality of them sticking together is what will happen, now the FP changes aren't going ahead.

Cheers

Xan