Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: SourceForge.net <noreply@so...>  20100920 08:10:28

Bugs item #3071726, was opened at 20100920 08:10 Message generated for change (Tracker Item Submitted) made by berwyn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3071726&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: CFront End Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Berwyn Hoyt (berwyn) Assigned to: Nobody/Anonymous (nobody) Summary: x/2 doesn't always translate to x>>1 Initial Comment: According to SDCC manual 8.1.6 "Algebraic Simplifications" the following grep should find nothing because it should translate x/2 into x>>1. Under certain conditions it does not always work on signed integers even though it works with unsigned integers. Notice the difference in the output of the following depending on whether x is signed or unsigned. main.c: int plus_div2(int x) { return x+x/2; } int main(void) { return plus_div2(4); } $ sdcc main.c $ grep __divsint main.lst  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3071726&group_id=599 
From: SourceForge.net <noreply@so...>  20100920 08:12:38

Bugs item #3071726, was opened at 20100920 08:10 Message generated for change (Comment added) made by berwyn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3071726&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: CFront End Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Berwyn Hoyt (berwyn) Assigned to: Nobody/Anonymous (nobody) Summary: x/2 doesn't always translate to x>>1 Initial Comment: According to SDCC manual 8.1.6 "Algebraic Simplifications" the following grep should find nothing because it should translate x/2 into x>>1. Under certain conditions it does not always work on signed integers even though it works with unsigned integers. Notice the difference in the output of the following depending on whether x is signed or unsigned. main.c: int plus_div2(int x) { return x+x/2; } int main(void) { return plus_div2(4); } $ sdcc main.c $ grep __divsint main.lst  >Comment By: Berwyn Hoyt (berwyn) Date: 20100920 08:12 Message: PS, I'm compiling to the 8051 using SDCC 2.9.0 #5416 March 22 2009 (MINGW32)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3071726&group_id=599 
From: SourceForge.net <noreply@so...>  20100920 08:41:53

Bugs item #3071726, was opened at 20100920 10:10 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3071726&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: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Berwyn Hoyt (berwyn) >Assigned to: Philipp Krause (spth) Summary: x/2 doesn't always translate to x>>1 Initial Comment: According to SDCC manual 8.1.6 "Algebraic Simplifications" the following grep should find nothing because it should translate x/2 into x>>1. Under certain conditions it does not always work on signed integers even though it works with unsigned integers. Notice the difference in the output of the following depending on whether x is signed or unsigned. main.c: int plus_div2(int x) { return x+x/2; } int main(void) { return plus_div2(4); } $ sdcc main.c $ grep __divsint main.lst  >Comment By: Philipp Krause (spth) Date: 20100920 10:41 Message: Fixed in revision #5988 by clarifying the manual. Philipp P.S.: x/2 is not quivalent to x >> 1 for signed integers: x / 2 rounds towards zero, while x >> 1 rounds towards minus infinity.  Comment By: Berwyn Hoyt (berwyn) Date: 20100920 10:12 Message: PS, I'm compiling to the 8051 using SDCC 2.9.0 #5416 March 22 2009 (MINGW32)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3071726&group_id=599 
From: <wek@ef...>  20100920 19:52:11

> P.S.: x/2 is not quivalent to x >> 1 for signed integers: x / 2 rounds > towards zero, while x >> 1 rounds towards minus infinity. But it still would be more efficient to perform the shift, "fix" the rounding and restore the MSB, rather than call the division routine, at least on platforms without hardware div, or not? I mean hypothetically; I understand that this would be more than a trivial undertaking. Jan Waclawek  http://www.freeserver.sk  Sponsored by freeserver webhosting 
From: Philipp Klaus Krause <pkk@sp...>  20100920 21:09:18

BEGIN PGP SIGNED MESSAGE Hash: SHA1 Am 20.09.2010 21:52, schrieb wek@...: >> P.S.: x/2 is not quivalent to x >> 1 for signed integers: x / 2 rounds >> towards zero, while x >> 1 rounds towards minus infinity. > > But it still would be more efficient to perform the shift, "fix" the > rounding and restore the MSB, rather than call the division routine, > at least on platforms without hardware div, or not? Shifting and then fixing is probably more expensive than the following: x / 2 = abs(x >> 1) * sgn(x). Written more verbose: int16_t divbytwo(int16_t x) { bool s = (x < 0); uint16_t v = x; v >>= 1; return(s ? v : v); } or a bit more generic: int16_t divbytwo(int16_t x, uint8_t n) { bool s = (x < 0); uint16_t v = x; do v >>= 1; while(n); return(s ? v : v); } > > I mean hypothetically; I understand that this would be more than a > trivial undertaking. > > Jan Waclawek > Well, so far each time I found an unoptimized /2 or /4 in my code it was either 1) Somewhere were I didn't care enough about it to implement the optimization or 2) Somewhere were speed was essential, but rounding towards minus infinity was OK, and I just manually replaced the / by >>. However I just opened a feature request for this, to save these ideas from being forgotten. Maybe I or someone else will implement it (or a better solution) one day. Philipp BEGIN PGP SIGNATURE Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla  http://enigmail.mozdev.org/ iEYEARECAAYFAkyXzXYACgkQbtUV+xsoLpprUACbBb4eI/+IXTiNpOObanBbeR6u AlIAnj34DGKzIiSEfkqiTAz9gkxZ2xfy =LklZ END PGP SIGNATURE 
From: Jan Waclawek <wek@ef...>  20100921 06:54:22

>Shifting and then fixing is probably more expensive than the following: > >x / 2 = abs(x >> 1) * sgn(x). I don't think so. In pseudolanguage, shift'n'fix: copy MSB.7 to CY shift right MSB shift right LSB if MSB.7 addc LSB,0 addc MSB,0 end abs'n'shift'n'sgn: copy MSB.7 to SGN if SGN not LSB not MSB add LSB,1 ; addc MSB,0 ;possibly 16bit inc on some targets (clear CY if needed) shift right MSB shift right LSB if SGN not LSB not MSB add LSB,1 addc MSB,0 end Even if e.g. Z80 has a NEG instruction, it works only on the accumulator so the associated movs to/from registers are to be taken into account, and it's only 8bit anyway so the following bytes must be CPL/ADC'd anyway. My unqualified view is, that if this is to be ever implemented, it should be moved down to the code generation for each target. Jan Waclawek 
From: Philipp Klaus Krause <pkk@sp...>  20100921 07:20:49

Am 21.09.2010 08:54, schrieb Jan Waclawek: > My unqualified view is, that if this is to be ever implemented, it > should be moved down to the code generation for each target. Yes, just like depending on certain conditions multiplications are not replaced by support calls on the Z80 one could do for division. Then there would be a genDiv() in each port for which this is implemented, which would be able to emit a division of e.g. a division of signed 8 and 16 bit values by powers of two. Philipp 
From: Borut Razem <borut.razem@si...>  20100920 21:13:12

See the discussion at http://sourceforge.net/tracker/?func=detail&atid=300599&aid=2997777&group_id=599 This can still be submitted as an RFE. IMHO the best solution would be the introduction of ASR_OP iCode operator... Borut On 09/20/2010 09:52 PM, wek@... wrote: >> P.S.: x/2 is not quivalent to x>> 1 for signed integers: x / 2 rounds >> towards zero, while x>> 1 rounds towards minus infinity. >> > But it still would be more efficient to perform the shift, "fix" the > rounding and restore the MSB, rather than call the division routine, > at least on platforms without hardware div, or not? > > I mean hypothetically; I understand that this would be more than a > trivial undertaking. > > Jan Waclawek > > >  > http://www.freeserver.sk  Sponsored by freeserver webhosting > > > >  > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novellsfdev2dev > _______________________________________________ > sdccdevel mailing list > sdccdevel@... > https://lists.sourceforge.net/lists/listinfo/sdccdevel > > 
From: Philipp Klaus Krause <pkk@sp...>  20100920 21:34:08

Am 20.09.2010 23:13, schrieb Borut Razem: > See the discussion at > http://sourceforge.net/tracker/?func=detail&atid=300599&aid=2997777&group_id=599 > This can still be submitted as an RFE. IMHO the best solution would be > the introduction of ASR_OP iCode operator... What would this opcode do? Philipp 
From: Borut Razem <borut.razem@si...>  20100921 05:52:15

ASR_OP would generate arithmetic shift right. RIGHT_OP generates arithmetic or logic shift right, depending on target implementation. Borut On 09/20/2010 11:34 PM, Philipp Klaus Krause wrote: > Am 20.09.2010 23:13, schrieb Borut Razem: > >> See the discussion at >> http://sourceforge.net/tracker/?func=detail&atid=300599&aid=2997777&group_id=599 >> This can still be submitted as an RFE. IMHO the best solution would be >> the introduction of ASR_OP iCode operator... >> > What would this opcode do? > > Philipp > >  > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novellsfdev2dev > _______________________________________________ > sdccdevel mailing list > sdccdevel@... > https://lists.sourceforge.net/lists/listinfo/sdccdevel > > 
From: Philipp Klaus Krause <pkk@sp...>  20100921 06:31:19

BEGIN PGP SIGNED MESSAGE Hash: SHA1 Am 21.09.2010 07:52, schrieb Borut Razem: > ASR_OP would generate arithmetic shift right. > RIGHT_OP generates arithmetic or logic shift right, depending on target implementation. > > Borut Well, AFAIK most targets do an arithmetic right shift for RIGHT_OP, when the operand is signed. We could just make them all do it if there are some that don't yet. But arithmetic right shift is not equivalent to division: The standard requires the division result to be rounded towards zero. Arithmetic right shift is equivalent to division rounding the result towards minus infinity. Philipp BEGIN PGP SIGNATURE Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla  http://enigmail.mozdev.org/ iEYEARECAAYFAkyYUS8ACgkQbtUV+xsoLpogdwCg9BVNkCEBp/ARsFHWqN/pkw5D vnMAn2daTz6MGPL8zxY7BFLK5fr5IXBd =PuyW END PGP SIGNATURE 
From: Borut Razem <borut.razem@si...>  20100921 07:22:08

On 09/21/2010 08:31 AM, Philipp Klaus Krause wrote: > But arithmetic right shift is not equivalent to > division: The standard requires the division result to be rounded > towards zero. Arithmetic right shift is equivalent to division rounding > the result towards minus infinity. > You are right, I missed that. So "ASR_OP would generate arithmetic shift right." should be redefined as "XXX_OP would generate negative division by power of 2". But probably it really doesn't make sense to introduce so specialized iCode opcodes and it would be better to handle it in the code generation for each target, as Jan proposed. Borut 
Sign up for the SourceForge newsletter:
No, thanks