From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-03-10 11:42:14
On Sun, Mar 09, 2003 at 04:58:38PM -0800, David Holz wrote: > What I meant is if there's a good 6502 FP library available that doesn't use > exactly the IEEE binary representation. So we aren't talking about a faster implementation but just about a non standard one? I like standards and interoperability, and IMHO the development of cc65 has proven that this has a lot of advantages. A non standard implementation is worth a look, but I don't think that "being available" as the only advantage is enough reason to include something into cc65. Especially since there's also a lot of work to be done in the compiler proper, and this work doesn't benefit from an existing fp library (which means that an existing library doesn't save 100% of all the work needed). If you could add "being considerably faster" to the "being available" argument, the situation might look different - however as several people have stated here, a 6502 is no number cruncher, so it doesn't matter a lot if floating point math is slow. I'm sure, there are several reasons why cc65 is the most popular C compiler for 6502 targets, despite the fact that the generated code could be a lot better. However, one reason for this popularity is definitely that cc65 adheres to standards and that portability (for which standards are the foundation) plays an important role in development. People have used cc65 to write code for embedded 6502 targets, other people have added new targets by just rewriting a few assembler modules. If you look at other C compilers out there (I know two of them: Bastian Schicks cc65 port for the Lynx and a port of lcc for the 6502 which is only available for the Oric), you will notice that these have never made it out of their respective niches. One important reason is that portability (which is always based on standards) has never played a role in development. What I want to say with all this (I've expressed this many times, but let me repeat it): Standard compliance and portability is not an add on for me. I don't ask "do we have any important reasons to make it portable?" as many other people seem to do. What I'm asking is: "Do we have any important reasons to make it NON portable?" I'm doing this because I consider standards and portability a worthwhile goal by itself, and anyone going to ignore this goal should have a good reason to do so. This is the explanation why I want to have IEEE routines if possible. Of course, having a math library that is considerably faster may be a reason to ignore standards in this case, but without some hard numbers proving this fact, I'm not willing to give up standards. > > Here's another one: The standard specifies explicitly how the different > > situations should be handled, so it is easy to diagnose if there are > problems > > with the implementation, and a user knows exactly what he can expect. > > > If those situations are met, but the binary representation isn't exactly > IEEE, it should still work, right? I don't know what exactly you mean with that. The IEEE specs define exactly how fp numbers behave, which accuracy can be expected, which errors can happen and how they are handled (in fact, there are several options as far as I remember). So you can point people to the standard, and if there is a problem, you need just one look into the standard to tell if this is a problem with the implementation or with the programmer/user. Considering your special floating point implementation, you would have to write up a document telling all the math theory behind your numbers, and how they should behave in different situations. Since this is the only specification, this document has to come with cc65, so people can look things up in case of problems. > Right, so SIGFPE is Posix or somesuch, but you can implement any error > mechanism you want (well, besides crashing ;) ) and still be C compliant? You cannot implement any error mechanism you want. I haven't read the whole chapter in the standard, but it seems there are required things (returning a special implementation defined value), and some optional ones (setting errno/raising a signal). The standard requires you to implement the required ones and allows you to implement one or more of the optional ones. Regards Uz -- Ullrich von Bassewitz uz_at_musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-03-10 11:42:36 CET