5 ms·
Maybe overflow checking could included as an ISA extension. If it is included, what is the least impactful design? Overflow is part of the result, so maybe in
by jhallenworld 6y ago
Maybe overflow checking could included as an ISA extension. If it is included, what is the least impactful design?
Overflow is part of the result, so maybe include extra bits to each register that can be arithmetic destination. These bits are not included in moves, but could be tested with new instructions.
Another way that avoids flags is new arithmetic instructions: add but jump on overflow. Maybe this is reduced to add and skip next instruction except for overflow, but maybe things are simplified if the only allowed next instruction is a jump, so the result is a single longer instruction.
- pizlonator 6y agoThe best design is control bits which RISC-V doesn’t have but x86 and ARM do have. The best design is part of the core ISA and not and extension since overflow checking is fundamental to modern languages.
- rwmj 6y agoYou need to either write a paper about this or produce some evidence.
- pizlonator 6y agoI don’t need to do anything. You’re welcome not to take my advice. :-) If you doubt that dynamic languages are using overflow checking in the way that I describe then it’s not because of lack of papers on the subject.
- wbl 6y agoControl bits as in ARM and x86 force serialization of arithmetic due to the RW dependency in every instruction on that bit. There are some tricks but it still needs tracking. For higher order superscalar or out of order processors this gets annoying.
- pizlonator 6y agoI think what you’re saying is basically true but it’s a trade against density. If you did overflow checks rarely then what you say is a very good point indeed. The key thing is just the frequency of this stuff in modern languages.
- deleted 6y ago[deleted]
- tom_mellior 6y agoARM has separate instruction variants with and without setting of flags. Normally one uses the flag-less versions, so you don't have this problem.
- CalChris 6y agoNo. Control bits (status bits, flags, ...) get renamed just as registers get renamed. Basically, if there's a bottleneck to x86 code, Intel has run into it, profiled for it and generally optimized around it both in their microarchitectures and in the their C compiler.
- wbl 6y agoThat's one of the tricks. But it doesn't solve the issue of clobbers, which Intel had to introduce new variants of ADD and MUL to solve. Named predicate registers make it all much easier for everyone.
- CalChris 6y agoAgreed. Waterman's thesis says this about that: "Several ISA features, including implicit condition codes and predicated moves, are onerous to implement in aggressive microarchitectures. Yet, their complexity often does not result in higher performance because their semantics were ill-conceived. For example, x86 provides a conditional load instruction, but, if the unconditional load were to cause an exception, it is implementation-defined whether the conditional version would do so. Thus, a compiler can only rarely use this instruction to perform the if-conversion optimization. Recognizing the inefficiency of their conditional operations, Intel’s recent implementations go to some lengths to fuse comparison instructions and branch instructions into internal compare-and-branch operations." Yeah, doing condition codes right is complicated but then that's the purpose of microarchitecture, to factor that complexity out. RISC-V succeeds in having a minimalist to a fault design which is appropriate for a certain design point. ARMv8 and x86_64 are more useful for a broader set of designs. The burden now is on RISC-V to show that their minimalist approach is fast+efficient rather than just simple. You have to get something out of the simplicity; otherwise what you get is design debt.
- jhallenworld 6y agoAfter thinking about this some more: I think the extension instruction should work like "slt" (set on less than). So we have "sov"- set if add would overflow: add t2, t1, t0 sov t3, t1, t0 bnez t3, overflow Why this way? "extra bits on destination registers"- this is really flags. The flags have to be preserved during interrupts, so extending the registers is not so easy (I think it just reduces to classic flags). "add but jump on overflow" or "add and skip on no overflow"- I don't like this because you can not break it into separate operations without flags. I think you might have to add hidden flags in a real implementation. An add followed by an sov could be fused, but requires an expensive multi-register write. Fusing maybe could be more likely if the destination is always to a fixed destination register: add t2, t1, t0 sov tflags, t1, t0 bnez tflags, overflow
- bshanks 6y agoIf the destination of sov is specified to always be tflags, then you may as well combine add and sov into one instruction, with tflags implicit: addsov t2, t1, t0