4 ms·

> RISC processors, with their reduced instruction sets, cast aside less-important instructions such as decimal arithmetic Interestingly, the John Mashey at MIP

> RISC processors, with their reduced instruction sets, cast aside less-important instructions such as decimal arithmetic Interestingly, the John Mashey at MIPS defended the use of BCD instructions in what I think is PA-RISC (which does have a DCOR - Decimal Correct instruction). That's because they looked at their instruction traces, saw lots of use of BCD arithmetic as the processor was targeting COBOL among other languages, and implemented that hardware support as single cycle register to register ops, and kept the overall arch of a normal RISC. That sort of diffusion test where you actually go look at instruction traces to come up with single cycle accelerators for your expected use case, but architecturally don't comingle your load store pathway with your ALU ops is sort of the heart of RISC. HP simply had different goals for their RISC chip than MIPS. https://yarchive.net/comp/bcd_instructions.html https://yarchive.net/comp/bcd_instructions.html That argument still pops up, for instance the "javascript instruction" in ARM. There's a lot about ARM that isn't pure RISC, but I argue that instruction is. They looked at instruction traces and found a single cycle (dispatch at least, it might be pipelined) ALU op that could accelerate the workloads that were important to them. In this case converting float to integer using x86 rounding modes rather than whatever modes are in the config register because Javascript expects x86 rounding which is different than default ARM rounding and switching back and forth is expensive. That instruction and the process used to come up with it are about as RISC as you can get, IMO. </semi_unrelated_rant>

kps 4y ago
One little line in there — “Machines are faster now, and the British use boring decimal currency like everyone else”. There were once machines with support for LSD mixed-base arithmetic (10, …, 10, 20, 12) in hardware and languages.
- KMag 4y ago
  ... and most stock markets are also decimalized now. I remember reading the newspaper for my 7th grade investment club run by my math teacher. Prices were in 1/8ths of a dollar, as I remember, and maybe the penny stocks were in 1/6ths. In an alternate universe where the IEEE-754r decimal formats were in the original IEEE-754 spec, presumably most of these decimal integer operations would be performed in the FPU. If they're common enough, a handful of specialized fast-path instructions could be implemented for cases where it's known a priori that the exponents of the arguments match. Though, as sad is it is that we still use gallons in the US, it is handy that all of the subdivisions of a gallon down to the ounce are powers of two. Alternatively, the Babylonians were more advanced than we generally give them credit, as their base-60 number system isn't intuitive, and yet has lots of small factors for handy fractions. Any fraction storable in a finite number of digits in base-2, base-10, or base-12 (including any integer power of 1/3) is storable in a finite number of digits in base-60. So, a base-60 calculation would result in fewer display issues due to rounding for common calculations in people's everyday lives. Storing one base-60 digit in 6 bits isn't terribly wasteful, though more wasteful than storing 3 base-10 digits in 10 bits.

kps 4y ago

One little line in there — “Machines are faster now, and the British use boring decimal currency like everyone else”. There were once machines with support for LSD mixed-base arithmetic (10, …, 10, 20, 12) in hardware and languages.

KMag 4y ago
... and most stock markets are also decimalized now. I remember reading the newspaper for my 7th grade investment club run by my math teacher. Prices were in 1/8ths of a dollar, as I remember, and maybe the penny stocks were in 1/6ths. In an alternate universe where the IEEE-754r decimal formats were in the original IEEE-754 spec, presumably most of these decimal integer operations would be performed in the FPU. If they're common enough, a handful of specialized fast-path instructions could be implemented for cases where it's known a priori that the exponents of the arguments match. Though, as sad is it is that we still use gallons in the US, it is handy that all of the subdivisions of a gallon down to the ounce are powers of two. Alternatively, the Babylonians were more advanced than we generally give them credit, as their base-60 number system isn't intuitive, and yet has lots of small factors for handy fractions. Any fraction storable in a finite number of digits in base-2, base-10, or base-12 (including any integer power of 1/3) is storable in a finite number of digits in base-60. So, a base-60 calculation would result in fewer display issues due to rounding for common calculations in people's everyday lives. Storing one base-60 digit in 6 bits isn't terribly wasteful, though more wasteful than storing 3 base-10 digits in 10 bits.