In message <8525696D.005995ED.00 at kanmta01.software.mitel.com>
          Dean_Swan at Mitel.COM wrote:

>   I think the OSKit would be substantial overkill for the ARM based
>   gameboy.  All the hardware is custom, so you won't exactly be able
>   to re-use device drivers, and probably won't want to "pay" for the
>   extra overhead either.  I suspect the same would have been true for
>   the Interval Pad, unless you were using PC-ish hardware for your
>   peripherals.
Could be, but I suspect that having a working system to examine would
have saved a bundle of time. You wouldn't (well maybe you would)
beleive how much time was lost to fixing the lowest levels of the
monitor, debug comms channels, interrupt handling basics and so on. And
as for the socket library we used... sheesh.
> 
>   While on the topic of Squeak on ARMs, I was looking over the dreaded
>   EPOC32 SDK this weekend, and based on comments you and/or Ed have made,
>   I'm wondering, why wouldn't you just target the port for an EXE rather
>   than an APP?  EXEs don't have any restrictions regarding writeable
>   statics, and they run in their own process, which is the case for
>   nearly every OS I can think of (except EPOC, of course).
I'm very happily deferring to Ed on this. He has been able to make sense
of the EPOC doc and so on. IIRC (Ed, help!) there are problems with
communicating to any other software or something like that if you use
exe form.
> 
>   It just seems like EXEs are the most straight-forward way to port
>   existing code to EPOC.  Am I missing something?  I'm sure I could be
>   since the EPOC documentation is "a little" hard to follow.
Tell me about it. Ever tried installing the SDK? The older ones required
that you install a particular version of PERL (even if you already had
PERL installed) in order to run an install program that was effectively
'cp -R blahblah' ! Oh, and only to particular directories on the c:
drive.
> 
>   I also started looking through the generated code for 'interp.c' to
>   see if I could find where the static variables declared in it come
>   from.  I'm guessing that class variables and anything in the System
>   Dictionary would be candidates?
Class variables in ObjectMemory etc are generally constants and the
instance variables are generally the statics you see at the top of
interp.c. Others can be added via the assorted #declareCVarsIn: methods
scattered around the place. I have a theory, never tested, that it would
be possible to put them all in a structure of somesort and access them
by globals->thingy type statements, which ought to be easy to do at
translation time. If the address of 'globals' can be coerced into a
register, it might even be faster (on an ARM, and who could possibly
care about any other:-) than straight global access. I think it would
also ease code sharing among mulitple VMs running at once, since each
could have a separate globals struct. Of course, any decent OS should do
that for you anyway.

> 
>   I was thinking that Squeak on an 18.432 MHz ARM 710 on the S5 would
>   give a very good idea of how it would perform on the 16.78 MHz
>   ARM 710T in the new Gameboy.
Extremely good would be my suspicion. And as Jecel pointed out, a 33-ish
486 would be about the same.
But I still want my quad processor SA-2 (whoops, XScale) running at
1+GHz...

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- One bird short of a flock.