From 4502448935937745722 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e94695845965b249 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-12-23 10:29:09 PST Newsgroups: comp.std.c++ Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) Subject: Re: Zero-length structures and pointer comparisons Message-ID: <1992Dec23.174653.16505@ucc.su.OZ.AU> Sender: news@ucc.su.OZ.AU Nntp-Posting-Host: extro.ucc.su.oz.au Organization: MAXTAL P/L C/- University Computing Centre, Sydney References: <1992Dec18.204337.3084@lth.se> <1992Dec19.202043.20366@ucc.su.OZ.AU> <1992Dec20.201212.8974@lth.se> Date: Wed, 23 Dec 1992 17:46:53 GMT Lines: 61 In article <1992Dec20.201212.8974@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes: >I think we're sliding away from the original discussion. > >The goal was to write data structures that use the ordering of >pointers to improve search time. What I need is mechanism that >compares the pointers -- what they actually point to is not relevant. Of course it is. You want < to be compatible with ==, and the ARM says a==b if a and b point to the same object. Without this requirement, a >I would finally like to return to a claim I made earlier, but nobody >has commented on (as far as I know). I belive that even if you >imposed a total ordering on pointers in a segmented architecture >(e.g., Inte 8086 family), compilers would be able to handle the >follwing common case efficiently: Now hang on there. The 8086 in my view does not have a segmented address space, it has a linear address space. The 286 and 386 have real segmented address spaces. Doing < on the 8086 would be just about the same overhead as == plus a bit (comparisons for equality are slightly simpler than less). Just guessing that these operations would be about 5-20 times slower than a single register to register comparison. I.e., significant but not insummountable. On the 386, if there was no aliasing, a slight mess converting 32 bit pointer to 48 bit ones before a 48 bit compare. > > void zap(int* a, unsigned n) > { > for (int* p = a; p < a+n; p++) > *p = 0; > } > >and produce the same code as today (without the total ordering). >After all, the assignment "p = a" says that "p" must point to the same >segment as "a". Any comments? True. Sometimes the comparisons could be optimised. (On the 386. On the 8086, if n>32K, you would not be able to fit the array in one segment) So there remains the conformance issue. Existing code will be broken. Note: actually it WONT be broken, vendors simply wont implement this requirement of the standard in some memory models. (Or they'll provided the dreaded compatibility switch) -- ;---------------------------------------------------------------------- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------