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
squeak-dev@lists.squeakfoundation.org