🚀 go-pugleaf

In article <watson.722463452@bellatrix.sce.carleton.ca> watson@sce.carleton.ca (Stephen Watson) writes:
>lectro@stein.u.washington.edu (Jonathan Maier) writes:
>
>>In article <1992Nov21.221745.23588@jarvis.csri.toronto.edu> ematias@csri.toronto.edu (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 -
(ematias@csri.toronto.edu)
(g1marker@cdf.toronto.edu)