[sdcc-devel] [ sdcc-Bugs-3515677 ] [PIC16] Bad TBLRD code generated?

[SourceForge.net <no...@so...>]

Bugs item #3515677, was opened at 2012-04-07 04:48
Message generated for change (Comment added) made by tecodev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3515677&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pic16 target
>Group: fixed
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Diego Herranz (diegoherranz)
Assigned to: Raphael Neider (tecodev)
Summary:  [PIC16] Bad TBLRD code generated?

Initial Comment:
Hi!

Compiling this simple code, I get an error running on simulators when PC reachs address 0x2EA:

 - On Proteus VSM I get the following error: Address for TBLRD*+ instruction (0x003FFBCC) is not a valid configuration address. 
 - On PIC Simulator IDE, the simulator crashes.


Some info:

	SDCC command: sdcc --use-non-free -mpic16 -p18f4550 test.c
	SDCC version: SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.4 #7538 (Apr  6 2012) (Linux). It also happens with 3.1.0.


Don't know if it's a compiler error or if I'm doing something wrong.

Thanks a lot.

----------------------------------------------------------------------

>Comment By: Raphael Neider (tecodev)
Date: 2012-04-14 10:56

Message:
Fixed in SDCC r7587.

----------------------------------------------------------------------

Comment By: Raphael Neider (tecodev)
Date: 2012-04-14 03:44

Message:
This is a bug in the pic16 implementation of signed 8x8->16 bit
multiplication code generation: The result overwrites the operand (in
r0x00) before the operand's sign is checked in the fix-up phase (BTFSC
after MULLW).
I have prepared a fix and will commit it later today.
Thank you for the report.

----------------------------------------------------------------------

Comment By: Diego Herranz (diegoherranz)
Date: 2012-04-11 03:37

Message:
Again after more research:

The array is declared like this uint8_t font5x7[95][5]={...}
So, if you want to access to font5x7[2][3] (for example), it does 5x2 + 3 =
13 and it's like reading font5x7[13].

The assembler instructions that I didn't understand are there because this
multiplication is signed.
I think that it is signed because I do the following subtraction font5x7[
character - ' ' ][...] and there is a promotion to signed int before
subtracting. Right?

Doing this:

uint8_t index = charachter - ' ';
font5x7[index][...]

seems to work because it's doing an unsigned multiplication. 

Anyway, even if its signed, I think that the result should be OK. Why is it
wrong? I can't see the problem.

Thank you very much.

----------------------------------------------------------------------

Comment By: Diego Herranz (diegoherranz)
Date: 2012-04-08 12:09

Message:
After some research on the .lst file:


- font5x7['H'-' '][0] generates a TBLRD to address 0x0000CC which is OK.

- getColumnFont5x7('H', 0) generates an invalid address for TBLRD because
there are two conditional instructions which in my humble (and
inexperienced) opinion are wrong:

[...]
0002b0   0e05     movlw	0x5                	MOVLW	0x05
----> 0002b2   be00     btfsc	0, 0x7, 0          	BTFSC	r0x00, 7 ; I don't
know why this is needed
----> 0002b4   5ef4     subwf	0xf4, 0x1, 0       	SUBWF	PRODH, F
0002b6   cff4     movff	0xff4, 0x2         	MOVFF	PRODH, r0x02
0002b8   f002
0002ba   6a03     clrf	0x3, 0              	CLRF	r0x03
----> 0002bc   be02     btfsc	0x2, 0x7, 0        	BTFSC	r0x02, 7  ; I don't
know why this is needed
----> 0002be   6803     setf	0x3, 0              	SETF	r0x03
0002c0   0e04     movlw	0x4                	MOVLW	LOW(_font5x7)
[...]

Thanks a lot

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3515677&group_id=599