Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-1409955 ] incorrectly nested push/pop r0/r1
|
From: SourceForge.net <no...@so...> - 2006-02-15 16:03:30
|
Bugs item #1409955, was opened at 2006-01-19 15:58 Message generated for change (Comment added) made by grasbon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1409955&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: msc51(8051) target Group: fixed >Status: Closed Resolution: Fixed Priority: 5 Submitted By: grasbon (grasbon) Assigned to: Maarten Brock (maartenbrock) Summary: incorrectly nested push/pop r0/r1 Initial Comment: Confused xdatas Version: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.5.4 #1191 (Jan 1 2006) (MINGW32) Call: "sdcc --stack-auto --noinduction Main.c" The following main.c contains a bug difficult to spot. Therefore have a look at the function WriteToXData(), which places two bytes of a given array info byte 0 and 1 of the xdata space. The rest of the main-loop does not make any sense - but we need the stuff because without it, the bug will not appear. So what's the problem? In the main-loop the WriteToXData() is called repeatedly. Normally every time the same thing is done: The values 0xab and 0xcd will be placed into byte 0 und 1 of the xdata space. But this is not work correctly. Sometimes, 0xcd, 0xab will be placed, sometimes correct values 0xab, 0xcd are stored. Here's the Main.c: ------------------------- void WriteToXData(char* buffer) { *((xdata char*)0) = buffer[0]; *((xdata char*)1) = buffer[1]; } void main(void) { char a; xdata char* p; char d[5]; d[0] = 0; d[1] = 0; d[2] = 0; d[3] = 0; d[4] = 0; p = 0; do { if( (unsigned short)p > 10 ) a = 10-(char)p; else a = 60; d[0] = 0xab; d[1] = 0xcd; WriteToXData(d); // Watch the xdata: 0, 1! p += a; } while( p ); d[0] = 1; d[1] = 2; d[2] = 3; d[3] = 4; d[4] = 5; } ------------------------- Greetings, Reimar Grasbon ---------------------------------------------------------------------- >Comment By: grasbon (grasbon) Date: 2006-02-15 17:03 Message: Logged In: YES user_id=1374486 Ooops, youre right ... I'd just downloaded the latest sdcc- version (Win) in the morning and forgot to compare the exact build-numbers. In the #1210, the bug does not longer appear. I'll close this thread now again. Sorry Maarten, Thanks Bernhard, Reimar ---------------------------------------------------------------------- Comment By: Bernhard Held (bernhardheld) Date: 2006-02-15 12:54 Message: Logged In: YES user_id=203539 Reimar, you're using build 1208! Just check the 3. line in your assembler files! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-02-15 12:38 Message: Logged In: YES user_id=888171 Bernhard, For some functions (f.e. genPlus) the freeAsmop calls were not yet in reverse order. I changed that according to your comment. genMult was another one. Am I sure my changes are ok? No. I find it very hard to write a good regression test for this bug. But it did complete all current regression tests without failures. To Reimar: I wondered the same as Bernhard, are you sure you're using #1210 ? Maarten ---------------------------------------------------------------------- Comment By: grasbon (grasbon) Date: 2006-02-15 12:33 Message: Logged In: YES user_id=1374486 Something went wrong at the file attachment. Here's my "main.asm" again. Reimar ---------------------------------------------------------------------- Comment By: Bernhard Held (bernhardheld) Date: 2006-02-15 11:00 Message: Logged In: YES user_id=203539 I'm confused too. I didn't dig into the bug, but I see that the order of freeAsmop calls are again changed. I guess we badly need a regression test for this. If I read my comment to gen.c 1.173 the calls of freeAsmop must be in opposite order than the previous calls of aopOp. It's my fault that I didn't write a regression test at that time :-( This is now broken in e.g. genMult. Are you sure your changes are ok? I reopened the bug just as a remainder for the missing regression test. Reimar: I had a quick look at the assembler and I couldn't find anything unusual. Your file main.asm is not attached. Are you sure you got build #1210 (check in you main.asm)? ---------------------------------------------------------------------- Comment By: grasbon (grasbon) Date: 2006-02-15 09:19 Message: Logged In: YES user_id=1374486 Sorry, but I can not confirm, that this bug is fixed. The swapping of xdata:0 and xdata:1 still occurs. Reimar To see the result of my compilation with "sdcc --stack-auto Main.c" I've attached the main.asm file. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-02-14 20:11 Message: Logged In: YES user_id=888171 Fixed in SDCC 2.5.4 #1210. ---------------------------------------------------------------------- Comment By: Bernhard Held (bernhardheld) Date: 2006-01-20 08:48 Message: Logged In: YES user_id=203539 The pushs and pops of r0, r1 are incorrectly nested. r0 holds &d[0], r1 holds &d[1], this way the contents is exchanged. ;bug-1409955.c:27: p += a; ; genPlus push ar0 ; push r0 mov r0,_bp inc r0 inc r0 push ar1 ; push r1 mov r1,_bp inc r1 mov a,@r1 add a,@r0 mov @r0,a ; Peephole 181 changed mov to clr clr a inc r0 addc a,@r0 mov @r0,a pop ar0 ; pop r0 pop ar1 ; pop r1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1409955&group_id=599 |