Re:Rust's unsafe pointer types need an overhaul
by jez on Sunday March 20, 2022 @02:27AM
(#30740598)
I imagine this isn’t the first time you’ve realized you wanted this so I’m curious: what’s stopping this today? CPU designers being lethargic? Technical complexity? Something else?
It seems like the kind of feature that competition among CPU manufacturers would drive towards an implementation out of a desire to claim faster performance on a workload that people care about.
Re:Rust's unsafe pointer types need an overhaul
by kaba0 on Sunday March 20, 2022 @04:13AM
(#30741008)
I’m way out of my depth here, but as far as I know flags have a non-trivial interaction with superscalar execution.
Not sure how accurate it is, but I can imagine it being similar to parallelizing a program with independent units of works vs trying to do the same for threads that depend on each other’s output.
Re:Rust's unsafe pointer types need an overhaul
by titzer on Sunday March 20, 2022 @12:12PM
(#30743887)
Flags are treated as just another kind of dependency in the register renaming phase, though it's a lot hairier because they probably need to be tracked on an individual (per-bit) basis.
As a sibling commenter noted, a conditional call is basically just a macro for a (negated) conditional branch jump over a call instruction, but with a different prediction.
Re:Rust's unsafe pointer types need an overhaul
by dzaima on Sunday March 20, 2022 @10:27AM
(#30742876)
such VMs would be near the only thing to benefit from them, and, still, only in code size (which wouldn't be in cache anyway) and codegen speed, i.e. not anything related to actual runtime speed.
You can't use them for actually conditionally calling functions because functions need arguments, thrash registers, and whatever else functions do.
Re:Rust's unsafe pointer types need an overhaul
by zozbot234 on Sunday March 20, 2022 @10:49AM
(#30743057)
How would "conditional call" differ from the obvious pattern of forward branching on the negative of the original condition to skip over a call instruction? The pattern could easily be macro-fused in hardware if deemed worthwhile.
Re:Rust's unsafe pointer types need an overhaul
by titzer on Sunday March 20, 2022 @12:09PM
(#30743854)
The default prediction for unseen branches is not taken, so the processor would default to speculatively falling through and off into the call.
Re:Rust's unsafe pointer types need an overhaul
by zozbot234 on Sunday March 20, 2022 @12:19PM
(#30743965)
"Default" (static) prediction matters very little in modern processors though. Branch prediction is largely based on dynamic data about the actual program run.
Re:Rust's unsafe pointer types need an overhaul
by titzer on Sunday March 20, 2022 @12:24PM
(#30744017)
They still do matter because programs are huge, with lots of cold and warm (not hot) code, and there are only so many branch prediction entries. Compilers have been tuned for several decades with this assumption in mind and processors, in turn, keep reinforcing it, because they keep running code produced by such compilers. It'll take some very extensive measurements to show that it is no longer the case.
Re:Rust's unsafe pointer types need an overhaul
by zozbot234 on Sunday March 20, 2022 @12:55PM
(#30744314)
The fact that modern CPU architectures in general have abandoned custom prediction hints suggests that static branch prediction is being viewed as less important.
Re:Rust's unsafe pointer types need an overhaul
by titzer on Sunday March 20, 2022 @06:23PM
(#30747326)
Sure, but default "predict not-taken" is a very decent zero-cost heuristic that hardware will probably keep using for the foreseeable future.
Re:Rust's unsafe pointer types need an overhaul
by flohofwoe on Sunday March 20, 2022 @06:53AM
(#30741630)
The Intel 8080 and Z80 had conditional call instructions. Don't know why x86 didn't deem them important enough to drag them along though.
Re:Rust's unsafe pointer types need an overhaul
by hyperman1 on Sunday March 20, 2022 @12:14PM
(#30743910)
x86 had INTO, interrupt when overflow, which basically gave this functionality. It would allow software to treat an overflow basically like a segmentation violation.
It never saw much use, and got removed in x64.
As a former JavaScript VM hacker, I think what I want the most is a conditional call instruction (like on arm32). The conditional flags are already computed for arithmetic, and there are already conditional jumps. JS VMs use them to check for overflow out of the small integer range (31 bits, but shifted one left, so a 32-bit arith op generates the right flags) followed by a branch to out-of-line code. That out-of-line code has to be duplicated for every different check site, since a branch doesn't keep track of where it came from. But a conditional call instruction would, either pushing the return address or putting it in a register. This allows a single, shared routine. You can then use this for all kinds of things....inline bump-pointer allocation with an automatic bailout to a slowpath, safety checks of all kinds, profiling, deoptimization, you name it.
What I wouldn't give for a conditional call instruction!