A quick c programming survey question - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: A quick c programming survey question
Quoted text here. Click to load it


I don't know if (b) refers to what i do when there is no software
process cop lurking around...

volatile unsigned char *this_address = 0x0F00
...
*this_address = 0x23;

So many times i dont even do (a) nor (b)

Re: A quick c programming survey question

Quoted text here. Click to load it

This is not 'generic' enough.  It works for initialisation of the
whole register.  It is useless for changing an individual bit.

Quoted text here. Click to load it

Um?

tim







Re: A quick c programming survey question
Quoted text here. Click to load it

b.

--
Dan Henry

Re: A quick c programming survey question
Quoted text here. Click to load it

Never. For two reasons:

1) Bit field "direction" is nondeterministic on non byte size operators and
often is a source of problems when porting from one CPU type to another

2) This approach won't work for registers that have different write behavior
than read behavior. This generates read/modify/write code when tweaking a
single bit or set of bits.

It'll probably be OK if you don't

Quoted text here. Click to load it

B)

-->Neil



Re: A quick c programming survey question

Quoted text here. Click to load it
and
behavior

see my reply to mike

tim

Quoted text here. Click to load it



Re: A quick c programming survey question
On Sat, 15 May 2004 11:03:01 -0700, "Neil Bradley"


Quoted text here. Click to load it

In situations when you have to deal with "write only" hardware
registers, it would be a good idea to use both methods :-).

You have to use a separate memory location to store the value most
recently written to the hardware register. To change the register, the
appropriate bit in the memory location has to be changed first and the
whole byte/word/longword is written with a single MOVE byte/word/long
instruction into the hardware register.

In this situation, the memory location could be a bit field structure,
which can then be written into the hardware register as a single
byte/word/long.

Although different compilers arrange the bit fields differently into
the byte or if you have to switch from big endian to little endian
processors using the same 16 or 32 bit peripheral register, you only
have to rearrange the fields in the struct definition. Bit fields
larger than 1 bit which are contained within the same byte, can also
be handled nicely with bit fields in big/little endian situations.

If the compiler is not capable of generating the correct size of the
structure (say 8, 16 or 32 bit) as required for the hardware access,
use a union parallel with the structure.

While this is quite readable on its own, two assignments are required,
one to change the memory bit field and an other to transfer the entire
structure value to the hardware register.

Of course, you can hide this into an access macro. This access macro
would be identical on all hardware platforms and only the struct
definition (in a header file) needs to be changed.

If method B) is solely used, you may have to change a lot of access
macro changes if the peripheral hardware register requires 16 bit
access and you are changing between big/little endian processors.

Paul
    

Re: A quick c programming survey question

Quoted text here. Click to load it


Having had the misfortune of doing the task I can assure you that
this change is a bitch without the macros.

Quoted text here. Click to load it



Re: A quick c programming survey question
Quoted text here. Click to load it

From "The Practice of Programming" by Kernighan and Pike, p183:
Quoted text here. Click to load it
generate voluminous and inefficient code."

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com



Re: A quick c programming survey question

Quoted text here. Click to load it

So why did they provide them then?
Or
Why did they not remove them (or define them properly)
when the stardards were updated.

I know this by the way,  it's why I created this survey.

Tim


Quoted text here. Click to load it



Re: A quick c programming survey question
Quoted text here. Click to load it


C was designed primarily as a systems programming language, I believe.
It was also implemented at a time that memory was much more scarce, so
that it was important to be able to use single bits for storing boolean
variables.  The C bitfields are a reasonable syntax for doing this.  

As far as portability, bitfields per se are not, in my opinion, "highly
non-portable".  You simply need to know the limitations that are given
by the standard: no specification of ordering of bit fields within a
word, no specification of the size of the word, no specification of
whether a bitfield can overlap words, no specification for the minimum
size of the word in which bitfields are stored, no specification of
whether a "plain int" bitfield (not explicitly signed or unsigned) is
signed or unsigned.  As long as you use each bitfield separately, you
shouldn't have much problem.

I think that bitfields are a benefit to the language.  Also, for
target-dependent code, you can take advantage of the
implementation-defined aspects of bitfields.

Quoted text here. Click to load it

Bitfields are used in a lot of applications, I think, and rewriting them
to remove bitfields would be a lot of work with very little profit.

Thad

Re: A quick c programming survey question

Quoted text here. Click to load it
to


I must disagree.  The syntax is horrid.

Quoted text here. Click to load it

But they could have been implemented better.

Quoted text here. Click to load it

Standard changes take a long time to implement.
Some fundamental items have been changed before and there
just has to be a sensible process for doing it.  It is not an
in-soluable problem to discourage the use of 'bits' in the
future whilst continuing to compile legacy code.  Having said
that, defining them better would be my choice.

tim


Quoted text here. Click to load it



Re: A quick c programming survey question
Quoted text here. Click to load it


I guess that is in the eye of the beholder.  While I'm not asserting
that it is the best possible way, I don't find it repugnant, either.
Feel free to not use bitfields.  You can even choose another language or
design and implement your own if you feel that strongly about it.

Years ago I used a Pascal compiler which implemented packed records to
achieve the same thing as bitfields.  The fields were specified as a
range of values, rather than the number of bits.  The compiler allocated
the minimum number of bits needed for the range, including whether to
allocate a sign bit.  I used them successfully for memory-mapped I/O
registers.  Better?  Not significantly.

Quoted text here. Click to load it

Do you mean the language could have been designed better, or implemented
better in a particular compiler?  As far as the latter, yes, I have seen
poorly implemented bitfield code generation.  That's the fault of the
compiler implementor, not the language.  As far as the language design,
possibly, but almost anything can be improved in hindsight.  At this
point, it's moot for C syntax.

Quoted text here. Click to load it

You can now stop using bitfields in your own code without any outside
mandate.  If you want to force others to do without, you might have an
uphill fight.  ;-)  The best course for an existing language, I think,
is to impose your own coding standards while maintaining most of the
language features for compatibility.

Thad

Re: A quick c programming survey question

Quoted text here. Click to load it

I don't get the choice.  As I freelancer I often turn up
on a project after someone has already 'designed' this
solution.  Getting it changed is impossible. (it's hard enough
stopping some people declaring everything global -  sorry
current gripe)

Quoted text here. Click to load it

yes.


As I've already said, I seen some pretty nifty code generation.

Quoted text here. Click to load it

I still subscribe to the 'conformity' rule, unless it doesn't
actually work.

Quoted text here. Click to load it

Where the he benefits are over-whelming, it's easy.  It is however
very hard to counter the "it's already done" answer.

Quoted text here. Click to load it

Agreed.  If only there were an automated way of enforcing,
for example: "no use of the comma operator (except in for
control loops)"

tim


Quoted text here. Click to load it



Re: A quick c programming survey question
Quoted text here. Click to load it
PCLint (http://www.gimpel.com ) can do this.

If I add a comma operator to my current project code, I get the
following warning:

xxxxx.c  120  Note 960: Violates MISRA Required Rule 42,
    comma operator used outside of 'for' expression


Andy

Re: A quick c programming survey question

Quoted text here. Click to load it

But Misra takes rules just a bit too far (and then some more)

tim


Quoted text here. Click to load it



Re: A quick c programming survey question
Quoted text here. Click to load it
Indeed.

But I was pointing out that PCLint can be tailored to complain about
almost anything you don't like.
The warning about using commas outside of a 'for' statement is an
optional warning that can be individually switched on.

It is an excellent tool for enforcing a coding standard.

Andy

Re: A quick c programming survey question
On Mon, 17 May 2004 19:05:13 +0200, "tim"

Quoted text here. Click to load it

Are you referring to the declaration syntax or how to use it ?

What is the problem with syntax like

if (uart->TxEmpty) ......

The declaration only occurs once, but there are usually a lot of cases
when the fields are referenced.

It is unrealistic to assume that you could write a program and
everything you would have to do is to transfer it to _any_ other
system and compile it. Someone is always going to make a bizarre
hardware architecture, which would break your idealistic ideas. Thus
it is a better idea to isolate the potentially unportable parts into
the data declarations (and possibly even into separate access
routines).

My guess that one reason for not allowing any bit number definitions
in the bit field declarations, is that various architectures quite
different numbering systems are used. For 16 bit architectures, you
might find (for MSB .. LSB) at least 15..0,  16..1, 0..15 and 1..16.
In addition in formats like 0..xx or 1..xx, the bit number of LSB is
different depending on if we are talking about bytes, words or long
words.  

Since you would have to use the absolute number at least in the
declaration part, what would uart.5 refer to (or uart[5]) if the
native bit numbering was some of the more bizarre kind as above.

Paul


Re: A quick c programming survey question
Quoted text here. Click to load it

C was used for many years before the first standard was created.
Different implementors made different choices about how to
implement bit fields.  Since the purpose of the C standard was 'to
codify existing practice' it could not specify bit orders without
breaking existing code, and therefore it didn't.

The standard for bitfields is non-portable because the C-code for
bitfields is non-portable because the standard for bitfields is
non-portable because ....

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: A quick c programming survey question

Quoted text here. Click to load it

Access to particular registers or hardware is non-portable, and you should
know the size or efficiency of the code your compiler generates for
particular constructs - at least on small micros.  In other words,
bit-fields are not all that much worse than other methods on some
compiler-target combinations, and are therefore worth considering.




Re: A quick c programming survey question
Quoted text here. Click to load it

Not necessarily. For example, a standard UART may be attached
to any number of processors. The driver code for that UART
can be independent of processor/compiler.

Even with today's highly integrated micro-controllers,
"good" vendors frequently use the same peripherals in differnt
mixtures for variants. The difference will often be nothing
more than the base address of the registers.

Quoted text here. Click to load it

When squeezed for space/time, all bets are off. However,
to paraphrase, "first get it right, then optimize it."
Too often I find embedded guys worried about optimizing
that which needs no optimizing.

Quoted text here. Click to load it

Using bit fields in hardware interfaces that need to be portable
across compiler/processor targets, is asking for trouble. Besides,
many hardware registers do not have simple access semantics, and
are therefore not suitable for the read-modify-write operations
generated by compilers for bit-fields. For example, read-only
registers, and write-only registers.


--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline