In message 8525696D.005995ED.00@kanmta01.software.mitel.com Dean_Swan@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
squeak-dev@lists.squeakfoundation.org