Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2364
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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