Re: [Sdcc-user] IAR with SDCC

[Kustaa N. <Kus...@pl...>]

On 13/02/2014 16:56, "Sebastien Lorquet" <seb...@lo...> wrote:

>yes, but that's only the bright side.
>
>Also,
>
>-developers are not often paid, so you have to wait until they have
>enough free time

That is true, then again you don't get a good service from
commercial player always either, especially the big ones.

>
>-architecture changes are rare since it requires a lot of time to break
>big
>things and rebuild them

Having seen this from the inside of commercial software developers
I'd say architecture changes maybe even rarer in them. And architecture
change as such does not warm anyone.

>
>-the number of contributors with enough skills and time to be able to dig
>deep
>inside the code of complex projects, and implement things that the main
>developers don't have time for, is not always so large.


Very true.

>
>SDCC is good for z80 and targets that benefited from the new allocator,
>but the
>for example, PIC ones are still broken and generate mostly correct but
>inefficient code. why? because it would require a rewrite and no one can
>do that
>until His Mighty Noodleiness sends a wizard to do it.

Agree about the produced code quality but doubt about the need to rewrite
everything, more likely just needs someone to get down to it, which
is the problem as there is no-one atm with enough time.

> It's just the truth.

Yeah, nothing can be gained by trying to hide the truth.

>
>
>About critical systems, just go back reading the GNU GPL license,
>especially the
>upper-case section.


Hmm, I could not easily find a version with the upper-case section but I
think I know what you refer to.

What are you trying to say with that?

When you are doing critical system (or any systems for that matter) you
don't get any warranties or guarantees from anyone for the quality
of their tools and especially of the code they produce, heck, most if
not all the chips we all use have clause in the data sheet that you
can't use them in critical systems, or words to that effect.

At the end of the day it is the OEM who is responsible for the product,
what ever it is. Both in the eye's of the law and the public/market place.

br Kusti






This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general.