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


Groups > comp.compilers > #2368

Re: C compiler pointer management on DSPs

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>

Show all headers | View raw


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 | 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