[TUHS] origins of void* -- Apology!
imp at bsdimp.com
Thu Nov 9 06:45:10 AEST 2017
On Wed, Nov 8, 2017 at 1:39 PM, Don Hopkins <don at donhopkins.com> wrote:
> On 8 Nov 2017, at 20:56, Ron Natalie <ron at ronnatalie.com> wrote:
> Ralph is right. You don't have to go any further than the old x86
> implementations to find machines where the function pointers are bigger
> than the data pointers.
> Further void* both by the standard and by practical matter MUST have the
> format of char*. Any other type of pointer has to be convertible to
> void*/char* (as both must address the smallest addressable unit).
> Most machines, don't need to actually do any pointer conversion but more
> than a few do, mostly those that have word addressing as native.
> If I recall properly, the CRAY, which didn't really have byte addressing
> at all, natively, just had the byte offset into word encoded in high order
> bits. The UNIVAC has a quite rich "partial word" format encoded in the
> pointers. The HEP as well used the low order bits to switch the operand
> size as well as the offset into the word.
> This all works because conversion via normal means converted the from or
> to the void*/char* and whatever the other data pointer type, as it knows
> the type of both sides of the conversion.
> The BSD kernels however were ripe with what I call "conversion by union."
> It would store one pointer type into a union of one pointer type and
> retrieve it from another. Now this is officially undefined behavior
> (as is most use of sockaddr_t in the early days). I remember spending a
> few days running around the kernel "fixing" this when doing the HEP port.
> Ah, yes, the strict alias rule. Took FreeBSD, at least, about a decade to
excise it from the tree...
> The PDP-10 had arbitrarily sized byte pointers! Did anybody ever implement
> a C compiler on that hardware?
Yes. Several people did. We had a thread about it not to long ago. kcc Kok
Chen's C compiler for PDP-10 can be found at https://github.com/PDP-10/kcc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS