Hi Raphael, 2007/11/8, Raphael Neider <[EMAIL PROTECTED]>: > Hi Alan, > > Sorry for having ported the wrong version; I just googled for picos and > found that one... >
Don't worry, your port help me too. > Yes, this is a bug... Unused (or ones used only in inline assembly > fragment and thus effectively hidden from the compiler) extern > declarations are discarded; as a consequence, they do not appear in the > .asm file as EXTERN SYMBOL nor EXTERN _SYMBOL and hence cannot be > resolved by the assembler. Sigh... > Sure, before using your workaround I tested just placing this symbols at generated .asm and it was assembled fine. Also placing the internal registers at "Equates to used internal registers" solve the internal register problem. Maybe if the preprocessor start analyzing the used symbols (extern functions and internal registers) into _asm/_endasm; block this problem can be solved. Just my 2cts, I don't understand about compiler internals. > The really bad workaround is to effectively access the symbols in c: > extern void _kernel(void); > with _kernel being only referenced in _asm ... _endasm; blocks such as > _asm goto _kernel _endasm; > should (for now) be rewritten as > extern kernel; // Note: SDCC mangles this into _kernel > static void *k = &kernel; // WORKAROUND SDCC BUG > Work fine now! ;-) > As I said, the workaround is really bad: It is both a maintenance > nightmare and even costs memory space at runtime! I really need to look > into a way of emitting even unused externs... > Yes, I verified SDCC only declares symbols used in pure C, if this symbols are used in assembly code only it is discarded. > Assembler symbols with no leading underscore need to be rewritten in the > defining .asm (or better .S) file to have a leading underscore if they > are to be accessed from C (which includes all symbols that need the > above workaround): > > global tsk_1_stack > tsk_1_stack res 15 > global great_function > great_function: > return > > becomes > global _tsk_1_stack > _tsk_1_stack res 15 > global _great_function > _great_function: > All right, really these functions are defined prefixed by underscore at kernel.S (formally kernel.asm) > Alternatively one might introduce an option for SDCC not to add a > leading underscore to user-defined symbols, probably risking name > clashes with compiler-defined symbols... > I think it is not a big problem, but solving it make possible the portability among MPLAB C18 and SDCC codes. > Regards, Thanks for you useful help and explanation! > Raphael > Alan ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
