From: Joris v. d. S. <vd...@pu...> - 2000-11-24 21:58:11
|
Hi, I feel embarrassed about the many bugs I have reported lately. Please understand that I appreciate all the work done, and that I enjoy using SDCC every day. However, now that I am very busy writing the first draft of the ROSES project, I happen to stumble across a lot of bugs related to the --xstack option. I was already warned that this option has not been tested very thoroughly, so consider me a beta-tester and please don't feel offended by the bug reports... [1] Invalid entry-code for ISR ------------------------------ If I compile a program using the --xstack option (and --model- small --stack-auto), that contains the following ISR: void rtos_clk_isr(void) interrupt TF1_VECTOR { /* some code */ } then SDCC will generate the following entry-code: 4503 358 _rtos_clk_isr: 4503 C0 E0 359 push acc 4505 C0 F0 360 push b 4507 C0 82 361 push dpl 4509 C0 83 362 push dph 450B C0 02 363 push ar2 450D C0 03 364 push ar3 450F C0 04 365 push ar4 4511 C0 D0 366 push psw 4513 75 D0 00 367 mov psw,#0x00 4516 A8 36 368 mov r0,_spx 4518 E5 35 369 mov a,_bp 451A F2 370 movx @r0,a 451B 05 36 371 inc _spx 451D 85 36 35 372 mov _bp,_spx 373 ; rtos_clk.c 124 ; here starts the first line of the ISR The problem here is that 'r0' is *not* saved. This causes system crashes at random moments, because 'r0' can change at random moments. I can't work around this bug, since whatever I put at the start of my ISR, it ends up at line 374 which is too late. [2] Compiler crashes at function call in ISR -------------------------------------------- Before giving me a RTFM, I am aware of the following line in the manual: "Calling other functions from an interrupt service routine is not recommended avoid it if possible." However, I need to split certain ISRs in a device-dependent and a device- independent part, which implies the device-dependent ISR will call the generic ISR. To be on the safe side, I have used a void-function for the generic ISR. Here is the prototype: void my_generic_isr(void) reentrant ; However, if I insert a call to this function in the device- dependent ISR, SDCC crashes *during compilation* with a general protection fault! I have also read the following line in the manual: "Note that when some function is called from an interrupt service routine it should be preceded by a #pragma NOOVERLAY (if it is not reentrant).", and tried it (although the function _is_ reentrant), but this doesn't help. I have improvised the following work-around: A = (unsigned int)my_generic_isr & 0xFF ; B = (((unsigned int)my_generic_isr) >> 8) & 0xFF ; _asm push acc push b ret _endasm ; This works, but it is of course something that should be looked at some day. [3] Typedef'd enumeration ------------------------- I have reported this bug some time ago, but just to make this summary complete I will list it again. The following code does not work: /* the following code would normally be in a header file */ typedef enum { OK = 0, WRONG = -1 } ERR ; extern ERR my_func(char foo) ; /* this would normally be in a .C file */ ERR my_func(char foo) { char bar ; bar = foo + 1 ; return OK ; } void main(void) { /* compiler gives 'too many parameters' error here?! */ my_func('A') ; } The workaround is splitting the typedef and the enumeration: enum err_t { OK = 0 WRONG = -1 } ; typedef enum err_t ERR ; [4] Sources in multiple directories ----------------------------------- This is not really a bug, but would greatly simply building the project. I wanted to split the project I am working on into several subdirectories. However, SDCC is unable to compile files that are not in the current directory. SDCC generates labels in the output .ASM file that hold the path and filename of the source file. For example: sdcc -c mydir/foo.c creates the file 'mydir/foo.asm' which contains labels such as: C$mydir/foo.c$15$1$1 ==. However, ASX8051 seems to choke on slashes in labels. Would it be possible to add some extra code to the label generation routine to convert illegal character such as slashes or backslashes into other characters that are legal in .ASM labels? That way, I could use a single makefile to build my project. [5] Compiler crashes when building the ANSI C libraries ------------------------------------------------------- I seem to be unable to build the libraries using the '--stack- auto' option. For example, the following will crash the compiler: sdcc --model-small --xstack --stack-auto -c _atoi.c \ -I../include Again, please don't be offended by this bug list, I'm only reporting these bugs because I assume that you --the development team--, are helped by receiving feedback from users. I was able to work around most bugs, but until bug [1] gets fixed, I can't create a working RTOS. Regards, Joris van der Sande vd...@pu... |