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