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


Groups > comp.compilers > #2364

Re: PR1ME C compiler sources

From "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk>
Newsgroups comp.compilers
Subject Re: PR1ME C compiler sources
Date 2019-09-28 00:48 +0100
Organization virginmedia.com
Message-ID <19-09-014@comp.compilers> (permalink)
References (1 earlier) <19-09-004@comp.compilers> <19-09-006@comp.compilers> <19-09-007@comp.compilers> <19-09-009@comp.compilers> <19-09-013@comp.compilers>

Show all headers | View raw


Dennis,

> For the Prime/Conboy/Pacer compiler:
>
> https://sysovl.info/pages/blobs/prime/devel/C%20Users%20Guide%20T3.0-23.0%20DOC7534-4LA%201990.pdf

Thanks.  The characteristics of the C compiler make it one of the
most unusual I have seen.

A discussion that crops up every now and again within the C committee,
is whether there are any processors that will trap if some
pattern of bits (usually a pointer value) is loaded into a register (but
not used to access storage).

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

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.

--
Derek M. Jones
blog:shape-of-code.coding-guidelines.com

Back to comp.compilers | Previous | NextPrevious 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