Newsgroups: comp.lang.pascal
Path: utzoo!utgpu!watserv1!maytag!watstat.waterloo.edu!dmurdoch
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Subject: Re: Variable sizes question
Message-ID: <1991May10.201807.9655@maytag.waterloo.edu>
Sender: news@maytag.waterloo.edu (News Owner)
Organization: University of Waterloo
References: <1991May10.150700.524@cunixf.cc.columbia.edu>
Date: Fri, 10 May 1991 20:18:07 GMT
Lines: 46

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


