Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2463
| From | robin51@dodo.com.au |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: C compiler pointer management on DSPs |
| Date | 2020-02-28 10:26 +1100 |
| Organization | Compilers Central |
| Message-ID | <20-02-025@comp.compilers> (permalink) |
| References | (4 earlier) <19-09-009@comp.compilers> <19-09-015@comp.compilers> <19-09-017@comp.compilers> <19-09-018@comp.compilers> <20-02-024@comp.compilers> |
On 2020-02-28 09:23, gah4@u.washington.edu wrote: > Machines not so well designed require masking off the appropriate > bits before operating with them, though many machines ignore high > bits on shift operations. (The 8086 allows shifts up to 255 bits.) Who can say that the CDC machines (7600; 70 series, etc) were not well designed? They were intended to be fast, and to carry out operations on words (of 60 bits). To be sure, it was necessary to mask bits (usually characters), but there was a simple instruction(s) to generate a mask of n bits (better than loading a word containing bits to be used as a mask). On the other hand, the IBM S/360 was designed from the beginning to handle bytes of 8 bits, half-words of 16 bits, and words of 32 bits. Instructions could load and store a byte into/from the low-order bits of a register, without affecting the other bits. Later models could load/store one or more bytes into/from a register without affecting the other bits. For more general work, masking operations were available in the 32-bit registers.
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