Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: kegs@provalid.com (Kent Dickey) Newsgroups: comp.arch Subject: Re: is Vax addressing sane today Date: Mon, 23 Sep 2024 21:57:08 -0000 (UTC) Organization: provalid.com Lines: 148 Message-ID: References: <2024Sep10.094353@mips.complang.tuwien.ac.at> Injection-Date: Mon, 23 Sep 2024 23:57:09 +0200 (CEST) Injection-Info: dont-email.me; posting-host="324f23bbc242b230d3abab4bcad73d8f"; logging-data="3017130"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/tHDmkUwJE/UU9uS8k1NPN" Cancel-Lock: sha1:gBSAQDTLsS6Ff9W7Y1koGPoJARk= Originator: kegs@provalid.com (Kent Dickey) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Bytes: 7208 In article , EricP wrote: >Kent Dickey wrote: >> In article <2024Sep10.094353@mips.complang.tuwien.ac.at>, >> Anton Ertl wrote: >>> Brett writes: >>>> Speaking of complex things, have you looked at Swift output, as it checks >>>> all operations for overflow? >>>> >>>> You could add an exception type for that, saving huge numbers of correctly >>>> predicted branch instructions. >>>> >>>> The future of programming languages is type safe with checks, you need to >>>> get on that bandwagon early. >>> MIPS got on that bandwagon early. It has, e.g., add (which traps on >>> signed overflow) in addition to addu (which performs modulo >>> arithmetic). It has been abandoned and replaced by RISC-V several >>> years ago. >>> >>> Alpha got on that bandwagon early. It's a descendent of MIPS, but it >>> renamed add into addv, and addu into add. It has been canceled around >>> the year 2000. >> >> [ More details about architectures without trapping overflow instructions ] >> >> Trapping on overflow is basically useless other than as a debug aid, >> which clearly nobody values. If you take Rust's approach, and only >> detect overflow in debug builds, then you already don't care about >> performance. > >Those automatic software correctness checks, of which signed integer >overflow detection is one of many, went away because most code was >being written in C/C++ and those two languages don't require them. > >That just makes it more expensive in code size and performance to effect >such checks. This overhead leads some to conclude it justifies eliminating >the error checks. > >Eliminating the error event detectors doesn't make errors go away, >just your knowledge of them. > >I gather portions of 16-bit Windows 3.1 were written in Pascal. >When Microsoft developed 32-bit WinNT, if instead of C it they had >switched their official development language from Pascal to Modula-2 >which does require signed and unsigned, checked and modulo arithmetic, >and array bounds checks, the world would have been a much safer place. > >But they didn't so it isn't. > >The x86 designers might then have had an incentive to make all the >checks as efficient as possible, and rather than eliminate them, >they might have enhanced and more tightly integrated them. OK, my post was about how having a hardware trap-on-overflow instruction (or a mode for existing ALU instructions) is useless for anything OTHER than as a debug aid where you crash the problem on overflow (you can have a general exception handler to shut down gracefully, but "patching things up and continuing" doesn't work). I gave details of reasons folks might want to try to use trap-on-overflow instructions, and show how the other cases don't make sense. In no way was I ever arguing that checking for overflow was a bad idea, or a language issue, or anything else. Just that CPUs should not bother having trap-on-overflow instructions. You then went on to discuss how you want trap-on-overflow instructions for stuff like C code, so you can detect code bugs and shut down gracefully. And my response to that is we already know compilers don't use it. x86 has INTO, which is "trap if the overflow bit is set". So "ADD r8,r9; INTO" would trap if the add overflowed. Look at: https://godbolt.org/z/oMhW55YsK Which is this code: int add2(int num, int other) { return num + other; } Compiled with these options: -O2 -ftrapv (-ftrapv is the GCC argument for detect signed overflows and crash). For x86-64 clang 19.1.0: add2: add edi, esi jo .LBB0_1 mov eax, edi ret ..LBB0_1: ud1 eax, dword ptr [eax] This looks OK: it does a normal add, then branches-on-overflow to an undefined instruction. But x86 has an instruction to trap on overflow directly: INTO. It's one byte. And it doesn't use it. GCC x86-64 14.2 is even worse: add2: sub rsp, 8 call __addvsi3 add rsp, 8 ret It calls a routine to do all additions which might overflow, and that routine calls assert() if an overflow occurs. The CPU has a trap-on-overflow instruction exactly for this case (to crash on detecting an overflow), and compilers don't even use it. So even on architectures which have a trap-on-overflow instruction, compilers don't use it. So why should any hardware include an instruction to trap-on-overflow? Trap-on-overflow instruction have a hardware cost, of varying severity. If the ISA isn't already trapping on ALU instructions (such as divide-by-0), it adds a new class of operations which can take exceptions. An ALU functional unit that cannot take exceptions doesn't have to save "unwinding" info (at minimum, info to recover the PC, and possibly rollback state), and not needing this can be a nice simplification. Branches and LD/ST always needs this info, but not needing it on ALU ops can be a nice simplification of logic, and makes it easier to have multiple ALU functional units. Note that x86 INTO can be treated as a branch, so it doesn't have the cost of an instruction like "ADDTO r1,r2,r3" which is a normal ADD but where the ADD itself traps if it overflows. ADDTO is particularly what I am arguing against-- it is just a bad idea for the ISA to have ALU instructions take exceptions. >> Instruction sets which make detecting overflow difficult (say, RISC-V), >> would do well to make branch-on-overflow efficient and easy. But adding >> trap-on-overflow instructions is a waste of effort. > >No they are a very useful tool for those who need such a tool >because the manual alternative is significantly more expensive >for both size and performance. > >"I have one example where overflow exceptions would be a poor implementation >choice" does not imply "therefore no one should have them as an option". Can you share what language, compiler, and hardware you are using which implements overflow checks using a trap-on-overflow instruction? Kent