On 2005-05-03, Dr. Vesselin Bontchev <[EMAIL PROTECTED]> wrote:
>> The execution starts at the first instruction of the code 1
>> resource.
>
> 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)
> RTS
>
> 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
68k compilers.

>> 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.
  
Ton van Overbeek

-- 
For information on using the Palm Developer Forums, or to unsubscribe, please 
see http://www.palmos.com/dev/support/forums/

Reply via email to