Interval Smalltalk redux (was "SqueakOS")

Tim Rowledge tim at sumeru.stanford.edu
Fri Oct 4 04:04:05 UTC 2002


Tommy Thorn <thorn at meko.dk> is claimed by the authorities to have written:

> Tim Rowledge wrote:
> 
> >>Not that I'm suggesting it, but FPGAs have progressed significantly in 
> >>recent years. Yesterdays ASICs might be reimplementable with todays 
> >>FPGAs (at a considerbly lower NRE cost).
> >>    
> >>
> >If you were thinking of some magical hardware interpreter, forget it.
> >
> 
> I'm not thinking of anything, just replying to your comments about 
> custom hardware which used expensive ASICs.
I hope I didn't make it sound like I was 'getting at' you in any way!
Your remarks stirred up a recollection of the almost innumerable times
that I've heard someone suggest that all that is needed is a special cpu
to execute bytecodes and all would be well; something that simply isn't
even vaguely true and has in fact been tried on several occasions to no
good effect. Just for starters, there are minor things like primitives
and memory management that don't have much use for bytecode interpreting
hardware.
> 
> You said that the native code compiler wouldn't be useful for most 
> people and I was asking if it required special hardware support, or if =20
> the reason it wasn't useful was simply that most people don't have ARMs.
Oh, I don't think that's quite I intended. The native code compiler we
made at Interval was (is) able to output C source code, ARM assembler
text or ARM object code ready to run. Alan Purdy (for it is he that
wrote 90+% of it) asserts that it would be fairly simple to retarget the
assembler output to any cpu. No special hardware was harmed in the
creation of the compiler. Several people have grabbed copies to look at
it and I think at least one person has decided to take their own hack at
the concept. Note that it was not very much to do with the core vm but
rather intended to compile device drivers delivered on the fly by
devices added to the net that the Trio pad was acting as controller for.

> However, now that you brought it up, making a hardware (FPGA) 
> implementation of Smalltalk would indeed be fun (it looks like Jercel is 
> doing that) and it *might* make sense in some settings. Why do you think 
> Xilinx and Altera spend millions to develop their softcores (MicroBlaze™ 
> and Nios respectively) when obviously their performance can't reach that 
> of a substantially cheaper of-the-shelf part? Softcores make sense for =20
> example for an embedded device where board space is at a premium and 
> there already is a substantiel need for custom logic.
Exactly; a very special case where the financial logic pushes the other
way to 'normal' desktop machines. Jecel is one ofthe very very small
number of peopleI belive could even come close to making special purpose
hardware actually deliver. SUN tried at least acouple of times for java
nad seem to have failed. SOAR was not very effective, Sword/32 failed,
iAPX432 was a dog, etc etc. None of which means that nobody will ever
suceed, it just means I won't be putting any of my millions into the
project.

> 
> Of course for a custom general purpose system there really is no way to 
> beat the performance of a $100 x86 chip.
Sad, isn't it?
> What special hardware support did the _Interval_Smalltalk_ require was =20
> what I meant. The StrongARM doesn't exactly have bandwidth nor big 
> on-chip caches and the MediaPad's custom (external) ASIC clearly didn't 
> implement a big cache.
No special hardware at all from the point of view of the Smalltalk. The
nearest part you could point at was the video memory controller where I
persuaded the hardware team make it such that I could write to control
registers to set the addresses where the display bits would live, rather
than having to tolerate whatever somebody else wanted. That meant I
could have the screen buffer in ordinary object memory space.
SA has pathetic onchip caches (which is annoying since the cpu core
occupies less that 50k gates and could fit in the top left corner of a
big ram chip in any decently organised world) but does have
reasonable memory bandwidth given its market. ARM10 & 11 are much
better. If somebody would up the money it would be most enjoyable to
build something from them.


tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: MII: Mask all Interrupts and then Interrupt




More information about the Squeak-dev mailing list