That’s A Lisp Machine In Your Pocket

43 Comments

Computer languages have always advanced faster than computer hardware. Case in point: we’re just now getting CPU instructions for JavaScript floating point numbers. The 1970s and 80s wasn’t the garbage fire of JavaScript instructions in silicon, instead they were all about garbage collection. Lisp machines were CPUs designed to run Lisp efficiently. They were great, until the companies responsible realized you had to sell a product to stay in business. Combine an interesting architecture with rarity and historical interest, and you have a centerpiece of any retrocomputing enthusiasts collection. Yes, we all want a Lisp machine.

Now there’s an interesting project on CrowdSupply that will make that possible. It’s the MakerLisp Machine, a credit card-sized computer that runs bare-metal Lisp.

We first saw the MakerLisp Machine in its raw prototype form at VCF West last August, and it was in a very, very raw state. That was just a prototype, though, but the MakerLisp business card-sized computer still features the Zilog eZ80 running at 50MHz. The basic board includes a USB port for a serial connection and a microSD card slot for storage. It boots into a Lisp environment, and you don’t even have to use a NuBus card. We’re living in the future here.

Because this is a credit card-sized computer, there is of course an expansion board that breaks everything out, including the GPIOs. Being a Z80, you’re also going to get CP/M support, but the real story here is Lisp, in your pocket.

43 thoughts on “That’s A Lisp Machine In Your Pocket”

    5. I fail to understand the confusion. Bare-metal LISP means its running LISP on the processor AS the operating system, not UNDER an operating system. LISP on Linux has the Linux kernel as its supporting OS. For bare-metal LISP, it has its own serial, SD-card, etc drivers.

      And yes, by that definition, the ZX Spectrum does run bare-metal BASIC.

      Report comment
      Reply

      1. no, “bare metal” means there is nothing in between. Putting an interpreter “in between” and calling that “bare metal” is just another jargon corruption that has become all to common in the computing field. This sort of thing tends to happen when a programmer wannabe tries to justify what they have done rather than understand what is already in place and work within that framework.

        “fire?! no this is PARC and I’ve just invented it”…

        Report comment
        Reply

          1. A friend had a spectrum emulator that he wrapped up in some other code* and ran on bare metal. That does not make it a bare-metal Spectrum – even though it quite happily sits there letting you play Manic Miner – it makes it a bare-metal Spectrum emulator. It’s a subtle (but important) difference.

            * The code ran on bare metal had a some drivers (Notably screen, serial port and timer) and the only hardware resource manager it had was a very simple sbrk based malloc and free. I’d argue that it wasn’t an OS.

            Report comment

          2. “No, really.. the LISP environment is running on bare-metal because there’s no OS under it.”…

            Ok, the “LISP environment” might be running on “bare-metal” but the programs that you run in the environment (written in LISP) are only able to be executed by the “environment”. So this is ***NOT*** a “bare-metal LISP machine”. There is a software layer between the LISP programs and the actual hardware.

            Executing an 8086 machine code program under MSDOS is infinitely more “bare-metal” than this “LISP machine”

            Report comment

          1. That’s why this discussion wouldn’t have blossomed into what it is, if an FPGA had been made into a LISP CPU. With that being said all those other layers above the “bare-metal” is what makes everything more useful…like a LISP OS. ;-)

            Report comment

  7. IMS the original Symbolics LISP machines had a microcoded instruction set optimized for LISP and even had some functions in hardware.

    Today that could be pulled off with a FPGA and would be a worthwhile project to attempt for the skilled maker.

    However this thing isn’t even close, it’s just a run of the mill 8 bit micro running a run of the mill LISP interpreter. Nothing to brag about.

    Report comment
    Reply

    1. I’d say it’s interesting in its own right – but it is a little misleading to explain that Lisp machines were designed to run Lisp efficiently – and then go on to discuss a project that is, as you say, a Lisp interpreter on a normal Micro. And it would be nice to have some more details about the interpreter, which, to me, is probably the more interesting bit.

      (Note: All I know about Lisp (And Scheme – although all I could find about this is that it appears to be a dialect called “Skim”) could be written on the back of a postage stamp with a JCB)

      Report comment
      Reply

      1. It’s an interpreter with a JIT engine that cracks open Lisp expressions into small primitives to execute code in an SECD-style virtual machine. Every Lisp expression is first expanded into a few VM instructions, which are themselves just implemented as short routines (in C, everything is in standard C89/C90), and then the list of VM instructions is executed, one at a time, until it’s time to crack the next bit of Lisp. It’s faster than most Lisp interpreters, not as fast as the most capable Lisp compilers. When I release the product the code will be out there so you will be able to see exactly what’s happening. There are a couple of good tricks, but mostly you can think of it as JIT’ing to threaded code. It’s got the Scheme execution model, but spelling and semantics of Common Lisp primitive functions, and Common Lisp-style low-level macros.

        Report comment
        Reply

  8. To me, “:Lisp on Bare Metal” means, as others have noted, that Lisp itself is the OS and environment, and yes, this product is meant to be very similar in nature, in its look and feel, to the Basic language console computers like the Sinclair, Tandy Color Computer, and so many others from that era – except that the language which is the system is a dialect of Lisp. The eZ80 is a later (2003), modern, pipelined, re-implementation and extension of the Z80, by Zilog – it’s binary compatible with the Z80, but also has “big” mode bits, so that address and data can be 24 bits – and this allows an address space of 16 M. which is something that gives a fairly capable and complete Lisp system enough room to run. So the eZ80 at 50 MHz, with a large amount of zero-wait-state SRAM available, turns out to be a good choice for a Lisp console computer. And then of course there’s the possibility of CP/M on the machine, too. There’s a little bit of information about the machine both on the website http://cpmaker.com (the company name is meant to suggest CP/M for makers), and also on the crowd-funding page, and more information will be coming through the Crowd Supply offering soon.

    Yes there are many very good Linux on small board, IOT-focused products, but this is a slightly different tack. When you don’t have to support all of Linux and all of the layers of software on top of that, a simpler processor and computer architecture can give your system-is-the-language solution and the applications you develop, direct, immediate access to the underlying machine, like console computers, but also like PCs running DOS, and the whole feel of the machine is pretty snappy, very low latency. Without virtual memory and cache effects, which can be a huge tax on applications, the performance is better than you might expect from a 50 MHz processor.

    Anyhow, the machine is meant to recapture the look and feel of computers of that era, some of the same design aesthetics, but re-implemented in (more) modern hardware fabric. It’s not a replacement for Raspberry Pi boards and the like, but if it strikes a chord with you, please give it a look :)

    Report comment
    Reply

      1. > (cat ‘benchtak.l)
        (include ‘)

        (define benchtak
        (lambda ()

        (define tak
        (lambda (x y z)
        (if ( (benchtak)
        11:24:54
        11:26:16
        > (benchtak)
        11:27:31
        11:28:52

        That’s 81 seconds for 10 iterations, both times, or about 8.1 seconds for one (tak 18 12 6), self-measured like this.

        MakerLisp JITs to SECD virtual machine instructions, so we have a kind of threaded primitive routine thing going on, it gets pretty good performance without creating compiled machine code directly. Many of the functions and macros in MakerLisp are loaded on demand from the SD card, so the start-up time includes both JIT time, which is pretty fast, and also SD card file load time. But on a benchmark like this, amortized over all the executions, the start-up time doesn’t impact us much.

        Here’s what the tak function looks like after it has run all paths of itself once:

        (#address (x y z) (GET20 GET10 LESS SELECT (EVALC (GET10 GET20 QUOTE 1 GET00 SUB GETB #address APPLY) EVALC (GET20 GET00 QUOTE 1 GET10 SUB GETB #address APPLY) EVALC (GET00 GET10 QUOTE 1 GET20 SUB GETB #address APPLY) GETB #address APPLY) (GET00)))

        I hope this sheds some light. I’m pretty busy today, so I don’t have time to put up a lot of benchmark results, but I have run most of those benchmarks on that page over the years as I refined the execution model of this Lisp. Thanks for your question !

        Report comment
        Reply

          1. Trying again:

            “(include ‘)

            (define benchtak
            (lambda ()

            (define tak
            (lambda (x y z)
            (if (< y x)
            (tak (tak (- x 1) y z)
            (tak (- y 1) z x)
            (tak (- z 1) x y))
            z)))

            (define looptak
            (lambda (n)
            (if (zerop n)
            n
            (progn
            (tak 18 12 6)
            (looptak (- n 1))))))

            (nlprint (time))
            (looptak 10)
            (nlprint (time))))"

            Report comment

          1. Ah, thanks. I was already wondering what you might have meant by FAST.
            For comparison, a Banana Pi sporting SBCL is about 500 times as fast:
            –88–

            A Dell M6800 (a few years old, but still a fairly capable machine, one might actually consider for developing software – Lisp or otherwise – on, is about 25000 (twenty-five THOUSAND) times faster:
            –8 (time (dotimes (i 10000) (tak 18 12 6)))
            Evaluation took:
            3.482 seconds of real time
            3.482035 seconds of total run time (3.481759 user, 0.000276 system)
            100.00% CPU
            9,379,410,406 processor cycles
            0 bytes consed

            NIL
            –>8–
            FWIW, the quoted 8.1s are about wice as long as the benchmark took on an original Symbolics LM-2 or about as fast as a PDP 11/780 with Franz Lisp was in the seventies. Why, oh why, would one chose a Z80 for a Lisp machine?

            Report comment

          2. I think I am turning the question around – I have not so much chosen a Z80, on which to run Lisp, as I have picked this particular (e)Z80 at 50 MHz as a chip around which to to build a modern hardware, vintage-styled software machine, economically and efficiently, and the micro-controller and ease of use in an Arduino-like learning environment is a big part of the equation. THEN, what language do I want to use ? Well, Lisp can be immediate and practical on such bare metal, and this implementation is geared for that. If you look at the uLisp benchmarks, tak is quoted at 49 seconds on an AtMega at 16 MHz. This machine runs tak a little more than 6 times faster. A factor of 3 is due to clock frequency, most likely, and a factor of two is the combination of the JIT Lisp interpreter and the performance characteristics of the eZ80 and this hardware.

            The chip was chosen because it is capable, efficient, and inexpensive, the same reasons people choose their other favorite micro-controllers. But this chip sort of has a foot in both the micro-controller world of today and the traditional microprocessor world. Besides the flash memory for code, it also has an external memory bus for both code and data, and uses the classic Microprocessor (Intel/Zilog) bus interfaces. It’s not Arduino, it’s not Raspberry Pi, it’s kind of in the middle. It’s 1986-1988, personal computer performance-wise, 2003 CPU architectural efficiency-wise, and competitive, price-wise, with today’s micro-controllers.

            So the point is not so much to recreate or rival the Lisp Machines of old, but to build a different mousetrap for computer science education and personal use, and I have chosen to provide a Lisp as part of that toolkit, and as part of the approach. But I think this machine may be good for lots of things, and I will support CP/M and CP/M C language development as well.

            I aim to develop an open platform. All the schematics and code will be posted. If people find it practical and fun, that’s the goal. Big iron for number crunching, it’s not, but I hope it will be enjoyable and effective in the uses people find for it.

            It’s not so much that the machine is there to run Lisp, but I think the right kind of Lisp implementation can make the most of the machine. Thanks for the conversation !

            Report comment

  10. I’d like to see someone make a TI GPL CPU with an FPGA. Texas Instruments intended to do that for the 99-4 but was having problems, so they shoehorned in a modified version of their 16 bit 9900. But rather than rewriting GPL in 9900 machine code they wrote an interpreter and to make things worse, they wrote TI BASIC so that it has to first be interpreted to GPL then to 9900 code. TI Extended BASIC is in 9900 code.

    So a GPL CPU would be an interesting curiosity, unless someone was building a super duper mega 99-4/A compatible computer.

    Report comment
    Reply

  11. Seems like the point was to build a vintage/retro machine that could do some good modern stuff that, in the vintage day would have weighed down a table, but now could fit in your pocket. In the 80’s there were ads like this all the time a la “A lisp machine the size of a credit card” that title by itself is a vintage throw back. Of COURSE you could run lisp on a raspberry pi which is also the size of a credit card, but THIS is a LISP machine, not an emulator.

    I’m confused by comments that someone could DO anything this SBC could do in software (X)* faster, but who G.A.S.?

    If YOU built a better LISP SBC then tell us about it otherwise, rather than distract about how it isn’t a supercomputer on a stamp, talk about what the card does or just gaze in a bit of awe…. It looks like fun for what it does. It isn’t for everyone and doesn’t need to be.

    Report comment
    Reply

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.