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

Groups > comp.compilers > #2371

Re: PR1ME C compiler sources and pointer formats

Show key headers only | View raw

 > I don't know where you saw the description of the register set.  I
 > suspect it was only describing the "general purpose registers"
 > associated with IX-mode (which I knew as I*-mode).  The 48 bit pointer
 > registers are not part of that set. And, what I was describing
 > previously was the way the C compiler worked in V-mode.  Reading the
 > documentation on the C compiler for IX-mode.  It is clear that they
 > added a whole new way of dealing with 32 bit pointers using the
 > general purpose registers.

Ignoring floating point stuff, the registers are all 16- or 32-bit.  The
48 bit pointers are strictly memory-based.

I mode is a general register mode.  It doesn't do much of anything to
hide segmentation.  It does include register-relative addressing, that
is, putting pointers into general registers.

IX mode is a small extension to I mode, which adds some additional
manipulation of pointers in registers, and some support for C character
manipulation.  Again, doesn't do much of anything to hide segmentation.

 > So, what follows is what I remember of the V-mode segmented address
 > space (with some guesses as to how they probably tweaked it for
 > IX-mode to make it appear more linear).  There were 4 pointer
 > registers in V-mode.  PB -- a pointer to the instruction space.  LB --
 > a pointer to "static" memory.  SB -- a pointer to the "stack frame".
 > XB -- a pointer for general use.   If I recall correctly, only the XB
 > was actually modifiable by normal code; done with the EAXB
 > instruction,  calculate effective address (including doing
 > indirections) and store it in the XB register.  The PB, LB, and SB
 > registers were only changed by the PCL (procedure call) instruction
 > (and it's corresponding return).  Each of these registers had the two
 > bits I mentioned previously (although, I forgot the ring bits which
 > separated them), a ring number 0, 1, 2, or 3 (the OS ran in ring 0 and
 > user code ran in ring 3, the DBMS used ring 1 or 2 if I recall
 > correctly, but the other ring was unused), a segment number, a
 > half-word (16 bit offset), and a bit offset (that was only used by the
 > hardware at the character (8 bit) level).

I suppose the base registers are "pointer registers" in the strict
sense, but 3/4 of them have fixed purposes.  You can directly alter the
contents of LB and XB via the EALB and EAXB instructions.  The obvious
way to alter PB is to use a PCL instruction.  The only one left is SB,
which you can modify by using the RSAV and RRST instructions to save
registers and restore them.

 > Calls to the OS or DBMS were done through the standard PCL mechanism
 > which would change which ring you were running in (increasing your
 > priority), but every segment also had a ring number (as well as every
 > pointer) had a ring number associated with it and the values were
 > ORed, so that you got the lowest priority access.  Thus, if you fudged
 > a pointer and you called into the OS, the OS would see your pointer
 > was in a lower priority space and use only the access rights that
 > space had to that address.  Code could also lower the priority of a
 > pointer itself, by setting the ring bits, and I believe if you stored
 > a pointer, the hardware stored the ring bits in the saved pointer to
 > be the weak access it was using.  So, even if your pointer got copied
 > into a ring 0 memory location, it would remain a ring 3 pointer if it
 > originally came from user space.

Entrance to the OS is through the PCL instruction and the gate
mechanism.  The microcode and/or the OS perform ring selection and
weakening as needed to ensure security.  Storing a pointer does not
cause any change in it.

 > The hardware supported at least 3 faults related to pointers.  Access
 > violation, the pointer was accessing a segment in a way it didn't have
 > rights to, with roughly the same 3 mode bits read, write, and execute
 > for each ring.  Pointer fault, the fault bit in the pointer was set.
 > and page fault, the pointer pointed to a page that wasn't currently
 > mapped in.  I believe there was also a segment fault for segments that
 > did not exist.

A pointer fault can occur for several reasons: the fault bit being set,
pointing into an invalid location, etc.  Page faults are part of the
virtual memory mechanism, and are not reflected to the user via a
condition the way a segmentation or pointer fault (or others).

 > So, my guess is that IX mode did roughly that, putting the XB at the
 > start of the linear address space for C programs and making the
 > instructions which used the GPR registers as pointers, do the
 > appropriate bit twiddling in hardware but basing the resulting address
 > off the XB.  Alternately, the instructions using the GPR registers as
 > pointers could have used "absolute addressing" with no base register,
 > letting the pointers deal with the segments (and their ring
 > restrictions) as required.  The rings and segments would have still
 > been there  but the code would have had the 29 bits to play with and
 > probably treated all accesses as if it were from ring 3.

I haven't spent as much time with I mode as with V, but the usual
idiom is to move XB around as needed.

De

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

PR1ME C compiler sources "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-09-25 15:27 +0100
  Re: PR1ME C compiler sources arnold@skeeve.com (Aharon Robbins) - 2019-09-25 18:32 +0000
    Re: PR1ME C compiler sources drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-25 20:02 -0500
      Re: PR1ME C compiler sources arnold@skeeve.com (Aharon Robbins) - 2019-09-26 10:57 +0000
    Re: PR1ME C compiler sources drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-25 20:04 -0500
      Re: PR1ME C compiler sources drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-25 20:28 -0500
        Re: PR1ME C compiler sources "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-09-26 11:53 +0100
          Re: PR1ME C compiler sources drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-27 10:19 -0500
            Re: PR1ME C compiler sources "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-09-28 00:48 +0100
              Re: PR1ME C compiler pointer management drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-28 11:08 -0500
                Re: PR1ME C compiler sources and pointer formats Christopher F Clark <christopher.f.clark@compiler-resources.com> - 2019-09-29 07:48 -0400
                Re: PR1ME C compiler sources and pointer formats drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-30 22:10 -0500
          Re: PR1ME C compiler sources George Neuner <gneuner2@comcast.net> - 2019-09-27 20:56 -0400
            Re: C compiler pointer management on DSPs "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-09-28 19:19 +0100
              Re: C compiler pointer management on DSPs David Brown <david.brown@hesbynett.no> - 2019-09-29 10:53 +0200
                Re: C compiler pointer management on DSPs Kaz Kylheku <847-115-0292@kylheku.com> - 2019-09-30 23:50 +0000
                Re: C compiler pointer management on DSPs George Neuner <gneuner2@comcast.net> - 2019-10-03 01:34 -0400
                Re: C compiler pointer management on DSPs gah4@u.washington.edu - 2020-02-27 14:23 -0800
                Re: C compiler pointer management on DSPs robin51@dodo.com.au - 2020-02-28 10:26 +1100
                Re: C compiler pointer management on DSPs gah4@u.washington.edu - 2020-02-28 02:33 -0800

csiph-web