| ??? 10/27/11 16:47 Read: times |
#184394 - as I've said before, where you sit determines what you see Responding to: ???'s previous message |
Per Westermark said:
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. That's only true if the evaluation compiler puts the code where it can actually run on the target. That is, after all, the issue that initiated this discussion. When I evaluate code quality, I do not need to build a full system. Nor do I. 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. The "spin cycle" is not an issue for me. After all, I've suggested one might actually "spin" the code with several compilers in order to compare the output's suitability for a specific task. I don't have a lot of experience with that, since I generally use ASM rather than HLL. That's not what some people prefer, however. 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. A one-week delay isn't the point. My clients, for example, seldom produce more than a dozen units. Yes, once in a while I do something that actually goes into volume production, but, mostly, it's one or two units and a few spares. That makes it hard to justify a compiler. That's why I prefer ASM. Bit-banging because code is fast enough? I don't think you have really looked at the code produced from high-end compilers. That's true. I've only looked at what the demo packages produce. 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. Nobody's discussing "ARM-class" processors at this point. I know ARM would like to supplant the 805x's but there are places where they'll NEVER fit. Almost all of my 805x's were designed and built back in the '70's and early '80's. They have 40-pin DIP-packaged MCU's, into which, at one stage or another, I've upgraded with a faster MCU, increased the code size, extended the hardware, and done so by means of a daughterboard living on that original 8751/8752 socket. That's why I don't generally use I2C, SPI, etc. 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? I'm not sure optimization is the issue. Compilers from different vendors produce code that runs at different rates, uses differing volumes of code space, uses more or fewer resources ... In the end, you are seeing problems that doesn't normally exist. There's the key ... Normally ... but, again, isn't that why this topic came up? 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. I have no evidence to the contrary. I doubt that's quite as common as you probably believe. You can't blame people for wanting free tools, but I certainly wouldn't expect anyone to distribute a work-product that took years to complete at no cost to the recipient if the original intent was to sell it. 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. After being repeatedly lied-to by the KEIL people, not to suggest they're the only ones, and probably as much out of ignorance as out of evil intent, I've nearly given up on trying to deal with software vendors. Because, from what I've seen, compilers seldom produce code that's as tight and as quick as what I can do with ASM, I've not spent much time, recently, trying to justify using HLL's with MCU coding. I have, more as mental-masturbation than for practical reasons, but also to try to inform myself, made some cursory comparisons between various compilers, and that has not only supported the notion that ASM produces code that I like better, for both size and performance reasons, and it has shown that different compilers produce differences in code volume and performance. No one compiler seems to have the clear advantage in this regard, though some certainly have the user interface polished. RE |
