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

21–30 of 56 posts

Re: RISC-V J extension – Instructions for JITs

#21

Post by samus »

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"

> "the plural of anecdote is data"

I love that line!

Re: RISC-V J extension – Instructions for JITs

#22

Post by KerrAvon »

mhh__ wrote: post #9
KerrAvon wrote: post #6

Earlier quoted context omitted.

I heard someone use those instructions once as examples of something compilers could do better than humans writing assembly -- Apple's MPW C compilers for PowerPC were capable of peephole optimizations that would produce them where a human might not think of them. (At least, that was the argument.)

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.

I didn’t say it was a good argument.

Re: RISC-V J extension – Instructions for JITs

#23

Post by eyelidlessness »

KerrAvon wrote: post #22
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.

I didn’t say it was a good argument.

Me, every day, even discussing my own points.

Re: RISC-V J extension – Instructions for JITs

#24

Post by Taniwha »

sdbbp wrote: post #11
Taniwha wrote: post #4

It's worth noting that on systems with real cache coherency (MOESI for example) where for example writing data into the dcache to an address A results in cache line shootdown in the icache as part of fetching an 'exclusive/modified' line into the dcache - in this world EXPORT.I is essentially a no-op because what it requires the icache implement (shootdown of icache lines) has already happened naturally. Equally on s…

This organization of functionality is intentional. It provides support for code modification orthogonal to instruction cache coherency support. The range of types of implementations of RISC-V is broad enough that imposing instruction cache coherency on all of them wouldn't be optimal. The I/D consistency proposal provides SW control now, while not requiring particular implementations. Particular RISC-V Platform specs…

Right, I think it's OK as written, I'm just encouraging people to make general specs rather than ones with special cases that are important for one end but slow everything else down

Re: RISC-V J extension – Instructions for JITs

#25

Post by rwmj »

aidenn0 wrote: post #3

For tagged values, I loved the POWER rlwinm: Rotate Left Word Immediate aNd with Mask (and it's companion rlimi). Pretty much any sane tagging scheme could be converted to the unboxed value with that single instruction; even somewhat exotic tagging schemes like mixing high-bit and low-bit tagging could be handled by it. Of course in modern architectures being able to do something in one instruction is only tenuously…

Most tagged arithmetic can be converted to one or two regular instructions. For OCaml which tags the bottom bit I wrote about it here: https://web.archive.org/web/20090810001400/https://caml.inri... and here (scroll down to bottom): https://rwmj.wordpress.com/2009/08/04/ocaml-internals/

Re: RISC-V J extension – Instructions for JITs

#26

Post by Dylan16807 »

userbinator wrote: post #20
fredoralive wrote: post #13

Earlier quoted context omitted.

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'…

that there should be some standard set of instructions that compilers should emit for that special case, and the instruction decoder on high end CPUs should be magic enough to detect the sequence and do optimal things (fused instructions?) Detecting a long fixed sequence of instructions and "compressing" them into one internal operation seems like it would require a lot of fetch bandwidth and/or a really wide decoder…

Those downsides would be real, depending on how awkward the set of instructions is, but on the plus side risc-v should be able to handle a lot more instructions per cycle in a given power/area budget.

Re: RISC-V J extension – Instructions for JITs

#27

Post by pjmlp »

Decabytes wrote: post #10

Wasn’t this tried with Jazelle and Java? I wonder how they will overcome the shortcomings of that attempt

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.

Re: RISC-V J extension – Instructions for JITs

#28

Post by pjmlp »

snek_case wrote: post #16

There's a document in there about pointer masking: https://github.com/riscv/riscv-j-extension/blob/master/point... It seems like the objective of this is to implement different access privileges... but why do you need specialized instructions for this? This is typically done by the OS and memory protection. The pointer masking extension would be to have multiple levels of privilege within a single process? I'm assumi…

Fixing C, hardware memory tagging is the ultimate mitigation strategy for pointer tricks.

Already being successfully used for decades in Solaris SPARC, iOS/macOS and Android are increasingly pushing for it on ARM CPUs, Pluton on Azure Sphere OS,...

Re: RISC-V J extension – Instructions for JITs

#29

Post by adgjlsfhk1 »

pjmlp wrote: post #27
Decabytes wrote: post #10

Wasn’t this tried with Jazelle and Java? I wonder how they will overcome the shortcomings of that attempt

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.

Re: RISC-V J extension – Instructions for JITs

#30

Post by my123 »

olliej wrote: post #19
snek_case wrote: post #16

There's a document in there about pointer masking: https://github.com/riscv/riscv-j-extension/blob/master/point... It seems like the objective of this is to implement different access privileges... but why do you need specialized instructions for this? This is typically done by the OS and memory protection. The pointer masking extension would be to have multiple levels of privilege within a single process? I'm assumi…

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.
Post reply on HN