5 ms·

Lisp Machine was not alone, similar products exist/existed. Intel iAPX 432 run Ada, Pascal MicroEngine run Pascal, CreditCards (EU) run JavaMicro bytecode, ECOM

by frik 12y ago

Lisp Machine was not alone, similar products exist/existed. Intel iAPX 432 run Ada, Pascal MicroEngine run Pascal, CreditCards (EU) run JavaMicro bytecode, ECOMP run Erlang, Burroughs Medium Systems run COBOL, etc. High-level language computer architecture: http://en.wikipedia.org/wiki/High-level_language_computer_architecture http://en.wikipedia.org/wiki/High-level_language_computer_ar... I could imagine a modern high-level computer architecture that is based on the LLVM intermediate representation (or GNU gcc RTL). A lot of transistors in a modern CPUs could be saved if we remove all the legacy x86 ASM. Especially as modern x86/x64 CPUs emulate an CISC, and are a RISC architecture.

lispm 12y ago
None of those were in any way 'similar' to Lisp Machines from Xerox, TI, LMI or Symbolics. Those were high-end workstations with a Lisp OS, coming in a lot of different form factors. They were developed from 1981 to 1992. The main similarities were that they all used electricity. Some of the computers with Java-processor were similar in that they provided an object-oriented garbage-collected language and OS.
- frik 12y ago
  > None of those were in any way 'similar' to Lisp Machines It seems you misinterpreted my sentences. Read the linked Wikipedia. Basically not ASM/Assembler code (0, 1 form) is executed on the CPU but a specific higher level language like Lisp/Ada/Pascal/Java/etc. directly.
  - lispm 12y ago
    Lisp Machines did not run Lisp 'directly'. Lisp code was either running interpreted or usually compiled to machine code. This is an example from a Symbolics Lisp Machine with an Ivory CPU. (defun example-count (predicate list) (let ((count 0)) (dolist (i list count) (when (funcall predicate i) (incf count))))) The disassembled machine code for above function (for the Ivory microprocessor from Symbolics): Command: (disassemble (compile #'example-count)) 0 ENTRY: 2 REQUIRED, 0 OPTIONAL ;Creating PREDICATE and LIST 2 PUSH 0 ;Creating COUNT 3 PUSH FP|3 ;LIST 4 PUSH NIL ;Creating I 5 BRANCH 15 6 SET-TO-CDR-PUSH-CAR FP|5 7 SET-SP-TO-ADDRESS-SAVE-TOS SP|-1 10 START-CALL FP|2 ;PREDICATE 11 PUSH FP|6 ;I 12 FINISH-CALL-1-VALUE 13 BRANCH-FALSE 15 14 INCREMENT FP|4 ;COUNT 15 ENDP FP|5 16 BRANCH-FALSE 6 17 SET-SP-TO-ADDRESS SP|-2 20 RETURN-SINGLE-STACK This machine also had C, Pascal, Fortran, Ada and Prolog compilers.
    - crististm 12y ago
      I was reading these days the Symbolics C manual to find some details about the compiler's output. I know that the hw had assembly instructions that mapped almost one-to-one to Lisp primitives. However, what was the output of the C compiler and how did they integrate it with the Lisp code? For that matter, what was the output of the Pascal or ADA compilers? In one of K. Reti's videos there's a blend of stack traces of Lisp and C code. What makes that possible?
      - lispm 12y ago
        > I know that the hw had assembly instructions that mapped almost one-to-one to Lisp primitives. In my example you see the assembly. You can see how much 'one-to-one' it was... The C compiler compiled to Lisp and then to machine code. Same for Pascal. For Ada, I don't know.
        DonHopkins 12y ago
        I once visited a Washington DC Beltway Bandit government contractor's office who had a Symbolics Lisp Machine that they used exclusively to develop Fortran code, which they compiled into Lisp and debugged with the awesome programming tools. And of course there was Gyro's Zeta-C compiler, with an interactive C listener.
        mietek 12y ago
        Artefacts of a future past…
    - psandersen 12y ago
      You sound knowledgable so thought I'd ask here :) ... Would there be any logic/benefit in a modern lisp machine? e.g. if intel decided they'd put the same engineering effort into a 'lisp machine' as they did Haswell, would there be any inherent advantages or things that could be done differently?
      - 12y ago
WallWextra 12y ago
Replacing x86 with a RISC instruction set would do little good. Performance doesn't come from the RISCness of the decoded uops, it comes from superscalar out-of-order execution, big caches, finely-tuned branch predictors, forwarding networks, a good memory controller, etc. That all takes up more transistors than x86 decode. POWER8 is the only RISC that is comparable to high-end Intel parts, and it is not a particularly small chip. ARM used to have some ISA extensions for directly-executing JVM bytecodes, but it's deprecated. An optimizing JIT compiler gets much better results.
- hajile 12y ago
  CISC vs RISC is a little blurred. Most/all x86 instruction sets from SSE and onward are very RISC-like (and theses provide most of the chip's power). If we move back from these problem types to look at something like coremark, then MIPS has the highest coremark/MHz score. A more interesting question is that of the resources required to compete. In 2013, Intel spent 10 Billion in R&D while it's closest competitor (Qualcomm) spent 3 Billion (in fact, Intel spent more than the next four companies put together -- lest you argue about fabs, TSMC spent only 1.6 Billion). When companies using RISC are getting similar results for a fraction of the R&D, is x86 winning or just showing that with enough money, even a bad design can be made to work? ARM's A9 has similar performance to a Core2 T7200 (Tegra3 -- even when you account for the compiler the A9 is faster per clock at several things). A15 is around 60% faster than A9, ARM claims A72 is supposed to be 3.5x faster than A15 in 2016. ARM's 2014 R&D budget was around 400 Million (25x less than Intel). ARM is getting very close very fast on what is a shoestring budget in comparison. http://www.icinsights.com/news/bulletins/Top-10-Semiconductor-RD-Leaders-Ranked-For-2013-/ http://www.icinsights.com/news/bulletins/Top-10-Semiconducto...
  - WallWextra 12y ago
    First, I would dispute that a cortex A9 is comparable to a Core 2. Second, if ARM is in fact getting that close to Intel, I would attribute it to diminishing returns, and not some mythical property of the ISA that makes it difficult to implement. I'm not sure what you mean by wide SIMD extensions providing "most of the chip's power." If you mean for vectorized DSP loops or whatever, sure, but I was talking about performance on branchy pointer-chasing spaghetti, which is what most real code is, and where it would be the hardest to catch up to Intel.

by frik 12y ago

lispm 12y ago

None of those were in any way 'similar' to Lisp Machines from Xerox, TI, LMI or Symbolics. Those were high-end workstations with a Lisp OS, coming in a lot of different form factors. They were developed from 1981 to 1992. The main similarities were that they all used electricity. Some of the computers with Java-processor were similar in that they provided an object-oriented garbage-collected language and OS.

frik 12y ago
> None of those were in any way 'similar' to Lisp Machines It seems you misinterpreted my sentences. Read the linked Wikipedia. Basically not ASM/Assembler code (0, 1 form) is executed on the CPU but a specific higher level language like Lisp/Ada/Pascal/Java/etc. directly.
- lispm 12y ago
  Lisp Machines did not run Lisp 'directly'. Lisp code was either running interpreted or usually compiled to machine code. This is an example from a Symbolics Lisp Machine with an Ivory CPU. (defun example-count (predicate list) (let ((count 0)) (dolist (i list count) (when (funcall predicate i) (incf count))))) The disassembled machine code for above function (for the Ivory microprocessor from Symbolics): Command: (disassemble (compile #'example-count)) 0 ENTRY: 2 REQUIRED, 0 OPTIONAL ;Creating PREDICATE and LIST 2 PUSH 0 ;Creating COUNT 3 PUSH FP|3 ;LIST 4 PUSH NIL ;Creating I 5 BRANCH 15 6 SET-TO-CDR-PUSH-CAR FP|5 7 SET-SP-TO-ADDRESS-SAVE-TOS SP|-1 10 START-CALL FP|2 ;PREDICATE 11 PUSH FP|6 ;I 12 FINISH-CALL-1-VALUE 13 BRANCH-FALSE 15 14 INCREMENT FP|4 ;COUNT 15 ENDP FP|5 16 BRANCH-FALSE 6 17 SET-SP-TO-ADDRESS SP|-2 20 RETURN-SINGLE-STACK This machine also had C, Pascal, Fortran, Ada and Prolog compilers.
  - crististm 12y ago
    I was reading these days the Symbolics C manual to find some details about the compiler's output. I know that the hw had assembly instructions that mapped almost one-to-one to Lisp primitives. However, what was the output of the C compiler and how did they integrate it with the Lisp code? For that matter, what was the output of the Pascal or ADA compilers? In one of K. Reti's videos there's a blend of stack traces of Lisp and C code. What makes that possible?
    - lispm 12y ago
      > I know that the hw had assembly instructions that mapped almost one-to-one to Lisp primitives. In my example you see the assembly. You can see how much 'one-to-one' it was... The C compiler compiled to Lisp and then to machine code. Same for Pascal. For Ada, I don't know.
      - DonHopkins 12y ago
        I once visited a Washington DC Beltway Bandit government contractor's office who had a Symbolics Lisp Machine that they used exclusively to develop Fortran code, which they compiled into Lisp and debugged with the awesome programming tools. And of course there was Gyro's Zeta-C compiler, with an interactive C listener.
        mietek 12y ago
        Artefacts of a future past…
  - psandersen 12y ago
    You sound knowledgable so thought I'd ask here :) ... Would there be any logic/benefit in a modern lisp machine? e.g. if intel decided they'd put the same engineering effort into a 'lisp machine' as they did Haswell, would there be any inherent advantages or things that could be done differently?
    - 12y ago

WallWextra 12y ago

Replacing x86 with a RISC instruction set would do little good. Performance doesn't come from the RISCness of the decoded uops, it comes from superscalar out-of-order execution, big caches, finely-tuned branch predictors, forwarding networks, a good memory controller, etc. That all takes up more transistors than x86 decode. POWER8 is the only RISC that is comparable to high-end Intel parts, and it is not a particularly small chip. ARM used to have some ISA extensions for directly-executing JVM bytecodes, but it's deprecated. An optimizing JIT compiler gets much better results.

hajile 12y ago
CISC vs RISC is a little blurred. Most/all x86 instruction sets from SSE and onward are very RISC-like (and theses provide most of the chip's power). If we move back from these problem types to look at something like coremark, then MIPS has the highest coremark/MHz score. A more interesting question is that of the resources required to compete. In 2013, Intel spent 10 Billion in R&D while it's closest competitor (Qualcomm) spent 3 Billion (in fact, Intel spent more than the next four companies put together -- lest you argue about fabs, TSMC spent only 1.6 Billion). When companies using RISC are getting similar results for a fraction of the R&D, is x86 winning or just showing that with enough money, even a bad design can be made to work? ARM's A9 has similar performance to a Core2 T7200 (Tegra3 -- even when you account for the compiler the A9 is faster per clock at several things). A15 is around 60% faster than A9, ARM claims A72 is supposed to be 3.5x faster than A15 in 2016. ARM's 2014 R&D budget was around 400 Million (25x less than Intel). ARM is getting very close very fast on what is a shoestring budget in comparison. http://www.icinsights.com/news/bulletins/Top-10-Semiconductor-RD-Leaders-Ranked-For-2013-/ http://www.icinsights.com/news/bulletins/Top-10-Semiconducto...
- WallWextra 12y ago
  First, I would dispute that a cortex A9 is comparable to a Core 2. Second, if ARM is in fact getting that close to Intel, I would attribute it to diminishing returns, and not some mythical property of the ISA that makes it difficult to implement. I'm not sure what you mean by wide SIMD extensions providing "most of the chip's power." If you mean for vectorized DSP loops or whatever, sure, but I was talking about performance on branchy pointer-chasing spaghetti, which is what most real code is, and where it would be the hardest to catch up to Intel.