I've ported Squeak 2.3 to Amiga, more or less

tim Rowledge tim at rowledge.org
Sun Jun 4 17:36:23 UTC 2006

On 4-Jun-06, at 8:53 AM, Tim Johnson wrote:

> On May 30, 2006, at 5:02 AM, Bert Freudenberg wrote:
>> Oh I guess every VM hacker has seen this :) You might just copy  
>> the bit depth conversion routines from another VM.
> Yes.  I am working on this.  I think the main issue is Squeak's  
> PixMaps / BitMaps being little-endian, and the Amiga being big- 
> endian.  I am looking at the UNIX-VM source for tips (I found a  
> function there for 8-bit depth to 8-bit depth blits).  What's  
> strange is the Squeak 2.3 VM seems to not use ioHasDisplayDepth(),  
> so if I want to implement 16-bit/32-bit display depths on my Amiga  
> VM I might have to move up to 2.4+...

Ah, Squeak bitmaps are BIG endian, not little. The first  
implementation was 68k mac based and the PPC. Us little endian guys  
(ARM, x86 etc) had all sorts of fun developing efficient Squeak  
'Display' to actual glass transfer routines. You would most likely  
benefit most from looking at the Mac code for this stuff. You might  
need to convert the *pixel* format though since not every platform is  
RGB. RISC OS is little-endian BGR for example, some thing that took a  
lot of attention to resolve in the early days of Squeak.

>>> You may wonder why I used 2.3 ... It seemed to be the best choice  
>>> for a simple, well-documented, starting-from-scratch VM-building  
>>> scheme, with little-to-no dependence on plug-ins.  I am scared of  
>>> VMMaker (it seems to be designed to create/tweak a VM for an  
>>> already-existing platform, versus a new one?), plus there is  
>>> already much documentation on Interpreter>>translate.  Of course,  
>>> I am ignorant.
>> I think you're the first one porting Squeak to a new platform  
>> after VMMaker. So there might be indeed some overly helpful  
>> features in there.
>> Or is it not VMMaker, but rather that the VM got more complicated  
>> because we rely a lot on modules nowadays? I'm not quite sure what  
>> we actually need for a minimal functioning Squeak port.
> It seems to be both of these are the issue for me.  It is much  
> easier to get the VM up-and-running when I don't have to worry  
> about compiling dynamic libraries and making sure they mesh with  
> the Squeak modules system.  The Amiga has great support for dynamic  
> libraries, but I am no whiz with them.

You don't need to worry about any dynamic library stuff yet. Take a  
look at the code in the vmmaker C code tree in platforms/Cross/vm/ 
sqNamedPrims.c which uses functions in platforms/{various platforms}/ 
vm/sq{blah-blah}ExternalPrims.c. Now see about implementing the  
latter functions as nulls, returning 0 or false or whatever is  
appropriate. For example for ioFindExternalFunction(char*, void*),  
return (void*)NULL to say "I know nothing about this". Similarly for  
ioLoadModule.  I think ioFreeMOdule can just return 0.

Then you use VMMaker to assemble all the generated files with all  
plugins *internal*. That means that all their entry points are stored  
in an internal array of pointers and there is no use whatsoever of  
any external dynamic lib flummery. Simple.

All in all, VMMaker was designed to try to make it really simple to  
keep control of your port and to make it uniform and portable. One of  
the original aims was a scriptable app that would allow us to have a  
single machine generate the code for all platforms to suitable places  
and then have them compile each night automagically. It's certainly  
trivially scriptable (look up the swiki page about VMMaker as opposed  
to VMMakerTool) but I never did quite finish the cross-generating  
stuff, though I do have a changeset sitting around awaiting  
integration that is claimed to fix even that.

Good luck.

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Life by Norman Rockwell, but screenplay by  
Stephen King.

More information about the Vm-dev mailing list