Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: pointer representation (was: Re: effect of free())
Message-ID: <2072@munnari.oz.au>
Date: 10 Sep 89 06:47:49 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <11016@smoke.BRL.MIL>
Sender: news@cs.mu.oz.au
Lines: 25

In article <11016@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
: In article <2064@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
: >If that is so, then a C compiler which exploits x == y to use y where x
: >was written is _not_ guaranteed to preserve things like a ring number,
: >which could be Bad News for people trying to write operating system
: >kernels in C.
: 
: If they're trying to represent (address+ring) as a C pointer, they're
: ALREADY in trouble!

I don't quite follow this.  On the PR1ME 50 series -- and some others --
the native "address" format *always* has a ring number in it.  It's not
a question of someone implementing C on such a machine _choosing_ to
represent address+ring as a C pointer, it's a question of them choosing
to represent C pointers as native hardware-type addresses, and those
addresses always have ring numbers in them.  If the C implementors choose
some other representation for C pointers than native hardware-type addresses,
then they're going to get a performance hit whenever there is an & or *.
All the address registers (remember that this thread is about address
registers?) have a ring number field in them.  The PCL (procedure call)
instruction constructs a stack frame where the argument slots are filled
in with addresses which contain ring numbers.  And so it goes.  There are
three C compilers on these machines that I've heard of, is there anyone on
the net who knows how the "pointers that refer to the same object must
compare equal" rule will affect any of them?