If Optimize 8 (Reuse Common Entry Code) detects void MyFunc() as the last statement within void OuterFunc() (for example), it will produce an LJMP to MyFunc() rather than an LCALL. (see examples) Nice optimization, but MyFunc() is part of a library written in assembly and by design reuqires a call rather than a jump. I tried surrounding its prototype with a #pragma OT (7), but that doesn't work. Surrounding OuterFunc() with the OT (7) pragma works, but that's a bit cumbersome and runs the risk of someone forgetting to do it.
void OuterFunc( void ) { MyFunc(); // Compiler generates LJMP. Not good :o( } #pragma OT (7) void OuterFunc( void ) { MyFunc(); // Compiler now generates the necessary // LCALL, but programmers WILL forget to use // this construct and will blow the whistle // when their software bombs. } #pragma OT (8)
make the compiler believe there is more code But that's not what your hack does --- there's no make-believe involved: there is more code after the sub-function call. The macro you wrap that in is just window-dressing. But even so, I rest less than convinced that a function like your JmpInd a) should fail if it's jumped to instead of called --- the only difference is in stack contents it has no business meddling with, even given the job it wants to do b) is any more elegant or easier to use than a function pointer
"But that's not what your hack does --- there's no make-believe involved: there is more code after the sub-function call. The macro you wrap that in is just window-dressing." The above sort of nit-picking reminds me why I don't visit this board very often. You can ALWAYS count on this sort of reply here...ALWAYS. "...the only difference is in stack contents it has no business meddling with, even given the job it wants to do" Who says? If the stack contents and the associate SP sfr are so off-limits and taboo, then why have both been accessible since the inception of the 8051 and, for that matter, still accessible to C51 itself? b) is any more elegant or easier to use than a function pointer Quote from Keil C51 User's Guide 09.2001, pg 379: "Function pointers are one of the most difficult aspects of C to understand and to properly utilize. Most problems involving function pointers are caused by improper declaration of the function pointer, improper assignment, and improper dereferencing."