On Sat 14 Nov, Jerry Bell wrote:
> I'm new to the list, but I've found some references to 'bare-metal' Squeak
> implementations.  Is anyone working on this?
Yup. We've been doing stuff along those lines for a while now. We have
custom hardware to run it on and can also run the same images on 'normal'
machines, though without the sort of full-control you can get with your own
h/w.
> 
> What would be the ideal kind of kernel to run Squeak on top of?  I know
> portability would be on the top of the list.  How about single vs.
> multithreaded? Maybe even something completely different to take advantage
> of the unique needs of a smalltalk environment?
We sort of started from the ARM/Digital 'Angel' + a sort-of port of
microC/OS (I always think of it as 'mucus' because it snot an OS) and then
waltzed off into the sunset.

> 
> I assume that a goal would be to eventually make Squeak classes that could
> generate the low-level kernel code for a given platform, much like the
> interpreter generator.  Then, to port to another platform you would simply
> define the characteristics of that specific platform.  All from within
> Squeak.  That would be.... nice.
It was, it does and it is. Mix in the direct-compile for primitives that
Hans-Martin has also spent some time on along with something like Andreas'
pluggable prims and yo uget quite a useful improvement on DLLs.

If there is serious interest in acutally using this sort of thing (not to
mention handling the work of writing code-gen backends for non-ARM cpus) we
might be able to release the code translator. Be warned - it requires quite
a bit of syntactically rejigging the VM code, like getting rid of all the
#cCode: stuff. Personally I think that makes it worth doing by itself :-)

tim

-- 
Useful random insult:- Couldn't hit water if he fell out of a boat.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>