5 ms·

We know the origins of that myth by examining the papers that the RISC-V designers wrote. They got a C compiler back-end working and didn't incorporate any oth

We know the origins of that myth by examining the papers that the RISC-V designers wrote. They got a C compiler back-end working and didn't incorporate any other languages in their benchmarking corpus.

pizlonator 6y ago
That’s my suspicion too! I don’t think these folks have seen what modern languages do.
convolvatron 6y ago
C really did screw things up by just refusing to address overflow in any form, didn't it
- brandmeyer 6y ago
  I don't think C screwed up. C's objective was to standardize a set of practices based on what the hardware of the day was capable of. If they had pessimized performance on one architecture because it failed to provide efficient checked overflow (or any other feature), then C would have never made it to standardization. ISO C is therefore a three-way compromise between three communities: Software authors, compiler authors, and CPU manufacturers. You will naturally end up with some decisions that dissatisfy some members of each.
  - Gibbon1 6y ago
    Better would be to say that the C standard committee screwed things up by refusing to address a lot of issues over the last 35 years.
    - saagarjha 6y ago
      Not really, they have addresses pretty much all of the issues. Now, you can argue that they favored compiler authors when doing so, but they have consider the problems and done things in response to them.
- pizlonator 6y ago
  Yes. In many ways: 1) it’s pretty important to have easy syntax for math with overflow checks. Otherwise there will be bugs. Bad bugs. We have those and it sucks. 2) it’s pretty important that if the overflow wraps in ISA then it wraps in language semantics but C just says “meh whatever” for signed overflow. That leads to even more bugs.
  - GeorgeTirebiter 6y ago
    The HP3000 had "SPL" - Systems Programming Language -- as its way of doing what C does. It had a specific syntax for checking the error codes: if <> then <whatever> so whatever previous arithmetic did, you could check the machine's flags directly. Can't do that in C. https://en.wikipedia.org/wiki/Systems_Programming_Language https://en.wikipedia.org/wiki/Systems_Programming_Language
  - the5avage 6y ago
    At the time C was designed not all machines did represent signed integers in 2 complement. Therefore it was not possible to define behavior for signed overflow. They probably should change that 2020^^ GCC has intrinsics for integer math with overflow checks
    - ncmncm 6y ago
      C++ formalized two's complement already. Formalizing power-of-two word size and 8-bit bytes might come.
CalChris 6y ago
This reminds me of Peter Drucker, "What gets measured gets improved". Conversely, if you don't measure it, it usually doesn't get improved.
- brandmeyer 6y ago
  Its a tough situation to be in, especially when RISC orthodoxy elevates measurements to a paramount position in the ISA design process. I don't think they were wrong to do so, either. The error was in finalizing the ISA without more backends to work with. How much business code out there burns most of its cycles in Java/C#/Rust/Go? Having even one of those (lets face it: Java) would have gone a very long way. How much client computing spends most of its cycles in (JITted) javascript? I understand the tradeoff that drives this omission, though. How many VC megabucks (Tens? Hundreds?) would they have had to spend commercially on a bet? Alternatively, how many grad student-years grinding through low payoff work to prove yea/nea on the value of checked arithmetic? Lets say that you make a hip-shot bet on some checked arithmetic support without the supporting toolchains and application code to back up the design choice. You could end up making a different set of mistakes instead and end up in the same situation. I think the only mistake was in finalizing the ISA without any support for checked arithmetic. My belief is that doing it well will not be orthogonal to the rest of the ISA's design, and therefore is a poor candidate for an extension.

pizlonator 6y ago

That’s my suspicion too! I don’t think these folks have seen what modern languages do.

convolvatron 6y ago

C really did screw things up by just refusing to address overflow in any form, didn't it

brandmeyer 6y ago
I don't think C screwed up. C's objective was to standardize a set of practices based on what the hardware of the day was capable of. If they had pessimized performance on one architecture because it failed to provide efficient checked overflow (or any other feature), then C would have never made it to standardization. ISO C is therefore a three-way compromise between three communities: Software authors, compiler authors, and CPU manufacturers. You will naturally end up with some decisions that dissatisfy some members of each.
- Gibbon1 6y ago
  Better would be to say that the C standard committee screwed things up by refusing to address a lot of issues over the last 35 years.
  - saagarjha 6y ago
    Not really, they have addresses pretty much all of the issues. Now, you can argue that they favored compiler authors when doing so, but they have consider the problems and done things in response to them.
pizlonator 6y ago
Yes. In many ways: 1) it’s pretty important to have easy syntax for math with overflow checks. Otherwise there will be bugs. Bad bugs. We have those and it sucks. 2) it’s pretty important that if the overflow wraps in ISA then it wraps in language semantics but C just says “meh whatever” for signed overflow. That leads to even more bugs.
- GeorgeTirebiter 6y ago
  The HP3000 had "SPL" - Systems Programming Language -- as its way of doing what C does. It had a specific syntax for checking the error codes: if <> then <whatever> so whatever previous arithmetic did, you could check the machine's flags directly. Can't do that in C. https://en.wikipedia.org/wiki/Systems_Programming_Language https://en.wikipedia.org/wiki/Systems_Programming_Language
- the5avage 6y ago
  At the time C was designed not all machines did represent signed integers in 2 complement. Therefore it was not possible to define behavior for signed overflow. They probably should change that 2020^^ GCC has intrinsics for integer math with overflow checks
  - ncmncm 6y ago
    C++ formalized two's complement already. Formalizing power-of-two word size and 8-bit bytes might come.

CalChris 6y ago

This reminds me of Peter Drucker, "What gets measured gets improved". Conversely, if you don't measure it, it usually doesn't get improved.

brandmeyer 6y ago
Its a tough situation to be in, especially when RISC orthodoxy elevates measurements to a paramount position in the ISA design process. I don't think they were wrong to do so, either. The error was in finalizing the ISA without more backends to work with. How much business code out there burns most of its cycles in Java/C#/Rust/Go? Having even one of those (lets face it: Java) would have gone a very long way. How much client computing spends most of its cycles in (JITted) javascript? I understand the tradeoff that drives this omission, though. How many VC megabucks (Tens? Hundreds?) would they have had to spend commercially on a bet? Alternatively, how many grad student-years grinding through low payoff work to prove yea/nea on the value of checked arithmetic? Lets say that you make a hip-shot bet on some checked arithmetic support without the supporting toolchains and application code to back up the design choice. You could end up making a different set of mistakes instead and end up in the same situation. I think the only mistake was in finalizing the ISA without any support for checked arithmetic. My belief is that doing it well will not be orthogonal to the rest of the ISA's design, and therefore is a poor candidate for an extension.