Porting Squeak to Bare Hardware

Jay Carlson nop at nop.com
Tue Oct 31 16:56:13 UTC 2000


Mark Guzdial writes:

> > > -- it's 32 bit internally, 16 bit data path.
> >
> >It's 8 bit internally, with various kludges to support expanded
> memory and a
> >bolt-on-the-side math unit that you can push 16*16 multiplies and 32/16
> >divides into.  (Actually, their expanded external addressing is
> a kludge on
> >top of the 8051's external memory kludge....)
> >
> >It is one scary CPU for C code that thinks mostly in terms of 32-bit ints
> >and void*s.
>
> Ohhh -- now that I *didn't* know.  Hmm, maybe we should check out
> these other board options you mention...

Well, maybe I overstated.  It's the C compiler's job to handle the whole
pointer/int abstraction, and if sdcc does provide the C programmer with 32
bit ints and 32 bit void*, Squeak should work.  The thing to be concerned
about is code density and performance.   I mean, the 22-bit addressing
through DPTR0/1 on the TINI chip is not like the HC11's 16-bit limits where
it would be very difficult to produce a C compiler to automatically address
more than 64k of memory.  But it takes at least four instructions to store
an int to memory, and that's not counting how much effort it takes to get
DPTR pointing at the right place.

I haven't read the docs on the TINI Java implementation yet, but I'd guess
their oop is 16-bit and indirect.  That's probably not a bad way to go for a
smalltalk implementation on that hardware.

I was hunting around for other boards, and I think the easiest way to find
reasonable ones are boards that already support uClinux.  Whatever processor
architecture they have on them, they'll have a known-good C compiler that
supports 32-bit memory addressing.

Of course, if you do a port to the ucsimm, a port to bare palm hardware
would probably fall out too. :-)

Jay





More information about the Squeak-dev mailing list