Author here. This bytecode interpreter is the continuation of my already published Class Browser and Virtual Image Viewer (see https://news.ycombinator.com/item?id=22451077 and https://news.ycombinator.com/item?id=22584364). The interpreter is able to directly run the original Xerox Smalltalk-80 v2 VirtualImage file (i.e. the unmodified file as provided by Xerox in May 1983); it complies with the Blue Book part 4 implementation and reproduces the trace files and screen output according to the manual. I use it to study the dynamic behavior of the VM; the goal is still to have an implementation based on LuaJIT, if feasible; a Win32 binary is available for download (Linux and Mac versions can be provided if need be).
back
2 comments
Great job!
After Squeak changed its license from the original Apple one to Apache it still wasn't accepted as free software by Debian because of a lack of C based tools to examine the image. A Virtual Image Viewer like yours would have solved that (specially if it could compare two images).
Thanks. It's work in progress since I currently implement a transpiler from ST to LuaJIT bytecode which will hopefully result in a substantial speedup. The current interpreter runs decently fast on modern machines though and looks and feels like ST80 in the old days.
Also note that Squeak is not compatible with ST80 in both the bytecode and object memory format. If I succeed with my LuaJIT based implementation (i.e. if it performs better than Cog or the Graal or RPython version) I might try to make it compatible with Squeak or Pharo.
The evolution from Apple Smalltalk to Squeak did change the object memory quite a bit but only added a few bytecodes. The Cog project added even more to the bytecodes in several steps (specially with the change of blocks into proper closures) and more recently moved to a very different object memory called Spur.
Do you happen to have specifications of the bytecodes, primitives and object memory format compared to the Blue Book? I only have a plethora of (outdated) papers and presentations, nothing systematical.
The best documentation is inside Squeak itself, specially very early ones. In later version the VM code was spun off as an external VMMaker package that you have to explicitly load.
This 2008 post in Eliot's blog shows the first changes he made to Squeak's bytecodes: http://www.mirandabanda.org/cogblog/category/cog/page/15/
Thanks.
Here is a 2016 paper about the changes to the OpenSmalltalk bytecodes:
https://rmod.inria.fr/archives/papers/Bera14a-IWST-BytecodeS...
Most of Squeak is MIT License. They did a big project to switch.
The original Squeak was the very first attempt at Apple to do open source. But the license had some terms that upset some people (about fonts, no export to countries with US restrictions, having to help Apple in any lawsuit against it due to you distributing Squeak). Given that Open Source was only defined a year after this license was released, it is hardly shocking there were issues.
This was a problem with some Linux distributions, but when the One Laptop Per Child project considered rejecting Squeak/Etoys (while embracing the Squeak-based and non open source Scratch) things had to change. Alan Kay personally got Steve Jobs to release the very first Squeak again under the Apple Community License. But people complained about that, so Alan had to go back to Steve and Apple released Squeak 1.1 a third time, now under the Apache 2 license.
Most of the code then in Squeak had been added after Apple. So a letter was sent to all programmers (or their living relatives) asking them to print and sign a form allowing their code to be switched from SqueakL to MIT. VPRI collected the forms. Then the Pharo people did the same for code they had that is not in the Etoys Squeak release.
Only in Squeak 2 did code start getting tagged with author initials. Code added between 1.1 and 2 was sent in emails to Dan Ingalls who personally inserted it into the official release. So I went through the email archives and identified all missing authors and the Squeak Board sent them forms to be signed.
All new contributions are required to use the MIT license (Richard Stallman considered two pieces of code that exist in the same Smalltalk image to be "linked" together in terms of GPL and LGPL instead of being potentially like two programs on the ISO CD-ROM image).
Ian Piumarta used the GPL for some small C fragments that are part of the Unix/Linux virtual machine. I am not sure if that code is still in use.
Really?!? Then one wonders how C keeps its hegemony.
How does Debian deal with other stuff also not written in C?
Yeah that doesn’t seem right. What Debian requirement does this follow from?
The idea is that the Squeak image is a "binary blob", so doesn't count as a source package. The image file does come paired with two text files (sources and changes) that can be viewed in any text editor (but with old Mac line ending) and have the full sources. But there are objects inside the image that aren't generated from these sources (some have been "alive" since 1976) and these can be only examined using tools that also exist inside the image.
Once in a while someone asks for a tool to save the image as a XML or JSON file. They don't know enough to write this tool themselves. The problem is that the people who do know (it is pretty trivial, actually) have no interest in doing it. Normally the idea is that you could then use Unix diff or similar tool to check what has changed from one version of the image to the next.
> The idea is that the Squeak image is a "binary blob", so doesn't count as a source package.
I get why they did this (arbitrary, simple to evaluate), but at no semantic level does this make any sense.
Pharo is now bootstrapped entirely from the text source files. To do it, you need already working Pharo, so there is a chicken-egg problem...
> To do it, you need already working Pharo
Just because of the compiler, or are there other preconditions only available in an existing image?
During bootstrap, the hosting Pharo serves a virtual object memory with object stubs and provides an AST interpreter. It is a quite complicated process. It is possible to rewrite it to another language but not easy.
Yeah, but as Dennis Ritchie has proven, having the source package isn't enough if one isn't a security expert anyway.
I doubt that every Debian package has such level of security review.
It's less about security auditing than it is just about freedom to view the source and/or modify. That's why Debian is separated into free and non-free to begin with. Nothing is stopping it from going into non-free as I understand it.
View the source in `ed`, apparently, is the requirement, as the full semantic specification is clearly accessible and modifiable.
Ken Thompson was the author of "Reflections on Trusting Trust" not Dennis Ritchie.
Ooops, thanks for the correction.
> it complies with the Blue Book part 4 implementation
I am a huge fan of the Blue Book part 4 which describes the bytecode VM implementation and runtime.