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

RISC-V J extension – Instructions for JITs

github.com

Post reply on HN
Print view View original

31–40 of 56 posts

Re: RISC-V J extension – Instructions for JITs

#31

Post by jasonwatkinspdx »

fredoralive wrote: post #13
userbinator wrote: post #5

I suspect it won't be long before RISC-V becomes not-so-RISC. Even ARM added FJCVTZS.

Successful architectures seem to need a certain degree of pragmatism. ARM isn't exactly the RISCiest RISC, nor is AMD64 as baroque as the outer limits of CISC like iAPX 432. FJCVTZS is an example of pragmatism, the JavaScript spec says float to int should be done the way that x86 does it, the original ARM FCVTZS (no J) didn't do it the same way, but JavaScript is so important you have to add a special case. I hope I'…

So, with RISC-V the design pretty deliberately enables a combination of compressed instructions and macro op fusion.

The compressed instructions are quite lightweight. It's generally an assembly level thing, and the decoder on the cpu side is apparently ~400 gates.

The compressed instructions are indeed a 16 bit wide thing, but fixing some of the flaws in Thumb. Generally they have more implicit operands or operands range over a subset of registers to fit in 16 bits.

But the hat trick is these two dovetail into each other, such that a sequence of compressed instructions can decompress into a fuse-able pair/tuple, which then decodes into a single internal micro op. This creates a way to handle common idioms and special cases without introducing an ever growing number of instructions. Or at least that's the basic claim by the RISC-V folks. I think they've done enough homework on this to not be trivially wrong, so it'll be interesting to see how things go.

Re: RISC-V J extension – Instructions for JITs

#32

Post by blippage »

aidenn0 wrote: post #14
mhh__ wrote: post #9

Earlier quoted context omitted.

That depends whether you mean a human who knows the instructions exist or not or a human who hasn't worked out how to use shifts to do integers mul/div by 2 yet.

The proper argument was always that optimizing compilers generate better assembly than 90% of the people using them could generate, and in a fraction of the time. However these things often get turned into stronger (or different) arguments as they pass from mouth to ear repeatedly. Sometimes they change completely, as in "the plural of anecdote is data"

I wanted to write a memcpy() routine for a microcontroller. I wrote a naive version where I copied from src to dst one byte at a time. You can find algorithms which are more efficient than this, which will typically copy 32 bit words at a time.

The interesting thing is, I turned on compiler optimisations. When I examined the assembled output (even though my knowledge of assembly is poor), I discovered that it had made the optimisations that you would find in a more complex C implementation. The compiler obviously thought to itself "I see what you're doing here", and put in a better version.

So the moral of the story is: your compiler is likely to be able to figure out a lot.

Re: RISC-V J extension – Instructions for JITs

#33

Post by pjmlp »

adgjlsfhk1 wrote: post #29
pjmlp wrote: post #27

Earlier quoted context omitted.

This has been tried plenty of times, ARM just decided something else because reasons. Also to note that all hardware vendors are adopting hardware memory tagging as the only way to fix C. Intel messed up with MPX, but I definitely see they coming with an alternative, as I bet they won't like to be seen as the only vendor left without such capabilities.

I'm honestly not sure why we haven't just admitted C isn't fixable.

Because that requires throwing away UNIX and many people feel quite strongly about it, given that it has won the data center wars.

> C Language. Dialect ISO C. ISO C source programs invoking the services of this Product Standard must be supported by the registered product.

-- http://get.posixcertified.ieee.org/docs/si-2016.html

I should also note that many attempts to add safer types to C have been tried, WG14 just doesn't care about them.

Re: RISC-V J extension – Instructions for JITs

#34

Post by mhh__ »

blippage wrote: post #32
aidenn0 wrote: post #14

Earlier quoted context omitted.

The proper argument was always that optimizing compilers generate better assembly than 90% of the people using them could generate, and in a fraction of the time. However these things often get turned into stronger (or different) arguments as they pass from mouth to ear repeatedly. Sometimes they change completely, as in "the plural of anecdote is data"

I wanted to write a memcpy() routine for a microcontroller. I wrote a naive version where I copied from src to dst one byte at a time. You can find algorithms which are more efficient than this, which will typically copy 32 bit words at a time. The interesting thing is, I turned on compiler optimisations. When I examined the assembled output (even though my knowledge of assembly is poor), I discovered that it had mad…

Even ignoring the usual optimizations like using SIMD and loop unrolling to find parallelism when doing memcpy, the compiler actually has techniques for spotting certain loop idioms so it can actually replace the loop with a memcpy library call if it deems it profitable (e.g. tell it it's likely to have N>bigNumber and it'll go for a library)

Re: RISC-V J extension – Instructions for JITs

#36

Post by olliej »

my123 wrote: post #30
olliej wrote: post #19

Earlier quoted context omitted.

Memory tagging isn't a privilege level thing, it's an anti-compromise mechanism similar to PAC (in the sense the goal is to make it harder for an attacker to compromise code, they are functionally completely different). The basic idea is you often want finer the page level granularity on memory access rights. An example ARM give in the documentation covering the ARM MTE is an allocator. With memory tagging you can ma…

Arm MTE uses a 4-bit tag for each 16 bytes region.

Which would eat a little more than 3% of the physical memory in a device.

Does ARM allow any freedom in tag size, or is it strictly 4 bits?

I realize I may not have been clear for people unfamiliar with MTE* tagging is device level so you can't (for example) put the tags in a separate mapping and just increase your usage of existing memory by 3% (obviously a software implementation could do that, but the perf would probably be suboptimal :D ). You literally need X% more dram cells.

* Not saying @my123 doesn't understand, just I can't edit my original comment and I figure contextually this is reasonable :D

Re: RISC-V J extension – Instructions for JITs

#37

Post by my123 »

olliej wrote: post #36
my123 wrote: post #30

Earlier quoted context omitted.

Arm MTE uses a 4-bit tag for each 16 bytes region.

Which would eat a little more than 3% of the physical memory in a device. Does ARM allow any freedom in tag size, or is it strictly 4 bits? I realize I may not have been clear for people unfamiliar with MTE* tagging is device level so you can't (for example) put the tags in a separate mapping and just increase your usage of existing memory by 3% (obviously a software implementation could do that, but the perf would p…

Strictly 4 bits. For the Morello prototype architecture with full CHERI, it’s 1 bit for each 16 bytes region. (capability valid bit)

Re: RISC-V J extension – Instructions for JITs

#39

Post by brucehoult »

fredoralive wrote: post #13
userbinator wrote: post #5

I suspect it won't be long before RISC-V becomes not-so-RISC. Even ARM added FJCVTZS.

Successful architectures seem to need a certain degree of pragmatism. ARM isn't exactly the RISCiest RISC, nor is AMD64 as baroque as the outer limits of CISC like iAPX 432. FJCVTZS is an example of pragmatism, the JavaScript spec says float to int should be done the way that x86 does it, the original ARM FCVTZS (no J) didn't do it the same way, but JavaScript is so important you have to add a special case. I hope I'…

To defend ARM (what? A RISC-V guy defending ARM?) there is absolutely nothing un-RISC about FJCVTZS. Every instruction set with floating point has some way to convert an FP value to an integer. FJCVTZS is no more complex than the existing FCVTZS -- it simply uses a different rounding mode and different behaviour if the value is too big.

I don't know what you think RISC-V "compressed instruction" means. It's precisely equivalent to ARM Thumb2 -- there are 16 bit opcode and 32 bot opcodes and you can tell which you have by looking at 2 bits (RISC-V) or 3 bits (Thumb2) in the first 16 bits of the instruction.

I don't believe there is any practical "magical" sequence of instructions that could be easily recognised to implement Javascript conversion from float to int. If that is in fact as important as ARM apparently think it is (I have my doubts) then an equivalent of FJCVTZS should be added to RISC-V as an extension.

As for "making the implementation of high performance CPUs complex" … high end CPUs are unavoidably complex. A little bit more is not a big deal. On the other hand, adding complexity to low end CPUs can easily be a complete deal-killer. Splitting an instruction into µops might be a little simpler than combining instructions into macro-ops, but it's not as simple as not having to do it.

Ironically, the people who criticise RISC-V for talking about macro-op fusion seem to be ignorant of the fact that no currently shipping RISC-V SoC does macro-op fusion [1], while every current higher end ARM and X86 does do macro-op fusion of compare (and maybe other ALU) instructions with a following conditional branch instruction.

[1] SiFive U74 can tie together a forward conditional branch over a single integer ALU instruction with that following instruction. They pass down the two execution pipes in parallel (occupying both i.e. they are still two instructions, not a macro-op). The ALU instruction executes regardless, but the conditional branch controls whether the result is written back. i.e. it effectively converts a branch into predication

Re: RISC-V J extension – Instructions for JITs

#40

Post by saagarjha »

my123 wrote: post #37
olliej wrote: post #36

Earlier quoted context omitted.

Which would eat a little more than 3% of the physical memory in a device. Does ARM allow any freedom in tag size, or is it strictly 4 bits? I realize I may not have been clear for people unfamiliar with MTE* tagging is device level so you can't (for example) put the tags in a separate mapping and just increase your usage of existing memory by 3% (obviously a software implementation could do that, but the perf would p…

Strictly 4 bits. For the Morello prototype architecture with full CHERI, it’s 1 bit for each 16 bytes region. (capability valid bit)

Of course, CHERI faces very different challenges than MTE does ;)
Post reply on HN