Hernán Morales Durand wrote on Tue, 22 Jan 2019 02:03:01 -0300
[Little Smalltalk and bootstrapping an image]
Yes, sadly some of the LS implementations were lost in time and need to be tracked now, http://www.littlesmalltalk.org is now chinese thing, PDST and Parla were based in LittleSmalltalk 3 but only accessible through archive: http://web.archive.org/web/20051025043437/http://www.copyleft.de/Parla/Parla.... There is another implementation now : https://github.com/0x7CFE/llst however didn't checked yet.
For those who don't know about Little Smalltalk, version 1 described in the book has some important differences from Smalltalk-80. One of them is that an object is split into pieces corresponding to the superclasses so that the offset of a variable can be the same in both a class and its subclasses. This avoid having to do a lot of recompilation when a class changes.
I don't remember any details about LST2, but LST3 was a lot more like Smalltalk-80 but had all classes be instances of Class like in Smalltalk-76. That was changed in LST4 to have metaclasses like Smalltalk-80. For some reason many people prefer the simpler LST3 and use that as the starting point of their forks, of which there have been many over the years.
You asked about bytecodes having a fixed size. I am not sure what you mean by that. While most Smalltalk-80 bytecodes are 1 byte long, a few are "extended" and in the case of closure bytecode in Squeak they can be up to 4 bytecodes long (bytecode 143 - push closure num copied num args blocksize).
The Little Smalltalk bytecodes (also the Self ones) use an operand extension bytecode like in the old Inmos Transputer. Each bytecode has a 4 bit op code and a 4 bit value for stuff that needs one argument (like push literal) or uses the 4 bit value as its op code for stuff that needs zero arguments (like return top of stack). A special extension bytecode will combine its value with the value of the next bytecode when an 8 bit argument is needed. Or two extensions allow a normal bytecode to have a 12 bit argument. While not really fixed size, this is more regular than the Smalltalk-80 scheme.
[Selft source to bytecode compiler in the VM]
I always wondered about how much performance is gained moving the all the Compiler infrastructure into the VM.
There should not be any performance difference if the VM compiles instead of interpreting. And the source to bytecode translation is not in the critical path anyway since only short methods are compiled at any one time while interacting with the user that won't be able to tell the difference between 3 ms and 12 ms.
Didn't knew there was a DOS-only based Squeak. Any link out there to try?
https://web.archive.org/web/20050217200230/http://www.unicavia.com:80/Squeak...
Note that most Smalltalks that use a command line have a few helper methods defined to make things easier, but this is just Squeak without any GUI. So navigating around and doing stuff can be really awkward. I didn't test the download link to see if the zip is actually at archive.org, but I am sure I have a copy of the binary here if needed.
For GST I should note there is an interesting project using GTK which provides a gst-browser, although cannot say if now is part of GNU Smalltalk.
There were optional GUIs for Little Smalltalk as well and a friend added a web browser based GUI to LST4. -- Jecel