C-extension memory alignment

[Marco Speziali]

Hi,

I'm developing a riscv core with support for compressed instructions.

I'm currently having a doubt about the memory alignment.

I know that supporting C means that the instruction memory is now 16-bit aligned. So, by fetching a 32-bit instruction there are three possible cases:

 |       compresses 16-bit       |       compresses 16-bit       |   (1)
 |                              non compresses 32-bit                         |   (2)
 |  compresses 16-bit  |  non compressed (first 16 bits)  |   (3)
31                                                                                             0

I don't understand how to recognize a 16-bit instruction.
I know that, in order to be a non-compressed instruction the first two bits must be 0b11, but what if I have a situation like this one:

 |  ...  11  | ... 01 |

31                      0

How can I be sure that I'm in the case (2). I could be in case (3) since there are no restrictions in for the bits 17-16 of a non compressed instruction.

Is there something that I'm missing?

Thanks

Marco Speziali

[Paul Campbell]

On Friday, 23 October 2020 11:20:27 PM NZDT Marco Speziali wrote:
> I'm developing a riscv core with support for compressed instructions.
> I'm currently having a doubt about the memory alignment.
> I know that supporting C means that the instruction memory is now 16-bit
> aligned. So, by fetching a 32-bit instruction there are three possible
>cases:

for fetching 32-bit bundles there's are actually 5 cases, you're missing:

4) the second half of a 32-bit instruction that started in cases 3) or 5)
followed by a 16-bit instruction
5) the second half of a 32-bit instruction that started in cases 3) or 5)
followed by the first half of a 32-bit instruction

> I don't understand how to recognize a 16-bit instruction.

Simple it starts with bits 1:0 not being 3.

What I think you're missing is that you need to keep track whether or not
you're halfway through decoding an instruction from the previous 32-bit
bundle, if that's the case you ignore bits 1:0.

What you can't do is just look at any 16-bit chunk and tell what sort of
instruction it is without knowing what's come before it

Paul

[Marco Speziali]

First of all thanks for the answer!

I did not include those 2 cases because I have an aligner that deals with that and I forgot to mention.

I only fetch aligned instructions.

1) Let's say I have the following situation:
| c.addi[15:0] | addi[31:16] |

c.addi[1:0] is 0b01 and addi[17:16] is rs1[2:1] (since the format is: | imm[11:0] | rs1 | funct3 | rd | opcode |)

Lets say also that rs1 is 0b00110 (x6), this means that rs1[2:1] is 0b11, hence (by looking at instr[1:0] I find 0b11) the 32-bit bundle could be confused with a 32-bit non-compressed instruction.

(in this point I assume that the first thing I do with the bundle is looking at the bits [1:0] so I try to find a non-compressed 32-bit instruction)

2) Let's say I have the following situation:
| addi[31:0] |

If in this case the first thing I try to find is the compressed-instruction (instr[17:16]) I might find 0b11 because rs1 is 0b00110 (x6).

Are these possible situations?

Thanks.

[Bill Huffman]

Hi Marco,

I'm not sure of your representation, but if, in #1, you mean to have the c.addi instruction coming earlier in the instruction stream than the addi instruction, then addi[15:0] comes earlier in the instruction stream than addi[31:16].  So you'll see

| c.addi[15:0] | addi[15:0] |

instead and then it's clear whether the addi is a 16-bit instruction or a 32-bit instruction.

Regardless of endianness, addi[31:16] is at a higher address than addi[15:0] - to avoid the problem (I think) you're describing.  Section 1.5 of the Unprivileged spec says:

RISC-V base ISAs have either little-endian or big-endian memory systems, with the privileged
architecture further defining bi-endian operation. Instructions are stored in memory as a sequence
of 16-bit little-endian parcels, regardless of memory system endianness. Parcels forming one in-
struction are stored at increasing halfword addresses, with the lowest-addressed parcel holding the
lowest-numbered bits in the instruction specification.

      Bill

On 10/23/20 5:56 AM, Marco Speziali wrote:

EXTERNAL MAIL

--
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 view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/8c5642c0-d0bd-4014-86a9-06cd187a40cdn%40groups.riscv.org.

[Marco Speziali]

I guess I completely missed that part in the documentation.

Now everything is clear, thank you so much Bill.

Best regards,
Marco Speziali