Re: [PATCH] C undefined behavior fix

Lars Brinkhoff
2002-01-04T09:52:42Z

Paul Mackerras <paulus@samba.org> writes:
> Lars Brinkhoff writes:
> > > [Linux] won't get very far on a PDP-10, I can assure you. :)
> > Any particular reason why?
> As to the question whether such code could be developed, it would
> depend a lot on how gcc did things. I would expect an int * to be
> just an 18-bit address but a char * to be a byte pointer, i.e. a
> 36-bit word with the byte offset and size in the top 18 bits and the
> word address in the lower 18 bits.

This is true in the classic PDP-10 architecture, but would it
really be worthwhile to run Linux in an 18-bit address space?.

In the extended architecture, an int * is a 30-bit address, and the
byte offset and size is encoded in the top 6 bits. This would be a
more suitable target for Linux.

> This would mean that casting char * pointers to unsigned long and
> vice-versa wouldn't give the kind of results we expect. The kernel
> assumes in a lot of places that memory is byte-addressable and that
> casting a pointer to an unsigned long gives you the byte address of
> the first byte of the object that the pointer points to, and that it
> can do arithmetic on those byte addresses.

When a pointer-to-integer conversion is made (or vice versa), GCC
could generate code to convert between a PDP-10 hardware pointer and a
linear byte address.

> Another difficulty would be in relation to the MMU. IIRC, the KA10
> processor had a simple offset/limit memory management scheme, which
> would not be sufficient for linux, which requires support for paged
> virtual memory.

Right.

> I have forgotten what the KI10 and KL10 processors did; I recall it
> was more complex but I don't think it amounted to paged virtual
> memory.

The KI10 has limited support for paging, but I don't remember the
details. KL10 most definitely supports full paged virtual memory.

--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10
Brinkhoff Consulting http://www.brinkhoff.se/ programming