| ??? 10/27/11 09:32 Read: times |
#184387 - Wrong view on evaluation tools Responding to: ???'s previous message |
Richard Erlacher said:
What about the guy who simply wants to evaluate the product? He probably does want to see the GUI, and some of the "features." Mainly, though, I'd guess, he wants to see how efficient a code body is produced by the compiler, i.e. how much slower and/or larger the output is. How efficiently it produces the same construct as a competing product. It is trivial to evaluate the code quality within 4kB. When I evaluate code quality, I do not need to build a full system. 20 years ago, it was important to know the slowdown of the development tools based on the size of the project. It was common to get a one-hour spin cycle for changing a couple of lines, recompile, link and download. Today, that really isn't a problem. I do not need to know if I can get 10 seconds or 30 seconds spin cycle - people who do care about that spin time are doing it wrong. They are changing a sign in an expression and testing. Then changing something else and testing. Even if I sell 100k units, the amount of time to evaluate the tools still matter a lot. Why? Because if I expect to sell 100k units/year, I expect to sell 2k units every week. So one week slower evaluation means one week later product release and a loss of sales of 2k units - that is 2%. It isn't likely that two top-of-the-line compilers have so big difference that selecting B instead of A would matter enough to regain a one-week delay in shipping. Bit-banging because code is fast enough? I don't think you have really looked at the code produced from high-end compilers. If using ARM-class processors, basically "all" compilers are fast enough, if just the processor is fast enough. If there is a problem, then the critical code sequence is so small that it is trivial to write in assembler. But even more importantly - the critical part of code is likely to contain lots if GPIO accesses, where there is a one-to-one between source lines and hardware accesses. Exactly how can a compiler fail when there isn't anything to optimize? In the end, you are seeing problems that doesn't normally exist. Erik has said he'd "borrow" a full version when he had a likely sale, but it's clear that these vendors don't really want someone to make a rigorous comparison and buy on the basis of what best suits a particular application. Sorry, but totally bull. 1) The majority of people downloading evaluation software do not want to evaluate. They want free tools. 2) The majority of situations where you do want to evaluate, you do not need more than the evaluation version can do. Or you are doing the evaluation wrong. 3) A real company can manage a lot when contacting the suppliers directly. |
