| ??? 10/27/11 15:57 Read: times |
#184391 - Wait a minute ... You've got this wrong ... Responding to: ???'s previous message |
Per Westermark said:
Most manufacturers releases evaluation versions at the same time as their full-version compilers. So they are up-to-date.
Next - I would not want to try to evaluate a product (i.e. compare with other manufacturers tools) by trying to break through the evaluation tool limitations. Besides taking much too much time, it would not be relevant for a real comparison. The only reason for doing this kind of work, would be to cheat the manufacturer of the money for a commercial version of the tool. Nobody's trying to cheat the manufacturer out of anything. By up-to-date, I mean supporting the available chips that it's theoretically supposed to support. If I buy a compiler that supports some chips in the 805x series, one of the first things I look for is whether it supports the one that I'm currently planning to use. When I say "up-to-date" I mean supporting the currently available technology, and not just the ones to which the software vendor has "gotten around" to including in the compiler's repertoire. That, of course has little to do with the specific limitation that I was suggesting could be circumvented. It would not be difficult to write the linker in the eval package such that it would produce runnable code in any region of the code memory space without removing that 2kB or 4kB size restriction. Some vendors simply haven't bothered. If a serious evaluation requires unlimited tools, then it would be much better to contact the manufacturer and request a special demo build. Maybe a time-limited version with a hardware lock. Or maybe contact a company close-by that have the commercial version, and have them build a full-size project. It doesn't require unlimited tools, per se. It does require that the code for evaluation be runnable on all the available targets. If a compiler costing as much as the one under discussion claims to support 805x chips, it should fully support all of them. If the demo package doesn't allow "limited" trial on any member of the 805x family, for example, it should clearly say so in the documentation of the evaluation package. Some vendors simply don't bother. Next thing is that most people do not go through life wondering about past decisions. When a decision is made, it is made. Only when there is a reason for a new decision would it be meaningful to spend time reevaluating known facts. Living life in past tense don't build any future. You either use the tools you have, or you get new ones. Thinking about what tools you _could_ have used will not improve the code quality or speed up the delivery times. You're right, with the exception that, particularly in cases such as mine, a decision has to be made in conjunction with each project. I don't advocate defeating the demonstration limits for the purpose of producing deliverable work product. I do think it's worth considering such an approach if a timely evaluation for use with a chip that presently doesn't have a memory map that will function trivially with the demo as it's provided. KEIL, unlike SDCC, thinks that "the next release", when the desired IC will be supported, can happen two years later, which won't meet anybody's current need. There are other matters, also dealing with simple omissions by the compiler vendor(s) but those can be discussed under a separate heading. RE |
