ra_robert@gsbacd.uchicago.edu (07/04/89)
I'm writing an MDEF with LSP/THINK Pascal. Near the start of my MDEF I call a
sub-procedure in which I allocate a pointer with NewPtr (which I dispose of
before exiting the MDEF). While debugging (with TMON), I intercepted the
NewPtr call, but the NewPtr call isn't in my sub-proc any longer, but rather
it's near the start of main the code. I think this section of main code is
called from my sub-proc and then jumps back there. Any idea of what's going
on? It's more difficult to debug when the assembly differs greatly from the
source (i.e, why is my NewPtr call not in the section of code (my sub-proc)
where it "should" be?).
This is basically (a very much simplified and edited version of) my setup:
procedure myMDEF(all the right params);
type
myStuff:array[1..x] of whatever;
myPtr:^myStuff
var
mainMyPtr:MyPtr;
function GiveMeMyPtr: MyPtr
begin
GiveMeMyPtr:=MyPtr(NewPtr(sizeof(myStuff)));
end;
begin {main}
mainMyPtr:=GiveMeMyPtr;
DisposPtr(pointer(mainMyPtr));
end; {main}
Robert
------
ra_robert@gsbacd.uchicago.edu
------
generic disclaimer: all my opinions are minebeard@ux1.lbl.gov (Patrick C Beard) (07/04/89)
In article <4246@tank.uchicago.edu> ra_robert@gsbacd.uchicago.edu writes: > >I'm writing an MDEF with LSP/THINK Pascal. Near the start of my MDEF I call a >sub-procedure in which I allocate a pointer with NewPtr (which I dispose of >before exiting the MDEF). While debugging (with TMON), I intercepted the >NewPtr call, but the NewPtr call isn't in my sub-proc any longer, but rather >it's near the start of main the code. I think this section of main code is >called from my sub-proc and then jumps back there. Any idea of what's going >on? It's more difficult to debug when the assembly differs greatly from the >source (i.e, why is my NewPtr call not in the section of code (my sub-proc) >where it "should" be?). This is because all calls to Memory Manager traps are handled through glue. i.e., NewPtr(sizeof(variable)) becomes... CallToNewPtr: CLR.L -(SP) ; save space for result MOVE.L #sizeof_variable,-(SP) ; push size JSR NewPtrGlue ... NewPtrGlue: MOVE.L (SP)+,A1 ; save return address. MOVE.L (SP)+,D0 ; get size of ptr request _NewPtr ; call trap. MOVE.L A0,(SP) ; put address back on stack JMP (A1) ; get out of this. I hope this answers your question. __________________ Patrick Beard PCBeard@lbl.gov BSI, Berkeley, CA ___________________
mystone@caen.engin.umich.edu (Dean Yu) (07/04/89)
In article <4246@tank.uchicago.edu> ra_robert@gsbacd.uchicago.edu writes: > >I'm writing an MDEF with LSP/THINK Pascal. Near the start of my MDEF I call a >sub-procedure in which I allocate a pointer with NewPtr (which I dispose of >before exiting the MDEF). While debugging (with TMON), I intercepted the >NewPtr call, but the NewPtr call isn't in my sub-proc any longer, but rather >it's near the start of main the code. I think this section of main code is >called from my sub-proc and then jumps back there. Any idea of what's going >on? It's more difficult to debug when the assembly differs greatly from the >source (i.e, why is my NewPtr call not in the section of code (my sub-proc) >where it "should" be?). > I noticed something similar in MPW Pascal last night. From what I've been able to fathom, this seems to be some form of optimization. Most Toolbox routines are stackbased, ie, the parameters are passed to the routines on the stack. However, _NewPtr is register based -- the size of the new pointer is passed in register D0, and the address is returned in A0. It looks like these compilers make their own stack based routine for creating a new pointer which in turn calls the original _NewPtr with the parameters in the proper registers. It kinda makes sense this way; instead of saving A0/D0, creating the pointer, moving A0 into your application storage, and restoring A0/D0 for every _NewPtr call, it pushes the size you want on the stack, call a procedure that handles all the register shuffling for you, and returns the address on the pointer on the stack. If _NewPtr gets called a lot in your program, this does save quite a bit of space. _______________________________________________________________________________ Dean Yu | E-mail: mystone@{sol,caen}.engin.umich.edu University of Michigan | Real-mail: Dean Yu Computer Aided Engineering Network | 909 Church St | Apt C ===================================| Ann Arbor, MI 48104 | Phone: Given on a need to know basis, and "I am the Merit Host. I speak for | only if you're going to offer me a the bitstream." (In other words, | job... these are my very own opinions; | my employer wants to have nothing |=========================================== to do with them, or me.) | This space available for rent -------------------------------------------------------------------------------
siegel@endor.harvard.edu (Rich Siegel) (07/05/89)
In article <4246@tank.uchicago.edu> ra_robert@gsbacd.uchicago.edu writes: > >before exiting the MDEF). While debugging (with TMON), I intercepted the >NewPtr call, but the NewPtr call isn't in my sub-proc any longer, but rather >it's near the start of main the code. I think this section of main code is NewPtr is a register-based call, so a little bit of glue is called in order to set up the registers and call the trap, ergo a subroutine call. Unless you're using a Custom Header, your main is likely to not be the first code in the code resource. --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel I classify myself as a real developer because my desk is hip-deep in assembly-language listings and I spend more than 50% of my time in TMON. ~~~~~~~~~~~~~~~