Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.std.c > #6223 > unrolled thread
| Started by | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| First post | 2021-06-22 16:49 +0200 |
| Last post | 2021-07-06 23:18 +0200 |
| Articles | 2 on this page of 42 — 6 participants |
Back to article view | Back to comp.std.c
bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-22 16:49 +0200
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-22 17:18 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-22 11:17 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 08:25 +0200
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-23 08:59 +0200
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 13:12 +0200
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-23 14:14 +0200
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 17:45 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-23 10:22 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 19:52 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-23 16:12 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-24 10:41 +0200
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-24 10:32 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-23 00:39 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 13:22 +0200
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 18:27 +0200
Re: bit-fields of type unsigned long and unsigned long long Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-23 10:53 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 20:13 +0200
Re: bit-fields of type unsigned long and unsigned long long Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-24 11:48 -0700
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-24 12:23 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-24 22:40 +0200
Re: bit-fields of type unsigned long and unsigned long long Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-10 09:13 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-24 22:14 +0200
Re: bit-fields of type unsigned long and unsigned long long Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-10 09:23 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-24 11:02 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-24 11:06 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-24 23:11 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-24 15:16 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-25 10:43 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-25 02:02 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-25 13:54 +0200
Re: bit-fields of type unsigned long and unsigned long long Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-25 13:07 +0100
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-25 15:17 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-25 08:22 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-25 18:22 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-25 13:28 -0700
Re: bit-fields of type unsigned long and unsigned long long Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-25 19:12 +0100
Re: bit-fields of type unsigned long and unsigned long long Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-10 08:58 -0700
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-25 08:09 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-25 14:43 +0200
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-25 15:33 +0200
Re: bit-fields of type unsigned long and unsigned long long Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2021-07-06 23:18 +0200
Page 3 of 3 — ← Prev page 1 2 [3]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-25 15:33 +0200 |
| Message-ID | <sb4lvu$i73$1@dont-email.me> |
| In reply to | #6253 |
On 25/06/2021 14:43, Philipp Klaus Krause wrote: > Am 25.06.21 um 10:43 schrieb David Brown: > >> >> As I see it, bit-fields are used for two main purposes. >> >> One is for structures internal to a program, in order to reduce space. >> There are two typical reasons for that. You might have a small embedded >> system with extremely small ram size (though these are getting less >> common, and since they are very rarely used with anything newer than >> C99, changes to the standard matter little there). > If newer standards are rarely used for programming small embedded > systems, is it because the standard might have been diverging from their > requirements? > Is it because newer standards take so much effort to implement that > compilers other than GCC and clang lack the manpower to implement them > timely? > Is it because users follow a coding standard, such as MISRA, that takes > a while to update for new C standards? > These are all valid reasons. I couldn't tell you the proportions here, but I suspect you've covered the biggest points. A lot of embedded developers are also very conservative - there is an amazing amount still being written in C90. And there is the question of what the newer C standards have given embedded developers. C11 gave us atomics that don't work for embedded systems, and threads that are useless even if embedded toolchain developers bothered to make some kind of implementation for them. _Generic is more complicated than most people want to see, and has little use in practice. Static assertions are a wonderful idea - that's why programmers in C90 and C99 already have them (using ugly macros rather than a language feature, but they still work). Anonymous structs and unions were already supported as extensions by many toolchains. C17 gives nothing bug bug fixes. Some emebedded programmers, such as myself, will use new standards when they are supported by my tools and give some advantages. But one of the most important points of C as a language is its stability, consistency and backwards compatibility. It doesn't really need changes, except perhaps to clarify some parts, simplify by removing support for long-outdated systems, codify existing common practice, and throw out old, dangerous and obsolete syntax.
[toc] | [prev] | [next] | [standalone]
| From | Jakob Bohm <jb-usenet@wisemo.com.invalid> |
|---|---|
| Date | 2021-07-06 23:18 +0200 |
| Message-ID | <P8CdnRiV8v4RVXn9nZ2dnUU78R3NnZ2d@giganews.com> |
| In reply to | #6253 |
On 2021-06-25 14:43, Philipp Klaus Krause wrote: > Am 25.06.21 um 10:43 schrieb David Brown: > >> >> As I see it, bit-fields are used for two main purposes. >> >> One is for structures internal to a program, in order to reduce space. >> There are two typical reasons for that. You might have a small embedded >> system with extremely small ram size (though these are getting less >> common, and since they are very rarely used with anything newer than >> C99, changes to the standard matter little there). > If newer standards are rarely used for programming small embedded > systems, is it because the standard might have been diverging from their > requirements? > Is it because newer standards take so much effort to implement that > compilers other than GCC and clang lack the manpower to implement them > timely? > Is it because users follow a coding standard, such as MISRA, that takes > a while to update for new C standards? > Besides what Mr. Krause mentioned, a major reason is that many embedded platforms are stuck with whichever actual compiler implementation shipped with the first release of that platform. Any new compilers tend to emulate that historic compiler extremely closely in order to get identical or very closely equivalent binaries from existing source code. And programmers that care tend to read up on which language "enhancements" will make their code incompatible with existing toolchains and smaller/cheaper/older platform versions. This essentially locks each platform family to that historic compiler and its idiosyncrasies. However newly created embedded platforms such as embedded RISC-VI or any new bit-sliced utility processor for FPGA projects would get frozen to whatever the commonly implemented language will be when that platform is created. This makes it worthwhile to discuss future improvements to the language for deeply embedded systems. A language aspect that will be useful even for existing platforms is a standard, easily backported, way to tell reusable code which language implementation alternatives are in effect when compiling the portable code with any old toolchain. Basically a supplement to <limits.h> that covers all the stuff currently only left to "read the implementation defined features document hopefully provided by your vendor" . Something that will allow a strictly conformant program or translation unit to actively use whichever syntax that historic compiler uses for things like "place this bit field at the most significant bit of the second byte" or "allow +1 to set this bit field to 1" or what bit encoding is used for signed ints (2s complement, 1s complement, sign+magnitude, etc.) Every implementation-defined language aspect needs a standard define indicating which alternative was chosen, with values for each common or historic choice, and a (common) rule for how to add yet-to-be-invented choices in a forward compatible manner. But turning it into a formal workable proposal is a major exercise. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.std.c
csiph-web