C embedded programming books?

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-

Reply to
Le Chaud Lapin
Loading thread data ...

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.
Reply to
David Brown

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
Reply to
Grant Edwards

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

formatting link

Reply to
Steve at fivetrees

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-

Reply to
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!!
Reply to
Grant Edwards

[...]

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.
Reply to
Dave Hansen

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
Reply to
CBFalconer

Thanks a lot!

Reply to
Je-Rock

The compiler is allowed to order the bits however it likes (i.e. big endian or little endian).

--

John Devereux
Reply to
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?
Reply to
Grant Edwards

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

Reply to
BobG

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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply to
Chris Hills

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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply to
Chris Hills

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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply to
Chris Hills

Je-Rock escribió:

I always recommend:

formatting link

For embedded and not-embedded programming.

Reply to
Ignacio G.T.

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.