
Bare metal Smalltalk-80 port to the Raspberry Pi - salgernon
https://github.com/michaelengel/crosstalk
======
johndoe0815
Author here - happy to answer your questions...

Beware, there's a bug on ARM11-based Raspberry Pis (BCM2835 on Pi 1/Zero/Zero
W and CM1) that crashes the VM when executing drawing functions. I'm currently
investigating the problem.

~~~
aarchi
FYI, your commits are signed with "Your Name <you@example.com>". You'll want
to fix your git config. For these existing commits, you can use git-filter-
repo [0] to rewrite the author name and email.

    
    
        git filter-repo --force --name-callback 'return b"Name to use"' --email-callback 'return b"emailtouse@example.com"'
    
    

[0]: [https://github.com/newren/git-filter-
repo](https://github.com/newren/git-filter-repo)

~~~
johndoe0815
Oops, good catch - thanks!

------
salgernon
"Past" submission didn't find anything, but the author had an "Ask HN" the
other day:
[https://news.ycombinator.com/item?id=23806323](https://news.ycombinator.com/item?id=23806323)

~~~
johndoe0815
Thanks for mentioning this - I would certainly appreciate input on this.
Testing software on half a dozen different Raspberry Pi models currently
involves quite a bit of cable un- and replugging...

------
endlessvoid94
This is so cool.

We know that smalltalk message passing was inspired by biology, and the
ultimate design vision was for objects to be ephemeral machines themselves.

Would it be possible to create a farm of Pis, where some objects were on some
subset of them, and some objects on another? Even a simplistic example with
two Pis, with the object space split between them? Can we use the network to
perform language-level message passing?

~~~
johndoe0815
That idea crossed my mind, too - in fact, I have a SOPINE cluster here [1]
(built by Pine64) that would be a good platform for experiments with
distributed objects. The Turing Pi is a very similar product for Raspberry Pi
Compute Modules [2], just a bit more expensive. Of course, this approach would
work as well with a bunch of Raspberry Pis connected via an Ethernet switch.

There was some research in the late '80s on building a distributed Smalltalk
[3,4] which is a nice inspiration for such a project. So it's definitely
possible to build a distributed Smalltalk and it would be interesting to
investigate how well such a system would work given today's hardware
performance and networking throughput.

Distributed Smalltalk is just one of the ideas for building distributed non-
shared-memory systems from the 1980s. This was an interesting time in general,
people experimented with different approaches for distributed systems hardware
and software. Some examples include the inmos Transputer, which had bit-serial
communication links [5] and support for CSP-based (paper [6] and book [7])
communication in the instruction set (later these ideas were picked up again
by David May and his colleagues for the XMOS embedded processors [8]); on the
operating system side there were systems such as Plan 9 and Inferno [9],
invented by the Unix team at Bell labs, Tanenbaum's (the Minix guy) Amoeba
[10] and Ousterhout's (otherwise known for tcl/tk) Sprite [11].

Some of these ideas seem to be gaining popularity again (e.g., CSP-based
communication for goroutines [12]) and I hope my students here are interested
in investigation these approaches to building distributed systems, e.g. as an
alternative platform for IoT applications.

(edit: links reformatted)

[1]
[https://www.pine64.org/clusterboard/](https://www.pine64.org/clusterboard/)

[2] [https://turingpi.com/](https://turingpi.com/)

[3] Marcel Schelvis, Eddy Bledoeg, The Implementation of a Distributed
Smalltalk, ECOOP 1988 - www.lirmm.fr/~ducour/Doc-
objets/ECOOP/papers/0322/03220212.pdf

[4] John K. Bennett. 1987. The design and implementation of distributed
Smalltalk. SIGPLAN Not. 22, 12 -
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.4288&rep=rep1&type=pdf)

[5] [http://www.transputer.net/](http://www.transputer.net/)

[6] Hoare, C. A. R. (1978). "Communicating sequential processes".
Communications of the ACM. 21 (8): 666–677 -
[https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf](https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf)

[7] Hoare, C. A. R. (1985). Communicating Sequential Processes. Prentice Hall.
ISBN 978-0-13-153289-2 - [http://www.usingcsp.com/](http://www.usingcsp.com/)

[8] [https://en.wikipedia.org/wiki/XMOS](https://en.wikipedia.org/wiki/XMOS)

[9] Pike, R.; Presotto, D.; Dorward, S.; Flandrena, B.; Thompson, K.; Trickey,
H.; Winterbottom, P. "Plan 9 from Bell Labs". Bell Labs Technical Report -
[https://css.csail.mit.edu/6.824/2014/papers/plan9.pdf](https://css.csail.mit.edu/6.824/2014/papers/plan9.pdf)

[10] Andrew S. Tanenbaum, M. Frans Kaashoek, Robbert van Renesse and Henri E.
Bal (1991). The Amoeba distributed operating system — a status report.
Computer Communications 14 -
[https://www.cs.vu.nl/pub/amoeba/Intro.pdf](https://www.cs.vu.nl/pub/amoeba/Intro.pdf)

[11] Ousterhout, John (1992). "Sprite Retrospective". University of California
at Berkeley -
[https://www2.eecs.berkeley.edu/Research/Projects/CS/sprite/r...](https://www2.eecs.berkeley.edu/Research/Projects/CS/sprite/retrospective.html)

[12] James Whitney, Chandler Gifford and Maria Pantoja, Distributed execution
of communicating sequential process-style concurrency: Golang case study, The
Journal of Supercomputing volume 75, pages 1396–1409(2019)

~~~
endlessvoid94
Thank you for this synopsis! It's been several years since I've had the time
to really dig into the (extensive) prior work in this area. You've given me
some great links!

I have the smalltalk blue book on my shelf and have always, always wondered
about the possibility of bringing back some of the radical ideas from the
60s/70s/80s in a language like Ruby (being popular). Live objects and
snapshots are the two that I was most enamored with way back in the day, but
I'm sure there are lots of others.

This isn't terribly old (2014) but would love thoughts on it (if you have
any!). It's a prototype of a smalltalk-like "System Browser" implemented in
Ruby and Qt on OS X:

[https://www.youtube.com/watch?v=2xC5B5t5Rq8](https://www.youtube.com/watch?v=2xC5B5t5Rq8)

The idea is that in the same way that Clojure is a sort of "improved" lisp on
the JVM for performance reasons, syntax enhancements, and access to the
standard library of Java, I see no reason why Ruby couldn't be the same thing
for Smalltalk. Access to the ruby standard library, bringing an interactive
live environment to a vibrant programming community and prioritizing
interoperability with the modern world (as opposed to much of the smalltalk
world which still sort of sits a "world" apart)

~~~
johndoe0815
Thanks for the link - that looks really interesting! I will have to give it a
try to make some informed statement, but I think it's definitely worth looking
at. Some parts of Ruby also seem to be inspired by Smalltalk, so that might be
a good fit. There's also a Smalltalk-80 VM by Rochus Keller based on the Lua
JIT compiler [8] (and a very nice Qt-based Smalltalk browser), that might also
go in the same direction.

In general, I think there are two major interesting aspects in systems like
the Ruby system browser and Smalltalk. On the one hand one can discover the
system - you can dig into the implementation without using a disassembler or
reverse engineering - and on the other hand it is possible to change the
system behavior at runtime (though this is, of course, dangerous).

I would love to see at least the discoverability aspect to be more pervasive
in standard operating systems. There are already partial approaches to this,
such as DTrace/systemtap and the proc filesystem, but having discoverability
as a first class concept - which might fit well to Plan 9's (and to some
extent Unix's) "everything is a file" approach - would be nice.

The ability to change the system at runtime is also fascinating. I already
mentioned the research of Stephen Kell in another comment [1] and there's a
great video of one of his talks [2] in which he shows his approach to
dynamically alter a program's behavior on Unix using shared library mechanisms
(you can find the code on github [3]). I worked on related ideas in my PhD
thesis 15 years ago, maybe it's time to dig these out again ;-).

However, these dynamic modifications should also be safe and accessible. I'm
thinking of something related to AppleScript here, which allows to
automate/scripts an amazingly large number of functions on OS X. Combining
this with a browser that enables a user to discover the accessible OS
functionality seems to be a good idea.

The persistent image ideas might also be useful again in the context of
persistent main memory systems, which are becoming available now, e.g. with
Intel Crosspoint [6]. There's so much prior work in persistent object systems
also on the OS side that is almost forgotten nowadays, such as the Eumel/L3
system by Jochen Liedtke [4] (the inventor of the L4 microkernel) and the
BirliX OS [5]. Sounds like a good time to re-evaluate these 1980's-era
approaches.

I see some more recent work, such as Ksplice [7], as interesting related
technology. What is really missing is an integration of many of these ideas
into a consistent system.

    
    
      [1] https://www.cs.kent.ac.uk/people/staff/srk21/
      [2] https://www.youtube.com/watch?v=LwicN2u6Dro
      [3] https://github.com/stephenrkell/liballocs
      [4] Jochen Liedtke, A Persistent System in Real Use - Experiences of the First 13 Years, Third International Workshop on Object Orientation in Operating Systems 1993 - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7112
      [5] W. E. Kühnhauser, H. Härtig, O. C. Kowalski, W. Lux, Mechanisms for Persistence and Security in BirliX, International Workshop on Computer Architectures to Support Security and Persistence of Information 1990, https://link.springer.com/chapter/10.1007/978-1-4471-3178-6_22
      [6] https://en.wikipedia.org/wiki/3D_XPoint
      [7] Arnold, Jeff and Kaashoek, M. Frans, Ksplice: Automatic Rebootless Kernel Updates, EuroSys 2009 - https://ksplice.oracle.com/doc/ksplice.pdf

~~~
scroot
> However, these dynamic modifications should also be safe and accessible. I'm
> thinking of something related to AppleScript here, which allows to
> automate/scripts an amazingly large number of functions on OS X. Combining
> this with a browser that enables a user to discover the accessible OS
> functionality seems to be a good idea.

I have been thinking a lot lately about HyperCard and Applescript. They
represent a line of thinking that has more or less been abandoned by the
commercial side of personal computing, which is really too bad. Applescript
still exists, sure, but they've really let it die on the vine. Back in the
late 90s I hoped they would make the whole front end of the OS in a HyperCard
like system, so that everything could be manipulated by the user. Don't like
how this part of the Finder works? No problem, just peel back a layer and see
what's going on.

~~~
johndoe0815
That's definitely a shame - and, as far as I know none of the open source
Unix(-like) systems has exposed a similar functionality. I think D-bus should
enable something like it, but I haven't had a closer look at that...

~~~
endlessvoid94
The possibilities of bringing back this way of thinking are tantalizing to me.
The intersection of end user programming a discoverable system with the
pervasiveness of the cloud could be really awesome. Something like a mashup of
Automator, Hypercard, Heroku, and Smalltalk.

The only reason this doesn't exist is simply that nobody has decided to build
it yet.

~~~
hhas01
Working on it…

[https://github.com/hhas/iris-script](https://github.com/hhas/iris-script)

~~~
endlessvoid94
this is really cool! thank you for sharing

------
7thaccount
Seems like a neat idea. I've always wanted a tiny LispOS or SmalltalkOS that I
could carry around and use on a Pi. I just wish it would also have the modern
necessities like web browser...etc.

~~~
johndoe0815
One of the inspirations for my "crosstalk" Smalltalk system was Lukas
Hartmann's Lisp-based "Interim OS" bare-metal system for the Raspberry
([http://interim-os.com/](http://interim-os.com/)), so you might want to give
this a try.

I think Interim only runs on the Raspberry Pi 2 at the moment; porting Interim
OS to use the circle library (which I use for crosstalk) should also be
feasible and would help to support other Raspberry versions.

Lukas is also the creator of the MNT Reform open source notebook (using a
Freescale i.MX8 quadcore ARM Cortex-A53) - see
[https://www.crowdsupply.com/mnt/reform](https://www.crowdsupply.com/mnt/reform)
for the currently running crowdfunding campaign.

Modern web browsing is, of course, more complex than the whole rest of the
Smalltalk system...

~~~
skissane
I really like language-based operating systems. It is cool you did this.

My ideal though would be – it is all written in the language
(Smalltalk/Lisp/whatever), with no use of other languages such as C/C++
(except possibly assembler, in which case my ideal is it comes with an
assembler written in the language); and it is fully self-hosting in terms of
the build process.

Of course, I realise my ideal is a lot more work than what you've done, and
none of us has infinite time in which to tinker with things...

(I myself have some toy programming language interpreters I wrote, some in C,
some in Java – I keep on thinking "oh, I should get rid of the C/Java, make it
generate native code and then rewrite its core in itself" – but that's a lot
of work and I've never had time for that.)

~~~
johndoe0815
Great that you like it - thanks! Some of the work of Stephen R. Kell at Kent
University also covers language-based OSes and how some of their ideas might
be adapted in Unix (see [1] and [2]).

The Smalltalk-80 VM is specified in Smalltalk itself (in the "Blue Book" [3])
and the Squeak VM (a Smalltalk derivative) was written in a subset of Squeak
itself [4].

The great thing is that it's a lot of fun to build this (at least for me)
because it's actually possible to understand the whole system. I hope my
students will have fun working on topics like these, too.

[1] Unix, Plan 9 and the Lurking Smalltalk. In L. de Mol and G. Primiero
(eds), Reflections on Programming Systems, Philosophical Studies Series,
Springer -
[https://www.cs.kent.ac.uk/people/staff/srk21/research/papers...](https://www.cs.kent.ac.uk/people/staff/srk21/research/papers/kell19unix-
personal.pdf)

[2] The operating system: should there be one?. In Proceedings of the 7th
Workshop on Programming Languages and Operating Systems, ACM, November 2013 -
[https://www.cs.kent.ac.uk/people/staff/srk21/research/papers...](https://www.cs.kent.ac.uk/people/staff/srk21/research/papers/kell13operating.pdf)

[3] Adele Goldberg and David Robson, Smalltalk-80: The Language and its
Implementation, ISBN 0-201-11371-6 -
[http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....](http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf)

[4] Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay. “Back
to The Future: The Story of Squeak, A Practical Smalltalk Written in Itself.”
In Proceedings of the 12th ACM SIGPLAN Conference on Object-Oriented
Programming (OOPSLA) 1997, 318–26, 1997 -
[http://files.squeak.org/docs/OOPSLA.Squeak.html](http://files.squeak.org/docs/OOPSLA.Squeak.html)

------
esfandia
Very neat! How much work would it be to write ROS bindings so you could
control robots easily with it? Googling around, I found one team that has done
it with Pharo: [http://car.imt-lille-
douai.fr/category/software/pharos/](http://car.imt-lille-
douai.fr/category/software/pharos/)

~~~
johndoe0815
Robot control would be a fascinating applications (but my students had to
program our robots in C [1] ;-)).

I am not an expert in ROS, but there have been other projects using Smalltalk
for robotics, such as NXTalk [2] and a Squeak-based system [3]. A more general
paper discusses the challenges in using Smalltalk for robotics applications
[4].

So it should be possible to do this on the Smalltalk-80 bare-metal port. One
problem that will definitely show up, though, is the limited memory space and
number of objects of Smalltalk-80, since it uses a 16 bit VM. Modern robotics
applications involving complex SLAM approaches, object recognition or LiDAR
might be a bit challenging for this, so I think a more modern 32 bit based VM
such as Squeak or Pharo is more appropriate here.

(edit: links reformatted)

[1] [https://www.hs-coburg.de/news-detailseite/roboterrennen-
im-l...](https://www.hs-coburg.de/news-detailseite/roboterrennen-im-
labor.html) (sorry, in German only)

[2] [https://www.hpi.uni-
potsdam.de/hirschfeld/projects/nxtalk/in...](https://www.hpi.uni-
potsdam.de/hirschfeld/projects/nxtalk/index.html)

[3] Joaquin Sitte, Robotics and Robotics Education with Smalltalk, AMiRE 2005

[4] LaLonde, W., Thomas, D., Johnson, K., Smalltalk as a programming language
for robotics?, IEEE International Conference on Robotics and Automation, 1987
-
[http://www.menneske.org/projects/bachelorsproject/Articles/s...](http://www.menneske.org/projects/bachelorsproject/Articles/smalltalk%20as%20a%20programming%20language%20for%20robotics.pdf)

------
slobiwan
I love the idea of bare-metal ports to the Pi. I saw snakeware posted here not
too long ago. Are there other examples? ColorForth would be interesting as
well

~~~
guenthert
Could someone share what one gains with such 'baremetal' ports? I see only the
loss of common ground, well tested libraries and functionality.

It doesn't take a lot of Linux know-how to boot you favorite interpreter from
/etc/rc.local or replacing /sbin/init (losing the libraries again, but at
least keeping the kernel with the filesystem, network support and all the
hardware drivers).

~~~
johndoe0815
In general, lower code complexity results in fewer bugs and security problems,
less code implies lower resource usage, so you could run the system with a
smaller main memory, a slower CPU or lower power/energy consumption. In
addition, if you plan to target real-time applications, setting up Linux to
guarantee your real-time constraints is not trivial.

All of this is not that relevant for running Smalltalk-80 on the Pi, since
Smalltalk was running happily on 16-bit machines with one or a few MBs of RAM.

So I guess the ultimate reason for doing this is "it can be done" \- for the
fun of hacking :-).

------
cmrdporcupine
I wonder if there's anything neat that could be done in the Smalltalk VM that
could take advantage of the BCM SOC's VPU etc. hardware ... hmm...

~~~
johndoe0815
Accelerating the Smalltalk VM BitBlt primitives using the VPU would certainly
be interesting. Currently, drawing is rather slow since lots of the
functionality is implemented in interpreted bytecodes and rendering to the
framebuffer is completely unoptimized.

~~~
zackangelo
Slight tangent, but: I first encountered a function named BitBlt when using
the Win32 C API a long time ago. I had no idea that it originated in
Smalltalk-72 in 1975 and the function name was just carried forward into the
Windows API.

~~~
pinewurst
A very long time ago, I ported Smalltalk to Windows and had to map Smalltalk
BitBlt to Win32 BitBlt.

~~~
johndoe0815
I had a quick look at the Win32 BitBlt API and it seems to be quite similar.
Can you remember how much work was actually involved in mapping the Smalltalk
primitives to Win32?

~~~
pinewurst
I probably shouldn't have described it quite like that.

This was in the days of Windows 2 (1988 or so) and I was hacking PPS Smalltalk
to support larger, non-VGA displays. I ran the VM in 386 protected mode,
because it needed large memory, where it blt-ed to an upper memory frame
buffer. This was sort of a "bounce buffer" which in turn was blt-ed onto a
Windows canvas by my Windows app which also reflected input events up to the
VM.

Bill Gates was impressed when he saw a demo (or so I was told). Of course, he
didn't realize the level of hackery involved to make it happen.

------
ekvintroj
Love this! awesome!

------
soapdog
Anyone got photos or screenshots of it running :-) I am quite curious.

~~~
johndoe0815
The screenshots are boring - it looks like any other Smalltalk-80 system :).

A picture of the setup to test one of my earliest versions can be found in my
blog article (this needs to be updated) [1] and another more current one in my
linkedin article [2] (I hope the direct link to the picture works for you).
Both pictures at home using a crappy TV in Corona times, unfortunately...

[1] [https://www.multicores.org/blog/smalltalk-on-a-small-
compute...](https://www.multicores.org/blog/smalltalk-on-a-small-
computer.html)

[2] [https://media-exp1.licdn.com/dms/image/C4D12AQF-
SUDkziblKg/a...](https://media-exp1.licdn.com/dms/image/C4D12AQF-
SUDkziblKg/article-inline_image-
shrink_1000_1488/0?e=1600300800&v=beta&t=5j4PEoZA5yPI6kCTJh2FKse_Ewfn_TqsLih5rLerPJg)

~~~
soapdog
Thanks a lot! :-) I will try to run here as well. Excited to see more people
doing stuff with Smalltalk.

