For those of you unfamiliar with the general world of Lisp machines, they are, as their name implies, workstations entirely designed around the Lisp programming language. That doesn't just mean using conventional processors with a Lisp runtime either: these devices are built to run Lisp from the silicon up with specific hardware support. (Some of these systems could also run Prolog, my personal favourite AI-adjacent language. We'll play with a surprising small Prolog implementation in a future article.) They existed in highly technical environments as workhorses of the first wave of AI hysteria (you crazy kids today with your LLMs) for applications like natural language processing and expert systems. The genre more-or-less flourished from the end of the 1970s to the early 1990s and included some of the first systems to implement advances like bitmapped displays, networking and pointer devices. In turn, those unusual capabilities caused them to also develop distinctive user interfaces for their unique feature set, years before today's GUI and keyboard conventions we almost unconsciously take for granted were even conceived of. Working with a Lisp machine can be a remarkably different user experience from modern computing and the occasionally jarring nature of those differences isn't something present-day emulators fully capture.
Unfortunately, their rarity also makes them the whitest of white elephants sometimes. Besides what I had to do to get it working properly to start with, the hard drive started timing out and it randomly froze during boot or shortly afterwards. (There was also the matter of me never finishing its setup, let alone getting it networked.) I'm not letting this benighted thing die on me after all I've put into it — it's time for a Refurb Weekend.
The MacIvory line hails from Symbolics, probably the longest lived Lisp-specific machine maker (not counting Texas Instruments, which of course remains very much in business and never specialized purely in Lisp hardware). Symbolics came out of an acrimonious split in the Artificial Intelligence Laboratory at the Massachusetts Institute of Technology where the first Lisp machine was built, the so-called "CONS" machine (named after the list-building primitive). Developed initially by programmers Richard Greenblatt and Tom Knight, the CONS machine and all of its descendants use varieties of a machine-specific dialect reasonably called Lisp Machine Lisp, descended from Project MAC's Maclisp, that added object-oriented ("Flavors") and system programming features. The CONS machine's key advances included incremental garbage collection and parallel runtime type evaluation (the machine was a tagged architecture) that with minor changes evolved into the "CADR" machine (the Lisp primitive to take the second item of a list). This is a 1979 example from the recent sale of Paul Allen's personal machines:
The CADRs in particular became very popular with the AI Lab hacking community — Steven Levy in Hackers: Heroes of the Computer Revolution called the Lisp machines "a true hacker's machine" — and started attracting substantial outside attention, even DARPA funding. Meanwhile, Russell Noftsker, hired originally by Marvin Minsky in 1965 as the administrator of the Project MAC AI Group that spun off into the AI Lab, had left in 1973 to form his own company (Pertron Controls, Inc.), although he still maintained personal connections at the Lab. Unfortunately, the contentiousness of what transpired next makes the various extant personal accounts unreliable. What is fairly certain was that in 1979 Noftsker and Richard Greenblatt discussed commercializing the technology but could not come to an agreement: Noftsker intended to create a more typical startup using venture capital that would then have ownership stakes, whereas Greenblatt believed growing customer interest was sufficient for advance orders to make a company self-sustaining and keep it in the hands of its founders.
The resulting dispute was so fraught that the lab split into two factions, but most supported Noftsker's approach. Noftsker notably agreed to give Greenblatt a year's head start, though with most of the departing AI Lab denizens moving full-time to Noftsker's new venture, Greenblatt's team struggled with development. (Stallman and Minsky were conspicuously not part of either company.) Despite the already existing customer interest Greenblatt had hoped for, eight months later his team still had no commercial product, distressing Control Data Corporation consultant Alexander Jacobson who wanted a Lisp machine for a natural language processing project. Greenblatt's original intentions notwithstanding, Jacobson forced the issue by creating a business plan and board and finding a partner, to which Greenblatt acquiesced. This new company in late 1979 was LISP Machine, Inc., or LMI. On Noftsker's side he made a deal with Patrick Winston, the AI Lab's director at that time, that in return for his staff using MIT facilities, MIT could freely use the software internally that the new company was developing. Noftsker's team incorporated as Symbolics, Inc. in 1980.
The 3600 series did well in its rareified market niche, in no small part due to the relative weakness of LMI's next generation offering, the 1983 LMI-LAMBDA. Unlike the 3600, which was a total revamp, the LAMBDA's Lisp core was largely a hopped-up CADR with cache, faster logic and some architectural improvements. It was notable for its 8088 service processor and its early use of NuBus, the interconnect standard originating with the MIT NuMachine, a 68010-based Unix system ("TRIX," a Unix V7 lookalike that GNU also intially used as a kernel) which Western Digital subsequently licensed for development. (We'll come back to NuBus shortly.) LMI hedged its bets by offering a 68000 option and Unix, which could even run simultaneously with Lisp, but the company only ended up selling around 200 of the LAMBDAs and became so starved for cash that Texas Instruments agreed to license the architecture in return for a 25 percent corporate stake. TI had already purchased the NuMachine rights from Western Digital in 1982 after WD decided not to enter the workstation market, and it updated and merged LAMBDA with its nunew acquisition to create a smaller platform it called the "Low Cost Lisp" system. The LCL CPU (codenamed "Raven") subsequently became the basis of the $52,500+ [$160,000+] TI Explorer workstation in 1984, which I guess was relatively lower cost for a Lisp workstation, though the G-machines were still cheaper.
The 3600s had other advantages over other Lisp vendors as well, in particular establishing an early lead in computer graphics through the Symbolics Graphics Division, also established in 1982 and located in Los Angeles' Westwood district near Hollywood. Early SGD animations generated by a 3600 system appeared on the shipboard displays in Star Trek III in 1984, and as a kid in junior high I remember the 1987 short Stanley and Stella in Breaking the Ice (here is a remastered version from the original director and executive producer) that turned up at a local computer animation festival. I didn't fully understand what a Lisp machine was back then, but I reasoned that if they could do stuff like that then they must be pretty cool. SGD remained in operation into the 1990s, generating the CGI orca in 1993's Free Willy.
During this period Symbolics officially christened their fork of the Lisp machine operating system as Genera, and ZetaLisp as their version of Lisp Machine Lisp. Originally the system software had been copyrighted by MIT and licensed to both LMI and Symbolics, and Noftsker's initial arrangement with Patrick Winston ensured that Symbolics' work could be done on MIT systems and made available to MIT, but Symbolics increasingly believed that the company needed greater control of the software base and in 1981 moved development to their own machines. Although Symbolics kept at least the letter of their arrangement with MIT and other customers by providing nearly all of the source code, customers — including MIT — were not allowed to redistribute it further. This infuriated Richard Stallman, who alleged Symbolics was acting unfairly to prevent their work from being incorporated into LMI's products (as well as, for that matter, TI's), and he determined to independently reimplement Symbolics' improvements in MIT's code base to prevent Symbolics from gaining unilateral control. After two years of doing so, he announced the GNU project in September 1983 and left the AI Lab the following year, and the rest is history.
By 1987 at least three efforts were being made to develop a Lisp-on-a-chip, though only two had any lasting import. LMI had been attempting its own reworked Lisp architecture as the RISC-inspired K-machine for several years, but the company went bankrupt in 1987 before its completion. However, LMI's work indirectly lived on through Texas Instruments, who produced the 553,000-transistor MegaChip (codenamed "Hummingbird") as a further evolution of the CADR/LAMBDA/LCL architecture; TI deployed MegaChip as the core of its new "Compact Lisp Machine," sold as the TI Explorer II. For its part, that same year and also after considerable delay, Symbolics announced their own single-chip Lisp processor with yet another new architecture. Symbolics christened their CPU "Ivory," a 390,000-transistor chip initially fabricated on a 2μm double-level metal CMOS process.
Ivory implements a four-stage pipeline fed by a 32-word (64-instruction) direct-mapped I-cache, itself populated by an autonomous prefetch. The simplest instructions take just a single cycle in each pipeline stage, though the more complex ones may spend several cycles in the execution phase before retirement. Tag and ECC checking are done parallel to the pipeline and in the typical case incur no time penalty. Instead of a conventional D-cache, however, the CPU has a 128-word top-of-stack cache, a 32-word scratch pad acting like a register bank, and a 16-entry translation lookaside buffer. Specialized SIMD/vector instructions accelerate garbage collection (along with other hardware features), database searches and graphical operations, and additional custom hardware also speeds up virtual memory and Lisp calls and returns. A coprocessor interface allows for an optional FPU.
A relatively advanced design for the era, Ivory in its first stepping ("Merlin") was easily twice as fast at the same Lisp code than the L- and G-machines, though fabrication problems meant Symbolics took close to a year getting the first I-machine to market as the VMEbus-based XL400 in 1988. Ivory's development delays ultimately exacted a heavy toll. While Noftsker had pushed for Symbolics to create a "Lisp chip" as early as 1983, the company's board rejected the project and it sat in semiconductor turnaround until around 1985 when design work could resume. Meanwhile, cheaper general-purpose computing was improving at an even faster rate and the performance delta between Lisp machines running Lisp and PCs and Macs running Lisp, though still non-trivial, was shrinking just as rapidly. This phenomenon meant that Lisp machines had to get cheaper to maintain their value proposition: while Moore's law applied equally to Lisp machines as well as x86 and 68K, there were a lot more people working on processor design at Intel and Motorola than there were at Symbolics and TI.
NuBus had its critics for its overengineered nature and it made cards and systems more expensive, but there were many fans as well. Although Steve Jobs had ferociously fought against expansion slots and colour displays as contrary to the Macintosh's nature, his precipitous departure from Apple in 1985 cleared the way for both to be implemented in the Macintosh II. Michael Dhuey and his team selected NuBus due to its plug-and-play nature which fit with Apple's goals of ease of use.
The microExplorer beat Symbolics' competing product by over six months, but in the end Symbolics did basically the same thing as TI: they put an Ivory on a NuBus card, and they sold it in a Mac II. Symbolics had been working on an Ivory card initially for the 68K-based Sony NEWS but the companies could not come to an agreement and the TI-Apple announcement sealed its fate. As announced in October 1988 Symbolics' package system came in more costly at $21,900 [$58,300], in part due to the larger 300MB hard disk it shipped with, but the card itself started at $10,900 [$29,000]. Also like the microExplorer, additional Lisp memory could be added with NuBus RAM cards. Struggling after downsizing their facilities due to sales declines, the MacIvory was a bright spot for the company, which still had a residual following using Genera as a rapid prototyping environment. Symbolics produced a refined version dubbed the MacIvory II and a VMEbus version called the UX400 for SunOS-based Sun-3 and SPARC systems, both in 1989.
Meanwhile, the eighties/nineties "AI winter" set in around 1988 after DARPA's Strategic Computing Initiative slashed new spending on artificial intelligence projects, citing the projects' expense but more importantly a general failure to meet their lofty and ill-defined goal of full machine intelligence. TI, never a Lisp machine specialist to begin with, had already been exploring SPARC as a licensee and quietly ended further development of the MegaChip to concentrate on the new architecture. Their gradual exit eventually left the Lisp market almost entirely to Symbolics, who continued modest Ivory development with process shrinks to 1.2 microns and finally 1 micron, now fabricated by Hewlett-Packard, and increasing its speed factor over the old 3600 line to roughly six times. The fastest Ivories were introduced in the XL1200 large system and UX1200 card in 1990, and the MacIvory III in 1991.
And that, finally, brings us to our problem child. Let's meet the hardware.
When the machine arrived it was utterly DOA, and I was livid at getting a $4500 doorstop. Even an anti-capper like me knew why: this was around the time when problems with classic Mac capacitors (notably 68030 Macs and their contemporaries like the Macintosh Portable) were starting to emerge, and this one was still on its factory caps. I sent it off to a professional to be recapped; this took a couple months and a couple hundred bucks. In the meantime I transplanted the MacIvory card and its half-height hard disk to my spare IIci for analysis. This disk contained System 7.6 and a preconfigured basic Genera 8.3 world. Since I had no install media I did have the presence of mind to try making a dd image of it using my NetBSD Quadra 605, but that turned out to be to no avail because the hard disk was riddled with soft errors. Writing anything to the 7.6 partition would cause it to poop its pants, Disk First Aid got so confused it claimed it wasn't even an HFS volume, and DiskWarrior repeatedly failed writing out a replacement directory on two different hard disks. This seriously called into question the state of the Genera partition as well. I had great difficulty believing the machine had been tested before it was shipped.
As the disk image was basically unrecoverable this meant I'd need to locate Genera CDs to reinstall it, but it also meant I needed to find an external SCSI CD-ROM drive to read them that was also compatible with Genera. As it happens, the MacIvory only supports single-speed (yes, 1x) CD-ROM drives. It took me a couple weeks to track down a working AppleCD 150 (I already had a few CD caddies from my 2x AppleCD 300) and a basic Genera distribution on disc, totalling close to a thousand dollars between them. I got a larger 4GB hard disk, partitioned and formatted it, installed System 7.1 (my preferred version of System 7) and got the basic Genera 8.3 world rebuilt from the CD with the Y2K patch. I don't have any pictures of this process as I did it years ago, but other than loading the Y2K changes and saving the modified world, everything I did was straight out of the thorough Genera 8.3 Software Installation Guide for MacIvory Machines which is on Bitsavers.
At this point and even after very limited use the 640x480 internal video became obviously cramped as a console (remember that real Lisp machine consoles were usually 1100x900 or more) and I wanted to improve its throughput, which is partially limited by how quickly the Mac can service Remote Procedure Calls from the Ivory. Although I put in 64MB of RAM to see if that would help caching, all that really seemed to do was make the initial memory test obnoxiously long. For these additional upgrades I had a number of cards on the shelf and altogether they make four CPUs running together in one case.
Accelerated is where it gets interesting. The 8*24 GC has its own CPU, an AMD Am29000 (#3 of our four on-board CPUs), which is used for fast drawing operations directly to its own video RAM rather than the Mac's CPU pushing pixels over the bus. (It will even accelerate any ordinary 8*24 and 4*8 cards present because they support NuBus block transfers.) The Am29K is a Berkeley RISC chip like the SPARC and implements register windows as well, but unlike SPARC it uses variably sized windows to avoid wasting valuable on-chip resources. On the card it runs at 30MHz (from a 60MHz crystal) with 2MB of VRAM and 64K of SRAM for cache. A CDEV loads the Am29K-optimized "GC QuickDraw" and "GC OS" kernel to the card and then patches QuickDraw calls to redirect to the GC. Apple bragged this accelerated video between five and thirty times, which sounds immediately suspect, but I certainly find it to be a very swift option for '030 Macs and we'll test its throughput soon enough. The Am29000 family was a popular architecture in rasterization applications and embedded systems, and eventually evolved into the basis of the x86-compatible AMD K5, which helped keep the company treading water until the speedy yet technologically unrelated K6 was released.
The trick with acceleration is that the 8•24 GC control panel is extremely finicky. It won't run in 32-bit mode, so now my 64MB of RAM was mostly wasted because I was limited to 8MB in 24-bit mode, and '040 Macs need not apply at all. Although it can run accelerated under 7.5 and 7.6, graphical glitches can occur especially with pull-down menus, so you really must run 7.1. Good thing we've already installed it.
I mentioned that the 3600 series have an on-board 68000 as a service processor, formally termed the Front-End Processor (FEP). As its name implies, the FEP handles the startup console but also manages slower devices during normal operation. (As an interesting point of trivia, 3600 systems could themselves be front end consoles for the Connection Machine CM-2 and CM-2a supercomputers.) I-machines, however, even the large systems, completely dispensed with a discrete FEP and all device management moved to the CPU. On boot the Ivory itself serves as the console, loading a small binary image which today we'd term the bootloader, but it's still called the FEP and still takes the same or similar commands. Strictly speaking, if we treat the Mac as a formal front end, then our PowerCache card would be the real "FEP" since it handles all the peripherals that the MacIvory doesn't. The upshot of all this is that there isn't a CPU #5 on the card; it's all Ivory, all the time.
Eventually the repaired original logic board returned and I transferred everything back. Unfortunately, when I attempted to install the rest of the system, the AppleCD 150 started ejecting every disc I tried to insert and wouldn't mount anything. You guessed it: capacitors. Rehabilitating the optical drive was a bigger job than I could handle and it went off to be recapped too, adding a couple hundred dollars more.
This was the state of the machine as you see it here and the bulk of the money spent. When the AppleCD 150 came back, I made sure it worked and planned to finish the installation "later." As usual "later" didn't happen until a few weeks ago, after I was replacing the spinning hard disks on the Quadra 800 and the Amiga 4000T with ZuluSCSIs and decided to see how the Lisp Mac was faring. It started but froze after around 10 or 15 minutes messing around. In fact, it would freeze even without the MacIvory booted up, and the hard disk was making weird clicking noises.
That got rid of the ominous hard drive noises but it still randomly froze after a few hours, and sometimes after a freeze it wouldn't power back up until I let it sit around for awhile. Considering the sheer number of cards in this system, that particular problem seemed like overheating. I did an unscientific finger test on the PowerCache CPU's heat spreader and found it was quite hot to the touch, and because the card is so close to the power supply it makes it impossible to mount any reasonable heat sink and fan on it. Although there's a fan in the power supply itself which provides case ventilation, and it was clean, working and pushing air, the Am29000 on the 8*24 GC was also uncomfortably hot and so was the Ivory's heatsink, so it probably wasn't enough.
However, this system is also mounted on its side for space-saving reasons. I had it in the "standard" Apple vertical position with the power switch up (same as the Quadra 700) so that I can forcibly power down the system if the Ivory is misbehaving (it can maintain its own state which can even survive reboots), but it's possible things were slipping around as a result too. In particular, the PowerCache CPU board was definitely a bit wiggly.
To test both those theories, I pulled out the system and ran it horizontally with the cover off but everything still installed. If there was a hardware problem unrelated to those two causes, it should have manifested that way, and of course it ran all day like a champ. A quick check with a Snooper board failed to demonstrate any obvious faults.
Unfortunately, the DayStar card is the wrong size and thickness to put on the cache card's clip, and installing immobilizers and shims around it just made airflow worse. Eventually I removed the card and very carefully with a jeweler's screwdriver slightly bent out the first and third rows of the card's pins towards the port's outer edges — if you're going to rely on a friction fit, then by golly make more friction. I'm not sure how much difference this actually made but it did subjectively seem to seat better afterwards.
I thought about replacing the power supply fan with a faster one but it seemed simpler just to add a second case fan. Unfortunately, with everything crammed inside there wasn't a lot of additional space. I still had some 80x80x25mm Arctic F8 fans (2000rpm, 31cfm) left over from when I was putting a fan bank in my mATX Raptor Blackbird, so I grabbed one just to see. To my delight it did fit and sat neatly on top of the RAM sticks with space to clear.
Even that wasn't quite enough to solve the freezes, though now they were definitely less frequent and the system was running stably for longer periods. I was pretty sure heat wasn't the problem anymore because all four CPUs were nice and cool to the touch even after hours of runtime, and all the cards seemed to be staying in place.
After pondering the situation I dimly recalled a problem I had decades ago with the NetBSD IIci where it also got intermittently unstable, and after multiple thrashings with a Snooper card I remembered catching a sag on one of the power supply lines. As a test I replaced the General Electric power supply in this unit with a recapped ASTEC I had sitting on the shelf, and the last remaining hiccups disappeared. I'm not sure why this didn't show up when I was burning it in horizontally, but perhaps it was just marginal enough to only flip out under load. Either way, let's get busy like Arsenio.
Time to resume the Lisp business. I should note that everything here is as of MacIvory Support version 4.2, which to the best of my knowledge is the last version that was released.
The MacIvory support package is split up over several places as deposited by its installer. The main applications are in the MacIvory Applications folder, including Genera, which is the primary bootstrap application. Yes, there's a HyperCard stack in the folder too and we'll look at it later. The poetically-named Breath of Life application is how an initial system is built after installation of the Mac components: it restores an FEP filesystem from CD or tape, creating it first if necessary, and sets up default virtual memory paging files and boot files. If you get hopelessly hosed, you can use it to pave over everything and try to start fresh. Source code in C and libraries for creating your own Ivory-powered applications are included which we might explore in a future entry.
The other major part is in the System Folder. An Ivory folder is created here containing support files and the default namespace which we'll spend some time in (the other Namespace folders are backups I made), along with the main MacIvory CDEV, which the installer oddly places in the Extensions folder but leaves an alias for in Control Panels.
The other channel is the "cold load stream," the lowest level text-based interface to the hardware and in practical terms not unlike hooking up a serial terminal to the Ivory in its FEP capacity. The Mac booter puts this into a window where you can interact with it.
I should parenthetically note that the following screenshots of Genera running on the Mac are tricky to get. My usual Inogeni VGA capture box doesn't like the 75Hz refresh rate and the Genera app traps all the keys when running, including Command, Shift and 3 — except Alt-Tab, which the LiteSwitch app switcher INIT nabs first. The trick, if you can time it right, is to have another app like SimpleText running with no windows visible. As long as the Genera app output is windowed, which it is by default for the FEP and can be configured so for Genera proper, you can then take a screenshot by switching to SimpleText instead. (If the window isn't moveable, Genera will "helpfully" cut off some of its window when backgrounded so you can see mounted desktop drives, but this is exactly what we don't want for a screenshot.)
After loading the Genera world and initializing the basic configuration, the Ivory then switches over to the full environment, but it's also possible to stop automatic boot after the FEP kernel loads if you need to do maintenance work from its prompt.
It's possible to trigger errors or hit race conditions that make the cold load stream come up on the console, even if you were accessing the system remotely. This is rare and can sometimes be recovered from, but if it happens you'll have to do it from the Mac.
The black bar at the bottom would ordinarily be populated with hints as to what key and mouse button sequences do what, though as an artifact of the way we're taking screenshots it remains black on the console (we'll get around this problem in a little bit). In the Genera User's Guide this is called the mouse documentation line.
The lowest part of the screen is the status line or who line, which by default gives the current time (from the Mac), username (no one's logged in yet), the current Lisp package, the process state (here User Input, since it's waiting for us to enter a command), and then any additional status information. Occasionally small horizontal underlines flash through below the text; these indicate certain types of processing are occurring, and are correspondingly called run bars. If a file is open, its name will be displayed along with how much has been read so far and a line indicator below that.
On smaller screens, larger fonts aren't used and the screen layout becomes denser, so you really want as big a framebuffer as you can get. With Moveable Screen set in the Genera app as we did here for screenshot purposes, you can move the entire Lisp window around and resize it, but as a practical matter we'll be using it full screen. Genera cooperatively multitasks like any other Mac application, so you can use the Mac as a Mac while Lisp runs in the background and makes asynchronous calls to the Mac (which is, in fact, how we're even taking these pictures).
I decided the next step was to get the network up. You are warned that the steps we'll take in the rest of this article will deviate, in some parts significantly, from the official Symbolics manual, but for my purposes I find the result more convenient and Mac-like to manage (ut semper de gustibus non est disputandum).
Genera has a pseudodevice called SYS: (a "logical pathname") under which many components and local configurations live, and it can point to either an LMFS directory or an HFS folder. This is medicated by SYS.TRANSLATIONS file, which contains a Lisp function mapping pseudofolders under SYS: to actual directories or folders. The configurations Mac Genera will consult are in :System Folder:Ivory:Namespace: (I recommend making a backup in the Finder before mucking with it), with the translations function found in that folder as SYS.translations. However, it seems that the system hardcodes SYS:SITE;*.* to always reference files in the Namespace folder on the Mac side, even if you don't specify it in the function definition. This will make installation a little complicated later on and we'll come back to this issue.
It turns out this folder handles lots of things on a Mac Ivory box. For networking purposes Symbolics supported either standalone systems or networked systems, though in Symbolispeak "standalone" merely indicates that the resources the given machine consults are stored locally; properly configured, a so-called standalone system can still access and be accessed over any supported network protocol. Regardless, in both cases you have to set up a "site," or at least modify the standalone site shipped with Genera by default, which for Mac Genera also lives in :System Folder:Ivory:Namespace:. As this is an HFS folder, that means changing it in the Namespace Editor, which is the normal way you'd edit a site in Genera, or tricks like directly invoking (tcp:initialize-internet-namespace) will fail hard: at best you'll get filesystem impedance mismatches saying it can't write attribute :AUTHOR or some such, and at worst it will solidly bug out into the FEP.
I have only one other Symbolics Lisp machine on the premises which is usually not acting as such — to be discussed at the end — and thus I have no interest in creating a new site. Happily, the entire standalone site in Mac Genera is just text files you can edit in SimpleText, and everything you'll want to edit for basic networking is in Standalone-Objects.text. Avoid changing the name of the namespace, the site name or the hostname; if you do these things improperly or incompletely, you'll get lots of error messages and generally make Genera unhappy, and I'm not going to go into detail about it here. However, less crucial stuff like pretty names and timezones are fair game. For example, on my machine the host is still called MACIVORY, but its PRETTY-NAME is now Russell, and while the user name for logins remains LISP-MACHINE I also changed the displayed user name by setting LISPM-NAME under USER LISP-MACHINE to spectre.
As configured out of the box Mac Genera doesn't know what the Internet is, even though it includes built-in TCP/IP support. To "define the Internets," add the following stanza after the NETWORK CHAOS stanza:
NETWORK INTERNET SITE STANDALONE TYPE INTERNET
Remember to put a blank line after this and every other new stanza you enter. Finally, add an ADDRESS INTERNET x.x.x.x to the HOST MACIVORY stanza. (If you like, this address can also be added to any Set Network Address line in the FEP's startup scripts with a ,INTERNET|x.x.x.x [comma before it], but isn't necessary.)
Now start defining your hostnames. The first one you must define is the gateway; there will be no networking without it. The simplest way is to make the X11 host you'll use the gateway, so something like
HOST FOOBAR ADDRESS INTERNET x.x.x.x SERVICE GATEWAY IP INTERNET-GATEWAY SERVICE X-WINDOW-SYSTEM TCP X-WINDOW-SYSTEM SERVICE LOGIN TCP TELNET SITE STANDALONE
However, you can make any host the gateway that the MacIvory box can reach directly. You can define additional hostnames in the same way; just drop the GATEWAY service since they aren't your gateway (are they?). The lines given here make it the gateway, say it's a valid host for starting an X session with, and say it's a valid host for connecting to via Telnet.
Next, add the services you'll use to the HOST MACIVORY stanza, if they aren't already there. At minimum you will want at least SERVICE LOGIN TCP TELNET so you can remotely log into your machine. For illustration purposes, we're going to use this set:
SERVICE FILE CHAOS NFILE SERVICE FILE CHAOS QFILE SERVICE LISPM-FINGER CHAOS-SIMPLE LISPM-FINGER SERVICE LOGIN CHAOS 3600-LOGIN SERVICE LOGIN CHAOS TELNET SERVICE LOGIN CHAOS SUPDUP SERVICE LOGIN TCP TELNET SERVICE LOGIN TCP 3600-LOGIN SERVICE NAMESPACE CHAOS NAMESPACE SERVICE NAMESPACE-TIMESTAMP CHAOS-SIMPLE NAMESPACE-TIMESTAMP SERVICE SEND CHAOS SEND SERVICE SEND CHAOS CONVERSE SERVICE SHOW-USERS CHAOS NAME SERVICE TIME CHAOS-SIMPLE TIME-SIMPLE SERVICE UPTIME CHAOS-SIMPLE UPTIME-SIMPLE
Finally, put the subnet you'll log in from into the SITE STANDALONE stanza with SECURE-SUBNETS INTERNET x.x.x.x. When you're finished, you should have something that looks like this:
For the fonts, since Genera doesn't implement an X font server, you'll need your Genera CD or you can copy the files out of an existing Genera install — but it's easier if you have the CD as it's ISO 9660 and you can just mount it on your Linux box. The font files are stored as PCF (Portable Compiled Format). Something like this will work:
% sudo tcsh # mkdir /usr/share/fonts/genera # cd /run/media/censored/GENERA_8_3/sys.sct/x11/fonts/75dpi/ # or where your CDs get mounted # cp *.pcf.* /usr/share/fonts/genera # cd /usr/share/fonts/genera # foreach k (*.pcf.*) foreach? mv $k `echo $k | perl -pe 's/\.~\d+~//'` foreach? end # ls charb08.pcf courbo18.pcf helvr12.pcf lubr12.pcf lutrs10.pcf symb18.pcf ...
The little tcsh foreach loop is to strip the version number off the file (I'll discuss that a bit when we briefly talk about LMFS). Unless you don't already have them or you prefer them, you should also remove Genera's version of Helvetica and Times (hel*.pcf and tim*.pcf) as these will conflict with what you likely have already. Then do a quick fc-cache -f -v to load the new fonts.
Next we need to add a small system patch because unfortunately most modern X servers, including Xwayland (which sucks anyway), will not work with Genera; Genera will open the window but then receive an Xlib error and halt. That knocked my Fedora 40 Raptor Talos II workstation right out of the running, and doesn't appear related to endianness (adding +byteswappedclients to the X server command line didn't fix it, which interestingly suggests that Genera's Xlib implementation is little-endian despite Ivory having no intrinsic endianness). However, I was successfully able to get it to talk to X11.app and XQuartz in Mac OS X 10.4 Tiger (later versions may work with XQuartz also), OpenWindows in SunOS 4.1.x (Solbourne OS/MP) and Power MachTen on Mac OS 9. Amusingly, these are all big-endian and worked with it just fine.
The problem ended up being Genera's implementation of XSetModifierMapping, which needs to be patched out. At the Genera console, enter
(defun xlib:set-modifier-mapping (display &rest args) (values))
and answer Y when it asks if you want to overwrite the current definition. This is a great example of how you can patch a live Genera system while it's running. At this point you can then Save World to capture the change (incremental should be fine), though I put it in MACIVORY:>(user name)>lispm-init.lisp to run upon first startup for comparison purposes. That file can be edited with Edit File MACIVORY:>(user name)>lispm-init.lisp and we will talk about the editor later. Your user name comes from LISPM-NAME in the same Mac-side standalone site file, by the way.
Now we're ready to bring up services. At the Genera console, after logging in (with the Login command and username LISP-MACHINE, no password required), next type Enable Network INTERNET (or All), Enable Services and (neti:remote-login-on) to allow remote logins. I put the equivalent of those commands in my init file, which now looks like this:
(neti:remote-login-on) (defun xlib:set-modifier-mapping (display &rest args) (values)) (cp:execute-command "Enable Network" "All") (cp:execute-command "Enable Services")
and triggers this:
% ftp russell Connected to russell. 220 FTP service ready. Name (russell:spectre): spectre 230 USER accepted. Remote system type is . ftp> passive Passive mode off. ftp> ls 200 PORT ce,ns,or,ed,162,213 (TIM port 41685) accepted. 150 Here comes a listing of >spectre>*.*.*. >spectre>lispm-init.lisp.4 1 172 9/07/24 22:12:33 spectre >spectre>lispm-init.lisp.3 1 170 9/07/24 22:11:28 spectre >spectre>lispm-init.lisp.2 1 171 9/07/24 22:10:44 spectre >spectre>lispm-init.lisp.1 1 87 9/07/24 21:48:59 spectre 226 File transfer completed. ftp> quit 221 Goodbye.
Notice no password required! The name TIM doesn't come from DNS but by reverse resolution using the namespace we just built by hand. There are a few other oddities about FTP, by the way: it's simpler to just use it to transfer files to and from your home directory, as it were, and then place them in the right locations from the Lisp prompt. If FTP connects but gives you a 421 error, you forgot the SECURE-SUBNETS INTERNET x.x.x.x line.
It should also be noted that the line ending character natively in Genera is $8d, not $0d, not $0a, and not $0d $0a, as shown if we transfer any of the files above in binary mode. However, if you transfer in ASCII mode (i.e., not binary), then the line endings should get converted for you, and you can write and upload files from your own local machine instead.
There are also mail (SMTP) and finger servers listening:
% telnet russell 25 # smtp Trying... Connected to russell. Escape character is '^]'. 220 [ce.ns.or.ed] SMTP service ready. HELO localhost 250 [ce.ns.or.ed] HELP 214- Symbolics Lisp Machine SMTP server; Zmail 437.0. 214- Protocol is RFC 821. 214 Commands supported are HELO, MAIL, RCPT, DATA, RSET, SEND, SOML, VRFY, EXPN, HELP, NOOP, QUIT, and XCTM. MAIL From: <president@whitehouse.gov> 501 Bad reverse path: From: <president@whitehouse.gov>. QUIT 221 Goodbye. % finger @russell [russell.floodgap.com] spectre MACIVORY Unknown (Genera 8.3, 1 private patch, Patched for Y2K. 7.9MW MacIvory model 3) % finger spectre@russell [russell.floodgap.com] spectre MACIVORY Unknown (Genera 8.3, 1 private patch, Patched for Y2K. 7.9MW MacIvory model 3) % finger macivory@russell [russell.floodgap.com] spectre MACIVORY Unknown (Genera 8.3, 1 private patch, Patched for Y2K. 7.9MW MacIvory model 3) macivory: The user named "macivory" was not found. No user with that name is already known by the local machine, but it is not certain that there is no such user. Some namespace server did not respond.
Bottom line: don't put your Lisp machine outside of a firewall, especially since Telnet and FTP don't require a password!
Let's actually start the X connection up. On the X side, allow the MacIvory system to connect with xhost +russell (or what have you), or just plain xhost + if you're on a trusted network and things aren't working. On the Genera side, the command is Start X Screen hostname, such as Start X Screen FOOBAR (capitalization doesn't matter). Remember, you have to have previously defined FOOBAR (or whatever host name you're using) as a host in the standalone site! In the sample Telnet session below, the ! at the end of a line is what Genera does to wrap the text; if you use a wide terminal, Set Remote Terminal Options can be used to expand the output.
% telnet russell Trying... Connected to russell. Escape character is '^]'. Symbolics System, FEP0:>Inc-Genera-8-3-from-Genera-8-3.ilod.1 (Patched for Y2! K.) MacIvory model 3 Processor, 7.9M words Physical memory, 24.4M words Swapping ! space. Genera 8.3 Standalone Russell Type c-_ H for Help. Type Set Remote Terminal Options to set the terminal type. Warning: Russell is a server machine. Please exercise caution. Command: Start X Screen (the name of a host) tim
The (the name of a host) prompt is provided for you by Genera. (The c-_ sequence is Ctrl-Underscore (i.e., Control-Shift-Minus), and allows access to a subset of Symbolics keys via Telnet. For example, Control-Underscore followed by A is Abort, E is End, H is Help, C is Complete and N is Network.) If you did it right, a new window will appear. On my 1080p display, the Lisp content area is 1728x972.
I mentioned that Genera has a pseudodevice called SYS: where certain core components are stored. This is not the Genera world you run, which is part of the FEP's filesystem, but it does contain (or will, when we finish this task) the source code for it as well as things like fonts, optional packages, online documentation and site configurations. The filesystem mappings that compose SYS: are contained in an S-expression in SYS.translations. At this point the file looks more or less like this (with the ≡ character representing Record Separator/$1E, displayed on a Telnet connection to Genera as <Equivalence>):
;;; -*- Mode: Lisp; Syntax: Common-Lisp; Package: FS; Base: 10 -*-
(SET-LOGICAL-PATHNAME-HOST "SYS" :TRANSLATIONS
'(("SYS:**;*.*.*" "MacIvory|HOST:≡:Ivory:Namespace:**:*.*")
SYS: is subdivided into various subcomponents, represented by the double asterisk, and LMFS file references are not only by filename and extension but also by version number (or LATEST). This snippet of Lisp tells the filesystem module that SYS: in its entirety should be represented by folders under the Ivory System Folder, ignoring the version number. For example, SYS:FONTS;font.font.3 will be turned into an RPC request for :System Folder:Ivory:Namespace:FONTS:font.font.
That said, the Lisp clueful among you will have noticed something in the earlier screenshot: the Ivory System Folder doesn't have a SITE folder. How then does that work to access the default namespace, which Genera looks for in SYS:SITE;? It happens first and foremost because the default FEP local boot script explicitly references it, but there's also an implied mapping ("SYS:SITE;*.*.*" "MacIvory|HOST:≡:Ivory:Namespace:*.*") that always exists. In fact, this very mapping is used to locate SYS.translations itself.
However, we don't actually want everything in SYS: stored on the Mac side when we complete the install. Doing so makes things a lot slower because there's an RPC request required for each file instead of "directly" from LMFS, there are filesystem attribute mismatches, and most importantly because a lot goes into SYS: and it might overrun your Mac HFS volume. Change the file to this:
;;; -*- Mode: Lisp; Syntax: Common-Lisp; Package: FS; Base: 10 -*-
(SET-LOGICAL-PATHNAME-HOST "SYS" :TRANSLATIONS
'(("SYS:SITE;*.*.*" "MacIvory|HOST:≡:Ivory:Namespace:*.*")
("SYS:**;*.*.*" "MACIVORY:>rel-8-3>sys>**>*.*.*")))
which is equivalent functionally to this, but makes the implied mapping explicit so there are no surprises:
;;; -*- Mode: Lisp; Syntax: Common-Lisp; Package: FS; Base: 10 -*-
(SET-LOGICAL-PATHNAME-HOST "SYS" :TRANSLATIONS
'(("SYS:**;*.*.*" "MACIVORY:>rel-8-3>sys>**>*.*.*")))
thus storing everything but SYS:SITE;*.*.* on the LMFS side yet keeping our standalone site configuration on the Mac side where we can get at it outside of Genera if we need to. In LMFS volumes, the greater-than sign is the path delimiter.
The translations facility isn't nearly as flexible as you think it is, by the way: you can't say, for example, that files ending in *.SYSTEM.* are in one place and all the other files are somewhere else. It's only granular to the folder level (darn).
For the installation step, make sure your CD-ROM drive is available and powered on (rebooting your Mac if necessary). The CD-ROM here, as I mentioned, is a recapped 1x AppleCD 150 (Sony CDU-8002) on ID 1 that requires a caddy. The CD SC and CD SC+ predate the 150 and being 1x drives themselves may also work, but not the 300 or any later drive, which are 2x and faster. Insert the Genera CD and wait for it to mount, then bring Genera back up and log in.
To switch back to Dynamic Lisp Listener 1, hold down F9 (the Mac FUNCTION equivalent), hold down 1 and press S. This key combination rotates through windows, by the way. You can restart Lisp at this point if you like, and I did, but it's not necessary.
At this point we've finished tuning up the hardware and installing the software, so let's have a little test drive. Pedantic Lisp machine denizens are advised: I don't have a neckbeard as long as yours, and I'm mostly doing this from the perspective of an minimally informed tourist, so I won't be demonstrating the length and breadth of Genera and Lisp Machine Lisp just like any other grab bag of screenshots couldn't exhaustively demonstrate a classic Mac or the Oberon System either. Treat this as a brief show-and-tell and not a user's guide. Also, because the X font set ends up slightly different, the appearance of UI elements and text prompts varies a little bit from what you'd see on the Mac console. Let's return to the Dynamic Lisp Listener command prompt with the wider screen on our Linux workstation (restart the X session as instructed above).
We've seen some of the basic interface, so now we'll peek under the hood. Appropriately, we'll do this using a built-in system monitor tool called Peek. Peek isn't in the default system menu but it has its own key combination SELECT-P (on the Mac, ESC-P, on X, F1-P).
The Genera scheduler is preemptive and tasks marked as "preemptive" take over the CPU as soon as they are runnable (priority permitting), relegating other tasks not marked preemptive to wait. The very highest priority tasks are "deadline" tasks that must complete execution in the specified time interval while within their critical sections. These tasks tend to be crucial system or user interface tasks like the status line updater and even the scheduler itself. You can see preemptive (P), foreground (F) and deadline (D) tasks in this list, and many tasks have multiple flags.
You may have noticed some tasks are listed as "dead." These are tasks that were manually killed and they remain in the process table, even keeping a window allocation if they had one, although the scheduler will never put them on the processor. However, unlike zombie tasks on a Unix system which can only be reaped (and then only by their parent or when their parent exits), these tasks can be resurrected by resetting and thus restarting them.
You might wonder why the FEP has not only a separate volume but also a completely different type of file system, and the reason is its very different purpose. The FEP file system is simpler and faster than LMFS and is optimized for reliable concurrent access to files which are written rarely but accessed frequently. These obviously include FEP boot scripts, binaries and the bootable Genera world, but also information about the entire disk the FEP file system is on (thus each disk accessible by Genera must have an FEP file system of its own to describe it). FEP volumes are hierarchical and versioned like LMFS volumes, and use the same "greater-than" delimiter. Its most notable contents are "load" binary image files, generally ending in .load or .?lod where ? is F for FEP and I for Ivory, but there are other types like virtual memory paging files and (on 3600-series systems) microcode.
No SLAP or Chaosnet connections are running, but of course there's one INTERNET (IP) connection open, which is the very X session we're taking grabs from (I am amused that exactly 68,040 packets were received at the time the screenshot was taken; I didn't plan that). Each supported IP protocol is listed: ICMP (the packets are probably from when I was pinging the link), EGP (Exterior Gateway Protocol for routing between autonomous systems, now obsolete and replaced with Border Gateway Protocol [BGP]), UDP and of course TCP. The single interface is listed as well, with the IPs blacked out because some of you are fun but I don't trust you, and its gateway, which I have chosen to be the NetBSD IIci so that they can interact, intertwine and have little baby IIcis (also it's on the same network hub).
You'll also notice that the editor pane is only taking up part of the screen, and that there is a blank area with a pattern over it. That's one of the windows behind Zmacs.
Let's go back to the Lisp Listener and look at systems now.
Systems can reference and load in other systems, so the first thing that Genera does is collect all the (sub)systems thus referenced. This hits our first error due to the filename length limitations of HFS. Again, however, Genera's flexible error handling saves the day. You should have already renamed these long names as I indicated earlier, so now you can just change the name it's looking for (you have to do it twice because it checks the file twice). Remember to do this step again when it gets to the second such file.
#include <stdio.h>
#include <math.h>
main_quad()
{
int a, b, c, d;
double drt, x1, x2;
printf("\nSolves the equation ax(2) + bx + c = 0");
printf("\nfor x.");
printf("\nEnter values for a, b and c: ");
scanf("%d %d %d", &a, &b, &c);
d=((b*b)-(4*(a*c)));
if (d <= 0)
{
printf("This program cannot solve a quadratic formula whose");
printf("\nresult is an imaginary number.");
}
else {
drt = sqrt((double)d);
x1=(-b+drt)/(2*a);
x2=(-b-drt)/(2*a);
printf("The value of root one is %f ", x1);
printf("\nThe value of root two is %f ", x2);
}
}
One thing that is particularly interesting about Symbolics C is that you can call existing Lisp functions from it, using declarations like
lisp "global:reverse" lispobj reverse(lispobj list); lisp "global:print" void print(lispobj anyobj);
You can also create your own Lisp functions that C can call, too. Consider this Lisp code:
(defun c-user::|listarray| (array-pointer-object array-object-byte-offset count)
(loop for i from (floor array-object-byte-offset 4)
for count from count above 0
collect (aref array-pointer-object i)))
This creates a function |listarray| in the C-USER package (not the default Lisp USER package). The prototype extern lispobj listarray(int a[], int count); then allows you to call it, and the Symbolics C runtime handles the call and marshalling the parameters and arguments. It's possible to call C code from Lisp, but again this isn't nearly as straightforward.
Mac Genera has some tricks up its sleeve too which are themselves part of a Genera system. Remember that HyperCard stack I pointed out way the heck earlier? That stack uses an external function (XFCN) module to do RPC with Lisp, letting you drive the MacIvory card from the Mac side. You can create your own native Mac C applications that do the same, too.
This portion here, where you can send Lisp to the card and have it executed, does seem to work, at least for simple Lisp. For example, I'm having it evaluate
(defun fact (x) (if (< x 2) 1 (* x (fact (1- x))))) (fact 6)
which defines the function fact (factorial) and then correctly computes 6!, which is 720. Math wouldn't be the strong suit for a setup like this: the 50MHz 68030 in this IIci runs rings around the slower Ivory at integer math, and this MacIvory doesn't even have an FPU. However, the Ivory can handle much larger data sets than the '030 can and it can do it separately of the '030, which is free to maintain the console and other Mac applications. That sort of large-set data crunching could be very useful to hand off, though I wouldn't likely create such an application purely in HyperCard, of course.
By the early 1990s the AI Winter's frosty bite was acutely felt through the industry, and while Symbolics largely had the Lisp AI market to itself, there wasn't much market left to have by then. Nevertheless, as Ivory finally fumbled towards the surface in 1987 a second project was already trying to create its successor. Sunstone's performance was intended to be over triple Ivory's and up to twenty times faster than the 3600s, yet it could serve as a drop-in replacement in a future XL400-type system that could additionally be sold as an upgrade to existing ones. It was also a 40-bit machine and used the same data structures as Ivory, but instead of the classic stack architecture was a more conventional RISC load-store design with specialized Lisp operations in the instruction set. This was intended to make Sunstone much faster at Lisp but make it more feasible than Ivory for running other programming languages if desired as well. Although simulations showed promising performance against Ivory and competing RISC designs like MIPS-X, it never reached prototyping because Symbolics was running low on dough, and Sunstone ended up cancelled allegedly the very same day it was supposed to tape out.
Instead of a hardware Lisp machine, Symbolics instead turned their waning development resources to creating a software one. DEC Alpha's emergence in 1992 shocked the industry with its high speed and exceptional performance, achieving 192MHz in the first version of the 21064 at a time when the Intel Pentium could only eke out 66MHz a year later. For Alpha systems running Digital UNIX and later Tru64, Symbolics developed a Virtual Lisp Machine which could directly interpret Ivory opcodes and, with emulated devices, run a standard Genera world. Although not as fast as Sunstone was claimed to be, the VLM was still ten to fifteen times faster than the 3600s even on the first Alpha chips, and thus was shipped the 1.0 release of so-called Open Genera in 1993 (simultaneously with Genera 8.3, the last release for hardware Symbolics systems, and the version we were using here). On my AlphaPC 164LX with a 600MHz 21164A, Open Genera runs pretty spiffy indeed in Tru64, and it serves as my second "Lisp machine" even though it's only so in software and I'm not usually running it.
Sadly, Open Genera couldn't save Symbolics; even as a much cheaper emulator it was still too pricey for what was regarded as a legacy product. As a desperation effort Symbolics' assets were sold to a new company headed by none other than Russell Noftsker himself in 1995, but this next iteration quickly had cash flow problems of its own and reorganized under Chapter 11 bankruptcy in 1996. In 1998 the modestly upgraded Open Genera 2.0 was released, the last official version for the Alpha, and in 1999 the remnants of "new Symbolics" were finally bought outright by the reclusive Andrew Topping. Topping retained the rights to Symbolics hardware and software while licensing sales and maintenance contracts to David K. Schmidt. As many of these contracts wound down and were not renewed, most of the few remaining facilities were closed, and Topping himself passed away in 2005.
Schmidt provided service and remaindered sales to contract customers and some end-users as (now) symbolics-dks.com, which is at least ostensibly still in business, and the $4500 doorstop I bought in 2015 was one of his systems. DKS, however, has no rights to the hardware or Genera itself; these were bought at Topping's 2009 estate auction by MIT CSAIL's John Mallery, who to date despite plans to open them has yet to do so. The former symbolics.com domain name, the first .com domain in 1985, was purchased separately and now is such a shadow of its former self that I refuse to link it here. (The legal situation is far clearer for the now completely free MIT CADR machines, which have their own simulator and updated software.) Today Genera's spirit lives on in two major ways: an unofficial port of the Virtual Lisp Machine, first to x86_64 by changing the code generator to emit C instead of Alpha assembly, and then to PowerPC G5 (see also these instructions); and Portable Genera, an official port of the VLM to Intel and ARM done under contract for existing customers. While this version isn't publicly available as of this writing, it's still actively developed.
As a footnote, it should be mentioned that the LMI/TI and Symbolics lineages were hardly the only Lisp machine families out there, though they were available in the largest numbers and are certainly the best known. Probably the most notable of the also-rans was BBN's Jericho, based on Interlisp, which never shipped as such but strongly influenced the 1979 Xerox 1100 ("Dolphin") and its successor line of Lisp machines. These machines became more famous as the hardware basis for the Xerox Star, among others. Xerox itself had plans for its own Lisp RISC chip but it's not clear if it ever got past the design phase. Some smaller efforts occurred in Japan and Europe, including from Fujitsu, Toshiba and Racal-Norsk.
But as for me personally, I've finally got the damn thing stable and fully configured. I would further argue this IIci is the smallest practical true-hardware Lisp box you can build: a IIsi with an MI3 on a NuBus bridge can't network and has to rely on anaemic internal video, the Q700 is the same size, and everything else is larger. In fact, it runs pretty well now, enough even to do some other tasks on it, so my fury at last has receded.
Somewhat, anyway.
Wow, very impressive. I founded ExperTelligence. We bought one of the first Symbolics 3600s in 1984. We used it to create LISP on the Mac. Got to work with Russell, Steve Jobs and Alan Kay. Created the first Interface Builder in 1986 in LISP on the Mac. Then in 1988 created Action!, an interface builder on steroids for the TI MicroExplorer. I still have a MicroExplorer in the attic somewhere. When TI shut down their computer division we ended up with over 30 MicroExplorers in trade!
ReplyDeleteDenny at Bollay dot com
Hey, thanks! How would you compare microExplorer to the MacIvory (or, for that matter, TI's Lisp implementation to Genera)? I've not used a TI Explorer and I'm told it's closer to the original MIT CADR style, but also lacks some of the creature comforts.
DeleteYou mentioned in passing, "Xerox itself had plans for its own Lisp RISC chip but it's not clear if it ever got past the design phase." -- I'm curious as to the source of that info. Can you say more?
ReplyDeleteThere is a mention in AI Magazine spring 1987 about a "Xerox Common Lisp Processor" (notice: not Interlisp), but little information about it. The article mentioned they were looking at having an "internal version" available in 1987 which suggests there was an existing design but I can't find any reference anywhere that indicates it actually got to silicon. Do you know differently?
DeleteInteresting, thanks. I didn't know the project was spoken about at AAAI. I don't know if it got to silicon. Separately, a small group of us (most of whom worked at PARC in the '80s and on) have been resurrecting (and modernizing a bit) Interlisp-D on the original byte-code emulator that shipped on Unix & DOS boxes. See https://interlisp.org/ if you're interested.
DeleteExcellent! That looks like a fabulous project!
DeleteSee https://xeroxparcarchive.computerhistory.org/phylum/tamarin/.index.html if you're interested in the Xerox PARC Lisp chip.
ReplyDelete