NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/os/msdos/programm/10851

Internet Message Format | 1992-11-22 | 2.2 KB

Path: sparky!uunet!think.com!rpi!utcsri!csri.toronto.edu!ematias
Newsgroups: comp.os.msdos.programmer
From: [e-mail] (Ummm... me!)
Subject: Re: Very puzzling struct problem!
Message-ID: <[e-mail]>
Organization: CSRI, University of Toronto
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: 23 Nov 92 00:07:16 GMT
Lines: 38

In article <[e-mail]> [e-mail] (Stephen Watson) writes:
>[e-mail] (Jonathan Maier) writes:
>
>>In article <[e-mail]> [e-mail] (Ummm... me!) writes:
>>>- having 16 integer variables in the struct would work.
>>>- having 32 integer variables in the struct would work.
>>>- having 48 integer variables in the struct would NOT work.
>>>- having 64 integer variables in the struct would work.
>>>- having 80 integer variables in the struct would NOT work.
>>>- having 96 integer variables in the struct would NOT work.
>>>- having greater than 96 ints in the struct would NOT work.
>
>>It looks like the number of variables should be 2 raised to some power
>>(ie- 16(=2^4), 32(=2^5), 64(=2^6), etc.).  You'll probably notice that
>>some things are more "efficient" if they map directly into the binary
>>(base 2) scheme that the computer is based on.
>
>Are you creating/destroying these things dynamically? (malloc/free,
>new/delete)

   No, all of these variables are relatively static in nature.  Sure, their
values are changing, but their actual assignments/declarations remain
unchanged.

>I've noticed that heap gets allocated in paragraphs (multiples of 16 bytes)
>since that's the minimum increment of a segment pointer.

   But if this was the reason for the optimization, it would also work for
the case where a 48-element (i.e., 96-byte) structure is created.
   What I can't understand is why (for example) a 32-byte structure works
fine, yet a 31- or 30-byte structure increases the .EXE size by over 1000
bytes!  Very strange...


     - Mark Rosteck -
([e-mail])
([e-mail])