From: SourceForge.net <no...@so...> - 2006-03-28 18:09:00
|
Bugs item #1453093, was opened at 2006-03-18 11:40 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1453093&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: None Status: Open Resolution: None Priority: 5 Submitted By: Stas Sergeev (stsp) >Assigned to: Maarten Brock (maartenbrock) Summary: relocation error (peephole) Initial Comment: Hi. The following program (attached) cannot be compiled with the sdcc code from CVS: --- static idata unsigned char f[1]; static unsigned char tst; unsigned char main() { idata unsigned char *ptr = f; while (ptr < f) tst = *ptr++; return tst; } --- $ sdcc ptrbug.c ?ASxxxx-Error-<r> in line 137 of ptrbug.asm <r> relocation error removing ptrbug.rel ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2006-03-28 20:08 Message: Logged In: YES user_id=888171 I'm sorry. I already wrote a fix like b) but I must have forgotten to commit it. I'll test it again this evening and commit. ---------------------------------------------------------------------- Comment By: Stas Sergeev (stsp) Date: 2006-03-28 20:08 Message: Logged In: YES user_id=501371 > causes the relocation error "mov a,#0x100 - _f" Yes, but why is this a problem? From my (rather ignorant in that area) point of view, #(_f + 20) is not too much different from #(0x100 - _f). Since the offset of _f is constant, why the '-' sign makes it invalid? ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2006-03-28 20:07 Message: Logged In: YES user_id=1160854 The replaced lines should use %1 and %2 in the sequence like the original ones. At peepholes d / e / f "%1" and "%2" are changed. It should work too, that's right - but it causes the bug... ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-03-28 19:26 Message: Logged In: YES user_id=589052 > Could you please clarify/confirm that its a peephole's > fault? I am quite ignorant about that asm semantic, but > I suspect that maybe an assembler is really guilty here? The problem with peephole 132.e was that it was applied to a symbol (resulting in a negative sign before a symbol, which causes the relocation error "mov a,#0x100 - _f") > and perhaps it would be better to leave this bug > open for now? If it is closed, then it is likely > to never be properly addressed. :( You're right - reopened. There are probably three approaches to address it (in the order of my preference) : a) modifying genCMP that it includes the tricks of 132.a-e, b) introduce an additional Peephole condition checking for non_symbols, c) remove 132.a-d (most likely an overkill as SDCC probably doesn't generate code which would match the peephole AND is using a symbol). ---------------------------------------------------------------------- Comment By: Stas Sergeev (stsp) Date: 2006-03-28 18:57 Message: Logged In: YES user_id=501371 > fixed with SDCC version #1230 by disabling peephole 132.e Could you please clarify/confirm that its a peephole's fault? I am quite ignorant about that asm semantic, but I suspect that maybe an assembler is really guilty here? > Note: peepholes 132.a-d are still lurking there. Exactly - thats what I did locally too, but thats the problem, and perhaps it would be better to leave this bug open for now? If it is closed, then it is likely to never be properly addressed. :( > Ideally the > optimizations of rules 132.x should be done in genCmpXX But are you sure that the assembler should not be fixed instead? ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-03-28 08:37 Message: Logged In: YES user_id=589052 fixed with SDCC version #1230 by disabling peephole 132.e Note: peepholes 132.a-d are still lurking there. Ideally the optimizations of rules 132.x should be done in genCmpXX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1453093&group_id=599 |