Thank you for your comment.
You are of course right: pointers in PL/1 and C have to be regarded
different.
PL/1, BTW, does other strange things using descriptors, which are kind of
"extended" pointers, but that's another story.
Indeed, in the meantime, I thought a bit more about the problem on the C
side
and about C's usage of pointers. In C, arithmetic with pointers is
present everywhere,
so I guess the compiler people decided that the pointers inside C have
to have
the first bit off all of the time. This should be the normal case.
Otherwise, all pointer arithmetic would have to be implemented in a way that
the first bits of the involved pointers are turned off first (which is a
performance
problem, IMO). If not, you will get 0C8s etc ... which we had in the
first versions
of LE, when passing pointers from PL/1 to C modules with the first bit on.
In any case, the pointer arithmetic has to be done vary carefully, if
you have to
take such pointers into account.
But: when receiving pointers from outside PROCEDUREs, you have not
only pointer in the argument list (which have the high order bit on in
case of
the last argument), but you also have pointers inside structures for
example,
which point on other structures, as in our case, or which point on CHAR VARZ
etc. ... or you have linked list or trees. In any case, you have
pointers that
you cannot fix easily to proper 31 bit values, that is, you are not safe.
So I think, the C compiler builders for z/Arch are in a real mess, given
the
pointer semantics of C: the pointers are physically 32 bits long ...
because
that's the way they are moved and stored through the machine, in registers
and 4 byte words ... but only the last 31 bits are significant and have to
be taken into account when doing pointer arithmetic (ptrdiff_t, for
example,
should reflect this ... but: is this possible ??).
So I guess, we will get no solution to this problem, which solves all
problems, maybe ...
Kind regards
Bernd
Am 28.03.2014 16:10, schrieb Tony Harminc:
On 28 March 2014 09:47, Bernd Oppolzer <[email protected]> wrote:
I just realized that "NULL returning 0xFF000000" was designed when we
still had 24 bit addressing, so there must have been other reasons
for this design decision.
I remember heated discussions on this matter at my university computer
centre in the early 1970s, long before 31-bit addressing on S/370. At
the time it was very common for assembler code to use the high byte of
a fullword address to hold flags of various kinds, and the notion of
indicating a NULL pointer "out of band" is attractive. Some people
even then had a longer view, and understood well that 24-bit
addressing would not do forever, and that something would have to be
done. One can see the evolution of this thinking in (IBM and others')
assembler coding style as flags were moved out of high address bytes.
Another thing to consider is that pointers in C and PL/I are, in their
different ways, both opaque objects with only certain defined external
properties, and various implementation details. For example, in the
PL/I Checkout Compiler, pointers were, iirc, 128-bits, and carried
various information far beyond the address that allowed the production
of useful run-time debugging messages. In C, pointers are very clearly
not addresses at all. Look at the semantics of adding an integer to a
pointer (which is defined in the language, and is not just an
implementation detail): if your pointer is to an array of, say, ints,
if you add 1 to it it will point to the next int in the array, not to
the next byte within the current int.
PL/I has its Unspec Built In Function, and C has its cast, but both
when applied to pointers have implementation defined results.
Perhaps your solution lies not in the C language, but in the
compiler-defined external linkage conventions, some of which can be
chosen by various pragmas.
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
