Paper submitted to IEEE CCECE

[Eleanor Young]

Hi folks,

Just sending the link to the paper I've written again, since Stephen asked to see it now that it's submitted.

Here's the link to the paper formatted for IEEE, though I think I might not've uploaded the most recent formatted version here. You'll have to download the document, as google docs can't preview the IEEE formatting. The first link should be up to date in terms of content, at least. I'll update this link later this evening once I'm home, as the up to date copy is on my desktop computer.

Further comments are welcome, if you'd like. I still plan to basically trim this down and shape it for a CACM article, if we can manage to get that lined up.

That's all!

-Ellie

[Ron Kaplan]

Thanks, Eleanor.  A very nice paper, it tells the story very well.

Reading about DWIM reminded of one of the motivating examples that Warren pointed to:  An error message from a compiler for a conventional language to the effect of "you left off a semicolon at the end of line 31".  If it knew that, why didn't it just stuff in the semicolon and go on?  (But later, I remember that another acronym was floating around:   DWIS: Do What I Said!)

In terms of the early history, the name Interlisp acrose when Danny and Warren moved moved some of the development effort of BBN-Lisp to Xerox, and it was not politically appropriate for Parc resources to be going into BBN's project.  So "Interlisp" was chosen as a neutral name.

I don't think it is correct to say that the microcode for the early machines was written in Lisp.  There was a specification of the opcode set for the Interlisp virtual machine, but then the microcode was written for each machine to implement those opcoces.  Maiko is another implementation for that (now more evolved) set of opcodes.

Figure 1 is pretty unreadable, at least in my download of the IEEE version.  Can that be improved?

Are "parachronistic" and "parachronisms" real words, or missspellings?

Best--

Ron

--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/9a7314da-adf9-4fb9-b4de-e6b05c68f338n%40googlegroups.com.

[Herb Jellinek]

Is it too late to update the IEEE paper?  I found a couple of nits I'd like to fix - the microcode comment is one.

Figure 1 looked fine on my screen, but if you can change it so the screen has a white background it will be more legible.  In an exec window type

(CHANGEBACKGROUND 0)

            Herb

To view this discussion visit https://groups.google.com/d/msgid/lispcore/5CB3E646-A568-4E4A-9475-9666E9768A5A%40post.harvard.edu.

[Larry Masinter]

I don't think it is correct to say that the microcode for the early machines was written in Lisp.

 it isn't .... 

 There was a specification of the opcode set for the Interlisp virtual machine, 

I don't think there was a "specification" of the opcode set. At least, I don't remember ever seeing one or working from one.  There was a design for AltoLisp and its microcoded instruction set.  there was an implementation for the Dorado which started with the AltoLisp opcodes.

 And then there were implementations in Dolphin (D0 "Dee-zero") and Dandelion (the star 8000 machine). The others came later.

 

but then the microcode was written for each machine to implement those opcoces.  Maiko is another implementation for that (now more evolved) set of opcodes.

Maiko implements not just "opcodes" but also "subrs" for other things, like the Interlisp-D file system on top of Unix/Posix file system (the {DSK} file system) and other parts.   

--

https://LarryMasinter.net  https://interlisp.org

To view this discussion visit https://groups.google.com/d/msgid/lispcore/235101e3-3908-4812-b4bf-8e91efb44c05%40newscenter.com.

[Paolo Amoroso]

There's a typo in the final paragraph of both versions of the paper, an extra "the": "While the we did not have this benefit...".

LibreOffice on Linux doesn't render the figures and Google Docs, as you noted, can't preview or open the document. Would it be possible to have a PDF so that I can take a look at the images?

The paper came out really well and I expect a lot of interest in this angle of analyzing the project.

--

You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/9a7314da-adf9-4fb9-b4de-e6b05c68f338n%40googlegroups.com.

--

Paolo Amoroso | Blog | Mastodon

[Eleanor Young]

Ron -- Thanks for the feedback! I'll fix the microcode bit, I must've taken inaccurate (or confusingly formatted) notes at some point. Parachronism / parachronistic is a real word, just a rare one, but this is one of the few times it actually has a nice use so I want to be sure it stays in there unless IEEE throws a fit about it, hah.

As for readability, I think the figures come out a bit better in the PDF. That said, I'll likely implement Herb's background change idea, that seems good.

Herb -- I have until the 7th to make further changes. Happy to fix nits.

I also attached the white background image to this response. Is that a bit better? It still has the dot-texture around the menus to the right, but that doesn't seem like a big deal to me.

I haven't updated the image in the paper, yet. I will (or won't) depending on people's thoughts on how the original one looks in the PDF, which should be easier to see in general.

Paolo -- Good catch on the typo, will fix that right away!

And yes, I can definitely throw you the pdf. It's attached to this response.

[Paolo Amoroso]

The image looks good in the PDF, thanks.

If the visual issue Ron and Herb alluded to is Moivre patterns it's probably a call between historical closeness and readability. In journal papers of the period the gray background shade was more common in Interlisp-D screenshots. A way of mitigating the Moivre patterns is to run Medley with a smaller screen with the -s option such as medley -a -e -n -s 1024x768 like in this screenshot.

[STEPHEN KAISLER]

Elenor/All:

 

I think the pdf looks good

 

The flat gray seems to be distracting.

 

Steve K.

To view this discussion visit https://groups.google.com/d/msgid/lispcore/CAJDpohvTwrZ2ztjS8QU-7N1p6O87awc4rmpkR43xwi%2BPN%3Dd7%2Bw%40mail.gmail.com.

[Nick Briggs]

I put a variant of this comment on the Google doc, this is more complete.

This looks pretty good.  Thanks for writing this up.  My only substantive comment is as regards the Maiko/microcode section:

Interlisp was developed such that it handled its own microcode — small, extremely low-level instructions for the computer — but modern computer systems have their own microcode built into the CPU. As such, Interlisp trying to mandate its own microcode greatly displeases modern operating systems and system architectures, requiring Maiko to serve as an intermediary.

This is overly folksy for my taste, as the maintainer of Maiko.  It was part of the design of Lisp on (and of) the D-machines to have some room in the microcode store to implement specialized instructions for an application program, and that's what Interlisp-D used to implement its virtual machine instructions.  As you say, modern processors, while they are microcoded, do not support application supplied loadable microcode - that's just not part of their architecture.

So, in order to execute the same Medley virtual machine instructions as the D-machines implemented in microcode (which was different for each of the D-machine families), we implement them in a higher level language that is compiled to the host hardware's native instruction set - at the time, C was the obvious choice for that language: it was the language in which the host operating system was written, and thus got a lot of attention to the performance, and could access all the features of the OS and hardware.  There were of course differences between the C compilers on different OSs, which had to be compensated for, variations in the graphic output capabilities, and so on.  These days, there is little variation between C compilers available on different OSs (usually GCC, CLANG, or Oracle's Studio C), and the graphics standards have been fairly static - which makes it much easier to port between systems, sometimes requiring no significant work at all.

-- Nick Briggs

On Apr 2, 2025, at 10:58 AM, Eleanor Young <esyo...@ualberta.ca> wrote:

[Nick Briggs]

Regarding

Could you elaborate a bit on what "application designed and loadable microcode" means? I understand it to mean "applications had their own microcode that had to fit together with the system's in some way" — is that correct?

You don't need to put this into the paper, but so you have a better idea of what was going on--

For all of the D-machines, when you booted them they came up in a command-line executive (shell) - it looked like (was?) the Alto Exec for the Dolphin and Dorado but on the Dandelion and Daybreak it was the Mesa executive Othello/Hello.  These were not written in Lisp - the Alto Exec was written in BCPL, and Othello/Hello was written in Mesa - so the machines had to have microcode loaded which implemented either the BCPL instruction set or the Mesa instruction set, as appropriate to the hardware.  To run Lisp, you had to change the initial microcode to one that could also load the microcode that had the additional Lisp instruction set implementation.  Once the Lisp initial microcode was loaded, when the machine booted up to its initial shell you could run the command that actually started the Lisp system.

For example, in the Fugue release notes you find:

• New 1108 [Dandelion] Lisp microcode.

Some operations previously in 1108 Lisp microcode have been moved into the initial microcode, and replaced by other opcodes.

• New 1108 initial microcode.

The process of installing Fugue.6 with the Installation Utility floppy will load new initial microcode into your 1108. Note that while the new initial microcode is compatible with all Fugue sysouts, the Fugue.6 version of Interlisp-D will only run with the new initial microcode. In addition, the new initial microcode depends on up-to-date PROMs: if Fugue.4 worked on your 1108, but the new initial microcode and new sysouts do not, contact 1100Support.

• New 1132 [Dorado] microcode.

A number of improvements, especially for "creation" of datatypes and for numerical operations.

[Nick Briggs]

It's getting a bit off in the weeds: trying to explain what microcode is, and Maiko, and Fuji Xerox' corporate ownership in the same section is not making things clearer.

On Apr 5, 2025, at 11:42 AM, Eleanor Young <esyo...@ualberta.ca> wrote:

Thanks so much for the elaboration! Having a better picture of the details helps a lot when trying to cover it more broadly.

As of right now, I've rewritten the microcode chunk to read:

"Further, Interlisp was designed as such that it both handles its own microcode — small, extremely low-level instructions for the computer — and allows room for application-supplied loadable microcode.

Interlisp's implementation was based around a virtual machine with an instruction set specifically designed to support Lisp operations.  On the D-machines the Lisp virtual machine was implemented in microcode.

[explain microcode here, if you want, but I don't think it should be necessary this is an engineering audience, though not all CS engineers.  Please read the Wikipedia entry for microcode first!]

When it became desirable to port Interlisp-D to more modern non-D-machine hardware (initially Sun SPARC workstations), which was not microcodeable, the virtual machine implementation was written in C.  This implementation, known as "Maiko", was done by Fuji Xerox [and PARC? Larry was definitely involved].  Maiko also provided the interface between Lisp code and the host OS file system and display subsystem.

However, while modern CPUs are microcoded, their design architecture is entirely incompatible with loadable microcode.  Interlisp’s insistence on using both its own microcode and loadable microcode greatly displeases modern computer systems, requiring Maiko to serve as an intermediary. Maiko is a virtual machine that was developed at Fuji Xerox (the Japanese branch of Xerox Corporation contemporary to Interlisp’s development, co-owned by Xerox and Fujifilm) that takes the place of Interlisp’s microcode by implementing the same instructions Interlisp used on Xerox’s D-Machines in a higher level language, C. This C code then compiles down to the host operating system’s native instruction set; this allows Interlisp to ‘play nice’ with modern operating systems while behaving accurately as it did on D-Machines. Lastly, Maiko’s implementation in C makes it the only piece of Medley that is not written in Interlisp."

Is that a bit more on-base? I think the broadest sweep that I'm not sure about there is saying that Maiko "takes the place of Interlisp's Microcode" -- is that an appropriate generalization of what's happening, or would it be better put some other way?

[Paolo Amoroso]

Enjoy your paper read aloud, possibly by an AI voice. In Japanese, which kind of pays homage to Fuji Xerox and Maiko.

[Paolo Amoroso]

It actually seems like one of those AI-generated podcasts, in this case discussing the IEEE paper.

--

You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lispcore/2b69cbc5-d50b-47a9-8862-5c4b0d9e6cc2n%40googlegroups.com.

[Eleanor Young]

Yeah, seems so, haha. What a strange little channel! The video with our paper has more views than most, which is interesting, maybe, hah.

You received this message because you are subscribed to a topic in the Google Groups "Medley Interlisp core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lispcore/g5_glUgnZ3g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/CAGi1hzuyeE1%3DioBicrPwqb5b0ju54awzA7aWBuBTKm9rYm8Fsg%40mail.gmail.com.

[pixel...@gmail.com]

I’ve been thinking about AI presentation in general and feel strongly it’s been soured by marketing. For example, quite a few people are instantly put off by what’s become known as “AI slop” — those AI-voiced English videos from non-English vendors selling various wares.

Unless the situation is dire (like a genuine language barrier) or otherwise exceptional, I think AI-narrated videos can be considered borderline offensive. In the current AI climate, they show a lack of respect for the listener.

One particularly annoying case is a company that turns AI slop into “audiobook” ads — and will keep reading an entire novel unless you click away. I’ve got a shower speaker and often listen to podcasts, and since there’s no “skip ad” button in there, I’ll end up trapped listening to 20 minutes of some AI-generated teen vampire story.

The English may be better than the TikTok “Valley Girl up-talk” voices we used to get, but the end result still feels disrespectful of the listener’s time.

People being bombarded by these things have, I think, soured on AI narration altogether.

But for the video needing translation it's certainly better than an audience not seeing it.
The only Japanese Lisper I know of is Eitaro Fukamachi. https://github.com/fukamachi

Just my two cents on five bucks’ worth of word salad. :)

[Eleanor Young]

Oh, definitely, I agree. In this case, it's not as if the paper isn't available to folks who have access to IEEE stuff (though, I thought it hadn't been uploaded there yet — I wonder where they got it from? The pre-print from our site? In that case, it's available to anyone, so, whatever), and this just renders it accessible in a way to a Japanese audience.

Who knows how accurate the transcription and reformatting into a podcast is, but LLMs are decent at summarization of a restricted pool of data (in this case, a single paper), so it's probably all right.

To view this discussion visit https://groups.google.com/d/msgid/lispcore/20f76094-d914-447b-ad5e-9a23c84453acn%40googlegroups.com.