Steve Hosgood wrote:
Grant Edwards wrote:
Sorry if I sounded a bit shrill, but you're suggesting a
compiler which refuses to compile 100% legal standard ANSI C
source code. I just don't see how that's a real option.
That's more like it!
Sorry, Steve Underwood, but Grant's right. That's not to belittle the
efforts of you and Dmitry over the years getting all this stuff working,
it's a great toolset. It just gets bugs sometimes.
I've been a compiler maintainer (on a home-grown Tiny-C about 20 years
ago). I know what it's like. No-one congratulates you for the great code
the compiler generates 99.9% of the time, they just winge about the 0.1%
stuff!
But as I said, Grant's right. The compiler *must* generate runnable code
(if it is to generate anything). It doesn't have to be *good* code, but
it must run.
Normally, the compiler should avoid alignment issues by padding structs
and things so that they can't get misaligned, but if the user uses
#pragmas or other constructs to force unaligned data then probably the
best thing is to generate whatever crap code that it needs(*), and
generate a warning that the alignment problem is causing a problem.
That would sort it for everyone, surely?
Steve.
Well, since you were not involved in the pathetic name calling, I'll
respond to you.
Obviously, the compiler should deal with things like memcpy and memset
correctly. These things are defined to work at the byte level, so they
must. If you look back a few messages I actually said it needed fixing,
but the question was how. Should the smallest possible, or fastest
routine be used? Should we do in-lining, or call a function? These are
valid questions, yet resulted in abuse.
What should happen with other stuff that is unaligned is less clear. I
was hoping for some discussion on that, but fights seem more popular
this week.
In my experience, compilers typically do what mspgcc currently does now.
If you try to access an unaligned integer in a structure on a processor
which doesn't like it, they don't warn you, but the code crashes. That's
what the Alpha and MIPs compilers I have used did. Later versions of
Alpha allowed misalignment with a speed penalty, like the x86. I'm not
sure if MIPs ever changed. Now, the question is, what do people really
expect on a thing like the MSP430.
If you try something like
struct
{
int x;
char y;
} xxx[10];
and loop through the array accessing x, all is well. If you pack the
structure it fails with mspgcc. The only real difference in the
generated code is the loop steps 3 bytes at a time instead of 4. Now, if
you try this with the IAR compiler for the MSP430, things still work
with the packed structure. However, to achieve that complex code is
produced when the structure is packed, and simple code is produced when
it is not. Is this something people would like to see in mspgcc?
Personally I wouldn't. Any significant amount of that kind of things
would generate so much code it would be impractical. I was, however,
naively hoping for some meaningful discussion.
Regards,
Steve
