Topics

48-bit encodings


Tariq Kurd
 

Hi everyone,

 

The question of 48-bit encodings came up in the code size meeting today.

Mark Himelstein pointed out that if any such encodings are to be allowed in RVA22/RVM22 then the extension mechanism needs to be determined in the next couple of months.

 

Is there any  plan to do this?

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Aztec West, Bristol, UK, BS32 4TR

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
 

I'm not sure I understand the question.
The encodings have been defined (as a group that is; all 48 bit encodings must have bits 5:0==0b011111)
Beyond that: is the extension mechanism any different than asking for 16 and 32 bit opcode semantics and encoding to be approved ?

On Tue, Jan 12, 2021 at 8:15 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

The question of 48-bit encodings came up in the code size meeting today.

Mark Himelstein pointed out that if any such encodings are to be allowed in RVA22/RVM22 then the extension mechanism needs to be determined in the next couple of months.

 

Is there any  plan to do this?

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Aztec West, Bristol, UK, BS32 4TR

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
 

The >32b encodings have not been ratified and there are proposals circulating for alternate >32b encodings,

Krste

On Jan 12, 2021, at 5:04 PM, Allen Baum <allen.baum@...> wrote:

I'm not sure I understand the question.
The encodings have been defined (as a group that is; all 48 bit encodings must have bits 5:0==0b011111)
Beyond that: is the extension mechanism any different than asking for 16 and 32 bit opcode semantics and encoding to be approved ?

On Tue, Jan 12, 2021 at 8:15 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

The question of 48-bit encodings came up in the code size meeting today.

Mark Himelstein pointed out that if any such encodings are to be allowed in RVA22/RVM22 then the extension mechanism needs to be determined in the next couple of months.

 

Is there any  plan to do this?

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Aztec West, Bristol, UK, BS32 4TR

<image001.png>    http://www.huawei.com

<image002.jpg>

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
 

Yes – so the real question is whether we want to push forwards with ratifying the encoding scheme for RV*22, or whether it can wait another year.

 

I’m not currently analysing any 48-bit encodings because the mechanism isn’t ratified. My feeling is that we don’t need them for the first version of the code size reduction extension, as there are other things I’d like to get in place first.

 

Tariq

 

From: Krste Asanovic [mailto:krste@...]
Sent: 13 January 2021 01:06
To: tech-unprivileged@...; Allen Baum <allen.baum@...>
Cc: Tariq Kurd <tariq.kurd@...>; Mark Himelstein <markhimelstein@...>
Subject: Re: [RISC-V] [tech-unprivileged] 48-bit encodings

 

The >32b encodings have not been ratified and there are proposals circulating for alternate >32b encodings,


Krste



On Jan 12, 2021, at 5:04 PM, Allen Baum <allen.baum@...> wrote:

 

I'm not sure I understand the question.

The encodings have been defined (as a group that is; all 48 bit encodings must have bits 5:0==0b011111)

Beyond that: is the extension mechanism any different than asking for 16 and 32 bit opcode semantics and encoding to be approved ?

 

On Tue, Jan 12, 2021 at 8:15 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

The question of 48-bit encodings came up in the code size meeting today.

Mark Himelstein pointed out that if any such encodings are to be allowed in RVA22/RVM22 then the extension mechanism needs to be determined in the next couple of months.

 

Is there any  plan to do this?

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Aztec West, Bristol, UK, BS32 4TR

<image001.png>    http://www.huawei.com

<image002.jpg>

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
 

Yes - focus on ILEN<=32b code-size extensions first. These will be
immediately useful in more implementations, and will already take
plenty of work to whittle down into shape for RVM22.

Krste

On Wed, 13 Jan 2021 17:55:11 +0000, Tariq Kurd <tariq.kurd@huawei.com> said:
| Yes – so the real question is whether we want to push forwards with ratifying the encoding scheme for RV*22, or whether it can wait another year.
| I’m not currently analysing any 48-bit encodings because the mechanism isn’t ratified. My feeling is that we don’t need them for the first version of the code size reduction extension, as there are
| other things I’d like to get in place first.

| Tariq

| From: Krste Asanovic [mailto:krste@berkeley.edu]
| Sent: 13 January 2021 01:06
| To: tech-unprivileged@lists.riscv.org; Allen Baum <allen.baum@esperantotech.com>
| Cc: Tariq Kurd <tariq.kurd@huawei.com>; Mark Himelstein <markhimelstein@riscv.org>
| Subject: Re: [RISC-V] [tech-unprivileged] 48-bit encodings

| The >32b encodings have not been ratified and there are proposals circulating for alternate >32b encodings,

| Krste

| On Jan 12, 2021, at 5:04 PM, Allen Baum <allen.baum@esperantotech.com> wrote:

| I'm not sure I understand the question.

| The encodings have been defined (as a group that is; all 48 bit encodings must have bits 5:0==0b011111)

| Beyond that: is the extension mechanism any different than asking for 16 and 32 bit opcode semantics and encoding to be approved ?

| On Tue, Jan 12, 2021 at 8:15 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@lists.riscv.org> wrote:

| Hi everyone,

| The question of 48-bit encodings came up in the code size meeting today.

| Mark Himelstein pointed out that if any such encodings are to be allowed in RVA22/RVM22 then the extension mechanism needs to be determined in the next couple of months.

| Is there any plan to do this?

| Tariq

| Tariq Kurd

| Processor Design I RISC-V Cores, Bristol

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

| Company: Huawei technologies R&D (UK) Ltd I Address: 290 Aztec West, Bristol, UK, BS32 4TR

| <image001.png> http://www.huawei.com

| <image002.jpg>

| 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 will start RV*22 documents so we can start memorializing some of these proposed decisions so we don't have to revisit them repeatedly and people can look and comment. We can merge them into some final doc or use this as the final doc.

Mark

On Thu, Jan 14, 2021 at 11:09 PM <krste@...> wrote:

Yes - focus on ILEN<=32b code-size extensions first.  These will be
immediately useful in more implementations, and will already take
plenty of work to whittle down into shape for RVM22.

Krste

>>>>> On Wed, 13 Jan 2021 17:55:11 +0000, Tariq Kurd <tariq.kurd@...> said:

| Yes – so the real question is whether we want to push forwards with ratifying the encoding scheme for RV*22, or whether it can wait another year.
| I’m not currently analysing any 48-bit encodings because the mechanism isn’t ratified. My feeling is that we don’t need them for the first version of the code size reduction extension, as there are
| other things I’d like to get in place first.

| Tariq

| From: Krste Asanovic [mailto:krste@...]
| Sent: 13 January 2021 01:06
| To: tech-unprivileged@...; Allen Baum <allen.baum@...>
| Cc: Tariq Kurd <tariq.kurd@...>; Mark Himelstein <markhimelstein@...>
| Subject: Re: [RISC-V] [tech-unprivileged] 48-bit encodings

| The >32b encodings have not been ratified and there are proposals circulating for alternate >32b encodings,

| Krste

|     On Jan 12, 2021, at 5:04 PM, Allen Baum <allen.baum@...> wrote:

|     I'm not sure I understand the question.

|     The encodings have been defined (as a group that is; all 48 bit encodings must have bits 5:0==0b011111)

|     Beyond that: is the extension mechanism any different than asking for 16 and 32 bit opcode semantics and encoding to be approved ?

|     On Tue, Jan 12, 2021 at 8:15 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

|         Hi everyone,

|         The question of 48-bit encodings came up in the code size meeting today.

|         Mark Himelstein pointed out that if any such encodings are to be allowed in RVA22/RVM22 then the extension mechanism needs to be determined in the next couple of months.

|         Is there any  plan to do this?

|         Tariq

|         Tariq Kurd

|         Processor Design I RISC-V Cores, Bristol

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

|         Company: Huawei technologies R&D (UK) Ltd I Address: 290 Aztec West, Bristol, UK, BS32 4TR

|         <image001.png>    http://www.huawei.com

|         <image002.jpg>

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

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