From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-05-22 21:01:35
Hi!
On Wed, May 22, 2002 at 03:15:01PM +0200, groepaz wrote:
> so you are saying that for example a grafics-library should contain
> only portable routines, and one target-specific setpixel routine?
> and if not, please explain whats different between that and the floats
> coz i just dont get it.
The difference is that the graphics interface is not covered by a standard
while floating point arithmetic is.
> we arent talking about writing a portable program (and yes i agree to
> what you were saying when it comes to that), we are talking about
> writing libraries used to compile the portable program => totally
> different thing.
When talking about C, portability means adhering to the standard. If libraries
differ from the standard they are not portable.
[writing a fp library]
> yeah, a theoretically nice, but practically unuseable solution. slow
> and large.... sounds like windoze(tm) to me ;=P
So where is the proof that the ROM routines are faster than something written
by someone else? Steve Judd once mentioned that he was writing a floating
point library, and I would bet a craddle of beer against a bottle of mineral
water that his routines would blow the C64 ROM routines to pieces (speedwise).
The space argument is more valid, but I will not judge about that before I've
seen how large such floating point routines would be.
> the point is, theres no point in makeing _the library_ portable -
> except for the heck of it.
A portable library means that the interface is portable. A portable interface
means an interface that adheres to the C standard. And the ROM routines do NOT
adhere to the C standard, so they are NOT portable.
> i would however prefer a compiler that produces the best code possible
> - not one whose libraries sourcecode looks most beautiful. thats just
> a non argument.
Doing floating point on a 6502 system is stupid anyway, no serious program
will use it. And the not so serious programs will not be hurt by the few
additional bytes needed.
> i disassembled the entire kernal routines for that matter... those are
> large and slow already, and they provide less accuracy then IEE would
> require.
Are you sure about that? As far as I know, both the CBM implementation and the
IEEE 32 bit format have an almost identical precision, the differences are in
the internal representation, and some border conditions.
> whythehell would i
> even consider using IEE floats here? to bloat my code and make it 10
> times slower?
Maybe you can explain how you come to these numbers? I hear you talking, but I
start wondering if we are talking about the same thing :-)
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 : 2002-05-22 21:01:50 CEST