Date: Sat, 31 May 1997 12:03:38 -0800 (AKDT) From: Steve Howe <un_x@anchorage.net> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-hackers <hackers@FreeBSD.ORG> Subject: Re: Borland 16bit bcc vs cc/gcc (float) Message-ID: <Pine.BSF.3.95q.970531110640.5177A-100000@aak.anchorage.net> In-Reply-To: <19970531092837.DA51579@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 31 May 1997, J Wunsch wrote: > Well, you should perhaps have posted the expected output... instead of ok, without posting the code again, the output is below. > I'm not much surprised that the use of non-standard components (long > double) produces unexpected results. > You multiply a long double with a double (result of pow()) what's non-standard about long double? they're standard ANSI C types ... ? much of my software relies on this precision - i can't do 64 bit int-to-string-to-int conversions without them, at least not cleanly, and not without alot of code re-writing. > it by first extending the result of pow() to long double format (thus > `inventing' missing precision digits), or by first truncating the long > double (although i wouldn't expect this)? i'm sorry - i'm lost. i know Borland 16-bit C uses 80-bit long doubles. from gcc sizeof(), i get 96 bits for BSD doubles (8 bytes), and 144 bits for BSD long doubles (12 bytes). so even with BSD doubles, i should get better precision, ... i assume. > > void main (unsigned char argc, unsigned char **argv) { > Don't get caught in comp.lang.c with this. :) It's an invalid > definition of main, thus the behaviour is implementation-dependant. > gcc could have exited immediately without violating the standard. ahhh! :) everyone says this - but exit() never returns, so main never returns anything, so IMHO, main should always be type void. > Also, your blatant use of unsigned char for everything doesn't look > right. At least with gcc, using an unsigned char as a loop index > counter isn't doing any good and is likely to slow down your code. It > doesn't save space at all, since (i think) %dh, %dl, and %edx are all > a single register for gcc, regardless of how many bits you're using. yes, i know. but this is code i'm porting! apple2 -> msdos -> bsd (it's been around :) plus, there are other reasons (shifting, etc.) i work on many systems, including embedded XT's. > -- > cheers, J"org thanks. as you can see below, DOS long doubles and powl() keep all my accuracy ... whereas BSD can't even subtract 9 from 18446744073709551616.000000. please help me! :) > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) BSD - ffffffffffffffff 15.000000 - ffffffffffffffff 255.000000 - ffffffffffffffff 4095.000000 - ffffffffffffffff 65535.000000 - ffffffffffffffff 1048575.000000 - ffffffffffffffff 16777215.000000 - ffffffffffffffff 268435455.000000 - ffffffffffffffff 4294967295.000000 - ffffffffffffffff 68719476735.000000 - ffffffffffffffff 1099511627775.000000 - ffffffffffffffff 17592186044415.000000 - ffffffffffffffff 281474976710655.000000 - ffffffffffffffff 4503599627370495.000000 - ffffffffffffffff 72057594037927936.000000 <- loss of precision - ffffffffffffffff 1152921504606846976.000000 - ffffffffffffffff 18446744073709551616.000000 + 18446744073709551616.000000 + 18446744073709551616.000000 (this should be the result above - 9) - 0fffffffffffffff 18446744073709551616.000000 - 00ffffffffffffff 1152921504606846976.000000 - 000fffffffffffff 72057594037927936.000000 - 0000ffffffffffff 4503599627370496.000000 - 00000fffffffffff 281474976710656.000000 - 000000ffffffffff 17592186044416.000000 - 0000000fffffffff 1099511627776.000000 - 00000000ffffffff 68719476736.000000 - 000000000fffffff 4294967296.000000 - 0000000000ffffff 268435456.000000 - 00000000000fffff 16777216.000000 - 000000000000ffff 1048576.000000 - 0000000000000fff 65536.000000 - 00000000000000ff 4096.000000 - 000000000000000f 256.000000 - 0000000000000000 16.000000 - 00000000000000001 1.000000 10000000000000000 DOS - ffffffffffffffff 15.000000 - ffffffffffffffff 255.000000 - ffffffffffffffff 4095.000000 - ffffffffffffffff 65535.000000 - ffffffffffffffff 1048575.000000 - ffffffffffffffff 16777215.000000 - ffffffffffffffff 268435455.000000 - ffffffffffffffff 4294967295.000000 - ffffffffffffffff 68719476735.000000 - ffffffffffffffff 1099511627775.000000 - ffffffffffffffff 17592186044415.000000 - ffffffffffffffff 281474976710655.000000 - ffffffffffffffff 4503599627370495.000000 - ffffffffffffffff 72057594037927935.000000 - ffffffffffffffff 1152921504606846975.000000 - ffffffffffffffff 18446744073709551615.000000 + 18446744073709551616.000000 + 18446744073709551605.000000 - ffffffffffffffff 18446744073709551615.000000 - ffffffffffffffff 1152921504606846975.000000 - ffffffffffffffff 72057594037927935.000000 - ffffffffffffffff 4503599627370495.000000 - ffffffffffffffff 281474976710656.000000 - ffffffffffffffff 17592186044415.000000 - ffffffffffffffff 1099511627775.000000 - ffffffffffffffff 68719476735.000000 - ffffffffffffffff 4294967295.000000 - ffffffffffffffff 268435455.000000 - ffffffffffffffff 16777215.000000 - ffffffffffffffff 1048575.000000 - ffffffffffffffff 65535.000000 - ffffffffffffffff 4095.000000 - ffffffffffffffff 255.000000 - ffffffffffffffff 15.000000 ffffffffffffffff ------------------------------------------------------------------------- Sleep: a sign a caffeine deprivation ... http://www.anchorage.net/~un_x -------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970531110640.5177A-100000>