Bye bye Keil 166 and 8051 (??)

On Thu, 03 Nov 2005 14:21:21 -0800 in comp.arch.embedded, Scott Moore wrote: [...]

My experience is a little different.

I don't buy compilers, but my employers do. They don't necessarily want "free," though "cost-effective" is good. And "cost" includes more than the initial purchase price. Indeed, initial purchase price is often one of the smallest costs involved with a tool purchase.

None of my employers has been unwilling to spend money on quality tools. C51 from Keil, for example. They've aso paid good money (sometimes quite a lot of it) for _lousy_ tools. Tools that maybe worked OK, at least at first, but cost more. Perhaps they cost time, effort, gray hair, or whatever, rather than money, but cost all the same. So we care a great deal about quality.

Back when TQM was a new rage, we were told that "quality" was "conformance to requirements." So a quality tool is one that meets my needs. Keil C51 is an example. So is gcc.

Regards, -=Dave

No it means that open source has an advantage because there is a much greater chance of getting those bugs fixed.

Ian

On the contrary I was not suggesting there are not large differences between different compilers, only that the differences are NOT attributable to technology.

Ian

Hello Joep,

Not always. When something goes seriously wrong because of a compiler bug and someone files suit, option 2 may not leave any recourse as there is no manufacturer per se. IOW, depending on your application the risk can be huge.

That is one reason why, for example, medical device mfgs tend to buy domestic power supplies even though they are more expensive.

Regards, Joerg

Dave Hansen wrote On 11/04/05 13:51,:

Read that, quite a long time ago in fact. I also quote it to people.

However, code cleanlyness is a loosing issue. Its like recycling, global warming and peace. Everyone is for it, nobody wants to really work towards it, and everyone assumes the'll be long gone before it really happens.

Me, I think of code quality as a leaky boat. If you bail water, you will never really be done, but if you give up, eventually you will sink.

The "big ball o' mud" theses is correct in the main. Eventually every boat sinks. Sometimes it takes the company with it. Yes, I have seen it happen on more than one occasion.

One can get comercial support for the GNU toolset. So one can get all the "advantages" of a commercial toolset, but still have the source if one really needs it.

Regards Anton Erasmus.

Fallacy. Lawyers go after deep pockets. If the pocket is not there, it is not gone after. If there is one there, it does not mitigate your exposure one whit. The fact that there is litigation hopefully means someone screwed up, and someone is in trouble - maybe. But there's always the misery loves company theory.

Certainly not. The fact that it is open source makes matter worse.

I think Chris was bitten by an open-source dog when he was still a babe in arms.

My experience is exactly the opposite.

When I found bugs in commercial toolchains, I was basically ignored. When I needed additional features in commerical toolchains, I was completely ignored.

When I found a very obscure bug in the ARM backend for gas, it was fixed within 2 hours of reporting. When I needed additional features in the gnu loader, I just spent a couple hours and added them.

In article , larwe writes

No. I have seen many people complain of bugs in compilers when in fact is was their lack of understanding of the language was the problem. Probably 9 out of 10 cases.

Now if these people can fix the "bugs" in open source compilers to what they thing it should do you have a very poor compiler the user thing si perfect.

Especially if the can modify the test suite to take into account their "fix"

I have been informed that the Gnu test suite is not a test suite as such but simply a confidence check that the build has gone OK.

I think he's just a troll. I haven't actually seen him post any useful information, ever. He seems quick to jump on the "GNU sux" or "Open Source Sux" whenever possible, but doesn't really provide any valuable insight.

Case in point: Awhile back someone asked about ARM dev tools and the post goes unanswered for a few days. I follow up and mentioned that the GNU ARM tools are free and an option for the original poster (I didn't claim that the GNU toolset produces the most optimal code, but I did state it was free). Chris Hills then jumps in and tromps all over GNU. I didn't recall seeing him post anything before the mention of GNU...

Everyone agrees that GNU tools have their + and -s. No one is claiming GNU is perfect and/or couldn't use work in a lot of areas. But for many projects they have the right mix of price and features, caveats included.

Regarding Chris Hills, I bet a good number of the websites visits use Apache and a BSD or a Linux there. Some part of everything we do probably touches an OpenSource or GNU influenced product or project through means we may not think about.

So Chris Hills, stop the bullshit GNU trollings and post useful information or go away.

H.

I think you'll find that there is well written open source software, and badly written open source software - and that exactly the same applies to closed source software. Some open source software is written as hacked together code and release "as is", and will often be poorly coded. Other open source code is written with pride, knowing that others will read the code and judge the programmer by it, and is therefore good code. Similarly, some closed source code has careful reviews or is written as a team, forcing structure and well written code, while other closed source is hacked together under time pressure and looks terrible.

That's certainly true - but there is no specific reason to assume that an open source compiler is necessarily worse than a closed source one. Some of the very top end compilers for some targets are noticably better than other compilers - but there are plenty of poor quality compilers available for some targets. Note that I'm talking mainly about generated code quality here - run-time speed and code size. There are many other factors to consider when looking for the "best" compiler for a particular job.

Consider, for example, some compilers for the AVR (since I know these tools, while I have not used the 8051). According to reputation, IAR's compiler produces the very best code, but the compiler is expensive. ImageCraft's compiler is cheap, but has significantly poorer code. avr-gcc is open source, and produces code that is (as far as I have seen) never worse than ImageCraft's, and often a lot better. It's been a while since I have compared IAR's code generator with gcc's - it will be interesting to see which is better with the latest gcc 4.1, but I would certainly not assume IAR's compiler is as much ahead as the difference in price would indicate.

Or look at high-end x86 processors. These days, Intel's own compiler generally wins most benchmarks - but gcc beats it for some code, and is undoubtable closing the gap. Or consider the Microblaize (from Xilinx) and Nios II (from Altera). These are two companies with a great deal of resources, and a great deal of expertise in large closed-source development environments. But when looking for a compiler and IDE for their soft processor cores, both chose to use open-source Eclipse as the IDE, and open-source gcc as the compiler. They chose gcc because they felt that was the best route to getting a high-end compiler for the processors.

I use different compilers for different purposes and different targets. Some compilers are closed-source, although most of my work these days uses gcc. When recommending toolkits to others (customers, colleagues or others), I will sometimes recommend gcc ports, sometimes commercial closed source tools, and sometimes commercial packings of gcc. Personally, I don't see the choice of software as a religious issue, though I do see why some people are fanatical about only using open-source tools. There are good reasons for that - depending on your priorities, they can be the most important reasons. But I fail completely to understand people who are fanatically anti-open-source. Arguing that a particular closed-source commercial tool is better than a particular open-source tool for good, solid, practical reasons is fine - arguing that it must of necessity be better simply because it is commercial is ludicrous.

Regards,

David

The people that actually fix open-source programs as complicated as compilers are not in these 9 out of 10 cases. Have you the slightest idea of what is involved in getting a patch into the gcc tree? To put it mildly, you won't get your patch accepted if you are in that 9 of 10 group. Theoretically, of course, you could download the source, make the change to your own local copy to fix the "bug", and re-compile. In practice, that doesn't happen - people only patch and re-compile if they are very capable, and know the issue is a bug and not a misunderstanding (and in almost all cases, after discussing it with other experts on mailing lists). But if you *are* in that category of expertise, and find a *real* bug, then begin open source, you can do exactly such a patch and re-compile. That way you get the fix immediately, rather than waiting for the next compiler release, as is the normal case for both open and closed source tools.

That may well be the case. If I want to be sure that a particular gcc version passes a particular "standard" conformance test, then I can run that test myself. If I want to be sure that a particular commercial compiler passes such a test, then I *also* have to run the test myself. I suppose there might be a middle-ground, where I want a compiler that I am reasonably confident passes the test, in which case I could take the commercial vendor's word for it. Maybe that suits if you have the attitude that you don't mind if your products work, as long as there is someone else to blame and sue.