Announcing PilMCU, the Lisp Machine on a Chip(mail-archive.com)
mail-archive.com
Announcing PilMCU, the Lisp Machine on a Chip
http://www.mail-archive.com/[email protected]/msg04823.html
11 comments
where's the kickstarter page? I want a few of those.
I've heard a few people suggest that with single core performance stagnating we may see more ASICs. I admit I'm skeptical, but this line of development does seem worth exploring.
Can it run emacs?
I think emacs needs a POSIX-like environment to run inside. (I think this is roughly correct even though I don't really understand what it means.)
Do you have a diagram with the design? Something to amuse people even more? ;)
It's a Verilog design for a new chip. But it doesn't seem to be open, at least I can't find the source anywhere.
It seems they're interested in launching this is a commercial (or crowd-funded) hardware product.
It seems they're interested in launching this is a commercial (or crowd-funded) hardware product.
No links to the actual thing?
Here's more information about the actual thing...
http://www.mail-archive.com/[email protected]/msg0483...
...But still no links to source. (As I understand it, this hardware design is expressed in the form of verilog source code.)
http://www.mail-archive.com/[email protected]/msg0483...
...But still no links to source. (As I understand it, this hardware design is expressed in the form of verilog source code.)
I wonder if this is related: http://picolisp.com/wiki/?home
That's PicoLisp, which you can apt-get install.
This is PilMCU, a hardware design which apparently runs PicoLisp.
Right now, only the design exists, not physical hardware. But you can run the design in a simulator. ...Something, something, verilog. (This is not my area of expertise.)
[Edit: the devs use the Icarus verilog compiler to provide simulations. It's available in Debian repositories.]
This is PilMCU, a hardware design which apparently runs PicoLisp.
Right now, only the design exists, not physical hardware. But you can run the design in a simulator. ...Something, something, verilog. (This is not my area of expertise.)
[Edit: the devs use the Icarus verilog compiler to provide simulations. It's available in Debian repositories.]
I'd really like to see the full ISA, etc for the chip. A few years ago, I was doing research on building a byte code based vm after working through Peter Michaux "Scheme From Scratch" http://peter.michaux.ca/articles/scheme-from-scratch-introdu.... (I highly recommend running through his code, but do the GC earlier, it's easier to get it from the start than to try to add it.) I couldn't find anything online listing the kinds of instructions you'd want in a lisp chip.
there's something similar done before, Lisp machines in FPGA [0] [1].
[0] http://www.frank-buss.de/lispcpu/ [1] http://www.aviduratas.de/lisp/lispmfpga/
[0] http://www.frank-buss.de/lispcpu/ [1] http://www.aviduratas.de/lisp/lispmfpga/
There are a few PDFs with the original Lisp Machine ISA, if I am not mistaken.
I will have a look when back at home.
I will have a look when back at home.
The original Lisp Machines were conventional machines with hardware features like tagged pointers that let them execute Lisp more quickly. I'm under the impression that the machine in the article is far more radical.
They were not that conventional. The first Lisp Machines were using micro-coded processors with special instruction sets tailored for compiled and interpreted Lisp.
* tagged architecture
* stack-oriented architecture with large stack buffers
* hardware assisted GC
* support for generic Lisp operators. For example a simple + operator.
* support for basic Lisp data structures like cons cells
The result is that Lisp programs compile to very compact machine code.
* tagged architecture
* stack-oriented architecture with large stack buffers
* hardware assisted GC
* support for generic Lisp operators. For example a simple + operator.
* support for basic Lisp data structures like cons cells
The result is that Lisp programs compile to very compact machine code.
I'm guessing that by "far more radical" the GP meant "directly evals s-expressions." Especially since, IIRC, that's how PicoLisp works. I don't think there is much benefit to that approach over simpler register machines, but it's an interesting idea at least.
If you mean the LMI Lisp machine: http://bitsavers.trailing-edge.com/pdf/lmi/
There's significantly more for the TI Explorer Lisp machine: http://bitsavers.trailing-edge.com/pdf/ti/explorer/
And even more for Symbolics: http://bitsavers.trailing-edge.com/pdf/symbolics/
Xerox did a Lisp machine line: http://bitsavers.trailing-edge.com/pdf/xerox/interlisp/
There's a working emulator for the MIT CADR: http://www.unlambda.com/cadr/index.html
And you can of course run Genera in an emulator: http://www.unlambda.com/download/genera/
There's a semi working TI explorer emu: http://www.unlambda.com/lispm/
There's significantly more for the TI Explorer Lisp machine: http://bitsavers.trailing-edge.com/pdf/ti/explorer/
And even more for Symbolics: http://bitsavers.trailing-edge.com/pdf/symbolics/
Xerox did a Lisp machine line: http://bitsavers.trailing-edge.com/pdf/xerox/interlisp/
There's a working emulator for the MIT CADR: http://www.unlambda.com/cadr/index.html
And you can of course run Genera in an emulator: http://www.unlambda.com/download/genera/
There's a semi working TI explorer emu: http://www.unlambda.com/lispm/
There is an emulator for the Xerox machines.
There is a working TI explorer emulator: http://www.unlambda.com/index.php?n=Main.Meroko
An updated version of the MIT CADR emulator: http://trac.common-lisp.net/mit-cadr/browser/
Source trees for the LMI and TI machines are also on the web.
There is a working TI explorer emulator: http://www.unlambda.com/index.php?n=Main.Meroko
An updated version of the MIT CADR emulator: http://trac.common-lisp.net/mit-cadr/browser/
Source trees for the LMI and TI machines are also on the web.
> Source trees for the LMI and TI machines are also on the web.
Without usable licenses.
Without usable licenses.
I have been told that TI have given formal permission to redistribute their code, I will chase up the person who got hold of it to get it properly labelled.
The LMI stuff is more interesting to me as it is complete, I'm still a fair bit of work away from being able to build it though. I have spoken with RG about it but we didn't discuss the licence.
The LMI stuff is more interesting to me as it is complete, I'm still a fair bit of work away from being able to build it though. I have spoken with RG about it but we didn't discuss the licence.
Texas Instruments sold their computer systems division at the start of the 1990s. I've read that that sale did not include the Explorer copyrights.
At the start of 2011 I got in touch with Robby Holland, then the head of TI's patent licensing division. Holland could not find anything about the computer systems division, or anything about the sale, or whether they owned the rights anymore. They did not have any of the project materials on hand. Holland said he would have someone look into the archives. When I tried to get in touch with him a few months later Holland was no longer with Texas Instruments.
At the start of 2011 I got in touch with Robby Holland, then the head of TI's patent licensing division. Holland could not find anything about the computer systems division, or anything about the sale, or whether they owned the rights anymore. They did not have any of the project materials on hand. Holland said he would have someone look into the archives. When I tried to get in touch with him a few months later Holland was no longer with Texas Instruments.
Texas Instruments closed their Lisp Machine activities in 1990. Nobody picked that up.
There is an extremely large amount of TI Explorer code with lots of later stuff written by TI:
https://archive.org/details/ti-explorer
No usable license so far.
https://archive.org/details/ti-explorer
No usable license so far.
Yes, that is the stuff that I have been told has been released by TI. I will try to get a proper licence added to it.
The microcode sources are missing and one of the files for NFS is truncated.
The microcode sources are missing and one of the files for NFS is truncated.
Yes that was it.
So this is something where the hardware is executing something that actually looks like LISP sort of like the Reduceron does with Haskell?
Is verilog design small enough to put on an FPGA?
FPGAs are the only context in which I've ever encountered Verilog, so I'm gonna say yes?
Verilog is a hardware description language. You describe the hardware connections, sometimes with high level constructs like "for" loops, sometimes by just describing the gates themselves. In a sense, it is similar to HTML describing a web page, but with higher level constructs available like loops. So maybe HTML with a templating engine is a closer analogy.
For simulation, you compile verilog with a software tool into something executable by a VM or natively. This is heavily event based in execution, with events being edge transitions (a signal going from 0->1 or 1->0) occuring at specific times--for most (but not all) cases.
For producing something usable by an FPGA or a foundry for an ASIC, instead of compiling you synthesize. Different tool. Synthesis is the process of taking higher level hardware descriptions and outputing the lower level descriptions usually called a netlist. It's akin to translating C into assembly for example.
Device specific tools can take that netlist and create a bitstream for configuring an FPGA, or the foundry can take that netlist and go through a process called "physical synthesis" which takes the netlist and chooses from the foundry's library the components that will work best for that netlist to operate at speed, figure out where to place them on the die, and insert buffers as needed.
What the GP was asking: is this design small enough to fit in an FPGA. This question is orthogonal to the language used to describe the hardware.
I'd say they answer is yes, depending on the FPGA you choose. Some FPGAs are pretty high capacity these days, and even fast.
For simulation, you compile verilog with a software tool into something executable by a VM or natively. This is heavily event based in execution, with events being edge transitions (a signal going from 0->1 or 1->0) occuring at specific times--for most (but not all) cases.
For producing something usable by an FPGA or a foundry for an ASIC, instead of compiling you synthesize. Different tool. Synthesis is the process of taking higher level hardware descriptions and outputing the lower level descriptions usually called a netlist. It's akin to translating C into assembly for example.
Device specific tools can take that netlist and create a bitstream for configuring an FPGA, or the foundry can take that netlist and go through a process called "physical synthesis" which takes the netlist and chooses from the foundry's library the components that will work best for that netlist to operate at speed, figure out where to place them on the die, and insert buffers as needed.
What the GP was asking: is this design small enough to fit in an FPGA. This question is orthogonal to the language used to describe the hardware.
I'd say they answer is yes, depending on the FPGA you choose. Some FPGAs are pretty high capacity these days, and even fast.
At some HN users' request, I started a Verilog guide for software engineers here: https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for...
Enjoy (improvements and comments welcome).
Enjoy (improvements and comments welcome).
Your CPU (and likely >90% of the rest of your hardware) is designed in Verilog.
Talking about Lisp machines. I don't know much about these things but I was thinking about them recently when Hewlett Packard announced its so-called Machine^1. They want to build a new kind of OS for it, but wouldn't a Lisp machine just do?
[1] http://www8.hp.com/hpnext/posts/discover-day-two-future-now-...
[1] http://www8.hp.com/hpnext/posts/discover-day-two-future-now-...
Where is the verilog source?
There's no indication of hardware support for garbage collection. It would probably be more useful to have tag bits to support GC than a LISP-oriented instruction set, especially if it allowed concurrent GC.