The PC counter in RISCV

2,376 views
Skip to first unread message

Dalas Yoo

unread,
Jul 30, 2018, 11:06:05 PM7/30/18
to RISC-V ISA Dev
Hello, I am SOC developer, and now writing RISC-V assembly codes by myself.
One of the question I got in my mind is that how could RISC-V hardware architecture would know how much PC counter to increment based on RISC-V ISA.
When looking through all RISC-V instruction dump logs, there are some 16 bit instruction while most are 32bit instruction.
One of the thing I have in mind is that most Processors increment their PC by 4, which means they could not read 16 bit instruction properly.
So the hardware architecture should know how much to increment PC value based on RISC-V Instructions.
Is this assumption right to think or am i missing something behind?

Christopher Celio

unread,
Jul 31, 2018, 1:28:41 AM7/31/18
to Dalas Yoo, RISC-V ISA Dev
The CPU has to fetch the instruction at Address X; decode the instruction; figure out if it is a 2 byte instruction or a 4 byte instruction, and only then can it increment the PC by 2 or 4 so it can fetch the next instruction at X+2 or X+4.

And yes, this sets up a serial dependency such that you can't know where instruction I+1 is without first knowing what instruction I is, which makes trying to fetch multiple instructions every cycle FUN.

-Chris

--
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/a5dcc49d-c275-42a4-987c-1e7cff18fc76%40groups.riscv.org.

Michael Clark

unread,
Jul 31, 2018, 8:29:55 AM7/31/18
to Dalas Yoo, RISC-V ISA Dev
These questions are not appropriate for the ISA Dev mailing list. This mailing list is intended for discussions related to development of the RISC-V ISA with the presumption you have read past the first few pages.

I think you need to read the RISC-V Instruction Set Manual more closely, noting the table with the instruction length encoding rules for variable length RISC-V instructions.

The PC is incremented by length(instruction).

On a processor that supports RVC compressed instructions, the instructions are fetched in 16-bit packets and the 2 least significant bits indicate the first part of an extensible length prefix. If the least significant bits of the packet are 0b00, 0b01 or 0b10 and your processor supports RVC compressed instructions then the instruction is a 16-bit RVC instruction and the PC is incremented by 2 (unless of course it is a branch instruction).

If the least significant bits are 0b11, then the instruction is 32-bits (unless the prefix is 011111 which indicates 48-bit, or one of several other prefixes which indicate other instruction lengths, if supported).

At present if you have an RV32GC or RV64GC processor, then 0b11 in the two least significant bits indicates a 32-bit instruction whereby the PC is incremented by 4.

Please read the RISC-V Instruction Set Manual...

Michael Clark

unread,
Jul 31, 2018, 8:45:33 AM7/31/18
to Christopher Celio, Dalas Yoo, RISC-V ISA Dev


> On 31/07/2018, at 5:28 PM, Christopher Celio <ce...@berkeley.edu> wrote:
>
> The CPU has to fetch the instruction at Address X; decode the instruction; figure out if it is a 2 byte instruction or a 4 byte instruction, and only then can it increment the PC by 2 or 4 so it can fetch the next instruction at X+2 or X+4.
>
> And yes, this sets up a serial dependency such that you can't know where instruction I+1 is without first knowing what instruction I is, which makes trying to fetch multiple instructions every cycle FUN.

Indeed. You make it sound complex. I guess doing it without too many gate delays is the hard part.

How many combinations of 4 instruction lengths with 2 or 4 byte lengths in a 16 byte fetch window. 2 x 2 x 2 x 2 = 16

Much easier than x86 ;-) where one has to start a parse at every byte offset and one doesn’t know the length until one has unpacked multiple prefix bytes, up to a possible length of 15 bytes.

Do you do it with two pipe stages? A length predecoder that lights up 4 of the 7 decoders in the next stage? (Its impossible to parse at offset 14).

Cesar Eduardo Barros

unread,
Jul 31, 2018, 7:47:01 PM7/31/18
to Dalas Yoo, RISC-V ISA Dev
Many processor instruction sets are variable-length, including the
popular Intel x86 and the AMD x86-64 architectures, as well as ARM's
Thumb-2 and others. In all these cases, the PC is incremented by the
size of the instruction; always incrementing the PC by 4 is a natural
consequence when every instruction is 4 bytes.

The PC is incremented after reading the instruction, not before. After
the instruction is decoded, its size is known. Obtaining the instruction
size can be hard (as in x86, in which each byte might say there are more
bytes to read) or easy (which is the case in RISC-V, where the first
16-bit parcel of the instruction has bits specifying the size in a fixed
location).

The details for RISC-V are in the Introduction chapter of the RISC-V
Instruction Set Manual. If you haven't read it yet, I suggest doing so
first (at least the Introduction and the Base Integer Instruction Set
chapters), instead of trying to learn by reverse-engineering instruction
dumps.

--
Cesar Eduardo Barros
ces...@cesarb.eti.br

Dalas Yoo

unread,
Aug 1, 2018, 3:22:44 AM8/1/18
to RISC-V ISA Dev, Dala...@gmail.com
Thanks, I didn't know the traits of this groups. I am sorry on that.
And I understand well with your post. Thanks~
Reply all
Reply to author
Forward
0 new messages