From: SourceForge.net <no...@so...> - 2011-04-26 22:38:28
|
Bugs item #3293371, was opened at 2011-04-26 23:38 Message generated for change (Tracker Item Submitted) made by u6c87 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-05-04 19:46:33
|
Bugs item #3293371, was opened at 2011-04-27 00:38 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 21:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-05-05 08:53:46
|
Bugs item #3293371, was opened at 2011-04-26 23:38 Message generated for change (Comment added) made by u6c87 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 09:53 Message: >From my point of view it was academic interest. Given the limited scope of this, and the severe brokenness on z80 (combined with the increase in both code size and execution time), I would have to conclude that nobody is actually using it, and it's probably better to simply remove it. Having an "omit-frame-pointer" option would probably make sense on architectures where there is a dedicated stack pointer register which can be used for indexed operations (like x86 and SPARC) and thus omitting the frame pointer can free up another register. This certainly isn't the case on Z80 (I can't say for the other architectures that SDCC supports), so I'd be happy just dropping the option completely. I can't believe anybody else is actually using it given the broken code it generates! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 20:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-05-05 09:11:25
|
Bugs item #3293371, was opened at 2011-04-27 00:38 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:11 Message: Sorry, but IMO we still need this. AFAIR it worked somehow not too long ago. --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. Unfortunately some OS designers have made the bad choice of reserving ix for OS or interrupt routine use, thus applciations meant to be run under these OS are not allowed to touch ix (it'S similar for iy, that's why I introduced --reserve-regs-iy some time ago). Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 10:53 Message: >From my point of view it was academic interest. Given the limited scope of this, and the severe brokenness on z80 (combined with the increase in both code size and execution time), I would have to conclude that nobody is actually using it, and it's probably better to simply remove it. Having an "omit-frame-pointer" option would probably make sense on architectures where there is a dedicated stack pointer register which can be used for indexed operations (like x86 and SPARC) and thus omitting the frame pointer can free up another register. This certainly isn't the case on Z80 (I can't say for the other architectures that SDCC supports), so I'd be happy just dropping the option completely. I can't believe anybody else is actually using it given the broken code it generates! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 21:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-05-05 09:19:43
|
Bugs item #3293371, was opened at 2011-04-27 00:38 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:19 Message: This bug seems to have been at least partially fixed in the optralloc branch some time ago (at least I cannot reproduce it with a small example, such as the one the OP gave). However many (about one in twenty or so) regression tests fail when when using --fomit-frame-pointer. I remember that the z88dk folks were experimenting with using sdcc as their underlying compiler some time ago. AFAIR they used --fomit-frame-pointer and got some applications to work. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:11 Message: Sorry, but IMO we still need this. AFAIR it worked somehow not too long ago. --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. Unfortunately some OS designers have made the bad choice of reserving ix for OS or interrupt routine use, thus applciations meant to be run under these OS are not allowed to touch ix (it'S similar for iy, that's why I introduced --reserve-regs-iy some time ago). Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 10:53 Message: >From my point of view it was academic interest. Given the limited scope of this, and the severe brokenness on z80 (combined with the increase in both code size and execution time), I would have to conclude that nobody is actually using it, and it's probably better to simply remove it. Having an "omit-frame-pointer" option would probably make sense on architectures where there is a dedicated stack pointer register which can be used for indexed operations (like x86 and SPARC) and thus omitting the frame pointer can free up another register. This certainly isn't the case on Z80 (I can't say for the other architectures that SDCC supports), so I'd be happy just dropping the option completely. I can't believe anybody else is actually using it given the broken code it generates! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 21:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-05-05 10:13:42
|
Bugs item #3293371, was opened at 2011-04-27 00:38 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2011-05-05 12:13 Message: > --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. I assume you mean IX here. optralloc gen.c:4105 if(!_G.omitFramePtr) is half of the fix. But gen.c:4116 emit2 ("!enterx", sym->stack); also needs to be fixed IMHO with if (_G.omitFramePtr) emit2 ("!ldaspsp", -sym->stack); else emit2 ("!enterx", sym->stack); As well as gen.c:4119 emit2 ("!enter"); if (!_G.omitFramePtr) emit2 ("!enter"); Then gen.c:2371 (aopGet) else should be else if (_G.omitFramePtr) { setupPair (PAIR_IX, aop, offset); dbuf_tprintf (&dbuf, "!*ixx", offset); } else Then with these fixes many regression tests fail and the first one (addsub) destroys HL in testAdd() for result += 0xab00; Brian, you're wrong here in describing the use case. The Z80 uses IX as frame pointer and this CAN be used for other indexed actions, so it could make sense to have this option. So, Philipp, shall I commit these changes even though it fixes only half the problem? ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:19 Message: This bug seems to have been at least partially fixed in the optralloc branch some time ago (at least I cannot reproduce it with a small example, such as the one the OP gave). However many (about one in twenty or so) regression tests fail when when using --fomit-frame-pointer. I remember that the z88dk folks were experimenting with using sdcc as their underlying compiler some time ago. AFAIR they used --fomit-frame-pointer and got some applications to work. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:11 Message: Sorry, but IMO we still need this. AFAIR it worked somehow not too long ago. --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. Unfortunately some OS designers have made the bad choice of reserving ix for OS or interrupt routine use, thus applciations meant to be run under these OS are not allowed to touch ix (it'S similar for iy, that's why I introduced --reserve-regs-iy some time ago). Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 10:53 Message: >From my point of view it was academic interest. Given the limited scope of this, and the severe brokenness on z80 (combined with the increase in both code size and execution time), I would have to conclude that nobody is actually using it, and it's probably better to simply remove it. Having an "omit-frame-pointer" option would probably make sense on architectures where there is a dedicated stack pointer register which can be used for indexed operations (like x86 and SPARC) and thus omitting the frame pointer can free up another register. This certainly isn't the case on Z80 (I can't say for the other architectures that SDCC supports), so I'd be happy just dropping the option completely. I can't believe anybody else is actually using it given the broken code it generates! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 21:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-05-05 11:22:00
|
Bugs item #3293371, was opened at 2011-04-26 23:38 Message generated for change (Comment added) made by u6c87 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 12:21 Message: > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: , on x86, you can read directly from the %rsp+offset if you wanted to, so you can dispense with setting up %rbp as the frame and use it for something else. On Z80, you cannot do this with sp directly, hence use of the ix register. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-05 11:13 Message: > --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. I assume you mean IX here. optralloc gen.c:4105 if(!_G.omitFramePtr) is half of the fix. But gen.c:4116 emit2 ("!enterx", sym->stack); also needs to be fixed IMHO with if (_G.omitFramePtr) emit2 ("!ldaspsp", -sym->stack); else emit2 ("!enterx", sym->stack); As well as gen.c:4119 emit2 ("!enter"); if (!_G.omitFramePtr) emit2 ("!enter"); Then gen.c:2371 (aopGet) else should be else if (_G.omitFramePtr) { setupPair (PAIR_IX, aop, offset); dbuf_tprintf (&dbuf, "!*ixx", offset); } else Then with these fixes many regression tests fail and the first one (addsub) destroys HL in testAdd() for result += 0xab00; Brian, you're wrong here in describing the use case. The Z80 uses IX as frame pointer and this CAN be used for other indexed actions, so it could make sense to have this option. So, Philipp, shall I commit these changes even though it fixes only half the problem? ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 10:19 Message: This bug seems to have been at least partially fixed in the optralloc branch some time ago (at least I cannot reproduce it with a small example, such as the one the OP gave). However many (about one in twenty or so) regression tests fail when when using --fomit-frame-pointer. I remember that the z88dk folks were experimenting with using sdcc as their underlying compiler some time ago. AFAIR they used --fomit-frame-pointer and got some applications to work. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 10:11 Message: Sorry, but IMO we still need this. AFAIR it worked somehow not too long ago. --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. Unfortunately some OS designers have made the bad choice of reserving ix for OS or interrupt routine use, thus applciations meant to be run under these OS are not allowed to touch ix (it'S similar for iy, that's why I introduced --reserve-regs-iy some time ago). Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 09:53 Message: >From my point of view it was academic interest. Given the limited scope of this, and the severe brokenness on z80 (combined with the increase in both code size and execution time), I would have to conclude that nobody is actually using it, and it's probably better to simply remove it. Having an "omit-frame-pointer" option would probably make sense on architectures where there is a dedicated stack pointer register which can be used for indexed operations (like x86 and SPARC) and thus omitting the frame pointer can free up another register. This certainly isn't the case on Z80 (I can't say for the other architectures that SDCC supports), so I'd be happy just dropping the option completely. I can't believe anybody else is actually using it given the broken code it generates! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 20:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-05-05 11:36:18
|
Bugs item #3293371, was opened at 2011-04-26 23:38 Message generated for change (Comment added) made by u6c87 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 12:36 Message: [Sorry about the previous post - a stray mouse click sent it prematurely ] > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: On other architectures (I'm familiar with SPARC and the AMD64 ABI), there are two registers set aside for stack (%sp/%rsp) and frame (%fp/%rbp) pointers. As all of these registers can be used to read from memory with a supplied offset. Thus it's and relatively trivial for the compiler to re-write "ldx [%fp-0x7e7], %g3" as "ldx [%sp+XXX], %g3" where XXX is the current frame size minus 0x7e7. Thus an "--fomit-frame-pointer" option makes no difference to the compiled code or execution time. On the Z80, we cannot use the %sp register this way, so re-writing "ld a, -5(ix)" becomes non-trivial and space/time consuming. So from my point of view, I cannot see the usefulness of disabling the frame pointer. That was my point, not that %ix cannot be used as an indexed register. Actually, SDCC's creation and use of a frame pointer is the one thing that drew me to sdcc when I was looking for a Z80 cross-compiler last year. I personally can't imagine running without one, except perhaps for the smallest, most trivial functions (at the possible expense of being able to build up a stack trace later...) If there are others who would make use of it, then by all means fix it. That's fine by me. ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 12:21 Message: > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: , on x86, you can read directly from the %rsp+offset if you wanted to, so you can dispense with setting up %rbp as the frame and use it for something else. On Z80, you cannot do this with sp directly, hence use of the ix register. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-05 11:13 Message: > --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. I assume you mean IX here. optralloc gen.c:4105 if(!_G.omitFramePtr) is half of the fix. But gen.c:4116 emit2 ("!enterx", sym->stack); also needs to be fixed IMHO with if (_G.omitFramePtr) emit2 ("!ldaspsp", -sym->stack); else emit2 ("!enterx", sym->stack); As well as gen.c:4119 emit2 ("!enter"); if (!_G.omitFramePtr) emit2 ("!enter"); Then gen.c:2371 (aopGet) else should be else if (_G.omitFramePtr) { setupPair (PAIR_IX, aop, offset); dbuf_tprintf (&dbuf, "!*ixx", offset); } else Then with these fixes many regression tests fail and the first one (addsub) destroys HL in testAdd() for result += 0xab00; Brian, you're wrong here in describing the use case. The Z80 uses IX as frame pointer and this CAN be used for other indexed actions, so it could make sense to have this option. So, Philipp, shall I commit these changes even though it fixes only half the problem? ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 10:19 Message: This bug seems to have been at least partially fixed in the optralloc branch some time ago (at least I cannot reproduce it with a small example, such as the one the OP gave). However many (about one in twenty or so) regression tests fail when when using --fomit-frame-pointer. I remember that the z88dk folks were experimenting with using sdcc as their underlying compiler some time ago. AFAIR they used --fomit-frame-pointer and got some applications to work. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 10:11 Message: Sorry, but IMO we still need this. AFAIR it worked somehow not too long ago. --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. Unfortunately some OS designers have made the bad choice of reserving ix for OS or interrupt routine use, thus applciations meant to be run under these OS are not allowed to touch ix (it'S similar for iy, that's why I introduced --reserve-regs-iy some time ago). Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 09:53 Message: >From my point of view it was academic interest. Given the limited scope of this, and the severe brokenness on z80 (combined with the increase in both code size and execution time), I would have to conclude that nobody is actually using it, and it's probably better to simply remove it. Having an "omit-frame-pointer" option would probably make sense on architectures where there is a dedicated stack pointer register which can be used for indexed operations (like x86 and SPARC) and thus omitting the frame pointer can free up another register. This certainly isn't the case on Z80 (I can't say for the other architectures that SDCC supports), so I'd be happy just dropping the option completely. I can't believe anybody else is actually using it given the broken code it generates! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 20:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-05-06 11:35:34
|
Bugs item #3293371, was opened at 2011-04-27 00:38 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2011-05-06 13:35 Message: Yes, please commit your fixes. The register allcoation issues that become observable when using --fomit-frame-pointer can be fixed, though I have not yet found a good way to do so. Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 13:36 Message: [Sorry about the previous post - a stray mouse click sent it prematurely ] > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: On other architectures (I'm familiar with SPARC and the AMD64 ABI), there are two registers set aside for stack (%sp/%rsp) and frame (%fp/%rbp) pointers. As all of these registers can be used to read from memory with a supplied offset. Thus it's and relatively trivial for the compiler to re-write "ldx [%fp-0x7e7], %g3" as "ldx [%sp+XXX], %g3" where XXX is the current frame size minus 0x7e7. Thus an "--fomit-frame-pointer" option makes no difference to the compiled code or execution time. On the Z80, we cannot use the %sp register this way, so re-writing "ld a, -5(ix)" becomes non-trivial and space/time consuming. So from my point of view, I cannot see the usefulness of disabling the frame pointer. That was my point, not that %ix cannot be used as an indexed register. Actually, SDCC's creation and use of a frame pointer is the one thing that drew me to sdcc when I was looking for a Z80 cross-compiler last year. I personally can't imagine running without one, except perhaps for the smallest, most trivial functions (at the possible expense of being able to build up a stack trace later...) If there are others who would make use of it, then by all means fix it. That's fine by me. ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 13:21 Message: > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: , on x86, you can read directly from the %rsp+offset if you wanted to, so you can dispense with setting up %rbp as the frame and use it for something else. On Z80, you cannot do this with sp directly, hence use of the ix register. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-05 12:13 Message: > --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. I assume you mean IX here. optralloc gen.c:4105 if(!_G.omitFramePtr) is half of the fix. But gen.c:4116 emit2 ("!enterx", sym->stack); also needs to be fixed IMHO with if (_G.omitFramePtr) emit2 ("!ldaspsp", -sym->stack); else emit2 ("!enterx", sym->stack); As well as gen.c:4119 emit2 ("!enter"); if (!_G.omitFramePtr) emit2 ("!enter"); Then gen.c:2371 (aopGet) else should be else if (_G.omitFramePtr) { setupPair (PAIR_IX, aop, offset); dbuf_tprintf (&dbuf, "!*ixx", offset); } else Then with these fixes many regression tests fail and the first one (addsub) destroys HL in testAdd() for result += 0xab00; Brian, you're wrong here in describing the use case. The Z80 uses IX as frame pointer and this CAN be used for other indexed actions, so it could make sense to have this option. So, Philipp, shall I commit these changes even though it fixes only half the problem? ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:19 Message: This bug seems to have been at least partially fixed in the optralloc branch some time ago (at least I cannot reproduce it with a small example, such as the one the OP gave). However many (about one in twenty or so) regression tests fail when when using --fomit-frame-pointer. I remember that the z88dk folks were experimenting with using sdcc as their underlying compiler some time ago. AFAIR they used --fomit-frame-pointer and got some applications to work. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:11 Message: Sorry, but IMO we still need this. AFAIR it worked somehow not too long ago. --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. Unfortunately some OS designers have made the bad choice of reserving ix for OS or interrupt routine use, thus applciations meant to be run under these OS are not allowed to touch ix (it'S similar for iy, that's why I introduced --reserve-regs-iy some time ago). Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 10:53 Message: >From my point of view it was academic interest. Given the limited scope of this, and the severe brokenness on z80 (combined with the increase in both code size and execution time), I would have to conclude that nobody is actually using it, and it's probably better to simply remove it. Having an "omit-frame-pointer" option would probably make sense on architectures where there is a dedicated stack pointer register which can be used for indexed operations (like x86 and SPARC) and thus omitting the frame pointer can free up another register. This certainly isn't the case on Z80 (I can't say for the other architectures that SDCC supports), so I'd be happy just dropping the option completely. I can't believe anybody else is actually using it given the broken code it generates! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 21:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-05-07 14:52:57
|
Bugs item #3293371, was opened at 2011-04-27 00:38 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2011-05-07 16:52 Message: They are in #6487 in the trunk. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-06 13:35 Message: Yes, please commit your fixes. The register allcoation issues that become observable when using --fomit-frame-pointer can be fixed, though I have not yet found a good way to do so. Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 13:36 Message: [Sorry about the previous post - a stray mouse click sent it prematurely ] > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: On other architectures (I'm familiar with SPARC and the AMD64 ABI), there are two registers set aside for stack (%sp/%rsp) and frame (%fp/%rbp) pointers. As all of these registers can be used to read from memory with a supplied offset. Thus it's and relatively trivial for the compiler to re-write "ldx [%fp-0x7e7], %g3" as "ldx [%sp+XXX], %g3" where XXX is the current frame size minus 0x7e7. Thus an "--fomit-frame-pointer" option makes no difference to the compiled code or execution time. On the Z80, we cannot use the %sp register this way, so re-writing "ld a, -5(ix)" becomes non-trivial and space/time consuming. So from my point of view, I cannot see the usefulness of disabling the frame pointer. That was my point, not that %ix cannot be used as an indexed register. Actually, SDCC's creation and use of a frame pointer is the one thing that drew me to sdcc when I was looking for a Z80 cross-compiler last year. I personally can't imagine running without one, except perhaps for the smallest, most trivial functions (at the possible expense of being able to build up a stack trace later...) If there are others who would make use of it, then by all means fix it. That's fine by me. ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 13:21 Message: > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: , on x86, you can read directly from the %rsp+offset if you wanted to, so you can dispense with setting up %rbp as the frame and use it for something else. On Z80, you cannot do this with sp directly, hence use of the ix register. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-05 12:13 Message: > --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. I assume you mean IX here. optralloc gen.c:4105 if(!_G.omitFramePtr) is half of the fix. But gen.c:4116 emit2 ("!enterx", sym->stack); also needs to be fixed IMHO with if (_G.omitFramePtr) emit2 ("!ldaspsp", -sym->stack); else emit2 ("!enterx", sym->stack); As well as gen.c:4119 emit2 ("!enter"); if (!_G.omitFramePtr) emit2 ("!enter"); Then gen.c:2371 (aopGet) else should be else if (_G.omitFramePtr) { setupPair (PAIR_IX, aop, offset); dbuf_tprintf (&dbuf, "!*ixx", offset); } else Then with these fixes many regression tests fail and the first one (addsub) destroys HL in testAdd() for result += 0xab00; Brian, you're wrong here in describing the use case. The Z80 uses IX as frame pointer and this CAN be used for other indexed actions, so it could make sense to have this option. So, Philipp, shall I commit these changes even though it fixes only half the problem? ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:19 Message: This bug seems to have been at least partially fixed in the optralloc branch some time ago (at least I cannot reproduce it with a small example, such as the one the OP gave). However many (about one in twenty or so) regression tests fail when when using --fomit-frame-pointer. I remember that the z88dk folks were experimenting with using sdcc as their underlying compiler some time ago. AFAIR they used --fomit-frame-pointer and got some applications to work. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:11 Message: Sorry, but IMO we still need this. AFAIR it worked somehow not too long ago. --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. Unfortunately some OS designers have made the bad choice of reserving ix for OS or interrupt routine use, thus applciations meant to be run under these OS are not allowed to touch ix (it'S similar for iy, that's why I introduced --reserve-regs-iy some time ago). Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 10:53 Message: >From my point of view it was academic interest. Given the limited scope of this, and the severe brokenness on z80 (combined with the increase in both code size and execution time), I would have to conclude that nobody is actually using it, and it's probably better to simply remove it. Having an "omit-frame-pointer" option would probably make sense on architectures where there is a dedicated stack pointer register which can be used for indexed operations (like x86 and SPARC) and thus omitting the frame pointer can free up another register. This certainly isn't the case on Z80 (I can't say for the other architectures that SDCC supports), so I'd be happy just dropping the option completely. I can't believe anybody else is actually using it given the broken code it generates! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 21:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-06-28 12:30:30
|
Bugs item #3293371, was opened at 2011-04-27 00:38 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2011-06-28 14:30 Message: Just for the record: For the Z80 port only (i.e. not the GBZ80) every bug that appears when using --fomit-frame-pointer is a bug that in principle could appear without --fomit-frame-pointer when there's more than 128 bytes of local variables in a function. The mechanism used to access all local variables when using --fomit-frame-pointer is the one that's always used for local variables that are further than 128 bytes away fromt he current frame pointer. Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-07 16:52 Message: They are in #6487 in the trunk. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-06 13:35 Message: Yes, please commit your fixes. The register allcoation issues that become observable when using --fomit-frame-pointer can be fixed, though I have not yet found a good way to do so. Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 13:36 Message: [Sorry about the previous post - a stray mouse click sent it prematurely ] > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: On other architectures (I'm familiar with SPARC and the AMD64 ABI), there are two registers set aside for stack (%sp/%rsp) and frame (%fp/%rbp) pointers. As all of these registers can be used to read from memory with a supplied offset. Thus it's and relatively trivial for the compiler to re-write "ldx [%fp-0x7e7], %g3" as "ldx [%sp+XXX], %g3" where XXX is the current frame size minus 0x7e7. Thus an "--fomit-frame-pointer" option makes no difference to the compiled code or execution time. On the Z80, we cannot use the %sp register this way, so re-writing "ld a, -5(ix)" becomes non-trivial and space/time consuming. So from my point of view, I cannot see the usefulness of disabling the frame pointer. That was my point, not that %ix cannot be used as an indexed register. Actually, SDCC's creation and use of a frame pointer is the one thing that drew me to sdcc when I was looking for a Z80 cross-compiler last year. I personally can't imagine running without one, except perhaps for the smallest, most trivial functions (at the possible expense of being able to build up a stack trace later...) If there are others who would make use of it, then by all means fix it. That's fine by me. ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 13:21 Message: > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: , on x86, you can read directly from the %rsp+offset if you wanted to, so you can dispense with setting up %rbp as the frame and use it for something else. On Z80, you cannot do this with sp directly, hence use of the ix register. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-05 12:13 Message: > --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. I assume you mean IX here. optralloc gen.c:4105 if(!_G.omitFramePtr) is half of the fix. But gen.c:4116 emit2 ("!enterx", sym->stack); also needs to be fixed IMHO with if (_G.omitFramePtr) emit2 ("!ldaspsp", -sym->stack); else emit2 ("!enterx", sym->stack); As well as gen.c:4119 emit2 ("!enter"); if (!_G.omitFramePtr) emit2 ("!enter"); Then gen.c:2371 (aopGet) else should be else if (_G.omitFramePtr) { setupPair (PAIR_IX, aop, offset); dbuf_tprintf (&dbuf, "!*ixx", offset); } else Then with these fixes many regression tests fail and the first one (addsub) destroys HL in testAdd() for result += 0xab00; Brian, you're wrong here in describing the use case. The Z80 uses IX as frame pointer and this CAN be used for other indexed actions, so it could make sense to have this option. So, Philipp, shall I commit these changes even though it fixes only half the problem? ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:19 Message: This bug seems to have been at least partially fixed in the optralloc branch some time ago (at least I cannot reproduce it with a small example, such as the one the OP gave). However many (about one in twenty or so) regression tests fail when when using --fomit-frame-pointer. I remember that the z88dk folks were experimenting with using sdcc as their underlying compiler some time ago. AFAIR they used --fomit-frame-pointer and got some applications to work. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:11 Message: Sorry, but IMO we still need this. AFAIR it worked somehow not too long ago. --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. Unfortunately some OS designers have made the bad choice of reserving ix for OS or interrupt routine use, thus applciations meant to be run under these OS are not allowed to touch ix (it'S similar for iy, that's why I introduced --reserve-regs-iy some time ago). Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 10:53 Message: >From my point of view it was academic interest. Given the limited scope of this, and the severe brokenness on z80 (combined with the increase in both code size and execution time), I would have to conclude that nobody is actually using it, and it's probably better to simply remove it. Having an "omit-frame-pointer" option would probably make sense on architectures where there is a dedicated stack pointer register which can be used for indexed operations (like x86 and SPARC) and thus omitting the frame pointer can free up another register. This certainly isn't the case on Z80 (I can't say for the other architectures that SDCC supports), so I'd be happy just dropping the option completely. I can't believe anybody else is actually using it given the broken code it generates! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 21:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-06-28 13:31:29
|
Bugs item #3293371, was opened at 2011-04-27 00:38 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&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: z80 port Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) >Assigned to: Philipp Klaus Krause (spth) Summary: omit-frame-pointer still generates prolog Initial Comment: The following trivial example code: int func(int a) { return (a * 2); } when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this: _func_start:: _func: push ix ld ix,#0 add ix,sp ;omit_fp.c:4: return (a * 2); ld iy,#4 add iy,sp ld l,0 (iy) ld h,1 (iy) add hl,hl 00101$: ret _func_end:: The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix. Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error). Compiler used: SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386) ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2011-06-28 15:31 Message: Most remaining issues with --fomit-frame-pointer on the Z80 have been fixed in revision #6612; there is only one remaining failing regression test. I close this bug report since the original issue (any many more) have been resolved. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-06-28 14:30 Message: Just for the record: For the Z80 port only (i.e. not the GBZ80) every bug that appears when using --fomit-frame-pointer is a bug that in principle could appear without --fomit-frame-pointer when there's more than 128 bytes of local variables in a function. The mechanism used to access all local variables when using --fomit-frame-pointer is the one that's always used for local variables that are further than 128 bytes away fromt he current frame pointer. Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-07 16:52 Message: They are in #6487 in the trunk. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-06 13:35 Message: Yes, please commit your fixes. The register allcoation issues that become observable when using --fomit-frame-pointer can be fixed, though I have not yet found a good way to do so. Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 13:36 Message: [Sorry about the previous post - a stray mouse click sent it prematurely ] > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: On other architectures (I'm familiar with SPARC and the AMD64 ABI), there are two registers set aside for stack (%sp/%rsp) and frame (%fp/%rbp) pointers. As all of these registers can be used to read from memory with a supplied offset. Thus it's and relatively trivial for the compiler to re-write "ldx [%fp-0x7e7], %g3" as "ldx [%sp+XXX], %g3" where XXX is the current frame size minus 0x7e7. Thus an "--fomit-frame-pointer" option makes no difference to the compiled code or execution time. On the Z80, we cannot use the %sp register this way, so re-writing "ld a, -5(ix)" becomes non-trivial and space/time consuming. So from my point of view, I cannot see the usefulness of disabling the frame pointer. That was my point, not that %ix cannot be used as an indexed register. Actually, SDCC's creation and use of a frame pointer is the one thing that drew me to sdcc when I was looking for a Z80 cross-compiler last year. I personally can't imagine running without one, except perhaps for the smallest, most trivial functions (at the possible expense of being able to build up a stack trace later...) If there are others who would make use of it, then by all means fix it. That's fine by me. ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 13:21 Message: > Brian, you're wrong here in describing the use case. The Z80 uses IX as > frame pointer and this CAN be used for other indexed actions, so it could > make sense to have this option. What I meant was this: , on x86, you can read directly from the %rsp+offset if you wanted to, so you can dispense with setting up %rbp as the frame and use it for something else. On Z80, you cannot do this with sp directly, hence use of the ix register. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-05 12:13 Message: > --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. I assume you mean IX here. optralloc gen.c:4105 if(!_G.omitFramePtr) is half of the fix. But gen.c:4116 emit2 ("!enterx", sym->stack); also needs to be fixed IMHO with if (_G.omitFramePtr) emit2 ("!ldaspsp", -sym->stack); else emit2 ("!enterx", sym->stack); As well as gen.c:4119 emit2 ("!enter"); if (!_G.omitFramePtr) emit2 ("!enter"); Then gen.c:2371 (aopGet) else should be else if (_G.omitFramePtr) { setupPair (PAIR_IX, aop, offset); dbuf_tprintf (&dbuf, "!*ixx", offset); } else Then with these fixes many regression tests fail and the first one (addsub) destroys HL in testAdd() for result += 0xab00; Brian, you're wrong here in describing the use case. The Z80 uses IX as frame pointer and this CAN be used for other indexed actions, so it could make sense to have this option. So, Philipp, shall I commit these changes even though it fixes only half the problem? ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:19 Message: This bug seems to have been at least partially fixed in the optralloc branch some time ago (at least I cannot reproduce it with a small example, such as the one the OP gave). However many (about one in twenty or so) regression tests fail when when using --fomit-frame-pointer. I remember that the z88dk folks were experimenting with using sdcc as their underlying compiler some time ago. AFAIR they used --fomit-frame-pointer and got some applications to work. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-05-05 11:11 Message: Sorry, but IMO we still need this. AFAIR it worked somehow not too long ago. --fomit-frame-pointer is currently the only way to tell sdcc not to use the iy register. Unfortunately some OS designers have made the bad choice of reserving ix for OS or interrupt routine use, thus applciations meant to be run under these OS are not allowed to touch ix (it'S similar for iy, that's why I introduced --reserve-regs-iy some time ago). Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-05-05 10:53 Message: >From my point of view it was academic interest. Given the limited scope of this, and the severe brokenness on z80 (combined with the increase in both code size and execution time), I would have to conclude that nobody is actually using it, and it's probably better to simply remove it. Having an "omit-frame-pointer" option would probably make sense on architectures where there is a dedicated stack pointer register which can be used for indexed operations (like x86 and SPARC) and thus omitting the frame pointer can free up another register. This certainly isn't the case on Z80 (I can't say for the other architectures that SDCC supports), so I'd be happy just dropping the option completely. I can't believe anybody else is actually using it given the broken code it generates! ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-05-04 21:46 Message: I made an attempt to fix this, but after the stack frame was fixed it failed register allocation in the regression tests. Next I looked where this option is actually used and it hardly seems to be. The hc08 port sets the flag but doesn't use it. The pic16 port uses it to setup/restore the framepointer but not for access to the stack frame. Only the z80 uses it and that is severely broken. Now my question is: is this option useful or only of academic interest? Or in other words: are we going to try to fix this or is it better to just remove it? In the latter case I will remove my local patches instead of committing them. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599 |