Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86894 > unrolled thread
| Started by | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| First post | 2022-10-12 15:57 -0700 |
| Last post | 2022-10-15 11:34 +0200 |
| Articles | 20 on this page of 106 — 22 participants |
Back to article view | Back to comp.lang.c++
CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-12 15:57 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-12 16:01 -0700
Re: CHAR_BIT is not eight Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-12 17:16 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 11:38 +0200
Re: CHAR_BIT is not eight Michael S <already5chosen@yahoo.com> - 2022-11-16 06:24 -0800
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-17 11:04 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-17 16:40 +0000
Re: CHAR_BIT is not eight Richard Damon <Richard@Damon-Family.org> - 2022-11-17 23:23 -0500
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 08:16 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-18 16:33 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 18:54 +0100
Re: CHAR_BIT is not eight Michael S <already5chosen@yahoo.com> - 2022-11-18 03:47 -0800
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-11-18 14:52 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-18 16:32 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 19:05 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-11-18 18:16 +0000
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 08:02 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-13 08:08 +0000
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:35 +0200
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 02:53 -0700
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:57 +0200
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 03:05 -0700
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-17 06:18 +0000
Re: CHAR_BIT is not eight Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-17 15:29 -0500
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-13 02:06 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 11:42 +0200
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-13 15:36 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 23:06 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-13 22:30 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-14 15:27 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-14 14:47 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-14 14:58 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-14 21:01 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 10:28 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-15 13:39 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 12:45 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:18 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:24 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:34 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:39 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:53 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:55 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:57 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:59 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 15:27 +0000
Re: CHAR_BIT is not eight "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-10-17 09:04 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 16:13 +0000
Re: CHAR_BIT is not eight red floyd <no.spam.here@its.invalid> - 2022-10-17 09:44 -0700
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:47 +0100
Re: CHAR_BIT is not eight Manfred <noname@add.invalid> - 2022-10-18 01:10 +0200
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-17 16:22 -0700
Re: CHAR_BIT is not eight Paul N <gw7rib@aol.com> - 2022-10-18 05:13 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-18 15:04 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-18 17:40 +0100
Re: CHAR_BIT is not eight "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-10-18 12:14 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-19 15:12 +0000
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-19 15:35 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-20 16:16 +0000
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 20:13 +0200
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 20:11 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 20:03 +0100
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-16 07:51 +0200
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 17:03 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 16:34 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 18:51 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 18:11 +0100
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 19:18 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 22:02 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 21:19 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-16 21:24 +0000
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 14:38 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 14:48 -0700
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 22:39 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-16 23:49 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 09:54 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:31 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 19:56 +0200
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 15:29 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:33 +0100
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 11:55 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-15 13:06 -0700
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 15:42 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 19:10 +0200
Re: CHAR_BIT is not eight Vir Campestris <vir.campestris@invalid.invalid> - 2022-10-16 21:28 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 10:09 +0200
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 13:35 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 13:36 -0700
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-02 17:46 -0700
Re: CHAR_BIT is not eight Bo Persson <bo@bo-persson.se> - 2022-10-13 11:10 +0200
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 10:49 +0000
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 12:05 +0000
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-13 06:34 -0700
Re: CHAR_BIT is not eight Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-13 15:24 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 15:59 +0200
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-14 05:54 +0000
Re: CHAR_BIT is not eight Paavo Helde <eesnimi@osa.pri.ee> - 2022-10-14 09:16 +0300
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-16 05:41 -0800
Re: CHAR_BIT is not eight Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-16 10:38 -0800
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-05 11:42 -0800
Re: CHAR_BIT is not eight Öö Tiib <ootiib@hot.ee> - 2022-12-06 01:03 -0800
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 20:49 -0800
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-14 00:17 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-14 15:33 +0200
Re: CHAR_BIT is not eight Vir Campestris <vir.campestris@invalid.invalid> - 2022-10-16 21:37 +0100
Re: CHAR_BIT is not eight Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-17 15:24 -0500
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:34 +0200
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| Date | 2022-10-12 15:57 -0700 |
| Subject | CHAR_BIT is not eight |
| Message-ID | <361b04cd-8be4-48c5-bc78-229f145eb343n@googlegroups.com> |
Since I started programming in C/C++ back in the early 2000's, I never encountered a compiler with CHAR_BIT anything other than 8. Well just now in the past 15 minutes, I was trying to get the code for the 'base58' algorithm to compile for the Texas Instruments F2809 microcontroller using the 'cl2000' compiler. At first I was puzzled as to why 'sizeof(long)' was coming back as 2. Of course my first assumption here was that 'long' was 16-Bit (even though the Standard says that a 'long' must be at least 32-Bit). So I figured that this compiler was just non-standard-compliant on a few issues. After a little messing around, I realised that CHAR_BIT is 16. I looked through the compiler manual and found this paragraph: "By ANSI/ISO C definition, the sizeof operator yields the number of bytes required to store an object. ANSI/ISO further stipulates that when sizeof is applied to char, the result is 1. Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits. This yields results you may not expect; for example, size of (int) = = 1 (not 2). TMS320C28x bytes and words are equivalent (16 bits). To access data in increments of 8 bits, use the __byte() and __mov_byte() intrinsics described in Section 7.6" So there you go: There are C++ compilers in use today in the year 2022 with CHAR_BIT something other than 8.
[toc] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-12 16:01 -0700 |
| Message-ID | <ti7h0v$1jeak$1@dont-email.me> |
| In reply to | #86894 |
On 10/12/2022 3:57 PM, Frederick Virchanza Gotham wrote: > Since I started programming in C/C++ back in the early 2000's, I never encountered a compiler with CHAR_BIT anything other than 8. > > Well just now in the past 15 minutes, I was trying to get the code for the 'base58' algorithm to compile for the Texas Instruments F2809 microcontroller using the 'cl2000' compiler. > > At first I was puzzled as to why 'sizeof(long)' was coming back as 2. Of course my first assumption here was that 'long' was 16-Bit (even though the Standard says that a 'long' must be at least 32-Bit). So I figured that this compiler was just non-standard-compliant on a few issues. > > After a little messing around, I realised that CHAR_BIT is 16. > > I looked through the compiler manual and found this paragraph: > > "By ANSI/ISO C definition, the sizeof operator yields the number of bytes required to store an object. ANSI/ISO further stipulates that when sizeof is applied to char, the result is 1. Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits. This yields results you may not expect; for example, size of (int) = = 1 (not 2). TMS320C28x bytes and words are equivalent (16 bits). To access data in increments of 8 bits, use the __byte() and __mov_byte() intrinsics described in Section 7.6" > > So there you go: There are C++ compilers in use today in the year 2022 with CHAR_BIT something other than 8. At least is should not be less than eight?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-10-12 17:16 -0700 |
| Message-ID | <877d144ly2.fsf@nosuchdomain.example.com> |
| In reply to | #86894 |
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> writes:
> Since I started programming in C/C++ back in the early 2000's, I never
> encountered a compiler with CHAR_BIT anything other than 8.
>
> Well just now in the past 15 minutes, I was trying to get the code for
> the 'base58' algorithm to compile for the Texas Instruments F2809
> microcontroller using the 'cl2000' compiler.
>
> At first I was puzzled as to why 'sizeof(long)' was coming back as
> 2. Of course my first assumption here was that 'long' was 16-Bit (even
> though the Standard says that a 'long' must be at least 32-Bit). So I
> figured that this compiler was just non-standard-compliant on a few
> issues.
>
> After a little messing around, I realised that CHAR_BIT is 16.
>
> I looked through the compiler manual and found this paragraph:
>
> "By ANSI/ISO C definition, the sizeof operator yields the number of
> bytes required to store an object. ANSI/ISO further stipulates that
> when sizeof is applied to char, the result is 1. Since the TMS320C28x
> char is 16 bits (to make it separately addressable), a byte is also 16
> bits. This yields results you may not expect; for example, size of
> (int) = = 1 (not 2). TMS320C28x bytes and words are equivalent (16
> bits). To access data in increments of 8 bits, use the __byte() and
> __mov_byte() intrinsics described in Section 7.6"
>
> So there you go: There are C++ compilers in use today in the year 2022
> with CHAR_BIT something other than 8.
Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've
heard that it's common for CHAR_BIT to be 16 or 32 in implementations
for DSPs.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-13 11:38 +0200 |
| Message-ID | <ti8mad$1p1cu$1@dont-email.me> |
| In reply to | #86897 |
On 13/10/2022 02:16, Keith Thompson wrote: > Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> writes: >> Since I started programming in C/C++ back in the early 2000's, I never >> encountered a compiler with CHAR_BIT anything other than 8. >> >> Well just now in the past 15 minutes, I was trying to get the code for >> the 'base58' algorithm to compile for the Texas Instruments F2809 >> microcontroller using the 'cl2000' compiler. >> >> At first I was puzzled as to why 'sizeof(long)' was coming back as >> 2. Of course my first assumption here was that 'long' was 16-Bit (even >> though the Standard says that a 'long' must be at least 32-Bit). So I >> figured that this compiler was just non-standard-compliant on a few >> issues. >> >> After a little messing around, I realised that CHAR_BIT is 16. >> >> I looked through the compiler manual and found this paragraph: >> >> "By ANSI/ISO C definition, the sizeof operator yields the number of >> bytes required to store an object. ANSI/ISO further stipulates that >> when sizeof is applied to char, the result is 1. Since the TMS320C28x >> char is 16 bits (to make it separately addressable), a byte is also 16 >> bits. This yields results you may not expect; for example, size of >> (int) = = 1 (not 2). TMS320C28x bytes and words are equivalent (16 >> bits). To access data in increments of 8 bits, use the __byte() and >> __mov_byte() intrinsics described in Section 7.6" >> >> So there you go: There are C++ compilers in use today in the year 2022 >> with CHAR_BIT something other than 8. > > Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've > heard that it's common for CHAR_BIT to be 16 or 32 in implementations > for DSPs. > Yes, that's correct. The TMS320 family are widely used in industrial electronics and high reliability or rough environment systems. They have 16-bit char. Most DSPs these days are very specialised devices, only programmed by a very few people and with virtually no overlap with "normal" programming. It's much easier to use a "normal" processor with SIMD and vector instructions to do the same job that previously needed a DSP for speed. But a DSP might have instructions that can handle multiple memory accesses from different ram banks, multiply-accumulate-saturate operations, pointer update with circular buffer wrapping or FFT bit-twiddling, loop counter decrement and checking, all within a single one-clock instruction. You don't really program these in C (much less C++) - it's really assembly, wrapped in a a C intrinsic. However, these are usually "hidden" coprocessors, using manufacturer-written binary blobs, rather than programmed by "normal" programmers. So your mobile phone chip might have a bunch of normal ARM cores and a hidden DSP for software-defined radio that you never access directly. There are also some DSP cores with odder CHAR size than 16 or 32, including soft cores where the size of a "byte" is determined when you add the core to your ASIC or FPGA. 24-bit used to be very common for audio and visual systems. The TMS320 and related devices from Texas Instruments are one of the few types of DSP that are still used by a wide variety of developers. Just be careful of TI's development tools - they have a tradition of being a little loose on standards conformance. A particular common feature of many of TI's tools is that they don't bother zero-initialising statically allocated implicitly initialised data (the ".bss" segment). That one caused me a lot of "fun" on a couple of occasions, once with a TMS320F28x device and once with a very different kind of microcontroller.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-11-16 06:24 -0800 |
| Message-ID | <d0337d59-c12c-44a3-95b6-7cd060c123a3n@googlegroups.com> |
| In reply to | #86897 |
On Thursday, October 13, 2022 at 3:16:54 A
> Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've
> heard that it's common for CHAR_BIT to be 16 or 32 in implementations
> for DSPs.
>
Late reaction, sorry.
No, TMS320C28xx, a.k.a. C2000 is not a DSP. It's a microcontroller
with DSP linage. C28 architecture is a 32-bit extension of C24
architecture which, in turn, is a derivative of TMS320C10 architecture
of early 1980s that was a [world's first popular] DSP.
TMS320C55xx, a.k.a. C5000 is another extant derivative TMS320C10
(via C25 and C54). This one is a DSP.
Why one is DSP and another is microcontroller?
Mostly because TI decided to call them taht way.
It is possible to find technical justifications as well, in their respective
architectures, micro-architectures and especially in sets of peripheral,
but all that is secondary to the will of manufacturer.
> --
> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
> Working, but not speaking, for Philips
> void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-17 11:04 +0100 |
| Message-ID | <tl50vr$2kj9m$1@dont-email.me> |
| In reply to | #87416 |
On 16/11/2022 15:24, Michael S wrote: > On Thursday, October 13, 2022 at 3:16:54 A >> Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've >> heard that it's common for CHAR_BIT to be 16 or 32 in implementations >> for DSPs. >> > > Late reaction, sorry. > No, TMS320C28xx, a.k.a. C2000 is not a DSP. It's a microcontroller > with DSP linage. C28 architecture is a 32-bit extension of C24 > architecture which, in turn, is a derivative of TMS320C10 architecture > of early 1980s that was a [world's first popular] DSP. > TMS320C55xx, a.k.a. C5000 is another extant derivative TMS320C10 > (via C25 and C54). This one is a DSP. > > Why one is DSP and another is microcontroller? > Mostly because TI decided to call them taht way. > It is possible to find technical justifications as well, in their respective > architectures, micro-architectures and especially in sets of peripheral, > but all that is secondary to the will of manufacturer. > It is a DSP, not a microcontroller - mostly because /I/ decide to call them that way :-) Of course there is no precise and universally agreed-upon distinction. Typical microcontroller traits are integrated peripherals (UART, I²C, SPI, PWM, Timers, CAN, etc.) and integrated memory. From that viewpoint, they are microcontrollers. Typical DSP traits are specialised processor cores with instructions and hardware targeting maximum throughput of FIR, IIR, FFT and other "DSP" algorithms, often at the expense of convenience of more "normal" code. The core of these devices (at least on the TMS320F24x device I have used) is clearly DSP oriented. It is very efficient for DSP style code, but a mess for more "random" stuff - trying to deal with 8-bit data, for example, is horrible. Probably the best way to describe these devices is microcontrollers with DSP cores.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-11-17 16:40 +0000 |
| Message-ID | <tl5o51$uv7$1@gioia.aioe.org> |
| In reply to | #87430 |
On Thu, 17 Nov 2022 11:04:42 +0100 David Brown <david.brown@hesbynett.no> wrote: >On 16/11/2022 15:24, Michael S wrote: >> On Thursday, October 13, 2022 at 3:16:54 A >>> Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've >>> heard that it's common for CHAR_BIT to be 16 or 32 in implementations >>> for DSPs. >>> >> >> Late reaction, sorry. >> No, TMS320C28xx, a.k.a. C2000 is not a DSP. It's a microcontroller >> with DSP linage. C28 architecture is a 32-bit extension of C24 >> architecture which, in turn, is a derivative of TMS320C10 architecture >> of early 1980s that was a [world's first popular] DSP. >> TMS320C55xx, a.k.a. C5000 is another extant derivative TMS320C10 >> (via C25 and C54). This one is a DSP. >> >> Why one is DSP and another is microcontroller? >> Mostly because TI decided to call them taht way. >> It is possible to find technical justifications as well, in their respective >> architectures, micro-architectures and especially in sets of peripheral, >> but all that is secondary to the will of manufacturer. >> > >It is a DSP, not a microcontroller - mostly because /I/ decide to call >them that way :-) > >Of course there is no precise and universally agreed-upon distinction. >Typical microcontroller traits are integrated peripherals (UART, I²C, >SPI, PWM, Timers, CAN, etc.) and integrated memory. From that To be fair a lot of microcontrollers have those too. I would define a DSP as something that can do ADC and/or DAC itself, ie it can process external data directly and the TI chips AFAIK can do that.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-17 23:23 -0500 |
| Message-ID | <mNDdL.680$ft35.98@fx12.iad> |
| In reply to | #87434 |
On 11/17/22 11:40 AM, Muttley@dastardlyhq.com wrote: > On Thu, 17 Nov 2022 11:04:42 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> On 16/11/2022 15:24, Michael S wrote: >>> On Thursday, October 13, 2022 at 3:16:54 A >>>> Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've >>>> heard that it's common for CHAR_BIT to be 16 or 32 in implementations >>>> for DSPs. >>>> >>> >>> Late reaction, sorry. >>> No, TMS320C28xx, a.k.a. C2000 is not a DSP. It's a microcontroller >>> with DSP linage. C28 architecture is a 32-bit extension of C24 >>> architecture which, in turn, is a derivative of TMS320C10 architecture >>> of early 1980s that was a [world's first popular] DSP. >>> TMS320C55xx, a.k.a. C5000 is another extant derivative TMS320C10 >>> (via C25 and C54). This one is a DSP. >>> >>> Why one is DSP and another is microcontroller? >>> Mostly because TI decided to call them taht way. >>> It is possible to find technical justifications as well, in their respective >>> architectures, micro-architectures and especially in sets of peripheral, >>> but all that is secondary to the will of manufacturer. >>> >> >> It is a DSP, not a microcontroller - mostly because /I/ decide to call >> them that way :-) >> >> Of course there is no precise and universally agreed-upon distinction. >> Typical microcontroller traits are integrated peripherals (UART, I²C, >> SPI, PWM, Timers, CAN, etc.) and integrated memory. From that > > To be fair a lot of microcontrollers have those too. I would define a DSP as > something that can do ADC and/or DAC itself, ie it can process external data > directly and the TI chips AFAIK can do that. > Analog <-> Digital conversion is not what makes a DSP a DSP. MANY ordinary microcontrollers have analog devices built in. DSP chips tend to be one optimized to do Multiply and Accumulate operations, particularly between vectors of values.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-18 08:16 +0100 |
| Message-ID | <tl7bga$2t05v$3@dont-email.me> |
| In reply to | #87440 |
On 18/11/2022 05:23, Richard Damon wrote: > On 11/17/22 11:40 AM, Muttley@dastardlyhq.com wrote: >> On Thu, 17 Nov 2022 11:04:42 +0100 >> David Brown <david.brown@hesbynett.no> wrote: >>> On 16/11/2022 15:24, Michael S wrote: >>>> On Thursday, October 13, 2022 at 3:16:54 A >>>>> Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've >>>>> heard that it's common for CHAR_BIT to be 16 or 32 in implementations >>>>> for DSPs. >>>>> >>>> >>>> Late reaction, sorry. >>>> No, TMS320C28xx, a.k.a. C2000 is not a DSP. It's a microcontroller >>>> with DSP linage. C28 architecture is a 32-bit extension of C24 >>>> architecture which, in turn, is a derivative of TMS320C10 architecture >>>> of early 1980s that was a [world's first popular] DSP. >>>> TMS320C55xx, a.k.a. C5000 is another extant derivative TMS320C10 >>>> (via C25 and C54). This one is a DSP. >>>> >>>> Why one is DSP and another is microcontroller? >>>> Mostly because TI decided to call them taht way. >>>> It is possible to find technical justifications as well, in their >>>> respective >>>> architectures, micro-architectures and especially in sets of >>>> peripheral, >>>> but all that is secondary to the will of manufacturer. >>>> >>> >>> It is a DSP, not a microcontroller - mostly because /I/ decide to call >>> them that way :-) >>> >>> Of course there is no precise and universally agreed-upon distinction. >>> Typical microcontroller traits are integrated peripherals (UART, I²C, >>> SPI, PWM, Timers, CAN, etc.) and integrated memory. From that >> >> To be fair a lot of microcontrollers have those too. I would define a >> DSP as >> something that can do ADC and/or DAC itself, ie it can process >> external data >> directly and the TI chips AFAIK can do that. >> > > Analog <-> Digital conversion is not what makes a DSP a DSP. MANY > ordinary microcontrollers have analog devices built in. > > DSP chips tend to be one optimized to do Multiply and Accumulate > operations, particularly between vectors of values. Yes. "DSP" is an aspect of the core and surrounding parts (such as specialised memory blocks). It means /Digital/ Signal Processing - it is independent of whether the device has /analogue/ signal handling. (Most serious DSP's don't, as the kind of device and surrounding electronics and layout that you need for quality analogue is very different from what you need for the digital parts of your system.)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-11-18 16:33 +0000 |
| Message-ID | <tl8c4v$1kik$1@gioia.aioe.org> |
| In reply to | #87442 |
On Fri, 18 Nov 2022 08:16:26 +0100 David Brown <david.brown@hesbynett.no> wrote: >On 18/11/2022 05:23, Richard Damon wrote: >> Analog <-> Digital conversion is not what makes a DSP a DSP. MANY >> ordinary microcontrollers have analog devices built in. >> >> DSP chips tend to be one optimized to do Multiply and Accumulate >> operations, particularly between vectors of values. > >Yes. "DSP" is an aspect of the core and surrounding parts (such as >specialised memory blocks). It means /Digital/ Signal Processing - it >is independent of whether the device has /analogue/ signal handling. You won't be processing any signals if you can't get the data which 99% of the time will be originating in the analogue realm.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-18 18:54 +0100 |
| Message-ID | <tl8gsa$301nh$1@dont-email.me> |
| In reply to | #87451 |
On 18/11/2022 17:33, Muttley@dastardlyhq.com wrote: > On Fri, 18 Nov 2022 08:16:26 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> On 18/11/2022 05:23, Richard Damon wrote: >>> Analog <-> Digital conversion is not what makes a DSP a DSP. MANY >>> ordinary microcontrollers have analog devices built in. >>> >>> DSP chips tend to be one optimized to do Multiply and Accumulate >>> operations, particularly between vectors of values. >> >> Yes. "DSP" is an aspect of the core and surrounding parts (such as >> specialised memory blocks). It means /Digital/ Signal Processing - it >> is independent of whether the device has /analogue/ signal handling. > > You won't be processing any signals if you can't get the data which 99% of > the time will be originating in the analogue realm. > Lots of data originates as digital, at least as far as your processing is concerned. Any kind of media player (music, TV, etc.) uses digital signal processing to handle signals that are digitised long before your telephone, TV or DAB radio ever sees it. And even when the electronics board in question takes in an analogue signal for processing, it is very frequently /not/ in the DSP device - it is digitised in a separate analogue to digital converter. Similarly, output goes through a separate digital to analogue converter of some kind. Analogue inputs are /much/ more common on /microcontrollers/, than on chips that are classified as DSP's. The TMS320 series are unusual in that they combine features of both kinds of chip.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-11-18 03:47 -0800 |
| Message-ID | <8b5b13c6-c179-4505-b3e1-f8139eef9dbbn@googlegroups.com> |
| In reply to | #87440 |
On Friday, November 18, 2022 at 6:24:03 AM UTC+2, Richard Damon wrote: > On 11/17/22 11:40 AM, Mut...@dastardlyhq.com wrote: > > On Thu, 17 Nov 2022 11:04:42 +0100 > > David Brown <david...@hesbynett.no> wrote: > >> On 16/11/2022 15:24, Michael S wrote: > >>> On Thursday, October 13, 2022 at 3:16:54 A > >>>> Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've > >>>> heard that it's common for CHAR_BIT to be 16 or 32 in implementations > >>>> for DSPs. > >>>> > >>> > >>> Late reaction, sorry. > >>> No, TMS320C28xx, a.k.a. C2000 is not a DSP. It's a microcontroller > >>> with DSP linage. C28 architecture is a 32-bit extension of C24 > >>> architecture which, in turn, is a derivative of TMS320C10 architecture > >>> of early 1980s that was a [world's first popular] DSP. > >>> TMS320C55xx, a.k.a. C5000 is another extant derivative TMS320C10 > >>> (via C25 and C54). This one is a DSP. > >>> > >>> Why one is DSP and another is microcontroller? > >>> Mostly because TI decided to call them taht way. > >>> It is possible to find technical justifications as well, in their respective > >>> architectures, micro-architectures and especially in sets of peripheral, > >>> but all that is secondary to the will of manufacturer. > >>> > >> > >> It is a DSP, not a microcontroller - mostly because /I/ decide to call > >> them that way :-) > >> > >> Of course there is no precise and universally agreed-upon distinction. > >> Typical microcontroller traits are integrated peripherals (UART, I²C, > >> SPI, PWM, Timers, CAN, etc.) and integrated memory. From that > > > > To be fair a lot of microcontrollers have those too. I would define a DSP as > > something that can do ADC and/or DAC itself, ie it can process external data > > directly and the TI chips AFAIK can do that. > > > Analog <-> Digital conversion is not what makes a DSP a DSP. MANY > ordinary microcontrollers have analog devices built in. > > DSP chips tend to be one optimized to do Multiply and Accumulate > operations, particularly between vectors of values. In practice, stand-alone DSP chips almost never had on-chip ADCs or DACs. Not because they didn't want, but because it precludes implementation on relatively modern silicon processes. And it is quite important for DSPs to be implemented on relatively modern process, because MOPs/Watt is far more important selling point for DSP than for MCU. All that applies to 1980 to ~2005. Later on stand-alone DSPs turned into shrinking and fragmenting niches. And after both leading manufacturers of stand-alone DSPs left the race for finer geometries, it became even harder to spot any trends.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-11-18 14:52 +0000 |
| Message-ID | <R_MdL.3893$dvL.2789@fx18.iad> |
| In reply to | #87445 |
Michael S <already5chosen@yahoo.com> writes: >On Friday, November 18, 2022 at 6:24:03 AM UTC+2, Richard Damon wrote: >> DSP chips tend to be one optimized to do Multiply and Accumulate=20 >> operations, particularly between vectors of values. > >In practice, stand-alone DSP chips almost never had on-chip ADCs >or DACs. >Not because they didn't want, but because it precludes implementation >on relatively modern silicon processes. And it is quite important for >DSPs to be implemented on relatively modern process, because=20 >MOPs/Watt is far more important selling point for DSP than for MCU. > >All that applies to 1980 to ~2005. >Later on stand-alone DSPs turned into shrinking and fragmenting niches.=20 >And after both leading manufacturers of stand-alone DSPs left >the race for finer geometries, it became even harder to spot any trends. Nowadays one just licenses the IP from Tensilica or Ceva and tape it out as part of a larger SoC package.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-11-18 16:32 +0000 |
| Message-ID | <tl8c35$1jar$1@gioia.aioe.org> |
| In reply to | #87440 |
On Thu, 17 Nov 2022 23:23:46 -0500 Richard Damon <Richard@Damon-Family.org> wrote: >On 11/17/22 11:40 AM, Muttley@dastardlyhq.com wrote: >> On Thu, 17 Nov 2022 11:04:42 +0100 >> David Brown <david.brown@hesbynett.no> wrote: >>> On 16/11/2022 15:24, Michael S wrote: >>>> On Thursday, October 13, 2022 at 3:16:54 A >>>>> Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've >>>>> heard that it's common for CHAR_BIT to be 16 or 32 in implementations >>>>> for DSPs. >>>>> >>>> >>>> Late reaction, sorry. >>>> No, TMS320C28xx, a.k.a. C2000 is not a DSP. It's a microcontroller >>>> with DSP linage. C28 architecture is a 32-bit extension of C24 >>>> architecture which, in turn, is a derivative of TMS320C10 architecture >>>> of early 1980s that was a [world's first popular] DSP. >>>> TMS320C55xx, a.k.a. C5000 is another extant derivative TMS320C10 >>>> (via C25 and C54). This one is a DSP. >>>> >>>> Why one is DSP and another is microcontroller? >>>> Mostly because TI decided to call them taht way. >>>> It is possible to find technical justifications as well, in their >respective >>>> architectures, micro-architectures and especially in sets of peripheral, >>>> but all that is secondary to the will of manufacturer. >>>> >>> >>> It is a DSP, not a microcontroller - mostly because /I/ decide to call >>> them that way :-) >>> >>> Of course there is no precise and universally agreed-upon distinction. >>> Typical microcontroller traits are integrated peripherals (UART, I²C, >>> SPI, PWM, Timers, CAN, etc.) and integrated memory. From that >> >> To be fair a lot of microcontrollers have those too. I would define a DSP as >> something that can do ADC and/or DAC itself, ie it can process external data >> directly and the TI chips AFAIK can do that. >> > >Analog <-> Digital conversion is not what makes a DSP a DSP. MANY >ordinary microcontrollers have analog devices built in. > >DSP chips tend to be one optimized to do Multiply and Accumulate >operations, particularly between vectors of values. Using that definition x86 post pentium are DSPs.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-18 19:05 +0100 |
| Message-ID | <tl8hi6$301nh$2@dont-email.me> |
| In reply to | #87450 |
On 18/11/2022 17:32, Muttley@dastardlyhq.com wrote: > On Thu, 17 Nov 2022 23:23:46 -0500 > Richard Damon <Richard@Damon-Family.org> wrote: >> On 11/17/22 11:40 AM, Muttley@dastardlyhq.com wrote: >>> On Thu, 17 Nov 2022 11:04:42 +0100 >>> David Brown <david.brown@hesbynett.no> wrote: >>>> On 16/11/2022 15:24, Michael S wrote: >>>>> On Thursday, October 13, 2022 at 3:16:54 A >>>>>> Apparently the TMS320C28x is a DSP (Digital Signal Processor). I've >>>>>> heard that it's common for CHAR_BIT to be 16 or 32 in implementations >>>>>> for DSPs. >>>>>> >>>>> >>>>> Late reaction, sorry. >>>>> No, TMS320C28xx, a.k.a. C2000 is not a DSP. It's a microcontroller >>>>> with DSP linage. C28 architecture is a 32-bit extension of C24 >>>>> architecture which, in turn, is a derivative of TMS320C10 architecture >>>>> of early 1980s that was a [world's first popular] DSP. >>>>> TMS320C55xx, a.k.a. C5000 is another extant derivative TMS320C10 >>>>> (via C25 and C54). This one is a DSP. >>>>> >>>>> Why one is DSP and another is microcontroller? >>>>> Mostly because TI decided to call them taht way. >>>>> It is possible to find technical justifications as well, in their >> respective >>>>> architectures, micro-architectures and especially in sets of peripheral, >>>>> but all that is secondary to the will of manufacturer. >>>>> >>>> >>>> It is a DSP, not a microcontroller - mostly because /I/ decide to call >>>> them that way :-) >>>> >>>> Of course there is no precise and universally agreed-upon distinction. >>>> Typical microcontroller traits are integrated peripherals (UART, I²C, >>>> SPI, PWM, Timers, CAN, etc.) and integrated memory. From that >>> >>> To be fair a lot of microcontrollers have those too. I would define a DSP as >>> something that can do ADC and/or DAC itself, ie it can process external data >>> directly and the TI chips AFAIK can do that. >>> >> >> Analog <-> Digital conversion is not what makes a DSP a DSP. MANY >> ordinary microcontrollers have analog devices built in. >> >> DSP chips tend to be one optimized to do Multiply and Accumulate >> operations, particularly between vectors of values. > > Using that definition x86 post pentium are DSPs. > Do you understand the difference between the phrases "are optimised for" and "are good at" ? The fact that general-purpose processors have been getting better at handling DSP algorithms does not make them DSPs. It /does/ mean the market for DSP's has dropped significantly - few people bother with the complexities of a DSP design if you can just use an ARM microcontroller or a desktop PC. But general purpose PC's do this by brute force, with a few DSP-style operations like MAC. High-class DSP cores will have instructions that combine fetch of data from 3 different sources at once, apply a MAC to them, saturate the results, store the results, increment all the pointers involved with circular buffer wrapping where needed, decrement and check a loop counter, and perform the loop - all in a /single/ instruction, in a /single/ clock cycle (with a few cycles pipelining). They will keep this up continuously - no cache delays, scheduling issues, history buffers, or any other unexpected variations in speed. Some will do several of these operations in parallel - in each core. That is their purpose, and they do it very well - orders of magnitude more efficiently than using a fast desktop PC. The reason you no longer see so many DSP's is that general purpose CPUs do the job fast enough, and you have the CPU anyway. Once you can decode audio or video fast enough to watch, there's no need to go faster. (Actually, the main reason you don't see DSP's is that they are hidden inside equipment and most people have no idea there's a processing element in there.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-11-18 18:16 +0000 |
| Message-ID | <i_PdL.11254$cVTf.8182@fx16.iad> |
| In reply to | #87453 |
David Brown <david.brown@hesbynett.no> writes: >On 18/11/2022 17:32, Muttley@dastardlyhq.com wrote: > >The reason you no longer see so many DSP's is that general purpose CPUs >do the job fast enough, and you have the CPU anyway. Once you can >decode audio or video fast enough to watch, there's no need to go faster. > >(Actually, the main reason you don't see DSP's is that they are hidden >inside equipment and most people have no idea there's a processing >element in there.) A good example is 5G base stations to process the 5G waveforms.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-10-13 08:02 +0000 |
| Message-ID | <ti8gnh$kqe$1@gioia.aioe.org> |
| In reply to | #86894 |
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> wrote: > So there you go: There are C++ compilers in use today in the year 2022 with CHAR_BIT something other than 8. The vast, *vast* majority of C and C++ programmers assume that 'char' is always 8-bit, and sometimes write code making that assumption. It's *extremely* rare to see any code out there that uses CHAR_BIT at all, but it's quite common to see code that assumes that it's 8. Most C and C++ programmers just assume that it's a de-facto universal standard, and that the actual C and C++ standards are just antiquated in this regard, by keeping "backwards compatibility" with some more exotic CPUs from the 1970's that have been completely obsolete for decades. I suppose there's a good reason why the language standards don't assume that 'char' is 8 bits, after all.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-10-13 08:08 +0000 |
| Message-ID | <ti8h26$pns$1@gioia.aioe.org> |
| In reply to | #86911 |
On Thu, 13 Oct 2022 08:02:59 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> wrote: >> So there you go: There are C++ compilers in use today in the year 2022 with >CHAR_BIT something other than 8. > >The vast, *vast* majority of C and C++ programmers assume that 'char' is >always 8-bit, and sometimes write code making that assumption. It's >*extremely* rare to see any code out there that uses CHAR_BIT at all, >but it's quite common to see code that assumes that it's 8. Most C and >C++ programmers just assume that it's a de-facto universal standard, >and that the actual C and C++ standards are just antiquated in this >regard, by keeping "backwards compatibility" with some more exotic >CPUs from the 1970's that have been completely obsolete for decades. > >I suppose there's a good reason why the language standards don't assume >that 'char' is 8 bits, after all. A number of current Texas Instruments DSPs have 16 bit chars. Personally I always use int8_t or uint8_t if I'm writing portable code just to be 100% sure.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-15 11:35 +0200 |
| Message-ID | <tidusj$2l925$2@dont-email.me> |
| In reply to | #86912 |
Am 13.10.2022 um 10:08 schrieb Muttley@dastardlyhq.com: > On Thu, 13 Oct 2022 08:02:59 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >> Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> wrote: >>> So there you go: There are C++ compilers in use today in the year 2022 with >> CHAR_BIT something other than 8. >> >> The vast, *vast* majority of C and C++ programmers assume that 'char' is >> always 8-bit, and sometimes write code making that assumption. It's >> *extremely* rare to see any code out there that uses CHAR_BIT at all, >> but it's quite common to see code that assumes that it's 8. Most C and >> C++ programmers just assume that it's a de-facto universal standard, >> and that the actual C and C++ standards are just antiquated in this >> regard, by keeping "backwards compatibility" with some more exotic >> CPUs from the 1970's that have been completely obsolete for decades. >> >> I suppose there's a good reason why the language standards don't assume >> that 'char' is 8 bits, after all. > > A number of current Texas Instruments DSPs have 16 bit chars. And you need portable code for that architectures ?
[toc] | [prev] | [next] | [standalone]
| From | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| Date | 2022-10-15 02:53 -0700 |
| Message-ID | <65951610-95b4-4e21-806a-2fe35ca6a438n@googlegroups.com> |
| In reply to | #86974 |
On Saturday, October 15, 2022 at 10:35:32 AM UTC+1, Bonita Montero wrote: > Am 13.10.2022 um 10:08 schrieb Mut: > > A number of current Texas Instruments DSPs have 16 bit chars. > > And you need portable code for that architectures ? I need to write a cryptography header file to be used on two kinds of microcontroller (Arduino with CHAR_BIT==8, Texas Instruments with CHAR_BIT==16), and also on a Desktop PC x86_64. I've decided to deal with 32-Bit chunks at a time using uint_least32_t.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web