Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-1865114 ] Relative jump calculation with dot offset
|
From: SourceForge.net <no...@so...> - 2008-01-19 12:04:44
|
Bugs item #1865114, was opened at 2008-01-06 16:02 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1865114&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: assembler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Laszlo BORTEL (bortel) Assigned to: Maarten Brock (maartenbrock) Summary: Relative jump calculation with dot offset Initial Comment: When using the dot symbol to generate relative jump without a label, the assembler produces strange result. Assembly source: sjmp .+3 sjmp .+2 sjmp .+1 sjmp . sjmp .-1 sjmp .-2 sjmp .-3 sjmp .-4 sjmp .-5 lbl1: sjmp lbl1 sjmp lbl2 lbl2: Command to assemble: asx8051 -glos BugReport17.asm Assembled result: ASxxxx Assembler V01.70 + NoICE + SDCC mods + Flat24 Feb-1999 (Intel 8051), page 1. 0000 80 02 1 sjmp .+3 0002 80 01 2 sjmp .+2 0004 80 00 3 sjmp .+1 0006 80 FE 4 sjmp . 0008 80 FE 5 sjmp .-1 000A 80 FD 6 sjmp .-2 000C 80 FC 7 sjmp .-3 000E 80 FB 8 sjmp .-4 0010 80 FA 9 sjmp .-5 0012 10 lbl1: 0012 80 FE 11 sjmp lbl1 0014 80 00 12 sjmp lbl2 0016 13 lbl2: It is strange that 'sjmp .' and 'sjmp .-1' produce the same offset. Instead of the result above I would expect the following: 0000 80 01 1 sjmp .+3 0002 80 00 2 sjmp .+2 0004 80 FF 3 sjmp .+1 0006 80 FE 4 sjmp . 0008 80 FD 5 sjmp .-1 000A 80 FC 6 sjmp .-2 000C 80 FB 7 sjmp .-3 000E 80 FA 8 sjmp .-4 0010 80 F9 9 sjmp .-5 0012 10 lbl1: 0012 80 FE 11 sjmp lbl1 0014 80 00 12 sjmp lbl2 0016 13 lbl2: Is this special behaviour intentional or a bug? If it is intentional, what is the rationale behind? ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2008-01-19 13:04 Message: Logged In: YES user_id=888171 Originator: NO Borut, I think I have nailed it and am running regression tests now. It was in all relative jump cases (BITBR, BR, CJNE, DJNZ). The problem I think is the order of outab(op) and expr(&e1,0). The expression must be evaluated before dot.s_addr is changed by outab(). The problem with the corrupted ib pointer happens on only one linux machine. I'm running the tests on another one right now and that does not show this behaviour. I don't know why yet. Maarten ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2008-01-19 12:53 Message: Logged In: YES user_id=568035 Originator: NO Laszlo and Maarten, are you sure that the line v1 = e1.e_addr - dot.s_addr - 2; is correct? The regression test on Linux failed on my machine too. Then I tried with the line: v1 = e1.e_addr - dot.s_addr - 1; and regtests ran without problems. I also dared to take a look into the latest asxxxx package and the line is as the one I wrote. There are similar cases for S_BITBR and S_CJNE. Borut ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2008-01-18 00:57 Message: Logged In: YES user_id=888171 Originator: NO Laszlo, I agree with your analysis. I found this place and several others too. However when I change it, it seems to work on windows but completely fails on linux. The regression tests time out and the .lst files look like garbage. Something fishy is going on with the global variable ib. When the assembler enters list() the variable suddenly changes its value, though a gdb watchpoint does not catch it. Can any of the more experienced linux developers help me? Maarten ---------------------------------------------------------------------- Comment By: Laszlo BORTEL (bortel) Date: 2008-01-11 11:25 Message: Logged In: YES user_id=1063737 Originator: YES I think that I have identified the cause of this strange behaviour in the following file: sdcc\as\mcs51\i51mch.c case S_BR: /* Relative branch */ outab(op); expr(&e1, 0); if (e1.e_base.e_ap == NULL || e1.e_base.e_ap == dot.s_area) { if ( e1.e_addr == dot.s_addr) v1 = -2; else v1 = e1.e_addr - dot.s_addr - 1; if (pass == 2 && ((v1 < -128) || (v1 > 127))) aerr(); outab(v1); } else { outrb(&e1, R_PCR); } if (e1.e_mode != S_USER) rerr(); break; So it seems that someone has intentionally distinguished the relative jump looping back to the same address (sjmp .) and other cases. For me it seems unnecessary, so I would apply the following correction: case S_BR: /* Relative branch */ outab(op); expr(&e1, 0); if (e1.e_base.e_ap == NULL || e1.e_base.e_ap == dot.s_area) { v1 = e1.e_addr - dot.s_addr - 2; if (pass == 2 && ((v1 < -128) || (v1 > 127))) aerr(); outab(v1); } else { outrb(&e1, R_PCR); } if (e1.e_mode != S_USER) rerr(); break; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1865114&group_id=599 |