Tim Rowledge wrote on Sun, 29 Jul 2018 14:20:11 -0700
On 29-07-2018, at 1:50 PM, Eliot Miranda wrote: A particular case where this applies is Internet Of Things size devices.
A 16-bit version would be killer. What 16-bit processors are doing well in the market these days, if any?
I think that the TI MSP430 is the most popular 16 bit processor.
https://en.wikipedia.org/wiki/TI_MSP430
I don't think there's any need for 16 bit; pretty much all IoT stuff is either ARM (with quite a lot of it using v8 cores because you might as well) or ESP/tensegrity. The ESP32 would run a stack vm ok I suspect, just needing a well trimmed image. The tiny ARM machines could potentially even run a Cog vm when memory allows.
If you have a chip with 512KB of RAM, running a 16 bit image would get you roughly the same results as a 32 bit image in 1MB (actually less since Strings and Bitmaps would not change size).
It is not a good idea to use a 16 bit processor to run a 16 bit image because 64KB (or 128KB with word addresses) is just not enough address space for Smalltalk. At the very least you need to be able to have multiple segments like in the 8086 or the Alto. But a 32 bit or even 64 bit processor can easily run a 16 bit Squeak as long as it can read and write 16 bit values from/to memory without being awkward.
In Alan's 1972 proposal for the dynabook he put in very little memory and expected to swap to tape in a virtual memory scheme (inspired by the LINC). So if your microcontroller only has 512KB of RAM but does have access to a serial Flash chip you could use that as a really fast tape and swap objects between the Flash and RAM as needed.
The combination I think would have some value is 32bit oops for '64 bit' machines, ie using the better instruction sets. On ARM it would potentially make a big improvement to run AArch64 code but stay with 32 bit oops. You are of course somewhat at the mercy of your OS to be able to run within a 4Gb address space and not get silly.
You could also use 32 bit oops and an object table to allow images larger than 4GB. Or you could have 32 bit oops that are addresses relative to some base and then the image would be less than 4GB but could be placed anywhere in the address space.
In any case, I did some work on 16 bit images and a key issue was not running out of oops. In my case I aliased SmallIntegers and Symbols and also merged all the methods in a class into a single object.
I have also worked on 8 bit Smalltalks (with objects divided into groups with at most 256 different oops in a group to local and remote objects) but that was a case of diminishing returns.
-- Jecel