 |
 |
| View previous topic :: View next topic |
| Author |
Message |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
| More PCD coding errors |
 Posted: Sun Oct 12, 2008 12:14 pm |
 |
|
Hello,
after resizing an UART transmit buffer, involving an int16 buffer and an int16 buffer pointer, I experienced printf() stuck in an endless loop. The below assembly list snippet shows why:
| Code: | void _putc4(BYTE c)
{
01B54: MOV W5,[W15++]
01B56: MOV W6,[W15++]
.................... WORD ni;
.................... STraBuf4[STraNextIn4] = make16(0,c);
01B58: MOV 1B74,W4
01B5A: MUL.UU W4,#2,W0 ; writes to W1, too !
01B5C: MOV #1974,W4
01B5E: ADD W0,W4,W5
01B60: MOV.B 1C99,W0L
01B62: MOV.B W0L,[W5]
01B64: MOV.B #0,W0L
01B66: MOV.B W0L,[W5+#1]
; calling function
.................... printf(_putc4,"Some text");
01D2A: MOV #0,W1 ; W1 is used as string index
01D2C: MOV W1,W0
01D2E: CALL 1042
01D32: INC W1,W1
01D34: MOV.B W0L,1C99
01D36: CALL 1B54 ; W1 is cleared on return !
01D3A: MOV #7,W0
01D3C: CPSGT W1,W0
01D3E: BRA 1D2C |
I'm not sure about the default PCD strategy in work register usage, but I guess, that PCD assumes W1 to be untouched in the called _putc4 function, missing that the register is used by mul.uu for the result high word. The bad thing with this bug is, that it can't be avoided by a simple systematic means.
I tried different #separate variants with _putc4(), but they seem to have no effect in this case.
I'm presently using PCD 4.079, but the bug isn't listed in the changes history.
Another, more simple bug appears in comparing an int8 and int16 variable:
| Code: | else if (value != dt)
0372C: MOV.B 1C74,W0L ; int8, W0H is undefined!
0372E: CP 1C76 ; int16
03730: BRA Z,3788 |
An additional typecast can be a workaround, but it's clearly required by the C-standard to be performed automatically
| Code: | else if (value != (int8)dt)
0372C: MOV.B 1C74,W0L
0372E: CP.B 1C76
03730: BRA Z,3788 |
Regards,
Frank |
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sun Oct 12, 2008 1:35 pm |
|
|
And another one from the road
here PCD mixes up target and destination in a copy
| Code: | if (STraNextIn4 != STraNextOut4 && (STraBuf4[STraNextOut4] >> 8) == mstic)
00D42: MOV.B 1973,W0L
00D44: CP.B 1B74
00D46: BRA Z,D62
00D48: MOV.B 1B74,W0L
00D4A: CLR.B 1
00D4C: SL W0,#1,W0
00D4E: MOV #1974,W4
00D50: ADD W0,W4,W0
00D52: MOV [W0],W5
00D54: MOV.B W0L,B ; should be MOV.B B,W0L !!
00D56: MOV.B W0L,W6L
00D58: CLR.B D
00D5A: MOV 1B78,W4
00D5C: CP W4,W6
00D5E: BRA NZ,D62 |
|
|
|
Ttelmah
Guest
|
|
| Posted: Mon Oct 13, 2008 2:15 am |
|
|
Report them to CCS.
Read the comment at the top of the page, about this forum.
Most people here, 'know', that CCS, releases code that is not even a good 'alpha' when it first comes out, and don't even try to use things for several months. For myself, I'd leave it a year, before really trusting CCS stuff. Unfortunately, this means that PCD is still going to show a lot of problems, but the best way to get them dealt with, is to report them ASAP. Unfortunately, until the bugs are reported, CCS will tend to not notice them themselves.
Best Wishes |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Mon Oct 13, 2008 12:43 pm |
|
|
Thanks for the suggestion. I basically know, that this isn't the offcial CCS support address. Cause CCS isn't providing a detailed and transparent bug list, I'm giving the information mainly for other users. When I report a bug at the forum, I have most likely found a workaround. A bugfix in the next version doesn't help me for the present project anyway.
As another point: CCS software developers have to decide themselves, if they notice information given in the forum discussion. Unlike me, they are paid for improving the product.
Regards,
Frank |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Sat Nov 01, 2008 3:37 pm |
|
|
I too am starting to find problems with incorrectly constructed code that I've sent into CCS and am still waiting for fixes --- on the timelines of weeks now.
I have a project completely stalled out waiting for these fixes. My customer isn't interested in paying me to fix/work-around compiler problems. So I have to work on other things in the meantime.
No so fabulous.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sun Nov 02, 2008 2:16 am |
|
|
Considering the number of pending PCD bugfixes, coming V4.082 seems to be somewhat delayed.
Fortunately, I was able to complete a first release of my PCD application, despite the various bugs.
Now I tried to add RFC 1321 CHAP algorithm and experienced the limits of workarounds. I got not less than 20 instances of the below erroneous usage of working registers. You have to rewrite most occurances of pointer->int32var in the code, to avoid the bug.
| Code: | 02334: MOV 1890,W0
02336: MOV #0,W4 ; sets W0 as destination, can't work
02338: MOV [W0++],[W4++] ; W0 gets overwritten
0233A: MOV [W0++],[W4++] ; high chance of ADDRERR trap |
Hopefully it's fixed in V4.082.
"I speak of none but the computer that is to come after me!" (Deep Thought in Douglas Adams Hitchhikers Guide to the Galaxy) |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sun Nov 02, 2008 1:34 pm |
|
|
| I was finally able to implement the MD5 code. Unfortunately, I found two new PCD bugs on the way. It's amazing. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
