| ??? 10/29/11 23:39 Read: times |
#184437 - Can _you_ not read debugger output? Responding to: ???'s previous message |
Richard Erlacher said:
Yes, I can imagine ... That would leave no way at all for a person to get any picture at all of what sort of code the compiler produces, though, wouldn't it? Any person who can't look at the disassembled instructions in the debugger and see if the code is good or bad is incompetent and would not manage to decide with an assembler listing either. Are you saying that you are unable to figure out if code is good or bad from the debugger window? As an alternative, they could make it possible to run their code on the desired target. They've chosen not to do the latter, haven't they? The majority of processors out there are based on very few cores. So with 99+ percent probability, you can test the code on a processor with more code space. Since the limitation is in amount of generated code, and not in max size of flash memory, you should even be able to run the simulator with the specific processor, but with the description of the processor modified to claim more code memory available. Wouldn't the rest of the software still prevent the practical use in a commercial sense? After all, who wants to generate two linkable objects of each module, run them through his own linker, and only then load them into the target. Further, that would still leave the miscreant without the ability to use the simulator and some of the other "features", would it not? You blame Keil for having a large hole in the code map. If they didn't had such a code window, there would not be any need for two linkable objects. So without the hole in the code map, there would be zero incentive to buy the commercial edition. Was that hard to figure out? Really? Is the demo linker the only "protection" that KEIL has built into their demo package? I had the impression that there were other features that also didn't work on larger code bodies and limited the location in the memory map. You can find out yourself. But mainly, you have a gap in the emitted code space, and a limit to the amount of code linked and debugged (ignoring the size of the hole). And you don't have access to their floating-point library. And you have to look at the assembler instructions in the debugger - no assembly listing, since it would be too easy to take the assembly listing and post-process to glue together multiple lists into a full-size binary. As I said before, I suspect that those who are smart, skilled, and diligent enough to do what I suggested have already thought of it themselves, or, much more likely, those bent on stealing someone else's work product are too lazy to do all that work just to be able to load a small code snipped into their target. So why are you suggesting things that you think skilled people already knows about? Don't you realize that you are also telling the slightly less skilled people things they shouldn't be told? So Richard: Out with it in clear text. Do you think it is correct to talk about licence circumvention? Yes or no? After all, there are other KEIL features that don't work outside the demo range. I suspect there are other things that KEIL could do if they really wanted to (a) enable people evaluating their product for a specific purpose or use in a chip not presently supported by their linker, but that they have simply chosen not to do that. The result is that all one in that situation can evaluate is their GUI. You don't need Keil support to build binaries for processors not in Keils database. You can add your own processors. Real people who are evaluating their tools don't see too much problems. Why do you? You aren't even interested in C compilers... |
