Oh boy! I've been thinking of something like this for a while. What is the low-hanging fruit here, in the sense of, what applications might we do faster/cheaper/better in hardware like this, than can be done otherwise?
The idea of pilog in hardware excites me too ... maybe time to go back and dust off old 1980s Fifth Generation Computer Systems project application ideas - http://en.wikipedia.org/wiki/Fifth_generation_computer Maybe some cool application that can be done better now with pilog in hardware than could be done otherwise. Same for the old lisp-machine/Symbolics applications, I wonder if there is anything useful from Symbolics' experience, in retrospect? The Fifth Generation Computer project was considered a failure but seems to be relevant to to picolisp (and pilog) in hardware. It would be really cool if picolisp in hardware ends up accomplishing things that caused Symbolics Inc and The Fifth Generation Computer Systems project to stumble. I expect this to be the case. Doug -------------------------------------------- On Fri, 9/19/14, Alexander Burger <a...@software-lab.de> wrote: Subject: Announce: PicoLisp in Hardware (PilMCU) To: picolisp@software-lab.de Date: Friday, September 19, 2014, 4:39 AM Hello List, we are proud to announce PilMCU, the Lisp Machine on a Chip! :) We, that is George Orais (who persuaded me into the project) and me. Georg built the actual machine in Verilog, and I did the changes and extensions to PicoLisp. PilMCU is an implementation of 64-bit PicoLisp directly in hardware. A truly minimalistic system. PicoLisp is both the machine language and the operating system: * Memory management is trivial, just the Lisp heap and the stack * The built-in database is extended to hold a "file system" * One SSD per database file for mass storage * "Processes" run as tasks and coroutines * Events (timing and interrupts) via a 'wait' instruction * Complex I/O protocols are delegated to peripheral chips The final hardware can be very lightweight. Low transistor count and power consumption. No overhead for an OS. It is conceivable for a later stage to put many interconnected CPUs on a single chip. At present, we have it running in the Verilog simulator, and in an emulator (adaption of the PicoLisp 'emu' architecture). How shall we proceed? We need investors (or crowdfunding) to polish, manufacture and distribute the real thing. We imagine something in the line of an "Embedded Lisp Machine" or a "Lisp Machine Kit". Perhaps for home brewing, educational institutions and/or robotics research? Is anybody interested -- or knows people who are? For the fun of it, here is a sample session: $ make mcu && vvp -M. -mtty mcu # Build and start Verilog engine : $ make emu && ./emu ssd@ ssdA # Or: Build and start the emulator : Now we are in an environment equivalent to the standard 'pil +'. The database is open on two image files for two SSD drives. Besides the normal, full DB functionality : (show *DB) {1} (7 . {17}) T ({2} {20} {56} {64} {105} {146}) -> {1} you can call 'in', 'out', 'load' and 'rm' on files which are maintained in external symbols: : (dir) -> ("lib.l" "lib/") : (dir "lib") -> ("btree.l" "db.l" "dbg.l" "misc.l" "pilog.l" "sq.l") : (in "lib/db.l" (read)) -> (de dbs Lst (default *Dbs (_dbs 1))) : (out "foo/bar/mumble.l" (prinl "Hello world")) -> "Hello world" : (in "foo/bar/mumble.l" (line)) -> ("H" "e" "l" "l" "o" " " "w" "o" "r" "l" "d") : (dir "foo/bar") -> ("mumble.l") : (cd "foo/bar") -> "foo/bar/" : (dir) -> ("mumble.l") : (pwd) -> "foo/bar/" Path names are stored as a normal B-Tree in the DB root: : (scan) "foo/bar/mumble.l" {172} "lib.l" {2} "lib/btree.l" {64} "lib/db.l" {105} "lib/dbg.l" {20} "lib/misc.l" {56} "lib/pilog.l" {146} "lib/sq.l" {166} They point to external symbols, like {2} for "lib.l". (load '{2}) is equivalent to (load "lib.l") The values of these symbols hold the file size: : (show '{2}) {2} 12401 -> {2} They should not have properties, and store the raw file data invisibly in dynamically maintained DB blocks. The rest of the system is standard PicoLisp :) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
