home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1903 < prev    next >
Encoding:
Text File  |  1992-12-23  |  2.8 KB  |  74 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Zero-length structures and pointer comparisons
  5. Message-ID: <1992Dec23.174653.16505@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. References: <1992Dec18.204337.3084@lth.se> <1992Dec19.202043.20366@ucc.su.OZ.AU> <1992Dec20.201212.8974@lth.se>
  10. Date: Wed, 23 Dec 1992 17:46:53 GMT
  11. Lines: 61
  12.  
  13. In article <1992Dec20.201212.8974@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
  14. >I think we're sliding away from the original discussion.
  15. >
  16. >The goal was to write data structures that use the ordering of
  17. >pointers to improve search time.  What I need is mechanism that
  18. >compares the pointers -- what they actually point to is not relevant.
  19.  
  20.     Of course it is. You want < to be compatible with ==,
  21. and the ARM says a==b if a and b point to the same object.
  22.  
  23.     Without this requirement, a<b==0 for all a,b is a perfectly
  24. legal total order.
  25.  
  26. >
  27. >I would finally like to return to a claim I made earlier, but nobody
  28. >has commented on (as far as I know).  I belive that even if you
  29. >imposed a total ordering on pointers in a segmented architecture
  30. >(e.g., Inte 8086 family), compilers would be able to handle the
  31. >follwing common case efficiently:
  32.  
  33.     Now hang on there. The 8086 in my view does not have a segmented
  34. address space, it has a linear address space. The 286 and 386 have
  35. real segmented address spaces.
  36.  
  37.     Doing < on the 8086 would be just about the same overhead
  38. as == plus a bit (comparisons for equality are slightly simpler
  39. than less). Just guessing that these operations would be about 
  40. 5-20 times slower than a single register to register comparison.
  41. I.e., significant but not insummountable.
  42.  
  43.     On the 386, if there was no aliasing, a slight mess
  44. converting 32 bit pointer to 48 bit ones before a 48 bit
  45. compare. 
  46. >
  47. >    void zap(int* a, unsigned n)
  48. >    {
  49. >        for (int* p = a; p < a+n; p++)
  50. >            *p = 0;
  51. >    }
  52. >
  53. >and produce the same code as today (without the total ordering).
  54. >After all, the assignment "p = a" says that "p" must point to the same
  55. >segment as "a".  Any comments?
  56.  
  57.     True. Sometimes the comparisons could be optimised.
  58. (On the 386. On the 8086, if n>32K, you would not be able to
  59. fit the array in one segment)
  60.  
  61.     So there remains the conformance issue. Existing
  62. code will be broken. Note: actually it WONT be broken,
  63. vendors simply wont implement this requirement of the standard
  64. in some memory models. (Or they'll provided the dreaded compatibility
  65. switch)
  66.  
  67.  
  68.  
  69. -- 
  70. ;----------------------------------------------------------------------
  71.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  72.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  73. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  74.