Date   

Re: Emulation and M-mode involvement; M extension without DIV as use case.

Allen Baum
 

Just to beat a dead horse and say it another way: 
M-code that reads misa.M=1 is free to assume that it can execute DIV ops without any special precautions or support and have it execute properly.
If it can't do that, it isn't a spec compatible M-extension.
If DIV is emulated, it can't do that. QED.

Misalign is different. M-code knows that misaligned can happen - it has special mcause encodings just for that.
Therefore must take precautions to not execute a load or store that could possibly be misaligned (by the spec definition of misaligned), or take precautions to handle it.


On Tue, Apr 6, 2021 at 9:58 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
- Trapping (for emulation) to a "more privileged layer" is fine.
Nice to know. However, this is stated as a sufficient case and I do not immediately infer that it is a necessary condition.
It's just that a general M-mode-based trap-and-emulate mechanism is not architecturally defined. 
Or is it? You can use the same mechanism used for misaligned emulation. Nothing new is needed for DIV emulation.
Trapping into M-mode for an unexpected (to M-mode architecture) reason, is what is not allowed in a compliant M-mode implementation.
This statement is about as circular as you can get.
Hence the "more privileged layer" needs to be something higher that is transparent to the M-mode architecture.
Not at all. M-mode IS the most privileged level [Debug not withstanding].

I'm not sure I agree that "a general M-mode-based trap-and-emulate mechanism is not architecturally defined."
I think there are qualifying terms in there that need a bit more precision.

But I also don't agree that "Trapping into M-mode for an unexpected (to M-mode architecture) reason" is circular.
IT is possible to trap while in M-mode to M-mode - but only if M-mode is expecting the trap 
   (which means it must have saved a bunch of CSRs that will be overwritten first, among other things.)
For emulation, it must be able to emulate without that function in the emulation routine, and possibly must avoid doing anything that will cause further exceptions.
I'm not sure this violates the word "general" in the above statement I disagree with, which would explain why I disagree but would otherwise agree.

If the intent is transparent (even to M-mode code) emulation, it must at some level be aware - in which case it isn't transparent at all.
It might be transparent to some bit of M-mode code, but not to all of it, at which point... it isn't transparent.
IF the intent is to be both aware (so non-transparent) and emulate (so you could run some M-code module that used DIV) - that's doable, but far from optimal.
Instead of doing that you'd replace DIV with a call to the DIV emulation routine and be done with it. 
Of course, that's not an option if you're .include-ing an M-code binary image that you can't modify.

So:   truly transparent emulation (U mode up to   and   including M-mode) isn't possible.
However, transparent emulation (U mode up to but not including M-mode) is    possible.

So: what is being disagreed with here?






On Tue, Apr 6, 2021 at 8:30 PM ds2horner <ds2horner@...> wrote:

I've started a new thread.

TLDR; I see the argument of Two keys as circular and unnecessarily restrictive.

On 2021-04-06 1:35 p.m., Greg Favor wrote:
On Tue, Apr 6, 2021 at 10:16 AM ds2horner <ds2horner@...> wrote:

This is a radical departure from RVI Volume I specification which does not depend upon any particular Privilege Implementation.

The base integer ISA may be subset by a hardware implementation, but opcode traps and software
emulation by a more privileged layer must then be used to implement functionality not provided
by hardware.
and

Subsets of the base integer ISA might be useful for pedagogical purposes, but the base has been
defined such that there should be little incentive to subset a real hardware implementation beyond
omitting support for misaligned memory accesses and treating all SYSTEM instructions as a
single trap.
The latter section, and misaligned memory accesses in particular, fully anticipates M-mode [or its substitute] to handle the emulation as a fully aware feature. 

Two keys:

- Trap and emulation of misaligned accesses is architecturally defined as part of the M-mode architecture.

This was to allow a common means of implementing "I" base without requiring actual misaligned hardware.

This was especially important as load and stores interact with the RISCV Memory Models RVWMO & RVTSO in unique ways, and so a detailed discussion and "definition" is warranted.

Even so, M-mode code must ensure that it does not execute misaligned accesses in most "critical code segments".

The parallels to misaligned emulation in "I" and any of M in M is obvious.

There is less need of a common mechanism to emulate div and rem components of the M extension, only to ensure the same critical code constraints [not to use an emulated instruction in critical code].

However, there is no reason that M-mode could not be updated to provide a preferred way to emulate DIV or REM or any other instruction, even other instructions in "I".

There is therefore no fundamental significance to misaligned load/store over any other emulation.


- Trapping (for emulation) to a "more privileged layer" is fine.
Nice to know. However, this is stated as a sufficient case and I do not immediately infer that it is a necessary condition.
It's just that a general M-mode-based trap-and-emulate mechanism is not architecturally defined. 
Or is it? You can use the same mechanism used for misaligned emulation. Nothing new is needed for DIV emulation.
Trapping into M-mode for an unexpected (to M-mode architecture) reason, is what is not allowed in a compliant M-mode implementation.
This statement is about as circular as you can get.
Hence the "more privileged layer" needs to be something higher that is transparent to the M-mode architecture.

Not at all. M-mode IS the most privileged level [Debug not withstanding].

It deals with the nitty-gritty of the machine. It always needs to know what the harts' relevant capabilities are, so that it can either accommodate or post that its code  cannot run on this hart.

Lack of DIV is discoverable by M-mode in a variety of ways.

(

Especially for when M-mode code does a div instruction and that needs to trap somewhere to be emulated.
It will trap to M-mode
)

Greg

P.S. The understanding by Allen and myself flows down from other email threads - I don't remember on which TG list(s).

Too bad. It would be good to understand the genesis of this "must emulate at a more privileged level.

I don't believe it must apply to S-mode nor HS-mode.

HS-mode, arguably, as a matter of "normal function", which includes emulation, does trap to itself.

  Also, it's not unreasonable to argue that this architectural intent is not yet stated in an explicit enough manner in the arch specs.  Which is why this got clarified in some past discussion(s).

It is equally reasonable to argue that Two keys was not the architectural intent, but the spec was insufficiently explicit to unequivocally communicate its inferred permission to emulate anything.

E.g. If M-mode can emulate HS [which it can] then it can emulate HS emulating HS, ad nauseam  [via vertigo most likely]

 


Re: Emulation and M-mode involvement; M extension without DIV as use case.

Allen Baum
 

- Trapping (for emulation) to a "more privileged layer" is fine.
Nice to know. However, this is stated as a sufficient case and I do not immediately infer that it is a necessary condition.
It's just that a general M-mode-based trap-and-emulate mechanism is not architecturally defined. 
Or is it? You can use the same mechanism used for misaligned emulation. Nothing new is needed for DIV emulation.
Trapping into M-mode for an unexpected (to M-mode architecture) reason, is what is not allowed in a compliant M-mode implementation.
This statement is about as circular as you can get.
Hence the "more privileged layer" needs to be something higher that is transparent to the M-mode architecture.
Not at all. M-mode IS the most privileged level [Debug not withstanding].

I'm not sure I agree that "a general M-mode-based trap-and-emulate mechanism is not architecturally defined."
I think there are qualifying terms in there that need a bit more precision.

But I also don't agree that "Trapping into M-mode for an unexpected (to M-mode architecture) reason" is circular.
IT is possible to trap while in M-mode to M-mode - but only if M-mode is expecting the trap 
   (which means it must have saved a bunch of CSRs that will be overwritten first, among other things.)
For emulation, it must be able to emulate without that function in the emulation routine, and possibly must avoid doing anything that will cause further exceptions.
I'm not sure this violates the word "general" in the above statement I disagree with, which would explain why I disagree but would otherwise agree.

If the intent is transparent (even to M-mode code) emulation, it must at some level be aware - in which case it isn't transparent at all.
It might be transparent to some bit of M-mode code, but not to all of it, at which point... it isn't transparent.
IF the intent is to be both aware (so non-transparent) and emulate (so you could run some M-code module that used DIV) - that's doable, but far from optimal.
Instead of doing that you'd replace DIV with a call to the DIV emulation routine and be done with it. 
Of course, that's not an option if you're .include-ing an M-code binary image that you can't modify.

So:   truly transparent emulation (U mode up to   and   including M-mode) isn't possible.
However, transparent emulation (U mode up to but not including M-mode) is    possible.

So: what is being disagreed with here?






On Tue, Apr 6, 2021 at 8:30 PM ds2horner <ds2horner@...> wrote:

I've started a new thread.

TLDR; I see the argument of Two keys as circular and unnecessarily restrictive.

On 2021-04-06 1:35 p.m., Greg Favor wrote:
On Tue, Apr 6, 2021 at 10:16 AM ds2horner <ds2horner@...> wrote:

This is a radical departure from RVI Volume I specification which does not depend upon any particular Privilege Implementation.

The base integer ISA may be subset by a hardware implementation, but opcode traps and software
emulation by a more privileged layer must then be used to implement functionality not provided
by hardware.
and

Subsets of the base integer ISA might be useful for pedagogical purposes, but the base has been
defined such that there should be little incentive to subset a real hardware implementation beyond
omitting support for misaligned memory accesses and treating all SYSTEM instructions as a
single trap.
The latter section, and misaligned memory accesses in particular, fully anticipates M-mode [or its substitute] to handle the emulation as a fully aware feature. 

Two keys:

- Trap and emulation of misaligned accesses is architecturally defined as part of the M-mode architecture.

This was to allow a common means of implementing "I" base without requiring actual misaligned hardware.

This was especially important as load and stores interact with the RISCV Memory Models RVWMO & RVTSO in unique ways, and so a detailed discussion and "definition" is warranted.

Even so, M-mode code must ensure that it does not execute misaligned accesses in most "critical code segments".

The parallels to misaligned emulation in "I" and any of M in M is obvious.

There is less need of a common mechanism to emulate div and rem components of the M extension, only to ensure the same critical code constraints [not to use an emulated instruction in critical code].

However, there is no reason that M-mode could not be updated to provide a preferred way to emulate DIV or REM or any other instruction, even other instructions in "I".

There is therefore no fundamental significance to misaligned load/store over any other emulation.


- Trapping (for emulation) to a "more privileged layer" is fine.
Nice to know. However, this is stated as a sufficient case and I do not immediately infer that it is a necessary condition.
It's just that a general M-mode-based trap-and-emulate mechanism is not architecturally defined. 
Or is it? You can use the same mechanism used for misaligned emulation. Nothing new is needed for DIV emulation.
Trapping into M-mode for an unexpected (to M-mode architecture) reason, is what is not allowed in a compliant M-mode implementation.
This statement is about as circular as you can get.
Hence the "more privileged layer" needs to be something higher that is transparent to the M-mode architecture.

Not at all. M-mode IS the most privileged level [Debug not withstanding].

It deals with the nitty-gritty of the machine. It always needs to know what the harts' relevant capabilities are, so that it can either accommodate or post that its code  cannot run on this hart.

Lack of DIV is discoverable by M-mode in a variety of ways.

(

Especially for when M-mode code does a div instruction and that needs to trap somewhere to be emulated.
It will trap to M-mode
)

Greg

P.S. The understanding by Allen and myself flows down from other email threads - I don't remember on which TG list(s).

Too bad. It would be good to understand the genesis of this "must emulate at a more privileged level.

I don't believe it must apply to S-mode nor HS-mode.

HS-mode, arguably, as a matter of "normal function", which includes emulation, does trap to itself.

  Also, it's not unreasonable to argue that this architectural intent is not yet stated in an explicit enough manner in the arch specs.  Which is why this got clarified in some past discussion(s).

It is equally reasonable to argue that Two keys was not the architectural intent, but the spec was insufficiently explicit to unequivocally communicate its inferred permission to emulate anything.

E.g. If M-mode can emulate HS [which it can] then it can emulate HS emulating HS, ad nauseam  [via vertigo most likely]

 


Re: Emulation and M-mode involvement; M extension without DIV as use case.

ds2horner@...
 

I've started a new thread.

TLDR; I see the argument of Two keys as circular and unnecessarily restrictive.

On 2021-04-06 1:35 p.m., Greg Favor wrote:
On Tue, Apr 6, 2021 at 10:16 AM ds2horner <ds2horner@...> wrote:

This is a radical departure from RVI Volume I specification which does not depend upon any particular Privilege Implementation.

The base integer ISA may be subset by a hardware implementation, but opcode traps and software
emulation by a more privileged layer must then be used to implement functionality not provided
by hardware.
and

Subsets of the base integer ISA might be useful for pedagogical purposes, but the base has been
defined such that there should be little incentive to subset a real hardware implementation beyond
omitting support for misaligned memory accesses and treating all SYSTEM instructions as a
single trap.
The latter section, and misaligned memory accesses in particular, fully anticipates M-mode [or its substitute] to handle the emulation as a fully aware feature. 

Two keys:

- Trap and emulation of misaligned accesses is architecturally defined as part of the M-mode architecture.

This was to allow a common means of implementing "I" base without requiring actual misaligned hardware.

This was especially important as load and stores interact with the RISCV Memory Models RVWMO & RVTSO in unique ways, and so a detailed discussion and "definition" is warranted.

Even so, M-mode code must ensure that it does not execute misaligned accesses in most "critical code segments".

The parallels to misaligned emulation in "I" and any of M in M is obvious.

There is less need of a common mechanism to emulate div and rem components of the M extension, only to ensure the same critical code constraints [not to use an emulated instruction in critical code].

However, there is no reason that M-mode could not be updated to provide a preferred way to emulate DIV or REM or any other instruction, even other instructions in "I".

There is therefore no fundamental significance to misaligned load/store over any other emulation.


- Trapping (for emulation) to a "more privileged layer" is fine.
Nice to know. However, this is stated as a sufficient case and I do not immediately infer that it is a necessary condition.
It's just that a general M-mode-based trap-and-emulate mechanism is not architecturally defined. 
Or is it? You can use the same mechanism used for misaligned emulation. Nothing new is needed for DIV emulation.
Trapping into M-mode for an unexpected (to M-mode architecture) reason, is what is not allowed in a compliant M-mode implementation.
This statement is about as circular as you can get.
Hence the "more privileged layer" needs to be something higher that is transparent to the M-mode architecture.

Not at all. M-mode IS the most privileged level [Debug not withstanding].

It deals with the nitty-gritty of the machine. It always needs to know what the harts' relevant capabilities are, so that it can either accommodate or post that its code  cannot run on this hart.

Lack of DIV is discoverable by M-mode in a variety of ways.

(

Especially for when M-mode code does a div instruction and that needs to trap somewhere to be emulated.
It will trap to M-mode
)

Greg

P.S. The understanding by Allen and myself flows down from other email threads - I don't remember on which TG list(s).

Too bad. It would be good to understand the genesis of this "must emulate at a more privileged level.

I don't believe it must apply to S-mode nor HS-mode.

HS-mode, arguably, as a matter of "normal function", which includes emulation, does trap to itself.

  Also, it's not unreasonable to argue that this architectural intent is not yet stated in an explicit enough manner in the arch specs.  Which is why this got clarified in some past discussion(s).

It is equally reasonable to argue that Two keys was not the architectural intent, but the spec was insufficiently explicit to unequivocally communicate its inferred permission to emulate anything.

E.g. If M-mode can emulate HS [which it can] then it can emulate HS emulating HS, ad nauseam  [via vertigo most likely]

 


Re: Proposal: Zmmul - draft: -m-nodiv

Greg Favor
 

On Tue, Apr 6, 2021 at 10:16 AM ds2horner <ds2horner@...> wrote:

This is a radical departure from RVI Volume I specification which does not depend upon any particular Privilege Implementation.

The base integer ISA may be subset by a hardware implementation, but opcode traps and software
emulation by a more privileged layer must then be used to implement functionality not provided
by hardware.
and

Subsets of the base integer ISA might be useful for pedagogical purposes, but the base has been
defined such that there should be little incentive to subset a real hardware implementation beyond
omitting support for misaligned memory accesses and treating all SYSTEM instructions as a
single trap.
The latter section, and misaligned memory accesses in particular, fully anticipates M-mode [or its substitute] to handle the emulation as a fully aware feature. 

Two keys:

- Trap and emulation of misaligned accesses is architecturally defined as part of the M-mode architecture.

- Trapping (for emulation) to a "more privileged layer" is fine.  It's just that a general M-mode-based trap-and-emulate mechanism is not architecturally defined.  Trapping into M-mode for an unexpected (to M-mode architecture) reason, is what is not allowed in a compliant M-mode implementation.  Hence the "more privileged layer" needs to be something higher that is transparent to the M-mode architecture.  (Especially for when M-mode code does a div instruction and that needs to trap somewhere to be emulated.)

Greg

P.S. The understanding by Allen and myself flows down from other email threads - I don't remember on which TG list(s).  Also, it's not unreasonable to argue that this architectural intent is not yet stated in an explicit enough manner in the arch specs.  Which is why this got clarified in some past discussion(s).
 


Re: Proposal: Zmmul - draft: -m-nodiv

ds2horner@...
 


On 2021-04-06 11:47 a.m., Greg Favor wrote:
On Tue, Apr 6, 2021 at 6:42 AM <ds2horner@...> wrote:

Implementation of the divider on FPGAs is one example which takes a lot of logic, whereas the multiplier typically comes as a standard building block.

Agreed. The classic solution is to trap and emulate.

If the idea is that an implementation claims support for the M extension and implements the div instructions by trap-and-emulate to M-mode,
yes. That is the idea.
that would be a non-compliant implementation of the M extension.

This is a radical departure from RVI Volume I specification which does not depend upon any particular Privilege Implementation.

The base integer ISA may be subset by a hardware implementation, but opcode traps and software
emulation by a more privileged layer must then be used to implement functionality not provided
by hardware.
and

Subsets of the base integer ISA might be useful for pedagogical purposes, but the base has been
defined such that there should be little incentive to subset a real hardware implementation beyond
omitting support for misaligned memory accesses and treating all SYSTEM instructions as a
single trap.
The latter section, and misaligned memory accesses in particular, fully anticipates M-mode [or its substitute] to handle the emulation as a fully aware feature. 

Volume II says as much:

We briefly note that the entire privileged-level design described in this document could be replaced
with an entirely different privileged-level design without changing the unprivileged ISA, and pos-
sibly without even changing the ABI. In particular, this privileged specification was designed to
run existing popular operating systems, and so embodies the conventional level-based protection
model. Alternate privileged specifications could embody other more flexible protection-domain
models. For simplicity of expression, the text is written as if this was the only possible privileged
architecture.


  Allen addressed this on the original Zmmul thread on tech-unpriv as follows (which matches my understanding of the architectural intent as well):

If Mul is in HW, and Div is trapped - that is NOT the equivalent of M-extension, because if M-extension is present, then Mmode code should be able to execute a Div op and get the result - without trapping.. You could have M-mode code that was careful to save and restore state before it could possibly execute a Div op, (so a trap to Mmode could recursively trap to Mmode), or could be guaranteed to never execute a Div op and have Div eulation code - but that;s not the same thing.

Put differently, any trap-and-emulation of "supported" instructions must be transparent to the M-mode architecture to be compliant.

I disagree. This is not what I signed up for. It is not consistent with the original guiding principles and it causes unnecessary complications.

Why? Is it intended for "truth in advertising"? The M label means efficient implementation? If this is the intent, it cannot be justified, as a very simple hardware implementation can just count the number of divisor subtractions until the sign changes, and thus be compliant.

(Practically speaking this probably would involve creation of a special M-mode like "emulation" privilege mode - analogous to Alpha PALcode for example.)

I am all in favour of enhancing the emulation capabilities in M-mode, but I see little reason to ensure M-mode cannot be aware of the feature.

M-mode was always intended to be the Alpha PALcode equivalent and the final arbitrator of Machine functioning.


Greg


Re: Proposal: Zmmul - draft: -m-nodiv

mark
 

I think this an example of why there may be profile variances for privilege modes. Waiting for Krste to get to closure on this.

On Tue, Apr 6, 2021 at 8:47 AM Greg Favor <gfavor@...> wrote:
On Tue, Apr 6, 2021 at 6:42 AM <ds2horner@...> wrote:

Implementation of the divider on FPGAs is one example which takes a lot of logic, whereas the multiplier typically comes as a standard building block.

Agreed. The classic solution is to trap and emulate.

If the idea is that an implementation claims support for the M extension and implements the div instructions by trap-and-emulate to M-mode, that would be a non-compliant implementation of the M extension.  Allen addressed this on the original Zmmul thread on tech-unpriv as follows (which matches my understanding of the architectural intent as well):

If Mul is in HW, and Div is trapped - that is NOT the equivalent of M-extension, because if M-extension is present, then Mmode code should be able to execute a Div op and get the result - without trapping.. You could have M-mode code that was careful to save and restore state before it could possibly execute a Div op, (so a trap to Mmode could recursively trap to Mmode), or could be guaranteed to never execute a Div op and have Div eulation code - but that;s not the same thing.

Put differently, any trap-and-emulation of "supported" instructions must be transparent to the M-mode architecture to be compliant.  (Practically speaking this probably would involve creation of a special M-mode like "emulation" privilege mode - analogous to Alpha PALcode for example.)

Greg


Re: Proposal: Zmmul - draft: -m-nodiv

Greg Favor
 

On Tue, Apr 6, 2021 at 6:42 AM <ds2horner@...> wrote:

Implementation of the divider on FPGAs is one example which takes a lot of logic, whereas the multiplier typically comes as a standard building block.

Agreed. The classic solution is to trap and emulate.

If the idea is that an implementation claims support for the M extension and implements the div instructions by trap-and-emulate to M-mode, that would be a non-compliant implementation of the M extension.  Allen addressed this on the original Zmmul thread on tech-unpriv as follows (which matches my understanding of the architectural intent as well):

If Mul is in HW, and Div is trapped - that is NOT the equivalent of M-extension, because if M-extension is present, then Mmode code should be able to execute a Div op and get the result - without trapping.. You could have M-mode code that was careful to save and restore state before it could possibly execute a Div op, (so a trap to Mmode could recursively trap to Mmode), or could be guaranteed to never execute a Div op and have Div eulation code - but that;s not the same thing.

Put differently, any trap-and-emulation of "supported" instructions must be transparent to the M-mode architecture to be compliant.  (Practically speaking this probably would involve creation of a special M-mode like "emulation" privilege mode - analogous to Alpha PALcode for example.)

Greg


Re: Proposal: Zmmul - draft: -m-nodiv

ds2horner@...
 


On 2021-04-06 5:12 a.m., Tariq Kurd wrote:

>Is this a solution to a non-existent problem?

The context for the question, which is broader than this specific example, is important.

That is why I did not intend my note for the list, and asked that it be ignored.

 

This is a real problem – which has come up before.

And I expect, the issue will continue to arise until we have clearly defined

  • profiles and
  • profile-strings and
  • compiler directives and
  • marketing jargon and
  • tactical expediencies and
  • political realities and
  • RISCV.org visions and
  • RISCV architecture flexibility and
  • elective [also/prominently read Custom] feature support

sufficiently that we can clearly address such problems.

Implementation of the divider on FPGAs is one example which takes a lot of logic, whereas the multiplier typically comes as a standard building block.

Agreed. The classic solution is to trap and emulate.

If the manufacturer/designer does not want to trap on divide/rem as unsupported [and thus illegal instructions] then they have larger issues to deal with.

One of them is the increased testing required for each compile to ensure that the compiler complied with a obscure flag set.

Silently ignoring a directive/command/instruction is always risky.

Hence, the pagan question was asked. 

Are we doing the right thing? If we support other aspects and thus frame the situation correctly is there really a problem? 

There are other ways of providing a "cpu model" profile.

Most vendors make changes to the tool chain, with donated code, to special case [with special code checks for] each of their new models.

We collectively have too many models, the incumbents win in such a playing field.

Rather, we could provide a "model profile" to be used universally. The incumbents can use it too.

One approach is to provide cpu cycles for each instruction [or instruction type], with MAX indicating don't use.

There are other approaches, but to me it is obvious that the game is rigged against us as it stands.

I mention much more in the email that also needs a context, if any are interested perhaps we set up a separate thread.

 

Divide/remainder are infrequently used, cost area and add complexity to a small embedded design.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of ds2horner@...
Sent: 01 April 2021 14:22
To: tech-unprivileged@...
Subject: Re: [RISC-V] [tech-unprivileged] Proposal: Zmmul - draft: -m-nodiv

 

Please ignore this post.

It was intended for Mark only.

On 2021-04-01 8:49 a.m., ds2horner via lists.riscv.org wrote:

This is a example of the churn we are going through because of profile and sub-set assumptions.

Yes we have to work through examples to do a POC of the approach of profile naming.

But because the larger context is not defined or even identified, and the objectives for the naming practices are not even known, we have this abrasive process, if not divisive. To give credit to the participants, every one has been very civil, but debates are arising.

Your point is germane.

Where does this name string apply?

Why would one actually want or need to use it?

The rationale for this sub-extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement. 

In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops, but need standard tool support that would use

There is no explanation here.

There are assumptions that it will be helpful, but no tie in to "honest marketing", compiler requirements or certification mandates.

Is this a solution to a non-existent problem? Is tghe problem technical, philosophical  or[/and] political?

I have avoided joining this discussion because it is immediately related to ours, I did not  want to impose my idea of relevance nor appear oppositional.

Especially given the fact that there have been complaints about my involvement/attitude/assertiveness.

On 2021-03-31 9:56 a.m., mark wrote:

Is there a difference between not using div and having Zmmul and not M? How will this be reflected in the elf flags (or whatever they are called)?

 

thanks

Mark

 

On Wed, Mar 31, 2021 at 1:35 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

>I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

According to this:

 

https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

 

RISCV GCC already supports –mno-div, which presumably also excludes REM?! Maybe Jim can confirm.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Allen Baum
Sent: 31 March 2021 02:43
To: Greg Favor <gfavor@...>
Cc: tech-unprivileged@...; RISC-V Help <help@...>; Ken Dockser <kdockser@...>
Subject: Re: [RISC-V] [tech-unprivileged] Proposal: Zmmul - draft

 

Here is v 0.3:
There are supposed to be "suitable required reviewers" from outside the proposer's organization.
It isn't clear to me if the relevant "standing committee" (this term should be replaced with Horizontal Committee or ISA Committed in  all the policy documents...) chooses reviewers or I do.

It also isn't clear to me that this hasn't already happened.


If it hasn't and it's up to me, Ken and Paul are the obvious choices, since they have been commenting on this already.

If they agree, then the next steps are to make any changes requested by them, and to fill out the Fastrack D.O.D checklist.

 

Then, if Krste and Chuanhua, (as chairs of the Unpriv IC), and Greg and Paul (as reviewers) agree, we can go for public review by announcing via email to ISA -dev and tech mailing lists.

I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

 

 

Proposal for fast track multiply extension

Chapter x+1
“Zmmul” Multiply extension v.3

The Zmmul extension implements multiply operations which are a proper subset of the M-extension.

Definition:
This extension defines instructions comprising the MUL, MULH, MUHU and MULHSU and (for RV64) MULW instructions of the M-extension without implementing the DIV* or REM* instructions.  
The ISA string is Zmmul.

[[The reasons for seeking fast track ratification: this is a proper subset of the existing M-extension:
   The opcode encodings          are identical to those in the M-extension.
   The instruction mnemonics are identical to those in the M-extension.
   The instruction semantics   are identical to those in the M-extension.

   No additional tests beyond those already being done for the M-extension are required.

   Both Spike and Sail already implement these instructions.
   No other instructions, new CSRs or new state are added.
]]


This extension explicitly allows the DIV and REM opcodes to cause illegal-instruction exceptions or be used for (non-conforming) custom ops. It therefore cannot co-exist with the M-extension. It has no dependencies on other extensions and can be used in any combination that the M-extension could be used.

 Note: a profile could require trapping DEV* and REM* with an illegal instruction exception if it were desirable to enable emulation of the M-extension using Zmmul, but the extension does not require it.

Rationale:
The rationale for this extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement.
In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops.

 

 

On Wed, Mar 24, 2021 at 11:07 PM Allen Baum <allen.baum@...> wrote:

Indeed  Zfinx is a counter-example and a good one.

Now I don't remember the context of the assertion that we can't have an extension which removes a feature/instruction, 

but as I think about it was literally more like "remove DIV from the M-extension" rather than "define a new extension like X but without Y"

OK, back to Zmmul then.

 

On Wed, Mar 24, 2021 at 3:54 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:

OK, v.2, renamed Zxmul because Paul pointed out that there is no such thing as a sub-extension defined anywhere, and Zm<> implies it is adding something into the M-extension instead of what this is doing - removing something. Or at least that's how I understand it.

 

It seems like if this can't be called Zmmul, then it should be called Zimul, i.e. isn't 'i' the appropriate second letter?

 

And just to ask: Are extension names like 'Zmnodiv' or 'Zmmul' - that represent a subset of an existing extension - disallowed?  Zmmul is not that much different than the Scalar Crypto extension wanting a Zbk extension as a group or subset of BitManip instructions.

 

Greg 


Re: Proposal: Zmmul - draft: -m-nodiv

Tariq Kurd
 

>Is this a solution to a non-existent problem?

 

This is a real problem – which has come up before. Implementation of the divider on FPGAs is one example which takes a lot of logic, whereas the multiplier typically comes as a standard building block.

 

Divide/remainder are infrequently used, cost area and add complexity to a small embedded design.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of ds2horner@...
Sent: 01 April 2021 14:22
To: tech-unprivileged@...
Subject: Re: [RISC-V] [tech-unprivileged] Proposal: Zmmul - draft: -m-nodiv

 

Please ignore this post.

It was intended for Mark only.

On 2021-04-01 8:49 a.m., ds2horner via lists.riscv.org wrote:

This is a example of the churn we are going through because of profile and sub-set assumptions.

Yes we have to work through examples to do a POC of the approach of profile naming.

But because the larger context is not defined or even identified, and the objectives for the naming practices are not even known, we have this abrasive process, if not divisive. To give credit to the participants, every one has been very civil, but debates are arising.

Your point is germane.

Where does this name string apply?

Why would one actually want or need to use it?

The rationale for this sub-extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement. 

In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops, but need standard tool support that would use

There is no explanation here.

There are assumptions that it will be helpful, but no tie in to "honest marketing", compiler requirements or certification mandates.

Is this a solution to a non-existent problem? Is tghe problem technical, philosophical  or[/and] political?

I have avoided joining this discussion because it is immediately related to ours, I did not  want to impose my idea of relevance nor appear oppositional.

Especially given the fact that there have been complaints about my involvement/attitude/assertiveness.

On 2021-03-31 9:56 a.m., mark wrote:

Is there a difference between not using div and having Zmmul and not M? How will this be reflected in the elf flags (or whatever they are called)?

 

thanks

Mark

 

On Wed, Mar 31, 2021 at 1:35 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

>I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

According to this:

 

https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

 

RISCV GCC already supports –mno-div, which presumably also excludes REM?! Maybe Jim can confirm.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Allen Baum
Sent: 31 March 2021 02:43
To: Greg Favor <gfavor@...>
Cc: tech-unprivileged@...; RISC-V Help <help@...>; Ken Dockser <kdockser@...>
Subject: Re: [RISC-V] [tech-unprivileged] Proposal: Zmmul - draft

 

Here is v 0.3:
There are supposed to be "suitable required reviewers" from outside the proposer's organization.
It isn't clear to me if the relevant "standing committee" (this term should be replaced with Horizontal Committee or ISA Committed in  all the policy documents...) chooses reviewers or I do.

It also isn't clear to me that this hasn't already happened.


If it hasn't and it's up to me, Ken and Paul are the obvious choices, since they have been commenting on this already.

If they agree, then the next steps are to make any changes requested by them, and to fill out the Fastrack D.O.D checklist.

 

Then, if Krste and Chuanhua, (as chairs of the Unpriv IC), and Greg and Paul (as reviewers) agree, we can go for public review by announcing via email to ISA -dev and tech mailing lists.

I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

 

 

Proposal for fast track multiply extension

Chapter x+1
“Zmmul” Multiply extension v.3

The Zmmul extension implements multiply operations which are a proper subset of the M-extension.

Definition:
This extension defines instructions comprising the MUL, MULH, MUHU and MULHSU and (for RV64) MULW instructions of the M-extension without implementing the DIV* or REM* instructions.  
The ISA string is Zmmul.

[[The reasons for seeking fast track ratification: this is a proper subset of the existing M-extension:
   The opcode encodings          are identical to those in the M-extension.
   The instruction mnemonics are identical to those in the M-extension.
   The instruction semantics   are identical to those in the M-extension.

   No additional tests beyond those already being done for the M-extension are required.

   Both Spike and Sail already implement these instructions.
   No other instructions, new CSRs or new state are added.
]]


This extension explicitly allows the DIV and REM opcodes to cause illegal-instruction exceptions or be used for (non-conforming) custom ops. It therefore cannot co-exist with the M-extension. It has no dependencies on other extensions and can be used in any combination that the M-extension could be used.

 Note: a profile could require trapping DEV* and REM* with an illegal instruction exception if it were desirable to enable emulation of the M-extension using Zmmul, but the extension does not require it.

Rationale:
The rationale for this extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement.
In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops.

 

 

On Wed, Mar 24, 2021 at 11:07 PM Allen Baum <allen.baum@...> wrote:

Indeed  Zfinx is a counter-example and a good one.

Now I don't remember the context of the assertion that we can't have an extension which removes a feature/instruction, 

but as I think about it was literally more like "remove DIV from the M-extension" rather than "define a new extension like X but without Y"

OK, back to Zmmul then.

 

On Wed, Mar 24, 2021 at 3:54 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:

OK, v.2, renamed Zxmul because Paul pointed out that there is no such thing as a sub-extension defined anywhere, and Zm<> implies it is adding something into the M-extension instead of what this is doing - removing something. Or at least that's how I understand it.

 

It seems like if this can't be called Zmmul, then it should be called Zimul, i.e. isn't 'i' the appropriate second letter?

 

And just to ask: Are extension names like 'Zmnodiv' or 'Zmmul' - that represent a subset of an existing extension - disallowed?  Zmmul is not that much different than the Scalar Crypto extension wanting a Zbk extension as a group or subset of BitManip instructions.

 

Greg 


Re: Proposal: Zmmul - draft: -m-nodiv

ds2horner@...
 

Please ignore this post.

It was intended for Mark only.

On 2021-04-01 8:49 a.m., ds2horner via lists.riscv.org wrote:

This is a example of the churn we are going through because of profile and sub-set assumptions.

Yes we have to work through examples to do a POC of the approach of profile naming.

But because the larger context is not defined or even identified, and the objectives for the naming practices are not even known, we have this abrasive process, if not divisive. To give credit to the participants, every one has been very civil, but debates are arising.

Your point is germane.

Where does this name string apply?

Why would one actually want or need to use it?

The rationale for this sub-extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement. 

In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops, but need standard tool support that would use

There is no explanation here.

There are assumptions that it will be helpful, but no tie in to "honest marketing", compiler requirements or certification mandates.

Is this a solution to a non-existent problem? Is tghe problem technical, philosophical  or[/and] political?

I have avoided joining this discussion because it is immediately related to ours, I did not  want to impose my idea of relevance nor appear oppositional.

Especially given the fact that there have been complaints about my involvement/attitude/assertiveness.

On 2021-03-31 9:56 a.m., mark wrote:
Is there a difference between not using div and having Zmmul and not M? How will this be reflected in the elf flags (or whatever they are called)?

thanks
Mark

On Wed, Mar 31, 2021 at 1:35 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

>I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

According to this:

 

https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

 

RISCV GCC already supports –mno-div, which presumably also excludes REM?! Maybe Jim can confirm.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Allen Baum
Sent: 31 March 2021 02:43
To: Greg Favor <gfavor@...>
Cc: tech-unprivileged@...; RISC-V Help <help@...>; Ken Dockser <kdockser@...>
Subject: Re: [RISC-V] [tech-unprivileged] Proposal: Zmmul - draft

 

Here is v 0.3:
There are supposed to be "suitable required reviewers" from outside the proposer's organization.
It isn't clear to me if the relevant "standing committee" (this term should be replaced with Horizontal Committee or ISA Committed in  all the policy documents...) chooses reviewers or I do.

It also isn't clear to me that this hasn't already happened.


If it hasn't and it's up to me, Ken and Paul are the obvious choices, since they have been commenting on this already.

If they agree, then the next steps are to make any changes requested by them, and to fill out the Fastrack D.O.D checklist.

 

Then, if Krste and Chuanhua, (as chairs of the Unpriv IC), and Greg and Paul (as reviewers) agree, we can go for public review by announcing via email to ISA -dev and tech mailing lists.

I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

 

 

Proposal for fast track multiply extension

Chapter x+1
“Zmmul” Multiply extension v.3

The Zmmul extension implements multiply operations which are a proper subset of the M-extension.

Definition:
This extension defines instructions comprising the MUL, MULH, MUHU and MULHSU and (for RV64) MULW instructions of the M-extension without implementing the DIV* or REM* instructions.  
The ISA string is Zmmul.

[[The reasons for seeking fast track ratification: this is a proper subset of the existing M-extension:
   The opcode encodings          are identical to those in the M-extension.
   The instruction mnemonics are identical to those in the M-extension.
   The instruction semantics   are identical to those in the M-extension.

   No additional tests beyond those already being done for the M-extension are required.

   Both Spike and Sail already implement these instructions.
   No other instructions, new CSRs or new state are added.
]]


This extension explicitly allows the DIV and REM opcodes to cause illegal-instruction exceptions or be used for (non-conforming) custom ops. It therefore cannot co-exist with the M-extension. It has no dependencies on other extensions and can be used in any combination that the M-extension could be used.

 Note: a profile could require trapping DEV* and REM* with an illegal instruction exception if it were desirable to enable emulation of the M-extension using Zmmul, but the extension does not require it.

Rationale:
The rationale for this extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement.
In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops.

 

 

On Wed, Mar 24, 2021 at 11:07 PM Allen Baum <allen.baum@...> wrote:

Indeed  Zfinx is a counter-example and a good one.

Now I don't remember the context of the assertion that we can't have an extension which removes a feature/instruction, 

but as I think about it was literally more like "remove DIV from the M-extension" rather than "define a new extension like X but without Y"

OK, back to Zmmul then.

 

On Wed, Mar 24, 2021 at 3:54 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:

OK, v.2, renamed Zxmul because Paul pointed out that there is no such thing as a sub-extension defined anywhere, and Zm<> implies it is adding something into the M-extension instead of what this is doing - removing something. Or at least that's how I understand it.

 

It seems like if this can't be called Zmmul, then it should be called Zimul, i.e. isn't 'i' the appropriate second letter?

 

And just to ask: Are extension names like 'Zmnodiv' or 'Zmmul' - that represent a subset of an existing extension - disallowed?  Zmmul is not that much different than the Scalar Crypto extension wanting a Zbk extension as a group or subset of BitManip instructions.

 

Greg 


Re: Proposal: Zmmul - draft: -m-nodiv

ds2horner@...
 

This is a example of the churn we are going through because of profile and sub-set assumptions.

Yes we have to work through examples to do a POC of the approach of profile naming.

But because the larger context is not defined or even identified, and the objectives for the naming practices are not even known, we have this abrasive process, if not divisive. To give credit to the participants, every one has been very civil, but debates are arising.

Your point is germane.

Where does this name string apply?

Why would one actually want or need to use it?

The rationale for this sub-extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement. 

In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops, but need standard tool support that would use

There is no explanation here.

There are assumptions that it will be helpful, but no tie in to "honest marketing", compiler requirements or certification mandates.

Is this a solution to a non-existent problem? Is tghe problem technical, philosophical  or[/and] political?

I have avoided joining this discussion because it is immediately related to ours, I did not  want to impose my idea of relevance nor appear oppositional.

Especially given the fact that there have been complaints about my involvement/attitude/assertiveness.

On 2021-03-31 9:56 a.m., mark wrote:
Is there a difference between not using div and having Zmmul and not M? How will this be reflected in the elf flags (or whatever they are called)?

thanks
Mark

On Wed, Mar 31, 2021 at 1:35 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

>I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

According to this:

 

https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

 

RISCV GCC already supports –mno-div, which presumably also excludes REM?! Maybe Jim can confirm.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Allen Baum
Sent: 31 March 2021 02:43
To: Greg Favor <gfavor@...>
Cc: tech-unprivileged@...; RISC-V Help <help@...>; Ken Dockser <kdockser@...>
Subject: Re: [RISC-V] [tech-unprivileged] Proposal: Zmmul - draft

 

Here is v 0.3:
There are supposed to be "suitable required reviewers" from outside the proposer's organization.
It isn't clear to me if the relevant "standing committee" (this term should be replaced with Horizontal Committee or ISA Committed in  all the policy documents...) chooses reviewers or I do.

It also isn't clear to me that this hasn't already happened.


If it hasn't and it's up to me, Ken and Paul are the obvious choices, since they have been commenting on this already.

If they agree, then the next steps are to make any changes requested by them, and to fill out the Fastrack D.O.D checklist.

 

Then, if Krste and Chuanhua, (as chairs of the Unpriv IC), and Greg and Paul (as reviewers) agree, we can go for public review by announcing via email to ISA -dev and tech mailing lists.

I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

 

 

Proposal for fast track multiply extension

Chapter x+1
“Zmmul” Multiply extension v.3

The Zmmul extension implements multiply operations which are a proper subset of the M-extension.

Definition:
This extension defines instructions comprising the MUL, MULH, MUHU and MULHSU and (for RV64) MULW instructions of the M-extension without implementing the DIV* or REM* instructions.  
The ISA string is Zmmul.

[[The reasons for seeking fast track ratification: this is a proper subset of the existing M-extension:
   The opcode encodings          are identical to those in the M-extension.
   The instruction mnemonics are identical to those in the M-extension.
   The instruction semantics   are identical to those in the M-extension.

   No additional tests beyond those already being done for the M-extension are required.

   Both Spike and Sail already implement these instructions.
   No other instructions, new CSRs or new state are added.
]]


This extension explicitly allows the DIV and REM opcodes to cause illegal-instruction exceptions or be used for (non-conforming) custom ops. It therefore cannot co-exist with the M-extension. It has no dependencies on other extensions and can be used in any combination that the M-extension could be used.

 Note: a profile could require trapping DEV* and REM* with an illegal instruction exception if it were desirable to enable emulation of the M-extension using Zmmul, but the extension does not require it.

Rationale:
The rationale for this extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement.
In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops.

 

 

On Wed, Mar 24, 2021 at 11:07 PM Allen Baum <allen.baum@...> wrote:

Indeed  Zfinx is a counter-example and a good one.

Now I don't remember the context of the assertion that we can't have an extension which removes a feature/instruction, 

but as I think about it was literally more like "remove DIV from the M-extension" rather than "define a new extension like X but without Y"

OK, back to Zmmul then.

 

On Wed, Mar 24, 2021 at 3:54 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:

OK, v.2, renamed Zxmul because Paul pointed out that there is no such thing as a sub-extension defined anywhere, and Zm<> implies it is adding something into the M-extension instead of what this is doing - removing something. Or at least that's how I understand it.

 

It seems like if this can't be called Zmmul, then it should be called Zimul, i.e. isn't 'i' the appropriate second letter?

 

And just to ask: Are extension names like 'Zmnodiv' or 'Zmmul' - that represent a subset of an existing extension - disallowed?  Zmmul is not that much different than the Scalar Crypto extension wanting a Zbk extension as a group or subset of BitManip instructions.

 

Greg 


Re: Proposal: Zmmul - draft

Ken Dockser
 

+Elisa

 

Thanks for doing this, Allen.

 

I would like to point out a few things:

  1. All proposals go through the O&CR before public review
    1. This is part of the Fast-Track DoD – I’m just repeating to ensure that we are all on the same page
  2. All proposals need to clearly delineate the normative and non-normative sections
    1. Normative – for each instruction

                                                    i.     Opcode

        1. Provide the complete encoding
        2. State that same as M instruction

                                                   ii.     Mnemonic

        1. Provide the complete encoding
        2. State that same as M instruction

                                                  iii.     Semantics

        1. Point to M

                                                  iv.     Sub-extension

        1. Zmul
        2. “This sub-extension is a proper subset of the ZM extension”
    1. Non-normative – for the extension

                                                    i.     “The Zmul sub-extension is the same as the M extension with divide and remainder removed.”

 

The non-normative text is formatted as a comment. In the current ISA spec it is delimited by lines and italics.

 

Moving forward, it had been proposed that we explicitly breakdown non-normative text into groups such as:

  1. Architecture Explanation
  2. Implementation Hints
  3. Software Hints

 

Cheers,

Ken

 

 

From: Allen Baum <allen.baum@...>
Sent: Tuesday, March 30, 2021 8:43 PM
To: Greg Favor <gfavor@...>
Cc: tech-unprivileged@...; RISC-V Help <help@...>; Ken Dockser <kdockser@...>
Subject: Re: Proposal: Zmmul - draft

 

CAUTION: This email originated from outside of the organization.

Here is v 0.3:
There are supposed to be "suitable required reviewers" from outside the proposer's organization.
It isn't clear to me if the relevant "standing committee" (this term should be replaced with Horizontal Committee or ISA Committed in  all the policy documents...) chooses reviewers or I do.

It also isn't clear to me that this hasn't already happened.


If it hasn't and it's up to me, Ken and Paul are the obvious choices, since they have been commenting on this already.

If they agree, then the next steps are to make any changes requested by them, and to fill out the Fastrack D.O.D checklist.

 

Then, if Krste and Chuanhua, (as chairs of the Unpriv IC), and Greg and Paul (as reviewers) agree, we can go for public review by announcing via email to ISA -dev and tech mailing lists.

I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

 

 

Proposal for fast track multiply extension

Chapter x+1
“Zmmul” Multiply extension v.3

The Zmmul extension implements multiply operations which are a proper subset of the M-extension.

Definition:
This extension defines instructions comprising the MUL, MULH, MUHU and MULHSU and (for RV64) MULW instructions of the M-extension without implementing the DIV* or REM* instructions.  
The ISA string is Zmmul.

[[The reasons for seeking fast track ratification: this is a proper subset of the existing M-extension:
   The opcode encodings          are identical to those in the M-extension.
   The instruction mnemonics are identical to those in the M-extension.
   The instruction semantics   are identical to those in the M-extension.

   No additional tests beyond those already being done for the M-extension are required.

   Both Spike and Sail already implement these instructions.
   No other instructions, new CSRs or new state are added.
]]


This extension explicitly allows the DIV and REM opcodes to cause illegal-instruction exceptions or be used for (non-conforming) custom ops. It therefore cannot co-exist with the M-extension. It has no dependencies on other extensions and can be used in any combination that the M-extension could be used.

 Note: a profile could require trapping DEV* and REM* with an illegal instruction exception if it were desirable to enable emulation of the M-extension using Zmmul, but the extension does not require it.

Rationale:
The rationale for this extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement.
In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops.

 

 

On Wed, Mar 24, 2021 at 11:07 PM Allen Baum <allen.baum@...> wrote:

Indeed  Zfinx is a counter-example and a good one.

Now I don't remember the context of the assertion that we can't have an extension which removes a feature/instruction, 

but as I think about it was literally more like "remove DIV from the M-extension" rather than "define a new extension like X but without Y"

OK, back to Zmmul then.

 

On Wed, Mar 24, 2021 at 3:54 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:

OK, v.2, renamed Zxmul because Paul pointed out that there is no such thing as a sub-extension defined anywhere, and Zm<> implies it is adding something into the M-extension instead of what this is doing - removing something. Or at least that's how I understand it.

 

It seems like if this can't be called Zmmul, then it should be called Zimul, i.e. isn't 'i' the appropriate second letter?

 

And just to ask: Are extension names like 'Zmnodiv' or 'Zmmul' - that represent a subset of an existing extension - disallowed?  Zmmul is not that much different than the Scalar Crypto extension wanting a Zbk extension as a group or subset of BitManip instructions.

 

Greg 


Re: Proposal: Zmmul - draft: -m-nodiv

mark
 

Is there a difference between not using div and having Zmmul and not M? How will this be reflected in the elf flags (or whatever they are called)?

thanks
Mark

On Wed, Mar 31, 2021 at 1:35 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

>I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

According to this:

 

https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

 

RISCV GCC already supports –mno-div, which presumably also excludes REM?! Maybe Jim can confirm.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Allen Baum
Sent: 31 March 2021 02:43
To: Greg Favor <gfavor@...>
Cc: tech-unprivileged@...; RISC-V Help <help@...>; Ken Dockser <kdockser@...>
Subject: Re: [RISC-V] [tech-unprivileged] Proposal: Zmmul - draft

 

Here is v 0.3:
There are supposed to be "suitable required reviewers" from outside the proposer's organization.
It isn't clear to me if the relevant "standing committee" (this term should be replaced with Horizontal Committee or ISA Committed in  all the policy documents...) chooses reviewers or I do.

It also isn't clear to me that this hasn't already happened.


If it hasn't and it's up to me, Ken and Paul are the obvious choices, since they have been commenting on this already.

If they agree, then the next steps are to make any changes requested by them, and to fill out the Fastrack D.O.D checklist.

 

Then, if Krste and Chuanhua, (as chairs of the Unpriv IC), and Greg and Paul (as reviewers) agree, we can go for public review by announcing via email to ISA -dev and tech mailing lists.

I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

 

 

Proposal for fast track multiply extension

Chapter x+1
“Zmmul” Multiply extension v.3

The Zmmul extension implements multiply operations which are a proper subset of the M-extension.

Definition:
This extension defines instructions comprising the MUL, MULH, MUHU and MULHSU and (for RV64) MULW instructions of the M-extension without implementing the DIV* or REM* instructions.  
The ISA string is Zmmul.

[[The reasons for seeking fast track ratification: this is a proper subset of the existing M-extension:
   The opcode encodings          are identical to those in the M-extension.
   The instruction mnemonics are identical to those in the M-extension.
   The instruction semantics   are identical to those in the M-extension.

   No additional tests beyond those already being done for the M-extension are required.

   Both Spike and Sail already implement these instructions.
   No other instructions, new CSRs or new state are added.
]]


This extension explicitly allows the DIV and REM opcodes to cause illegal-instruction exceptions or be used for (non-conforming) custom ops. It therefore cannot co-exist with the M-extension. It has no dependencies on other extensions and can be used in any combination that the M-extension could be used.

 Note: a profile could require trapping DEV* and REM* with an illegal instruction exception if it were desirable to enable emulation of the M-extension using Zmmul, but the extension does not require it.

Rationale:
The rationale for this extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement.
In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops.

 

 

On Wed, Mar 24, 2021 at 11:07 PM Allen Baum <allen.baum@...> wrote:

Indeed  Zfinx is a counter-example and a good one.

Now I don't remember the context of the assertion that we can't have an extension which removes a feature/instruction, 

but as I think about it was literally more like "remove DIV from the M-extension" rather than "define a new extension like X but without Y"

OK, back to Zmmul then.

 

On Wed, Mar 24, 2021 at 3:54 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:

OK, v.2, renamed Zxmul because Paul pointed out that there is no such thing as a sub-extension defined anywhere, and Zm<> implies it is adding something into the M-extension instead of what this is doing - removing something. Or at least that's how I understand it.

 

It seems like if this can't be called Zmmul, then it should be called Zimul, i.e. isn't 'i' the appropriate second letter?

 

And just to ask: Are extension names like 'Zmnodiv' or 'Zmmul' - that represent a subset of an existing extension - disallowed?  Zmmul is not that much different than the Scalar Crypto extension wanting a Zbk extension as a group or subset of BitManip instructions.

 

Greg 


Re: Proposal: Zmmul - draft: -m-nodiv

Tariq Kurd
 

>I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

According to this:

 

https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

 

RISCV GCC already supports –mno-div, which presumably also excludes REM?! Maybe Jim can confirm.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Allen Baum
Sent: 31 March 2021 02:43
To: Greg Favor <gfavor@...>
Cc: tech-unprivileged@...; RISC-V Help <help@...>; Ken Dockser <kdockser@...>
Subject: Re: [RISC-V] [tech-unprivileged] Proposal: Zmmul - draft

 

Here is v 0.3:
There are supposed to be "suitable required reviewers" from outside the proposer's organization.
It isn't clear to me if the relevant "standing committee" (this term should be replaced with Horizontal Committee or ISA Committed in  all the policy documents...) chooses reviewers or I do.

It also isn't clear to me that this hasn't already happened.


If it hasn't and it's up to me, Ken and Paul are the obvious choices, since they have been commenting on this already.

If they agree, then the next steps are to make any changes requested by them, and to fill out the Fastrack D.O.D checklist.

 

Then, if Krste and Chuanhua, (as chairs of the Unpriv IC), and Greg and Paul (as reviewers) agree, we can go for public review by announcing via email to ISA -dev and tech mailing lists.

I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces

 

 

 

Proposal for fast track multiply extension

Chapter x+1
“Zmmul” Multiply extension v.3

The Zmmul extension implements multiply operations which are a proper subset of the M-extension.

Definition:
This extension defines instructions comprising the MUL, MULH, MUHU and MULHSU and (for RV64) MULW instructions of the M-extension without implementing the DIV* or REM* instructions.  
The ISA string is Zmmul.

[[The reasons for seeking fast track ratification: this is a proper subset of the existing M-extension:
   The opcode encodings          are identical to those in the M-extension.
   The instruction mnemonics are identical to those in the M-extension.
   The instruction semantics   are identical to those in the M-extension.

   No additional tests beyond those already being done for the M-extension are required.

   Both Spike and Sail already implement these instructions.
   No other instructions, new CSRs or new state are added.
]]


This extension explicitly allows the DIV and REM opcodes to cause illegal-instruction exceptions or be used for (non-conforming) custom ops. It therefore cannot co-exist with the M-extension. It has no dependencies on other extensions and can be used in any combination that the M-extension could be used.

 Note: a profile could require trapping DEV* and REM* with an illegal instruction exception if it were desirable to enable emulation of the M-extension using Zmmul, but the extension does not require it.

Rationale:
The rationale for this extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement.
In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops.

 

 

On Wed, Mar 24, 2021 at 11:07 PM Allen Baum <allen.baum@...> wrote:

Indeed  Zfinx is a counter-example and a good one.

Now I don't remember the context of the assertion that we can't have an extension which removes a feature/instruction, 

but as I think about it was literally more like "remove DIV from the M-extension" rather than "define a new extension like X but without Y"

OK, back to Zmmul then.

 

On Wed, Mar 24, 2021 at 3:54 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:

OK, v.2, renamed Zxmul because Paul pointed out that there is no such thing as a sub-extension defined anywhere, and Zm<> implies it is adding something into the M-extension instead of what this is doing - removing something. Or at least that's how I understand it.

 

It seems like if this can't be called Zmmul, then it should be called Zimul, i.e. isn't 'i' the appropriate second letter?

 

And just to ask: Are extension names like 'Zmnodiv' or 'Zmmul' - that represent a subset of an existing extension - disallowed?  Zmmul is not that much different than the Scalar Crypto extension wanting a Zbk extension as a group or subset of BitManip instructions.

 

Greg 


Re: Proposal: Zmmul - draft

Greg Favor
 

On Tue, Mar 30, 2021 at 6:43 PM Allen Baum <allen.baum@...> wrote:
Here is v 0.3:
There are supposed to be "suitable required reviewers" from outside the proposer's organization.
It isn't clear to me if the relevant "standing committee" (this term should be replaced with Horizontal Committee or ISA Committed in  all the policy documents...

This was corrected yesterday.
 
) chooses reviewers or I do.

The intent is for the proposer to make reasonable choices.
 
It also isn't clear to me that this hasn't already happened.

If it hasn't and it's up to me, Ken and Paul are the obvious choices, since they have been commenting on this already.

The fact that they have already commented doesn't inherently make them "suitable required reviewers".  But, after the fact of starting the initial review, if you feel that they are appropriate choices, then that is OK.  The point was simply to try and "ensure a minimum level of meaningful review".
 
If they agree, then the next steps are to make any changes requested by them, and to fill out the Fastrack D.O.D checklist.

Then, if Krste and Chuanhua, (as chairs of the Unpriv IC), and Greg and Paul (as reviewers) agree, we can go for public review by announcing via email to ISA -dev and tech mailing lists.

I don't object to being one of the two non-chairs to agree to push forward, but it would be preferable to have people that have some vested interest, to some degree, in seeing this extension happen.

Greg


Re: Proposal: Zmmul - draft

Allen Baum
 

Here is v 0.3:
There are supposed to be "suitable required reviewers" from outside the proposer's organization.
It isn't clear to me if the relevant "standing committee" (this term should be replaced with Horizontal Committee or ISA Committed in  all the policy documents...) chooses reviewers or I do.
It also isn't clear to me that this hasn't already happened.

If it hasn't and it's up to me, Ken and Paul are the obvious choices, since they have been commenting on this already.
If they agree, then the next steps are to make any changes requested by them, and to fill out the Fastrack D.O.D checklist.

Then, if Krste and Chuanhua, (as chairs of the Unpriv IC), and Greg and Paul (as reviewers) agree, we can go for public review by announcing via email to ISA -dev and tech mailing lists.
I'm not sure how we get tools/compilers to avoid DIV/REM instructions, which is one of the final missing pieces


 

Proposal for fast track multiply extension

Chapter x+1
“Zmmul” Multiply extension v.3

The Zmmul extension implements multiply operations which are a proper subset of the M-extension.

Definition:
This extension defines instructions comprising the MUL, MULH, MUHU and MULHSU and (for RV64) MULW instructions of the M-extension without implementing the DIV* or REM* instructions.  
The ISA string is Zmmul.

[[The reasons for seeking fast track ratification: this is a proper subset of the existing M-extension:
   The opcode encodings          are identical to those in the M-extension.
   The instruction mnemonics are identical to those in the M-extension.
   The instruction semantics   are identical to those in the M-extension.

   No additional tests beyond those already being done for the M-extension are required.

   Both Spike and Sail already implement these instructions.
   No other instructions, new CSRs or new state are added.
]]


This extension explicitly allows the DIV and REM opcodes to cause illegal-instruction exceptions or be used for (non-conforming) custom ops. It therefore cannot co-exist with the M-extension. It has no dependencies on other extensions and can be used in any combination that the M-extension could be used.

 Note: a profile could require trapping DEV* and REM* with an illegal instruction exception if it were desirable to enable emulation of the M-extension using Zmmul, but the extension does not require it.

Rationale:
The rationale for this extension is that, particularly in the microcontroller market where cost reduction is critical, divide operations are infrequent and divider hardware is expensive, while multiplication operations are more useful and both easier and cheaper to implement.
In short: many microcontroller vendors would like to implement a multiplier, but without the baggage of having to implement divide or remainder ops.

 


On Wed, Mar 24, 2021 at 11:07 PM Allen Baum <allen.baum@...> wrote:
Indeed  Zfinx is a counter-example and a good one.
Now I don't remember the context of the assertion that we can't have an extension which removes a feature/instruction, 
but as I think about it was literally more like "remove DIV from the M-extension" rather than "define a new extension like X but without Y"
OK, back to Zmmul then.

On Wed, Mar 24, 2021 at 3:54 PM Greg Favor <gfavor@...> wrote:
On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:
OK, v.2, renamed Zxmul because Paul pointed out that there is no such thing as a sub-extension defined anywhere, and Zm<> implies it is adding something into the M-extension instead of what this is doing - removing something. Or at least that's how I understand it.

It seems like if this can't be called Zmmul, then it should be called Zimul, i.e. isn't 'i' the appropriate second letter?

And just to ask: Are extension names like 'Zmnodiv' or 'Zmmul' - that represent a subset of an existing extension - disallowed?  Zmmul is not that much different than the Scalar Crypto extension wanting a Zbk extension as a group or subset of BitManip instructions.

Greg 


Re: Proposal: Zmmul - draft

Paul Donahue
 

Zbb and friends are called extensions, not sub-extensions, in the bitmanip spec.  The base architecture (in particular the "Extending RISC-V" chapter) talks only of extensions and not sub-extensions.  We can have sub-extensions but we'd have to clarify what that term means and how they are distinct from extensions.  I think it's just easier to have extensions that happen to be subsets of other extensions.  I also note that after the first paragraph you call Zmmul an extension instead of a sub-extension.


Thanks,

-Paul



On Tue, Mar 30, 2021 at 10:55 AM Ken Dockser <kdockser@...> wrote:

We are talking about a new sub-extension under “M” that includes some of the instructions from the M extension (i.e., it is a proper subset of ZM). Sub-extensions do exist, that is what we are calling Zba, Zbb, etc. under the ZB Bitmanip extension.

 

The extension specification would consist of groupings of the each supported instruction with its mnemonic, encoding, and a link to the instruction’s normative text within the ZM portion of the ISA specification.

 

To avoid confusion, we can include non-normative text that explains that this is effectively the M extension without DIV or REM. But, this is like any other extension that includes instructions from another extension; it is additive not subtractive.

 

Thanks,

Ken

 

 

From: Allen Baum <allen.baum@...>
Sent: Thursday, March 25, 2021 1:07 AM
To: Greg Favor <gfavor@...>
Cc: tech-unprivileged@...; RISC-V Help <help@...>; Ken Dockser <kdockser@...>
Subject: Re: Proposal: Zmmul - draft

 

CAUTION: This email originated from outside of the organization.

Indeed  Zfinx is a counter-example and a good one.

Now I don't remember the context of the assertion that we can't have an extension which removes a feature/instruction, 

but as I think about it was literally more like "remove DIV from the M-extension" rather than "define a new extension like X but without Y"

OK, back to Zmmul then.

 

On Wed, Mar 24, 2021 at 3:54 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:

OK, v.2, renamed Zxmul because Paul pointed out that there is no such thing as a sub-extension defined anywhere, and Zm<> implies it is adding something into the M-extension instead of what this is doing - removing something. Or at least that's how I understand it.

 

It seems like if this can't be called Zmmul, then it should be called Zimul, i.e. isn't 'i' the appropriate second letter?

 

And just to ask: Are extension names like 'Zmnodiv' or 'Zmmul' - that represent a subset of an existing extension - disallowed?  Zmmul is not that much different than the Scalar Crypto extension wanting a Zbk extension as a group or subset of BitManip instructions.

 

Greg 


Re: Proposal: Zmmul - draft

Ken Dockser
 

Whether or not an instruction takes a trap when it is not implemented (or the opcode is unused)  is up to the profile. Likewise, the behavior on the trap (e.g., emulate or return an error) can be specified by the profile. The profile can explicitly defer these decisions to the platform specification.

 

We can have, for example, an embedded profile that says that all of M must be implemented but states that it is up to the platform as to whether DIV and REM they are trapped (and emulated). If emulation were to be required, it would need to performed outside of the profile and platform. For example, if the profile didn’t include Machine Mode, the emulation could be performed there.

 

Ken

 

From: Allen Baum <allen.baum@...>
Sent: Wednesday, March 24, 2021 7:23 PM
To: Greg Favor <gfavor@...>
Cc: tech-unprivileged@...; RISC-V Help <help@...>; Ken Dockser <kdockser@...>
Subject: Re: Proposal: Zmmul - draft

 

CAUTION: This email originated from outside of the organization.

Yea, I'm being completely redundant. 

I want to list every possible reason that could shoot down fast-track to be explicitly mentioned.

I want every possible parameter that could possibly be controversial listed - so they won't be controversial.

I want to possible mistunderstandings

 

If Mul is in HW, and Div is trapped - that is NOT the equivalent of M-extension, because if M-extension is present, then Mmode code should be able to execute a Div op and get the result - without trapping.. You could have M-mode code that was careful to save and restore state before it could possibly execute a Div op, (so a trap to Mmode could recursively trap to Mmode), or could be guaranteed to never execute a Div op and have Div eulation code - but that;s not the same thing.

 

On Wed, Mar 24, 2021 at 4:07 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:

Definition:

This extension defines instructions comprising the MUL, MULH, MUHU and MULHSU and (for RV64) MULW instructions of the M-extension without implementing the DIV* or REM* instruction
The opcode encodings are identical to those in the M-extension.
The instruction mnemonics are identical to those in the M-extension.
The instruction semantics are identical to those in the M-extension.
No CSRs or state are added

 

It still seems unnecessary to explicitly specify the preceding three statements.  Is there any ambiguity in the first statement, i.e. can one say that an extension is "comprised of instructions from other extensions" while changing the definitions of those instructions?

 

If so, then what did "comprise" really mean other than saying "similar but not exactly the same".

 

Btw, I'm picking on this for the sake of a standard template, for simple extensions like this, hopefully eventually being created (soon).

 

 Note: this extension could require trapping DEV* and REM* with an illegal instruction exception if it were desirable to enable emulation of the M-extension using Zxmul, or a profile could require them to trap for emulation purposes.

 

If the div instructions are trapped and emulated, isn't the full M extension being supported/implemented?  In other words, isn't a compliant M extension implementation allowed to trap and emulate some of the instructions?

 

Greg

 


Re: Proposal: Zmmul - draft

Ken Dockser
 

We are talking about a new sub-extension under “M” that includes some of the instructions from the M extension (i.e., it is a proper subset of ZM). Sub-extensions do exist, that is what we are calling Zba, Zbb, etc. under the ZB Bitmanip extension.

 

The extension specification would consist of groupings of the each supported instruction with its mnemonic, encoding, and a link to the instruction’s normative text within the ZM portion of the ISA specification.

 

To avoid confusion, we can include non-normative text that explains that this is effectively the M extension without DIV or REM. But, this is like any other extension that includes instructions from another extension; it is additive not subtractive.

 

Thanks,

Ken

 

 

From: Allen Baum <allen.baum@...>
Sent: Thursday, March 25, 2021 1:07 AM
To: Greg Favor <gfavor@...>
Cc: tech-unprivileged@...; RISC-V Help <help@...>; Ken Dockser <kdockser@...>
Subject: Re: Proposal: Zmmul - draft

 

CAUTION: This email originated from outside of the organization.

Indeed  Zfinx is a counter-example and a good one.

Now I don't remember the context of the assertion that we can't have an extension which removes a feature/instruction, 

but as I think about it was literally more like "remove DIV from the M-extension" rather than "define a new extension like X but without Y"

OK, back to Zmmul then.

 

On Wed, Mar 24, 2021 at 3:54 PM Greg Favor <gfavor@...> wrote:

On Wed, Mar 24, 2021 at 3:46 PM Allen Baum <allen.baum@...> wrote:

OK, v.2, renamed Zxmul because Paul pointed out that there is no such thing as a sub-extension defined anywhere, and Zm<> implies it is adding something into the M-extension instead of what this is doing - removing something. Or at least that's how I understand it.

 

It seems like if this can't be called Zmmul, then it should be called Zimul, i.e. isn't 'i' the appropriate second letter?

 

And just to ask: Are extension names like 'Zmnodiv' or 'Zmmul' - that represent a subset of an existing extension - disallowed?  Zmmul is not that much different than the Scalar Crypto extension wanting a Zbk extension as a group or subset of BitManip instructions.

 

Greg 


Re: Zfinx + Zfh configurations

Allen Baum
 

yes... but being extensively(?) revised by Krste.

On Mon, Mar 29, 2021 at 10:44 AM Tariq Kurd <tariq.kurd@...> wrote:

It was a valid point – is there is definition for the config string rules written down anywhere?

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 29 March 2021 17:58
To: Tariq Kurd <tariq.kurd@...>
Cc: Krste Asanovic <krste@...>; Greg Favor <gfavor@...>; tech-unprivileged@...; Jessica Clarke <jrtc27@...>; Jim Wilson <jimw@...>; Mark Himelstein <markhimelstein@...>
Subject: Re: [RISC-V] [tech-unprivileged] Zfinx + Zfh configurations

 

I'm being deliberately pedantic here, because parsers may care; that was really just an offhand remark.

What I'm more concerned with is basically having a ISA string spec that can be codified and parsed unambiguously without major effort.

 

On Mon, Mar 29, 2021 at 2:47 AM Tariq Kurd <tariq.kurd@...> wrote:

Hi Allen – the capital letter was from the email Mark sent me following his meeting with Krste about the config string several weeks back.

I’ve been referring to the extension in general as Zfinx, and the actual usage as Z<base-ext>inx where <base-ext> is F/D/Q.

 

I don’t make the rules, but of course I’ll change it if it’s wrong (although that will affect the toolchain etc.)

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 27 March 2021 06:35
To: Tariq Kurd <tariq.kurd@...>
Cc: Krste Asanovic <krste@...>; Greg Favor <gfavor@...>; tech-unprivileged@...; Jessica Clarke <jrtc27@...>; Jim Wilson <jimw@...>; Mark Himelstein <markhimelstein@...>
Subject: Re: [RISC-V] [tech-unprivileged] Zfinx + Zfh configurations

 

but Z[FDQ]inx should be Z[fdq]inx - capitalization rules. The last time I looked anyway.

and single letter extensions were supposed to come before any Zextension.  The last time I looked anyway.

 

Documenting what a canonical ISA string is (or will be) sounds like a bit of a nightmare.

Luckily... not my problem. I'll let others whose problem it is comment.

 

 

On Fri, Mar 26, 2021 at 7:22 AM Tariq Kurd <tariq.kurd@...> wrote:

Catching up with this thread…. Let’s see if I follow where we’re up to….

 

1.        we allow the parsing of the config string to be context sensitive, so there’s no problem with Z[FDQ]inx_Zfh

a.       I’d say that the Z[FDQ]inx should be required to be first, for simple left-to-right parsing – which would also require it to be before V or any other extensions which have FP ops.

2.       Given the context sensitive nature, we can keep the existing spec of Z[FDQ]inx, or move to Zfinx_[DQ] (where Zfinx itself implies F)

a.       The toolchain  and simulators are being updated to the existing spec, so I’d rather not change it.

3.       Anything Zfinx related won’t use misa

a.       It will wait for the CPUID mechanism

 

Is that it? So no change to the Zfinx spec, and we’re all happy <fingers-crossed!>

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 26 March 2021 07:40
To: Krste Asanovic <krste@...>
Cc: Greg Favor <gfavor@...>; tech-unprivileged@...; Jessica Clarke <jrtc27@...>; Jim Wilson <jimw@...>; Tariq Kurd <tariq.kurd@...>; Mark Himelstein <markhimelstein@...>
Subject: Re: [RISC-V] [tech-unprivileged] Zfinx + Zfh configurations

 

no; 

Zfinx removes FP Load/Store/Mv instructions because it doesn't use FPRegs. 

It (re)uses normal LD/St instructions instead. 

It also removes the ability to use 0 as source/dest register specifier, and removes HW NanBoxing

 

On Fri, Mar 26, 2021 at 12:20 AM <krste@...> wrote:



>>>>> On Fri, 26 Mar 2021 00:00:09 -0700, Allen Baum <allen.baum@...> said:

| On Thu, Mar 25, 2021 at 11:31 PM <krste@...> wrote:
|     Yes, every extension can depend on whole string, though hopefully only
|     a few extensions will be major modifiers of others.  Extensions don't
|     remove things.  Zfinx adds floating-point instructions without adding
|     f registers - it doesn't remove f registers because F and D don't add
|     f registers if Zfinx is present.

| Zfinx *removes* floating point instructions; it doesn't add any.

Zfinx by itself adds the single-precision FP instructions operating
out of X registers (at least in the last definition of Zfinx I read).

You seem to be treating it as a modifier of F.

For me, RV32I_Zfinx defines a system with single-precision
floating-point instructions operating out of the integer registers.


|     Is there an alternative proposal that doesn't result in very long
|     strings or constrain the options available?

|     E.g., if you want each extension to have a unique context-insensitive
|     additive-only meaning, then every base ISA would need a new name for
|     its version of every extension:
|          RV32I_RV32IM_RV32IA_RV32IF_RV32ID_RV32IC,
|          RV32E_RV32EM_RV32EA_RV32EF_RV32ED_RV32EC,
|          RV32I_RV32IM_RV32IA_RV32IZfinx,
|          RV32E_RV32EM_RV32EA_RV32EZfinx,
|          RV64I_RV64IZfinx_RV64IZdinx_RV64IZfhinx,
|          etc.,

| Yes, and I listed them in a previous email (11:21am)
| The architecture string is RV32I, RV32E, RV64I, RVI28I, etc. It
| comes first and is architecture, not extension, so you can ignore
| that.

Of course - the point is there's a common part, and while the base is
certainly special, there will be other places where you want to factor
out a component of the names of other extensions.

| There are 12 legal combinations of {F/D/Q}{Zfinx{}{Zfh}:
| each of the individual lengths needs a separate extension ISA string because 
|     they remove FPRegs AND remove ops from the ratified ops and read/write
| pairs of Xregs (D_Finx case)
| So, F/D/Q/Zfh becomes Zfinx, Zfdinx, Zfdqinx/Zfhinx (for example) when FP is
| done in Xregs.
| The 12 legal combinations are:
| F            FD         FDQ       <--FP in FP regs
| F_Zfh     FD_Zfh  FDQ_Zfh<--FP with 16bit FP
| Zfinx      Zdinx     Zqinx      <--FP in Xregs
| Zfhinx    Zdhinx   Zhqinx    <--FP in Xregs with 16bit FP

| The bottom two row are abbreviations, collections of other extensions, just as
| G, or Ksn or KSe (and K itself) are abbreviations
| e.g. Zqinx   is really Zfinx+ Zfdinx+Zfqinx, 
|        Zqhinx is really Zfinx+ Zfdinx+Zfqinx+Zfhinx, 
| That should be pretty intuitive, and in all cases I think is shorter than, or
| equal to, the alternative.

I agree that abbreviations for common combinations are a good thing
(e.g. G).

I don't see the disagreement here.  I'm only pointing out that there
will be overlap between extension names, and that they are already
context-sensitive even if only on base ISA.

If we add another 15 FP extensions, I'm fairly sure we'll want to
factor out the common Zfinx part from the FP extension names instead
of defining potentially 2^15 abbreviations for Zfinx systems.

Krste

1 - 20 of 164