The Lisp Machine: Noble Experiment or Fabulous Failure? (1991) [pdf]
pt.withy.org
pt.withy.org
Eventually the time was over and the technology was replaced. That happened to Apollo, DEC, SUN, Cray, Thinking Machines, SGI, Amiga, ... and a bunch of other tech companies.
It was great while it lasted. With the cold war ending (and with it the government spending for military and civilian high-tech shifting) and with more versatile/cheaper technology capturing the market (C++, RISC computers, ...) the time was over.
Basically the Lisp Machine tech was ripe for a full reboot (like Steve Jobs did with NeXT, but there was no money for that in the Lisp market anymore). The existing Lisp Machine software was not flexible enough and too limited in its capabilities. Lisp developers might have still like its capabilities, but for the average user/developer, it would have needed to be slimmed down. The emulator needed a DEC Alpha - and not a PC, where it would have found more users and cheaper hardware.
Apple tried it with Dylan for mobile and application development, but that never entered the market. The Newton wasn't shipped with Dylan. Lucid tried it with C++/Energize. Sank the company. Harlequin tried it with DylanWorks. CMU tried to develop a Dylan environment. More was tried, but most failed.
Environments like modern IDEs and languages like Wolfram might be the way forward to regain what was lost with the demise of Lisp Machines.
Nope, it turned out the "business" person/people who arranged the contracts for OEM sales of Lucid's Lisp did them as essentially loans, against the OEM's actual sales as I recall, and when they came due Lucid's investors felt that the success of Energize was sufficiently iffy the extra investment was not worth it. Details can be found on Richard Gabriel's web site: http://dreamsongs.com/
In general my take on what happened is somewhat different. It starts from the observation that when the Lisp Machine was developed, there was a great deal to be said for a custom TTL processor laser focused on Lisp. It was a good way to squeeze a lot of performance out of the available technology, pretty much the only way unless you were crazy enough to try to do it in ECL. And people could see the utility of what became the engineering workstation from the success of Xerox's Alto (which added graphics to NLS).
As it became practical to put enough gates on a single chip for a Lisp Machine, it would have taken a great deal of adroitness to make the transition, and that wasn't in the cards. LMI didn't have the capital to do so, in fact, TI bailed them out and invested in them just to keep the company alive so they could do their own gate array Lisp Machine, the TI Explorer. Don't know what happened with TI, but LMI was eventually killed by Canadian politics. Symbolics was very badly managed by then, and continued to make a number of very bad decisions.
And then, going back to Gabriel, there's the whole worse is better thesis. Worse is better seems to have fantastically greater survival characteristics, in fact, nowadays the only wildly successful The Right Thing software ecosystem is Java.... If there's such a strong ... force, if you will, against the approach of Lisp and therefore Lisp Machines, then it's hard to see how they could have survived.
> As it became practical to put enough gates on a single chip for a Lisp Machine, it would have taken a great deal of adroitness to make the transition, and that wasn't in the cards.
TI developed a single-chip microprocessor. The later TI Explorer and the MicroExplorer were based on microprocessor CPUs. DARPA financed it for the 'Compact Lisp Machine'. Symbolics did the same - they redid the CPU as a microprocessor, the Symbolics Ivory. Many Symbolics machines were based on that chip: XL400, XL1200, XL1201, UX400, UX1200, MacIvory 1/2/3 and the NXP1000. Symbolics did three iterations of the CPU and had a full design of a RISC cpu ready.
Tagged machines are interesting. There have been some good ones, most notably the Burroughs machines. What killed them was the triumph of C, which wants a big flat address space, and the triumph of UNIX/Linux, which wants a vanilla CPU. A tagged machine works best with languages, compilers, and operating systems which use the tags properly. A whole specialized ecosystem is needed, and the motivation for it is weak.
Even the segmentation features in IA-32 were never used much. There's hardware intended to allow calls across protection boundaries in a controlled way. That stuff was left out of AMD-64, and is now almost forgotten.
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.
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.
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.
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)))))
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
In one of K. Reti's videos there's a blend of stack traces of Lisp and C code. What makes that possible?
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.
And of course there was Gyro's Zeta-C compiler, with an interactive C listener.
Does a Lisp CPU make sense? Economically not, since there is no market for it and no innovation driver. You have seen what happened to Java CPUs...
Technically? Could be. Instructions were probably a lot smaller. Memory would be tagged. The CPU would know more about data structures (which in many cases would get rid of buffer overflow exploits).
Generally compiled Lisp runs quite nicely on 64bit Haswell machines.
These days I really feel like I/O is most often my bottleneck, not CPU execution. That said, when I was doing things in Java a lot that I should have been doing in C/C++ (or something like Rust now) I fought with the garbage collector and the latencies it introduced.
That's what we all thought in those days but Pat Solvobarro killed it by using the MMU on a Sun Machine to implement a write barrier.
I don't know how great that is these days (since you get a fault and a cache miss) but the principle was that the conventional hardware could get better faster than the specialized hardware could, and so general would overwhelm any local advantages of the specific.
ARM used to have some ISA extensions for directly-executing JVM bytecodes, but it's deprecated. An optimizing JIT compiler gets much better results.
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-Semiconducto...
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.
source http://www.vrworld.com/2011/02/21/why-nvidiae28099s-tegra-3-...
source http://www.edn.com/electronics-blogs/systems-interface/44199...
Programs like cinebench or linpack are used to to test top-end performance. A lot of things factor into these benchmarks, but SIMD, cache, and data throughput factor very heavily into them. This is why Sunway BlueLight supercomputer (a PetaFLOP computer) uses an Alpha design from around 1997 paired with a very large SIMD. The old core was "fast enough" to keep the SIMD units flowing.
When it comes to branch prediction, the techniques are well-known. The 13-stage A8 supposedly has 95% branch prediction rates (http://www.ti.com.cn/cn/lit/wp/spry112a/spry112a.pdf), so I wouldn't say that is an issue (except to say that x86 decoding is much more complex and usually adds several extra stages to the pipeline which requires more sophisticated prediction hardware along with the associated costs).
As far as prefetching go, the contract is basically that the programmer puts related data close together and the computer fetches the nearby data. The bigger the caches, the better chances of hitting. This is why lisp's pervasive use of linked lists can be problematic when compared to arrays (in theory) and why a naive b-tree implementation can be less performant than expected.
Adding cache takes die and power. When Intel tries for low power, one of the first things it does is cut the cache size. IBM did something very interesting on this front when they used onboard eDRAM for cache (along with some fancy refresh logic to deal with persistence problems) because it was much more dense allowing more cache per chip (32MB L3 at 45nm).
The problem is less list vs. array in Lisp. Both tend to get allocated nearby or a copying/compacting GC will move them so. The problem is more that lists and arrays in Lisp usually point to data. For very few data types they will contain the data (fixnums, characters). Thus a list/array is often a list/array of pointers to data...
I paid for my 1108 by selling a simple expert system tool for $5000 per machine license. While I felt good making my toy sort of cost free for my company, I didn't feel great about selling something simple for $5000.
I continue to be surprised how much of my consulting work in the last 15 years has used a Lisp (either Common Lisp or Clojure). From my perspective, Lisp languages are thriving.
It looks like Azul has basically given up on their custom hardware, I guess? They found a way to make their GC work on commodity x86.
They did indeed ditch their custom hardware: the appliances were excellent, but not really a competitive proposition compared to "buy a cluster of commodity hardware and if one JVM instance goes for a coffee break, treat it as any other transient failure and route requests to another host."
http://www.lowrisc.org/downloads/lowRISC-memo-2014-001.pdf
As I understand it its proposed use is for security reasons, for preventing hostile memory corruption. But I imagine it could also be used for the kind of type and GC purposes that tagging in the Lisp machines was used for?
It's intended primarily for security, essentially to allow hacks to let our current C type code bases to run ... less insecurely. It was proposed to allow the 2 tag bits to be used for other things like type and GC tagging, which is why I'm personally interested in it.
By comparison, the CADR Lisp machine had a 32 bit word size, with 8 bits used for tags, and the remaining 24 bits used for immediate data or as a word addressed pointer. The lowRISC project proposes to add tag bits taken from other regions of memory that are fetched into a tag cache, and promoted as additional bits in the L2 and L1 caches and above. So starting with the L2 cache words will be internally 66 bits long.
Would it actually still make sense to make a dedicated design?
"A new paradigm is always a tough sell, and ... would not prove a financial success"
https://www.youtube.com/watch?v=qxM9pMEnJQ0&index=3&list=PLO...
To me Lisp still hold the number 1.5 (sic) place in programming languages top list. It still is a magnificent thing, combining minimal and abstract traits so well.
There are however things which can't be affected by packages, without a total rewrite (like Shen). Things like parametric-typing, and adding synergistic mechanisms with define-compiler-macro and inbuilt optimizations, would be extremely useful.
The Lisp Machine is what happens when a group of engineers cannot distinguish vision from tunnel-vision. Probably because they have lived far too long in the self-congratulatory universe of Lisp, and believe in the divinity of S-expressions and CONS cells, never once questioning the foundations of their faith.
This all happened over 30 years ago. Intel didn't have a hegemony in CPUs. There was funding available to try new things in hardware. Some of it failed, some of it succeeded.
Thirty years from now we will be rolling in laughter at the absurdity of so many of today's startups.