Re: PR1ME C compiler pointer management

From	drb@ihatespam.msu.edu (Dennis Boone)
Newsgroups	comp.compilers
Subject	Re: PR1ME C compiler pointer management
Date	2019-09-28 11:08 -0500
Organization	Compilers Central
Message-ID	<19-09-016@comp.compilers> (permalink)
References	(2 earlier) <19-09-006@comp.compilers> <19-09-007@comp.compilers> <19-09-009@comp.compilers> <19-09-013@comp.compilers> <19-09-014@comp.compilers>

Show all headers | View raw

 > I see that the PR1ME pointer value included fault and ring bits.
 > But the register set does not appear to contain special address
 > registers.

There are base registers, and address registers for e.g.  field operands
used in packed decimal arithmetic or character string edit instructions.
But for the most part, effective addresses would be computed from base
registers or pointers in memory.

 > Do you know if casting an integer to a pointer result could create
 > a value that trapped when the pointer was loaded into a register?
 > I assume it could trap if an attempt was made to treat the value as
 > an address.

I don't think a trap would occur when the register was loaded.  It would
happen when you tried to use the register as an address.  This would be
unusual at best, though: see the above comment about base registers and
memory pointers.  Off the top, I think you might have to abuse the
mapping of some of the user registers to locations 0-7 to get this to
happen.  I-mode is more general-register-y, so you might be able to use
a general register as a pointer there.

One version of the architecture manual is here if you're interested.

https://sysovl.info/pages/blobs/prime/archhw/Sys%20Arch%20Ref%20Guide%20Rev%2019.2%20DOC3060-192P%201983.pdf

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