🚀 go-pugleaf

In article <1992Nov21.221745.23588@jarvis.csri.toronto.edu>, ematias@csri.toronto.edu (Ummm... me!) writes:
|> 
|> 
|>    While working on a little arcade-action game in Borland C v2.0, I've
|> recently come across something very puzzling; perhaps someone can explain 
|> to me exactly what is going on, since I'm not an expert programmer by any  
|> stretch of the imagination.  The problem is explained below.
|> 
|> ...
|> 
|> - 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.
|>
|> ...
|> 
|>    This is totally baffling me, since I can't comprehend why my program
|> would be BIGGER and SLOWER just because the number of elements in a struct
|> isn't a multiple of 16 -- and furthermore, why it works fine for only
|> a select few multiples of 16.  Help!
|> 
|> ... 
|> 
|>      - Mark Rosteck -
|> (ematias@csri.toronto.edu)
|> (g1marker@cdf.toronto.edu)
|> 
|> ...

I think I can think of a possible reason;

If you are using arrays of these structures, and subtracting a pointer to one element to
a pointer to the other element, this involves a division by the size of the elements, which
is of course a lot easier if the element size is a power of two; The division can be done
by repeated shifting. It could be that the compiler is generating a series of shift right
operations andjust has some generic code generator which does this for small powers of two
only (?) Just a wild guess.

Also, are you copying structures around? Perhaps a special block-copy sequence of instructions
is available on 8086 for this, although I can't think what it would be.

Since you say that the *executable* size is increasing, here is a way of finding out:

1. Compile all your ".OBJ" files in such a way that *fast* code is generated.

2. Copy all the objects off somewhere else.

3. Do the same again for *slow* objects.

4. Find out which ".OBJ" files have increased by a fair amount in size between the two compilations,
    and of these select one which was fairly small in the first place.

5. Compile them again, each time, except use the "/S" option to get assembler output.

6. Compare the assembler files (!)

I for one would be intrigued to find out why.

All the above opinions are my own, etc. etc. etc.

--- Charles Reindorf