producing the memory layout you really want is non-portable anddeprecated

[aarklon]

Hi,

I used to argue at this point that using memory-mapped IO made it
easier to write device drivers in C, since you could map devices to C
structures. Unfortunately, modern C compilers pad structures for
performance reasons, and trying to coerce the compiler into producing
the memory layout you really want is non-portable and deprecated. So
I'm leaving the argument in place, but it's really for historical
interest at this point. The comments about trying to create in and out
instructions do remain valid, however.

Also, when writing device drivers in C, it's a lot easier to work
with when devices are in memory space. Let's suppose you have a simple
device (for concreteness, let's look at the A/D convertor on an HC11.
It's controlled by five registers (not counting the OPTION register),
located at addresses $1030-$1034. We can define a struct that looks
like this:

see:- http://www.cs.nmsu.edu/~pfeiffer/classes/473/notes/io.html

 

[Richard]

Hi,

I used to argue at this point that using memory-mapped IO made it
easier to write device drivers in C, since you could map devices to C
structures. Unfortunately, modern C compilers pad structures for
performance reasons, and trying to coerce the compiler into producing
the memory layout you really want is non-portable and deprecated. So
I'm leaving the argument in place, but it's really for historical
interest at this point. The comments about trying to create in and out
instructions do remain valid, however.

Also, when writing device drivers in C, it's a lot easier to work
with when devices are in memory space. Let's suppose you have a simple
device (for concreteness, let's look at the A/D convertor on an HC11.
It's controlled by five registers (not counting the OPTION register),
located at addresses $1030-$1034. We can define a struct that looks
like this:

see:- http://www.cs.nmsu.edu/~pfeiffer/classes/473/notes/io.html

Which begs the question : since people have known for a long time that C
was going to be used primarily for embedded systems in the future, why
oh why is the support for non padded structures so bad? Sure some
compilers have a pragma to remove padding but thats not "standard".

The FAQ says this:

http://c-faq.com/struct/padding.html

I would be interested in seeing a general approach to this

,----
| If you're worried about wasted space, you can minimize the effects of padding by ordering the members of a structure based on their base types, from largest to smallest.
`----

that is "standards compliant" and not "hard coded".

 

[Ian Collins]

Which begs the question : since people have known for a long time that C
was going to be used primarily for embedded systems in the future, why
oh why is the support for non padded structures so bad? Sure some
compilers have a pragma to remove padding but thats not "standard".

Every embedded compiler (ant that's quite a lot!) I've used supported
packed structures. I certainly would think many times about using one
that didn't.

 

[Richard]

Every embedded compiler (ant that's quite a lot!) I've used supported
packed structures. I certainly would think many times about using one
that didn't.

Is the pragma line itself "standard"?

 

[Ian Collins]

Is the pragma line itself "standard"?

Don't be silly, how can you standardise something a lot of machines
can't do?

 

[Richard]

Don't be silly, how can you standardise something a lot of machines
can't do?

It could stop the compilation? Hence standard code base.

 

[Philip Potter]

Don't be silly, how can you standardise something a lot of machines
can't do?

The same way you standardise IEEE floating point - that is, make it an
optional part of the standard.

Philip