Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Book: RISC-V System-on-Chip Design

amazon.com

Post reply on HN
Print view View original

51–60 of 80 posts

Re: Book: RISC-V System-on-Chip Design

#51

Post by Joker_vD »

camel-cdr wrote: post #37
Joker_vD wrote: post #17

Earlier quoted context omitted.

> RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it. ...no, not really? There is nothing like 9 byte-long MOVABS instruction of x64 that exists on RISC-V. The main difficulty in decoding is that 32-bit instructions are not required to be 4-byte aligned, this means that naïve decoders will spend 2 cycles fetching such split instructions. It's possible to a…

There are two options when designing an ISA to achieve competitive code size, add variable length instructions or add more complex fixed-length instructions which require cracking (2W instructions). The other option is: maybe codesize don't matter? For high performance implementations both decoding variable length instructions and decoding/cracking fixed-length instructions into uops, are rather analogous in terms of…

> maybe codesize don't matter?

Well, instruction cache still has limited size, and you still need to get your code into it. Paging in 512 KiB from the disk is faster than paging in 1 MiB from the disk.

> like pre-decoding in Icache.

I'm fairly certain x64 also does that?

> RVC is self synchronizing,

No, not really. You can still jump into the middle a 32-bit instruction, and it's possible it can be reinterpreted as a valid 32/16-bit instruction. Remember when people complained about how "overlapped instructions"/"hidden instruction streams" on x64 enable even more ROPs/gadgets than meets the eye? Don't worry, RISC-V has those too!

Re: Book: RISC-V System-on-Chip Design

#52

Post by inkyoto »

Taniwha wrote: post #44
timhh wrote: post #36

Earlier quoted context omitted.

Of course you can make compressed work. E.g. you fetch 66 bytes instead of 64. Hell, Intel/AMD manage to make x86 fairly fast. But it's definitely more awkward and has costs throughout the CPU. I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned. Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra…

You don't really fetch 66 bytes instead of 64, what real implementations do is read cache lines (of whatever size) and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line (the ISA has the 16/32-bit tag in the lower byte so you know how big an instruction will be even if you've only seen half of it)

> […] and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line […]

Well, and that is the worst case scenario from the performance standpoint since, if a 32-bit instruction is spans a page boundary, it will result in a page fault stalling the instruction decoder.

It might be acceptable in implementations not sensitive to such an overhead (e.g. embedded solutions) but is wholly unacceptable in high performance scenarios.

Re: Book: RISC-V System-on-Chip Design

#53

Post by sph »

gertop wrote: post #35
xlmnxp wrote: post #3

Earlier quoted context omitted.

I just pre-ordered this book and think it's definitely worth it. Full disclosure: I have no affiliation with the author, but I'm sharing because I genuinely believe in the work.

Why do you say it's worth it before you've even read it, let alone seen it?

It’s worth (for me paying that amount of money for) it.

We all do this kind of value judgement before paying for a product we haven’t yet evaluated.

Re: Book: RISC-V System-on-Chip Design

#55

Post by rramadass »

oumua_don17 wrote: post #49
rramadass wrote: post #21

What are some good books/resources on overall System-On-Chip Design? There is a surprising paucity of material on SoC design which are comprehensive and complete. Application-specific tailored features, Cost, Performance, Area, Power etc. all go into SoC design and yet there does not seem to be a comprehensive resource bringing everything together. Even wikipedia isn't detailed enough - https://en.wikipedia.org/wiki/…

There's also Modern System-on-Chip Design on Arm textbook by David J. Greaves and it's available as a free download [1]. [1] https://www.arm.com/resources/education/books/modern-soc

Nice; thanks for the pointer.

Searched Amazon for other books on SoC design and found a series of books by Dr. Veena S. Chakravarthi which seem quite comprehensive - https://www.amazon.com/s?k=Veena+S.+Chakravarthi&i=stripbook...

Re: Book: RISC-V System-on-Chip Design

#56

Post by brucehoult »

inkyoto wrote: post #52
Taniwha wrote: post #44

Earlier quoted context omitted.

You don't really fetch 66 bytes instead of 64, what real implementations do is read cache lines (of whatever size) and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line (the ISA has the 16/32-bit tag in the lower byte so you know how big an instruction will be even if you've only seen half of it)

> […] and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line […] Well, and that is the worst case scenario from the performance standpoint since, if a 32-bit instruction is spans a page boundary, it will result in a page fault stalling the instruction decoder. It might be acceptable in implementations not sensitive to such an overhead (e.g. embe…

x86 seems to get by.

And how is an instruction spanning a page boundary and causing a page fault any worse than an instruction NOT spanning a page boundary and the next instruction causing the page fault instead?

As Paul said, if a 4 byte instruction spans a cache line/page boundary then you just hang on to the last 2 bytes of the page (first 2 bytes of that instruction) and decode them along with the instructions in that next cache line / page.

The only time it could possibly make a difference is if that spanning instruction is a jump to somewhere else AND that instruction could somehow have fit entirely in the previous page.

If there was no C extension then that next instruction would NOT be entirely in the previous page, it would be somewhere well into the next page, and that next page would have been required to be fetched much sooner. The C extension typically allows 30% to 50% more functionality to fit in each VM page.

Also, Qualcomm's proposed new instructions did not in fact use the freed-up space from not having C. They fit into other unused parts of the ISA.

I don't object to the new instructions Qualcomm suggested. I'd be perfectly happy to see them ratified and added to a future standard (even to RVA23 if they'd chosen to pursue that, but they didn't).

What I and others objected to was dropping the C extension from RVA23, or any future RVA-series, overnight given that RVA20 and RVA22 already existed with the C extension.

There will come a time when some RISC-V extensions will be retired and replaced, and it's entirely possible that C might be one of them, but there is currently no mechanism to do that, and when there is I'd expect that it would be done with a 10 or 12 year deprecation period, minimum.

NEVER overnight between one standard and the next one.

Which wouldn't have helped Qualcomm with their Nuvia core anyway.

Anyway, Qualcomm had now bought Ventana, which has engineers who know how to support the C extension with high performance, and they already had high performance RISC-V cores doing so.

So problem solved.

Re: Book: RISC-V System-on-Chip Design

#57

Post by brucehoult »

Joker_vD wrote: post #24
rwmj wrote: post #19

Earlier quoted context omitted.

RISC-V definitely does support instructions longer than 32 bits, starting at 48 bits (ie. 32 + 16), and going much longer. They are much easier to decode than x86 because the length is evident from the first byte. No ratified extension uses them now, but you're going to need to deal with them as the extension space gets more crowded. Including dealing with instructions split across cache lines and pages, and instruct…

My point is that fixed-length instructions are supposed to be easier to decode than variable-length ones, right? If not, then why even bother with fitting immediates and inventing LUI/AUIPC, just have a 48-bit long LI instruction. The same goes for 64-bit, an 80-bit LI.W is still shorter than the piecemeal construction with several instructions. If yes, then the small cores are arbitrarily given a burden of supportin…

> small cores are arbitrarily given a burden of supporting variable-length instructions

Even the smallest commercial microcontroller cores e.g. the CH32V003, support the C extension. They strip out other things, such as half the integer registers, but they keep C.

And that's in a market where you can use literally any combination of extensions you want, because the customers compile all their own code, and you just tell them what ISA string to use.

Re: Book: RISC-V System-on-Chip Design

#58

Post by brucehoult »

dmitrygr wrote: post #50
camel-cdr wrote: post #48

Earlier quoted context omitted.

You can see the encoding limitation it in the design on SVE, which only has destructive operations, but MOVPRFX, which is a round about way of doing 64-bit instructions, without doing 64-bit instructions.

When the top perf per watt or perf per MHz machine is RISCV, we'll talk. Until then, lol.

Self-evidently, you therefore won't be the person building this machine.

Re: Book: RISC-V System-on-Chip Design

#59

Post by brucehoult »

sylware wrote: post #43
rwmj wrote: post #41

Earlier quoted context omitted.

Aarch64 dropped thumb instructions. I don't think you're going to find a single benchmark on the effectiveness of compressed instructions since it really depends deeply on both the workload and the whole system. For example, memory bandwidth and cache pressure are both important for whether smaller text sizes matter, and that may depend on what else is running at the same time. Note your assembler may be automaticall…

Maybe the best approach is to remove C from RVA while keeping it around in the specs for niche applications where text size _really_ matters (with current silicon processes, I wonder how weird those niche applications have to be to require C). But it seems some would remove C even from the specs to free some ISA space. If arm removed thumb... Don't worry, I would know if the assembler is producing C machine instructi…

You can't remove C from future RVA because a large part of the value of RVA is that each version can run all the shrink-wrapped (binary distribution) code built for the previous versions.

Re: Book: RISC-V System-on-Chip Design

#60

Post by sylware »

brucehoult wrote: post #59
sylware wrote: post #43

Earlier quoted context omitted.

Maybe the best approach is to remove C from RVA while keeping it around in the specs for niche applications where text size _really_ matters (with current silicon processes, I wonder how weird those niche applications have to be to require C). But it seems some would remove C even from the specs to free some ISA space. If arm removed thumb... Don't worry, I would know if the assembler is producing C machine instructi…

You can't remove C from future RVA because a large part of the value of RVA is that each version can run all the shrink-wrapped (binary distribution) code built for the previous versions.

Well, I said that because based on the documents provided here, it seems there are key people considering its removal even from the specs.

From my point of view, just do like all the others: clearly deprecate it, namely say that "from RVAx, don't create new machine code with the C extension". It is like in the linux kernel, it will then be removed very far in the future. But RISC-V is all about the far future, it can only be better to fix it asap.

After reading the comments and documents provided here, I am the first to be suprised by how much doing 'performant C' is not that easy and has a significant hardware cost. "arm removing thumb" should have been a strong signal.

Again, I am coding rv64 assembly almost every day, a good part could be C-ized to shrink text size, but based on various numbers provided here, why bother, better keep the 'R' of RISC as faithfull to its goal than anything else.

Post reply on HN