> 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.
Sorry, I still don't understand. Most of what you describe above is done by the OS (the Memory Manager). OK, so it finds the most appropriate place where to move the code 1 resource, locks it, and transfers control to it.
But it's not it (the Memory Manager) that does the weird push/ret stuff - it's the first few instructions of the loaded code 1 resource. Are you saying that, after loading them in memory, the memory manager *modifies* the operands of these instructions, in order to reflect the place of the code 1 resource in memory?
No... look at the code at the start of a CW 'code' #1 segment again:
00000000 ORI.B #$01,D0 ; '.' | 0000 0001 00000004 PEA *+$0006 ; 0000000A | 487A 0004 00000008 ADDI.L #$00000FB6,(A7) ; '....' | 0697 0000 0FB6 0000000E RTS | 4E75
The instruction at 00000000 is filler -- I think it's there because of some quirk on the old Macintosh.
At 00000004, you push the current address plus 6 on the stack. This gets you a pointer into the currently executing code.
At 00000008, you modify that address by adding a value to it. This is the offset into the 'code' #1 resource where __Startup__ lives, and is set at link time.
At 0000000E, you jump to that address using an RTS instruction.
Is this the simplest code that can do this? Yes, at least using the original 68K instruction set. If you look at long jumps in the CW generated code after a link, you'll see a similar sequence. If the linker put __Startup__ at the beginning of the resource, then this wouldn't be needed, although CW's linker doesn't do that optimization. If __Startup__ was within 32K, it could be done with a direct jump, but its easier in the linker to always assume a long jump here, as that avoided multiple code paths and kept the offset to the first real code the same.
-- Ben Combee, Senior Software Engineer, palmOne, Inc. "Combee on Palm OS" weblog: http://palmos.combee.net/ Developer Forum Archives: http://news.palmos.com/read/all_forums/
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
