X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Trace-PostClient-IP: 68.147.131.211 From: Brian Inglis Newsgroups: comp.os.msdos.djgpp Subject: Re: Cross Platform Incompatabilites? - code fragments Organization: Systematic Software Message-ID: <1t3a30d4ia5mq2vqnqqofhopqkqreafpu4@4ax.com> References: <3 DOT 0 DOT 1 DOT 16 DOT 20040216231142 DOT 38e7a7cc AT earthlink DOT net> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 57 Date: Thu, 19 Feb 2004 20:02:30 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse AT shaw DOT ca X-Trace: pd7tw2no 1077220950 24.71.223.147 (Thu, 19 Feb 2004 13:02:30 MST) NNTP-Posting-Date: Thu, 19 Feb 2004 13:02:30 MST To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Mon, 16 Feb 2004 23:11:42 -0500 in comp.os.msdos.djgpp, Ethan Rosenberg wrote: >Dear Listmembers - > > >MUCH THANKS IN ADVANCE FOR ANY AVICE WHICH WILL BE GIVEN. > >>Does that mean that the modified program produces _exactly_ the same >>results as before, on each platform? Or do you see any changes in the >>results with the _CRT0_FLAG_FILL_DEADBEEF bit set? > >No change wantsoever!!! > > >The following are code FRAGMENTS from the program. My feelings are that >the error is in the integration routine. etot is defined as FLOAT. > >I have extracted these fragments for a program of approx. 3000 lines of >code. I hope I am not burdening you with too much. In general, most programmers should not use 32 bit float for arithmetic, unless they do careful analysis and coding of algorithms to avoid the *SEVERE* loss of precision that can occur in just a single operation with unfortunate values. A simple example of this would be when you do accumulation in float: you need to sort and add up the numbers from smallest to largest absolute value to avoid losing the effect of small values totally. If you can enable precision loss reporting in your program, with a compiler switch or library function call, you may find that's occurring all over the place on the problem platform. Some compilers (many if you set the right options) may effectively ignore the float definition, may carry out all the calculations in double or long double, and particularly at high optimization levels, may keep the values in floating point registers, and never truncate the value to float precision, except possibly during output conversion. OTOH particularly if you compile with debugging enabled (-g), all results may be stored and reloaded from memory locations on every operation, resulting in bit loss on every operation, especially on register poor platforms like i86 systems. You can also often force this if you can set FP precision control to force 32 bit float results on every operation, using a compiler switch or library function call. Some libraries and OSes have suffered from not properly saving and/or restoring the complete FP register status: around calls that are known to trash the registers; from being unable to detect that a program is using FP; or just buggy code. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian DOT Inglis AT CSi DOT com (Brian dot Inglis at SystematicSw dot ab dot ca) fake address use address above to reply