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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-15 11:57 +0200 |
| Message-ID | <tie05s$2lf56$5@dont-email.me> |
| In reply to | #86975 |
Am 15.10.2022 um 11:53 schrieb Frederick Virchanza Gotham: > 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. You need cryptography on a DSP ???
[toc] | [prev] | [next] | [standalone]
| From | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| Date | 2022-10-15 03:05 -0700 |
| Message-ID | <eeeeb859-7fa8-48e0-b0bd-176f6bb46122n@googlegroups.com> |
| In reply to | #86976 |
On Saturday, October 15, 2022 at 10:57:33 AM UTC+1, Bonita Montero wrote: > > 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. > You need cryptography on a DSP ??? Yeah I program a commercial product that is sold in two varieties (one being more expensive than the other). The hardware in both varieties is the same, it's only the firmware that's different. So if you buy the cheap one and then want to upgrade to the more expensive one, you get sent a code in an email. You enter the code into the device, it decrypts it and checks that it's correct and then unlocks the features.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-10-17 06:18 +0000 |
| Message-ID | <tiis34$13k0$1@gioia.aioe.org> |
| In reply to | #86976 |
Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 15.10.2022 um 11:53 schrieb Frederick Virchanza Gotham: > >> 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. > > You need cryptography on a DSP ??? I think you should take to heart the saying "better to remain silent and be thought a fool than to speak and remove all doubt".
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2022-10-17 15:29 -0500 |
| Message-ID | <tikdvg$3h56e$2@dont-email.me> |
| In reply to | #86976 |
On 10/15/2022 4:57 AM, Bonita Montero wrote: > Am 15.10.2022 um 11:53 schrieb Frederick Virchanza Gotham: > >> 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. > > You need cryptography on a DSP ??? Every one need cryptography. If you are processing in the clear then you will be owned sooner or later. Lynn
[toc] | [prev] | [next] | [standalone]
| From | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| Date | 2022-10-13 02:06 -0700 |
| Message-ID | <e8eafc6a-cea4-4099-b666-d9cdc2d3489en@googlegroups.com> |
| In reply to | #86911 |
On Thursday, October 13, 2022, Juha Nieminen wrote:
> 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.
I totally agree. I've been using C++ compilers for about 20 years now, and yesterday was the first time I encountered CHAR_BIT != 8. Lots of my code uses "char unsigned" and "uint8_t" interchangeably.
On Thursday, October 13, 2022, Mut...@... wrote:
> 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.
I'm writing a 'universal header file' today that will be used in a program on:
1) x86_64 desktop PC
2) microcontroller Texas Instruments F2809 (with 16-Bit bytes)
3) microcontroller Arduino sam3x8e
If I include "cstdint", then it doesn't have "uint8_t" on the Texas Instruments compiler. So I'm using "uint_least8_t" in the code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-13 11:42 +0200 |
| Message-ID | <ti8mir$1p209$1@dont-email.me> |
| In reply to | #86915 |
On 13/10/2022 11:06, Frederick Virchanza Gotham wrote: > On Thursday, October 13, 2022, Juha Nieminen wrote: >> 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. > > > I totally agree. I've been using C++ compilers for about 20 years now, and yesterday was the first time I encountered CHAR_BIT != 8. Lots of my code uses "char unsigned" and "uint8_t" interchangeably. > > > On Thursday, October 13, 2022, Mut...@... wrote: >> 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. > > I'm writing a 'universal header file' today that will be used in a program on: > 1) x86_64 desktop PC > 2) microcontroller Texas Instruments F2809 (with 16-Bit bytes) > 3) microcontroller Arduino sam3x8e > > If I include "cstdint", then it doesn't have "uint8_t" on the Texas Instruments compiler. So I'm using "uint_least8_t" in the code. > That's one solution, yes. Another is to avoid 8-bit types entirely, and use uint16_t as your smallest type. That makes it easier to be sure sizes and structs are the same size in every case. (This depends on what you need to do in the header, of course.) Static assertions are your friend to ensure that everything (such as struct size) is as you expect on all targets. It is not common to program DSP's like the TMS320 using C++ - usually C is the language of choice. But maybe TI's C++ compilers have improved since I last looked (which was a long time ago). It's generally not hard to make a common header that is suitable for C and C++, for flexibility.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-10-13 15:36 +0000 |
| Message-ID | <ti9bar$1qfh$1@gioia.aioe.org> |
| In reply to | #86919 |
On Thu, 13 Oct 2022 11:42:50 +0200 David Brown <david.brown@hesbynett.no> wrote: >It is not common to program DSP's like the TMS320 using C++ - usually C >is the language of choice. But maybe TI's C++ compilers have improved >since I last looked (which was a long time ago). It's generally not >hard to make a common header that is suitable for C and C++, for >flexibility. IIRC some of the TI chips use 16 bit addressing so 32 bit addressing requires a lot of faffing around with paging and offsets which makes using pointers very expensive and that in turn makes C++ features such as virtual functions slow and even assuming the STL would even fit in memory it would run like a half dead dog.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-13 23:06 +0200 |
| Message-ID | <ti9ulc$1sd84$1@dont-email.me> |
| In reply to | #86927 |
On 13/10/2022 17:36, Muttley@dastardlyhq.com wrote: > On Thu, 13 Oct 2022 11:42:50 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> It is not common to program DSP's like the TMS320 using C++ - usually C >> is the language of choice. But maybe TI's C++ compilers have improved >> since I last looked (which was a long time ago). It's generally not >> hard to make a common header that is suitable for C and C++, for >> flexibility. > > IIRC some of the TI chips use 16 bit addressing so 32 bit addressing requires a > lot of faffing around with paging and offsets which makes using pointers very > expensive and that in turn makes C++ features such as virtual functions > slow and even assuming the STL would even fit in memory it would run like a > half dead dog. > Most of these chips don't have more than 64 KB memory (flash and ram) to address, making that a moot point. But you do get the fun of multiple address spaces in many DSPs. There are other TI chips that /do/ have 16-bit pointers and on some devices have more than 64 KB memory. Some of the MSP430 devices are like that. Some of them have "solved" this by having 20-bit registers, which adds to their interest. (The pure 16-bit MSP430 are very C-friendly, with an architecture similar to the original C DEC targets.) Yes, paging of any kind is a pain for some kinds of coding that you take for granted on "big" processors. But for the kinds of systems these devices target, you almost never want any kind of dynamic memory anyway - thus you have no problems with the C++ standard library containers because you'd never use such things (other than std::array).
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-13 22:30 +0100 |
| Message-ID | <20221013223034.00002f0b@reddwarf.jmc.corp> |
| In reply to | #86933 |
On Thu, 13 Oct 2022 23:06:51 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 13/10/2022 17:36, Muttley@dastardlyhq.com wrote: > > On Thu, 13 Oct 2022 11:42:50 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > >> It is not common to program DSP's like the TMS320 using C++ - > >> usually C is the language of choice. But maybe TI's C++ compilers > >> have improved since I last looked (which was a long time ago). > >> It's generally not hard to make a common header that is suitable > >> for C and C++, for flexibility. > > > > IIRC some of the TI chips use 16 bit addressing so 32 bit > > addressing requires a lot of faffing around with paging and offsets > > which makes using pointers very expensive and that in turn makes > > C++ features such as virtual functions slow and even assuming the > > STL would even fit in memory it would run like a half dead dog. > > > > Most of these chips don't have more than 64 KB memory (flash and ram) > to address, making that a moot point. But you do get the fun of > multiple address spaces in many DSPs. > > There are other TI chips that /do/ have 16-bit pointers and on some > devices have more than 64 KB memory. Some of the MSP430 devices are > like that. Some of them have "solved" this by having 20-bit > registers, which adds to their interest. (The pure 16-bit MSP430 are > very C-friendly, with an architecture similar to the original C DEC > targets.) > > Yes, paging of any kind is a pain for some kinds of coding that you > take for granted on "big" processors. But for the kinds of systems > these devices target, you almost never want any kind of dynamic > memory anyway > - thus you have no problems with the C++ standard library containers > because you'd never use such things (other than std::array). Why just std::array? You could use any container with a suitable allocator. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-14 15:27 +0200 |
| Message-ID | <tibo3h$24fcq$1@dont-email.me> |
| In reply to | #86937 |
On 13/10/2022 23:30, Mr Flibble wrote: > On Thu, 13 Oct 2022 23:06:51 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 13/10/2022 17:36, Muttley@dastardlyhq.com wrote: >>> On Thu, 13 Oct 2022 11:42:50 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>>> It is not common to program DSP's like the TMS320 using C++ - >>>> usually C is the language of choice. But maybe TI's C++ compilers >>>> have improved since I last looked (which was a long time ago). >>>> It's generally not hard to make a common header that is suitable >>>> for C and C++, for flexibility. >>> >>> IIRC some of the TI chips use 16 bit addressing so 32 bit >>> addressing requires a lot of faffing around with paging and offsets >>> which makes using pointers very expensive and that in turn makes >>> C++ features such as virtual functions slow and even assuming the >>> STL would even fit in memory it would run like a half dead dog. >>> >> >> Most of these chips don't have more than 64 KB memory (flash and ram) >> to address, making that a moot point. But you do get the fun of >> multiple address spaces in many DSPs. >> >> There are other TI chips that /do/ have 16-bit pointers and on some >> devices have more than 64 KB memory. Some of the MSP430 devices are >> like that. Some of them have "solved" this by having 20-bit >> registers, which adds to their interest. (The pure 16-bit MSP430 are >> very C-friendly, with an architecture similar to the original C DEC >> targets.) >> >> Yes, paging of any kind is a pain for some kinds of coding that you >> take for granted on "big" processors. But for the kinds of systems >> these devices target, you almost never want any kind of dynamic >> memory anyway >> - thus you have no problems with the C++ standard library containers >> because you'd never use such things (other than std::array). > > Why just std::array? You could use any container with a suitable > allocator. > Yes, it is always /possible/. But the complications and effort involved is unlikely to be worth the effort, and you'd still end up with something taking a massive amount of code space. (With "massive" being relative to the small code memories of such systems.) It's not uncommon in my coding to build up a few lists at the startup of the system - lists of "run" functions or software timers, etc. Modules might register such callbacks or functions when initialised. In "big system" C++, you might just use a vector for that - adding your timer objects to your vector as needed. It's simple and easy in the code. But in a resource-constraint embedded system, where efficiency of code space, ram space and run-time is important (though run-time efficiency is usually less important for startup code), that's not what you would do. You make your timer class have the required list link pointers in the class, have each registering function declare their timer object with static lifetime, and your registration function links them together. There's no doubt that this takes a bit more effort to write than an off-the-shelf std::vector. But it is vastly simpler than faffing around making your own allocator, avoids the use of any kind of dynamic memory (using neither the standard heap nor a home-made allocation system), and pulls in a tiny fraction of the amount of library code. std::array<> is free - it's just a nice wrapper around a plain C-style array.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-14 14:47 +0100 |
| Message-ID | <20221014144746.00000b28@reddwarf.jmc.corp> |
| In reply to | #86954 |
On Fri, 14 Oct 2022 15:27:13 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 13/10/2022 23:30, Mr Flibble wrote: > > On Thu, 13 Oct 2022 23:06:51 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> On 13/10/2022 17:36, Muttley@dastardlyhq.com wrote: > >>> On Thu, 13 Oct 2022 11:42:50 +0200 > >>> David Brown <david.brown@hesbynett.no> wrote: > >>>> It is not common to program DSP's like the TMS320 using C++ - > >>>> usually C is the language of choice. But maybe TI's C++ > >>>> compilers have improved since I last looked (which was a long > >>>> time ago). It's generally not hard to make a common header that > >>>> is suitable for C and C++, for flexibility. > >>> > >>> IIRC some of the TI chips use 16 bit addressing so 32 bit > >>> addressing requires a lot of faffing around with paging and > >>> offsets which makes using pointers very expensive and that in > >>> turn makes C++ features such as virtual functions slow and even > >>> assuming the STL would even fit in memory it would run like a > >>> half dead dog. > >> > >> Most of these chips don't have more than 64 KB memory (flash and > >> ram) to address, making that a moot point. But you do get the fun > >> of multiple address spaces in many DSPs. > >> > >> There are other TI chips that /do/ have 16-bit pointers and on some > >> devices have more than 64 KB memory. Some of the MSP430 devices > >> are like that. Some of them have "solved" this by having 20-bit > >> registers, which adds to their interest. (The pure 16-bit MSP430 > >> are very C-friendly, with an architecture similar to the original > >> C DEC targets.) > >> > >> Yes, paging of any kind is a pain for some kinds of coding that you > >> take for granted on "big" processors. But for the kinds of systems > >> these devices target, you almost never want any kind of dynamic > >> memory anyway > >> - thus you have no problems with the C++ standard library > >> containers because you'd never use such things (other than > >> std::array). > > > > Why just std::array? You could use any container with a suitable > > allocator. > > > > Yes, it is always /possible/. But the complications and effort > involved is unlikely to be worth the effort, and you'd still end up > with something taking a massive amount of code space. (With > "massive" being relative to the small code memories of such systems.) > > It's not uncommon in my coding to build up a few lists at the startup > of the system - lists of "run" functions or software timers, etc. > Modules might register such callbacks or functions when initialised. > In "big system" C++, you might just use a vector for that - adding > your timer objects to your vector as needed. It's simple and easy in > the code. > > But in a resource-constraint embedded system, where efficiency of > code space, ram space and run-time is important (though run-time > efficiency is usually less important for startup code), that's not > what you would do. You make your timer class have the required list > link pointers in the class, have each registering function declare > their timer object with static lifetime, and your registration > function links them together. > > There's no doubt that this takes a bit more effort to write than an > off-the-shelf std::vector. But it is vastly simpler than faffing > around making your own allocator, avoids the use of any kind of > dynamic memory (using neither the standard heap nor a home-made > allocation system), and pulls in a tiny fraction of the amount of > library code. > > std::array<> is free - it's just a nice wrapper around a plain > C-style array. List link pointers? Again there is no reason to not use std::list with a suitable allocator even on such resource constrained hardware and I disagree that the resultant text size and ram usage would be any worse than anything you could come up with by hand. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-10-14 14:58 +0000 |
| Message-ID | <tibtfd$1sps$1@gioia.aioe.org> |
| In reply to | #86956 |
On Fri, 14 Oct 2022 14:47:46 +0100 Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >On Fri, 14 Oct 2022 15:27:13 +0200 >David Brown <david.brown@hesbynett.no> wrote: >> Yes, it is always /possible/. But the complications and effort >> involved is unlikely to be worth the effort, and you'd still end up >> with something taking a massive amount of code space. (With >> "massive" being relative to the small code memories of such systems.) >> >> It's not uncommon in my coding to build up a few lists at the startup >> of the system - lists of "run" functions or software timers, etc. >> Modules might register such callbacks or functions when initialised. >> In "big system" C++, you might just use a vector for that - adding >> your timer objects to your vector as needed. It's simple and easy in >> the code. >> >> But in a resource-constraint embedded system, where efficiency of >> code space, ram space and run-time is important (though run-time >> efficiency is usually less important for startup code), that's not >> what you would do. You make your timer class have the required list >> link pointers in the class, have each registering function declare >> their timer object with static lifetime, and your registration >> function links them together. >> >> There's no doubt that this takes a bit more effort to write than an >> off-the-shelf std::vector. But it is vastly simpler than faffing >> around making your own allocator, avoids the use of any kind of >> dynamic memory (using neither the standard heap nor a home-made >> allocation system), and pulls in a tiny fraction of the amount of >> library code. >> >> std::array<> is free - it's just a nice wrapper around a plain >> C-style array. > >List link pointers? Again there is no reason to not use std::list with >a suitable allocator even on such resource constrained hardware and I >disagree that the resultant text size and ram usage would be any worse >than anything you could come up with by hand. If the memory layout is hard coded at boot time why even bother pulling in std::list or any kind of container as you don't need their generic functionality which will almost certainly waste EEPROM space. With embedded development you often literally have to worry about every byte you use both in ROM and RAM and whether the mainloop is going to be fast enough to do its job.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-14 21:01 +0100 |
| Message-ID | <20221014210120.00005b43@reddwarf.jmc.corp> |
| In reply to | #86958 |
On Fri, 14 Oct 2022 14:58:54 -0000 (UTC) Muttley@dastardlyhq.com wrote: > On Fri, 14 Oct 2022 14:47:46 +0100 > Mr Flibble <flibble@reddwarf.jmc.corp> wrote: > >On Fri, 14 Oct 2022 15:27:13 +0200 > >David Brown <david.brown@hesbynett.no> wrote: > >> Yes, it is always /possible/. But the complications and effort > >> involved is unlikely to be worth the effort, and you'd still end up > >> with something taking a massive amount of code space. (With > >> "massive" being relative to the small code memories of such > >> systems.) > >> > >> It's not uncommon in my coding to build up a few lists at the > >> startup of the system - lists of "run" functions or software > >> timers, etc. Modules might register such callbacks or functions > >> when initialised. In "big system" C++, you might just use a vector > >> for that - adding your timer objects to your vector as needed. > >> It's simple and easy in the code. > >> > >> But in a resource-constraint embedded system, where efficiency of > >> code space, ram space and run-time is important (though run-time > >> efficiency is usually less important for startup code), that's not > >> what you would do. You make your timer class have the required > >> list link pointers in the class, have each registering function > >> declare their timer object with static lifetime, and your > >> registration function links them together. > >> > >> There's no doubt that this takes a bit more effort to write than > >> an off-the-shelf std::vector. But it is vastly simpler than > >> faffing around making your own allocator, avoids the use of any > >> kind of dynamic memory (using neither the standard heap nor a > >> home-made allocation system), and pulls in a tiny fraction of the > >> amount of library code. > >> > >> std::array<> is free - it's just a nice wrapper around a plain > >> C-style array. > > > >List link pointers? Again there is no reason to not use std::list > >with a suitable allocator even on such resource constrained hardware > >and I disagree that the resultant text size and ram usage would be > >any worse than anything you could come up with by hand. > > If the memory layout is hard coded at boot time why even bother > pulling in std::list or any kind of container as you don't need their > generic functionality which will almost certainly waste EEPROM space. > With embedded development you often literally have to worry about > every byte you use both in ROM and RAM and whether the mainloop is > going to be fast enough to do its job. In C++ you don't pay for what you don't use: in the case of a C++ class template only the member functions instantiated will exist in the text segment. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-10-15 10:28 +0000 |
| Message-ID | <tie20p$31v$1@gioia.aioe.org> |
| In reply to | #86966 |
On Fri, 14 Oct 2022 21:01:20 +0100 Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >On Fri, 14 Oct 2022 14:58:54 -0000 (UTC) >Muttley@dastardlyhq.com wrote: > >> On Fri, 14 Oct 2022 14:47:46 +0100 >> Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >> >On Fri, 14 Oct 2022 15:27:13 +0200 >> >David Brown <david.brown@hesbynett.no> wrote: >> >> Yes, it is always /possible/. But the complications and effort >> >> involved is unlikely to be worth the effort, and you'd still end up >> >> with something taking a massive amount of code space. (With >> >> "massive" being relative to the small code memories of such >> >> systems.) >> >> >> >> It's not uncommon in my coding to build up a few lists at the >> >> startup of the system - lists of "run" functions or software >> >> timers, etc. Modules might register such callbacks or functions >> >> when initialised. In "big system" C++, you might just use a vector >> >> for that - adding your timer objects to your vector as needed. >> >> It's simple and easy in the code. >> >> >> >> But in a resource-constraint embedded system, where efficiency of >> >> code space, ram space and run-time is important (though run-time >> >> efficiency is usually less important for startup code), that's not >> >> what you would do. You make your timer class have the required >> >> list link pointers in the class, have each registering function >> >> declare their timer object with static lifetime, and your >> >> registration function links them together. >> >> >> >> There's no doubt that this takes a bit more effort to write than >> >> an off-the-shelf std::vector. But it is vastly simpler than >> >> faffing around making your own allocator, avoids the use of any >> >> kind of dynamic memory (using neither the standard heap nor a >> >> home-made allocation system), and pulls in a tiny fraction of the >> >> amount of library code. >> >> >> >> std::array<> is free - it's just a nice wrapper around a plain >> >> C-style array. >> > >> >List link pointers? Again there is no reason to not use std::list >> >with a suitable allocator even on such resource constrained hardware >> >and I disagree that the resultant text size and ram usage would be >> >any worse than anything you could come up with by hand. >> >> If the memory layout is hard coded at boot time why even bother >> pulling in std::list or any kind of container as you don't need their >> generic functionality which will almost certainly waste EEPROM space. >> With embedded development you often literally have to worry about >> every byte you use both in ROM and RAM and whether the mainloop is >> going to be fast enough to do its job. > >In C++ you don't pay for what you don't use: in the case of a C++ class >template only the member functions instantiated will exist in the text >segment. Same as in C obv. My issue is that it may well be built in a generic way that will include a lot of functions that are not required if you did it manually at the start. eg pop_front(), insert() etc. > >/Flibble >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-15 13:39 +0200 |
| Message-ID | <tie65c$2n1ei$1@dont-email.me> |
| In reply to | #86966 |
On 14/10/2022 22:01, Mr Flibble wrote: > On Fri, 14 Oct 2022 14:58:54 -0000 (UTC) > Muttley@dastardlyhq.com wrote: > >> On Fri, 14 Oct 2022 14:47:46 +0100 >> Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >>> On Fri, 14 Oct 2022 15:27:13 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>>> Yes, it is always /possible/. But the complications and effort >>>> involved is unlikely to be worth the effort, and you'd still end up >>>> with something taking a massive amount of code space. (With >>>> "massive" being relative to the small code memories of such >>>> systems.) >>>> >>>> It's not uncommon in my coding to build up a few lists at the >>>> startup of the system - lists of "run" functions or software >>>> timers, etc. Modules might register such callbacks or functions >>>> when initialised. In "big system" C++, you might just use a vector >>>> for that - adding your timer objects to your vector as needed. >>>> It's simple and easy in the code. >>>> >>>> But in a resource-constraint embedded system, where efficiency of >>>> code space, ram space and run-time is important (though run-time >>>> efficiency is usually less important for startup code), that's not >>>> what you would do. You make your timer class have the required >>>> list link pointers in the class, have each registering function >>>> declare their timer object with static lifetime, and your >>>> registration function links them together. >>>> >>>> There's no doubt that this takes a bit more effort to write than >>>> an off-the-shelf std::vector. But it is vastly simpler than >>>> faffing around making your own allocator, avoids the use of any >>>> kind of dynamic memory (using neither the standard heap nor a >>>> home-made allocation system), and pulls in a tiny fraction of the >>>> amount of library code. >>>> >>>> std::array<> is free - it's just a nice wrapper around a plain >>>> C-style array. >>> >>> List link pointers? Again there is no reason to not use std::list >>> with a suitable allocator even on such resource constrained hardware >>> and I disagree that the resultant text size and ram usage would be >>> any worse than anything you could come up with by hand. >> >> If the memory layout is hard coded at boot time why even bother >> pulling in std::list or any kind of container as you don't need their >> generic functionality which will almost certainly waste EEPROM space. >> With embedded development you often literally have to worry about >> every byte you use both in ROM and RAM and whether the mainloop is >> going to be fast enough to do its job. > > In C++ you don't pay for what you don't use: in the case of a C++ class > template only the member functions instantiated will exist in the text > segment. > There are always /lots/ of other functions that get pulled in from libraries. Remember, for small embedded systems the libraries are not shared dynamic libraries that you don't see. Just for a quick test, I made a minimal C++ main() function and compiled for a modern microcontroller. With an empty main(), it was about 8400 bytes code of common library code. Adding a "std::list<int>" object and using a couple of pops and pushes adds about 7 KB code to the program. If you are making a lot of use of the standard containers, that's fine - and there's a lot of overlap and sharing in this extra code. But in small systems, this kind of stuff can get significant - microcontrollers with 32 KB flash are common, and it's nice to be able to program them in C++. In the C++ /language/, you pay very little (not quite nothing) for features that you don't use, but that does not apply equally to the more advanced standard library classes. It's the same in C, of course - call just one little time conversion function and you can find half your flash is used for locale handling and time zones. The needs of embedded systems vary enormously - for many, the cost in code space or run-time efficiency for using a std::list or std::vector is negligible. But for others, it is very far from negligible. (It is relatively rare that you have to worry about /every/ byte of code or data space, however - though it does happen.)
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-15 12:45 +0100 |
| Message-ID | <20221015124549.000031e1@reddwarf.jmc.corp> |
| In reply to | #86979 |
On Sat, 15 Oct 2022 13:39:24 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 14/10/2022 22:01, Mr Flibble wrote: > > On Fri, 14 Oct 2022 14:58:54 -0000 (UTC) > > Muttley@dastardlyhq.com wrote: > > > >> On Fri, 14 Oct 2022 14:47:46 +0100 > >> Mr Flibble <flibble@reddwarf.jmc.corp> wrote: > >>> On Fri, 14 Oct 2022 15:27:13 +0200 > >>> David Brown <david.brown@hesbynett.no> wrote: > >>>> Yes, it is always /possible/. But the complications and effort > >>>> involved is unlikely to be worth the effort, and you'd still end > >>>> up with something taking a massive amount of code space. (With > >>>> "massive" being relative to the small code memories of such > >>>> systems.) > >>>> > >>>> It's not uncommon in my coding to build up a few lists at the > >>>> startup of the system - lists of "run" functions or software > >>>> timers, etc. Modules might register such callbacks or functions > >>>> when initialised. In "big system" C++, you might just use a > >>>> vector for that - adding your timer objects to your vector as > >>>> needed. It's simple and easy in the code. > >>>> > >>>> But in a resource-constraint embedded system, where efficiency of > >>>> code space, ram space and run-time is important (though run-time > >>>> efficiency is usually less important for startup code), that's > >>>> not what you would do. You make your timer class have the > >>>> required list link pointers in the class, have each registering > >>>> function declare their timer object with static lifetime, and > >>>> your registration function links them together. > >>>> > >>>> There's no doubt that this takes a bit more effort to write than > >>>> an off-the-shelf std::vector. But it is vastly simpler than > >>>> faffing around making your own allocator, avoids the use of any > >>>> kind of dynamic memory (using neither the standard heap nor a > >>>> home-made allocation system), and pulls in a tiny fraction of the > >>>> amount of library code. > >>>> > >>>> std::array<> is free - it's just a nice wrapper around a plain > >>>> C-style array. > >>> > >>> List link pointers? Again there is no reason to not use std::list > >>> with a suitable allocator even on such resource constrained > >>> hardware and I disagree that the resultant text size and ram > >>> usage would be any worse than anything you could come up with by > >>> hand. > >> > >> If the memory layout is hard coded at boot time why even bother > >> pulling in std::list or any kind of container as you don't need > >> their generic functionality which will almost certainly waste > >> EEPROM space. With embedded development you often literally have > >> to worry about every byte you use both in ROM and RAM and whether > >> the mainloop is going to be fast enough to do its job. > > > > In C++ you don't pay for what you don't use: in the case of a C++ > > class template only the member functions instantiated will exist in > > the text segment. > > > > There are always /lots/ of other functions that get pulled in from > libraries. Remember, for small embedded systems the libraries are > not shared dynamic libraries that you don't see. > > Just for a quick test, I made a minimal C++ main() function and > compiled for a modern microcontroller. With an empty main(), it was > about 8400 bytes code of common library code. Adding a > "std::list<int>" object and using a couple of pops and pushes adds > about 7 KB code to the program. > > If you are making a lot of use of the standard containers, that's > fine - and there's a lot of overlap and sharing in this extra code. > But in small systems, this kind of stuff can get significant - > microcontrollers with 32 KB flash are common, and it's nice to be > able to program them in C++. In the C++ /language/, you pay very > little (not quite nothing) for features that you don't use, but that > does not apply equally to the more advanced standard library classes. > > It's the same in C, of course - call just one little time conversion > function and you can find half your flash is used for locale handling > and time zones. > > The needs of embedded systems vary enormously - for many, the cost in > code space or run-time efficiency for using a std::list or > std::vector is negligible. But for others, it is very far from > negligible. > > (It is relatively rare that you have to worry about /every/ byte of > code or data space, however - though it does happen.) Try using std::list with a custom allocator as I originally suggested; also your quote of 7KB sounds highly dubious and anecdotal. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-10-15 15:18 +0000 |
| Message-ID | <tiej03$1h62$1@gioia.aioe.org> |
| In reply to | #86981 |
On Sat, 15 Oct 2022 12:45:49 +0100 Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >On Sat, 15 Oct 2022 13:39:24 +0200 >David Brown <david.brown@hesbynett.no> wrote: >> It's the same in C, of course - call just one little time conversion >> function and you can find half your flash is used for locale handling >> and time zones. >> >> The needs of embedded systems vary enormously - for many, the cost in >> code space or run-time efficiency for using a std::list or >> std::vector is negligible. But for others, it is very far from >> negligible. >> >> (It is relatively rare that you have to worry about /every/ byte of >> code or data space, however - though it does happen.) > >Try using std::list with a custom allocator as I originally suggested; >also your quote of 7KB sounds highly dubious and anecdotal. You really Don't Get It do you? Stick to application programming.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-15 16:24 +0100 |
| Message-ID | <20221015162408.000071b2@reddwarf.jmc.corp> |
| In reply to | #86983 |
On Sat, 15 Oct 2022 15:18:27 -0000 (UTC) Muttley@dastardlyhq.com wrote: > On Sat, 15 Oct 2022 12:45:49 +0100 > Mr Flibble <flibble@reddwarf.jmc.corp> wrote: > >On Sat, 15 Oct 2022 13:39:24 +0200 > >David Brown <david.brown@hesbynett.no> wrote: > >> It's the same in C, of course - call just one little time > >> conversion function and you can find half your flash is used for > >> locale handling and time zones. > >> > >> The needs of embedded systems vary enormously - for many, the cost > >> in code space or run-time efficiency for using a std::list or > >> std::vector is negligible. But for others, it is very far from > >> negligible. > >> > >> (It is relatively rare that you have to worry about /every/ byte of > >> code or data space, however - though it does happen.) > > > >Try using std::list with a custom allocator as I originally > >suggested; also your quote of 7KB sounds highly dubious and > >anecdotal. > > You really Don't Get It do you? Stick to application programming. Of course I get it, the question is do you? The only way I can see using a few methods from std::list taking 7KB of space is the overhead of exception handling; perhaps Mr Brown should try it again but with exceptions disabled and a custom allocator that allocates from an explicit memory pool. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-10-15 15:34 +0000 |
| Message-ID | <tiejtb$1uoa$1@gioia.aioe.org> |
| In reply to | #86984 |
On Sat, 15 Oct 2022 16:24:08 +0100 Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >On Sat, 15 Oct 2022 15:18:27 -0000 (UTC) >Muttley@dastardlyhq.com wrote: > >> On Sat, 15 Oct 2022 12:45:49 +0100 >> Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >> >On Sat, 15 Oct 2022 13:39:24 +0200 >> >David Brown <david.brown@hesbynett.no> wrote: >> >> It's the same in C, of course - call just one little time >> >> conversion function and you can find half your flash is used for >> >> locale handling and time zones. >> >> >> >> The needs of embedded systems vary enormously - for many, the cost >> >> in code space or run-time efficiency for using a std::list or >> >> std::vector is negligible. But for others, it is very far from >> >> negligible. >> >> >> >> (It is relatively rare that you have to worry about /every/ byte of >> >> code or data space, however - though it does happen.) >> > >> >Try using std::list with a custom allocator as I originally >> >suggested; also your quote of 7KB sounds highly dubious and >> >anecdotal. >> >> You really Don't Get It do you? Stick to application programming. > >Of course I get it, the question is do you? The only way I can see >using a few methods from std::list taking 7KB of space is the overhead >of exception handling; perhaps Mr Brown should try it again but with >exceptions disabled and a custom allocator that allocates from an >explicit memory pool. I've tried to explain it to you, so has he. You've obviously never done embedded dev, yet as usual you seem to assume you're an expert on the matter. Believe what you like. Something to bear in mind is not all compilers and linkers build in the same way as VC or gcc.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-15 16:39 +0100 |
| Message-ID | <20221015163905.00004d9c@reddwarf.jmc.corp> |
| In reply to | #86985 |
On Sat, 15 Oct 2022 15:34:03 -0000 (UTC) Muttley@dastardlyhq.com wrote: > On Sat, 15 Oct 2022 16:24:08 +0100 > Mr Flibble <flibble@reddwarf.jmc.corp> wrote: > >On Sat, 15 Oct 2022 15:18:27 -0000 (UTC) > >Muttley@dastardlyhq.com wrote: > > > >> On Sat, 15 Oct 2022 12:45:49 +0100 > >> Mr Flibble <flibble@reddwarf.jmc.corp> wrote: > >> >On Sat, 15 Oct 2022 13:39:24 +0200 > >> >David Brown <david.brown@hesbynett.no> wrote: > >> >> It's the same in C, of course - call just one little time > >> >> conversion function and you can find half your flash is used for > >> >> locale handling and time zones. > >> >> > >> >> The needs of embedded systems vary enormously - for many, the > >> >> cost in code space or run-time efficiency for using a std::list > >> >> or std::vector is negligible. But for others, it is very far > >> >> from negligible. > >> >> > >> >> (It is relatively rare that you have to worry about /every/ > >> >> byte of code or data space, however - though it does happen.) > >> >> > >> > > >> >Try using std::list with a custom allocator as I originally > >> >suggested; also your quote of 7KB sounds highly dubious and > >> >anecdotal. > >> > >> You really Don't Get It do you? Stick to application programming. > > > >Of course I get it, the question is do you? The only way I can see > >using a few methods from std::list taking 7KB of space is the > >overhead of exception handling; perhaps Mr Brown should try it again > >but with exceptions disabled and a custom allocator that allocates > >from an explicit memory pool. > > I've tried to explain it to you, so has he. You've obviously never > done embedded dev, yet as usual you seem to assume you're an expert > on the matter. Believe what you like. Something to bear in mind is > not all compilers and linkers build in the same way as VC or gcc. I have done embedded dev and I am well aware of its constraints; all you have got are words completely devoid of any calories. /Flibble
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web