MIPS IV vs RISC V free opcodes - detailed analysis

[Xan Phung]

Hi all,

Below is a more detailed analysis of free opcode spaces of RV64GC, and a comparison to MIPS IV.

Note MIPS has 64 opcodes x 26 bit encoding spaces vs RV64GC has 28 opcodes x 25 bit encoding spaces, ie: under one quarter the 32 bit instruction encoding space of MIPS)

In addition to major opcodes, I also looked for the largest available encoding space within each major opcode.

Colour coding is as follows:

1. DARK GREEN = 26 bit encoding space

  = one MIPS major opcode (equivalent to 200% x RISCV major opcode)

2. GREEN = 100% x RISCV major opcode fully available

3. YELLOW = 50% of RISCV major opcode

4. ORANGE = 6.25%~25% of RISCV major opcode

5. RED < 6.25% of RISC V major opcode

As table below shows, MIPS IV has the equivalent of 42 RISC V "greenfield" major opcodes completely available.

It also has 28 opcodes with 21-24 bits of "brownfield" encoding space available.

Yet MIPS is considered to be opcode constrained...

In comparison, RV64GC only has 5 reserved "greenfield" major opcodes available (also 2 custom opcodes for non-standard extensions).

It also has 18 opcodes with 21-24 bits of "brownfield" encoding space

So if MIPS is considered opcode space constrained, then RISC V is almost an order of magnitude more constrained.  (Greenfield opcodes are 2-8x the value of brownfield opcodes).

I'm of the opinion RISC V can't afford to set aside 75% of it's opcode space for RVC.  Instead RVC 16 bit instructions should be only 50%.  This will provide 60 major opcodes (instead of 28 opcodes) for 32 bit instructions.  The cost is a reduction in the compression performance of RVC by 1-2% but the win is a future-proofed extensibility...

[Andrew Waterman]

On Thu, Dec 15, 2016 at 2:42 AM, Xan Phung <xan....@gmail.com> wrote:

Hi all,

Below is a more detailed analysis of free opcode spaces of RV64GC, and a comparison to MIPS IV.

Note MIPS has 64 opcodes x 26 bit encoding spaces vs RV64GC has 28 opcodes x 25 bit encoding spaces, ie: under one quarter the 32 bit instruction encoding space of MIPS)

In addition to major opcodes, I also looked for the largest available encoding space within each major opcode.

Colour coding is as follows:

1. DARK GREEN = 26 bit encoding space

  = one MIPS major opcode (equivalent to 200% x RISCV major opcode)

2. GREEN = 100% x RISCV major opcode fully available

3. YELLOW = 50% of RISCV major opcode

4. ORANGE = 6.25%~25% of RISCV major opcode

5. RED < 6.25% of RISC V major opcode

As table below shows, MIPS IV has the equivalent of 42 RISC V "greenfield" major opcodes completely available.

It also has 28 opcodes with 21-24 bits of "brownfield" encoding space available.

Yet MIPS is considered to be opcode constrained...

If you honestly think that MIPS has been a better steward of its opcode space than RISC-V has, then you and your attorneys should have a field day building free and open ISA extensions within that ecosystem.  Good luck on the code size.

In comparison, RV64GC only has 5 reserved "greenfield" major opcodes available (also 2 custom opcodes for non-standard extensions).

It also has 18 opcodes with 21-24 bits of "brownfield" encoding space

So if MIPS is considered opcode space constrained, then RISC V is almost an order of magnitude more constrained.  (Greenfield opcodes are 2-8x the value of brownfield opcodes).

I'm of the opinion RISC V can't afford to set aside 75% of it's opcode space for RVC.  Instead RVC 16 bit instructions should be only 50%.  This will provide 60 major opcodes (instead of 28 opcodes) for 32 bit instructions.  The cost is a reduction in the compression performance of RVC by 1-2% but the win is a future-proofed extensibility...

--
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/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/f7bbbc73-beda-470b-a0d5-b4df3971081e%40groups.riscv.org.

[Alex Bradbury]

On 15 December 2016 at 10:42, Xan Phung <xan....@gmail.com> wrote:
>
> Hi all,
>
> Below is a more detailed analysis of free opcode spaces of RV64GC, and a comparison to MIPS IV.
> Note MIPS has 64 opcodes x 26 bit encoding spaces vs RV64GC has 28 opcodes x 25 bit encoding spaces, ie: under one quarter the 32 bit instruction encoding space of MIPS)
>
> In addition to major opcodes, I also looked for the largest available encoding space within each major opcode.
> Colour coding is as follows:
> 1. DARK GREEN = 26 bit encoding space
> = one MIPS major opcode (equivalent to 200% x RISCV major opcode)
> 2. GREEN = 100% x RISCV major opcode fully available
> 3. YELLOW = 50% of RISCV major opcode
> 4. ORANGE = 6.25%~25% of RISCV major opcode
> 5. RED < 6.25% of RISC V major opcode
>
> As table below shows, MIPS IV has the equivalent of 42 RISC V "greenfield" major opcodes completely available.
> It also has 28 opcodes with 21-24 bits of "brownfield" encoding space available.
> Yet MIPS is considered to be opcode constrained...
>
> In comparison, RV64GC only has 5 reserved "greenfield" major opcodes available (also 2 custom opcodes for non-standard extensions).
> It also has 18 opcodes with 21-24 bits of "brownfield" encoding space
> So if MIPS is considered opcode space constrained, then RISC V is almost an order of magnitude more constrained. (Greenfield opcodes are 2-8x the value of brownfield opcodes).

Hi Xan. I think one point missed in your analysis is RISC-V's
variable-length encoding. Extensions can be defined using 48-bit,
64-bit, 80-bit, ... instructions. This gives a _huge_ encoding space.

> I'm of the opinion RISC V can't afford to set aside 75% of it's opcode space for RVC. Instead RVC 16 bit instructions should be only 50%. This will provide 60 major opcodes (instead of 28 opcodes) for 32 bit instructions. The cost is a reduction in the compression performance of RVC by 1-2% but the win is a future-proofed extensibility...

I think this is an interesting suggestion, and I'd be interested in
seeing a counter-argument from anyone who disagrees. It seems clear to
me that we need results from a much wider range of codebases/workloads
to inform decisions about the compressed spec. It would be easier for
others to follow if this proposal could be kept on one thread though.

Best,

Alex

[Xan Phung]

> I'm of the opinion RISC V can't afford to set aside 75% of it's opcode space for RVC.  Instead RVC 16 bit instructions should be only

> 50%.  This will provide 60 major opcodes (instead of 28 opcodes) for 32 bit instructions.  The cost is a reduction in the compression  

> performance of RVC by 1-2% but the win is a future-proofed extensibility...

I think this is an interesting suggestion, and I'd be interested in
seeing a counter-argument from anyone who disagrees. It seems clear to
me that we need results from a much wider range of codebases/workloads
to inform decisions about the compressed spec. It would be easier for
others to follow if this proposal could be kept on one thread though.

Best,

Alex

Thanks Alex for your interest.

Apologies about the separate threads, if anyone has difficulty following the separate threads, this thread is related to the following:

"RV Compressed in 16 opcodes"

https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/YG80MMHMWis

I guess having two threads can be useful, so as to divide up the discussion as follows:

1.  (Problem) Does RISC V have enough reserved 32 bit future encoding space? - discuss long term opcode space "future proofing" issues in this thread

2.  (Solution) Proposal to reduce RV Compressed into only 16 opcodes (ie: only 50% of opcode space instead of 75%) - discuss specific Compressed ISA details in the thread at the link given above (eg. which RVC v1.9 instructions to drop, size of register & immediate fields, etc).

[kr...@berkeley.edu]

Just following up on this old email thread.

Some points;

1) There's a huge encoding space in RISC-V thanks to the
variable-length encoding - we won't run out of room to add new
opcodes.

2) Most new instruction extensions won't be very frequently used
compared to the existing standard extensions, so using shorter
encodings isn't as important. Once you have 16-bit C implemented,
and possibly macroop fusion, 48-bit instructions are not much
additional complexity.

3) Compression ratios vary greatly from app to app and people really
care about code size. When we earlier tried to drop back to to a
smaller C extension, we had many complaints about particular codes
getting bigger, even though averages weren't too bad, so we upped C
back to the larger set we have now.

4) At this point, with multiple systems implemented using the existing C
standard, there's going to be a very high bar for incompatible
changes.

The C spec does need some cleaning up with respect to HINTS,
"reserved", and "never-standard" opcode space, before ratification.

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/

| 3b8263ab-7f8b-4e4a-829c-eb57fec91e03%40groups.riscv.org.

[J Osmany]

Hello

Could some give some possible examples of micro-op fusion for a RISC-V implementation?

My fading recollection regarding mirco-op fusion being wrt interlock collapsing ALU's.

Best Regards

J.Osmany

---

From: kr...@berkeley.edu <kr...@berkeley.edu>
Sent: 03 April 2017 02:02
To: Xan Phung
Cc: RISC-V ISA Dev
Subject: Re: [isa-dev] MIPS IV vs RISC V free opcodes - detailed analysis

 

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

Google Groups groups.google.com Google Groups allows you to create and participate in online forums and email-based groups with a rich experience for community conversations.

[Krste Asanovic]

https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-130.pdf

Krste

[J Osmany]

Thanks Krste.

Best Regards

J.Osmany

---

From: Krste Asanovic <kr...@berkeley.edu>
Sent: 03 April 2017 11:23
To: J Osmany
Cc: Xan Phung; RISC-V ISA Dev

Subject: Re: [isa-dev] MIPS IV vs RISC V free opcodes - detailed analysis

 

https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-130.pdf

The Renewed Case for the Reduced Instruction Set Computer ... people.eecs.berkeley.edu The Renewed Case for the Reduced Instruction Set Computer: Avoiding ISA Bloat with Macro-Op Fusion for RISC-V Christopher Celio Daniel Dabbelt David A. Patterson

[Xan Phung]

Dear Krste,

Thanks for following on this issue (which I had kind of resigned to being a "dead" issue).

I can accept point #4 is particularly a concern for the fostering of RISC V's ecosystem and ensuring it's ongoing growth & vitality.

Naturally, concerns about opcode space may not manifest for one or more decades, and in the mean time backwards compatibility is a more immediate pressure.

(but more on this later).

In relation to point #3, certainly it is true different workloads have different ISA compression profiles but in the end, doesn't this mean it is premature to fully commit 72% of opcode space to existing workloads, hence over-optimising for these apps, and then only having 3% left for any future additional 16 bit instructions (should future unforeseen compressed ISA needs arise)?  Doesn't this strengthen the case to keep 25% of opcode space in reserve for potentially optimising compression of these future unforeseen workloads?

I agree points #1 and #2 are fair enough if the eventual future of RISC V is a variable length instruction set, where opcodes may be 16 bit, 32 bit, 48bit or indeed 64bit.  Preserving the architecture for 48bit & 64bit extensions is very far sighted, but my own hope had been that the 32 bit 'fixed size' opcode ISA subset would have an "adequate" lifespan for a longer future horizon (than just the immediate present needs).

In particular, my hope had been that at least the Decimal FP extensions could fit into the 32bit opcode ISA (in my mind, decimal FP should be a "first class" citizen, treated equally to binary FP).  If opcode space wasn't a concern, the most orthogonal Decimal FP encoding would require 5 x 25 bit opcodes to fully support 4-operand fused multiply-add instructions, 6 rounding modes and 3 data sizes (ie: 32 bit, 64 bit & 128bit decimals). You could get away with 3 x 25 bit opcodes if 32 bit data size is dropped ... but on the other hand you might need 10 x 25 opcodes if you want to support both densely packed decimal format and binary significand format.

What the Decimal FP example shows is that continuous 25bit opcodes are very valuable - an order of magnitude more valuable than less continuous opcodes (yet only 3x25 bit opcodes are explicitly "reserved" for future 32 bit standard extensions).  I know others have suggested "taking over" custom0-3 or >32bit opcodes but both of these also involve breaking backwards compatibility.

Coming back to the issue of backwards compatibility, can I ask an hypothetical question: if RISC V compressed was designed from scratch today, would the decision still be to go with giving it 75% of the total 32 bit opcode space.  If the answer is no then perhaps a "migration strategy" could work?  eg. guarantee the existing RVC will remain supported for the next 10-15 years, but mark out seven of it's 23x11 bit opcodes as "deprecated" or subject to future change?  That way you could still get the best long term design, whilst still catering for short term pressure points on backwards compatibility.

[kr...@berkeley.edu]

RISC-V has always been a variable-length instruction set. We
supported variable length from the beginning precisely to enable
compression-as-an-extension, as well as to avoid opcode space wars.
Given how important instruction compression is to system cost, energy,
and performance, and how few other ideas give the same broad
improvement across many scenarios, if we started again, we would
probably still decide to use more than 50% of first parcel space (NOT
50% of opcode space, which is effectively infinite) for compressed
encoding. Of course, if we did it again, there are multiple little
things we'd change, but "finished, now" is far more useful than
"perfect, sometime".

We imagine C being mandatory in most ABIs for server architectures and
microcontrollers. The main places you would not implement C are a)
educational processors, b) very small microcontrollers where code size
is irrelevant because absolute code size is small, c)
inhouse/home-grown cores where development effort is more important
than marginal system cost, d) the base of accelerators where again
there is little total general code. These are important use cases, so
that's why C is an extension and not part of mandatory base, and why
we emphasize having the software tools work with just the base I ISA.

Once you have C, you have variable-length instructions, and have
already paid most of the complexity of dealing with 48-bit
instructions. In this context, using more of the first parcel space
to allow more 16-bit instructions to increase compression across a
wide range of existing uses (which will look a lot like many future
uses) seems wiser than lowering compression now and reserving a lot of
it to either a) compress some future unknown uses that look
substantially different than current applications fed through current
compilers and that benefit greatly from a different C extension, or b)
to enable more exotic instructions to fit into the 32-bit encoding.
In particular, I doubt there would be much support for lowering
compression ratio in order to fit decimal floating-point into 32 bits.

Some other points:

- For RVIC, there are a bunch of open slots in the encoding for
additional extensions.

- For RV32EC, there is a vast number of open slots as anything
making use of the high bit of 5-bit register specifiers is not
going to be used for standard extensions.

- Future compression extensions don't have to be 16-bit
instructions. We might ponder a 48-bit compressed extension that
reduces two 32-bit instructions to a single 48-bit instruction,
for example.

As for deprecating/changing C, well, this would face a very high bar
for adoption. The route would have to be a different extension that
wasn't C, C itself won't change once ratified.

Krste

>>>>> On Tue, 4 Apr 2017 04:11:32 -0700 (PDT), Xan Phung <xan....@gmail.com>h said:

| Dear Krste,

| Thanks for following on this issue (which I had kind of resigned to being a
| "dead" issue).

| I can accept point #4 is particularly a concern for the fostering of RISC V's
| ecosystem and ensuring it's ongoing growth & vitality

| Naturally, concerns about opcode space may not manifest for one or more
| decades, and in the mean time backwards compatibility is a more immediate
| pressure.
| (but more on this later).

| In relation to point #3, certainly it is true different workloads have
| different ISA compression profiles but in the end, doesn't this mean it is
| premature to fully commit 72% of opcode space to existing workloads, hence
| over-optimising for these apps, and then only having 3% left for any future
| additional 16 bit instructions (should future unforeseen compressed ISA needs
| arise)?  Doesn't this strengthen the case to keep 25% of opcode space in

| reserve for potentially optimising compression of these future unforeseenyo

| workloads?

| I agree points #1 and #2 are fair enough if the eventual future of RISC V is a
| variable length instruction set, where opcodes may be 16 bit, 32 bit, 48bit or
| indeed 64bit.  Preserving the architecture for 48bit & 64bit extensions is very
| far sighted, but my own hope had been that the 32 bit 'fixed size' opcode ISA

| subset would have an "adequate" lifespan for a longer future horizon (than jearyust

| a0199c26-eaad-450a-88c8-be743d86feee%40groups.riscv.org.

[Bruce Hoult]

On Tue, Apr 4, 2017 at 2:11 PM, Xan Phung <xan....@gmail.com> wrote:

In relation to point #3, certainly it is true different workloads have different ISA compression profiles but in the end, doesn't this mean it is premature to fully commit 72% of opcode space to existing workloads, hence over-optimising for these apps, and then only having 3% left for any future additional 16 bit instructions (should future unforeseen compressed ISA needs arise)?  Doesn't this strengthen the case to keep 25% of opcode space in reserve for potentially optimising compression of these future unforeseen workloads?

I doubt that's the case. What would you leave out? It seems unlikely that any future workload will cease to rely heavily on loads and stores to the stack and at small offsets from hot pointer registers, integer arithmetic/shifts/logical ops on registers, loading and operating on small literals, short branches including conditional branches (if anything I'd like to see more than just BEQZ/BNEZ).

Note that compressed or not is NOT a performance issue for your app's critical inner loops or hot functions that might have all kinds of currently unforeseen instructions in them. It's not going to matter if your specialised instructions are 32 or 48 or 64 bits in size. No matter what, they're going to be mixed in with a lot of instructions that WILL be small.

The main thing for the compressed instructions is that they hit on a large fraction of the boilerplate code in your app, on the standard libraries, and so forth.

I don't think 50 years of experience with that kind of code is going to be invalidated in a hurry.

 

In particular, my hope had been that at least the Decimal FP extensions could fit into the 32bit opcode ISA (in my mind, decimal FP should be a "first class" citizen, treated equally to binary FP).

I should think most people's level of caring about Decimal FP (or Decimal Integer, for that matter) is almost indistinguishable from zero. Standard software doesn't use it, and I doubt that will ever change. 

Coming back to the issue of backwards compatibility, can I ask an hypothetical question: if RISC V compressed was designed from scratch today, would the decision still be to go with giving it 75% of the total 32 bit opcode space.

It seems like a good amount to me.

The main competitor, Thumb2, gives 7/8ths (87.5%) of the opcode space to 16 bit instructions. Despite that, they've managed to get a heck of a lot of functionality into the 32 bit instruction space. Only having 16 registers helps that, of course.

IBM 360 gives 25% of the opcode space to 16 bit instructions. All they managed to fit in that was, mostly, 2-operand register-to-register arithmetic, and a bunch of simple opcodes with no operands. No memory operations at all. I think it's really great that RVC can do most of the loads and stores in a program (especially including function prolog/epilog) using 16 bit instructions and I wouldn't want to give that up.

Again: what would you leave out?

I'd be tempted to drop out the quad loads/stores -- or perhaps have RVC stick to XLEN/FLEN with the same opcode, whatever XLEN/FLEN happen to be. I wouldn't want to lose a whole bit and have to shorten immediates and offsets even more than they are now.

[Xan Phung]

On Tuesday, 4 April 2017 23:05:00 UTC+10, Bruce Hoult wrote:

I should think most people's level of caring about Decimal FP (or Decimal Integer, for that matter) is almost indistinguishable from zero. Standard software doesn't use it, and I doubt that will ever change. 

Pretty much all business software programmers would switch over to Decimal FP in a heart beat, if it had equal levels of hardware & language/compiler support as Binary FP.  It's a chicken & egg cycle of the hardware not being there so software doesn't use it.

Excel if it were written today (for a CPU with Decimal FP as a native hardware format) would use Decimal FP

Ironically, I suspect most binary FP will move over to Vector/SIMD/GPUs over time, so the day might come when Decimal FP takes over the core CPU itself...

 

Again: what would you leave out?

I'd be tempted to drop out the quad loads/stores -- or perhaps have RVC stick to XLEN/FLEN with the same opcode, whatever XLEN/FLEN happen to be. I wouldn't want to lose a whole bit and have to shorten immediates and offsets even more than they are now.

Below are for RV64:

Three instructions get dropped completely (code size expands by just 1~2% due to dropping of these instructions):

- ADDI4SPN

- LWSP/SWSP [32 bit stack ops are rare in 64bit systems]

These get 'downsized' to smaller operand sizes:

- LW/SW/FLW/FLD/FSD/FSW get cut down to 3 bit offsets, instead of 5 bit offsets [see attached table - look at the Green cells vs Orange cells on code size data effects 5bit vs 3bit operands - ie: pretty minimal]... **Bonus** can now also add 16 bit LBU/SB instructions as well.

- LUI gets reduced to 8 register format (instead of 32 registers)

  ==> becomes part of an ALU-immediate instruction, also providing operations like ANDI/right shifts

What's gained:

- 25% of opcode space becomes available for future extensions

- ALU-REGOPS are now in their own major opcode (separate from ALU-immediate major opcode) - tidies up a currently messy opcode in RVC v1.9

- ALU-REGOPS has 5 bit function field, up to 32 register to register operations are possible - if desired, can put in full set of multiply/divide/add/sub/logical

- byte store/loads added as 16bit instructions with 3 bit offsets as per above

==> the RV 'C' extension becomes more of a balanced/general purpose instruction set, which will also make it more robust to future workload changes vs the current RVC v1.9 bias to load/store 16 bit instructions (which alone take up 50% of C's encoding space). 

[Bruce Hoult]

On Tue, Apr 4, 2017 at 4:52 PM, Xan Phung <xan....@gmail.com> wrote:

On Tuesday, 4 April 2017 23:05:00 UTC+10, Bruce Hoult wrote:

I should think most people's level of caring about Decimal FP (or Decimal Integer, for that matter) is almost indistinguishable from zero. Standard software doesn't use it, and I doubt that will ever change. 

Pretty much all business software programmers would switch over to Decimal FP in a heart beat, if it had equal levels of hardware & language/compiler support as Binary FP.  It's a chicken & egg cycle of the hardware not being there so software doesn't use it.

I doubt it.

Numbers with factional parts have no place in accounting. Pick the smallest unit you care about (whether it's cents, hundredths of cents or whatever) and use 64 bit integers to store that. It's trivial to write output routines to insert a "." in the right place. Accounting software only ever does add, subtract, or multiply by a unit count or possibly by a tax rate (which is then immediately rounded to a whole number of the fundamental unit).

Before the common availability of 64 bit integers, double precision FP was useful for accounting as it can represent 53 bit integers and arithmetic on them exactly. There should *never* be a fractional part, so whether the FP is binary or decimal is irrelevant.

 Excel if it were written today (for a CPU with Decimal FP as a native hardware format) would use Decimal FP

Recalculation speed is seldom a limiting factor in Excel. 

Excel was written before PCs *had* FPUs. I was using it in 1986 on Motorola 68000 (not 020, 030 etc) with no FPU. Hell, it probably shared a lot of code with Multiplan which dates from 1982.

Below are for RV64:

Three instructions get dropped completely (code size expands by just 1~2% due to dropping of these instructions):

- ADDI4SPN

- LWSP/SWSP [32 bit stack ops are rare in 64bit systems]

These get 'downsized' to smaller operand sizes:

- LW/SW/FLW/FLD/FSD/FSW get cut down to 3 bit offsets, instead of 5 bit offsets [see attached table - look at the Green cells vs Orange cells on code size data effects 5bit vs 3bit operands - ie: pretty minimal]... **Bonus** can now also add 16 bit LBU/SB instructions as well.

- LUI gets reduced to 8 register format (instead of 32 registers)

  ==> becomes part of an ALU-immediate instruction, also providing operations like ANDI/right shifts

What's gained:

- 25% of opcode space becomes available for future extensions

- ALU-REGOPS are now in their own major opcode (separate from ALU-immediate major opcode) - tidies up a currently messy opcode in RVC v1.9

- ALU-REGOPS has 5 bit function field, up to 32 register to register operations are possible - if desired, can put in full set of multiply/divide/add/sub/logical

- byte store/loads added as 16bit instructions with 3 bit offsets as per above

==> the RV 'C' extension becomes more of a balanced/general purpose instruction set, which will also make it more robust to future workload changes vs the current RVC v1.9 bias to load/store 16 bit instructions (which alone take up 50% of C's encoding space). 

It's interesting.

I think the solution here is to make this a competitor to RVC, not a modification of it. Make and sell CPUs with this extension and let them fight it out in the marketplace.

[Rogier Brussee]

Op dinsdag 4 april 2017 16:15:03 UTC+2 schreef Bruce Hoult:

On Tue, Apr 4, 2017 at 4:52 PM, Xan Phung <xan....@gmail.com> wrote:

[snip]

 

Below are for RV64:

Three instructions get dropped completely (code size expands by just 1~2% due to dropping of these instructions):

- ADDI4SPN

- LWSP/SWSP [32 bit stack ops are rare in 64bit systems]

These get 'downsized' to smaller operand sizes:

- LW/SW/FLW/FLD/FSD/FSW get cut down to 3 bit offsets, instead of 5 bit offsets [see attached table - look at the Green cells vs Orange cells on code size data effects 5bit vs 3bit operands - ie: pretty minimal]... **Bonus** can now also add 16 bit LBU/SB instructions as well.

- LUI gets reduced to 8 register format (instead of 32 registers)

  ==> becomes part of an ALU-immediate instruction, also providing operations like ANDI/right shifts

What's gained:

- 25% of opcode space becomes available for future extensions

- ALU-REGOPS are now in their own major opcode (separate from ALU-immediate major opcode) - tidies up a currently messy opcode in RVC v1.9

- ALU-REGOPS has 5 bit function field, up to 32 register to register operations are possible - if desired, can put in full set of multiply/divide/add/sub/logical

- byte store/loads added as 16bit instructions with 3 bit offsets as per above

==> the RV 'C' extension becomes more of a balanced/general purpose instruction set, which will also make it more robust to future workload changes vs the current RVC v1.9 bias to load/store 16 bit instructions (which alone take up 50% of C's encoding space). 

It's interesting.

I think the solution here is to make this a competitor to RVC, not a modification of it. Make and sell CPUs with this extension and let them fight it out in the marketplace.

Xan Phung's great proposal  (lets call it Xcompressed for the moment) not only shows that a C like compression with only 50% of the primary opcodes taken is entirely doable and reasonable (and actually might even have advantages over RVC) but that an executable compiled for the RVC extension can be trivially, efficiently and transparently be transformed in an Xcompressed executable (and vice versa?). That's because both simply substitute RVI instructions in the asm, and only need to hint the compiler to use the same 3bit addressable registers (x8--x15 how do you call these?) if possible, not to mention being _identical_ for the part that gives >= 90% of the code reduction benefit.  

 

[Alex Bradbury]

I like the sound of this proposal, but it would obviously need
analysis on a larger benchmark set, and a look at the effect on
dynamic bytes fetched. Given that RVC is basically considered 'done' I
appreciate there's little motivation to do this. Although I can't
speak on behalf of the RISC-V Foundation, I'm sorry your attempt to
contribute here has perhaps come too late. For what it's worth, my
understanding is that at some point in the future specification
development will move over to the RISC-V Foundation, and from then on
there is a well-defined process of specifications having a public
comment period etc. At that point, if "people have already adopted the
draft standard" becomes an accepted reason to push back against
changes I think that would signal a pretty bleak future for RISC-V as
an independent standard.

Given that C is currently quite 'full', it's probably more likely that
cores optimised for a certain application will ignore the standard C
encoding and have their own compressed instruction set rather than
starting with C as the base, then using unused opcodes. Of course one
of the nice things about RISC-V is that this is possible, and the free
space Krste points out in RV32EC may help avoid the need to do this.
It seems a real shame that we're still stuck judging the options for
the C extension based primarily on SPEC, but I guess this brings us
back to Krste's "finished, now" vs "perfect, sometime" point.

Best,

Alex

[Bruce Hoult]

On Tue, Apr 4, 2017 at 6:54 PM, Alex Bradbury <a...@asbradbury.org> wrote:

It seems a real shame that we're still stuck judging the options for
the C extension based primarily on SPEC, but I guess this brings us
back to Krste's "finished, now" vs "perfect, sometime" point.

I'd like to see analysis done on, say, a full Ubuntu or Redhat distribution, including kernel, glibc, binutils, and all the other usual stuff.

Since those things actually exist for risc-v now, and can be automatically built and run (with qemu, if not on real hardware) with various options, this seems fairly easily achievable.

[Stefan O'Rear]

While it'd probably be better than SPEC, what we actually have for
Fedora is a quite biased sample due to dependencies. E.g. we never
managed to compile gtk+3 or Qt so any code pattern which only appears
in modern GUIs will be rather underrepresented. The Fedora image also
has no compilers other than gcc (and possibly ocamlopt?) so you'd
still be optimizing for the contingent history of the gcc port.

-s

[Rogier Brussee]

FWIW, Xan made his Xcompressed proposal in december and my own Xcondensed proposal that triggered Xan was on Oktober 6. So if anybody is to blame for being late it would be me for beating on the wrong drum.

 

Op dinsdag 4 april 2017 17:54:14 UTC+2 schreef asb:

[Rogier Brussee]

Out of curiosity. Does hardware that implements RVC actually exist? 

Op dinsdag 4 april 2017 18:33:48 UTC+2 schreef Rogier Brussee:

[Bruce Hoult]

Sure. Here's me with my HiFive1 board, which is RV32IMAC:

https://pbs.twimg.com/media/C3Ldl_MWIAMDmze.jpg

And here's one of my little hacks with it:

https://www.youtube.com/watch?v=0eDS6pGYsCE

--

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

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/90ccd345-2a66-4af4-8936-3415545adbef%40groups.riscv.org.

[David PATTERSON]

There are a lot of important instruction extensions that need to be developed for RISC-V to succeed that are still in their infancy or not yet started.

IMHO, until we make a lot of progress on them, not sure how important it is to work on 2nd pass on the few that have been defined

Dave

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/90ccd345-2a66-4af4-8936-3415545adbef%40groups.riscv.org.

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

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

[Rogier Brussee]

Dear Dave,

Agreed, except that using only half the major opcodes for C (i.e. something like Xan's Xcompressed proposal) creates more breathing room for those other extensions. Lurking on this list it seems that A) people want to create a 32 bit length extensions and B) they wonder where to put it given the opcode space they can use.  

Anyway, I have no interest in this other than a bit of vanity and a sympathy towards the whole idea of an open source procesor. Having in some sense thrown the stone in the C water hoping that somebody could do something useful with my Xcondensed proposal I felt (and feel!) that Xan's Xcompressed proposal that it inspired, could use my cheap support. I bow my head in deep respect for the people who have been doing the real work! 

Rogier

Op dinsdag 4 april 2017 23:05:15 UTC+2 schreef pattrsn:

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

[Xan Phung]

[Moving this into new thread]

Hi Bruce, thanks for suggesting the 'integer-only' workaround.  Glad you've highlighted this, so that I can make the case for why hardware guys need to get their act together on making Decimal FP a 1st class 'native' data type.  I think this is a **golden** 'first mover' opportunity for RISC V to leapfrog ARM & Intel.

(1) Why 'integer-only' workaround doesn't work - example situations:

- Currency conversions: some use cases might want FX calcs to nearest cent, others to 3 decimal places, others to 4 decimal places, others to 5 decimal places.  There isn't obvious 'integer only' implementation that I can see without doing all sorts of 10^X multiplies & divides & doing floor/ceiling calcs (& why should I be doing this in software when it's really the job of hardware people to give this to me?)

- Tax rates/import tariff rates/VAT/GST/franking credits: these are all typically legislated as percentages (=1/10^2 units) but sometimes you want to do 'compound' multiplication calcs, eg. an imported good might have a 10% tariff, and then have a further 20% VAT levied on top to the 10% tariff.  Doing this in Decimal FP is simple, easy and intuitive.  Doing this using 'integer only' calcs is bug prone and messy.

- Compound interest calculations & discounted cashflows: you might want to accrue compound interest at a 15% annual rate, but this could be done as monthly compound interest calcs, or as daily compound interest, or indeed quarterly compound interest.  Why should I be thinking about low level 10^X shifts or arcane binary floating point math issues, when I should just be focusing on higher level financial stuff?

- Reusable library APIs: some use cases might want cents as fundamental units, others might want higher precision.  Do we start putting in a separate 10^X exponent field into every library API that does decimal calcs?

(2) Is OpenOffice/Excel constrained by CPU/FPU?

I've got a 1MB spreadsheet that is fairly modest - it contains financial data for a small funds management business, approx 100,000 data inputs

However, it has a 'Dashboard' worksheet that contains approx 1000 'outputs' (20 cols x 50 rows).  Each of these outputs are formulas that combine various sets of the 100K inputs in various ways, and some contain exponential compound interest calcs.  (It does lots of floating point comparisons on the 100K inputs to determine which input subset gets included).

Despite the data set being modest, when you combine a 1000 output 'Dashboard' with 100K data inputs, plus do the compound interest calcs, a full spreadsheet recalc requires 10-100 billion floating point ops.  (Note: each exp fn is considered = 1 floating point op).

This takes approx 5-10secs to do each refresh.... which means whenever the user enters an additional row of data, there is a noticeable latency to the 'Dashboard' being updated.  It's a pretty poor user experience as a result.

That's for a modest funds management business.  I'm sure bigger companies would have even bigger data sets and bigger workloads.

Bottom line is that Excel/OpenOffice/iWork **do** require all the FP math speed up you hardware guys can give to it.

[Jacob Bachmeyer]

Xan Phung wrote:
> Hi Bruce, thanks for suggesting the 'integer-only' workaround. Glad
> you've highlighted this, so that I can make the case for why hardware
> guys need to get their act together on making Decimal FP a 1st class
> 'native' data type. I think this is a **golden** 'first mover'
> opportunity for RISC V to leapfrog ARM & Intel.

Fear not, decimal FP is the planned L standard extension.
Unfortunately, it will require more encoding space than is available in
the 32-bit length. The L extension will probably require either 48-bit
or 64-bit instructions.


-- Jacob

[Stefan O'Rear]

It sounds like we have some interest here in non-SPEC, non-gcc testing
of the C extension. I added RVC support to the Go compiler recently
and got a 29.6% reduction on the self-compiled compiler binary. With
a little more tweaking to prefer 16-bit instructions I got it up to
about 30%, although there are some size/latency tradeoffs that need to
be made carefully.

RV64GC is now the densest ISA supported by our Go fork by a
considerable margin (Go does not implement Thumb2). I did also
testing against all of the binaries in the Go standard and extended
standard distribution with several different backends. My results are
at https://gist.github.com/sorear/94abbe432efe0d57f31be05a8e01c930 ,
although this is an unfair comparison because the riscv backend is
only optimized for code size while the other backends are also
optimized for speed. (riscv means riscv64 here, the compiler for
those tests is https://github.com/sorear/riscv-go/tree/bb0d822c134a0dba8a9981b01a40c0df3b495fe5
).

On C's size: RV64GC implementations have all the space they could want
for standard and nonstandard extensions in the 48-bit and longer code
spaces. RV64G implementations without C have >75% of opcode space
free for 32-bit instructions. So the size of the C extension really
only matters for "which *standard* extensions can be supported on a
32-bit-only design". Personally I am not terribly concerned about
that.

>>
>> In particular, my hope had been that at least the Decimal FP extensions
>> could fit into the 32bit opcode ISA (in my mind, decimal FP should be a
>> "first class" citizen, treated equally to binary FP).
>
>
> I should think most people's level of caring about Decimal FP (or Decimal
> Integer, for that matter) is almost indistinguishable from zero. Standard
> software doesn't use it, and I doubt that will ever change.

We should be picking encoding lengths based on frequency, not "class".
I've written quite a bit of business decimal code and there are very
few places where I would use a decimal FMA (since decimal code and
linear algebra tend not to happen at the same time). So I am 100% OK
with 48-bit decimal FMAs, and actually pretty OK with all of decimal
going in 48-bit.

-s

[Bruce Hoult]

On Wed, Apr 5, 2017 at 6:31 AM, Stefan O'Rear <sor...@gmail.com> wrote:

It sounds like we have some interest here in non-SPEC, non-gcc testing

of the C extension.  I added RVC support to the Go compiler recently
and got a 29.6% reduction on the self-compiled compiler binary.  With
a little more tweaking to prefer 16-bit instructions I got it up to
about 30%, although there are some size/latency tradeoffs that need to
be made carefully.

RV64GC is now the densest ISA supported by our Go fork by a
considerable margin (Go does not implement Thumb2).  I did also
testing against all of the binaries in the Go standard and extended
standard distribution with several different backends.  My results are
at https://gist.github.com/sorear/94abbe432efe0d57f31be05a8e01c930 ,

Cool!

So with RV64GC you can get on average 51% more functionality in the same space than with ARM64, of 75% more functionality than with AMD64.

Why is S390 so big when it has variable length instructions?

 

>> In particular, my hope had been that at least the Decimal FP extensions
>> could fit into the 32bit opcode ISA (in my mind, decimal FP should be a
>> "first class" citizen, treated equally to binary FP).

We should be picking encoding lengths based on frequency, not "class".
I've written quite a bit of business decimal code and there are very
few places where I would use a decimal FMA (since decimal code and
linear algebra tend not to happen at the same time).  So I am 100% OK
with 48-bit decimal FMAs, and actually pretty OK with all of decimal
going in 48-bit.

Exactly.

1) Even in programs that use decimal FP there will be a very small percentage overall of actual decimal FP instructions, so their size doesn't matter for program size.

2) Their size also doesn't matter for program speed, unless it results in busting the instruction cache. See 1).

[Stefan O'Rear]

On Tue, Apr 4, 2017 at 6:26 PM, Xan Phung <xan....@gmail.com> wrote:
> [Moving this into new thread]
>
> Hi Bruce, thanks for suggesting the 'integer-only' workaround. Glad you've
> highlighted this, so that I can make the case for why hardware guys need to
> get their act together on making Decimal FP a 1st class 'native' data type.
> I think this is a **golden** 'first mover' opportunity for RISC V to
> leapfrog ARM & Intel.

So if I may ask a rather naive question as someone who does a lot of
currency stuff professionally, why decimal *floating* point? FP is
relevant in the sciences because scientific values have relative
error, but currency values typically have a precision known at compile
time.

-s

[Albert Cahalan]

Not that I think decimal FP is sane, but...

The important thing is to define a calling convention and make sure that it
works on all hardware. Without this, there will be major opposition to having
separate binaries. ARM and PowerPC have both suffered greatly from this
issue with floating-point, vector, and compactly-encoded instructions. When
there are 3 or 4 incompatible ways to do floats, it doesn't get good support.

The same goes for 16-bit and 128-bit binary floats, both of which are far
more useful than decimal floats.

FWIW, if you don't need the legal correctness of working with integers,
you don't need your floats to be decimal. Regular floats are just fine.

[Xan Phung]

To understand the nasty 'edge case' round errors with simple decimal fractions that you can get with binary FP, 

type this into your browser's Javascript console, which uses binary FP:

> 0.2+0.1

> 0.30000000000000004

Then do this type of comparison in Javascript (or any other binary FP based language):

> (0.2+0.1)==0.3

> false

==> Binary FP doesn't work well with decimal fraction arithmetic.

[Stefan O'Rear]

On Wed, Apr 5, 2017 at 12:02 AM, Xan Phung <xan....@gmail.com> wrote:
>
> To understand the nasty 'edge case' round errors with simple decimal
> fractions that you can get with binary FP,
> type this into your browser's Javascript console, which uses binary FP:
>
>> 0.2+0.1
>> 0.30000000000000004
>
> Then do this type of comparison in Javascript (or any other binary FP based
> language):
>
>> (0.2+0.1)==0.3
>> false

That's not what I asked. I understand the appeal of decimal
arithmetic. I don't understand why it should be **floating point** -
why should the decimal exponent be tracked by the CPU instead of by
the compiler? If I need to calculate something with 4 decimals of
precision, I want a data type that expresses that explicitly, rather
than the quantum=0.0001 only being manifest at runtime?

-s

[Michael Chapman]

On 05-Apr-17 03:26, Xan Phung wrote:

[Moving this into new thread]

Hi Bruce, thanks for suggesting the 'integer-only' workaround.  Glad you've highlighted this, so that I can make the case for why hardware guys need to get their act together on making Decimal FP a 1st class 'native' data type.  I think this is a **golden** 'first mover' opportunity for RISC V to leapfrog ARM & Intel.

(1) Why 'integer-only' workaround doesn't work - example situations:

- Tax rates/import tariff rates/VAT/GST/franking credits: these are all typically legislated as percentages (=1/10^2 units) but sometimes you want to do 'compound' multiplication calcs, eg. an imported good might have a 10% tariff, and then have a further 20% VAT levied on top to the 10% tariff.  Doing this in Decimal FP is simple, easy and intuitive.  Doing this using 'integer only' calcs is bug prone and messy.

These calculations if done according to the legal accounting standards are not easy and intuitive. Rounding/truncating has to be done the right way and the totals have to add up to the cent.

I remember when I worked on this kind of stuff, that it was essential that the arithmetic was done using scaled integer units. The result of a calculation involving VAT for individual items had to be an exact number of cents and not fractional cents. Then there had to be a separate calculation of the total over the whole batch of different bills - again in cents and had to add up to the cent. There were rules for items in a bill - each item had to show the amount of VAT in the price and then the total amount and total VAT (again there were precise rules about rounding and truncating effects).

Also costs had to be distributed to each item (even if bought in a batch). The individual costs then had to be round/truncated to cents, and the total had to be precise to the cent.

And yes, all this rounding/truncating stuff (in many places you had to truncate rather than round to nearest), was a right pain, but it would be even harder to get right with a floating decimal representation.

Have you ever wondered why when you do your mortgage payment table in excel you end up a different number of cents in some places?

These kind of calculations can only be done with fixed point numbers - not floating point. Whether those numbers are decimal or binary encoded or anything else makes no difference (assuming big enough numbers).

[Michael Chapman]

This is exactly why accounting programs use an integer number of cents.

Then $0.20 + $0.10 is always exactly $0.40

--

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/43024e1c-01fa-40ae-b0da-560da34d5bb3%40groups.riscv.org.

[Xan Phung]

On 5 April 2017 at 13:31, Stefan O'Rear <sor...@gmail.com> wrote:

I've written quite a bit of business decimal code and there are very
few places where I would use a decimal FMA (since decimal code and
linear algebra tend not to happen at the same time).

-s

The spreadsheet I mentioned in my previous email does a lot of calcs like this:

cost_basis = share_qty * share_price + brokerage_commission,

I'm not a compiler writer, but presumably this would compile into a FMA instruction, if they were written in a complied language & the compiler optimisation settings permitted FMA?

Another example - volume weighted calcs might be of the form:

for (int i = 0; i < n; i++) {

  total_cost += volume[i] * price[i]

}

volume_weighted_price = total_cost / total_volume

Presumably the inner loop would be translated into a single FMA instruction?

Also, the exp(x) function, or power(x) function is used quite a lot in compound interest calcs ... presumably the math library would use FMA-based Taylor series calcs or Newtown-Raphson to 'simulate' exp(x)?  (I'm not a math library writer so wouldn't know myself...)

[Bruce Hoult]

On Wed, Apr 5, 2017 at 10:02 AM, Xan Phung <xan....@gmail.com> wrote:

To understand the nasty 'edge case' round errors with simple decimal fractions that you can get with binary FP, 

type this into your browser's Javascript console, which uses binary FP:

> 0.2+0.1

> 0.30000000000000004

Then do this type of comparison in Javascript (or any other binary FP based language):

> (0.2+0.1)==0.3

> false

==> Binary FP doesn't work well with decimal fraction arithmetic.

Oh my god.

You are treating people who have been doing this stuff for 20 or 30 years as if they are 1st year students.

[David PATTERSON]

I don't get this debate. 

IEEE 754R has added decimal arithmetic to the IEEE standard for good reasons.

(e.g., you can't represent 0.1 exactly in floating point.)

They don't add to the standard without extensive discussions with many people from many backgrounds.

Why are we rehashing the wisdom of the IEEE standard on the RISC-V forum?

Dave

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

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

[Benjamin Scherrey]

On Wed, Apr 5, 2017 at 5:33 PM, David PATTERSON <pat...@cs.berkeley.edu> wrote:

I don't get this debate. 

IEEE 754R has added decimal arithmetic to the IEEE standard for good reasons.

(e.g., you can't represent 0.1 exactly in floating point.)

They don't add to the standard without extensive discussions with many people from many backgrounds.

Why are we rehashing the wisdom of the IEEE standard on the RISC-V forum?

Dave

Perhaps because the same standards organization gave us a math standard that can't represent 0.1 exactly in the first place? :-O

I'm just being slightly facetious here. I haven't studied up on FPD enough to have a strong opinion beyond I agree the problem needs to be solved. Are there any good docs on computational complexity of FPD vs FP? Is it feasible to create dedicated FPDPU devices that have similar computations per watt capabilities? If so then I'm quite excited about having this available as lots of the apps we build would benefit from it. I'd love to see FP die a well deserved death. I'm an old FORTH hack and we did everything with fixed decimal for a long time until floating point co-processors cheated and forced us to adopt FP. But is this a practical alternative, I simply don't know and would appreciate being educated about it.

  -- Ben Scherrey

On Wed, Apr 5, 2017 at 2:47 AM, Bruce Hoult <br...@hoult.org> wrote:

On Wed, Apr 5, 2017 at 10:02 AM, Xan Phung <xan....@gmail.com> wrote:

To understand the nasty 'edge case' round errors with simple decimal fractions that you can get with binary FP, 

type this into your browser's Javascript console, which uses binary FP:

> 0.2+0.1

> 0.30000000000000004

Then do this type of comparison in Javascript (or any other binary FP based language):

> (0.2+0.1)==0.3

> false

==> Binary FP doesn't work well with decimal fraction arithmetic.

Oh my god.

You are treating people who have been doing this stuff for 20 or 30 years as if they are 1st year students.

--
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/CAMU%2BEkzmcmLWJNqb5Xztj05Wtf8s9i7XtwfrKKRFXvB87X9sNw%40mail.gmail.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+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/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAHis7pm23WnE-1hkHsK9vqupgij4f1tmz7xJ-DBfZwgTin-%3Dbg%40mail.gmail.com.

[M Farkas-Dyck]

On 05/04/2017, David PATTERSON <pat...@cs.berkeley.edu> wrote:
> IEEE 754R has added decimal arithmetic to the IEEE standard for good
> reasons.
> (e.g., you can't represent 0.1 exactly in floating point.)

Well, sure, and i can't represent ⅓ exactly in binary OR decimal
floating point. If we care about this, we ought to use a
highly-composite base like 12 or 60.

Not saying i think it's a good idea either.

[David PATTERSON]

You really can't see practical difficulties of difference between fractions that can be represented exactly in decimal but not in binary vs fractions that cannot be represented exactly in either decimal or binary? 

And what you see in output can be exactly what is inside the computer?

Dave

[M Farkas-Dyck]

On 04/04/2017, Xan Phung <xan....@gmail.com> wrote:
> *(1) Why 'integer-only' workaround doesn't work - example situations*:
>
> - *Currency conversions*: some use cases might want FX calcs to nearest

> cent, others to 3 decimal places, others to 4 decimal places, others to 5
> decimal places. There isn't obvious 'integer only' implementation that I
> can see without doing all sorts of 10^X multiplies & divides & doing
> floor/ceiling calcs
> (& why should I be doing this in software when it's
> really the job of hardware people to give this to me?)

Why should we be doing this in hardware when it's so easy to do in
software and not useful in most use cases? It cuts both ways.

The other concerns of (1) are readily resolved with a custom data
type; whether its operations are emitted as machine instructions,
machine traps, or compiler intrinsics would not affect the source code
using it at all.

> *(2) Is OpenOffice/Excel constrained by CPU/FPU?*
>
> ...

>
> Bottom line is that Excel/OpenOffice/iWork **do** require all the FP math
> speed up you hardware guys can give to it.

By what i could find about OpenOffice, it seems to use binary
floating-point and decimal fixed-point
[https://wiki.openoffice.org/wiki/Documentation/BASIC_Guide/Numbers].

So yes, it wants speedy FP — in binary ☺

Not sure about the others, if they use decimal FP, or if i'm somehow
wrong about OO, it would be another question.

[M Farkas-Dyck]

On 05/04/2017, David PATTERSON <pat...@cs.berkeley.edu> wrote:
> And what you see in output can be exactly what is inside the computer?

Ahh, so this is the concern. But if it's critical to see the exact
value, i can simply read it in binary.

[David PATTERSON]

Idea is simply to match exactly what the accounting system shows, which is obviously decimal

Dave

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

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

[Alex Elsayed]

The issue is that floating point of _any_ kind - binary *or* decimal - is unacceptable for any financial use beyond the casual. it does not have the very-strictly defined rounding behavior that is a _regulatory requirement_.

For real financial usage, fixed-point is _mandatory_ - it is not a use case for decimal FP for reasons that are more fundamental than speed.

On Apr 5, 2017 11:49, "David PATTERSON" <pat...@cs.berkeley.edu> wrote:

Idea is simply to match exactly what the accounting system shows, which is obviously decimal

Dave

On Wed, Apr 5, 2017 at 11:17 AM, M Farkas-Dyck <m.fark...@gmail.com> wrote:

On 05/04/2017, David PATTERSON <pat...@cs.berkeley.edu> wrote:
> And what you see in output can be exactly what is inside the computer?

Ahh, so this is the concern. But if it's critical to see the exact
value, i can simply read it in binary.

--
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/CAL3m8eDDMbe8m-8NuZg6jH6kocBSMjARSjsoUfHNBP9J8Y4VgQ%40mail.gmail.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+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/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAHis7pn3mOnS%3DQ_bt_sKyAzWwEdOTFN%2BkNQZndAD%3Dh9qHhgoXA%40mail.gmail.com.

[Xan Phung]

If fine grain precision & rounding control is needed (beyond what Decimal64 or Decimal128 provide), I would use something like Java's BigDecimal class, which is (conceptually) just a "wrapper" around an arbitrary length array of integers, paired with a 10^X scaling factor (expressed as a 32bit integer, ie: enough for 2^32 decimal digits).  This class provides essentially infinite precision (and only rounds when explicitly instructed to round a number - otherwise does exact calculations).

It can do anything hard coded fixed point integer arithmetic does, but encapsulates away the complexity of 10^X scaling.  Conceptually it is nothing much more than an unbounded sequence of integers...

**But** here is the catch: on systems that have decimal FPUs (eg. IBM systems), BigDecimal is smart enough to 'switch' the underlying storage & math operations for numbers with less than 34 digits into Decimal128 ... ie: no loss of accuracy and all the semantics of 'integer' representation are preserved.  Only where a number is 'bigger' than 34 digits does BigDecimal start storing the number of separate integer array + scaling factor storage.

(IBM does this by building 'smarts' into their Java JIT compiler, that automatically optimises BigDecimal calcs, transparently to the programmer).

==> Bottom line is even for use cases that require infinite precision decimals and explicit control over rounding, typical implementations would still use Decimal128 for numbers that can be represented in <34 digits, and only resort to using an array of integers when >34 digits.

On 7 April 2017 at 01:03, Alex Elsayed <etern...@gmail.com> wrote:

The issue is that floating point of _any_ kind - binary *or* decimal - is unacceptable for any financial use beyond the casual. it does not have the very-strictly defined rounding behavior that is a _regulatory requirement_.

For real financial usage, fixed-point is _mandatory_ - it is not a use case for decimal FP for reasons that are more fundamental than speed.

On Apr 5, 2017 11:49, "David PATTERSON" <pat...@cs.berkeley.edu> wrote:

Idea is simply to match exactly what the accounting system shows, which is obviously decimal

Dave

On Wed, Apr 5, 2017 at 11:17 AM, M Farkas-Dyck <m.fark...@gmail.com> wrote:

On 05/04/2017, David PATTERSON <pat...@cs.berkeley.edu> wrote:
> And what you see in output can be exactly what is inside the computer?

Ahh, so this is the concern. But if it's critical to see the exact
value, i can simply read it in binary.

--
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/CAL3m8eDDMbe8m-8NuZg6jH6kocBSMjARSjsoUfHNBP9J8Y4VgQ%40mail.gmail.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/CAHis7pn3mOnS%3DQ_bt_sKyAzWwEdOTFN%2BkNQZndAD%3Dh9qHhgoXA%40mail.gmail.com.

--
You received this message because you are subscribed to a topic in the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/groups.riscv.org/d/topic/isa-dev/-gKcbXx9jJk/unsubscribe.
To unsubscribe from this group and all its topics, 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/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2Bfp8xJAXjNv4U7c-ivcEqkHi-mFAD_xwim673mt88J4MNdew%40mail.gmail.com.

[Alex Elsayed]

Sure, but then it's an optimization of a strategy that works equally well without it, rather than something programmers use directly. That concentrates the decfloat code into a few library routines, where there's little to no downside to using 48-bit instructions, much like any other extension that accelerates relatively rare code.

To unsubscribe from this group and all its topics, 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/CA%2B%2Bfp8xJAXjNv4U7c-ivcEqkHi-mFAD_xwim673mt88J4MNdew%40mail.gmail.com.

[Xan Phung]

As I understand it, IBM does the Decimal128 optimisation at the JIT (ie: inlined compiled code) level rather than at the BigDecimal library level.

ie: Decimal128 cpu instructions are inserted into each and every instance of client code using the BigDecimal library, not in the library itself.

In any event, it's not just me saying Decimal FPU will take over Binary FPU in the long term.... the quote below is attributed the 'father' of Binary FP/IEEE 754-1985 (who is also the guy who discovered Intel Pentium floating point bug):

“the continuing decline in the cost of processors and of memory will result (in applications intended for human interaction) in the displacement of substantially all binary floating-point arithmetic by decimal” 

Professor W. Kahan

 

To unsubscribe from this group and all its topics, 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/.

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

[promach]

Xan Phung:

The picture in the first post in this thread disappeared. Could you fix it ?

To unsubscribe from this group and all its topics, 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/CA%2B%2Bfp8xdOsoa9KLmTeZV7hQYZFTCd0DWZrkhseu2WzoFNsVHGw%40mail.gmail.com.

[Xan Phung]

Hi promach, thanks for your interest.

The table/picture from the first post is attached... it got accidentally deleted from Google Drive.

[Krste Asanovic]

I haven’t had time to check this more thoroughly, but the dark red right column for RISC-V should be dark green.

Those opcodes allow for close-to-infinite 26-bit opcode spaces, so this flat comparison is very misleading.

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/19ae83a9-03b4-41cf-a893-6850eb79291f%40groups.riscv.org.
<RV vs MIPS Opcode Utilisation.PNG>

[Xan Phung]

Hi Krste, it is true the comparison was a 'flat' comparison, and RISCV had the foresight to plan for future 48+bit instructions (which MIPS didn't, or arguably deliberately avoided doing).

Presumably MIPS (if it wanted to) could assign two of it's 11 reserved (26 bit) opcodes to also enable 48+bit instructions, to have equivalent 'long opcode' space to RISCV's 4 reserved 'long instruction' opcodes.

So perhaps a better way of making the comparison 'fair' is to convert two of the 11 dark green MIPS boxes to dark red...

[kr...@berkeley.edu]

>>>>> On Wed, 17 May 2017 05:01:11 -0700 (PDT), Xan Phung <xan....@gmail.com> said:

| Hi Krste, it is true the comparison was a 'flat' comparison, and RISCV had the
| foresight to plan for future 48+bit instructions (which MIPS didn't, or
| arguably deliberately avoided doing).

| Presumably MIPS (if it wanted to) could assign two of it's 11 reserved (26 bit)
| opcodes to also enable 48+bit instructions, to have equivalent 'long opcode'
| space to RISCV's 4 reserved 'long instruction' opcodes.

MIPS would have to fix branch offsets to allow branches to 16-bit
aligned targets, so might want to restrict to 64-bit extensions.
There's also branch delay slots to specify around, etc.

| So perhaps a better way of making the comparison 'fair' is to convert two of
| the 11 dark green MIPS boxes to dark red...

Once you want compression+performance of mixed 32+16-bit instruction
format, you have to deal with variable-length instructions, but can
then also cease worrying about running out of opcode space. So not
sure what the point of the table is.

Krste

| 15e06f55-3c23-4314-aff3-16e14fe69e97%40groups.riscv.org.

[promach]

Xan:

What do you mean by the sentence "MIPS has 64 opcodes x 26 bit encoding spaces vs RV64GC has 28 opcodes x 25 bit encoding spaces, ie: under one quarter the 32 bit instruction encoding space of MIPS) " ?

[Bruce Hoult]

On Mon, May 22, 2017 at 3:51 PM, promach <feiph...@gmail.com> wrote:

Xan:

What do you mean by the sentence "MIPS has 64 opcodes x 26 bit encoding spaces vs RV64GC has 28 opcodes x 25 bit encoding spaces, ie: under one quarter the 32 bit instruction encoding space of MIPS) " ?

It's a fairly trivial observation.

MIPS instructions are 32 bits. End of story. 6 bits (64 options) for opcode plus 26 bits for the other stuff = 32.

RISC-V 32 bit instructions always have the 2 least significant bits 11, leaving 30 bits for the actual instructions. Et voila, RISC-V has a quarter of the encoding space for "32 bit" instructions. And then an eighth of what remains (the next three bits 111) are reserved for instructions longer than 32 bits, so it's actually 21.875% not 25%

That doesn't necessarily mean that RISC-V has fewer useful "32 bit" (30 bit usable on RISC-V) instructions than MIPS. A lot of space has been reclaimed by decreasing offsets and immediates from 16 bits to 12 bits, and increasing LUI and AUIPC from 16 bits to 20 bits to compensate. You can still load 32 bit constants or branch or load/store to anywhere in 32 bit program space with two instructions, but the usually fairly rare cases of literals or offsets between 4096 and 65535 require two instructions in RISC-V vs one instruction in MIPS. That's a pretty small sacrifice in any case, but as it enables typically 50% or 60% of all instructions in the program to be replaced by 16 bit instructions it's a pretty big net win for RISC-V.

 

[David PATTERSON]

I guess "end of story" depends on popularity of MIPS-16 for applications. I know Thumb-2 is very popular for embedded apps, so I presume same holds for MIPS-16?

Dave

--

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

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

[Bruce Hoult]

Except that MIPS16 is more akin to Thumb1, with 16 and 32 bit instructions switched only by flow control instructions, not mixed arbitrarily instruction by instruction like Thumb2 or RISC-V.

 

On Mon, May 22, 2017 at 5:45 PM, David PATTERSON <pat...@cs.berkeley.edu> wrote:

I guess "end of story" depends on popularity of MIPS-16 for applications. I know Thumb-2 is very popular for embedded apps, so I presume same holds for MIPS-16?

Dave

On Mon, May 22, 2017 at 7:18 AM, Bruce Hoult <br...@hoult.org> wrote:

On Mon, May 22, 2017 at 3:51 PM, promach <feiph...@gmail.com> wrote:

Xan:

What do you mean by the sentence "MIPS has 64 opcodes x 26 bit encoding spaces vs RV64GC has 28 opcodes x 25 bit encoding spaces, ie: under one quarter the 32 bit instruction encoding space of MIPS) " ?

It's a fairly trivial observation.

MIPS instructions are 32 bits. End of story. 6 bits (64 options) for opcode plus 26 bits for the other stuff = 32.

RISC-V 32 bit instructions always have the 2 least significant bits 11, leaving 30 bits for the actual instructions. Et voila, RISC-V has a quarter of the encoding space for "32 bit" instructions. And then an eighth of what remains (the next three bits 111) are reserved for instructions longer than 32 bits, so it's actually 21.875% not 25%

That doesn't necessarily mean that RISC-V has fewer useful "32 bit" (30 bit usable on RISC-V) instructions than MIPS. A lot of space has been reclaimed by decreasing offsets and immediates from 16 bits to 12 bits, and increasing LUI and AUIPC from 16 bits to 20 bits to compensate. You can still load 32 bit constants or branch or load/store to anywhere in 32 bit program space with two instructions, but the usually fairly rare cases of literals or offsets between 4096 and 65535 require two instructions in RISC-V vs one instruction in MIPS. That's a pretty small sacrifice in any case, but as it enables typically 50% or 60% of all instructions in the program to be replaced by 16 bit instructions it's a pretty big net win for RISC-V.

 

--

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/CAMU%2BEkxSBAFYdqxPKt0_sL%2BhnaKEkCyO0MmY3NbesnJhOnKpnA%40mail.gmail.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+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/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAHis7pm2%2BL47RCG4cP-koGvf-j5kE3wrXVoCMTvS4vjF_6-2Uw%40mail.gmail.com.