🚀 go-pugleaf

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<b==0 for all a,b is a perfectly
legal total order.

>
>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 ------------------