digitalmars.D - Why are some casts from floating point to integral done differently from others?
- Aldo Nunez (6/6) Mar 14 2010 I was testing evaluating cast expressions for a debugger I'm working on,...
- Don (9/18) Mar 15 2010 This happens because there are no built-in functions for converting from...
- Aldo Nunez (5/11) Mar 15 2010 You're right, but why isn't it done for (float, double -> ulong) like it...
- bearophile (5/6) Mar 15 2010 If you don't like this you can add a comment after it:
- Aldo Nunez (2/10) Mar 15 2010 Thanks, bearophile! I just did.
- Don (4/21) Mar 15 2010 I don't know, but it's probably historical. The real->ulong code is
- Walter Bright (2/5) Mar 15 2010 Eh, go back a lot further!
- Don (11/17) Mar 15 2010 Actually I suspected it might be from the x87 emulator days.
- Walter Bright (9/30) Mar 15 2010 The Digital Mars C compiler was started in 1982, and a lot of it still s...
I was testing evaluating cast expressions for a debugger I'm working on, when I came across this bit of behavior that hopefully Walter or someone else can explain. Most conversions in D from floating point to integer are done with the help of the x87 FP instructions: load FP number, store as integer. This is understandable. The following conversions are done differently: - float, double, real -> uint - float, double -> ulong They are done with the help of runtime functions called DBLULNG and DBLULLNG respectively. They work completely with x86 non-FP instructions. What I don't like about them is that they produce results that are inconsistent with the way the other conversions are handled. For example, (cast(uint) -1.0) becomes 0, whereas (cast(ulong) -1.0L) becomes 0xFFFFFFFFFFFFFFFF and (cast(ushort) -1.0L) becomes 0xFFFF.
Mar 14 2010
Aldo Nunez wrote:I was testing evaluating cast expressions for a debugger I'm working on, when I came across this bit of behavior that hopefully Walter or someone else can explain. Most conversions in D from floating point to integer are done with the help of the x87 FP instructions: load FP number, store as integer. This is understandable. The following conversions are done differently: - float, double, real -> uint - float, double -> ulong They are done with the help of runtime functions called DBLULNG and DBLULLNG respectively.This happens because there are no built-in functions for converting from float to unsigned. Values between int.max and uint.max need to be treated specially. What I don't like about them is that they produce results that are inconsistent with the way the other conversions are handled. For example, (cast(uint) -1.0) becomes 0, whereas (cast(ulong) -1.0L) becomes 0xFFFFFFFFFFFFFFFF and (cast(ushort) -1.0L) becomes 0xFFFF. The cast(uint) case is clearly a bug. Please file it in Bugzilla.
Mar 15 2010
Don Wrote:The cast(uint) case is clearly a bug. Please file it in Bugzilla.I'll file a bug, but...This happens because there are no built-in functions for converting from float to unsigned. Values between int.max and uint.max need to be treated specially.You're right, but why isn't it done for (float, double -> ulong) like it's done for (real -> ulong), where it's a simple conversion to long plus a fixup. It's not like (float -> real -> ulong) will introduce more precise non-zero bits (or will it?). Then there's the case of (float, double, real -> uint). Why isn't this done like (float, double, real -> ushort), where a simple conversion to int is done, and then the result is truncated to ushort? Wouldn't it work the same to do a simple conversion to long, and then truncate the result to uint? I'm just trying to understand why these simple, yet seemingly just as accurate methods weren't used.
Mar 15 2010
Aldo Nunez:I'll file a bug, but...If you don't like this you can add a comment after it: http://d.puremagic.com/issues/show_bug.cgi?id=3970 Bye, bearophile
Mar 15 2010
Aldo Nunez <aldonunez1 gmail.com> bearophile Wrote:Aldo Nunez:Thanks, bearophile! I just did.I'll file a bug, but...If you don't like this you can add a comment after it: http://d.puremagic.com/issues/show_bug.cgi?id=3970 Bye, bearophile
Mar 15 2010
Aldo Nunez wrote:Don Wrote:I don't know, but it's probably historical. The real->ulong code is quite recent (about a year old), but the other ones are ancient. They may even come from the 386 days.The cast(uint) case is clearly a bug. Please file it in Bugzilla.I'll file a bug, but...This happens because there are no built-in functions for converting from float to unsigned. Values between int.max and uint.max need to be treated specially.You're right, but why isn't it done for (float, double -> ulong) like it's done for (real -> ulong), where it's a simple conversion to long plus a fixup. It's not like (float -> real -> ulong) will introduce more precise non-zero bits (or will it?). Then there's the case of (float, double, real -> uint). Why isn't this done like (float, double, real -> ushort), where a simple conversion to int is done, and then the result is truncated to ushort? Wouldn't it work the same to do a simple conversion to long, and then truncate the result to uint? I'm just trying to understand why these simple, yet seemingly just as accurate methods weren't used.
Mar 15 2010
Don wrote:I don't know, but it's probably historical. The real->ulong code is quite recent (about a year old), but the other ones are ancient. They may even come from the 386 days.Eh, go back a lot further!
Mar 15 2010
Walter Bright wrote:Don wrote:Actually I suspected it might be from the x87 emulator days. So, the code is probably older than some of the posters to this newsgroup! OT: My all-time favourite bit of code that I maintain is a little piece of x87 asm which dates from 1981. Back then, Intel didn't even sell the x87 directly, you had to buy it by mail-order from a guy in Silicon Valley who lived near the Intel fab. It's great to see that code still running on a quad-core 64 bit CPU! The app that was converted to Pascal at some point before the 90's, but all of that's gone now. Yet the asm survived (with just AX->EAX->RAX)! It was a fine piece of work.I don't know, but it's probably historical. The real->ulong code is quite recent (about a year old), but the other ones are ancient. They may even come from the 386 days.Eh, go back a lot further!
Mar 15 2010
Don wrote:Walter Bright wrote:The Digital Mars C compiler was started in 1982, and a lot of it still survives in the code base (library & compiler). The evolution of the human brain is not done by replacing structures with new ones, but by putting new layers over the old ones and overriding them. Hence, we all have a notochord, and a dinosaur brain, etc. You can see that in the back end code; the original design and structure is intact, it's just been layered over. Maybe some day I should dig up NWC 1.0 and post it! The D front end, however, is radically different from the C front end.Don wrote:Actually I suspected it might be from the x87 emulator days. So, the code is probably older than some of the posters to this newsgroup! OT: My all-time favourite bit of code that I maintain is a little piece of x87 asm which dates from 1981. Back then, Intel didn't even sell the x87 directly, you had to buy it by mail-order from a guy in Silicon Valley who lived near the Intel fab. It's great to see that code still running on a quad-core 64 bit CPU! The app that was converted to Pascal at some point before the 90's, but all of that's gone now. Yet the asm survived (with just AX->EAX->RAX)! It was a fine piece of work.I don't know, but it's probably historical. The real->ulong code is quite recent (about a year old), but the other ones are ancient. They may even come from the 386 days.Eh, go back a lot further!
Mar 15 2010