Re: gnu software bugs - long double
On 11/03/2013 12:29 AM, Rob wrote:
Sat, Nov 02, 2013, Mischa Baars:
On 11/02/2013 11:19 PM, Jonathan Wakely wrote:
On 2 November 2013 22:12, Mischa Baars wrote:
And 1.1 is not representable as long double.
If you are willing to stop being so arrogant for a few minutes and
learn something try running this program and think about what the
result means:
#include
int main()
{
long double l = 1.1;
long double ll = 10 * l;
assert( ll == 11 );
}
If you think GCC gets this result wrong then please use a different
compiler and stop wasting everyone's time, this is off-topic for this
mailing list.
There's no converting to any string in your example. You only
convert source code strings into their corresponding doubles.
What I'm trying to point out is that the output differs from the
value entered in the source. The string 1.1 from the source is not
correctly converted to it's corresponding double, or the double is
not correctly converted back into it's corresponding string.
I challenge you to come up with a better way of representing floating
point numbers in an efficient manner _and_ support silly edge cases like
imperfectly representable numbers. Read up on IEEE floats, particularly
that link Jonathan posted earlier.
This sounds like to most reasonable alternative. I will do it myself.
But please stop wasting everyones' time. Clang exhibits the same
behaviour, it's not a compiler issue.
Thank you
Thanks.
Re: gnu software bugs - long double
On 11/02/2013 11:19 PM, Jonathan Wakely wrote:
On 2 November 2013 22:12, Mischa Baars wrote:
On 11/02/2013 11:06 PM, Jonathan Wakely wrote:
On 2 November 2013 21:52, Mischa Baars wrote:
You are mistaken :)
Indeed some rational numbers can only be represented up to a certain
number
of bits, like 1 / 3. Others can be exactly represented, like 1 / 8.
All real numbers, and therefore all rational numbers, can be represented
up
to a certain number of bits.
i.e. not exactly.
Converting 1.1 from string to double should not be a problem.
That's not what your program does. It converts (long double)1.1, which
is not equal to 1.1, to a string.
I'm trying to pass a completely normal value to the debugger and to the
standard output, and do not convert any value to a string.
Seriously? How do you think printf writes to standard output if not
converting to a string?
So that what glibc does :) That's not my doing.
And 1.1 is not representable as long double.
If you are willing to stop being so arrogant for a few minutes and
learn something try running this program and think about what the
result means:
#include
int main()
{
long double l = 1.1;
long double ll = 10 * l;
assert( ll == 11 );
}
If you think GCC gets this result wrong then please use a different
compiler and stop wasting everyone's time, this is off-topic for this
mailing list.
There's no converting to any string in your example. You only convert
source code strings into their corresponding doubles.
What I'm trying to point out is that the output differs from the value
entered in the source. The string 1.1 from the source is not correctly
converted to it's corresponding double, or the double is not correctly
converted back into it's corresponding string.
Re: gnu software bugs - long double
On 11/02/2013 11:06 PM, Jonathan Wakely wrote: On 2 November 2013 21:52, Mischa Baars wrote: You are mistaken :) Indeed some rational numbers can only be represented up to a certain number of bits, like 1 / 3. Others can be exactly represented, like 1 / 8. All real numbers, and therefore all rational numbers, can be represented up to a certain number of bits. i.e. not exactly. Converting 1.1 from string to double should not be a problem. That's not what your program does. It converts (long double)1.1, which is not equal to 1.1, to a string. I'm trying to pass a completely normal value to the debugger and to the standard output, and do not convert any value to a string. The fact you don't understand doesn't mean the compiler has a bug, and this is off topic for this mailing list. You've been asked before to use gcc-help for this sort of email, instead of reporting "bugs" that are actually just your incorrect assumptions.
Re: gnu software bugs - long double
On 11/02/2013 09:11 PM, David Given wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/13 19:48, Mischa Baars wrote: [...] I have written a couple of new trigonometric functions for use in the library, and actually I need this to function properly. The point is that 1.1 simply cannot be represented precisely as a IEEE floating point number, for precisely the same reasons that 1/3 cannot be represented precisely as a decimal number (1....). This is intrinsic to the way that floating point numbers work. If you try, you'll get the closest number that IEEE floats *can* represent. If you really need a completely precise representation of 1.1, then you're not going to be able to use IEEE floats --- you'll have to use decimals or some sort of fractional representation instead. I don't know if gcc can help you with those, but there are endless helper libraries that will do both for you. They're usually pretty slow, though. You are mistaken :) Indeed some rational numbers can only be represented up to a certain number of bits, like 1 / 3. Others can be exactly represented, like 1 / 8. All real numbers, and therefore all rational numbers, can be represented up to a certain number of bits. Converting 1.1 from string to double should not be a problem. - -- ?? ? http://www.cowlark.com ? ? "There does not now, nor will there ever, exist a programming ? language in which it is the least bit hard to write bad programs." --- ? Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFSdVxhf9E0noFvlzgRAjTFAJ4+UO9b60TkX+/lOa8C/5Hs/XMT3QCcCm8u k2FWyohiL0rQtLUtotFkS/Q= =LgFz -END PGP SIGNATURE-
Re: gnu software bugs - long double
On 11/02/2013 08:28 PM, Jonathan Wakely wrote: On 2 November 2013 18:59, Mischa Baars wrote: On 11/02/2013 07:57 PM, Ian Lance Taylor wrote: On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars wrote: Here's the examples again, now each bug in a separate file. Hope it helps... Just compile with 'make' and run the executable. The source code is documented, so any questions you might have will probably be answered by reading the comments. Again I would suggest that you just put the code inline. In this case I downloaded your test case and ran it on my system. The two numbers printed were identical. Probably identical to each other, but certainly not identical to the input given in the source. As Ian said, you make it unnecessarily difficult to review these "bugs" - why do I have to download an archive and extract it to see a 10 line program? Please read http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html to understand this very, very basic property of floating point numbers. I have written a couple of new trigonometric functions for use in the library, and actually I need this to function properly. Regards, Mischa.
Re: gnu software bugs - long double
On 11/02/2013 08:28 PM, Jonathan Wakely wrote: On 2 November 2013 18:59, Mischa Baars wrote: On 11/02/2013 07:57 PM, Ian Lance Taylor wrote: On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars wrote: Here's the examples again, now each bug in a separate file. Hope it helps... Just compile with 'make' and run the executable. The source code is documented, so any questions you might have will probably be answered by reading the comments. Again I would suggest that you just put the code inline. In this case I downloaded your test case and ran it on my system. The two numbers printed were identical. Probably identical to each other, but certainly not identical to the input given in the source. As Ian said, you make it unnecessarily difficult to review these "bugs" - why do I have to download an archive and extract it to see a 10 line program? Please read http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html to understand this very, very basic property of floating point numbers. Yes well, I get the point, although I don't see what this has to do with the parsing of one simple number?!
Re: gnu software bugs - shift left
On 11/02/2013 08:17 PM, Jonathan Wakely wrote: On 2 November 2013 18:57, Mischa Baars wrote: I understand, however it seems more logical to use the destination type to determine the type of the first and second operand. Are you completely sure this is the desired behaviour? It's the behaviour required by the C standard, so yes, it is absolutely desirable that GCC does that. The literal 1 has a fixed type and the literal 31 has a fixed type, and the expression (1<<31) has a fixed type. Whether you assign the result to a different type does not alter those types involved in the expression. Wow, that sounds pretty stupid for a standard again :) Thanks.
Re: gnu software bugs - long double
On 11/02/2013 07:57 PM, Ian Lance Taylor wrote: On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars wrote: Here's the examples again, now each bug in a separate file. Hope it helps... Just compile with 'make' and run the executable. The source code is documented, so any questions you might have will probably be answered by reading the comments. Again I would suggest that you just put the code inline. In this case I downloaded your test case and ran it on my system. The two numbers printed were identical. Probably identical to each other, but certainly not identical to the input given in the source. I ran the test on an Ubuntu Precise system using GCC 4.6.3. Ian
Re: gnu software bugs - shift left
On 11/02/2013 07:52 PM, Ian Lance Taylor wrote: On Sat, Nov 2, 2013 at 11:31 AM, Mischa Baars wrote: Here's the examples again, now each bug in a separate file. Hope it helps... Just compile with 'make' and run the executable. The source code is documented, so any questions you might have will probably be answered by reading the comments. Thanks for reporting issues with the compiler. This code is short enough that it would be simpler to just include the code inline in your e-mail message. For a case this short we don't need a makefile; just put the command line showing the problem in e-mail. Unfortunately your test case was not very clear. I think you are wondering why these two declarations uint64_t x = 1 << 31; uint64_t y = (uint64_t) 1 << 31; do not produce the same values in x and y. That is not a bug in GCC. It's how the C language works. In the first line, an integral constant without a suffix has type int. Left shifting that int value by 31 still gives you a value of type int. On a system where int is 32 bits, converting a value of type to a value of type uint64_t sign extends the int. I understand, however it seems more logical to use the destination type to determine the type of the first and second operand. Are you completely sure this is the desired behaviour? In the second line, the value is already type uint64_t, and so left shifting it and then assigning it to a variable of type uint64_t does not do any sign extension. Ian
gnu software bugs - long double
Hi, Here's the examples again, now each bug in a separate file. Hope it helps... Just compile with 'make' and run the executable. The source code is documented, so any questions you might have will probably be answered by reading the comments. Regards, Mischa. On 11/02/2013 07:10 PM, Dan Kegel wrote: Please don't crosspost. It would probably also help if you posted just one bug per message, and included the commandline, source, and error message for your smallest test case inline, and used a more descriptive subject line. On Sat, Nov 2, 2013 at 10:26 AM, Mischa Baars wrote: Hi, I found these two small bugs in the gnu software. Anyone who would like to try to fix these? Regards, Mischa. 2013101701 - gnu software bugs - long double.tar.bz2 Description: application/bzip
gnu software bugs - shift left
Hi, Here's the examples again, now each bug in a separate file. Hope it helps... Just compile with 'make' and run the executable. The source code is documented, so any questions you might have will probably be answered by reading the comments. Regards, Mischa. On 11/02/2013 07:10 PM, Dan Kegel wrote: Please don't crosspost. It would probably also help if you posted just one bug per message, and included the commandline, source, and error message for your smallest test case inline, and used a more descriptive subject line. On Sat, Nov 2, 2013 at 10:26 AM, Mischa Baars wrote: Hi, I found these two small bugs in the gnu software. Anyone who would like to try to fix these? Regards, Mischa. 2013101700 - gnu software bugs - shift left.tar.bz2 Description: application/bzip
gnu software bugs
Hi, I found these two small bugs in the gnu software. Anyone who would like to try to fix these? Regards, Mischa. 2013101700 - gnu software bugs.tar.bz2 Description: application/bzip
Re: Components no longer exist
On 01/17/2013 07:40 PM, Jonathan Wakely wrote: On 17 January 2013 17:48, Mischa Baars wrote: Indeed I am, I thought you were trying to say that gcc-x.y.z.tar.gz has missing components. I had some trouble compiler: unable to compute suffix for object files, but now it seems to work?! Did you read http://gcc.gnu.org/wiki/FAQ#configure_suffix ? Let me get back to you. See if I can fix the 'if / else' for you, and finish the algorithm. It will be my first update to the compiler so it will probably take a while. I have no idea what "if / else" you're talking about. Please read the topic on not-a-number's then. At the very beginning there's one of my attachments. Thanks, Mischa.
Re: Components no longer exist
On 01/17/2013 06:31 PM, Jonathan Wakely wrote: On 17 January 2013 17:29, Mischa Baars wrote: On 01/17/2013 06:23 PM, Jonathan Wakely wrote: On 17 January 2013 15:48, Michael Witten : The documentation here: http://gcc.gnu.org/install/download.html says: It is possible to download a full distribution or specific components... If you choose to download specific components, you must download the core GCC distribution plus any language specific distributions you wish to use. However, from what I can tell, this hasn't been the case since the release of 4.7.0; there is only a monolithic distribution of source (no separate components). Either the components need to be added, or the documentation needs to be updated. The documentation is out of date, thanks for reporting it. Does that mean that you are satisfied with the 'if / else' as is, and that you also do not need an improvement of the arctangent in glibc? You're confused. This is nothing to do with glibc. The "distribution" is the tarball of GCC sources. The "components" are the separate tarballs that used to be made available for gcc-core-x.y.z.tar.gz, gcc-c++-x.y.z.tar.gz, gcc-fortran-x.y.z.tar.gz, etc. but these are no longer made available, only the gcc-x.y.z.tar.gz tarball containing everything. Indeed I am, I thought you were trying to say that gcc-x.y.z.tar.gz has missing components. I had some trouble compiler: unable to compute suffix for object files, but now it seems to work?! Let me get back to you. See if I can fix the 'if / else' for you, and finish the algorithm. It will be my first update to the compiler so it will probably take a while. Mischa.
Re: Components no longer exist
On 01/17/2013 06:23 PM, Jonathan Wakely wrote: On 17 January 2013 15:48, Michael Witten : The documentation here: http://gcc.gnu.org/install/download.html says: It is possible to download a full distribution or specific components... If you choose to download specific components, you must download the core GCC distribution plus any language specific distributions you wish to use. However, from what I can tell, this hasn't been the case since the release of 4.7.0; there is only a monolithic distribution of source (no separate components). Either the components need to be added, or the documentation needs to be updated. The documentation is out of date, thanks for reporting it. Does that mean that you are satisfied with the 'if / else' as is, and that you also do not need an improvement of the arctangent in glibc? Mischa.
Re: Components no longer exist
On 01/17/2013 04:48 PM, Michael Witten wrote: The documentation here: http://gcc.gnu.org/install/download.html says: It is possible to download a full distribution or specific components... If you choose to download specific components, you must download the core GCC distribution plus any language specific distributions you wish to use. However, from what I can tell, this hasn't been the case since the release of 4.7.0; there is only a monolithic distribution of source (no separate components). Either the components need to be added, or the documentation needs to be updated. Sincerely, Michael Witten Perhaps we can exchange parts? It's just that my documentation is not finished, you can look at it tough if you like. Mischa.
Re: Components no longer exist
On 01/17/2013 04:48 PM, Michael Witten wrote: The documentation here: http://gcc.gnu.org/install/download.html says: It is possible to download a full distribution or specific components... If you choose to download specific components, you must download the core GCC distribution plus any language specific distributions you wish to use. However, from what I can tell, this hasn't been the case since the release of 4.7.0; there is only a monolithic distribution of source (no separate components). Either the components need to be added, or the documentation needs to be updated. Sincerely, Michael Witten Could you please be so kind to look into this matter, what specific components you might want to add to make this distribution worth downloading? I have a pretty good arctangent more or less waiting for you, although some changes to the documentation are still in order and the little problem with the NaN's still needs some attention. Other trigonometric functions will be added shortly, but I need to be able to compile my compiler to be able to help. Hope you are willing to help too, Thanks, Mischa.
Re: not-a-number's
On 01/17/2013 04:46 PM, Vincent Lefevre wrote: On 2013-01-17 16:33:56 +0100, Mischa Baars wrote: Actually it is the correct way, as long as you stick to the conventions. A QNaN is not supposed to change into anything, also not with the pow(). Only the other way around. Normal numbers can change into QNaN's. The C standard specified pow(NaN,0) = 1, pow(1,NaN) = 1, and hypot(inf,NaN) = +inf. You may consider that these are bad choices (I don't like them much either), but this is how these cases have been specified. You are free to write wrappers for your own programs and never call pow and hypot directly... Again, personally I think that might just be not the smartest choice. QNaN are only useful when normal numbers can be changed into QNaN's but not the other way around. Then you can see at the end of any calculation if something went wrong or if it gave you the answer you had expected.
Re: not-a-number's
On 01/17/2013 04:33 PM, Mischa Baars wrote: On 01/17/2013 01:08 PM, Gabriel Paubert wrote: On Thu, Jan 17, 2013 at 12:21:04PM +0100, Vincent Lefevre wrote: On 2013-01-17 06:53:45 +0100, Mischa Baars wrote: Also this was not what I intended to do, I was trying to work with quiet not-a-numbers explicitly to avoid the 'invalid operation' exception to be triggered, so that my program can work it's way through the calculations without being terminated by the intervention of a signal handler. When any not-a-number shows up in results after execution, then you know something went wrong. When the program does what it is supposed to do, you could remove any remaining debug code, such as the boundary check in the trigonometric functions. Checking whether a (final) result is NaN is not always the correct way to detect whether something was wrong, because a NaN can disappear. For instance, pow(NaN,0) gives 0, not NaN. Actually 1, but that's a detail. NaN typically propagate, but there are a few exceptions. Actually it is the correct way, as long as you stick to the conventions. A QNaN is not supposed to change into anything, also not with the pow(). Only the other way around. Normal numbers can change into QNaN's. I'm would be very happy to write you an update to the compiler, but it seems I can't get gcc-4.7.2 to compile. I was just enjoying the newest glibc, which finally is. Can I now please try to finish the arctan for glibc? You need to check the "invalid operation" exception flag (if you don't want a trap). And this flag will also be set by the <=, <, >, >= comparisons when one of the operands is NaN, which should be fine for you. Hmm, are you sure that this part is properly implemented in gcc, using unordered compare versus ordered compare instructions depending on the operator you use? At least on PPC, floating point compares always use the unordered instruction (fcmpu) and never the ordered one (fcmpo), so exceptions flags are never set. Regards, Gabriel
Re: not-a-number's
On 01/17/2013 01:08 PM, Gabriel Paubert wrote: On Thu, Jan 17, 2013 at 12:21:04PM +0100, Vincent Lefevre wrote: On 2013-01-17 06:53:45 +0100, Mischa Baars wrote: Also this was not what I intended to do, I was trying to work with quiet not-a-numbers explicitly to avoid the 'invalid operation' exception to be triggered, so that my program can work it's way through the calculations without being terminated by the intervention of a signal handler. When any not-a-number shows up in results after execution, then you know something went wrong. When the program does what it is supposed to do, you could remove any remaining debug code, such as the boundary check in the trigonometric functions. Checking whether a (final) result is NaN is not always the correct way to detect whether something was wrong, because a NaN can disappear. For instance, pow(NaN,0) gives 0, not NaN. Actually 1, but that's a detail. NaN typically propagate, but there are a few exceptions. Actually it is the correct way, as long as you stick to the conventions. A QNaN is not supposed to change into anything, also not with the pow(). Only the other way around. Normal numbers can change into QNaN's. You need to check the "invalid operation" exception flag (if you don't want a trap). And this flag will also be set by the <=, <, >, >= comparisons when one of the operands is NaN, which should be fine for you. Hmm, are you sure that this part is properly implemented in gcc, using unordered compare versus ordered compare instructions depending on the operator you use? At least on PPC, floating point compares always use the unordered instruction (fcmpu) and never the ordered one (fcmpo), so exceptions flags are never set. Regards, Gabriel
Re: not-a-number's
On 01/16/2013 07:23 PM, David Paterson wrote: -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Mischa Baars Sent: 16 January 2013 12:53 To: Robert Dewar; gcc@gcc.gnu.org Subject: Re: not-a-number's On 01/16/2013 01:28 PM, Robert Dewar wrote: On 1/16/2013 7:10 AM, Mischa Baars wrote: And as I have said before: if you are satisfied with the answer '2', then so be it and you keep the compiler the way it is, personally I'm am not able to accept changes to the sources anyway. I don't think it is the right answer though. The fact that you don't think that gcc shoudl follow the C standard is hardly convincing unless it is backed up by convincing technical argument. I see nothing surprising about the 2 here, indeed any other answer *would* be surprising. I still don't understand the basis for your non-stnadard views. Mischa. Let me explain again for you. Every 'if' statement in C is translated into a 'fucom' or similar instruction, which sets a number of conditions flags in the co-processor. Some instructions need you to load these into the eflags register manually, others don't. Now, as soon as the 'fucom' or similar instruction encounters a 'signalling not-a- number' or 'quiet not-a-number' as one or both of it's arguments, the condition code is set to 'not comparable'. This has nothing to do with the C specification, but purely with the Intel/AMD hardware. Intel and AMD aren't the only manufacturers or developers of floating point hardware. Plus there are software implementations to consider as well. In order for different hardware and software implementations to work correctly with each other, there have to be standards defining all aspects of their operation. The same applies to the C language (and other languages!). Without standards we'd have no way to ensure programs would run in the same way on different hardware, or when using different compilers... If you ask me, it would be counter-intuitive to change the value of the condition code to some other value and call that the new standard. Instead it would seem logical to use the 'not comparable' and terminate the 'if' statement. What exactly do you mean by "terminate the if"?? Do you mean skip the whole compound statement, including any "else" clause? Yes, exactly. Skip it, including the 'else'. Does that make sense to you? In our example, a 'not-a-number' would be returned to the main program, without the need for an extra 'isnan()'. "...returned to the main program" doesn't make sense. How is the compiler going to figure out what to return and when? What does it return from a void, or int function? There is an 'r = -NAN' at the beginning which will then be the value returned. I'm sorry you don't like the way it's implemented, but we have standards for very good reasons, and although this particular one may seem a bit counter- intuitive, it's well known, and many programs rely on it operating as it does. But, if you want to change the standards, by all means try... David P.
Re: not-a-number's
On 01/16/2013 02:53 PM, Richard Biener wrote: On Wed, Jan 16, 2013 at 1:52 PM, Mischa Baars wrote: On 01/16/2013 01:28 PM, Robert Dewar wrote: On 1/16/2013 7:10 AM, Mischa Baars wrote: And as I have said before: if you are satisfied with the answer '2', then so be it and you keep the compiler the way it is, personally I'm am not able to accept changes to the sources anyway. I don't think it is the right answer though. The fact that you don't think that gcc shoudl follow the C standard is hardly convincing unless it is backed up by convincing technical argument. I see nothing surprising about the 2 here, indeed any other answer *would* be surprising. I still don't understand the basis for your non-stnadard views. Mischa. Let me explain again for you. Every 'if' statement in C is translated into a 'fucom' or similar instruction, which sets a number of conditions flags in the co-processor. Some instructions need you to load these into the eflags register manually, others don't. Now, as soon as the 'fucom' or similar instruction encounters a 'signalling not-a-number' or 'quiet not-a-number' as one or both of it's arguments, the condition code is set to 'not comparable'. This has nothing to do with the C specification, but purely with the Intel/AMD hardware. If you ask me, it would be counter-intuitive to change the value of the condition code to some other value and call that the new standard. Instead it would seem logical to use the 'not comparable' and terminate the 'if' statement. Does that make sense to you? In our example, a 'not-a-number' would be returned to the main program, without the need for an extra 'isnan()'. You can enable FP exceptions via fpsetexceptflag and friends (it's disabled in the FPU by default) and if you then make sure to compile with -fsignalling-nans (that's not the default) you will get the desired behavior (program termination via an exception). Richard. Yes, I understand that more or less the same can be done with signaling not-a-numbers. By unmasking the appropriate bits in the exception mask, indeed the 'invalid operation' exception would be triggered on the first 'if' statement. Probably the whole program including the 'main()' loop is terminated that way, but I have never looked at the actual handler more close, so I can't with certainty. Also this was not what I intended to do, I was trying to work with quiet not-a-numbers explicitly to avoid the 'invalid operation' exception to be triggered, so that my program can work it's way through the calculations without being terminated by the intervention of a signal handler. When any not-a-number shows up in results after execution, then you know something went wrong. When the program does what it is supposed to do, you could remove any remaining debug code, such as the boundary check in the trigonometric functions. Mischa.
Re: not-a-number's
On 01/16/2013 01:28 PM, Robert Dewar wrote: On 1/16/2013 7:10 AM, Mischa Baars wrote: And as I have said before: if you are satisfied with the answer '2', then so be it and you keep the compiler the way it is, personally I'm am not able to accept changes to the sources anyway. I don't think it is the right answer though. The fact that you don't think that gcc shoudl follow the C standard is hardly convincing unless it is backed up by convincing technical argument. I see nothing surprising about the 2 here, indeed any other answer *would* be surprising. I still don't understand the basis for your non-stnadard views. Mischa. Let me explain again for you. Every 'if' statement in C is translated into a 'fucom' or similar instruction, which sets a number of conditions flags in the co-processor. Some instructions need you to load these into the eflags register manually, others don't. Now, as soon as the 'fucom' or similar instruction encounters a 'signalling not-a-number' or 'quiet not-a-number' as one or both of it's arguments, the condition code is set to 'not comparable'. This has nothing to do with the C specification, but purely with the Intel/AMD hardware. If you ask me, it would be counter-intuitive to change the value of the condition code to some other value and call that the new standard. Instead it would seem logical to use the 'not comparable' and terminate the 'if' statement. Does that make sense to you? In our example, a 'not-a-number' would be returned to the main program, without the need for an extra 'isnan()'. Mischa.
Re: not-a-number's
On 01/16/2013 01:04 PM, Robert Dewar wrote: On 1/16/2013 6:54 AM, Mischa Baars wrote: ] And indeed apparently the answer then is '2'. However, I don't think this is correct. If that means that there is an error in the C specification, then there probably is an error in the specification. The C specification seems perfectly reasonable to me (in fact it is rather familiar that x != x is a standard test for something being a NaN. The fact that you for unclear reasons don't like the C spec does not mean it is wrong! And as I have said before: if you are satisfied with the answer '2', then so be it and you keep the compiler the way it is, personally I'm am not able to accept changes to the sources anyway. I don't think it is the right answer though. Mischa.
Re: not-a-number's
On 01/16/2013 12:07 PM, Andrew Haley wrote:
On 01/16/2013 09:27 AM, Mischa Baars wrote:
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a "terminated statement". The first condition
evaluates to true.
Whatever you want, although personally I think it is very unlikely that
'2' is the correct value to return :)
Let's go through this line by line. If there's anything you disagree
with, speak up. But if you disagree that GCC has implemented C
correctly according to the standard, you must quote the relevant
sections of the document and explain your belief, not in terms of what
you think it should do, but in terms of what the standard actually
says.
Comparisons with NaN don't terminate a statement, and they don't
return a NaN. They return a boolean.
Here's what Standard C, F.8.3 Relational operators, says:
x != x → falseThe statement x != x is true if x is a NaN.
x == x → true The statement x == x is false if x is a NaN.
And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.
So:
{
double r = -NAN;
// if (!isnan(y) && !isnan(x))
// {
double a = absd(x);
double b = absd(y);
if (b != a)
If one of a or b is a NaN, the comparison is unordered, so we take this branch.
{
if (b < a)
If one of a or b is a NaN, the comparison is unordered, so it returns
false. We'll take the else branch.
{
if (b != 0) // octant 1, 4, 5 and
8 (open set)
{
r = 0;
}
else// x-axis
{
r = 1;
}
}
else
{
if (a != 0) // octant 2, 3, 6 and
7 (open set)
If a is a NaN, the comparison is unordered, so != returns true. So we
take this branch and return 2.
{
r = 2; // not-a-number's ???
}
else// y-axis
{
r = 3;
}
}
}
else// between axes
{
r = 4;
}
// }
Andrew.
Re: not-a-number's
On 01/16/2013 12:07 PM, Andrew Haley wrote:
On 01/16/2013 09:27 AM, Mischa Baars wrote:
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a "terminated statement". The first condition
evaluates to true.
Whatever you want, although personally I think it is very unlikely that
'2' is the correct value to return :)
Let's go through this line by line. If there's anything you disagree
with, speak up. But if you disagree that GCC has implemented C
correctly according to the standard, you must quote the relevant
sections of the document and explain your belief, not in terms of what
you think it should do, but in terms of what the standard actually
says.
Comparisons with NaN don't terminate a statement, and they don't
return a NaN. They return a boolean.
They shouldn't return anything, the comparison should be terminated.
Here's what Standard C, F.8.3 Relational operators, says:
x != x → falseThe statement x != x is true if x is a NaN.
x == x → true The statement x == x is false if x is a NaN.
So:
{
double r = -NAN;
This should be the value returned.
// if (!isnan(y) && !isnan(x))
// {
double a = absd(x);
double b = absd(y);
if (b != a)
Right here evaluation should be terminated, when one or both of the
arguments are NaN. The statement becomes invalid.
If one of a or b is a NaN, the comparison is unordered, so we take this branch.
{
if (b < a)
If one of a or b is a NaN, the comparison is unordered, so it returns
false. We'll take the else branch.
{
if (b != 0) // octant 1, 4, 5 and
8 (open set)
{
r = 0;
}
else// x-axis
{
r = 1;
}
}
else
{
if (a != 0) // octant 2, 3, 6 and
7 (open set)
If a is a NaN, the comparison is unordered, so != returns true. So we
take this branch and return 2.
{
r = 2; // not-a-number's ???
}
else// y-axis
{
r = 3;
}
}
}
else// between axes
{
r = 4;
}
// }
Andrew.
Re: not-a-number's
On 01/16/2013 10:06 AM, Andreas Schwab wrote: Mischa Baars writes: This means that the first 'if' statement should have been terminated when There is no such thing as a "terminated statement". The first condition evaluates to true. Whatever you want, although personally I think it is very unlikely that '2' is the correct value to return :) Furthermore, the manual states that any operation on a QNaN should return a QNaN. That is only true for arithmethic operations. A comparison always evaluates to true or false. Andreas.
Re: not-a-number's
On 01/16/2013 08:57 AM, Eric Botcazou wrote: Well, I have an Intel manual here that states that any operation on a QNaN should return a QNaN, which means that also the compare should return a QNaN when one or both of the arguments is a QNaN. No, that isn't how comparisons work. The correct result is 2 according to the comparison rules of IEEE-754. I'd suggest reading page 8 of "Lecture Notes on the Status of IEEE 754" by Kahan: http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF Well, this is just a document of another teacher, this is not the Intel manual. Please read the other mail for me with the output of the 'ftst' instruction.
Re: not-a-number's
On 01/16/2013 09:14 AM, Andreas Schwab wrote: Mischa Baars writes: Furthermore, since 'fxam' will return a 'non-comparable' during the first compare, I suppose the function should then enter the first 'else' and return a '4'. Non-comparable means that NaN != NaN is always true. Andreas. Sorry, let me correct, first I mean 'ftst' instead of 'fxam'. This is the output of 'ftst' is according to the manual: [C3 C2 C1 C0] := [1 1 x 1] when not-comparable (this is where the not-a-numbers go) [C3 C2 C1 C0] := [0 0 x 0] when st(0) > 0 [C3 C2 C1 C0] := [0 0 x 1] when st(0) < 0 [C3 C2 C1 C0] := [1 0 x 0] when st(0) = 0 This means that the first 'if' statement should have been terminated when one or both of the arguments is a QNaN, entering the 'else' would be in error. Also the second 'if' statement shouldn't be evaluated. This should also be true when the first 'if' is not enclosed by any 'isnan()'. Furthermore, the manual states that any operation on a QNaN should return a QNaN. Correct?
Re: not-a-number's
On 01/15/2013 05:24 PM, Eric Botcazou wrote: When disregarding the 'isnan()', the function is returning a '2' when one or both the arguments is a NaN. Do you suppose this is correct? If you ask me, it should exit on the first compare and thus return a not-a-number. You cannot "exit" a comparison in C, one of the branches is always taken, which means that npx_dr11_inverse_tangent_series can never return -NAN. Furthermore, since 'fxam' will return a 'non-comparable' during the first compare, I suppose the function should then enter the first 'else' and return a '4'. Mischa.
Re: not-a-number's
On 01/15/2013 05:24 PM, Eric Botcazou wrote: When disregarding the 'isnan()', the function is returning a '2' when one or both the arguments is a NaN. Do you suppose this is correct? If you ask me, it should exit on the first compare and thus return a not-a-number. You cannot "exit" a comparison in C, one of the branches is always taken, which means that npx_dr11_inverse_tangent_series can never return -NAN. Well, I have an Intel manual here that states that any operation on a QNaN should return a QNaN, which means that also the compare should return a QNaN when one or both of the arguments is a QNaN.
not-a-number's
This is what I was trying to point out: When disregarding the 'isnan()', the function is returning a '2' when one or both the arguments is a NaN. Do you suppose this is correct? If you ask me, it should exit on the first compare and thus return a not-a-number. Regards, Mischa. 2010100706 - series expansion - inverse tangent.tar.gz Description: GNU Zip compressed data
Re: bug report: not-a-number not recognized when compiling for x86_64
On 01/14/2013 03:50 PM, Marc Glisse wrote: On Mon, 14 Jan 2013, Mischa Baars wrote: When running the example attached, you can see the compiler fails to recognize not-a-number's properly. Bug reports go to bugzilla. NaN doesn't compare equal to anything. x==x is actually the usual way to test if x is NaN. Oops, sorry :) I see, I will have a different example for you later... Regards, Mischa.
bug report: not-a-number not recognized when compiling for x86_64
Hi,
When running the example attached, you can see the compiler fails to
recognize not-a-number's properly.
Anyone who would like to have a look?
Regards,
Mischa.
#include
#include
int main()
{
double x = NAN;
if (x == NAN)
{
printf("found a not-a-number\n");
}
return;
}
Re: calculation of pi
On 11/05/2012 12:26 PM, David Brown wrote: On 05/11/2012 11:33, Mischa Baars wrote: On 11/05/2012 05:55 AM, Ian Lance Taylor wrote: On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars wrote: On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: There is no "original." The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. An ABI is by definition processor specific. The placement of argument values is chosen based on runtime efficiency, not on any other sort of logic. On x86_64, 32-bit and 64-bit float values can be passed directly in registers, as the x86_64 has efficient 32-bit and 64-bit floating point registers. The x86_64 does not have floating point registers that can efficiently store floating point values with more than 64 bits, so those values are not passed in floating point registers. To make any other choice would cost runtime efficiency, which is the only logic that matters. Ian Hi Ian, Here I have attached the code that proves that you are wrong, the 64-bit code gets slower and not faster while passing arguments in 'xmm0' when loading arguments in the floating point core for processing, i.e. transcendental functions like 'fsin' which can't be done using 'sse' instructions. For the extended real numerical type, the argument cannot even be passed in 'xmm0' since there are no 'sse' instructions for extended real numbers, which makes the passing of arguments in 64-bit mode very inconsistent as you can see. Regards, Mischa. Hi, I think you are still misunderstanding the situation here. Floating point arguments are not passed in the xmm registers "because Ian thinks it's faster". They are passed in the xmm registers because that is the ABI that was agreed on long ago by a group of experienced experts involved in the design of the processor (the 64-bit AMD processors, since they pre-dated Intel's 64-bit x86 chips), compiler design, and operating system design (since it is the ABI for 64-bit x86 Linux we are discussing). It is quite possible that Ian was part of that group - he is an "experienced expert" - but it was not his decision. And it is /not/ going to change. The ABI is fixed - you have to live with it. I'm sure there are many aspects of the 32-bit x86 ABI that people would like to change, since it was fixed in stone before features like xmm registers were part of the x86 cpus. But that doesn't happen - you have to keep the ABI consistent. For purely internal code - static functions without external linkage - the compiler can use whatever calling conventions it wants. If you think that such calls could be done better, then that can be discussed or filed as "missed optimisation" bug reports. In the particular case of passing floating point arguments, of course, the extra step needed to move data from an xmm register onto the stack for the "fsin" code is totally negligible. The great majority of floating point operations /are/ handled by SSE instructions, since operations such as load, store, register move, and basic arithmetic outweigh the use of transcendental functions by many orders of magnitude. You do not change the ABI used by an entire operating system to shave a few clock cycles off an unusual piece of test code to calculate pi. mvh., David Then it will probably will not hurt you either when you run this 'unusual piece of test code' on your 'entire operating system' :) Mischa. 2012110501 - division by zero.tar.bz2 Description: application/bzip
Re: calculation of pi
On 11/05/2012 05:55 AM, Ian Lance Taylor wrote: On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars wrote: On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: There is no "original." The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. An ABI is by definition processor specific. The placement of argument values is chosen based on runtime efficiency, not on any other sort of logic. On x86_64, 32-bit and 64-bit float values can be passed directly in registers, as the x86_64 has efficient 32-bit and 64-bit floating point registers. The x86_64 does not have floating point registers that can efficiently store floating point values with more than 64 bits, so those values are not passed in floating point registers. To make any other choice would cost runtime efficiency, which is the only logic that matters. Ian Hi Ian, Here I have attached the code that proves that you are wrong, the 64-bit code gets slower and not faster while passing arguments in 'xmm0' when loading arguments in the floating point core for processing, i.e. transcendental functions like 'fsin' which can't be done using 'sse' instructions. For the extended real numerical type, the argument cannot even be passed in 'xmm0' since there are no 'sse' instructions for extended real numbers, which makes the passing of arguments in 64-bit mode very inconsistent as you can see. Regards, Mischa. 2012110500 - arguments.tar.bz2 Description: application/bzip
Re: calculation of pi
On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: On Sat, Nov 3, 2012 at 12:55 AM, Mischa Baars wrote: On 11/02/2012 07:11 PM, Ian Lance Taylor wrote: On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars wrote: I have been writing this piece of example code, but it seems that someone has been modifying the compiler in the meantime such that arguments are now passed in xmm registers instead of over the stack. Also the npx top of stack pointer isn't handled alike for all three different types of real numbers on function return any more. I have not looked at your code. However, I can tell you that on 32-bit x86 floating point function arguments are normally passed on the stack and on 64-bit x86 floating point arguments are normally passed in the xmm registers. There are various ways that you can change this default behaviour, but if you are seeing an unexpected change then I would guess that you changed from 32-bit compilation to 64-bit compilation. Ian By the way, it seems this only holds for single and double real numbers. These are indeed passed in xmm registers, the long double however is still passed over the stack. Yes. Do we have any compiler options that change this behaviour back to the original? The default behaviour in 64-bit mode is not even the same for all real number types. There is no "original." The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Ian Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. Mischa.
Re: calculation of pi
On 11/03/2012 12:41 PM, Tim Prince wrote: On 11/3/2012 3:32 AM, Mischa Baars wrote: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory which also prevents me from compiling the compiler under Fedora 17. This means that I am both not able to compile programs in 32-bit mode and help you with the compiler. Normally, this means you didn't install the optional (32-bit) glibc-devel i386. Yes, you are right! You need to install both 'glibc-devel.i686' and 'libgcc.i686', however you need to do this manually with 'yum' because they do not appear on the list of installable packages with the 'add/remove software' applet. Mischa.
Re: calculation of pi
On 11/02/2012 07:11 PM, Ian Lance Taylor wrote: On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars wrote: I have been writing this piece of example code, but it seems that someone has been modifying the compiler in the meantime such that arguments are now passed in xmm registers instead of over the stack. Also the npx top of stack pointer isn't handled alike for all three different types of real numbers on function return any more. I have not looked at your code. However, I can tell you that on 32-bit x86 floating point function arguments are normally passed on the stack and on 64-bit x86 floating point arguments are normally passed in the xmm registers. There are various ways that you can change this default behaviour, but if you are seeing an unexpected change then I would guess that you changed from 32-bit compilation to 64-bit compilation. Ian By the way, it seems this only holds for single and double real numbers. These are indeed passed in xmm registers, the long double however is still passed over the stack. Do we have any compiler options that change this behaviour back to the original? The default behaviour in 64-bit mode is not even the same for all real number types. Mischa.
Re: calculation of pi
On 11/02/2012 07:11 PM, Ian Lance Taylor wrote: On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars wrote: I have been writing this piece of example code, but it seems that someone has been modifying the compiler in the meantime such that arguments are now passed in xmm registers instead of over the stack. Also the npx top of stack pointer isn't handled alike for all three different types of real numbers on function return any more. I have not looked at your code. However, I can tell you that on 32-bit x86 floating point function arguments are normally passed on the stack and on 64-bit x86 floating point arguments are normally passed in the xmm registers. There are various ways that you can change this default behaviour, but if you are seeing an unexpected change then I would guess that you changed from 32-bit compilation to 64-bit compilation. Ian Probably I have. But when I pass the -m32 parameter I get an unexpected error: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory which also prevents me from compiling the compiler under Fedora 17. This means that I am both not able to compile programs in 32-bit mode and help you with the compiler. Is there a solution and what are the exact alternatives you refer to? Mischa
calculation of pi
Hi, I have been writing this piece of example code, but it seems that someone has been modifying the compiler in the meantime such that arguments are now passed in xmm registers instead of over the stack. Also the npx top of stack pointer isn't handled alike for all three different types of real numbers on function return any more. Assistance would be appreciated. Regards, Mischa. 2011071802 - series expansion (pi).tar.bz2 Description: application/bzip
website update
Hi, I just wanted to let you know, I've updated my website at: http://www.cyberfiber.org, hope you don't mind me notifying you. Hope you people can fine-tune both the compiler and the assembler during development, otherwise I will have to migrate to Microsoft Windows in the near future. Let me know, Regards, Mischa.
macro's and arguments
Hi, Who will be fixing this? Macro arguments without brackets are not accepted by the assembler. If I can be of any help, let me know. Thanks, Mischa. .intel_syntax noprefix .global function .code64 .macro A arg1, arg2 mov ax, \arg1 mov bx, \arg2 .endm .macro B .seti, 0 .rept 4 // A i + i, i * i A (i + i), (i * i) .seti, i + 1 .endr .endm function: B
macro's and arguments
Hi, Who will be fixing this? Macro arguments without brackets are not accepted by the assembler. If I can be of any help, let me know. Thanks, Mischa.
Re: macro's and local variables
Hi, If you look at them more closely, you will see that the two different macro's give different answers to the same problem. If you like, I will retry at gcc-h...@gcc.gnu.org, although I suppose binut...@sourceware.org should be having a copy too. Thanks, Mischa. On 10/13/2012 02:03 AM, Jonathan Wakely wrote: On 12 October 2012 22:43, Mischa Baars wrote: Hi All, Who can take a first look at this in the morning? Hi, I looked, they seem to be some files. Nice. If you want people to look at them properly you should probably send them to the gcc-help list and explain why you want people to look at them.
macro's and local variables
Hi All, Who can take a first look at this in the morning? Thanks, Mischa. function.o: file format elf64-x86-64 Disassembly of section .text: : 0: c3 ret function.o: file format elf64-x86-64 Disassembly of section .text: : 0: 66 bb 00 00 movbx,0x0 4: 66 bb 00 00 movbx,0x0 8: 66 bb 01 00 movbx,0x1 c: 66 bb 00 00 movbx,0x0 10: 66 bb 01 00 movbx,0x1 14: 66 bb 02 00 movbx,0x2 18: c3 ret .intel_syntax noprefix .global function .code64 .macro A arg1 .seti, 0 .rept \arg1 mov ax, i .seti, i + 1 .endr .endm .macro B arg1 .setj, 0 .rept \arg1 mov bx, j .setj, j + 1 .endr .endm .macro C .seti, 0 .rept 4 // A i B i .seti, i + 1 .endr .endm function: C ret
Passing 64-bit function arguments to assembler
Hi, Here's a possible bug in the compiler: As can be seen from the objdump output, 64-bit arguments are passed in 32-bit registers 0040049c : 40049c:55 push rbp 40049d:48 89 e5 movrbp,rsp 4004a0:be 44 44 00 00 movesi,0x 4004a5:bf 33 33 00 00 movedi,0x 4004aa:e8 05 00 00 00 call 4004b4 4004af:90 nop 4004b0:5d poprbp 4004b1:c3 ret 4004b2:66 90xchg ax,ax also the opcodes on line 4004AF and 4004B2 seem obsolete. Best Regards, Mischa. ./a.out: file format elf64-x86-64 Disassembly of section .init: 00400358 <_init>: 400358: 48 83 ec 08 subrsp,0x8 40035c: e8 5b 00 00 00 call 4003bc 400361: 48 83 c4 08 addrsp,0x8 400365: c3 ret Disassembly of section .plt: 00400370 <__libc_start_main@plt-0x10>: 400370: ff 35 ca 04 20 00 push QWORD PTR [rip+0x2004ca] # 600840 <_GLOBAL_OFFSET_TABLE_+0x8> 400376: ff 25 cc 04 20 00 jmpQWORD PTR [rip+0x2004cc] # 600848 <_GLOBAL_OFFSET_TABLE_+0x10> 40037c: 0f 1f 40 00 nopDWORD PTR [rax+0x0] 00400380 <__libc_start_main@plt>: 400380: ff 25 ca 04 20 00 jmpQWORD PTR [rip+0x2004ca] # 600850 <_GLOBAL_OFFSET_TABLE_+0x18> 400386: 68 00 00 00 00 push 0x0 40038b: e9 e0 ff ff ff jmp400370 <_init+0x18> Disassembly of section .text: 00400390 <_start>: 400390: 31 ed xorebp,ebp 400392: 49 89 d1movr9,rdx 400395: 5e poprsi 400396: 48 89 e2movrdx,rsp 400399: 48 83 e4 f0 andrsp,0xfff0 40039d: 50 push rax 40039e: 54 push rsp 40039f: 49 c7 c0 50 05 40 00movr8,0x400550 4003a6: 48 c7 c1 c0 04 40 00movrcx,0x4004c0 4003ad: 48 c7 c7 9c 04 40 00movrdi,0x40049c 4003b4: e8 c7 ff ff ff call 400380 <__libc_start_main@plt> 4003b9: f4 hlt 4003ba: 66 90 xchg ax,ax 004003bc : 4003bc: 48 83 ec 08 subrsp,0x8 4003c0: 48 8b 05 69 04 20 00movrax,QWORD PTR [rip+0x200469] # 600830 <_DYNAMIC+0x1d0> 4003c7: 48 85 c0test rax,rax 4003ca: 74 02 je 4003ce 4003cc: ff d0 call rax 4003ce: 48 83 c4 08 addrsp,0x8 4003d2: c3 ret 4003d3: 66 2e 0f 1f 84 00 00nopWORD PTR cs:[rax+rax*1+0x0] 4003da: 00 00 00 4003dd: 0f 1f 00nopDWORD PTR [rax] 004003e0 : 4003e0: b8 67 08 60 00 moveax,0x600867 4003e5: 55 push rbp 4003e6: 48 2d 60 08 60 00 subrax,0x600860 4003ec: 48 83 f8 0e cmprax,0xe 4003f0: 48 89 e5movrbp,rsp 4003f3: 77 02 ja 4003f7 4003f5: 5d poprbp 4003f6: c3 ret 4003f7: b8 00 00 00 00 moveax,0x0 4003fc: 48 85 c0test rax,rax 4003ff: 74 f4 je 4003f5 400401: 5d poprbp 400402: bf 60 08 60 00 movedi,0x600860 400407: ff e0 jmprax 400409: 0f 1f 80 00 00 00 00nopDWORD PTR [rax+0x0] 00400410 : 400410: b8 60 08 60 00 moveax,0x600860 400415: 55 push rbp 400416: 48 2d 60 08 60 00 subrax,0x600860 40041c: 48 c1 f8 03 sarrax,0x3 400420: 48 89 e5movrbp,rsp 400423: 48 89 c2movrdx,rax 400426: 48 c1 ea 3f shrrdx,0x3f 40042a: 48 01 d0addrax,rdx 40042d: 48 89 c6movrsi,rax 400430: 48 d1 fesarrsi,1 400433: 75 02 jne400437 400435: 5d poprbp 400436: c3 ret 400437: ba 00 00 00 00 movedx,0x0 40043c: 48 85 d2test rdx,rdx 40043f: 74 f4 je 400435 400441: 5d poprbp 400442: bf 60 08 60 00 movedi,0x600860 400447: ff e2 jmprdx 400449:
unsigned integers and the calculation of PI
Hi All, I'm trying to verify the 'fldpi' instruction on the Intel Processor. Hope you would like to have a look at the following piece of example code? Best Regards, Mischa. http://www.cyberfiber.org/sites/default/files/2012020314%20-%20algorithms%20on%20the%20intel%20processor%20-%20unsigned%20integers%20of%20extended%20order%20_64-bit_.tar.bz2
