I suspected that this is the reason. Certainly you will agree that this is hardly an issue if you're already comitted to the idea that you are doing hardware-based I/O?
-Le Chaud Lapin-
I suspected that this is the reason. Certainly you will agree that this is hardly an issue if you're already comitted to the idea that you are doing hardware-based I/O?
-Le Chaud Lapin-
ImageCraft's website says their compilers support C89, not C99, although they support parts of later standards.
gcc supports most of C99, along with their own extensions, but are not fully compliant.
I always find it amazing that so few compilers support C99 seven years after it was made (although I gather there were some amendments made in
2000 or 2001?). Either the compiler (and library) writers are doing a poor job, or the standards people came up with something that either people don't want, or that the compiler writers can't easily give them, and have thus done a poor job.
Or the customers are doing a poor job demanding C99 compliance.
-- Grant Edwards grante Yow! Now I understand the at meaning of "THE MOD SQUAD"! visi.com
Unless I'm misunderstanding you, I/O is *precisely* where masks rather than bitfields should be used.
Only use bitfields where bit placement doesn't matter. Where it matters, use masks.
Steve
I cannot recall any situation where I could not control the layout of a structure using bit-fields to accommodate hardware registers.
What am I missing?
-Le Chaud Lapin-
I've never had problems controlling bit-placement (though the mechanisms to do so are trivially non-portable). The problems I've had is with controlling the width of read/write operations the compiler uses to access the bitfields. Using bitfields, the compiler is free to choose any width it likes for read/write operations. Many registers require accesses be of certain widths.
-- Grant Edwards grante Yow! I want to so HAPPY, at the VEINS in my neck STAND visi.com OUT!!
[...]
You can probably get it to work in most cases, though there's no guarantee that it must work. It won't necessarily be portable to other compilers or platforms (the latter only an issue for external hardware and/or communications), but it can be made to work.
Later, a compiler upgrade can bite you. A colleague at a PPOE relied on bit fields to drive seven-segment displays among other things. Between versions 3 and 4, the compiler vendor changed the way they packed bit fields, and totally fupped that duck. Kind of a maintenance headache.
OTOH, "var |= 0x01" will work on every C compiler worth the power to run it. It will always do exactly the same thing through compiler upgrades and bug fixes (and vendor changes and platform changes). No apologies necessary. It just works.
And it likely generates the same (or better) code anyway. Sometimes, syntactic sugar just rots your teeth.
Regards, -=Dave
-- Change is inevitable, progress is not.
It can bite you even if you don't change the hardware. A revision of the compiler you are using can result in entirely different patterns.
-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: Also see
Thanks a lot!
The compiler is allowed to order the bits however it likes (i.e. big endian or little endian).
-- John Devereux
That's true, but it's moot in the real world. Every compiler I've ever used for embedded work in the past 20 years let the user control the ordering of bitfields.
It's the width of read/write operations that actually causes problems.
-- Grant Edwards grante Yow! Who wants some at OYSTERS with SEN-SEN an' visi.com COOL WHIP?
DB: ImageCraft's website says their compilers support C89, not C99, although they support parts of later standards. ================================= But in my defense, and Richard's, a recent email to his mail list asks his early adopters to dl his V7 beta with C99 preprocessor. I assume that it will propagate to his whole line. When Chris Hills says 'compiler' does he mean a target cpu, a platform, or a whole line of compilers offered by a company??
According to many on the ISO panels the standard has drifted away from where it should be. To many things were added that the majority did not want or need.
There are C99 front ends so it can be done....
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article , BobG writes
Perennial only listed 4 last time I looked as being C99 compliant Dinkumware, Ltd. Edison Design Group IBM Corporation Lund Multiprocessor Compiler Co, AB Sun Microsystems
"GCC has many C99 things" lots of compilers have "many C99 things" I doubt many would pass a full compliance check by a long way. I do know that Gcc has dropped several C99 things from their "to do" list with out actually implementing them.
Many compilers claim "ANSI C" which means bugger all these days as no one is sure which version they are on about.
Incidentally LOTS of compilers use a C99 compliant front end.... having a C99 front end does not mean that they have fully implemented C99 in the compiler.
Apparently Imagecraft claim C89 which is the original ISO C90 not C99.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article , BobG writes
I meant it will take all and any C99 code and compiler/link it to s sensible output.... ok maybe I should not have said sensible :-) I meant a running program.
At the moment Perennial only list a few that pass their tests.
I do know several of the companies using the EDG C99 system which is a fully compliant front end do not fully implement C99 in their compiler suites.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Je-Rock escribió:
I always recommend:
For embedded and not-embedded programming.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.