Hello,
I found that using --stack-auto when (re)compiling sdcclib for needed
reetrancy (as manual recommends) can break int (and long)
multiplication in "user" code when interrupts are on.
And not only int/long, libmath too.
Looks like an "empty" ISR (which has only a prologue and epilogue) has
impact on _mulint result and using simple code:
volatile int x;
int main(){
while(1){
x=100;
x=x*x; // <x becomes not 10000 when ISR is active
}
When I disable interrupts at the end of _mulint reentrant code:
[...]
BCF _INTCONbits,7
MOVFF PREINC1, r0x09
MOVFF PREINC1, r0x08
MOVFF PREINC1, r0x07
MOVFF PREINC1, r0x06
MOVFF PREINC1, r0x05
MOVFF PREINC1, r0x04
MOVFF PREINC1, r0x03
MOVFF PREINC1, r0x02
MOVFF PREINC1, r0x01
MOVFF PREINC1, r0x00
MOVWF POSTINC1
MOVLW 0x05
ADDWF FSR1L, F
BTFSC STATUS, 0
INCF FSR1H, F
COMF WREG, F
MOVF PLUSW1, W
MOVFF PREINC1, FSR2L
BSF _INTCONbits,7
RETURN
and reenable interrupts before return seems to temporary fix the
problem, but I'm pretty sure that this isn't a correct way to fix it.
Becouse --stack-auto won't work correctly on pic16 port is there any
other way to get full reentrant sdcc support library? Disabling
interrupts before any integer mul/div operation
is a real pain...
regards,
Marico
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
