Ron Natalie wrote:
> kanze@gabi-soft.fr wrote:

> > I wonder, does it use all 36 bits for word addressing, or
> > does it put the character offset on some unused (typically
> > high order) bits, like the PDP-10 did?

> The PDP-10 (and the UNIVAC/SPERRY/UNISYS) processors didn't
> really byte address at all.  The unused high order bits was a
> software convention.

I don't know about the Sperry/Univac/Unisys machines, but the
PDP-10 had hardware instructions to support variable width
bytes, see http://www.inwap.com/pdp10/hbaker/pdp-10/Byte.html.
These put the byte offset (and the byte width) in the upper
bits.  The "traditional" byte was 7, with 5 bytes per 36 bit
word (and one bit inaccessable through the bytes).  This
wouldn't be legal for C/C++, however, and presumably, c/C++
implementations used (or use -- I believe that there is a
version of g++ for the PDP-10) 4 nine bit bytes per word.

> Actually the Univac only has 9 bit chars by conention as well.
> It has a pretty nice partial word format that lets you divide
> it up, but if you want to pack ascii characters in there
> evenly nine is the way to go.

But the necessity of packing is an artifact of C/C++; 5 * 7 bits
works nice otherwise:-).

>  > java on 1's complement.

> signed math takes an additional instruction or two.

And floating point probably has to be emulated as well.  Not
really the sort of things that will speed up execution.  On the
other hand, a really good JIT compiler could detect when it
mattered, and suppress the instructions most of the time.  I
don't know the exact specification of Java with regards to
optimization, but there is no way to look at the actual
representation in memory, so as long as no bit manipulatiion
instructions are used, you can probably get away with using 1's
complement most of the time, on the grounds that the program
can't tell.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Graeme Prentice wrote:
> On Tue,  5 Apr 2005 13:32:28 CST, kanze@gabi-soft.fr wrote:

> >John Nagle wrote:
> >> Andrew Koenig wrote:
> >> > Consider a C++ implementation on a word-addressed machine.

> >>     There's still C++ for Unisys ClearPath servers running OS
> >> 2200, 36-bit machines with four 9-bit characters per word.
> >> That is, I think, the last commercial word-addressed general
> >> purpose computer still in production.

> >I wonder, does it use all 36 bits for word addressing, or does
> >it put the character offset on some unused (typically high
> >order) bits, like the PDP-10 did?

> >Independant of hardware, one could also imagine debugging
> >compilers with special pointer types.  Say with a void* which
> >contained added information concerning the actual type.

> <3.9.2/4>
> A cv-qualified or cvunqualified (3.9.3) void* shall have the same
> representation and alignment requirements as a cv-qualified or
> cv-unqualified char*.
> <>

> Presumably "representation" means both object and value
> representation.  I guess this means char* would have to have
> the added info as well.

More or less.  The char* would have to have the same format as a
void*.  I think that the implementation could ensure that the
type information in a char* always corresponded to char*, and
not to some other type.  Or it could make this optional.  The
main reason for that rule dates back to the early days of C,
when there wasn't a void*, and char* was traditionally used in
place of it.  The requirement that char* and void* have the same
representation would presumably result in a lot less broken
code.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote:

> Ron Natalie wrote:
>
>>kanze@gabi-soft.fr wrote:
>
>
>>>I wonder, does it use all 36 bits for word addressing, or
>>>does it put the character offset on some unused (typically
>>>high order) bits, like the PDP-10 did?
>
>
>>The PDP-10 (and the UNIVAC/SPERRY/UNISYS) processors didn't
>>really byte address at all.  The unused high order bits was a
>>software convention.
>
>
> I don't know about the Sperry/Univac/Unisys machines, but the
> PDP-10 had hardware instructions to support variable width
> bytes, see http://www.inwap.com/pdp10/hbaker/pdp-10/Byte.html.

    Production of PDP-10/DECsystem machines ceased in the late 1980s.
No machines of that family are known to be in non-museum use.
There is one hardware emulator of the PDP-10 line still running on
the net (telnet to "toad.xkl.com", and type "systat").

    The UNISYS B line of 36-bit word machines, which stretches
back to the vacuum-tube UNIVAC 1103A of the 1950s and continues
with the ClearPath servers of today, is the last 36-bit line
still in production.  Even there, the 36-bit support is
provided with plug-in boards for 36-bit compatibility.
Most of the installed CPUs are actually x86 processors.

    My point is that it may be time to consider dropping
support for word machines.  There are so few left.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu,  7 Apr 2005 16:32:24 GMT, John Nagle wrote:

>
>    My point is that it may be time to consider dropping
>support for word machines.  There are so few left.
>

"word" machines may actually be increasing in the embedded world.
What do you mean by "dropping support"?  What support does the language
provide for word-addressed machines at the moment?  Do you mean that the
language should require all non-member type pointers to be the same size
and representation so that reinterpret-cast on a void* will work -
assuming no alignment problems.  I don't understand the need to do a
blind re-interpret cast on a void* in the first place.  What's wrong
with static-cast (5.2.9/10) ?

Graeme

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:Yad5e.20783$zl.5132@newssvr13.news.prodigy.com...
| kanze@gabi-soft.fr wrote:

|    My point is that it may be time to consider dropping
| support for word machines.  There are so few left.

would that mean that we could make the cast legal?

-Thorsten


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Graeme Prentice" <gprenz@hotmail.com> wrote in message
news:trta51liqikpbcenkr99159difhuqqbu5g@4ax.com...

| provide for word-addressed machines at the moment?  Do you mean that the
| language should require all non-member type pointers to be the same size
| and representation so that reinterpret-cast on a void* will work -
| assuming no alignment problems.  I don't understand the need to do a
| blind re-interpret cast on a void* in the first place.  What's wrong
| with static-cast (5.2.9/10) ?

my motivation is quite real; consider a container

ptr_vector<T>

which stores T*'s pointing to heap-allocated objects. By using
vector<void*> instead of vector<T*> internally we can save quite a lot
generated code.
You can imagine two types of iterators for ptr_vector<T>: one
that is indirected and one that iterates over T*; the latter requries
that we can convert void*& to T*& since vector<void*>'s iterator
will return a void*& to us.

br

-Thorsten


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri,  8 Apr 2005 00:35:19 GMT, "Thorsten Ottosen" wrote:

>"Graeme Prentice" <gprenz@hotmail.com> wrote in message
>news:trta51liqikpbcenkr99159difhuqqbu5g@4ax.com...
>
>| provide for word-addressed machines at the moment?  Do you mean that the
>| language should require all non-member type pointers to be the same size
>| and representation so that reinterpret-cast on a void* will work -
>| assuming no alignment problems.  I don't understand the need to do a
>| blind re-interpret cast on a void* in the first place.  What's wrong
>| with static-cast (5.2.9/10) ?
>
>my motivation is quite real; consider a container
>
>ptr_vector<T>
>
>which stores T*'s pointing to heap-allocated objects. By using
>vector<void*> instead of vector<T*> internally we can save quite a lot
>generated code.
>You can imagine two types of iterators for ptr_vector<T>: one
>that is indirected and one that iterates over T*; the latter requries
>that we can convert void*& to T*& since vector<void*>'s iterator
>will return a void*& to us.

ok, so you want to return a type of reference to T* when the actual
object being referred to is a void*.  The vector subscript operator []
also returns a reference to the element type.

This would require the size, alignment and representation of void* to be
the same as T* for any T.  I don't think the language will ever be
changed to provide this guarantee.  static_cast isn't going to work
because e.g. vector allows client code to take the address of any
element of the vector and use pointer arithmetic on that address, which
you have no control over, nor do you have control of the dereferencing
of such addresses.  I don't think a proxy object would work because
client code will always need to be able to get the address of any
element in the container as a T**

I really have no idea how many cases/platforms there would be when T*
objects do not have the same size and alignment etc. for all T or
whether you can "safely" restrict your code to common platforms such as
x86.

Maybe a better solution is to specialize vector member functions for a
vector of pointers based on the size of the stored pointer, for the
parts of the code where you know the representation of the pointer
itself is "don't care".

Graeme

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

I'm trying to figure out whether the reinterpret_cast
conversion from void*& to T*& is legal
given the pointer really points to a T object.

If I read 5.2.10/7 correctly, then this is legal if the alignment requirement
of T and U
are equal

U* u = ...
T*  t = reinterpret_cast<T*>( u );

Now replace U with void* and T with T* to get

void** u = ...
T** t = reinterpret_cast<T**>(u);

then this should be legal too

void*& u2 = *u;
T*& t = reinterpret_cast<T*&>( u2 );

Have I missed anything? Can the alignment of T* and void* be different?

Thanks

-Thorsten
--
Thorsten Ottosen
----------------------------
www.dezide.com
http://www.cs.aau.dk/index2.php?content=Research/mi
www.boost.org
www.open-std.org/JTC1/SC22/WG21/


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Thorsten Ottosen" wrote:
> Hi,
>
> I'm trying to figure out whether the reinterpret_cast
> conversion from void*& to T*& is legal
> given the pointer really points to a T object.
>
> If I read 5.2.10/7 correctly, then this is legal if the alignment
requirement
> of T and U
> are equal
>
> U* u = ...
> T*  t = reinterpret_cast<T*>( u );
>
> Now replace U with void* and T with T* to get
>
> void** u = ...
> T** t = reinterpret_cast<T**>(u);
>
> then this should be legal too
>
> void*& u2 = *u;
> T*& t = reinterpret_cast<T*&>( u2 );
>
> Have I missed anything? Can the alignment of T* and void* be
different?
>
> Thanks
>
> -Thorsten
> --

You appear to be perfectly safe here.  The relevant sections of the
Standard are 3.9.2/4, 4.10/2 and 5.2.9/10.  The upshot of these is that
a void * shall be capable of holding any object pointer, and converting
any object pointer to void * and back again is guaranteed to result in
the same value.

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Thorsten Ottosen"" <nesotto@cs.auc.dk> wrote in message
news:424d8832$0$43984$14726298@news.sunsite.dk...

> I'm trying to figure out whether the reinterpret_cast
> conversion from void*& to T*& is legal
> given the pointer really points to a T object.

No way.

Consider a C++ implementation on a word-addressed machine.  Unless the
implementation wastes storage by always storing only a single character per
word, pointers to objects smaller than a word have to have extra
information, such as a byte offset within the word.

On such an implementation, it is reasonable to assume that class objects
will always be at least word-aligned, thereby making that information
unnecessary for such pointers.  However, void* has to carry the additional
information because it might be pointing to a character.

Therefore, it is not reasonable to assume in general that void* and T* have
the same internal representation, even if they are pointing to the same
object.  Putting it another way, converting between void* and T* may involve
a change of representation, which means that you cannot assume that a
reinterpret_cast will yield a result pointing to the same object.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thorsten Ottosen wrote:

> I'm trying to figure out whether the reinterpret_cast
> conversion from void*& to T*& is legal
> given the pointer really points to a T object.

How about a machine where sizeof(int*) < sizeof(char*)?
void* must be able to store both int* and char* without
loss of information so that it can be converted back
to the original pointer type and still point to the
same object. Thus, sizeof(void*) > sizeof(int*), too.
Then consider you have
   int*  pi =3D ...
   void* pv =3D pi; // conversion of the pointer's object representation =
required

reinterpret_cast<int*&>(pv) however will not carry out a
conversion of the pointer's object representation
(=A7 5.2.10/10). Unless you know both object representations
(especially where inside the void* representation is stored
the extraneous address information not present in the int*
representation and allowing to address bytes within machine
words aka ints), nothing tells you that the result of said
reinterpret_cast has any useful relationship with the original
int* pointer.=20

Falk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Andrew Koenig"" <ark@acm.org> wrote in message
news:rvh3e.499180$w62.219415@bgtnsc05-news.ops.worldnet.att.net...
| ""Thorsten Ottosen"" <nesotto@cs.auc.dk> wrote in message
| news:424d8832$0$43984$14726298@news.sunsite.dk...
|
| > I'm trying to figure out whether the reinterpret_cast
| > conversion from void*& to T*& is legal
| > given the pointer really points to a T object.
|
| No way.

ok, a bit different answer than before :-)

| Consider a C++ implementation on a word-addressed machine.  Unless the
| implementation wastes storage by always storing only a single character per
| word, pointers to objects smaller than a word have to have extra
| information, such as a byte offset within the word.
|
| On such an implementation, it is reasonable to assume that class objects
| will always be at least word-aligned, thereby making that information
| unnecessary for such pointers.  However, void* has to carry the additional
| information because it might be pointing to a character.
|
| Therefore, it is not reasonable to assume in general that void* and T* have
| the same internal representation, even if they are pointing to the same
| object.  Putting it another way, converting between void* and T* may involve
| a change of representation, which means that you cannot assume that a
| reinterpret_cast will yield a result pointing to the same object.

Is it possible to say *anything* about a certain classs of objects where the
reinterpret_cast is going to succeed? In particular, the only case that
interests
me is when T is not a builtin-type (thought perhaps a pointer to one).

-Thorsten.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Falk Tannh=E4user wrote:
> Thorsten Ottosen wrote:
>=20
>> I'm trying to figure out whether the reinterpret_cast
>> conversion from void*& to T*& is legal
>> given the pointer really points to a T object.
>=20
>=20
> How about a machine where sizeof(int*) < sizeof(char*)?


It doesn't even have to be a different size.   If the encoding
of int* is incompatible with char* (i.e. some conversion is
required), you're not going to be able to do that with a reference
or pointer to these types.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri,  1 Apr 2005 17:50:23 GMT, nesotto@cs.auc.dk ("Thorsten Ottosen")
wrote:

> I'm trying to figure out whether the reinterpret_cast
> conversion from void*& to T*& is legal
> given the pointer really points to a T object.

Did you mean what you said?  If so, no.  If you intended to say
the reference is really to a T*, yes.

    char* a(0);
    void*& b(reinterpret_cast<void*&>(a));   // no conversion
    char*& c(reinterpret_cast<char*&>(b));   // no conversion

    void* d(a);                              // possible conversion
    void*& e(d);
    char*& f(reinterpret_cast<char*&>(e));   // all bets off

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat,  2 Apr 2005 05:36:32 GMT, Falk Tannh=E4user wrote:

>Thorsten Ottosen wrote:
>
>> I'm trying to figure out whether the reinterpret_cast
>> conversion from void*& to T*& is legal
>> given the pointer really points to a T object.
>
>How about a machine where sizeof(int*) < sizeof(char*)?
>void* must be able to store both int* and char* without
>loss of information so that it can be converted back
>to the original pointer type and still point to the
>same object. Thus, sizeof(void*) > sizeof(int*), too.
>Then consider you have
>   int*  pi =3D ...
>   void* pv =3D pi; // conversion of the pointer's object representation=
 required
>
>reinterpret_cast<int*&>(pv) however will not carry out a
>conversion of the pointer's object representation
>(=A7 5.2.10/10). Unless you know both object representations
>(especially where inside the void* representation is stored
>the extraneous address information not present in the int*
>representation and allowing to address bytes within machine
>words aka ints), nothing tells you that the result of said
>reinterpret_cast has any useful relationship with the original
>int* pointer.=20


Do you know of any compiler/machine combination where sizeof(int*)  is
less than sizeof(char*)? =20

Possibly depending on how char * was represented, some of the benefit of
a 16 bit data bus would be lost in the inefficiency of processing and
storing char* and void*.  Such a word_addressable machine could have
say, 32 bit pointers, with the bottom bit of the internal address
representation never appearing on the address bus (I think some Hitachi
micros do this).  Incrementing an int* would then add some value greater
than one to the actual value in memory and incrementing a char* would
add one.  This would mean the max physical memory is 2**32 bytes (4GB)
instead of 8GB but seems like a better deal than having to do weird
manipulations of char* values.

Are AMD and Intel 64 bit micros byte addressable (I wonder)?

Graeme

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrew Koenig wrote:
> Consider a C++ implementation on a word-addressed machine.

    There's still C++ for Unisys ClearPath servers running
OS 2200, 36-bit machines with four 9-bit characters per word.
That is, I think, the last commercial word-addressed general
purpose computer still in production.

    However, Unisys recommends using Java.  Their C++
is minimally supported.  So C++ standard support for
word addressable machines probably isn't a high priority
any more.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Potter" <jpotter@lhup.edu> wrote in message
news:dUx3e.13099$S46.4461@newsread3.news.atl.earthlink.net...
| On Fri,  1 Apr 2005 17:50:23 GMT, nesotto@cs.auc.dk ("Thorsten Ottosen")
| wrote:
|
| > I'm trying to figure out whether the reinterpret_cast
| > conversion from void*& to T*& is legal
| > given the pointer really points to a T object.
|
| Did you mean what you said?

well, maybe :-)

| If so, no.  If you intended to say
| the reference is really to a T*, yes.

I guess you're saying this is illegal ( :-( )

    void* a = new Foo; // possible conversion
    void*& b = a;
    Foo*& = reinterpret_cast<Foo*&>(b);

Thanks.

-Thorsten


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
> Andrew Koenig wrote:
> > Consider a C++ implementation on a word-addressed machine.

>     There's still C++ for Unisys ClearPath servers running OS
> 2200, 36-bit machines with four 9-bit characters per word.
> That is, I think, the last commercial word-addressed general
> purpose computer still in production.

I wonder, does it use all 36 bits for word addressing, or does
it put the character offset on some unused (typically high
order) bits, like the PDP-10 did?

Independant of hardware, one could also imagine debugging
compilers with special pointer types.  Say with a void* which
contained added information concerning the actual type.

>     However, Unisys recommends using Java.

And how do they implement Java on a 36 bit ones complement
machine?  Efficiently, at least.  Java imposes 32 bit twos
complement.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue,  5 Apr 2005 13:32:28 CST, kanze@gabi-soft.fr wrote:

>John Nagle wrote:
>> Andrew Koenig wrote:
>> > Consider a C++ implementation on a word-addressed machine.
>
>>     There's still C++ for Unisys ClearPath servers running OS
>> 2200, 36-bit machines with four 9-bit characters per word.
>> That is, I think, the last commercial word-addressed general
>> purpose computer still in production.
>
>I wonder, does it use all 36 bits for word addressing, or does
>it put the character offset on some unused (typically high
>order) bits, like the PDP-10 did?
>
>Independant of hardware, one could also imagine debugging
>compilers with special pointer types.  Say with a void* which
>contained added information concerning the actual type.


<3.9.2/4>
A cv-qualified or cvunqualified (3.9.3) void* shall have the same
representation and alignment requirements as a cv-qualified or
cv-unqualified char*.
<>

Presumably "representation" means both object and value representation.
I guess this means char* would have to have the added info as well.

Graeme

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote:

>
> I wonder, does it use all 36 bits for word addressing, or does
> it put the character offset on some unused (typically high
> order) bits, like the PDP-10 did?

The PDP-10 (and the UNIVAC/SPERRY/UNISYS) processors didn't really
byte address at all.   The unused high order bits was a software
convention.

Actually the Univac only has 9 bit chars by conention as well.
It has a pretty nice partial word format that lets you divide
it up, but if you want to pack ascii characters in there evenly
nine is the way to go.

 > java on 1's complement.

signed math takes an additional instruction or two.

Ron (Used to have a cat named FURPUR)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]