gnu for uvision3

Started by naderus2000 July 31, 2006
hi
i see this line from keil site:
The GNU ARM tools (compiler, assembler, and so on) that are provided
are
not limited or restricted in any way.

so i want to know if using GNU is uvision3 IDE is free so why all of
the peaple use free tool winARm+Eclipse+..?
is there any limited for gnu in keil?

An Engineer's Guide to the LPC2100 Series

--- In l..., "naderus2000" wrote:

> so i want to know if using GNU is uvision3 IDE is free so why all of
> the peaple use free tool winARm+Eclipse+..?
> is there any limited for gnu in keil?

Two reasons:

1) they distribute a very old version of gcc with the Keil tools (the
last update they sent out in May 2006 still has a gcc from 2003)
2) they don't have gdb - you have to use their debugger, which is good
but has a 16K limit.

It's true that their obsolete gcc has no limits. But you can't do any
debugging if your program is over 16K, and who really wants to use a
compiler from 2003, anyway?

Eric
--- In l..., "Eric Engler" wrote:
> ....and who really wants to use a
> compiler from 2003, anyway?
>

I'd be happy to use one from 1983, if it worked!

Some things (in particular, the things that work) are best left
unchanged.....

Brendan
--- In l..., "Eric Engler" wrote:

*********************SNIP*********************************************
> , and who really wants to use a compiler from 2003, anyway?
>
> Eric
>
You mean ARM changed the ARM7/ARM9 instruction sets after 2003??????

-- Dave
derbaier wrote:

> --- In lpc2000@yahoogroups .com ,
> "Eric Engler" wrote:
>
> ************ ********* SNIP***** ********* ********* *********
> ********* ****
> > , and who really wants to use a compiler from 2003, anyway?
> >
> > Eric
> >
> You mean ARM changed the ARM7/ARM9 instruction sets after 2003??????
3.3.x and 3.4.x have significant issues with code generation for ARM.
One of which is a subtle stack corruption caused by an interrupt
occurring within the early execution of a function. It is subtle, there
is a variety of conditions that must be present in the coding of the
function to force this wart to surface.

I have seen code which produces this error, compiled it under both
gcc-3.3.3 and gcc-3.4.4, both versions of the compiler produced code
sequences which left the stack open to corruption should an interrupt
occur in the early part of the function code.

Compiling that same code under gcc-4.0.1 did not produce the code
sequence, but produced code that would be immune to such corruption.

Another issue is that gcc-3.3 did not produce proper thumb code. This
was corrected in gcc-3.4.

So far, I've been using gcc-4.0.2 for about 10 months now and have had
satisfactory results.

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------
--- In l..., Tom Walsh wrote:
>
> derbaier wrote:
>
> > --- In lpc2000@yahoogroups .com
40yahoogroups.com>,
> > "Eric Engler" wrote:
> >
> > ************ ********* SNIP***** ********* ********* *********
> > ********* ****
> > > , and who really wants to use a compiler from 2003, anyway?
> > >
> > > Eric
> > >
> > You mean ARM changed the ARM7/ARM9 instruction sets after
2003??????
> >
> No, GNU gcc just got better a producing ARM code. The gcc
versions
> 3.3.x and 3.4.x have significant issues with code generation for
ARM.
> One of which is a subtle stack corruption caused by an interrupt
> occurring within the early execution of a function. It is subtle,
there
> is a variety of conditions that must be present in the coding of
the
> function to force this wart to surface.
>
> I have seen code which produces this error, compiled it under both
> gcc-3.3.3 and gcc-3.4.4, both versions of the compiler produced
code
> sequences which left the stack open to corruption should an
interrupt
> occur in the early part of the function code.
>
> Compiling that same code under gcc-4.0.1 did not produce the code
> sequence, but produced code that would be immune to such
corruption.
>
> Another issue is that gcc-3.3 did not produce proper thumb code.
This
> was corrected in gcc-3.4.
>
> So far, I've been using gcc-4.0.2 for about 10 months now and have
had
> satisfactory results.
>
> TomW
>

This begs the question: is there a documented list of such issues
anywhere?

I as aware of the interrupt issue you mention: as far as I know it's
associated with using the "irq" modifier (yet another reason to
avoid such "features").

Do you know what the issue with Thumb code is?

By the way, my own comment about using somethinhg prior to 2003 was
a natural caution against using the latest and greatest version of
anything, if what went before worked OK. Even if an older version
has issues, at least there generally known: it's the unknown issues
I'd be worried about!

We've used GNU 3.3.1 (as far as I know) for ARM work for about three
years now, with no issues. This is in contrast from other compiler
vendors which had several code generation bugs.

>From what you say, though, it looks like we should at least look at
4.0.2: thanks for the info.

Brendan.
--- In l..., Tom Walsh wrote:
>
> derbaier wrote:
>
> > --- In lpc2000@yahoogroups .com ,
> > "Eric Engler" wrote:
> >
> > ************ ********* SNIP***** ********* ********* *********
> > ********* ****
> > > , and who really wants to use a compiler from 2003, anyway?
> > >
> > > Eric
> > >
> > You mean ARM changed the ARM7/ARM9 instruction sets after
2003??????
> >
> No, GNU gcc just got better a producing ARM code.

********************SNIP*************************************
Well, that is a whole lot better reason than "who really wants to use
a compiler from 2003, anyway?". BTW, means GRIN, and that means
the comment was all in fun anyway. I only use GCC every once in
awhile, so I got some worthwhile information from your post.

Thanks!
-- Dave
--- In l..., Tom Walsh wrote:

> Another issue is that gcc-3.3 did not produce proper thumb code. This
> was corrected in gcc-3.4.
>
> So far, I've been using gcc-4.0.2 for about 10 months now and have had
> satisfactory results.

>From a different perspective perhaps, GCC 3.3.2 build (with patches to
remove compiler in-built calls to newlib) have served me very well for
both arm and thumb code.

I have been looking for an excuse to move people to later versions
(makes support easier) but this is hard when there are those who will
not move unless the version they have is broken.

Jaya
Brendan Murphy wrote:

> --- In lpc2000@yahoogroups .com ,
> Tom Walsh wrote:
> >
> > derbaier wrote:
> >
> > > --- In lpc2000@yahoogroups .com > 40yahoogroups. com>,
> > > "Eric Engler" wrote:
> > >
> > > ************ ********* SNIP***** ********* ********* *********
> > > ********* ****
> > > > , and who really wants to use a compiler from 2003, anyway?
> > > >
> > > > Eric
> > > >
> > > You mean ARM changed the ARM7/ARM9 instruction sets after
> 2003??????
> > >
> > No, GNU gcc just got better a producing ARM code. The gcc
> versions
> > 3.3.x and 3.4.x have significant issues with code generation for
> ARM.
> > One of which is a subtle stack corruption caused by an interrupt
> > occurring within the early execution of a function. It is subtle,
> there
> > is a variety of conditions that must be present in the coding of
> the
> > function to force this wart to surface.
> >
> > I have seen code which produces this error, compiled it under both
> > gcc-3.3.3 and gcc-3.4.4, both versions of the compiler produced
> code
> > sequences which left the stack open to corruption should an
> interrupt
> > occur in the early part of the function code.
> >
> > Compiling that same code under gcc-4.0.1 did not produce the code
> > sequence, but produced code that would be immune to such
> corruption.
> >
> > Another issue is that gcc-3.3 did not produce proper thumb code.
> This
> > was corrected in gcc-3.4.
> >
> > So far, I've been using gcc-4.0.2 for about 10 months now and have
> had
> > satisfactory results.
> >
> > TomW
> > This begs the question: is there a documented list of such issues
> anywhere?
>
bugzilla

>
> I as aware of the interrupt issue you mention: as far as I know it's
> associated with using the "irq" modifier (yet another reason to
> avoid such "features").
>
No, it is not. It is not associated with "irq, fiq, naked" or any other
modifiers. See:
http://www.openhardware.net/Embedded_ARM/Toolchain/#toolchainsource

This message summarizes the problem:
http://groups.yahoo.com/group/gnuarm/message/1651

He sent me a copy of the code that produces the error, I compiled it on
gcc-3.3.3 and 3.4.4 and got the same issue. gcc-4.0.2 did not produce
the problem.

Up to that time, I was confidently using 3.4.4 to produce ARM32 code and
had been using it for that for a while. But, after the demonstration of
this problem, I moved on to 4.0.2.

One thing about the bugs you don't know, if you have good debugging
skills, experience and the tools, plus confidence, you can usually track
the suckers down fairly quickly. At least the gnu gcc developers would
be more responsive to fixing an issue with the latest release, rather
than one that is 4..6 years old?

TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------
--- In l..., Tom Walsh wrote:
>
> Brendan Murphy wrote:
>
> > --- In lpc2000@yahoogroups .com
40yahoogroups.com>,
> > Tom Walsh wrote:
> > >
> > > derbaier wrote:
> > >
> > > > --- In lpc2000@yahoogroups .com > > 40yahoogroups. com>,
> > > > "Eric Engler" wrote:
> > > >
> > > > ************ ********* SNIP***** ********* ********* *********
> > > > ********* ****
> > > > > , and who really wants to use a compiler from 2003, anyway?
> > > > >
> > > > > Eric
> > > > >
> > > > You mean ARM changed the ARM7/ARM9 instruction sets after
> > 2003??????
> > > >
> > > No, GNU gcc just got better a producing ARM code. The gcc
> > versions
> > > 3.3.x and 3.4.x have significant issues with code generation for
> > ARM.
> > > One of which is a subtle stack corruption caused by an interrupt
> > > occurring within the early execution of a function. It is
subtle,
> > there
> > > is a variety of conditions that must be present in the coding of
> > the
> > > function to force this wart to surface.
> > >
> > > I have seen code which produces this error, compiled it under
both
> > > gcc-3.3.3 and gcc-3.4.4, both versions of the compiler produced
> > code
> > > sequences which left the stack open to corruption should an
> > interrupt
> > > occur in the early part of the function code.
> > >
> > > Compiling that same code under gcc-4.0.1 did not produce the
code
> > > sequence, but produced code that would be immune to such
> > corruption.
> > >
> > > Another issue is that gcc-3.3 did not produce proper thumb code.
> > This
> > > was corrected in gcc-3.4.
> > >
> > > So far, I've been using gcc-4.0.2 for about 10 months now and
have
> > had
> > > satisfactory results.
> > >
> > > TomW
> > >
> >
> > This begs the question: is there a documented list of such issues
> > anywhere?
> >
> bugzilla
>
> >
> > I as aware of the interrupt issue you mention: as far as I know
it's
> > associated with using the "irq" modifier (yet another reason to
> > avoid such "features").
> >
> No, it is not. It is not associated with "irq, fiq, naked" or any
other
> modifiers. See:
> http://www.openhardware.net/Embedded_ARM/Toolchain/#toolchainsource
>
> This message summarizes the problem:
> http://groups.yahoo.com/group/gnuarm/message/1651
>
> He sent me a copy of the code that produces the error, I compiled
it on
> gcc-3.3.3 and 3.4.4 and got the same issue. gcc-4.0.2 did not
produce
> the problem.
>
> Up to that time, I was confidently using 3.4.4 to produce ARM32
code and
> had been using it for that for a while. But, after the
demonstration of
> this problem, I moved on to 4.0.2.
>
> One thing about the bugs you don't know, if you have good debugging
> skills, experience and the tools, plus confidence, you can usually
track
> the suckers down fairly quickly. At least the gnu gcc developers
would
> be more responsive to fixing an issue with the latest release,
rather
> than one that is 4..6 years old?
>
> TomW
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------
>
Hi,

the www.openhardware.net link mentions the optimizer level -Os.
We use GCC 3.3.1 with optimizer level -O2 experiencing no problems.

xjag