6 ms·

This video is very interesting. Very good point about the manufacturing of processors being backwards. Why _not_ put an interpreter inside the L1 cache that ac

by htor 12y ago

This video is very interesting. Very good point about the manufacturing of processors being backwards. Why _not_ put an interpreter inside the L1 cache that accomodates higher level programming of the computer? Why are we still stuck with assembly as the interface to the CPU?

valarauca1 12y ago
This should answer your question. Albeit satirically but the context is very solid [1]. Basically like most forms of engineering, making processors is hard. [1] https://www.usenix.org/system/files/1309_14-17_mickens.pdf https://www.usenix.org/system/files/1309_14-17_mickens.pdf
frik 12y ago
We had already Lisp running directly on a CPU: http://en.wikipedia.org/wiki/Lisp_machine http://en.wikipedia.org/wiki/Lisp_machine Java runs directly on hardware: http://en.wikipedia.org/wiki/Java_processor http://en.wikipedia.org/wiki/Java_processor , http://en.wikipedia.org/wiki/Java_Card http://en.wikipedia.org/wiki/Java_Card Pascal MicroEngine: http://en.wikipedia.org/wiki/Pascal_MicroEngine http://en.wikipedia.org/wiki/Pascal_MicroEngine And some more: http://en.wikipedia.org/wiki/Category:High-level_language_computer_architecture http://en.wikipedia.org/wiki/Category:High-level_language_co... And the x86 instruction set is CISC, but (modern) x86 architecture is RISC (inside) - so your modern Intel/AMD CPU already does it. http://stackoverflow.com/questions/13071221/is-x86-risc-or-cisc http://stackoverflow.com/questions/13071221/is-x86-risc-or-c... Backward compatibility aside, we could have CPUs that support a ANSI C or the upcoming Rust directly in hardware, instead of ASM.
- vezzy-fnord 12y ago
  Don't forget the Burroughs B5000, from 1961: https://en.wikipedia.org/wiki/Burroughs_large_systems#B5000 https://en.wikipedia.org/wiki/Burroughs_large_systems#B5000 The fact that we had an architecture running entirely on ALGOL with no ASM as far back as 54 years ago, is quite astonishing, followed by depressing.
  - Animats 12y ago
    I know. I once took a computer architecture course from Bill McKeeman at UCSC, and we had an obsolete B5500 to play with. We got to step through instruction execution from the front panel, watching operands push and pop off the stack. The top two locations on the stack were hardware registers to speed things up. An address on the Burroughs machines is a path - something like "Process 22 / function 15 / array 3 / offset 14. The actual memory address is no more visible to the program than an actual disk address is visible in a modern file system. Each of those elements is pageable, and arrays can be grown. The OS controls the memory mapping tree. One of the things that killed those machines was the rise of C and UNIX. C and UNIX assume a flat address space. The Burroughs machines don't support C-style pointers.
- e12e 12y ago
  Don't forget transmeta either. Unfortunately they didn't succeed either. Did employ Linus Torvalds for a while though.
Animats 12y ago
Because when DEC did that in the VAX 11/780, nobody used it. Instructions could be added to the microcode, which was loaded at boot time from an 8" floppy. The VAX 11/780 machine language was designed to allow clean expression of program concepts. There's integer overflow checking, a clean CALL instruction, MULTICS-style rings of protection, and very general addressing forms. It's a very pleasant machine to program in assembler. Unfortunately, it was slow, at 1 MIPS, and had an overly complex CPU that took 12 large boards. (It was late for that; by the time VAXen shipped in volume, the Motorola 68000 was out.) The CALL instruction was microcoded, and it took longer for it to do all the steps and register saving than a call written without using that instruction. Nobody ever added to the microcode to implement new features, except experimentally. DEC's own VMS OS used the rings of protection, but UNIX did not. One of the results of UNIX was the triumph of vanilla hardware. UNIX can't do much with exotic hardware, so there's not much point in building it. There's a long history of exotic CPUs. Machines for FORTH, LISP, and BASIC (http://www.classiccmp.org/cini/pdf/NatSemi/INS8073_DataSheet.pdf http://www.classiccmp.org/cini/pdf/NatSemi/INS8073_DataSheet...) have been built. None were very successful. NS's cheap BASIC chip was used for little control systems at the appliance level, and is probably the most successful one. There are things we could do in hardware. Better support for domain crossing (not just user to kernel, but user to middleware). Standardized I/O channels with memory protection between device and memory. Integer overflow detection. Better atomic primitives for multiprocessors. But those features would just be added as new supported items for existing operating systems, not as an architectural base for new one. (I'm writing this while listening to Alan Kay talk at great length. Someone needs to edit that video down to 20 minutes.)
- ableal 12y ago
  The Data General MV-8000 (of Soul of a New Machine book fame) also had programmable microcode, if memory serves. The feature was touted, and there were supposed to exist a few brave souls, desperate for performance, who used it.

by htor 12y ago

valarauca1 12y ago

This should answer your question. Albeit satirically but the context is very solid [1]. Basically like most forms of engineering, making processors is hard. [1] https://www.usenix.org/system/files/1309_14-17_mickens.pdf https://www.usenix.org/system/files/1309_14-17_mickens.pdf

frik 12y ago

We had already Lisp running directly on a CPU: http://en.wikipedia.org/wiki/Lisp_machine http://en.wikipedia.org/wiki/Lisp_machine Java runs directly on hardware: http://en.wikipedia.org/wiki/Java_processor http://en.wikipedia.org/wiki/Java_processor , http://en.wikipedia.org/wiki/Java_Card http://en.wikipedia.org/wiki/Java_Card Pascal MicroEngine: http://en.wikipedia.org/wiki/Pascal_MicroEngine http://en.wikipedia.org/wiki/Pascal_MicroEngine And some more: http://en.wikipedia.org/wiki/Category:High-level_language_computer_architecture http://en.wikipedia.org/wiki/Category:High-level_language_co... And the x86 instruction set is CISC, but (modern) x86 architecture is RISC (inside) - so your modern Intel/AMD CPU already does it. http://stackoverflow.com/questions/13071221/is-x86-risc-or-cisc http://stackoverflow.com/questions/13071221/is-x86-risc-or-c... Backward compatibility aside, we could have CPUs that support a ANSI C or the upcoming Rust directly in hardware, instead of ASM.

vezzy-fnord 12y ago
Don't forget the Burroughs B5000, from 1961: https://en.wikipedia.org/wiki/Burroughs_large_systems#B5000 https://en.wikipedia.org/wiki/Burroughs_large_systems#B5000 The fact that we had an architecture running entirely on ALGOL with no ASM as far back as 54 years ago, is quite astonishing, followed by depressing.
- Animats 12y ago
  I know. I once took a computer architecture course from Bill McKeeman at UCSC, and we had an obsolete B5500 to play with. We got to step through instruction execution from the front panel, watching operands push and pop off the stack. The top two locations on the stack were hardware registers to speed things up. An address on the Burroughs machines is a path - something like "Process 22 / function 15 / array 3 / offset 14. The actual memory address is no more visible to the program than an actual disk address is visible in a modern file system. Each of those elements is pageable, and arrays can be grown. The OS controls the memory mapping tree. One of the things that killed those machines was the rise of C and UNIX. C and UNIX assume a flat address space. The Burroughs machines don't support C-style pointers.
e12e 12y ago
Don't forget transmeta either. Unfortunately they didn't succeed either. Did employ Linus Torvalds for a while though.

Animats 12y ago

Because when DEC did that in the VAX 11/780, nobody used it. Instructions could be added to the microcode, which was loaded at boot time from an 8" floppy. The VAX 11/780 machine language was designed to allow clean expression of program concepts. There's integer overflow checking, a clean CALL instruction, MULTICS-style rings of protection, and very general addressing forms. It's a very pleasant machine to program in assembler. Unfortunately, it was slow, at 1 MIPS, and had an overly complex CPU that took 12 large boards. (It was late for that; by the time VAXen shipped in volume, the Motorola 68000 was out.) The CALL instruction was microcoded, and it took longer for it to do all the steps and register saving than a call written without using that instruction. Nobody ever added to the microcode to implement new features, except experimentally. DEC's own VMS OS used the rings of protection, but UNIX did not. One of the results of UNIX was the triumph of vanilla hardware. UNIX can't do much with exotic hardware, so there's not much point in building it. There's a long history of exotic CPUs. Machines for FORTH, LISP, and BASIC (http://www.classiccmp.org/cini/pdf/NatSemi/INS8073_DataSheet.pdf http://www.classiccmp.org/cini/pdf/NatSemi/INS8073_DataSheet...) have been built. None were very successful. NS's cheap BASIC chip was used for little control systems at the appliance level, and is probably the most successful one. There are things we could do in hardware. Better support for domain crossing (not just user to kernel, but user to middleware). Standardized I/O channels with memory protection between device and memory. Integer overflow detection. Better atomic primitives for multiprocessors. But those features would just be added as new supported items for existing operating systems, not as an architectural base for new one. (I'm writing this while listening to Alan Kay talk at great length. Someone needs to edit that video down to 20 minutes.)

ableal 12y ago
The Data General MV-8000 (of Soul of a New Machine book fame) also had programmable microcode, if memory serves. The feature was touted, and there were supposed to exist a few brave souls, desperate for performance, who used it.