Topics

Instruction encoding allocation policy and Zfinx


Tariq Kurd
 

Hi everyone,

 

From the instruction encoding policy:

 

https://docs.google.com/document/d/1uC6QAyFmglGbO9kRR-X8LQWga6B3yBJR7-iw6ZXnfG8/edit#

 

“The basic meaning of an instruction encoding shall not be dependent on machine state. This does not preclude the common practice of using machine state to change aspects of the execution (e.g., rounding mode, vector length) or even modify or block execution (e.g., user mode vs supervisor mode). Also, this does not preclude different base architectures (e.g., RV32I, RV64I) from using the same encoding for different base-architecture-specific instructions (e.g.,  C.JAL(RV32) and C.ADDIW(RV64)).  Likewise, an encoding used in one standard extension shall not be given a completely different meaning in another standard extension, even when the two standard extensions might not (or could not) coexist.This restriction is intended to prevent the practice of giving an instruction a completely new meaning based on machine state. For example, an encoding should not be used for divide when a CSR bit is set and multiply when it is cleared. Such context-dependent semantics like this introduce, among other unintended consequences, hard-to-find security vulnerabilities.”

 

I agree with the statement, but I’d like to clarify where Zfinx fits into this picture. One important reason for Zfinx is to free up encoding space, ideally for code-size reduction in the 16-bit encodings.

-          I think we need to define e.g. RV32I and RV32I Zfinx as distinct base architectures

-          If so this would imply that RV32I Zfinx without F would be a valid configuration, and would have a distinct meaning.

 

For example, if we defined an extension to reuse the encodings for C.FSW, C.FLW, C.FSWSP, C.LFWSP as C.SH, C.SB, C.LHU, C.LBU  and called it Zcsbhldst (code-size-byte-half-load-store). Then the following configuration would be valid:

 

RV32I Zfinx Zcsbhldst

 

And this wouldn’t

 

RV32I Zcsbhldst

 

Because RV32I allocates those encodings to F for that base architecture. RV32I Zfinx doesn’t allocate them to F so they can be reallocated to Zcsldstbh.

 

Is this reasonable?

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 


Allen Baum
 


This:
"Likewise, an encoding used in one standard extension shall not be given a completely different meaning 
in another standard extension, even when the two standard extensions might not (or could not) coexist."
entirely precludes reusing an op for a different standard extension.

Even if Zfinx makes it a different base architecture,  there is no reuse of opcodes between RV32 and RV64, so not sure why it should make a difference.

IF this were changed, then it might hinge on the understanding of this:
   "For example, an encoding should not be used for divide when a CSR bit is set and multiply when it is cleared. "
The question is: does set and clear imply that the CSR bi is changed dynamically (so the bit is RW), or also intended to be the case when is RO?
For Zfinx: there is no CSR bit, but there is a code sequence that can determine whether Zfinx is present or not.
In the absence of a state bit, I think we can conclude that it is not possible to enable or disable ZFinx, for what it is worth.

On one hand, I am not in favor of reusing opcodes; they preclude easy disassembly of programs for one thing.
But I certainly understand the synergy of ZFinx and code size where this case would make sense.

On Thu, Oct 15, 2020 at 3:29 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

From the instruction encoding policy:

 

https://docs.google.com/document/d/1uC6QAyFmglGbO9kRR-X8LQWga6B3yBJR7-iw6ZXnfG8/edit#

 

“The basic meaning of an instruction encoding shall not be dependent on machine state. This does not preclude the common practice of using machine state to change aspects of the execution (e.g., rounding mode, vector length) or even modify or block execution (e.g., user mode vs supervisor mode). Also, this does not preclude different base architectures (e.g., RV32I, RV64I) from using the same encoding for different base-architecture-specific instructions (e.g.,  C.JAL(RV32) and C.ADDIW(RV64)).  Likewise, an encoding used in one standard extension shall not be given a completely different meaning in another standard extension, even when the two standard extensions might not (or could not) coexist.This restriction is intended to prevent the practice of giving an instruction a completely new meaning based on machine state. For example, an encoding should not be used for divide when a CSR bit is set and multiply when it is cleared. Such context-dependent semantics like this introduce, among other unintended consequences, hard-to-find security vulnerabilities.”

 

I agree with the statement, but I’d like to clarify where Zfinx fits into this picture. One important reason for Zfinx is to free up encoding space, ideally for code-size reduction in the 16-bit encodings.

-          I think we need to define e.g. RV32I and RV32I Zfinx as distinct base architectures

-          If so this would imply that RV32I Zfinx without F would be a valid configuration, and would have a distinct meaning.

 

For example, if we defined an extension to reuse the encodings for C.FSW, C.FLW, C.FSWSP, C.LFWSP as C.SH, C.SB, C.LHU, C.LBU  and called it Zcsbhldst (code-size-byte-half-load-store). Then the following configuration would be valid:

 

RV32I Zfinx Zcsbhldst

 

And this wouldn’t

 

RV32I Zcsbhldst

 

Because RV32I allocates those encodings to F for that base architecture. RV32I Zfinx doesn’t allocate them to F so they can be reallocated to Zcsldstbh.

 

Is this reasonable?

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 


Tariq Kurd
 

>Even if Zfinx makes it a different base architecture,  there is no reuse of opcodes between

>RV32 and RV64, so not sure why it should make a difference.

 

In the 32-bit opcode space, this is true. But in the 16-bit opcode space there are overlaps, C.JAL (RV32) and C.ADDIW (RV64) share an encoding for example. I’d like to extend this principle to Zfinx to get maximum benefit from freed up 16-bit encodings for code size reduction.

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 15 October 2020 21:23
To: tech-unprivileged@...; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-unprivileged] Instruction encoding allocation policy and Zfinx

 

 

This:

"Likewise, an encoding used in one standard extension shall not be given a completely different meaning 

in another standard extension, even when the two standard extensions might not (or could not) coexist."

entirely precludes reusing an op for a different standard extension.

 

Even if Zfinx makes it a different base architecture,  there is no reuse of opcodes between RV32 and RV64, so not sure why it should make a difference.

 

IF this were changed, then it might hinge on the understanding of this:

   "For example, an encoding should not be used for divide when a CSR bit is set and multiply when it is cleared. "

The question is: does set and clear imply that the CSR bi is changed dynamically (so the bit is RW), or also intended to be the case when is RO?

For Zfinx: there is no CSR bit, but there is a code sequence that can determine whether Zfinx is present or not.

In the absence of a state bit, I think we can conclude that it is not possible to enable or disable ZFinx, for what it is worth.

 

On one hand, I am not in favor of reusing opcodes; they preclude easy disassembly of programs for one thing.

But I certainly understand the synergy of ZFinx and code size where this case would make sense.

 

On Thu, Oct 15, 2020 at 3:29 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

From the instruction encoding policy:

 

https://docs.google.com/document/d/1uC6QAyFmglGbO9kRR-X8LQWga6B3yBJR7-iw6ZXnfG8/edit#

 

“The basic meaning of an instruction encoding shall not be dependent on machine state. This does not preclude the common practice of using machine state to change aspects of the execution (e.g., rounding mode, vector length) or even modify or block execution (e.g., user mode vs supervisor mode). Also, this does not preclude different base architectures (e.g., RV32I, RV64I) from using the same encoding for different base-architecture-specific instructions (e.g.,  C.JAL(RV32) and C.ADDIW(RV64)).  Likewise, an encoding used in one standard extension shall not be given a completely different meaning in another standard extension, even when the two standard extensions might not (or could not) coexist.This restriction is intended to prevent the practice of giving an instruction a completely new meaning based on machine state. For example, an encoding should not be used for divide when a CSR bit is set and multiply when it is cleared. Such context-dependent semantics like this introduce, among other unintended consequences, hard-to-find security vulnerabilities.”

 

I agree with the statement, but I’d like to clarify where Zfinx fits into this picture. One important reason for Zfinx is to free up encoding space, ideally for code-size reduction in the 16-bit encodings.

-          I think we need to define e.g. RV32I and RV32I Zfinx as distinct base architectures

-          If so this would imply that RV32I Zfinx without F would be a valid configuration, and would have a distinct meaning.

 

For example, if we defined an extension to reuse the encodings for C.FSW, C.FLW, C.FSWSP, C.LFWSP as C.SH, C.SB, C.LHU, C.LBU  and called it Zcsbhldst (code-size-byte-half-load-store). Then the following configuration would be valid:

 

RV32I Zfinx Zcsbhldst

 

And this wouldn’t

 

RV32I Zcsbhldst

 

Because RV32I allocates those encodings to F for that base architecture. RV32I Zfinx doesn’t allocate them to F so they can be reallocated to Zcsldstbh.

 

Is this reasonable?

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 


Allen Baum
 

Actually, you're right; and that isn't the only one; there are at least 5 others. 
I thought there were just cases where there was overloading the use of rs or rd=0 (or 2 in some cases) 
So, there is precedent for this.

On Fri, Oct 16, 2020 at 1:20 AM Tariq Kurd <tariq.kurd@...> wrote:

>Even if Zfinx makes it a different base architecture,  there is no reuse of opcodes between

>RV32 and RV64, so not sure why it should make a difference.

 

In the 32-bit opcode space, this is true. But in the 16-bit opcode space there are overlaps, C.JAL (RV32) and C.ADDIW (RV64) share an encoding for example. I’d like to extend this principle to Zfinx to get maximum benefit from freed up 16-bit encodings for code size reduction.

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 15 October 2020 21:23
To: tech-unprivileged@...; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-unprivileged] Instruction encoding allocation policy and Zfinx

 

 

This:

"Likewise, an encoding used in one standard extension shall not be given a completely different meaning 

in another standard extension, even when the two standard extensions might not (or could not) coexist."

entirely precludes reusing an op for a different standard extension.

 

Even if Zfinx makes it a different base architecture,  there is no reuse of opcodes between RV32 and RV64, so not sure why it should make a difference.

 

IF this were changed, then it might hinge on the understanding of this:

   "For example, an encoding should not be used for divide when a CSR bit is set and multiply when it is cleared. "

The question is: does set and clear imply that the CSR bi is changed dynamically (so the bit is RW), or also intended to be the case when is RO?

For Zfinx: there is no CSR bit, but there is a code sequence that can determine whether Zfinx is present or not.

In the absence of a state bit, I think we can conclude that it is not possible to enable or disable ZFinx, for what it is worth.

 

On one hand, I am not in favor of reusing opcodes; they preclude easy disassembly of programs for one thing.

But I certainly understand the synergy of ZFinx and code size where this case would make sense.

 

On Thu, Oct 15, 2020 at 3:29 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

From the instruction encoding policy:

 

https://docs.google.com/document/d/1uC6QAyFmglGbO9kRR-X8LQWga6B3yBJR7-iw6ZXnfG8/edit#

 

“The basic meaning of an instruction encoding shall not be dependent on machine state. This does not preclude the common practice of using machine state to change aspects of the execution (e.g., rounding mode, vector length) or even modify or block execution (e.g., user mode vs supervisor mode). Also, this does not preclude different base architectures (e.g., RV32I, RV64I) from using the same encoding for different base-architecture-specific instructions (e.g.,  C.JAL(RV32) and C.ADDIW(RV64)).  Likewise, an encoding used in one standard extension shall not be given a completely different meaning in another standard extension, even when the two standard extensions might not (or could not) coexist.This restriction is intended to prevent the practice of giving an instruction a completely new meaning based on machine state. For example, an encoding should not be used for divide when a CSR bit is set and multiply when it is cleared. Such context-dependent semantics like this introduce, among other unintended consequences, hard-to-find security vulnerabilities.”

 

I agree with the statement, but I’d like to clarify where Zfinx fits into this picture. One important reason for Zfinx is to free up encoding space, ideally for code-size reduction in the 16-bit encodings.

-          I think we need to define e.g. RV32I and RV32I Zfinx as distinct base architectures

-          If so this would imply that RV32I Zfinx without F would be a valid configuration, and would have a distinct meaning.

 

For example, if we defined an extension to reuse the encodings for C.FSW, C.FLW, C.FSWSP, C.LFWSP as C.SH, C.SB, C.LHU, C.LBU  and called it Zcsbhldst (code-size-byte-half-load-store). Then the following configuration would be valid:

 

RV32I Zfinx Zcsbhldst

 

And this wouldn’t

 

RV32I Zcsbhldst

 

Because RV32I allocates those encodings to F for that base architecture. RV32I Zfinx doesn’t allocate them to F so they can be reallocated to Zcsldstbh.

 

Is this reasonable?

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 


Tariq Kurd
 

Hi everyone,

 

Can get some resolution on this thread?

The proposal is that Zfinx will be a new base arch so we can reuse the instruction encodings for FP load/stores and INT/FP moves. There is already a precedent for this as we currently reuse 16-bit encodings for RV32/RV64/RV128

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 16 October 2020 21:30
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-unprivileged@...
Subject: Re: [RISC-V] [tech-unprivileged] Instruction encoding allocation policy and Zfinx

 

Actually, you're right; and that isn't the only one; there are at least 5 others. 

I thought there were just cases where there was overloading the use of rs or rd=0 (or 2 in some cases) 

So, there is precedent for this.

 

On Fri, Oct 16, 2020 at 1:20 AM Tariq Kurd <tariq.kurd@...> wrote:

>Even if Zfinx makes it a different base architecture,  there is no reuse of opcodes between

>RV32 and RV64, so not sure why it should make a difference.

 

In the 32-bit opcode space, this is true. But in the 16-bit opcode space there are overlaps, C.JAL (RV32) and C.ADDIW (RV64) share an encoding for example. I’d like to extend this principle to Zfinx to get maximum benefit from freed up 16-bit encodings for code size reduction.

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 15 October 2020 21:23
To: tech-unprivileged@...; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-unprivileged] Instruction encoding allocation policy and Zfinx

 

 

This:

"Likewise, an encoding used in one standard extension shall not be given a completely different meaning 

in another standard extension, even when the two standard extensions might not (or could not) coexist."

entirely precludes reusing an op for a different standard extension.

 

Even if Zfinx makes it a different base architecture,  there is no reuse of opcodes between RV32 and RV64, so not sure why it should make a difference.

 

IF this were changed, then it might hinge on the understanding of this:

   "For example, an encoding should not be used for divide when a CSR bit is set and multiply when it is cleared. "

The question is: does set and clear imply that the CSR bi is changed dynamically (so the bit is RW), or also intended to be the case when is RO?

For Zfinx: there is no CSR bit, but there is a code sequence that can determine whether Zfinx is present or not.

In the absence of a state bit, I think we can conclude that it is not possible to enable or disable ZFinx, for what it is worth.

 

On one hand, I am not in favor of reusing opcodes; they preclude easy disassembly of programs for one thing.

But I certainly understand the synergy of ZFinx and code size where this case would make sense.

 

On Thu, Oct 15, 2020 at 3:29 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

From the instruction encoding policy:

 

https://docs.google.com/document/d/1uC6QAyFmglGbO9kRR-X8LQWga6B3yBJR7-iw6ZXnfG8/edit#

 

“The basic meaning of an instruction encoding shall not be dependent on machine state. This does not preclude the common practice of using machine state to change aspects of the execution (e.g., rounding mode, vector length) or even modify or block execution (e.g., user mode vs supervisor mode). Also, this does not preclude different base architectures (e.g., RV32I, RV64I) from using the same encoding for different base-architecture-specific instructions (e.g.,  C.JAL(RV32) and C.ADDIW(RV64)).  Likewise, an encoding used in one standard extension shall not be given a completely different meaning in another standard extension, even when the two standard extensions might not (or could not) coexist.This restriction is intended to prevent the practice of giving an instruction a completely new meaning based on machine state. For example, an encoding should not be used for divide when a CSR bit is set and multiply when it is cleared. Such context-dependent semantics like this introduce, among other unintended consequences, hard-to-find security vulnerabilities.”

 

I agree with the statement, but I’d like to clarify where Zfinx fits into this picture. One important reason for Zfinx is to free up encoding space, ideally for code-size reduction in the 16-bit encodings.

-          I think we need to define e.g. RV32I and RV32I Zfinx as distinct base architectures

-          If so this would imply that RV32I Zfinx without F would be a valid configuration, and would have a distinct meaning.

 

For example, if we defined an extension to reuse the encodings for C.FSW, C.FLW, C.FSWSP, C.LFWSP as C.SH, C.SB, C.LHU, C.LBU  and called it Zcsbhldst (code-size-byte-half-load-store). Then the following configuration would be valid:

 

RV32I Zfinx Zcsbhldst

 

And this wouldn’t

 

RV32I Zcsbhldst

 

Because RV32I allocates those encodings to F for that base architecture. RV32I Zfinx doesn’t allocate them to F so they can be reallocated to Zcsldstbh.

 

Is this reasonable?

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!