Last updated at 9:31 pm UTC on 3 November 2006
Porting Squeak – Ian Piumarta's Chapter of Porting Squeak in the Squeak Book
The following is horribly out of date.
Be sure to also look at InterpreterSupportCode class >> macMinimal
As a quick start on the subject here is some mail advice I once sent on the subject.
As I expect you will notice very soon after taking a look at the Squeak VM
sources, it's pretty simple. Most of the code is produced for you and is
platform independent - at least, nobody has had problems so far.
The platform specific code can be broken down into two parts:-
a) relatively simple stuff such as starting up, reading commandline (if
appropriate) arguments, using fopen/fseek/fread/fclose to load the image,
open a window, read keyboard/mouse events, some way to do a few directory
b) more complex stuff like sockets, midi, serial, and so on.
The items in b) can be left till much later, as long as we can make
sensible 'null' routines to satisfy the linker. My recent comments on the
thread about cleaning up the VM are in large part aimed at reducing this
problem. I can certainly help with producing an image to help with this.
For the part a) items, a normal ANSI C library will suffice for most of the
file handling. All the float and arithmetic etc is plain ansi. We need to
be able to return a sensible path string for the VM and the image file -
they are used to work out relative paths etc later. Basic directory
enumerations are needed, a quick look at the sqXXXXDirectory.c files for
the different platforms will explain quite well. Some way to allocate a
_big_ chunk of memory is required - most of use find malloc() to be ok.
This will be typically a malloc of image file size + 1 or more MB for
working room. You can manage with less, but it hurts performance and
The most tricky work is normally that relating to connecting to the display
and input events. We need to be able to copy pixels from the Squeak display
bitmap to the actual machine display memory. Complications include things
like the Squeak display being 16bpp when the machine is displaying 8bpp, or
vice versa. It is feasible during early development to set things up to
match the bpp of the two. Input events need to be translated to map key
presses reasonably closely to Mac key numbers, in order to get metakey
events to work. This can be a right bugger to get done correctly!
Basically, if you can see how to write a prog that will:-
to start with)
- open a file and read it into a large malloc'd chuink of memory
- work out the strings for the path to the VM and the loaded file
- open a window (I'd go for taking over the screen as directly as possible
top/left/right/bottom values and maybe converting bpp, and maybe converting
- copy a bitmap from malloc'd memory to the screen, using arbitrary
from big-endian to little endian at the same time
then we're in business. Everything else is negotiable later.
- read the keyboard and pointer values and convert them to the 'right' form
If you've already been looking at Squeak then you already have the sources
for the Mac built into the system. The PC sources are usually available at
ftp://alix.inria.fr/pub/squeak as are various unix sources. My Acorn sources
are off the Squeak page on my website (see below). Since I have never bothered
to do the sound, serial or midi stuff for the Acorn, the relevant files would
make good null files to start with.
The following email describes the tasks to do when porting Squeak to a new platform
Subject: Porting Squeak
From: John Maloney
At 2:46 PM +0100 11/23/99, Stefan Rieken wrote:
>> I'm sure many people would love to seen an Amiga port.
>That's what I feel, too, but please don't pin me up on it... I'm still
>very scared of "someone-else's code", however small ;-D
I feel the same way about "someone-else's code". But the thing that
makes Squeak so portable is that the the bulk of the code–the code
for the VM itself–just compiles and runs everywhere. So you don't
need to look at that. If you have a C compiler and a Squeak image,
you've got everything you need to generate and compile "interp.c".
If this compiles–and it should–then you just need to link in three
other source files to get Squeak running:
sqAmigaMinimal.c – *the only one you need to write!*
sqFilePrims.c – file primitives (supplied version uses C stdio)
sqMiscPrims.c – automatically generated primitives (optional)
SInce the supplied "sqFilePrims.c" will probably work and the
generated "sqMiscPrims.c" almost certainly does, the task is
really clear: implement sqAmigaMinimal.c. The way to do this is
to rename sqMacMinimal.c, cut out all the Mac-specific code,
and implement it from scratch for the Amiga. There are only
about twelve i/o functions that you need to implement, and six]
of these are optional!
Please don't take this as pressure. I don't have an Amiga, so I
have no personal stake in this. But I wanted to tell you that, far
from the big, scary project it could be, porting Squeak is an
amazingly localized and modularized task. Long ago, I tried and
failed to port various free Smalltalks to the Mac. In each case,
I got tons of compiler errors, made my best guesses about how to
fix them, and ultimately got a non-functional executable that
I didn't have the courage to debug. If Squeak is like this, please
give up right away! But I gather from talking to people who have
ported Squeak that it goes very smoothly. The only two hurdles you
might run into are (a) an old C compiler that doesn't support 32-bit
ints or (b) a limit on the amount of contiguous memory that an
application can allocate (the Palm Pilot has this problem, and
we haven't yet ported Squeak to it as a result).
P.S. I'm sure the folks who have ported Squeak will chime in if
I've misrepresented the difficulty. :-> (Note that I'm only talking
about getting Squeak running, NOT implementing the optional things like
sockets and sound I/O. These DO require some work since you have
to dig into some of the darker corners of your native OS...)
P.P.S. I was wrong about the size of sqMacPrimitive.c. It isn't
2000 lines, it is only 1153! With many lines of comments.