[TUHS] origins of void* -- Apology!

[Warner Losh]

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.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/b51b96e1/attachment.html>