4 ms·

I want to call this text out, because I nearly did a spit-take when I saw it, and someone skimming the post may miss it: The mortally wounded features included

by scott_s 12y ago

I want to call this text out, because I nearly did a spit-take when I saw it, and someone skimming the post may miss it: The mortally wounded features included a data cache (!), an instruction cache (!!) and registers (!!!). Yes, you read correctly: this machine had no data cache, no instruction cache and no registers — it was exclusively memory-memory. No. Registers. I would love to know what discussions they had, and what arguments were made, to come to that decision. That point alone has made me re-open the paper to take a closer look.

JoeAltmaier 12y ago
I recall it was a microprogrammed processor - a set of chips including a rom 'executed' the instruction set. More of an emulator than a processor. So maybe nowhere in that design for a cache?
- scott_s 12y ago
  Possibly - the design started back in 1975, which is when we were still figuring out a lot of how processors should be designed. That's also far back enough that, frankly, I don't have much of an intuition for what people were thinking. By the way, I am struck by how close their object model sounds like the JVM. A major difference, though, is that the JVM can do some extra work at runtime to figure out when it is profitable and safe to throw away the overhead causes by safety and isolation - JITing. Then it can just execute instructions optimized for the hardware, not constrained by the object model. When your hardware maps to your object model, you can't do that.
  - wmf 12y ago
    The IBM 801 project started around the same time but its proto-RISC approach was kind of the anti-432. The 801 papers give a pretty readable explanation for "why we are proposing the opposite of what everyone else is doing".
    - twoodfin 12y ago
      Do you have links for any of these? I love reading historical rationale papers.
      - JoeAltmaier 12y ago
        I don't. I asked my brother but he just reminisced: "I was at Intel as that project ramped up. One of my friends moved to Portland to work on it. I tried to move, but they didn't want any system software people. If I had, my life would have gone a totally different path... Rich"
spitfire 12y ago
It was a stack machine. No user visible registers. One of the neat things about stack machines is that you can quietly add registers to a machine in the background without having to recompile code. I think this would have been a huge advantage over time. Being able to add registers and performance without having to recompile code. It took us decades to add a few new registers to the X86 architecture. Just imagine if every single (286, 386, 486, pentium, pII, etc) generation had more registers and they were automatically used by software. Pretty neat imho. IIRC it was also a tagged architecture as well. So they could define a generic instruction set and fallback to software implementation for many ops, adding hardware implementations at leisure. Executive summary: They could have done it right first, then made it fast. Rather than make it fast, then try and clean up the technical debt later.
- yuriks 12y ago
  >Just imagine if every single (286, 386, 486, pentium, pII, etc) generation had more registers and they were automatically used by software. This is, in fact, exactly what modern processors do. They have upwards of a hundred registers internally.
  - twic 12y ago
    Although because the x86 only has a handful of architectural registers, it has to spend quite a bit of area and heat working out how to make use of them all. The SPARC's register window design was rather more elegant - provide 520 architectural registers, arranged in a stack, and shuffle between physical registers and memory as needed: http://ieng9.ucsd.edu/~cs30x/sparcstack.html http://ieng9.ucsd.edu/~cs30x/sparcstack.html Unfortunately, it seems it didn't actually work very well!
    - angersock 12y ago
      I had a professor in college bag on those, but he never really explained why. Does anybody know?
      - 12y ago

by scott_s 12y ago

JoeAltmaier 12y ago

I recall it was a microprogrammed processor - a set of chips including a rom 'executed' the instruction set. More of an emulator than a processor. So maybe nowhere in that design for a cache?

scott_s 12y ago
Possibly - the design started back in 1975, which is when we were still figuring out a lot of how processors should be designed. That's also far back enough that, frankly, I don't have much of an intuition for what people were thinking. By the way, I am struck by how close their object model sounds like the JVM. A major difference, though, is that the JVM can do some extra work at runtime to figure out when it is profitable and safe to throw away the overhead causes by safety and isolation - JITing. Then it can just execute instructions optimized for the hardware, not constrained by the object model. When your hardware maps to your object model, you can't do that.
- wmf 12y ago
  The IBM 801 project started around the same time but its proto-RISC approach was kind of the anti-432. The 801 papers give a pretty readable explanation for "why we are proposing the opposite of what everyone else is doing".
  - twoodfin 12y ago
    Do you have links for any of these? I love reading historical rationale papers.
    - JoeAltmaier 12y ago
      I don't. I asked my brother but he just reminisced: "I was at Intel as that project ramped up. One of my friends moved to Portland to work on it. I tried to move, but they didn't want any system software people. If I had, my life would have gone a totally different path... Rich"

spitfire 12y ago

It was a stack machine. No user visible registers. One of the neat things about stack machines is that you can quietly add registers to a machine in the background without having to recompile code. I think this would have been a huge advantage over time. Being able to add registers and performance without having to recompile code. It took us decades to add a few new registers to the X86 architecture. Just imagine if every single (286, 386, 486, pentium, pII, etc) generation had more registers and they were automatically used by software. Pretty neat imho. IIRC it was also a tagged architecture as well. So they could define a generic instruction set and fallback to software implementation for many ops, adding hardware implementations at leisure. Executive summary: They could have done it right first, then made it fast. Rather than make it fast, then try and clean up the technical debt later.

yuriks 12y ago
>Just imagine if every single (286, 386, 486, pentium, pII, etc) generation had more registers and they were automatically used by software. This is, in fact, exactly what modern processors do. They have upwards of a hundred registers internally.
- twic 12y ago
  Although because the x86 only has a handful of architectural registers, it has to spend quite a bit of area and heat working out how to make use of them all. The SPARC's register window design was rather more elegant - provide 520 architectural registers, arranged in a stack, and shuffle between physical registers and memory as needed: http://ieng9.ucsd.edu/~cs30x/sparcstack.html http://ieng9.ucsd.edu/~cs30x/sparcstack.html Unfortunately, it seems it didn't actually work very well!
  - angersock 12y ago
    I had a professor in college bag on those, but he never really explained why. Does anybody know?
    - 12y ago