3 ms·
> re-adding trapping arithmetic As a former JavaScript VM hacker, I think what I want the most is a conditional call instruction (like on arm32). The condition
by titzer 5y ago
> re-adding trapping arithmetic
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!
- jez 5y agoI 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.
- kaba0 5y agoI’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.
- titzer 5y agoFlags 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.
- dzaima 5y agosuch 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.
- flohofwoe 5y agoThe Intel 8080 and Z80 had conditional call instructions. Don't know why x86 didn't deem them important enough to drag them along though.
- hyperman1 5y agox86 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.
- zozbot234 5y agoHow 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.
- titzer 5y agoThe default prediction for unseen branches is not taken, so the processor would default to speculatively falling through and off into the call.
- zozbot234 5y ago"Default" (static) prediction matters very little in modern processors though. Branch prediction is largely based on dynamic data about the actual program run.
- titzer 5y agoThey 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.
- zozbot234 5y agoThe fact that modern CPU architectures in general have abandoned custom prediction hints suggests that static branch prediction is being viewed as less important.
- titzer 5y agoSure, but default "predict not-taken" is a very decent zero-cost heuristic that hardware will probably keep using for the foreseeable future.