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

Reply via email to