stone@cunixb.cc.columbia.edu (Glenn Stone) (05/10/91)
Dear people who understand memory addressing better than I:
I must be making an obvious mistake but I can't figure out what it
is. My data segment is too large and I want to list my global
variables by size to see what I should turn into pointers. I
created a .MAP file, converted the hex addresses to decimal, read
it into a spreadsheet, and calculated variable sizes. One variable
size makes no sense. Here is the relevant part of the spreadsheet:
OFS:SEG(hex) OFS(dec) SEG(dec) ADDRESS SIZE VARIABLE
------------------------------------------------------------
0D91:9656 3473 38486 94054 2 IOCODE
0D91:9658 3473 38488 94056 2 KBDCHAR
0D91:965A 3473 38490 94058 16642 PATH1
0D91:D75C 3473 55132 110700 2 DOSERROR
0D91:D75E 3473 55134 110702 1 CHECKBREA
The ADDRESS column is (OFS*16)+SEG. The far left and far right
columns are from the .MAP file, I calculated the rest.
The problem is that PATH1, which is from a unit, is in fact a variable
of type SEARCHTYPE, which is 130 bytes in size:
SearchType = record
FoundFile,
FoundFirst : boolean;
FileRec : SearchRec; { declared in DOS unit; 43 bytes }
FileAttr,
FilesFound : word;
FileSpec : str80;
end;
This is verified by SIZEOF(path1). Why does the .MAP file indicate
this variable is 16,642 bytes in size? Or am I reading it wrong?
Also: is there an easier way to get a listing of variables by size?
-------------------------------------------------------------------------
Glenn Stone BITNET: stone@cunixc
Columbia University INTERNET: stone@cunixb.cc.columbia.edu
-------------------------------------------------------------------------dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (05/11/91)
In article <1991May10.150700.524@cunixf.cc.columbia.edu> stone@cunixb.cc.columbia.edu (Glenn Stone) writes: >Dear people who understand memory addressing better than I: > >I must be making an obvious mistake but I can't figure out what it >is. My data segment is too large and I want to list my global >variables by size to see what I should turn into pointers. I >created a .MAP file, converted the hex addresses to decimal, read >it into a spreadsheet, and calculated variable sizes. One variable >size makes no sense. Here is the relevant part of the spreadsheet: > > >OFS:SEG(hex) OFS(dec) SEG(dec) ADDRESS SIZE VARIABLE >------------------------------------------------------------ >0D91:9656 3473 38486 94054 2 IOCODE >0D91:9658 3473 38488 94056 2 KBDCHAR >0D91:965A 3473 38490 94058 16642 PATH1 >0D91:D75C 3473 55132 110700 2 DOSERROR >0D91:D75E 3473 55134 110702 1 CHECKBREA > >The ADDRESS column is (OFS*16)+SEG. The far left and far right >columns are from the .MAP file, I calculated the rest. > >The problem is that PATH1, which is from a unit, is in fact a variable >of type SEARCHTYPE, which is 130 bytes in size: Part of the problem is that the .MAP file only lists publics - i.e. variables that are interfaced by units (and maybe some from the main program, I forget). The difference between the addresses for PATH1 and DOSERROR includes all the variables in all the units between yours and DOS (where DOSERROR is the first variable) that end up in the data segment. (You don't need to worry about typed constants; they come first in the data segment.) I don't know an easy way to find the missing 16512 bytes. If you get a copy of one of my INTRFC programs (version depends on TP version), and compile all your units with full debugging and local variables, you'll be able to find it pretty quickly. (INTRFC is INTRFC4.ZIP, INTRFC5.ZIP, INTRFC55.ZIP, or INTRFC61.ZIP, available on garbo.uwasa.fi or Simtel20). TD can also tell you which variable follows PATH1, if you ask the CPU window to go to the address following it. I hope this helps. Duncan Murdoch dmurdoch@watstat.waterloo.edu