3 ms·
Author here, feel free to ask any questions you have :). It's amazing this little project shows up again here. So far, I received a lot of very positive and fr
by johndoe0815 4y ago
Author here, feel free to ask any questions you have :).
It's amazing this little project shows up again here. So far, I received a lot of very positive and friendly feedback about this little pet project of mine.
The whole project would not have been possible without the work of Rene Stange, who created the circle bare-metal library for the Raspberry Pi (https://github.com/rsta2 https://github.com/rsta2) and Dan Banay, who created a C++ implementation of the Smalltalk-80 VM (https://github.com/dbanay/Smalltalk https://github.com/dbanay/Smalltalk). I mostly hacked together some glue code...
If you want to dig deeper, the Blue Book by Adele Goldberg and David Robson (scan provided by Stephane Ducasse, thanks a lot!) is _the_ reference on both the language and the structure and implementation of the underlying bytecode VM: http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....
Beware, though it's fully functional, crosstalk is still limited by constraints of the original Smalltalk 80 system - e.g. in terms of color (black and white only), possible screen resolution (2^20 pixels, the system crashes if you try to increase the resolution beyond this) and available memory (~1 MB!).
Nevertheless, I think it's a rather authentic reproduction of a more than 40 year old system and I learned (in a comment thread on a completely different topic) that one of our fellow hackernews regulars used it to teach his kid Smalltalk programming - love it! I haven't tried to optimize it significantly, so there's no JIT compiler or bitblit acceleration using the Raspberry Pi GPU.
There's a more modern bare-metal Smalltalk implementation based on Squeak (https://squeak.org https://squeak.org) for the Raspberry Pi by Pablo Marx, though this seems to have some stability problems according to the author: https://github.com/pablomarx/RaspberrySqueak https://github.com/pablomarx/RaspberrySqueak
Finally, if you are interested in alternative bare-metal language/OS environments for the Raspberry Pi, you could also give Lukas Hartmann's (of MNT Reform notebook fame) Interim OS a try: http://interim-os.com http://interim-os.com
- b33j0r 4y agoI’m baffled that I never saw the name Alan Kay. Given, I did not read everything. Expected it to be in bright lights, based on the story I was told ;) (That’s my malformed question)
- johndoe0815 4y agoThere are a lot of famous persons involved in the history of Smalltalk, without who we would have nothing to write about here. Alan Kay was certainly the driving force, but let's not forget Dan Ingalls, Adele Goldberg, Ted Kaehler, Diana Merry, Scott Wallace, and Peter Deutsch (who is also the founder of Aladdin Enterprises and creator of Ghostscript) - and all others I forgot to mention here... One other very important person related to this endeavor is Mario Wolczko, who ported Smalltalk 80 to the Perq workstation (his master thesis at Manchester University) and extracted and distributed the Smalltalk 80 VM image - see http://www.wolczko.com/st80/ http://www.wolczko.com/st80/. Later, Mario worked on the SELF language (and many other projects, of course) at Sun Labs.
- Stratoscope 4y agoThank you for mentioning Scott! He is an old friend of mine, but I'm afraid we have been out of touch the last few years. (My fault, not his.) You have reminded me to drop him a note to say hello.
- bogomipz 4y agoThanks for the great links and background. I had a couple of questions: I'm guessing The Blue Book is "thee" book for learning Small Talk then? Are there other resources folks would recommend as well perhaps other books or online resources? Regarding the bytecode VM, was this one of the earliest languages that ran in its own bytcode VM then? Was this as innovative as it sound for the time? Did it have JIT optimizations as well?
- int_19h 4y agoThe idea of bytecode dates back to mid-60s. It was already widespread in the 70s because it was a common way to implement Pascal in particular.
- bogomipz 4y agoAh neat, this is fascinating. I had never really thought about where they actually came from. I suppose I just assumed it was Java. For anyone else who is curious - the roots of bytecode are in the BCPL compiler and the intermediate O-codes it generated: https://handwiki.org/wiki/O-code https://handwiki.org/wiki/O-code
- int_19h 4y agoIt should be noted though that bytecode from that era would often be represented as text rather than binary in storage. If I remember correctly, UCSD p-code was literally just numbers spelled out in text with spaces between them - something that could be conveniently read by just about any language and system around, usually via a primitive like Pascal's own Read function, or BASIC's INPUT. It makes it that much easier to move from platform to platform when there's no agreement on things that we take for granted these days, like number of bits in a byte etc. But that also makes it harder to recognize what you see when you're used to binary bytecode like JVM or CIL.
- pinewurst 4y agoThe original Smalltalk-80 VMs (Xerox and others) did not have JIT. Deutsch and Schiffman did the 1st JIT one (PS) that was the parent of the ParcPlace HPS VMs.
- infinite8s 4y ago> Beware, though it's fully functional, crosstalk is still limited by constraints of the original Smalltalk 80 system - e.g. in terms of color (black and white only), possible screen resolution (2^20 pixels, the system crashes if you try to increase the resolution beyond this) and available memory (~1 MB!). I would imagine it would be less work to start with an early Squeak to remove these constraints than to try upgrading this system to remove these old limits?
- johndoe0815 4y agoI wanted to keep the system as close to the original as possible, but some extensions such as increasing the available memory space and screen resolution would be nice even for the original system. It would also be interesting to implement the early ideas for a JIT compiler. Starting with Squeak is probably the easier way if you want advanced features such as color or network connectivity - still, there might be some interesting ideas to improve the system. One idea I had was to accelerate the bitblit functions using the Raspberry Pi's GPU. Currently, crosstalk uses a simple framebuffer and the runtime has to convert all monochrome bitblit operations into color ones since the Raspberry GPU doesn't have a 1bpp mode. Support for multiple cores (available in all but the most simple Raspberry Pis) would also be nice. Here, the Roar system (https://github.com/smarr/RoarVM https://github.com/smarr/RoarVM) might be an interesting starting point. Let's see if I can find some students who want to work on some of these tasks... but my students are nowadays rather interested in Rust and RISC V :) (though a port of crosstalk to the Allwinner D1/Nezha and related boards and JH7110/Vision Five 2 is on my to-do list).