Recommendations for ARM compilers

On 20 Jun 2005 02:56:30 -0700, napi@axiomsol.com wrote in
comp.sys.arm:

> You may want to try AMPC at http://www.axiomsol.com
> It's a C to Java Bytecode compiler
> that runs on JVM enabled devices (including ARM based systems).
> 
> Napi

That's a very interesting idea, although completely impossible for my
situation for several reasons.  The first is that the application runs
on our own real time kernel, and the effort to bring up a JVM is not
practical.  Then there's the fact that we peak at about 90% CPU usage
with code written in compiled C with some assembly language in the
ISRs and kernel, so we'd never meet our timing requirements with Java
bytecode.

But I do appreciate your suggestion.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

"tum_" <atoumantsev_spam@mail.ru> wrote in message
news:1119268463.760252.299800@f14g2000cwb.googlegroups.com...
> >surely taking the address of a _packed member should yield a _packed
> >pointer. passing that to a function requiring a non-packed pointer should
> >surely report a warning at least.
>
> There was no warning. And it's a good question to compiler writers
> whether it should have been there. AFAIK, this '_packed' thing
> is not properly standardized.

Actually it is an error to implicitly cast a packed qualified pointer to a
non-packed pointer. It would be a bug if it allowed you to pass a
packed pointer as if it weren't. Packed behaves a lot like a type
qualifier that sets the natural alignment to 1, so it is quite well specified.
No chance of it getting accepted as in the next C standard of course.

Wilco

In comp.arch.embedded Peter Dickerson <first{dot}surname@ukonline.co.uk> wrote:

> surely taking the address of a _packed member should yield a _packed
> pointer. 

Actually, surely on an architecture that has the concept of bus error
for unaligned accesses, like yours, packing of struct members that
moves elements to "illegal" addresses should plain and simply never
have been allowed in the first place.

I would say that using such a feature, you're firmly in "whatever
silly result you get is exactly what you asked for" territory.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Wilco Dijkstra wrote:
> Actually it is an error to implicitly cast a packed qualified pointer to a
> non-packed pointer.

Mmm, I have to admit I don't know how such a cast can be done.

> It would be a bug if it allowed you to pass a
> packed pointer as if it weren't. Packed behaves a lot like a type

That's exactly what happened.
Let's talk (pseudo)C:

typedef __packed struct
{
	uint8_t a[n];
	uint16_t field1;
	uint16_t field2;
	uint16_t field3;
} the_struct;

void update_field( uint16_t * );
...

the_struct THESTRUCT;

...

   // This line does not generate any error/warning
   update_field( &THESTRUCT.field1 );

druck wrote:
> On 20 Jun 2005 "tum_" <atoumantsev_spam@mail.ru> wrote:
>
> Please can you ensure you don't remove the attribution lines ("xxx wrote:"),
> as it makes the posts difficult to follow.
>
> ---druck
>
> --
> The ARM Club Free Software - http://www.armclub.org.uk/free/
> The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

Sorry, I didn't remove them, I just quoted manually.
Had to read Help to learn how to do this properly with Google Groups.

tum_ wrote:
> druck wrote:
>> "tum_" <atoumantsev_spam@mail.ru> wrote:
>>
>> Please can you ensure you don't remove the attribution lines
>> ("xxx wrote:"), as it makes the posts difficult to follow.
> 
> Sorry, I didn't remove them, I just quoted manually.  Had to
> read Help to learn how to do this properly with Google Groups.

The google groups interface to usenet is seriously broken.  However
you can do fairly well if you follow the instructions in my sig.
below.

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

In article <1119602722.982744.72910@g14g2000cwa.googlegroups.com>, 
atoumantsev_spam@mail.ru says...
> 
> Wilco Dijkstra wrote:
> > Actually it is an error to implicitly cast a packed qualified pointer to a
> > non-packed pointer.
> 
> Mmm, I have to admit I don't know how such a cast can be done.
> 
> > It would be a bug if it allowed you to pass a
> > packed pointer as if it weren't. Packed behaves a lot like a type
> 
> That's exactly what happened.
> Let's talk (pseudo)C:
> 
> typedef __packed struct
> {
> 	uint8_t a[n];
> 	uint16_t field1;
> 	uint16_t field2;
> 	uint16_t field3;
> } the_struct;
> 
> void update_field( uint16_t * );
> ...
> 
> the_struct THESTRUCT;
> 
> ...
> 
>    // This line does not generate any error/warning
>    update_field( &THESTRUCT.field1 );

So you are using a non-portable, non-standard and dangerous construct and 
the compiler doesn't warn of alignment issues when you do something with 
it that violates the processors alignment restrictions.

Why do you feel the need to use packed in the first place?  Every time 
I've looked at it, it appeared to be far more trouble than it was worth.  
Most of the adavantages of it appear to be illusory to me.

Robert

R Adsett wrote:
> In article <1119602722.982744.72910@g14g2000cwa.googlegroups.com>,
> atoumantsev_spam@mail.ru says...
> >
> So you are using a non-portable, non-standard and dangerous construct and

well, it's not my code. But it's a real life code, part of
the large software project that has been ported from an 8-bit
platform to ARM (and then from ADS 1.2 to GCC).

> the compiler doesn't warn of alignment issues when you do something with
> it that violates the processors alignment restrictions.

That's what I'm actually interested in: should there be a warning
for such a construct?

> Why do you feel the need to use packed in the first place?  Every time
> I've looked at it, it appeared to be far more trouble than it was worth.
> Most of the adavantages of it appear to be illusory to me.

I don't feel the need for it at all in this particular example.
What seems to have happened is: in the process of porting
from 8-bit to 32-bit, it became clear that certain structures
has to be __packed (for whatever reason) to make the code work
correctly,
it was also considered worthwhile to apply __packed to all the
structures
in the project to save memory. Luckily, it was the only bug introduced
this way.

[and my apologies to the OP: my remark has led the discussion away from
the original goal (as it always happens in a newsgroup)]

On 25 Jun 2005 "tum_" <atoumantsev_spam@mail.ru> wrote:
> What seems to have happened is: in the process of porting from 8-bit to
> 32-bit, it became clear that certain structures has to be __packed (for
> whatever reason) to make the code work correctly, it was also considered
> worthwhile to apply __packed to all the structures in the project to save
> memory. Luckily, it was the only bug introduced this way.

A very bad idea if the structure already has aligned fields or the space
saving is very small. Most compilers will generate 4 byte accesses for a
32bit word in a packed structure, and performance will be abysmal.

---druck

-- 
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

In comp.arch.embedded tum_ <atoumantsev_spam@mail.ru> wrote:

> > the compiler doesn't warn of alignment issues when you do
> > something with it that violates the processors alignment
> > restrictions.

> That's what I'm actually interested in: should there be a warning
> for such a construct?

There should not be one, there should be at least four:

1) the moment it saw "__packed", the compiler should have output a
"Danger Will Robinson!  Needless loss of portability encountered!"
warning.

2) The moment it saw that the effect of __packed was to place any
structure field into a position inaccessible by an ordinary pointer,
it should have either refused to do that, or output another warning
"Potential loss of usability."

3) If it allowed misaligned elements, it should have refused to let
you take the address of such a thing, or printed yet another warning
"Unusable pointer value computed."

4) Even it did let you pass all the way through here, it should have
refused to let you assign this pointer as if it was a correct pointer
to an object, or output an other warning "Use of misaligned pointers
is almost guaranteed to fail."

One alternative that would allow to not issue warnings 2 to 4 would be
to make all C pointers inherently capable of addressing even
misaligned values, either by installing a CPU exception handler for
misaligned access that fixes it up, or by introducing an abstraction
layer between pointer values and actual addresses that checks every
pointer usage for possible misalignment. Both of these tend to be
performance desasters, so you don't really want to go down that road.

So the code in question does one questionable, one foolish, and one
completely crazy thing, in that order.  Sometime between the
questionable and the foolish, the compiler made a decision that
exposes the last in the code's list of sins as the crazy thing it is,
and you say you want to be warned only when it's reached the "crazy"
stage.  That's a strange view of the world you have there.

I say the compiler should have bluntly refused to cooperate at the
foolish step of taking the address of a packed structure element, and
given you a stern warning about the effects of its own decision
combined with the questionable use of __packed before that.  Or it
should have simply not packed that densely.  But then your ulterior
motive for using the __packed hack would have failed to work out,
wouldn't it?

> I don't feel the need for it at all in this particular example.
> What seems to have happened is: in the process of porting from 8-bit
> to 32-bit, it became clear that certain structures has to be
> __packed (for whatever reason) to make the code work correctly,

Actually, from what you say, the only thing that became clear at that
point was that the 8-bit code was not particularly portable to begin
with, and that the people who ported it to ARM had no idea how to
*properly* fix that problem once and for good.  __packed is hardly
ever the right way of doing that, because it's based on the
fundamentally wrong concept of equating internal data structures of a
C program with externally defined data exchange formats.

> it was also considered worthwhile to apply __packed to all the
> structures in the project to save memory. 

That was quite a silly idea, to put it mildly.  What on earth would
you conserve individual bytes for, given that

1) the smallest memory chips you can easily get your hands on are a factor
of 4 larger than the entire supported address range of the previous CPU

2) the new CPU can address more memory than you can afford

3) the new CPU may kill your program on a misaligned access?

?

> Luckily, it was the only bug introduced this way.

... the only one you've *found* so far.  Absence of evidence is not
evidence of absence.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.