Is there a lookup table somewhere that maps all the compressed instructions to the regular ones?

[Артём Литвинович]

I'm writing a RISC-V emulator, and i'm lazy.

It developed that bbl does not actually emulate compressed instructions, so i would have to implement them in order to run anything interesting like real linux distros.

However, from reading the specs i got an impression that each C instruction got an equivalent G instruction, which means it's possible to make an exhaustive lookup table that maps every 16 bit instruction into a corresponding 32bit one.

If so, it feels like the way to go as far as software design goes, which make me wonder if any of the existing emulators already did this, or even if there is an official version of the said table somewhere.

So, the question is - where can i find one?

If it was never done, why?

If there is no reason, where should i post it after i make one myself?

[Tommy Thorn]

I'm not aware of such a thing and would encourage you to make it and share it.

A good place to start is https://github.com/riscv/riscv-opcodes; the 39 line lists the

32 patterns which can _almost_ be mechanically translated to the G-equivalent

(addi4spn, and most of C2 need a bit of help).

Tommy

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/98200fe9-4839-4c76-bc34-b7b88d55721c%40groups.riscv.org.

[Schuyler Eldridge]

Take a look at riscv-meta (https://github.com/michaeljclark/riscv-meta). That may be a good place to start.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/66E346A7-C0E8-4700-8DF7-C703DA627C2E%40esperantotech.com.

[Andrew Waterman]

There’s also Rocket’s RVC expander: https://github.com/freechipsproject/rocket-chip/blob/master/src/main/scala/rocket/RVC.scala

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAG%3DZR1tATsTuR0yruQDS2Tjy4a%3DvRPec_2T6opo7EVFrCRmeNA%40mail.gmail.com.

[Rogier Brussee]

You are right that every C instruction "expands" to a unique I (or FD load/store) instruction, sometimes with "expansion"  of a 3 bit enumerated common register into 5 bit enumerated ordinary register,

sometimes with special choices of architectural register (such as ra and zero) and sometimes with shifting in zeros in immediates that correspond to aligned loads and stores.

Most of the opcodes are in this spread sheet, Look for the ones marked Cxi

https://drive.google.com/file/d/0ByVaAMf8--EqYnIxRF9vQ0pvQ2c/view?usp=sharing

Rogier.

Op maandag 10 september 2018 01:55:10 UTC+2 schreef Артём Литвинович:

[Deepa N Sarma]

Hi ,

I had created a C to G mapping while adding Compressed extension to Shakthi -Eclass

Hope you find this useful

https://docs.google.com/spreadsheets/d/10-HUHdRy3OeKuP0KePUW85ucgA4gtkRSA4EYrZeU80Y/edit?usp=sharing

Regards,

Deepa

Project Officer

RISE LAB

IIT Chennai

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/553fd303-cb91-4cf2-ac75-da5103b59bbe%40groups.riscv.org.

[Артём Литвинович]

Hm, guess i'm not going to be lucky enough to get an actual include file with a table, but thanks for all the neat reference material.

I'll be sure to publish the tables once they are done and verified.

[Артём Литвинович]

Sigh, and after a day of work i'm rewarded with a passing rv64uc-p-rvc test, no RVC support in riscv-torture and a Linux kernel that fails in a mysterious way when compiled with compressed instructions...

How come riscv-torture supports the not-yet-existent vector extensions, but doesn't support the effectively-in-G compressed extension?

Or am i missing something in it's configs?

[Andrew Waterman]

On Mon, Sep 10, 2018 at 4:41 PM, Артём Литвинович <thea...@gmail.com> wrote:

Sigh, and after a day of work i'm rewarded with a passing rv64uc-p-rvc test, no RVC support in riscv-torture and a Linux kernel that fails in a mysterious way when compiled with compressed instructions...

That sounds to me like a very productive day, not worthy of griping.

 

How come riscv-torture supports the not-yet-existent vector extensions, but doesn't support the effectively-in-G compressed extension?

Because torture predates the C extension but does not predate some experimental vector extensions.

Improving the number and quality of tests is everyone's problem.   If you find them lacking and can donate the time to improve them, please contribute your improvements.

Or am i missing something in it's configs?

It looks hardwired to RV64G, but it should just be a matter of changing the assembler command line: https://github.com/ucb-bar/riscv-torture/blob/master/testrun/src/main/scala/main.scala#L151

The coverage will be poor if torture isn't taught to bias the register allocator and immediate selector, but it's better than nothing.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/f0b7ef39-1787-454c-ab6e-4c56488fb184%40groups.riscv.org.

[Артём Литвинович]

Improving the number and quality of tests is everyone's problem.   If you find them lacking and can donate the time to improve them, please contribute your improvements.

I have actually been collecting notes on the bugs encountered after all tests passed, with intention to expand the coverage a bit.

Hopefully i'll get to it eventually.

The coverage will be poor if torture isn't taught to bias the register allocator and immediate selector, but it's better than nothing.

Yeah, tweaking the invocation did make it produce some C instructions, but it's less than 1% and got no interesting edge cases what-so-ever.

In the end i just ran Linux with and without C in parallel to locate the point of divergence, which led me to a sign extension issue with c.j instruction, something that isn't covered by either the tests or the pitiful subset of instructions torture tester generated.

Since there is a total of only 49152 RVC instructions, it should be possible to do exhaustive testing of the mapping of them into the 32bit space, thus perfectly reducing the testing problem to the already well covered base set.

So the table i'll be making should be a significantly better debugging tool than any tweaks to the torture tester (which i can't really do since i'm not familiar with scala).

[Michael Clark]

On 11/09/2018, at 12:44 AM, Артём Литвинович <thea...@gmail.com> wrote:

Hm, guess i'm not going to be lucky enough to get an actual include file with a table, but thanks for all the neat reference material.

I'll be sure to publish the tables once they are done and verified.

It sounds like you are well on your way now; however;

There are tables here in C although some of it is switch statements:

https://github.com/michaeljclark/riscv-disassembler

I just fixed a bug with reserved encodings (compressed instructions that have non-zero immediate constraints). I have booted RVC Linux from the riscv-meta compression metadata although this was in the Privilege ISA v1.9.1 timeframe. It should not have been affected by this bug because the reversed encodings are not generated by the assembler; however they are useful test cases; because the knock out depends on immediate decode, which depends on opcode or type. I had to add code to translate these to illegal after decompression to the Base ISA opcode.

Also note there is a pseudo lifting stage which uses another set of constraints to map the Base ISA instruction after decompression to the set of simple single instruction pseudo instructions (not call, tail, li or la as they require a state machine across more than one instruction). A pipeline may have move detection in its rename stage so a mv uop might be useful (it does this for Base and Compressed).

The interesting case is 0x0000 which has an interesting natural decompression and lift to “mv s0, sp” (inst[1:0]=0b00, funct3=0, op=c.addi4spn, rs2=sp;implicit, rs1=compressed-reg-0 or x8). This interesting case is further obfuscated due to the move pattern.

Executing 0 data would be interesting if any silicon had this bug. Also of note is that the Base ISA and Compressed ISA have different move patterns. Andrew Waterman added a note regarding this as it affects move detection.

I have another repo ‘rv8’ that has an object model for the riscv-meta metadata along with a generator framework for machine generation. Here is LaTeX PDF generated from the metadata. It’s quite similar to the ISA spec:

https://github.com/michaeljclark/rv8/blob/master/doc/pdf/riscv-instructions.pdf

I’m curious about your J bug, as I should double-check riscv-meta against your findings. I actually made the same mistake with signed vs zero-extended immediate forms because the Base ISA is all sign extended. Since then Andrew Waterman and others have revised this area of the spec to be more precise. We could move to a notation that is completely unambiguous as this was a slight usability issue for the spec.

It might be nice to have a sign-extend(x) zero-extend(x) type notation although it depends on what will fit in the tables. In my own notation I use sx(x) and ux(x) for signed and unsigned respectively. The immediate names for some of the opcodes could be somewhat improved as z has different potential interpretations. In fact with the generator it’s relatively easy to make these sorts of changes with relative safety once the metadata has been verified.

Indeed there is the potential to create new formats of the docs and diagrams using PGF/TiKZ. I must review the PDF to see if there is anything we could improve.

Michael

[Артём Литвинович]

Ok, it's more or less done. rv64imac compiled bbl, linux and userspace seem to work just fine, and that's about as far as i can test it.

I've included the generator as well.

https://github.com/artlav/riscv-c2g-table

Hope other people would find this useful.

I’m curious about your J bug, as I should double-check riscv-meta against your findings.

That was a simple case of a typo - i was sign extending on the wrong bit.
Took 14 million instructions deep into the Linux kernel before a jump far enough happened, however.

I have another repo ‘rv8’ that has an object model for the riscv-meta metadata along with a generator framework for machine generation. Here is LaTeX PDF generated from the metadata. It’s quite similar to the ISA spec:
https://github.com/michaeljclark/rv8/blob/master/doc/pdf/riscv-instructions.pdf

I actually made the same mistake with signed vs zero-extended immediate forms because the Base ISA is all sign extended. Since then Andrew Waterman and others have revised this area of the spec to be more precise. We could move to a notation that is completely unambiguous as this was a slight usability issue for the spec.

Neat. Once of the frustrations i had is that the official specs have the descriptions in one place and the actual encoding and bit values in another place, so i had to constantly flip the pdf back and forth.
It would be nice to have a all-in-one-place, formally defined spec.