Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2359

Character pointers in Garth Conboy (Pacer Software's C Compiler) Re: PR1ME C compiler sources

Show key headers only | View raw

[The Prime machines suffered from having too many versions of
everything. Page 41 of that quick reference card has a 48 bit pointer
format with a bit number in the low 16 bits. It seems unlikely that a
C compiler would use that as a general pointer format since it doesn't
fit in any sort of normal int, and it's not what you'd want to point
at an int or a function or anything bigger than a char. -John]

I don't know about this C compiler written in ratfor, but Garth's C
compiler used a very clever trick to fit 48 bit character pointers in
32 bits.

In the 48 bit pointer format (that the hardware supported) the top two
bits were special.  This sign bit if I recall was special and when set
caused a hardware pointer fault,  The bit next to the sign bit,
selected whether the final 16 bits of the pointer were used.  Now, I
might have these bits backwards, but it doesn't matter.  A normal
"word" (16 bit) aligned pointer would have both bits 0.  If the fault
bit was set, it always trapped (to the OS, that did special things
with the pointer).   However, if the fault bit wasn't set and the
"extension bit" was set the last 16 bits were used as a "bit offset".

Now, the hardware did not actually implement full bit level
addressing, that required RTL (runtime library) support, but it did do
byte level addressing.  The full PL/I compiler's RTL and generated
code did support bit level addressing, but that wasn't needed for C.
So, Garth absconded that bit in the C RTL and used it as the last bit
in a byte addressed pointer.  He did that by having a 48 bit location
in which you could store the pointer, and setting the "bottom" 16 bits
of that to be "0x0008".  So, if you stored a 32 bit int in the top 32
bits of that area and then indirected to it, the hardware would do a
byte addressed fetch.  Now, it took some shifts (and perhaps masks) to
convert that into a linear address (the byte portion of the address
was in the wrong spot) so increments of a byte addresses pointer
required a little work, but with that hack, you can store byte
pointers in integers.  By the way the pointer registers all knew about
the extension bit, so if you stored a pointer with the bit off, it
only stored 32 bits.  Of course, the general purpose registers only
read and stored 32 bits.

To further support that hack, the hardware folks introduced yet
another instruction mode called I* that natively did those operations
and was much more C friendly.

One of the bizarre, but quite impressive in its own way was its
backward compatibility.  The original Pr1me machines were based on
some NASA project (IIRC, I wasn't there, I got this info second hand)
that were used to build networks for the early ARPAnet.   That was S0
mode.  They then implemented a machine with two pages S1 mode.  Flip a
bit and the second page existed.  They made a version that had a stack
and supported recursion, R mode, a new setting ot the bits.  They
implemented virtual memory, V mode, which was the main mode for the
time I started and the TSI, LPI, and other compilers used that mode
(at first).  They then did a general register mode, I mode. And,
finally I* mode.  All of these modes were "hardware" compatible in
some sense and the machine booted into S0 mode working its way up to
at least V mode in the OS.  But from V mode, you could run software in
any of the other modes and call instructions could switch mode (IIRC).

--
******************************************************************************
Chris Clark                  email: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc.  Web Site: http://world.std.com/~compres
23 Bailey Rd                 voice: (508) 435-5016
Berlin, MA  01503 USA      twitter: @intel_chris
------------------------------------------------------------------------------
[S mode was the Honeywell DDP 316/516 minicomputer instruction set, which was indeed
the machine used to build the Arpanet IMPs. -John]

Back to comp.compilers | Previous | Next | Find similar

Thread

Character pointers in Garth Conboy (Pacer Software's C Compiler) Re: PR1ME C compiler sources Christopher F Clark <christopher.f.clark@compiler-resources.com> - 2019-09-26 04:39 -0400

csiph-web