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