Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2368
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: C compiler pointer management on DSPs |
| Date | 2019-09-29 10:53 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <19-09-018@comp.compilers> (permalink) |
| References | (2 earlier) <19-09-006@comp.compilers> <19-09-007@comp.compilers> <19-09-009@comp.compilers> <19-09-015@comp.compilers> <19-09-017@comp.compilers> |
On 28/09/2019 20:19, Derek M. Jones wrote: > George, > >> Just curious - what DSPs have 48-bit characters? > > Motorola DSP56000 Family Optimizing C Compiler uses 24 bits > TMS320C3x/C4x Optimizing C Compiler uses 32 bits > > I remember reading a compiler manual and thinking, wow, that's > unusual. 24-bit DSP's have been popular for audio applications. (There is also the TPU, a specialised RISC processor used for timer applications in engine control microcontrollers, that is 24-bit.) Some processors have larger access sizes to simplify the hardware. The first DEC Alpha, and some ARM designs, had no instructions for reading or writing 8-bit or 16-bit data. In effect, these had 32-bit (maybe on the Alpha it was 64-bit) "byte" sizes. But smaller access sizes could be easily simulated in software. I can't think of any application where 48-bit would such a natural fit that you'd have it as your basic access unit. Some video DSP's have used 48-bit units, but that is for a vector of 3 16-bit colour units.
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