On 2005-05-03, Dr. Vesselin Bontchev <vbontchev@yaho...> wrote:
>> The execution starts at the first instruction of the code 1
> Thanks. Are you sure about this? That was one of the places I thought of
> checking and the code there didn't make much sense to me. It looks
> something like this:
> ORI.B #1,D0 ; Set the lowest bit of D0 to 1? What for?
> PEA $some_small_number
> ADDI.L #some_big_number,(SP)
> Is that a way to transfer control to address = some_big_number +
> some_small_number by pushing the result of the addition on the stack and
> doing a return? Why does it have to be done in such a bizarre way? Can't
> it jump directly?
> Perhaps the reason for my confusion is that my knowledge of the 68k assembly
> language is a bit on the lacking side... Maybe it cannot jump directly
> because the jmp instruction can take only a relative 16-bit value and the
> location could be more than 32 Kb away from the beginning? Then why the
> addition? Maybe there isn't an instruction to push a large enough number
> on the stack directly?
It has to do with the locking of the code 1 resource into memory. The
memory manager can move unlocked resources around to compact the storage
heap.i So the launch code looks up the code 1 resource, pushes its start
address on the stack and jumps to it with RTS.
The D0 register is typically used for integer type return codes by most
>> The code 0 resource contains preferences about stacksize, etc.
>> Google for it and you will find some interesting stuff.
> Oh, I did - but the article I found told me that "it is not clear what the
> code 0 is for" and that different compilers seem to put different things
> there. :-)
> Also, I thought that things like the stack size, etc. were put in an
> application preferences resource? At least the resource editor of PODS
> offered me to put such things there when I tried creating such a resource
> - originally I thought that I could put some preferences specific to my
> application in such a resource; you know, the kind of stuff that
> PrefSetAppPreferences saves.
All old PalmOS history ... Now, indeed the requested (68k) stack size is
part of the preference resource.
Look at the SystemMgr.c code in the Limited PalmOS 4 sources. You'll find
the answer to your questions there.