Developing/compiling software

In message <h9g855$4vg$1@reader1.panix.com>, Grant Edwards
<invalid@invalid.invalid> writes
>On 2009-09-24, Chris H <chris@phaedsys.org> wrote:
>
>> My god you are sad.  Most companies insist that employees use
>> private email addresses and not company ones when conversing
>> on newsgroups and forum lest anything they say be taken as
>> being said on behalf of the company.
>
>We're supposed to believe that things TI employees say in
>regards to TI products _aren't_ being said on behalf of the
>company?
>
>> Your paranoid suggestion that TI was planting "moles" is a sad
>> reflection on you.
>>
>> Then again what is your email address? invalid@invalid.invalid
>> Hmmm not a TI mole by any chance?  OK so you do have another
>> email address inthe sig.
>
>A futile attempt to avoid my e-mail address from being
>harvested mechanically.
>
>> Tell me is Mike Sowada happy with you/visi making these
>> accusations about TI?
>
>I don't think my ISP cares one way or the other about my
>opinions on TI's interaction with their customers.  Neither
>does the post office or the phone company, in case you're
>curious about them.
>

So you don't email from your work account either.....

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 2009-09-24, Chris H <chris@phaedsys.org> wrote:
> In message <h9g855$4vg$1@reader1.panix.com>, Grant Edwards

>>> Tell me is Mike Sowada happy with you/visi making these
>>> accusations about TI?
>>
>>I don't think my ISP cares one way or the other about my
>>opinions on TI's interaction with their customers.  Neither
>>does the post office or the phone company, in case you're
>>curious about them.
>
> So you don't email from your work account either.....

When I'm dealing with customers, vendors, or anything regarding
products of my employer, I do.

For miscellaneous usenet postings containing my personal
opinions, I don't.

-- 
Grant Edwards                   grante             Yow! MMM-MM!!  So THIS is
                                  at               BIO-NEBULATION!
                               visi.com            

ChrisQ skrev:
> Chris H wrote:
> 
>>
>> If that were the case there would be a problem but so far most of the
>> open source compilers are no where near as good as the top commercial
>> ones.
>>
> 
> I'm sorry, but you need to be more specific in terms of *how* they are 
> better. You're not selling soap powder to the 19th c unwashed here. If 
> we are discussing Keil, it's not so much the compiler, but the linker, 
> which seems to do magic in terms of it's overlay analysis and ability to 
> make use of constrained ram and xdata space. A btter solution might have 
> been to do more work upfront in terms of design and cpu choice to avoid 
> the problem in the first place. Great for legacy hardware but not 
> necessarily relevant if you're starting from scratch.
> 
> So what else is there and how about other vendors and architectures. 
> What's so inferior about the gnu toolchain, for example ?.
> 
The GNU toolchain can be OK, and it can be horrible.
If you look at ST's home page you will find some discussion
about performance of GCC-4.2.1 on the STM32.

The rumoured 90 MIPS becomes:

wait for it...

32 MIPS...

With a Keil compiler you can reach about 60-65 MIPS at least with
a 72 MHz Cortex-M3.

Anyone seen improvement in later gcc versions?

...
On the AVR I noted things like pushing ALL registers
when entering an interrupt.
The IAR is simply - better - .

The gcc compiler can be OK, as shown with the AVR32 gnu compiler.


BR
Ulf Samuelsson

>>
>>> means a diminishing client base and less money for development. Unless
>>> they can come up with a revised business model, they seem condemned to
>>> niche markets and long term decline. If you want evidence, compare the
>>> diversity of tool vendors a decade ago with the same now.
>>
>> True... So eventually programmers will be expected to produce their own
>> tools and RTOS on their own time at their own expense.
> 
> Some already do :-), but that's taking the argument to absurd limits. Of 
> course, you write some tools over the years, but buy in the stuff that 
> would be uneconomic to develop yourself. One of the great strengths of 
> open source is that it shares the cost and time to develop complex 
> applications among the many with the result available for all to use. It 
> potentially brings together resources that would be not possible for 
> individual companies.
> 
>>
>> Who funds these open source programmers? They have to eat.
> 
> Some people are still altruistic, believe it or not and do it for fun or 
> the intellectual challenge while keeping their day job. Others want to 
> be remembered for contributing something for the common good, rather 
> than merely for commercial gain. Any number of reasons. Not to say that 
> there's not serious money involved now. IBM, Hp / Compaq and many others 
> fund development and the likes of Redhat, Code Sourcery and Kpit Cummins 
> package up the results to sell and provide support.
> 
> The truth is that the marketplace for tools has changed forever. How 
> will traditional tool vendors  like Keil and IAR survive in the long 
> term ?.
> 
>>
>> The problem is the main users of the open source tools are not the ones
>> who are producing them...
>>
> 
> How is this a problem ?...
> 
> Regards,
> 
> Chris

ChrisQ skrev:
> Grant Edwards wrote:
> 
>>
>> In my experience the producers of open-source tools _do_ use
>> them. It's just that not all of the users are producers.
>>
> 
> The best example must be gcc, where each new generation will be compiled 
> by the previous one.
> 
>>
>> IMO, the problem is even worse for commericial tools where it's
>> quite obvious that in many cases the producers do not (nor have
>> they ever attempted to) use the tools.
>>
> 
> None of the commercial tools i've used have been really bad. They all 
> compile code and seem to have few bugs. Even the older stuff (>10yrs) 
> more or less did what it said on the tin, but by the time you get all 
> the costs, lack of trust, dongles and flexlm hassles onboard, they can 
> turn into a real can of worms totally unrelated to tool quality. It's 
> not the tools that are the problem, but sometimes the attitude of the 
> vendors, imho.
> 
> Anyway, the open source stuff, where available, is often as good or 
> better for all practical purposes. There's no real reason not to use it 
> and the open source model of cooperative development is arguably more 
> suited to the mindset of many users. You just have to do some of the 
> legwork yourself...

If you are designing products which are produced in large volumes
you have to look at the code generation of open-source vs commercial
because you can save a lot of money, by selecting another chip
with less memory.
BR
Ulf

> 
> Regards,
> 
> Chris

In message <h9geue$7el$1@reader1.panix.com>, Grant Edwards
<invalid@invalid.invalid> writes
>On 2009-09-24, Chris H <chris@phaedsys.org> wrote:
>> In message <h9g855$4vg$1@reader1.panix.com>, Grant Edwards
>
>>>> Tell me is Mike Sowada happy with you/visi making these
>>>> accusations about TI?
>>>
>>>I don't think my ISP cares one way or the other about my
>>>opinions on TI's interaction with their customers.  Neither
>>>does the post office or the phone company, in case you're
>>>curious about them.
>>
>> So you don't email from your work account either.....
>
>When I'm dealing with customers, vendors, or anything regarding
>products of my employer, I do.

When officially representing the company

>For miscellaneous usenet postings containing my personal
>opinions, I don't.

And neither do the TI employees

You are complaining they do exactly what you are doing

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Ulf Samuelsson wrote:

> The GNU toolchain can be OK, and it can be horrible.
> If you look at ST's home page you will find some discussion
> about performance of GCC-4.2.1 on the STM32.
> 
> The rumoured 90 MIPS becomes:
> 
> wait for it...
> 
> 32 MIPS...
> 
> With a Keil compiler you can reach about 60-65 MIPS at least with
> a 72 MHz Cortex-M3.

Just how are they measuring these "mips" and can we see some asm code 
output evidence Everything else is just supposition ... ?.

The assembler output is the final arbiter. Optimisation and code 
generation can only work with what you give it and depends a lot on the 
C constructs and code layout used. That is, you need to understand and 
work cooperatively with your compiler to get the best results.  Gcc 68k 
produces pretty well optimised code as it's been around for a long time. 
Have been working with Renesas 80C87 on and off for a couple of years 
now. The assembler output would be difficult to improve on. Often half a 
dozen lines of C produces about the same number of lines of assembler 
output. If there is a major difference, is it perhaps because Cortex is 
still fairly new in gcc terms, or is it because there are not enough 
people interested enough / have the free time to improve it ?.

> On the AVR I noted things like pushing ALL registers
> when entering an interrupt.
> The IAR is simply - better - .

Hardly rational - I think you need to look at a lot more than single 
point to decide on "better". I used IAR on H8 projects some years ago 
and found the toolchain, shall we say, a bit eccentric. It worked and 
produced good code afaik, but was quite limited in terms of command line 
switches, options, utilities etc. That is, there wasn't much added value 
in the package and nothing like as good as Microtek's 68k offerings. 
It's probably much better now, but compare that with the gnu toolchain, 
which is not just gcc and binutils, but a whole raft of other utilities, 
all of which work seamlessly with a linux, unix or windows development 
environment and cost nothing other than the time to set it up.

As for registers, many of us came from an assembler background, but the 
world has moved on and modern micros have more than enough grunt to get 
the job done without worrying about how many registers are being saved. 
The whole idea is that you can now afford to write eveything in C 
without having to examine the entrails to optimise the code. Issues like 
no view of the big picture, poor system design and partitioning have 
much more impact than any tool efficiency issues, imnsho. Pushing a few 
or all registers makes how much ? - a few microseconds difference at 
most. Irrelevant in  practical terms. If the architecture is being 
pushed so far close to the ragged edge, it suggests that you are trying 
to do a "mission impossible" project, or didn't size up requirements 
properly in the first place. Must be out of date on this as well - since 
when did vanilla gcc provide support for interrupt handlers ?.

If you want a better gcc for your architecture, don't just criticise, 
join in and contribute. I'm just gratefull that there is so much good 
open source code out there and free to use...

Regards,

Chris

"ChrisQ" <meru@devnull.com> wrote in message 
news:W91vm.97400$Bg1.35156@newsfe25.ams2...
> Ulf Samuelsson wrote:

<snip>

>> With a Keil compiler you can reach about 60-65 MIPS at least with
>> a 72 MHz Cortex-M3.
>
> Just how are they measuring these "mips" and can we see some asm code 
> output evidence Everything else is just supposition ... ?.

GCC output is very literal and therefore very slow when optimisation is 
turned off - it does ok with higher optimisation.  With regard to code size, 
by default it does not remove unreferenced code whereas commercial linkers 
do.  With a few command line options you can get the code size very close to 
the commercial guys.

I'm not offering an opinion on the quality of GCC - just pointing out a few 
facts.  The best thing to do is not believe anything you read and instead 
try it out for yourself.

Also, when using an 8051 squeezing out every last instruction can be 
important.  If it is really that important on your new designs then 
basically you chose the wrong CPU (I don't want to start another thread 
about supporting legacy systems!).


>> On the AVR I noted things like pushing ALL registers
>> when entering an interrupt.
>> The IAR is simply - better - .
>

GCC and IAR compilers do very different things on the AVR - the biggest 
difference being that IAR use two stacks whereas GCC uses one.  This makes 
IAR more difficult to setup and tune, and GCC slower and clunkier because it 
has to disable interrupts for a few instructions on every function call. 
Normally this is not a problem, but it is not as elegant as the two stack 
solution for sure.  GCC is very popular on the AVR though, and is good 
enough for most applications, especially used in combination with the other 
free AVR tools such as AVRStudio.

-- 
Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T&#4294967295;V as meeting the requirements for safety related systems 

Ulf Samuelsson wrote:
> The GNU toolchain can be OK, and it can be horrible.
> If you look at ST's home page you will find some discussion
> about performance of GCC-4.2.1 on the STM32.
> 

Could you provide a link to this?  I could not see any such discussion.

I note that gcc-4.2.1 was the CodeSourcery release two years ago, when 
Thumb-2 support was very new in gcc.  And if the gcc-4.2.1 in question 
was not from CodeSourcery but based on the official FSF tree, then I 
don't think it had Thumb-2 at all.  It is very important with gcc to be 
precise about the source and versions - particularly so since 
CodeSourcery (who maintain the ARM ports amongst others) have 
target-specific features long before they become part of the official 
FSF tree.

> The rumoured 90 MIPS becomes:
> 
> wait for it...
> 
> 32 MIPS...
> 
> With a Keil compiler you can reach about 60-65 MIPS at least with
> a 72 MHz Cortex-M3.
> 
> Anyone seen improvement in later gcc versions?
> 

I would be very surprised to see any major ARM compiler generating code 
at twice the speed of another major ARM compiler, whether we are talking 
gcc or commercial compilers.  To me, this indicates either something odd 
about the benchmark code, something wrong in the use of the tools (such 
as compiler flags or libraries), or something wrong in the setup of the 
device in question (maybe failing to set clock speeds or wait states 
correctly).

If there was consistently such a big difference, I would not expect 
gcc-based development tools to feature so prominently on websites such 
as ST's or TI (Luminary Micros) - a compiler as bad as you suggest here 
would put the devices themselves in a very bad light.

I haven't used the ST32 devices, but I am considering TI's Cortex-M3 for 
a project, so I interested in the state of development tools for the 
same core.

> ...
> On the AVR I noted things like pushing ALL registers
> when entering an interrupt.

avr-gcc does /not/ push all registers when entering an interrupt.  It 
does little for the credibility of your other points when you make such 
widely inaccurate claims.

avr-gcc always pushes three registers in interrupts - SREG, and its 
"zero" register and "tmp" register because some code sequences generated 
by avr-gcc make assumptions about being able to use these registers. 
Theoretically, these could be omitted in some cases, but it turns out to 
be a difficult to do in avr-gcc, and the advantages are small (for 
non-trivial interrupt functions).  No one claims that avr-gcc is 
perfect, merely that it is very good.

Beyond that, avr-gcc pushes registers if they are needed - pretty much 
like any other compiler I have used.  If your interrupt function calls 
an external function, and you are not using whole-program optimisation, 
then this means pushing all ABI "volatile" registers - an additional 12 
registers.  Again, this is the same as for any other compiler I have 
seen.  And as with any other compiler, you avoid the overhead by keeping 
your interrupt functions small and avoiding external function calls, or 
by using whole-program optimisations.

> The IAR is simply - better - .
> 

I'll not argue with you about IAR producing somewhat smaller or faster 
code than avr-gcc.  I have only very limited experience with IAR, so I 
can't judge properly.  But then, you apparently have very little 
experience with avr-gcc - few people have really studied and compared 
both compilers in a fair and objective test.  There is certainly room 
for improvement in avr-gcc - there are people working on it, and it gets 
better over time.

But to say "IAR is simply better" is too sweeping a statement to be 
taken seriously, since "better" means so many different things to 
different people.

> The gcc compiler can be OK, as shown with the AVR32 gnu compiler.
> 

To go back to your original statement, "The GNU toolchain can be OK, and 
it can be horrible", I agree in general - although I'd rate the range a 
bit higher (from "very good" down to "pretty bad", perhaps).  There have 
been gcc ports in the past that could rate as "horrible", but I don't 
think that applies to any modern gcc port in serious active use.

> 
> BR
> Ulf Samuelsson
> 

Grant Edwards wrote:
> On 2009-09-25, Chris H <chris@phaedsys.org> wrote:
> 
>>>>>> Tell me is Mike Sowada happy with you/visi making these
>>>>>> accusations about TI?
>>>>> I don't think my ISP cares one way or the other about my
>>>>> opinions on TI's interaction with their customers.  Neither
>>>>> does the post office or the phone company, in case you're
>>>>> curious about them.
>>>> So you don't email from your work account either.....
>>> When I'm dealing with customers, vendors, or anything regarding
>>> products of my employer, I do.
>> When officially representing the company
>>
>>> For miscellaneous usenet postings containing my personal
>>> opinions, I don't.
>> And neither do the TI employees
>>
>> You are complaining they do exactly what you are doing
> 
> No, I was complaining that when working with customers
> (specifically people who were working on open-source tools for
> the MSP430), certain TI employees attempted to hide the fact
> that they were TI employees.  When asked directory whether or
> not they were TI employees, they declined to answer.
> 

If this is a chess game :-). Is the issue that you should declare 
conflicts of interest when expressing opinions about proprietary 
products. No reason to do so otherwise...

Regards,

Chris

FreeRTOS info wrote:

> 
> GCC and IAR compilers do very different things on the AVR - the biggest 
> difference being that IAR use two stacks whereas GCC uses one.  This 
> makes IAR more difficult to setup and tune, and GCC slower and clunkier 
> because it has to disable interrupts for a few instructions on every 
> function call. Normally this is not a problem, but it is not as elegant 
> as the two stack solution for sure.  GCC is very popular on the AVR 
> though, and is good enough for most applications, especially used in 
> combination with the other free AVR tools such as AVRStudio.
> 

Can you elaborate a bit as to why 2 stacks are used with IAR ?. Haven't 
user avr, so have no real experience. The AVR 32 has shadow register 
sets, including stacks for each processor and exception mode. Thus, 
separate initialisation on startup, but so do Renasas 80C87 and some arm 
machines. How does gcc work for arm, for example ?.

Regards,

Chris