> So I am interested in recommendations for commercial (not gcc, thank
> you) C compiler and tool packages.

I am very dappy with gcc. Lot of help available online on IRC, newsgroups and ML.

gcc: http://www.codesourcery.com/gnu_toolchains/arm/
(Bare Metal GCC for ARM)

> 1.  No ARM9 specific code is used, the binaries could run on an ARM7.

use
-march=armv4 -mtune=arm9t
options

> 2.  No Thumb code, full 32-bit all the way.

just use
-mno-thumb-interwork
option to forbide this :)

> 3.  We own several Abatron BDI2000 Ethernet JTAG debuggers (and really
> like them!), so we need tools that support it and allow programming
> off-chip flash through the debugger.

so do I :)

just use the telnet version that supports gdb, and thats it.

> I would appreciate any recommendations or experiences good or bad with
> tool sets, we can check out the debugger and flash support issues with
> the tool vendors.

arm-none-eabi-as
is the assembler

arm-none-eabi-gcc
to compile

arm-none-eabi-ld
to link

arm-none-eabi-objcopy
to extract bits of code

arm-none-eabi-objdump
to examine the files

arm-none-eabi-gdb
to upload the data in the board through the network interface.

This can work using Linux or Windows. Since it is CLI, it isvery easy to write
scripts an automise procedures.

Since everything is text file in the source tree, it is trivial to use a versionning
system like subversion or CVS to allow sharing the development (even with multisite
developpers, so that many ppl can contribute to the code, but only my can test it in
the board), when the versionning systemallow to tag which version doeswhat, has
bugs, include reports and comments, and reload old version of the source tree.

I ve never seen versionning system for other project managers.

Note that my project is not exactly a standard free software project since it is
leaded by a company which pays some developpers.

Once Makefiles are written, after changing some line of code, just run 'make' to
recompile and upload the newcode in the board.

-- 
DEMAINE Benoit-Pierre (aka DoubleHP ) http://www.demaine.info/
\_o< If computing were an exact science, IT engineers would not have work >o_/

"R Adsett" <radsett@junk.aeolusdevelopment.cm> wrote in message
news:prmdnR5N5IW8cl_fRVn-gQ@rogers.com...
> In article <1119896254.016733.285780@z14g2000cwz.googlegroups.com>,
> atoumantsev_spam@mail.ru says...
> >
> >
> > tum_ wrote:
> > > Wilco Dijkstra wrote:
> > > > No, there shouldn't be - it is an error. The example you gave produces a
> > > > compile-time error in ADS1.2 as expected. It is illegal to lose the packed
> > > > qualifier, but it is legal to gain it - it works just like const and volatile.
> > > >
> > > > Wilco
> > >
> > > Here it gets interesting. I've just checked (had to ask my colleague
> > > The commandline is:
> > > [-O0 -Otime -asm -Oautoinline -g+ -fs -Wq -Ec]

Note that -O0 means that all optimizations are switched off (ie. slow&large
code), so -Otime has no effect.

> > All right, looks like '-Ec' suppresses the error. Haven't tried
> > w/out it yet but the description in the docs gives a good hint
> > on this.
> > No bleeping idea who put it into the makefile and for what reason :)
>
> Well, obviously to get rid of the alignment errors, since they couldn't
> possibly be a problem ;)

Possibly. It is likely however that the code simply didn't compile
without ignoring illegal implicit casts - most code isn't even close to
being standards compliant, so all compilers accept quite loose C
by default, and have many options to accept even more arcane C.

Wilco

In article <1119896254.016733.285780@z14g2000cwz.googlegroups.com>, 
atoumantsev_spam@mail.ru says...
> 
> 
> tum_ wrote:
> > Wilco Dijkstra wrote:
> > > No, there shouldn't be - it is an error. The example you gave produces a
> > > compile-time error in ADS1.2 as expected. It is illegal to lose the packed
> > > qualifier, but it is legal to gain it - it works just like const and volatile.
> > >
> > > Wilco
> >
> > Here it gets interesting. I've just checked (had to ask my colleague
> > The commandline is:
> > [-O0 -Otime -asm -Oautoinline -g+ -fs -Wq -Ec]
> >
> 
> All right, looks like '-Ec' suppresses the error. Haven't tried
> w/out it yet but the description in the docs gives a good hint
> on this.
> No bleeping idea who put it into the makefile and for what reason :)

Well, obviously to get rid of the alignment errors, since they couldn't 
possibly be a problem ;)


Robert

tum_ wrote:
> Wilco Dijkstra wrote:
> > No, there shouldn't be - it is an error. The example you gave produces a
> > compile-time error in ADS1.2 as expected. It is illegal to lose the packed
> > qualifier, but it is legal to gain it - it works just like const and volatile.
> >
> > Wilco
>
> Here it gets interesting. I've just checked (had to ask my colleague
> The commandline is:
> [-O0 -Otime -asm -Oautoinline -g+ -fs -Wq -Ec]
>

All right, looks like '-Ec' suppresses the error. Haven't tried
w/out it yet but the description in the docs gives a good hint
on this.
No bleeping idea who put it into the makefile and for what reason :)

Went to double-check the options used for gcc now.

Wilco Dijkstra wrote:
> "tum_" <atoumantsev_spam@mail.ru> wrote in message
> news:1119693665.893946.16560@g44g2000cwa.googlegroups.com...
> > That's what I'm actually interested in: should there be a warning
> > for such a construct?
>
> No, there shouldn't be - it is an error. The example you gave produces a
> compile-time error in ADS1.2 as expected. It is illegal to lose the packed
> qualifier, but it is legal to gain it - it works just like const and volatile.
>
> Wilco

Here it gets interesting. I've just checked (had to ask my colleague
with yet unexpired ADS license) - and there's *no* warning or error.
ADS1.2 [Build 848].
The commandline is:
[-O0 -Otime -asm -Oautoinline -g+ -fs -Wq -Ec]

Could you quote the exact error message, please?

And thanks to all of you who produced such lengthy posts
explaining how stupid it is to use __packed ;-)
I can't afford replying to every post and don't feel it's
really necessary because I completely agree with you on most points.

I can assure you that the bug is about to be fixed properly :),
so the question is of purely academic interest.

On Sat, 25 Jun 2005 22:36:32 GMT, "Wilco Dijkstra"
<wilco-dot-dijkstra@ntlworld.com> wrote:

>
>"tum_" <atoumantsev_spam@mail.ru> wrote in message
>news:1119693665.893946.16560@g44g2000cwa.googlegroups.com...
>>
>>
>> R Adsett wrote:
>> > In article <1119602722.982744.72910@g14g2000cwa.googlegroups.com>,
>> > atoumantsev_spam@mail.ru says...
>
>> > 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?
>
>No, there shouldn't be - it is an error. The example you gave produces a
>compile-time error in ADS1.2 as expected. It is illegal to lose the packed
>qualifier, but it is legal to gain it - it works just like const and volatile.
>

The gcc documentation explicitly states that if the packed attribute
is used, that the resultant code is incompatible  with code not using
the packed attribute. From compiling a number of examples it appears
as if all accesses to structures are made using byte accesses when
using the packed attribute. On the Philips LPC2xxx series of ARM MCUs,
many people uses structures to access the peripheral registers. The
code is completely broken when using the packed attribute.

Regards
  Anton Erasmus

"tum_" <atoumantsev_spam@mail.ru> wrote in message
news:1119693665.893946.16560@g44g2000cwa.googlegroups.com...
>
>
> R Adsett wrote:
> > In article <1119602722.982744.72910@g14g2000cwa.googlegroups.com>,
> > atoumantsev_spam@mail.ru says...

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

No, there shouldn't be - it is an error. The example you gave produces a
compile-time error in ADS1.2 as expected. It is illegal to lose the packed
qualifier, but it is legal to gain it - it works just like const and volatile.

Wilco

"druck" <news@druck.freeuk.com> wrote in message news:f16f82804d.druck@druck.freeuk.net...
> 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.

Indeed, and for this reason it is generally a bad idea to pack all fields in
a structure. It is much better to pack just the fields that need to be packed.
This way most fields will be aligned to their natural alignment and thus
accessing them is efficient.

Packing all fields or assuming all pointers have lower than natural alignment
is only feasible on CPUs that have unaligned support in hardware, such as all
new ARM cores.

Wilco

In article <1119693665.893946.16560@g44g2000cwa.googlegroups.com>, 
atoumantsev_spam@mail.ru says...
> 
> 
> 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).

I won't ask you to defend it then ;)

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

Maybe.  In fact my inclination would be that it should, but we are well 
into implementation defined constructs here.

The biggest problem I see is that the only solutions appear to be
	- a (yet another) keyword to indicate the pointer passed to the 
routine may be unaligned.  If done globally the cost of accessing via 
pointers will have just gone through the roof.  Can you say code bloat?  
If done only on routines that get passed pointers to (potentially) 
unaligned pointers, and you rely on the compiler to warn on those 
instances you end up with a sort of creeping rot.
	- Forbid passing pointers to structure members.  
	- Forbid passing unaligned pointers and rely on the compiler 
warning about all the cases.  That would make me a bit nervous but the 
compiler might be up to it.
	- Forbid passing unaligned pointers and rely on the user 
recognizing the forbidden cases.  You already know why you don't like 
that one :)

Frankly I don't see any viable solution on an architecture with alignment 
restrictions other than to forbid the use of packed.  Or if you must use 
packed forbid taking the address of member elements of packed structures.
 
> > 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,

Hmm, that strikes me as applying a non-standard keyword to cover up a bug 
rather than fixing the bug in the first place.  

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

Um, if they want to apply packed to all structure why not just tell the 
compiler that rather than add the keyword to every structure.  You are 
much less likely to miss an instance that way.  It still strikes me as a 
bad optimization though, it takes more time and space to access unaligned 
members.

Robert