I believe you see a boogieman behind every bush. You must be in league with the software vendors.

I think it's much, Much, MUCH worse for a software vendor to publish a work product that is not in every testable way absolutely perfect, even if they fix it later, than for a couple of dozen thieves to steal their product in the way you describe every day.


The guy who wrote "Pretty Good Solitaire" seems to have figured it out just fine. Others have too. That's a really fine set of solitaire games that has brought amusement to lots of folks, yet doesn't cost much. I'm not a game player, but my mother was. She liked the thing.


Just what has PC programming to do with the subject at hand? MCU programmers should know, understand, and be able to simulate precisely the behaviors of the MCU they're using. If their compiler doesn't do that to the nearest clock cycle, it's rubbish!



First of all, writing a dispatch loop in ASM produces a VERY short (fewer than a dozen bytes) bit of very fast code, and I don't know from day to day what a compiler will do with it. A multilevel dispatch loop uses multiple tables, one for each level. If you have up to 16 input bytes, then it will need at least 16 tables, possibly many more, depending on how many branches in the dispatch decision tree, but generally speaking they're all pretty much the same length in time. If each of those is 256 bytes long, i.e. has 128 jump addresses, that's quite a bit of code space. With a teensy processor core like 805x, where you have a small stack, you don't want to chew up stack space with calls. Moreover, you don't want to chew up the time, either.

Now, is there a KEIL version with 4kB of code support that runs on non-SiLabs MCU's? Is there a simulator from KEIL that produces precise and correct oscillator cycle counts when external memory accesses available on, say, the DS89C4x0's are involved, with external memory cycle counts variable due to software? As you can see ... they really only support the "classic" model timing. Do you still use that? It's no different with other compiler vendors. That makes the simulator essentially useless.

Actually, you can't TEST anything in a simulator. All you can do is count cycles and hope the hardware resolves the signal propagation. You can't really TEST anything in a debugger, either, since the debugger doesn't run at the oscillator rate, as it has to stop for you to trace, modify, or whatever.

ASM allows you to specify precisely what will happen. If you can write the program in ASM, you can understand what's going on because there's no compiler to shelter you from your own ingorance, which is what many people want, and there's no compiler to hide what's going on, either. Once you've written it in ASM, you already know where the problems are likely to occur, and can focus on those interactions that may prove troublesome. In HLL, you won't even see them. Sometimes, I guess, that's a good thing. It prevents you from knowing how nearly you've failed.

RE