Topics

Re-use of 16-bit encodings between standard extensions


Tariq Kurd
 

Hi everyone,

 

Following discussions with Krste, he has decided to allow reuse of a subset of 16-bit encodings for code-size reduction instructions.

This is a very important step for the code-size reduction work, and is key to success against the competition.

 

The principle is to allow reuse of the16-bit  double precision encodings in the case that

-          The core does not support D, OR

-          The core supports Zfinx

 

As in both cases the encodings are reserved, and highly valuable.

 

If we divide up the C extension into sub-extensions:

 

Zcd        C.FLD, C.FSD, C.FLDSP, C.FSDSP                             

Zcf         C.FLW, C.FSW, C.FLWSP, C.FSWSP                                                                                  

Zci_base all other existing 16-bit encodings                                     

 

And define a new 16-bit code-size reduction extension Zce which is defined as follows (E for embedded)

 

Zce_ldstbh         C.LHU, C.LBU, C.SH, C.SB (which reuse the encodings for C.FLDSP, C.FLD, C.FSDP, C.FSD respectively)

Zce_base            all other Zce encodings 

 

Then, as an example the encoding of 16’b101____00 means the following for different combinations of Zce, D and Zfinx. Note that Zfinx removes all floating point load/store instructions.

 

RV32/64C                         reserved

RV32/64CD                      C.FSD

RV32/64CD_Zfinx           reserved

 

RV32/64C_Zce                 C.LHU

RV32/64CD_Zce              C.FSD

RV32/64CD_Zce_Zfinx   C.LHU

 

There are no plans to reuse Zcf encodings as the F-extension is too important for embedded cores.

 

This gives us many issues to solve

-          How to discover the meaning of the encodings by CPU instructions, memory map, debug probe

-          How to decode the ELF file / ELF header information, which will need to distinguish between these cases

-          How this fits with the instruction allocation policy, as this type of reuse is not currently permitted

 

This affects several different task groups, but this first step is to make the proposal to the unpriv committee

 

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 !

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

 


mark
 

I think we have a general discovery discussion going on. I am CCing Krste and Tim and Jim to comment as appropriate (although they may already be on the list)

We need to solve this generally and apply the decisions here for both discovery from the RISC-V device and how to distinguish it in an elf binary (and how it interacts with other extensions -- is there precedence where there is conflict? do we need an address range within the binary that it applies to or is it only for the whole binary?

On Fri, Nov 13, 2020 at 3:31 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

Following discussions with Krste, he has decided to allow reuse of a subset of 16-bit encodings for code-size reduction instructions.

This is a very important step for the code-size reduction work, and is key to success against the competition.

 

The principle is to allow reuse of the16-bit  double precision encodings in the case that

-          The core does not support D, OR

-          The core supports Zfinx

 

As in both cases the encodings are reserved, and highly valuable.

 

If we divide up the C extension into sub-extensions:

 

Zcd        C.FLD, C.FSD, C.FLDSP, C.FSDSP                             

Zcf         C.FLW, C.FSW, C.FLWSP, C.FSWSP                                                                                  

Zci_base all other existing 16-bit encodings                                     

 

And define a new 16-bit code-size reduction extension Zce which is defined as follows (E for embedded)

 

Zce_ldstbh         C.LHU, C.LBU, C.SH, C.SB (which reuse the encodings for C.FLDSP, C.FLD, C.FSDP, C.FSD respectively)

Zce_base            all other Zce encodings 

 

Then, as an example the encoding of 16’b101____00 means the following for different combinations of Zce, D and Zfinx. Note that Zfinx removes all floating point load/store instructions.

 

RV32/64C                         reserved

RV32/64CD                      C.FSD

RV32/64CD_Zfinx           reserved

 

RV32/64C_Zce                 C.LHU

RV32/64CD_Zce              C.FSD

RV32/64CD_Zce_Zfinx   C.LHU

 

There are no plans to reuse Zcf encodings as the F-extension is too important for embedded cores.

 

This gives us many issues to solve

-          How to discover the meaning of the encodings by CPU instructions, memory map, debug probe

-          How to decode the ELF file / ELF header information, which will need to distinguish between these cases

-          How this fits with the instruction allocation policy, as this type of reuse is not currently permitted

 

This affects several different task groups, but this first step is to make the proposal to the unpriv committee

 

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 !

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

 


Krste Asanovic
 

On Fri, 13 Nov 2020 11:31:44 +0000, "Tariq Kurd via lists.riscv.org" <tariq.kurd=huawei.com@lists.riscv.org> said:
| Hi everyone,
| Following discussions with Krste, he has decided to allow reuse of a subset of 16-bit encodings for code-size
| reduction instructions.

[...]

To be clear, it's only a proposal from me, reflecting discussions with
a large number of other people over several years, not an executive
order. Everything needs to be ratified by org.

| Zci_base all other existing 16-bit encodings

Can't use "_" in name here, or in below names - it's the separator
between extensions.

Krste

| And define a new 16-bit code-size reduction extension Zce which is defined as follows (EE for embedded)

| Zce_ldstbh C.LHU, C.LBU, C.SH, C.SB (which reuse the encodings for C.FLDSP, C.FLD, C.FSDP, C.FSD
| respectively)

| Zce_base all other Zce encodings

| Then, as an example the encoding of 16’b101____00 means the following for different combinations of Zce, D and
| Zfinx. Note that Zfinx removes all floating point load/store instructions.

| RV32/64C reserved

| RV32/64CD C.FSD

| RV32/64CD_Zfinx reserved

| RV32/64C_Zce C.LHU

| RV32/64CD_Zce C.FSD

| RV32/64CD_Zce_Zfinx C.LHU

| There are no plans to reuse Zcf encodings as the F-extension is too important for embedded cores.

| This gives us many issues to solve

| - How to discover the meaning of the encodings by CPU instructions, memory map, debug probe

| - How to decode the ELF file / ELF header information, which will need to distinguish between these
| cases

| - How this fits with the instruction allocation policy, as this type of reuse is not currently
| permitted

| This affects several different task groups, but this first step is to make the proposal to the unpriv committee

| Tariq

| Tariq Kurd

| Processor Design I RISC-V Cores, Bristol

| E-mail: Tariq.Kurd@Huawei.com

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

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

| cid:image002.jpg@01D4BC65.4BB52AF0

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

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

|
| x[DELETED ATTACHMENT image001.png, PNG image]
| x[DELETED ATTACHMENT image002.jpg, JPEG image]


mark
 

+arun +phillip
psABI committee?

On Fri, Nov 13, 2020 at 2:01 PM Jim Wilson <jimw@...> wrote:
On Fri, Nov 13, 2020 at 10:18 AM Mark Himelstein <markhimelstein@...> wrote:
I think we have a general discovery discussion going on. I am CCing Krste and Tim and Jim to comment as appropriate (although they may already be on the list)

We need to solve this generally and apply the decisions here for both discovery from the RISC-V device and how to distinguish it in an elf binary (and how it interacts with other extensions -- is there precedence where there is conflict? do we need an address range within the binary that it applies to or is it only for the whole binary?

I'm happy to leave the hardware discussions to others.  And I haven't been following the discovery discussion as I'm not sure that it is relevant to a compiler guy.  It is more of a kernel and debugger problem.

On the toolchain side, we already have support to control which instructions exist based on the architecture extensions selected.  Reusing opcodes doesn't compilate this.  I would hope that the Unix Platform Spec disallows extensions that reuse encodings as this likely won't work for desktop linux systems, though if someone wants to enable that for an embedded linux system that is OK.

We do need a way to represent this info in the ELF executable file.  We already have ELF attributes (similar to ARM attributes) that include info about how the file was compiled, including the -march option string.  It would be more convenient to have ELF header flags, but there are only 32 of them, so we need to be careful about how we allocate them.  This is something that should probably be handled in the psABI committee if we had one, but I guess the toolchain&runtimes subcommittee is it for now.

Jim


Philipp Tomsich <ptomsich@...>
 

Known issue. Should become a TG under T&R.

On Fri 13. Nov 2020 at 23:24, Mark Himelstein <markhimelstein@...> wrote:
+arun +phillip
psABI committee?

On Fri, Nov 13, 2020 at 2:01 PM Jim Wilson <jimw@...> wrote:
On Fri, Nov 13, 2020 at 10:18 AM Mark Himelstein <markhimelstein@...> wrote:
I think we have a general discovery discussion going on. I am CCing Krste and Tim and Jim to comment as appropriate (although they may already be on the list)

We need to solve this generally and apply the decisions here for both discovery from the RISC-V device and how to distinguish it in an elf binary (and how it interacts with other extensions -- is there precedence where there is conflict? do we need an address range within the binary that it applies to or is it only for the whole binary?

I'm happy to leave the hardware discussions to others.  And I haven't been following the discovery discussion as I'm not sure that it is relevant to a compiler guy.  It is more of a kernel and debugger problem.

On the toolchain side, we already have support to control which instructions exist based on the architecture extensions selected.  Reusing opcodes doesn't compilate this.  I would hope that the Unix Platform Spec disallows extensions that reuse encodings as this likely won't work for desktop linux systems, though if someone wants to enable that for an embedded linux system that is OK.

We do need a way to represent this info in the ELF executable file.  We already have ELF attributes (similar to ARM attributes) that include info about how the file was compiled, including the -march option string.  It would be more convenient to have ELF header flags, but there are only 32 of them, so we need to be careful about how we allocate them.  This is something that should probably be handled in the psABI committee if we had one, but I guess the toolchain&runtimes subcommittee is it for now.

Jim


Jim Wilson <jimw@...>
 

On Fri, Nov 13, 2020 at 10:18 AM Mark Himelstein <markhimelstein@...> wrote:
I think we have a general discovery discussion going on. I am CCing Krste and Tim and Jim to comment as appropriate (although they may already be on the list)

We need to solve this generally and apply the decisions here for both discovery from the RISC-V device and how to distinguish it in an elf binary (and how it interacts with other extensions -- is there precedence where there is conflict? do we need an address range within the binary that it applies to or is it only for the whole binary?

I'm happy to leave the hardware discussions to others.  And I haven't been following the discovery discussion as I'm not sure that it is relevant to a compiler guy.  It is more of a kernel and debugger problem.

On the toolchain side, we already have support to control which instructions exist based on the architecture extensions selected.  Reusing opcodes doesn't compilate this.  I would hope that the Unix Platform Spec disallows extensions that reuse encodings as this likely won't work for desktop linux systems, though if someone wants to enable that for an embedded linux system that is OK.

We do need a way to represent this info in the ELF executable file.  We already have ELF attributes (similar to ARM attributes) that include info about how the file was compiled, including the -march option string.  It would be more convenient to have ELF header flags, but there are only 32 of them, so we need to be careful about how we allocate them.  This is something that should probably be handled in the psABI committee if we had one, but I guess the toolchain&runtimes subcommittee is it for now.

Jim


Tim Newsome <tim@...>
 

On Fri, Nov 13, 2020 at 10:18 AM Mark Himelstein <markhimelstein@...> wrote:

Following discussions with Krste, he has decided to allow reuse of a subset of 16-bit encodings for code-size reduction instructions.

This is a very important step for the code-size reduction work, and is key to success against the competition.

 

-          How to discover the meaning of the encodings by CPU instructions, memory map, debug probe


An external debugger would prefer to read a CSR bit or a bool in a configuration structure type thing, if it exists.

Requiring software to try to execute some 16-bit instruction and see the result would be doable, but introduces lots of complexity for the debugger. I'd like to avoid that.

Tim


Tariq Kurd
 

Hi everyone,

 

With help from Allen I’ve made a spreadsheet dividing up the existing C-extension into subsets, and adding in the code-size reduction ISA proposals.

 

The current 16-bit proposals are here:

 

https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/16bit_encodings.adoc

 

which links to the spreadsheet:

 

https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/C-extension%20subsets.xlsx

 

The proposed extension Zce is split into

Zcebase – always present if Zce is configured

Zcemultistep – all multistep instructions (PUSH/POP for now) so they can be removed for high performance cores

Zceldstbh – 16-bit encodings for load/store byte/half which reuse the D-extension 16-bit encodings

 

Please give me your feedback

 

Tariq

 

From: Tim Newsome [mailto:tim@...]
Sent: 16 November 2020 21:12
To: Mark Himelstein <markhimelstein@...>
Cc: tech-unprivileged@...; Tariq Kurd <tariq.kurd@...>; Jim Wilson <jimw@...>; Krste Asanovic <krste@...>
Subject: Re: [RISC-V] [tech-unprivileged] Re-use of 16-bit encodings between standard extensions

 

On Fri, Nov 13, 2020 at 10:18 AM Mark Himelstein <markhimelstein@...> wrote:

Following discussions with Krste, he has decided to allow reuse of a subset of 16-bit encodings for code-size reduction instructions.

This is a very important step for the code-size reduction work, and is key to success against the competition.

 

-          How to discover the meaning of the encodings by CPU instructions, memory map, debug probe

 

An external debugger would prefer to read a CSR bit or a bool in a configuration structure type thing, if it exists.

 

Requiring software to try to execute some 16-bit instruction and see the result would be doable, but introduces lots of complexity for the debugger. I'd like to avoid that.

 

Tim


Allen Baum
 

Small correct: the condition text for C.SLLI should be (rd=0:HINT; RV32&nzuimm[5]=1:NSE )

On Wed, Nov 18, 2020 at 2:39 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

With help from Allen I’ve made a spreadsheet dividing up the existing C-extension into subsets, and adding in the code-size reduction ISA proposals.

 

The current 16-bit proposals are here:

 

https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/16bit_encodings.adoc

 

which links to the spreadsheet:

 

https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/C-extension%20subsets.xlsx

 

The proposed extension Zce is split into

Zcebase – always present if Zce is configured

Zcemultistep – all multistep instructions (PUSH/POP for now) so they can be removed for high performance cores

Zceldstbh – 16-bit encodings for load/store byte/half which reuse the D-extension 16-bit encodings

 

Please give me your feedback

 

Tariq

 

From: Tim Newsome [mailto:tim@...]
Sent: 16 November 2020 21:12
To: Mark Himelstein <markhimelstein@...>
Cc: tech-unprivileged@...; Tariq Kurd <tariq.kurd@...>; Jim Wilson <jimw@...>; Krste Asanovic <krste@...>
Subject: Re: [RISC-V] [tech-unprivileged] Re-use of 16-bit encodings between standard extensions

 

On Fri, Nov 13, 2020 at 10:18 AM Mark Himelstein <markhimelstein@...> wrote:

Following discussions with Krste, he has decided to allow reuse of a subset of 16-bit encodings for code-size reduction instructions.

This is a very important step for the code-size reduction work, and is key to success against the competition.

 

-          How to discover the meaning of the encodings by CPU instructions, memory map, debug probe

 

An external debugger would prefer to read a CSR bit or a bool in a configuration structure type thing, if it exists.

 

Requiring software to try to execute some 16-bit instruction and see the result would be doable, but introduces lots of complexity for the debugger. I'd like to avoid that.

 

Tim


Krste Asanovic
 

For each 16-bit instruction, please give (e.g., in Table 7) the
expansion into existing 32-bit instructions where possible, or note
the equivalent 32-bit instruction sequence.

I also think it would be much clearer to use rd' instead of rs1' for
the source operand when describing instructions where a single
register specifier (rd'/rs1') is used for both source and destination.

Krste


On Wed, 18 Nov 2020 10:39:25 +0000, Tariq Kurd <tariq.kurd@huawei.com> said:
| Hi everyone,
| With help from Allen I’ve made a spreadsheet dividing up the existing C-extension into subsets, and adding in the code-size reduction ISA proposals.

| The current 16-bit proposals are here:

| https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/16bit_encodings.adoc

| which links to the spreadsheet:

| https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/C-extension%20subsets.xlsx

| The proposed extension Zce is split into

| Zcebase – always present if Zce is configured

| Zcemultistep – all multistep instructions (PUSH/POP for now) so they can be removed for high performance cores

| Zceldstbh – 16-bit encodings for load/store byte/half which reuse the D-extension 16-bit encodings

| Please give me your feedback

| Tariq

| From: Tim Newsome [mailto:tim@sifive.com]
| Sent: 16 November 2020 21:12
| To: Mark Himelstein <markhimelstein@riscv.org>
| Cc: tech-unprivileged@lists.riscv.org; Tariq Kurd <tariq.kurd@huawei.com>; Jim Wilson <jimw@sifive.com>; Krste Asanovic <krste@berkeley.edu>
| Subject: Re: [RISC-V] [tech-unprivileged] Re-use of 16-bit encodings between standard extensions

| On Fri, Nov 13, 2020 at 10:18 AM Mark Himelstein <markhimelstein@riscv.org> wrote:

| Following discussions with Krste, he has decided to allow reuse of a subset of 16-bit encodings for code-size reduction instructions.

| This is a very important step for the code-size reduction work, and is key to success against the competition.

| - How to discover the meaning of the encodings by CPU instructions, memory map, debug probe

| An external debugger would prefer to read a CSR bit or a bool in a configuration structure type thing, if it exists.

| Requiring software to try to execute some 16-bit instruction and see the result would be doable, but introduces lots of complexity for the debugger. I'd like to avoid that.

| Tim


Tariq Kurd
 

Thanks for the feedback.
I've added the 32-bit equivalent instructions now and have tweaked the spreadsheet as suggested by Allen.

Tariq

-----Original Message-----
From: krste@berkeley.edu [mailto:krste@berkeley.edu]
Sent: 19 November 2020 07:23
To: Tariq Kurd <tariq.kurd@huawei.com>
Cc: Tim Newsome <tim@sifive.com>; Mark Himelstein <markhimelstein@riscv.org>; tech-unprivileged@lists.riscv.org; Jim Wilson <jimw@sifive.com>; Krste Asanovic <krste@berkeley.edu>; ds2horner@gmail.com
Subject: RE: [RISC-V] [tech-unprivileged] Re-use of 16-bit encodings between standard extensions


For each 16-bit instruction, please give (e.g., in Table 7) the expansion into existing 32-bit instructions where possible, or note the equivalent 32-bit instruction sequence.

I also think it would be much clearer to use rd' instead of rs1' for the source operand when describing instructions where a single register specifier (rd'/rs1') is used for both source and destination.

Krste


On Wed, 18 Nov 2020 10:39:25 +0000, Tariq Kurd <tariq.kurd@huawei.com> said:
| Hi everyone,
| With help from Allen I’ve made a spreadsheet dividing up the existing C-extension into subsets, and adding in the code-size reduction ISA proposals.

| The current 16-bit proposals are here:

| https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20p
| roposals/Huawei/16bit_encodings.adoc

| which links to the spreadsheet:

| https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20p
| roposals/Huawei/C-extension%20subsets.xlsx

| The proposed extension Zce is split into

| Zcebase – always present if Zce is configured

| Zcemultistep – all multistep instructions (PUSH/POP for now) so they
| can be removed for high performance cores

| Zceldstbh – 16-bit encodings for load/store byte/half which reuse the
| D-extension 16-bit encodings

| Please give me your feedback

| Tariq

| From: Tim Newsome [mailto:tim@sifive.com]
| Sent: 16 November 2020 21:12
| To: Mark Himelstein <markhimelstein@riscv.org>
| Cc: tech-unprivileged@lists.riscv.org; Tariq Kurd
| <tariq.kurd@huawei.com>; Jim Wilson <jimw@sifive.com>; Krste Asanovic
| <krste@berkeley.edu>
| Subject: Re: [RISC-V] [tech-unprivileged] Re-use of 16-bit encodings
| between standard extensions

| On Fri, Nov 13, 2020 at 10:18 AM Mark Himelstein <markhimelstein@riscv.org> wrote:

| Following discussions with Krste, he has decided to allow reuse of a subset of 16-bit encodings for code-size reduction instructions.

| This is a very important step for the code-size reduction work, and is key to success against the competition.

| - How to discover the meaning of the encodings by CPU instructions, memory map, debug probe

| An external debugger would prefer to read a CSR bit or a bool in a configuration structure type thing, if it exists.

| Requiring software to try to execute some 16-bit instruction and see the result would be doable, but introduces lots of complexity for the debugger. I'd like to avoid that.

| Tim