4 ms·

A higher clock rate means little. What each instruction does and how fast it does it is the real question; MIPS fails horribly here, as its instructions are bo

A higher clock rate means little. What each instruction does and how fast it does it is the real question; MIPS fails horribly here, as its instructions are both obscenely large and also do very little. RISC in general is misguided and MIPS is a nice monument to how a ''reduced'' instruction set eventually bloats from various reasons, such as increasing the register size. From what I've seen, SuperH is much nicer, with multiple addressing modes and sixteen bit instructions. RISC-V has nice qualities, but being among the nicer RISC hardly means much. It's unfortunate there's a dearth of high-level machines nowadays. Where are the hardware implementations of abstract machines that aren't the JVM? Where's the attribute memory that stores things such as array bounds and types? For that matter, where's the real notion of an array instead of offset memory? That's all in the past now, unfortunately. MIPS is hardly something worth crying over. The only reason I give it any attention is because I own some exotic MIPS hardware.

ernst_klim 7y ago
>Where are the hardware implementations of abstract machines that aren't the JVM? Why would anyone like to have such a CPU? CPUs should be generic, being able to run any language and any runtime, being easy target for compilation, giving the way for various optimizations (pipelines, branch prediction). RISC is the best here. Abstract high level machines are slow, clumsy, useless in real world applications.
- verisimilitudes 7y ago
  >Why would anyone like to have such a CPU? Well, the common theme is, once processors won't become faster due to hardware improvements, they'll become faster through specialization. That's tangential, however, because it's clearly better to execute, say, Lisp on a machine with hardware support for lists or Forth on a machine with a hardware stack and so on and so forth. >CPUs should be generic, being able to run any language and any runtime, being easy target for compilation, giving the way for various optimizations (pipelines, branch prediction). Right, I forgot that if it runs C and UNIX, that automatically qualifies it as ''generic''. Firstly, anything that can emulate a Turing machine, sans memory, can run ''any language and any runtime'', in general. I know Genera had compilers for C and other several other languages; ironically, it's my understanding the C compiler had to use arrays of small integers to represent many things, as C ties itself irreparably to such details, no matter how tangential to the program. Secondly, if you have an operation you'll be performing a great deal of, such as bounds checking, list manipulation, or abitrary-length arithmetic, it's worthwhile to have it supported in the hardware. Having smart instructions is leagues better than working around dumb instructions with pipelines and whatnot and, apparently, is easier to get right, knowing the recent Intel flaws and all of that.
  - ernst_klim 7y ago
    > they'll become faster through specialization Do you have any evidences of that? Because from my naive understanding, simple processors are easier to optimize: you could have hierarchical memory, pipelines, speculative execution, branch prediction, additional instructions, like vectors and so on. Doesn't the specialization make such things harder to implement due to higher complexity. Do you have an example of specialized hardware that beats the contemporary highly optimized CPUs like ARM? >Secondly, if you have an operation you'll be performing a great deal of, such as bounds checking, list manipulation, or abitrary-length arithmetic, it's worthwhile to have it supported in the hardware Why would you like to have bounds checking or list manipulation in hardware? It's a waste of transistors. A code like x := array[1] should have one bounds check, yet for x in 0..n: sum := sum + array[x] should also have one bounds check, not many. Thus you have to either use an inefficient instruction or implement a hardware iterator bloating your CPU beyond reasonable limits. And why lists? Why not trees, hashtables, ephemerons?
    - verisimilitudes 7y ago
      >Do you have any evidences of that? If you have a circuit that implements an algorithm, it can beat a program that implements the algorithm for a machine that lacks such a circuit. This is clear. >Because from my naive understanding, simple processors are easier to optimize I've already reasonably explained why that's not the case, but I want to note that these machines aren't necessarily simpler. The Lisp machine processors are far simpler than anything Intel, ARM, or MIPS have been putting out, and yet did more, just not as fast due to major hardware production advancements. >Do you have an example of specialized hardware that beats the contemporary highly optimized CPUs like ARM? I don't have an example in speed, no, but I can tell you that there are simpler processors that avoid entire classes of programming errors these machines are still vulnerable to. If you're only going to judge a machine by speed, I wonder if you own a car and, if so, if it has air bags, seat belts, and other such things. >Why would you like to have bounds checking or list manipulation in hardware? It's a waste of transistors. Having a large amount of a processor dedicated to fast memory to store groups of instructions for things such as bounds checking and list manipulation isn't? x := array[1] This could likely be determined at compilation. for x in 0..n: sum := sum + array[x] It's my understanding there were implementations of hardware, or at least descriptions thereof, explaining how such a bound could easily be cached and compared in tandem with other operations, for each new iteration, which would be equivalent to checking when the loop should terminate. >And why lists? Why not trees, hashtables, ephemerons? Why not? It's not unreasonable to expect the machine to have canonical and supported representations for commonly used forms of data and operations on such.

ernst_klim 7y ago

>Where are the hardware implementations of abstract machines that aren't the JVM? Why would anyone like to have such a CPU? CPUs should be generic, being able to run any language and any runtime, being easy target for compilation, giving the way for various optimizations (pipelines, branch prediction). RISC is the best here. Abstract high level machines are slow, clumsy, useless in real world applications.

verisimilitudes 7y ago
>Why would anyone like to have such a CPU? Well, the common theme is, once processors won't become faster due to hardware improvements, they'll become faster through specialization. That's tangential, however, because it's clearly better to execute, say, Lisp on a machine with hardware support for lists or Forth on a machine with a hardware stack and so on and so forth. >CPUs should be generic, being able to run any language and any runtime, being easy target for compilation, giving the way for various optimizations (pipelines, branch prediction). Right, I forgot that if it runs C and UNIX, that automatically qualifies it as ''generic''. Firstly, anything that can emulate a Turing machine, sans memory, can run ''any language and any runtime'', in general. I know Genera had compilers for C and other several other languages; ironically, it's my understanding the C compiler had to use arrays of small integers to represent many things, as C ties itself irreparably to such details, no matter how tangential to the program. Secondly, if you have an operation you'll be performing a great deal of, such as bounds checking, list manipulation, or abitrary-length arithmetic, it's worthwhile to have it supported in the hardware. Having smart instructions is leagues better than working around dumb instructions with pipelines and whatnot and, apparently, is easier to get right, knowing the recent Intel flaws and all of that.
- ernst_klim 7y ago
  > they'll become faster through specialization Do you have any evidences of that? Because from my naive understanding, simple processors are easier to optimize: you could have hierarchical memory, pipelines, speculative execution, branch prediction, additional instructions, like vectors and so on. Doesn't the specialization make such things harder to implement due to higher complexity. Do you have an example of specialized hardware that beats the contemporary highly optimized CPUs like ARM? >Secondly, if you have an operation you'll be performing a great deal of, such as bounds checking, list manipulation, or abitrary-length arithmetic, it's worthwhile to have it supported in the hardware Why would you like to have bounds checking or list manipulation in hardware? It's a waste of transistors. A code like x := array[1] should have one bounds check, yet for x in 0..n: sum := sum + array[x] should also have one bounds check, not many. Thus you have to either use an inefficient instruction or implement a hardware iterator bloating your CPU beyond reasonable limits. And why lists? Why not trees, hashtables, ephemerons?
  - verisimilitudes 7y ago
    >Do you have any evidences of that? If you have a circuit that implements an algorithm, it can beat a program that implements the algorithm for a machine that lacks such a circuit. This is clear. >Because from my naive understanding, simple processors are easier to optimize I've already reasonably explained why that's not the case, but I want to note that these machines aren't necessarily simpler. The Lisp machine processors are far simpler than anything Intel, ARM, or MIPS have been putting out, and yet did more, just not as fast due to major hardware production advancements. >Do you have an example of specialized hardware that beats the contemporary highly optimized CPUs like ARM? I don't have an example in speed, no, but I can tell you that there are simpler processors that avoid entire classes of programming errors these machines are still vulnerable to. If you're only going to judge a machine by speed, I wonder if you own a car and, if so, if it has air bags, seat belts, and other such things. >Why would you like to have bounds checking or list manipulation in hardware? It's a waste of transistors. Having a large amount of a processor dedicated to fast memory to store groups of instructions for things such as bounds checking and list manipulation isn't? x := array[1] This could likely be determined at compilation. for x in 0..n: sum := sum + array[x] It's my understanding there were implementations of hardware, or at least descriptions thereof, explaining how such a bound could easily be cached and compared in tandem with other operations, for each new iteration, which would be equivalent to checking when the loop should terminate. >And why lists? Why not trees, hashtables, ephemerons? Why not? It's not unreasonable to expect the machine to have canonical and supported representations for commonly used forms of data and operations on such.