That seems like a very odd argument, that someone who has been here a lot should be able to fount conventions while someone new must toe the line. Is that what you are really saying?
Personally I think this entire discussion is a bit absurd. I've been using newsgroups for around 10 years and I have come to the realization that this is a bit like the wild west. There may be some conventions, but mostly people do what they will as much as they aren't shot. I think calling someone out on top posting is a bit like asking them not to spit in the gutter. It may seem a bit crude or otherwise undesirable by some while it doesn't bother others at all. Either way, there is not much point in asking them to stop. It's not at all like them spitting in your living room where you would have every right to tell them that was not a proper thing to do.
But calling someone out about calling someone out about top posting is pretty much the same. This guy who insists on "correcting" people to educate them about "correct" behavior is being condescending and many people would consider that rude. But he knows what he is doing, he knows how others feel about it and there is no point to trying to get him to stop.
It is also very likely that my stating all this is also pointless, but just like everyone else in this discussion, it is not so much about what I expect to change, but rather it is just a way to express myself and even a bit of a lack of self control when I see things I find absurd. Consider this my contribution to the absurdity of this thread.
Well, I don't want to get in the middle of professionals in this area. But your opinion isn't universally held and you may remember your own discussion with Paul here:
formatting link
I suppose this will just have to remain "unsettled" in my own mind, for now. I respect both of you a great deal.
It was MS sponsored (since it was "good" FUD against Linux), but I think it was SCO's new boss's idea.
Of course, the other possibility for why it is rarely done is that valuable copyrighted code rarely ends up in serious open source projects without the owner's permission - major open source projects are very careful about who contributes and where the code comes from.
I'm sure there are lots of cases of sections of copyrighted code ending up in open source code under a different license (the typical example being an extract from a book or website), but only in rare cases is it worth pursuing that sort of infringement.
And for balance, there is no difference here between closed-source code and open source code - let he who has not copied from a book into their code without checking the license throw the first stone. Open source simply makes it easier to see the code.
Most of the major gcc contributors are paid to contribute to gcc - they work for companies like Intel, Red Hat, IBM, Freescale, Code Sourcery, etc. It's part of their job. The same applies, more or less, to many major open source projects.
For those with other programming jobs, it makes sense to clarify the position with your employer before contributing to open source projects (or doing any other sort of programming). Only a truly foolish employer would object (assuming, of course, that the free-time programming did not compete with the employer, and that it does not in other ways affect his job).
Unless the employer can reasonably claim disloyalty in the employee, he'd have a very hard job trying to get a court's backing in any claims over copyright ownership. He might stand a good chance if the employee was making money from the extra programming, but not if he is giving the code away as open source.
However, IANAL, and it is best to get permission in advance rather than fight about it later.
In fact, this is the whole concept behind the GPL.
Correct.
This is the point of the GPL. It means that a GPL project can only die through lack of interest - not because the owner decides to stop making or selling the code. It means that once the code is released, it will always be available as long as someone has a copy. And it also means that the code in question can be modified or re-used regardless of the copyright owner's wishes. The copyright owner will often own trademarks on the name and logo, which will need to be changed by anyone distributing the code, but that's not a big deal.
Consider embedded compilers as an example. We know that ByteCraft puts a lot of effort into making sure that customers can get old versions of their software if needed. But supposing IAR makes a hostile takeover of ByteCraft, fires Walter Banks, and kills off ByteCraft's 6808 compiler tools because they compete with IAR's own tools. An old user of ByteCraft's 6808 compiler then wants to get an extra license for their old version - IAR refuses. Another user has found a bug, and would like ByteCraft to fix it and give or sell them an update - again, IAR refuses. Customers are stuck, despite ByteCraft's best intentions, and no matter how much money the customer is willing to pay.
For comparison, supposing IAR buys the FSF and now owns the copyrights of gcc. They stop distributing gcc sources, and re-license everything with a proprietary license and sell the binaries. The next week you'd find the website fcc.sourceforge.net hosting the "free compiler collection" tools based on the last GPL'ed gcc sources with a name change. And as an avr-gcc user, even if no one else worked on the gcc source, I'd still be able to modify it and improve it myself. If I didn't have the expertise (or the time!), I could pay someone else to do it.
*That* is the protection and insurance you get from open source software, that you cannot get from closed source software. The two scenarios above are highly unlikely, but they are possible - and similar things have happened with other pieces of software.
This post also has a link to miBench which has grown up considerably in the last couple years. MiBench is application code that can be used to benchmark competing implementations.
Thanks. That was 2004 for the benchmark on GCC. Roughly 5 years ago. And on the MSP430 back then. I'm not sure how new the processor was at that point (but at least two years in terms of general availability, I think) or how much effort had been supplied in working through issues with GCC. You now make me wonder how things may have changed in that regard.
I also note that you wrote that "GCC ... is also not the universal answer" -- which is something I completely agree with. Neither commercial, nor the FSF approach, is a panacea. It's good (to me) that there exists new options, though.
However, while you made some of the same points then that you are making now, it does seem now that you are adding some new ones.
Specifically, that the impact of GNU c is simultaneously stunting art advancing innovation _and_ standards development. At that time, you hadn't added quite such strong accusations to the pile.
Jon
P.S. While I looked for C99 vs C90 discussion in your reference, I only found a comment about a URL having failed to demonstrate that GCC had been tested against C99 _at that time_. Which doesn't tell me that it hadn't been tested then, because a URL's failure does not demonstrate GCC failure. Nor does it tell me if that has been done since. And worse, it says nothing whatsoever about Paul's comments regarding C99 as a standard, in and of itself. Separate subject.
So I still remain curious and unsettled, I suppose.
A couple of minor points about that test of msp430 gcc referenced in the linked post - first, compilation was done with -O1 "which generates the smallest code". The correct optimisation flag for generating the smallest code (in general) is -Os. For multiplier-intensive code, there are other flags that can make a big difference (controlling interrupt flag and multiplier interaction). I've no idea whether that would be significant or not in this case - it often does, though not by the margins needed to beat the other compilers in the test. Secondly, msp430-gcc is a very poor representative of gcc - it is not part of the FSF tree, and is based on gcc 3.2, which was two years old at the time of the post. The msp430-gcc developers have not had the time or motivation to switch to a more modern gcc base (they are happy with their current base, and prioritise stability over performance with their limited time budget).
A more useful comparison for gcc on small devices would be to use avr-gcc and compare it to other compilers. Of course, that could be a little difficult - commercial compilers often have EULA clauses specifically banning any publication of benchmarks or comparisons without explicit consent (I understand why - it's easy to accidentally put a tool in a bad light, such as by using -O1 instead of -Os).
Walter (and also Chris) are very concerned with *language* test suites. gcc has a *functional* test suite (checking that the code generated gives the expected outputs), with many of the tests being regression tests (testing explicitly with code that was known to be problematic in the past). For most users, who are primarily interested in using the compiler to compile sensible source code to object code, this covers what they need - they want to generate correct code from their source.
The other sort of testing applied to compilers is language test suites, such as Plum Hall and Perennial. These test the conformance of the compiler to the standards. There is no doubt that running these sorts of tests are useful - as well as finding non-compliances with the language standards, they can be useful for finding obscure bugs. But I wouldn't expect gcc or any other embedded compiler to pass these tests completely - if nothing else, then extensions needed for embedded work will cause failures. And gcc has many other extensions (most are disabled in "pedantic" ansi mode, but you want to do your testing in modes that are typically used, which have the extensions enabled) - a test suite should complain about things like "asm" statements, non-standard "inline" linkage (pre gcc 4.3), or "0b1011" constants.
The other big problem with tests like these is the licensing terms involved, and the pricing, that do not fit well with an open source development model. It is important for gcc's development model that all its tests are part of the distributable source code - you can build and run the test suite as part of the compilation process (as we all know, you have to test against the compiler build you are using). Clearly, that's not going to happen with tools like Plum Hall. Even among the key gcc developers, the developers are very much spread out - each would need licenses to the tools, and the restrictions on publicising test results goes against the development model. Plum Hall etc., are ideal for small, dedicated commercial compiler development groups - but far from practical for open source compiler development.
Having said that, people *do* run these sorts of suites on gcc. I know that CodeSourcery uses one or more such suite, and results from the testing are used to improve the development of gcc by fixing (or at least identifying) non-conformances or other bugs that are found. I expect that other commercial groups within gcc development (IBM, Intel, Red Hat, etc.) make use of such tools in a similar way. But if you want validation, or certification, then you have to license the tools yourself and do your own validation (I expect some gcc users will do this).
As does every other commercials compiler company I know.
Not likely. I don't want to go into details but IAR have supplied old version of compilers where they did not develop the original version. Subsequent versions were pure IAR
It has nothing to do with Bytecraft at that point.
This is the same with ALL compilers.... bugs are fixed in the next version. You do not go and patch an old version for a specific bug and reissue that old compiler
After many years of tech support one thing I do know is that the vast majority of customers have no idea of what is a bug and what isn't.
More to the pint even with the source could they could not safely fix the bug. That is a FACT. They most certainly do not have the knowledge or resources to regression test the compiler.
OK.
Yes and the point is? However do you have all the tests suites for the compiler? GCC does not have anything like the same level of test suites for either the language or the functional testing that commercial compilers have
SO at the end of it you have a non-standard untested C-like compiler.
Sorry having just supplied customers with old version of compilers that are 5 and 18 (yes EIGHTEEN) years old from commercial companies your argument does not stack up. (Now I think of it I have supplied old versions from 5 commercial companies)
More to the point the old compilers were EXACTLY the same as they were
5 and 18 years ago. You can NOT do that starting with the source now.
Compiling now with a modern compiler an 18 year old set of source will not give you the same compiler.
SO you are saying with GCC you can make a non-standard, un-tested C- like compiler which may or may not behave the same as the one you wanted that does not have the "bug" you notices but you have no real idea what else you have changed....
And the advantages over a tested commercial compiler are?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
I did survey most of the professional compiler companies (over 20) for their views on C90 and C99. The majority said that they were moving to C99 but not all of it was relevant for embedded. I believe that the ISO WG may drop some of the contentious stuff in C1x
However as Walter has a good view of the standards and other compiler companies... most do talk to each other *I would back his view.
Several are in this thread. A lot more are lurking :-) AFAIK Walter and Paul are the only two commercial compiler writers who post under their own names here.
BTW when are you going to publish your Keil-SDCC results?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Lurking is fair enough - it's a useful way for a company to gauge opinions - but posting under assumed names or without revealing your connection with a particular product (when relevant to the thread, obviously) is downright deceitful. People like Walter, and yourself, gain a great deal of respect because you are clear and unambiguous about where you stand. There are few things more pitiful than company employees posting fake comments as "satisfied users".
Of course, unless you are in a position to speak for your company, it's important to have a "these are my own views, not my company's" disclaimer. If a poster makes it clear that they have connections with a particular compiler (or whatever is under discussion), they make it clear to everyone what biases they might have, and also that they speak with more authority than the average user.
I know it's not likely - it's a hypothetical example using familiar companies.
True - but the customer wants the "ByteCraft" compiler, not an "IAR" compiler (regardless of the name of the company selling it).
Actually, you *do* patch old versions - it's called "product lifetime management", or whatever the fashionable term is these days. You gradually reduce the level of patching or fixing done on older versions as they are phased out.
True, but irrelevant to the example.
Again, you are making the mistake of thinking "officially tested but known bad" being automatically better than "not officially tested, but fixed". How the user judges the seriousness of the bug and the risks of breaking something else when fixing it (and the time and cost of fixing it) is up to the user and the project in question.
Sometimes this is like talking to a child with his fingers in his ears, saying "Blah, blah, blah - I'm not listening. gcc doesn't use a language test suite, ha ha ha!".
I believe you already mentioned the lack of official independent language testing with published verifications and results.
A buggy compiler is non-standard, untested (or at least inadequately tested) and merely "C-like". So what exactly have you lost?
And yes, you *do* have all the standard test suites for your gcc compiler - these test suites are open source. They are mostly included with the source tarball, and any other relevant tests are available from the same sources.
And if you want to run Plum Hall or whatever, you are free to buy a license and test it yourself.
First off, having the source code does not preclude you from keeping the binaries - you can keep and reuse gcc compiler binaries as long as you want (both the cross-compiler binaries, and the native compiler used to compile the cross-compiler). Secondly, you can get the source for the old version of the compiler, compile it, then use it to compiler your cross-compiler. At some point you've got to stop this "it's not the same compiler if it's not the same binary" nonsense and accept that source code can be compiled with a different compiler and still have the same functionality.
Secondly, you could take the source code for your 18 year old version of your commercial compiler, and compile it with a modern compiler. Then you run your beloved test suites on it to check that it works as expected. It does not matter if the exact binary image is not the same as that of the original 18 year old compiler binary, since it is
*functionally* the same compiler. Given the same customer source code, it will produce the same output. Unless, of course, your commercial compiler's test suites are not good enough to trust.
Have you ever done any programming, or looked at any source code, or done any debugging? Are you aware of what programmers *do* for a living? Do you understand the concept of finding and fixing bugs in existing code? Do you actually understand the concept of testing, especially regression testing, or is it just something you like to pontificate about?
Obviously those were rhetorical questions - the point is that programmers can fix bugs in compilers just like in any other program. Just like any other bug fixing, there are questions of expertise, efficient use of time, and so on. But in the case of gcc, remember that this is open source code - it has been viewed and edited by a great many people over a long period of time. There are some parts that are pretty hairy, and few people understand - but most is reasonably accessible and there are a great many developers who have experience working with it and are ready to help or advise. It is not remotely like trying to get to grips with the source code of typical commercial closed-source programs.
The advantage of a tested commercial compiler is that you can pay money and rely on the supplier to provide testing, fixes, updates, support, improvements, new licenses, old versions, etc. The disadvantage is that you have no choice but to rely on the supplier for this service.
With open source compilers, you can do it yourself (if you want, or if no one else will), you can rely on the developers (clearly you will only rely on a compiler with an active group of developers), you can pay a support company (such as Code Sourcery, or another commercial supplier of open source software) for the service, or you can even pay individual developers to do the work for you.
Which is the most appropriate model for a given developer, company, and project will vary. You have to balance what you feel are the costs and benefits of the alternatives available - there is no one-size-fits-all answer.
Not at all given the stupidity of many posters here. Also they may want to post personal opinions which may or may not reflect their company's opinion.
Thanks. However both of us own our own companies. DO you speak for West Controls?
That is pitiful and AFAIK none do. I know because I do know who most of the company men are.
Even so companies may not let you post using a works email address.
However does everyone else. There are a lot more bias and connections other than working for a company or selling a particular brand. Many of these connections and bias's are far more insidious.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
1 I have not over the last 20 years seen that may users who actually understand the language well enough to recognise a compiler bug. I have seen may who claim bugs because it is not the way some other compiler does it. Which is not the same thing as a language bug.
2 Who are these hired hands who have access to a full set of test suites for the compiler? Any fool can "fix a bug" but introduce several others.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
That's what "it's my own opinion" disclaimers are for (although that's the default, I think, unless you explicitly state that it's your employer's position).
No, but I'm not discussing anything that is relevant to WestControl as a company. If I were, I'd state my connection either with a disclaimer or after getting permission from my company. As my employer is irrelevant here, you can find it by looking at my posting address if you want. (Actually, that only applies to some of my posts such as this lunchtime ramble. Many of my posts are from my home.)
That's good - although ordinary readers have no way of telling (and I doubt even you and Walter know all such anonymous "company me" and all their aliases). It certainly happens in other branches - to pick everyone's favourite example, Microsoft is well known for its armies of astroturfers. And I have seen such behaviour on occasion in this group, though not regarding compilers or development tools.
Absolutely true, of course. But it's nice to be open and honest about biases when possible.
I understand the reasons why some of these "company men", as you call them, might want to post under aliases. I still don't think it's right, and posting explicitly would certainly increase my respect for them and their companies - regardless of whether or not I agreed with the contents of their post.
You fix an old version 1 and call the new version 2 when you get to version 11 you don't go back and fix a bug in version 1. No one does that as it is a pointless exercise because you haven't fixed any other bugs in V1 that V2 fixed.
No it's is VERY relevant to the example. These "bugs" you want fixed are probably not bugs at all.
Sorry you are wrong. I am comparing officially tested and known faults against possibly fixed but possibly not with other possible faults or may be not but also possibly with some new faults thay may have been introduced (or not) during the "fixing" (or gratuitous incompatibility installation) of the original issue.
I now case you know what it will and wont do. I the other case you have no idea at all. What is more to the point you have no real idea if it was fixed.
They have nothing to judge it against as there is no proper testing. On one side you have a whole load of testing and on the other blind hope.
Quite or any other test suite worth having. So it is an untested compiler.
No I didn't You did. There are several independent language test suites. There are also other compiler testing tools. The results are available and I have seen them. They are just not freely available in the GCC sense. It's not my problem that the rest of the world does not want to you your rules. IT works for everyone else.
That the GCC is several orders of magnitude less standard and less tested.
They are also a joke compared to the ones used by real compilers for proper testing.
Quite so and that is the benchmark used by the rest of the world. It IS the required standard. Making up your own rules and refusing to play by those is fine until up have to stand up in court.
What are you going to say? We did not like the way the professionals did it so we invented a far lower standard for our selves? The Courts will eat you alive.
You mean you are going to have to stop the denial? This has been argued before it does not wash. Ask any safety critical expert. You are only looking VERY superficially.
Quite a lot... mainly on high reliability and safety critical stuff.
Programmers or SW Engineers?
Yes. Done that.
Yes done that. Which is why I know GCC is weak in this area.
Yes.
Yes
Quite. However I suspect that we mean for very different reasons
Yes
Not that that seems to be a problem for many. Especially those who buy GCC compilers and support. The point here is that the GCC compilers they get like that are not the same as other GCC compilers they are all different. SO you have the same problem as being locked to a supplier.
Yes.. Which is a complete waste of time and money .. I am not bad a t woodwork. I can make my own desk whilst I am at it.
This changes a lot. Some versions have an active team this month and are dead a few months later. This got mentioned Re splint. Apparently that has been dead for a couple of years (which says a lot about the FOSS community)
SO yet again you are locked into a supplier as their version will be different to anyone else's and of course untested
Quite one wants cost effective and tested tools and the other wants untested tools
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
It gets to be a grey area on the Internet. Many jurisdictions etc The only people who get rich on it are lawyers.
If your company does any SW it is relevant as your views on testing or in this case the lack of a requirement for properly tested tools could be detrimental to your company... an extreme view but you know solicitors :-(
BTW what is the legal status of posts to a newsgroup?
How many work from home these days? IT is becoming more prevent in the UK In the close I live in half work from home. They were thinking of having lunch time barbecues in the summer :-)
This is true.
A bit more difficult on this NG I would have thought. It is a bit more obvious when asking for chip recommendations.
Yes.
Their companies won't let them use company addresses. They can speak freely under an alias. Not only do you not know who they work for, neither does the company.
They want the freedom to speak freely. The average marketing department would go berserk if they were in any way not completely pro the company
Beside they start some interesting threads... like this one :-) and no it was not me.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
If the bug is in gcc (sorry if that was not clear in my message), then there are many people people familiar with the code base.
The test suites are publicly available. Whether they are of succient quality and quantity to be useful, I don't know, but they have been good enough to bring gcc to the point where it is now.
So what is the take home message? That all the people in the Far East who thought they can get an unfair advantage by using open source software (and not contributing back) are in for a nasty surprise? That would be rather good news to people doing embedded work in the West. As far as I understand it would also be the complete antithesis of the subject of this thread.
Fortunately, I don't know solicitors! I am lucky enough to live in a country where you have to have good grounds for bringing a lawsuit against someone, and where you can defend a lawsuit reasonably cheaply and get compensation for your costs. We don't have the problem of big companies suing little guy automatically winning because the little guy can't afford to defend himself. So there will be no lawyers involved here unless there is very good reason.
Having said that, I don't know the legal status of posts here. I guess it's the same as any other public speech - you are free to say what you want, you can't be assumed to be speaking for another person or body unless you explicitly state that you are doing so, and you must be careful about making defamatory comments.
I think hiding from their employer when making comments relevant to that employer is far riskier than being explicit. This would be especially true if you were publishing negative comments about your company - doing so anonymously would put you in a very bad light.
I'm not sure how to describe the average marketing department politely - they don't often seem to be on the same side as their engineers and technical staff (that doesn't apply to the WestControl marketing department, obviously :-)
That's odd. I though you were in the UK. If you are in the UK and you believe what you just wrote then you are not living in reality,.
You would like to think that but where would a law suite over comments mad "here" be adjudicated?
I am not sure anyone really does. The law is on the side of those with the money That is because there will be a lot of (very expensive) legal wrangling over it.
In which jurisdiction. UK, China, Koreas (which), USA, Guatemala?
It depends. If you wanted a full and open discussion on compiler optimisation and benchmarks it might be better, especially for IP, not to say which company you worked for.
:-)
:-)))
Short story. In one episode of MASH they captured some POW's from "the North" including a Doctor. They decided that it was a waste to send him to a POW camp when he could help in the Operating theatre. The man was a Doctor first and an enemy solider a long way second.
So they went to Radar and asked him how you could "help some one on the other side?"
With out blinking Radar asked "why would you want to help a storeman? " :-)
Now.. back to Marketing departments and the need for Engineers to sometimes use aliases when discussing topics related to their work.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.