Do you seriously believe that those who'd steal a product if it were sufficiently difficult to get past the time-limiting features would ever buy the product? If they steal it, it's no loss in sales. The vendor hasn't lost a dime! OTOH, if even one prospective customer finds, after evaluating the product, finds it is what he wants, not because he's been stampeded into it, but because he's actually determined that product XYZ is more suited to his purpose than ABC, then the vendor makes a sale.

Yes, there are people out there who create "cracks" just as there are people out there who create virus and other types of malware. Nothing will ever get rid of them. However, if KEIL, IAR, or others have a million copies of their software "out there" not being used by the folks who cracked it, and crackers seldom actually use the products they steal, Keil, IAR, etc, haven't lost a dime! The guys who would buy a "cracked" package seldom benefit, as the cracks are seldom without undesirable and generally catastrophic side-effects. That's why I don't know anyone who uses 'em.


Nobody said anything about "a time limit you can tamper with." If the software guys can't figure out how to prevent such tampering, they get what they deserve.


I just used that as an example. The price isn't the issue. I don't know how hard it would be to bypass the time-lock. However, as I said earlier, if the software guys can't do that such that it's not easy to "crack" then they get what they deserve.


It's not "hard" but it is time-consuming and burdensome, and much more so when applied to the output from a compiler. Cycle counting isn't the only valuable thing, you know. It's just of particular interest to me.


It's not the compiler that does that, but many compiler packages include a simulator/debugger. That's what does the cycle counting. Some don't, of course. I associate them simply because in the cases where they're included, it's unlikely one would buy the package without the simulator. It's a valuable function, particularly with the sort of impenetrably twisted code that the compiler spits out. That code isn't necessarily bad, but it's hard for humans to follow unless they have a very clear understanding of exactly what that compiler does.



When I write ASM, I'm acutely aware of how long code segments take, and even include the cycle counts in the comments. In some cases, with MCU's that can change cycle lengths and memory access modes dynamically, e.g. the SiLabs and Maxim/Dallas one-clockers, the timing can vary considerably depending on the context from which a given code segment is instantiated. What's needed, I guess, is a REAL simulator.

RE