home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / msdos / programm / 10861 < prev    next >
Encoding:
Text File  |  1992-11-23  |  2.8 KB  |  73 lines
  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!mcsun!Germany.EU.net!ira.uka.de!slsvaat!us-es.sel.de!reindorf
  3. From: reindorf@us-es.sel.de (Charles Reindorf)
  4. Subject: Re: Very puzzling struct problem!
  5. Message-ID: <1992Nov23.135554.14574@us-es.sel.de>
  6. Sender: news@us-es.sel.de
  7. Organization: SEL-Alcatel Line Transmission Systems Dept. US/ES
  8. References:  <1992Nov21.221745.23588@jarvis.csri.toronto.edu>
  9. Date: Mon, 23 Nov 92 13:55:54 GMT
  10. Lines: 61
  11.  
  12. In article <1992Nov21.221745.23588@jarvis.csri.toronto.edu>, ematias@csri.toronto.edu (Ummm... me!) writes:
  13. |> 
  14. |> 
  15. |>    While working on a little arcade-action game in Borland C v2.0, I've
  16. |> recently come across something very puzzling; perhaps someone can explain 
  17. |> to me exactly what is going on, since I'm not an expert programmer by any  
  18. |> stretch of the imagination.  The problem is explained below.
  19. |> 
  20. |> ...
  21. |> 
  22. |> - having 16 integer variables in the struct would work.
  23. |> - having 32 integer variables in the struct would work.
  24. |> - having 48 integer variables in the struct would NOT work.
  25. |>
  26. |> ...
  27. |> 
  28. |>    This is totally baffling me, since I can't comprehend why my program
  29. |> would be BIGGER and SLOWER just because the number of elements in a struct
  30. |> isn't a multiple of 16 -- and furthermore, why it works fine for only
  31. |> a select few multiples of 16.  Help!
  32. |> 
  33. |> ... 
  34. |> 
  35. |>      - Mark Rosteck -
  36. |> (ematias@csri.toronto.edu)
  37. |> (g1marker@cdf.toronto.edu)
  38. |> 
  39. |> ...
  40.  
  41. I think I can think of a possible reason;
  42.  
  43. If you are using arrays of these structures, and subtracting a pointer to one element to
  44. a pointer to the other element, this involves a division by the size of the elements, which
  45. is of course a lot easier if the element size is a power of two; The division can be done
  46. by repeated shifting. It could be that the compiler is generating a series of shift right
  47. operations andjust has some generic code generator which does this for small powers of two
  48. only (?) Just a wild guess.
  49.  
  50. Also, are you copying structures around? Perhaps a special block-copy sequence of instructions
  51. is available on 8086 for this, although I can't think what it would be.
  52.  
  53. Since you say that the *executable* size is increasing, here is a way of finding out:
  54.  
  55. 1. Compile all your ".OBJ" files in such a way that *fast* code is generated.
  56.  
  57. 2. Copy all the objects off somewhere else.
  58.  
  59. 3. Do the same again for *slow* objects.
  60.  
  61. 4. Find out which ".OBJ" files have increased by a fair amount in size between the two compilations,
  62.     and of these select one which was fairly small in the first place.
  63.  
  64. 5. Compile them again, each time, except use the "/S" option to get assembler output.
  65.  
  66. 6. Compare the assembler files (!)
  67.  
  68. I for one would be intrigued to find out why.
  69.  
  70. All the above opinions are my own, etc. etc. etc.
  71.  
  72. --- Charles Reindorf
  73.