Topics

xpulp


mark
 

At the open source for him I just got asked by a gentleman name Shavon Pantar about Xpulp which is being done by ETH. He would like to see about making this a standard extension. I believe it falls under the umbrella of a privileged and if he contacts me I will put them in contact with this group.

I told him it was a community decision and that anyone can start an extension with the approval of the community and the governing standing committee and TSC.

Mark


--
Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv


Greg Favor
 

I'm not sure, but my impression is that the instruction extensions implemented by xpulp are exactly in the realm of what the code size reduction TG is considering.  I blindly imagine this means that, by default, any xpulp standardization should be via that TG (which I'm guessing wouldn't happen since the TG is trying to develop a single code size reduction standard).  Or should any attempted xpulp standardization effort be via a separate TG?  Or?

Greg


On Mon, Oct 26, 2020 at 6:13 AM mark <markhimelstein@...> wrote:
At the open source for him I just got asked by a gentleman name Shavon Pantar about Xpulp which is being done by ETH. He would like to see about making this a standard extension. I believe it falls under the umbrella of a privileged and if he contacts me I will put them in contact with this group.

I told him it was a community decision and that anyone can start an extension with the approval of the community and the governing standing committee and TSC.

Mark


--
Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv


Allen Baum
 

Looks like Greg and I are looking at this the same way again.
To be clear: xPULP is an implementation with a bunch of added custom instructions.
From what I can tell, most seem to be already covered by the bitmanip extensions, so they probably don't need to be covered in an "Xpulp" extension,  but if it is important to them that the Xpulp opcodes be used (should that be "legal"), they need to work fast with the bitmanip TG, because those opcode assignments are being finalized as we speak.

I would guess that the remaining ones belong with the code-size TG, and as that is just starting up, they should be participating in that.
I don't see a need for a separate TG and I see conflicts if there is one.


On Mon, Oct 26, 2020 at 6:13 AM mark <markhimelstein@...> wrote:
At the open source for him I just got asked by a gentleman name Shavon Pantar about Xpulp which is being done by ETH. He would like to see about making this a standard extension. I believe it falls under the umbrella of a privileged and if he contacts me I will put them in contact with this group.

I told him it was a community decision and that anyone can start an extension with the approval of the community and the governing standing committee and TSC.

Mark


--
Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv


Krste Asanovic
 

On Mon, 26 Oct 2020 13:00:03 -0700, "Allen Baum" <allen.baum@esperantotech.com> said:
| Looks like Greg and I are looking at this the same way again.
| To be clear: xPULP is an implementation with a bunch of added custom instructions.
| From what I can tell, most seem to be already covered by the bitmanip extensions, so they probably don't need to be covered in an "Xpulp" extension,  but if it is important to them
| that the Xpulp opcodes be used (should that be "legal"), they need to work fast with the bitmanip TG, because those opcode assignments are being finalized as we speak.

I believe Pulp team also added a bunch that are covered by P
extension. Interested parties should review B and P and check if
there are any important gaps relative to Xpulp, before trying to start
a separate proposal.

| I would guess that the remaining ones belong with the code-size TG, and as that is just starting up, they should be participating in that.
| I don't see a need for a separate TG and I see conflicts if there is one.

I know Pulp also had zero-overhead loop instructions (not actually a
code-size reduction, but a performance tweak for small
implementations).

Krste

| On Mon, Oct 26, 2020 at 6:13 AM mark <markhimelstein@riscv.org> wrote:

| At the open source for him I just got asked by a gentleman name Shavon Pantar about Xpulp which is being done by ETH. He would like to see about making this a standard
| extension. I believe it falls under the umbrella of a privileged and if he contacts me I will put them in contact with this group.

| I told him it was a community decision and that anyone can start an extension with the approval of the community and the governing standing committee and TSC.

| Mark

| --
| Mark I Himelstein
| CTO RISC-V International
| +1-408-250-6611
| twitter @mark_riscv

|


Tariq Kurd
 

https://core-v-docs-verif-strat.readthedocs.io/projects/cv32e40p_um/en/latest/instruction_set_extensions.html#

they have post-increment loads, which are on my list for code-size reduction (although we might implement pre-increment instead TBD)
hardware loops, bit manip style.= instructions etc.

They've used a lot of major opcodes:

101 0111 reserved
110 0011 branch
011 0011 op
111 1011 custom-3
000 0011 load
010 0011 store
000 1011 custom-0

(maybe the reserved one is actually vector? Not sure...)

Given that they've used custom-0/3 it can't be standardised as it is

Tariq

-----Original Message-----
From: tech-unprivileged@lists.riscv.org [mailto:tech-unprivileged@lists.riscv.org] On Behalf Of Krste Asanovic
Sent: 27 October 2020 06:41
To: tech-unprivileged@lists.riscv.org; allen.baum@esperantotech.com
Cc: Mark Himelstein <markhimelstein@riscv.org>
Subject: Re: [RISC-V] [tech-unprivileged] xpulp


On Mon, 26 Oct 2020 13:00:03 -0700, "Allen Baum" <allen.baum@esperantotech.com> said:
| Looks like Greg and I are looking at this the same way again.
| To be clear: xPULP is an implementation with a bunch of added custom instructions.
| From what I can tell, most seem to be already covered by the bitmanip
| extensions, so they probably don't need to be covered in an "Xpulp" extension,  but if it is important to them that the Xpulp opcodes be used (should that be "legal"), they need to work fast with the bitmanip TG, because those opcode assignments are being finalized as we speak.

I believe Pulp team also added a bunch that are covered by P extension. Interested parties should review B and P and check if there are any important gaps relative to Xpulp, before trying to start a separate proposal.

| I would guess that the remaining ones belong with the code-size TG, and as that is just starting up, they should be participating in that.
| I don't see a need for a separate TG and I see conflicts if there is one.

I know Pulp also had zero-overhead loop instructions (not actually a code-size reduction, but a performance tweak for small implementations).

Krste

| On Mon, Oct 26, 2020 at 6:13 AM mark <markhimelstein@riscv.org> wrote:

| At the open source for him I just got asked by a gentleman name Shavon Pantar about Xpulp which is being done by ETH. He would like to see about making this a standard
| extension. I believe it falls under the umbrella of a privileged and if he contacts me I will put them in contact with this group.

| I told him it was a community decision and that anyone can start an extension with the approval of the community and the governing standing committee and TSC.

| Mark

| --
| Mark I Himelstein
| CTO RISC-V International
| +1-408-250-6611
| twitter @mark_riscv

|