On 2005-05-03, Ben Combee <[EMAIL PROTECTED]> wrote: > At 11:03 AM 5/3/2005, you wrote: >> > 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. >
Sine I am a prc-tools guy, I did not know the CodeWarrior startup, and hence the code sequence Ben commented above. Prc-tools uses a much simpler approach: the linker is called with crt0.o as first object file. Hence start() is at offset 0 from the .text section in the linker output. Normally the .text section maps one to one to the code 1 resource. If startup() (for some reason, i.e. SysLibs) is not at the beginning of the .text section, then buildprc puts in a jump to start() at the beginning of the code 1 resource. By the way, this possible moving around of code resources in the Palm memory is the reason the code is normally compiled as PIC (Position Independent Code). Hence the limitation of +/-32K branches. Otherwise you need extensive relocation in the runtime startup. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
