Developing/compiling software

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.

-- 
Grant Edwards                   grante             Yow! Was my SOY LOAF left
                                  at               out in th'RAIN?  It tastes
                               visi.com            REAL GOOD!!

Grant Edwards wrote:
> On 2009-09-25, ChrisQ <meru@devnull.com> wrote:
> 
>> 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...
> 
> I'm not talking about expressing opinions.  I'm talking about
> being actively involved in working with/on open-source tools
> and attempting to hide one's affilliation while doing so.
> 
> It turned out the maintainer of one of the key libraries that
> was holding back progress in the effort to support JTAG
> debugging was a TI employee who didn't disclose the fact and
> declined to answer when asked directly.
> 
> Offers to help with development of the library (even if it
> required signing an NDA) or offerst to beta-test the library
> were ignored.
> 
> I can't speak for others involved, but that left a pretty bad
> taste in my mouth.
> 

Wasn't implying criticism - just my warped sense of humour found the 
thread amusing for some reason ~).

Can't comment on TI, but they all have agendas and usually the bigger 
they are the worse they can be. Add to that the infantile postering and 
arrogance of some of them and it's off to the next vendor if possible. 
Some of the worst are those  who don't want to deal with you as a small 
company, or a bit offbeat, but are all over you if you mention the 
client. I feel it's unethical and should never have to do it, but 
sometimes you have to pull rank just to get stuff done. I really can't 
be bothered with "front". The recommendation in all such cases is for 
the client to look elsewhere in the future. Business depends on mutual 
trust and cooperation and breaks down if one side or the other is being 
devious or economical with the truth. Having said that, there are some 
really good companies out there who have brilliant resources and are 
easy to do business with.

I guess you have to accept that some vendors and individuals are just 
hard work and learn to live with it or leave it :-)...

Regards,

Chris

On 2009-09-25, ChrisQ <meru@devnull.com> wrote:

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

I'm not talking about expressing opinions.  I'm talking about
being actively involved in working with/on open-source tools
and attempting to hide one's affilliation while doing so.

It turned out the maintainer of one of the key libraries that
was holding back progress in the effort to support JTAG
debugging was a TI employee who didn't disclose the fact and
declined to answer when asked directly.

Offers to help with development of the library (even if it
required signing an NDA) or offerst to beta-test the library
were ignored.

I can't speak for others involved, but that left a pretty bad
taste in my mouth.

-- 
Grant Edwards                   grante             Yow! This PORCUPINE knows
                                  at               his ZIPCODE ... And he has
                               visi.com            "VISA"!!

"ChrisQ" <meru@devnull.com> wrote in message 
news:sK4vm.199649$AC5.36013@newsfe06.ams2...
> 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 ?.


I have not gone back to check, but from memory (might not be completely 
accurate) the AVR uses two 8 bit registers to implement a 16 bit stack 
pointer.  When entering/exiting a function the stack pointer has to 
potentially be updated as two separate operations, and you don't want the 
update to be split by an interrupt occuring half way through.

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

FreeRTOS info wrote:
> 
> "ChrisQ" <meru@devnull.com> wrote in message 
> news:sK4vm.199649$AC5.36013@newsfe06.ams2...
>> 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 ?.
> 
> 
> I have not gone back to check, but from memory (might not be completely 
> accurate) the AVR uses two 8 bit registers to implement a 16 bit stack 
> pointer.  When entering/exiting a function the stack pointer has to 
> potentially be updated as two separate operations, and you don't want 
> the update to be split by an interrupt occuring half way through.

Adding a bit to Richard's reply: The AVR call and return instructions 
update the 16-bit "hardware" stack pointer (to push and pop the return 
address) but they do so atomically, so they don't need interrupt 
disabling. But gcc uses the "hardware" stack also for data, and must 
then update the stack pointer as two 8-bit parts, which needs interrupt 
disabling as Richard describes above.

The IAR compiler uses the AVR Y register (a pair of 8-bit registers 
making up a 16-bit number) as the stack pointer for the second, 
compiler-defined "software" stack. IAR still uses the hardware stack for 
return addresses, so it still uses the normal call and return 
instructions (usually), but it puts all stack-allocated data on the 
software stack accessed via the Y register. The AVR provides 
instructions that can increment or decrement the Y register atomically, 
as a 16-bit entity, and the IAR compiler's function prologues/epilogues 
often use these instructions. However, sometimes the IAR compiler 
generates code that adds or subtracts a larger number (> 1) to/from Y, 
and then it must use two 8-bit operations, and must disable interrupts 
just as gcc does.

Conclusion: the frequency of interrupt disabling is probably less in 
IAR-generated code than in gcc-generated code, but the impact in terms 
of an increased worst-case interrupt response latency is the same.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

On 2009-09-25, ChrisQ <meru@devnull.com> wrote:
> Grant Edwards wrote:
>> On 2009-09-25, ChrisQ <meru@devnull.com> wrote:
>> 
>>> 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...
>> 
>> I'm not talking about expressing opinions.  I'm talking about
>> being actively involved in working with/on open-source tools
>> and attempting to hide one's affilliation while doing so.
>> 
>> It turned out the maintainer of one of the key libraries that
>> was holding back progress in the effort to support JTAG
>> debugging was a TI employee who didn't disclose the fact and
>> declined to answer when asked directly.
>> 
>> Offers to help with development of the library (even if it
>> required signing an NDA) or offerst to beta-test the library
>> were ignored.
>> 
>> I can't speak for others involved, but that left a pretty bad
>> taste in my mouth.
>
> Wasn't implying criticism - just my warped sense of humour
> found the thread amusing for some reason ~).

[...]

> I guess you have to accept that some vendors and individuals
> are just hard work and learn to live with it or leave it
> :-)...

Yep.  It's a trade-off.  When you find a part that fits the
requirements much better than the alternatives, but the vendor
is difficult to deal with, you pays your money and you makes
your choice.

And then you complain about it. :)

-- 
Grant Edwards                   grante             Yow! I hope the
                                  at               ``Eurythmics'' practice
                               visi.com            birth control ...

A small addition to my own posting, sorry for omitting it initially:

Niklas Holsti wrote:
(I elide most of the context):

> However, sometimes the IAR compiler 
> generates code that adds or subtracts a larger number (> 1) to/from Y, 
> and then it must use two 8-bit operations, and must disable interrupts 
> just as gcc does.

Some AVR models do provide instructions (ADIW, SBIW) that can atomically 
add/subtract an immediate number (0..63) to/from the 16-bit Y register. 
I assume, but haven't checked, that IAR uses these instructions when 
possible, rather than two 8-bit operations in an interrupt-disabled region.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

ChrisQ skrev:
> 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 MIPS rate is Dhrystone number divided by Dhrystone number on a 
VAX-11/780.
Can't tell how the ST gcc result was measured, but
the code I ran, used a timer for measurement.

There is a Dhrystone benchmark on :
http://www.atmel.com/dyn/resources/prod_documents/softpack-1.6-at91sam3u-ek.zip
In the test power consumption project.



> 
> 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 have, that is but one example.
If you look at the code generation, there are plenty of things
which is done better on the IAR compiler.

 >
I used IAR on H8 projects some years ago

And I was discussing the AVR architecture.
The IAR compiler will be good for some architectures, and not
so good for others.

> 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 

With IAR it is easier to write in C, because it is closer
to assembler in performance.


> 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 a poor compiler generates signifianct more code, then
you might have to add more code, and eventually go
to a larger controller.  adding cost.



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

You might have made a good selection, and then the environment changes
forcing you to add more code.

  Must be out of date on this as well - since
> when did vanilla gcc provide support for interrupt handlers ?.

WinAVR does.

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

FreeRTOS info skrev:
> "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.

32 MIPS was gcc-4.2.1 with -O3.


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

Or ask for other people's experience.

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

Yes,
more than 50% of the AVR users, use gcc.

BR
Ulf Samuelsson

David Brown skrev:
> 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.

In the case I investigated for a customer
(which was more than one year ago)
the interrupt routines took a lot longer time to execute,
and this causes a lot of grievance.


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

I don't disagree with that.
I have both, but I quickly scurry back to the IAR compiler
if I need to show off the AVR.


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

OK, let me rephrase: It generally outputs smaller and faster code.

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