From: groepaz (groepaz_at_gmx.net)
Date: 2002-05-23 00:39:03
Hello Ullrich, Wednesday, May 22, 2002, 9:01:35 PM, you wrote: UvB> Hi! UvB> 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. UvB> The difference is that the graphics interface is not covered by a standard UvB> while floating point arithmetic is. so thats the accuracy argument again? or what else? errno? ;=P >> 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. UvB> When talking about C, portability means adhering to the standard. If libraries UvB> differ from the standard they are not portable. yes, and like mentioned before - if you really ever need standard compliance you could always drop in your own standard-compliant routines. i am just saying that for most reallife programs (those you could compile using cc65 atleast) wont really suffer from the little differences. its just the same as using file i/o that cannot seek or termio that cant handle all attributes (or substitutes them for that matter). it will perfectly work for a lot, if not most, applications - and these applications will even be (well can be, theres always a way to screw things up ;)) perfectly portable. problems arise when you try to port a program originally written for a full standard compliant lib, and which additionally excessivly uses its features. seeking to fileend to get filesize is just as bad as rather trivial code that relies on the least significant bit of some float number :=) UvB> [writing a fp library] >> yeah, a theoretically nice, but practically unuseable solution. slow >> and large.... sounds like windoze(tm) to me ;=P UvB> So where is the proof that the ROM routines are faster than something written UvB> by someone else? Steve Judd once mentioned that he was writing a floating UvB> point library, and I would bet a craddle of beer against a bottle of mineral UvB> water that his routines would blow the C64 ROM routines to pieces (speedwise). UvB> The space argument is more valid, but I will not judge about that before I've UvB> seen how large such floating point routines would be. common logic: kernal routines are VERY large. for once, you dont ever want routines that are even larger (well actually, you dont even want routines in ram that are half their size). like i said, the kernal pulls a dozen stunts already to keep the code short (and ofcoz,these stunts are what makes the code sloooow). there's no doubt someone could write an fp-emulator that is faster than the rom - but for damn sure even those eat-math-for-breakfast guys like stephen can't make them faster and at the same time not make them (a lot) larger :) the only way to make those faster (without making them larger) is to remove the unnecessary overhead from packed basic-variables, and to remove accuracy. >> the point is, theres no point in makeing _the library_ portable - >> except for the heck of it. UvB> A portable library means that the interface is portable. A portable interface UvB> means an interface that adheres to the C standard. And the ROM routines do NOT UvB> adhere to the C standard, so they are NOT portable. well yes and no :o) thats why i suggested using "real" (IEEE) floats in the compiler internally, and use IEEE for internal conversion and arithmetics, but apart from that let the assembler know about different targets formats (and also IEEE for that matter) - and then simply spill calls to a standard fp-emulator interface.... this way the compiler doesnt even need to know about how floats are implemented. (and it always simplifies internal calculations to be standard compliant). done that, one could probably come up with modules like that 2-bytes floats i used once, or also a full IEEE float/double emulator. and yes, standard compliant programs that expect floats to work as in IEEE could maybe fail to work at all with the kernal-float module - fully aware of that. UvB> Maybe you can explain how you come to these numbers? I hear you talking, but I UvB> start wondering if we are talking about the same thing :-) same for me ;=P as far as i understand we are both concerned about different things at all - you want your compiler to act standard-compliant, and by all means to work as one would expect from any other "big" compiler - i want the compiler to spit out the best possible code, and i prefer non standard compliant, but existant solutions over no solution at all. so the real question is, how can the user (me) use his non-standard libraries with your compiler without the need of adding "ugly" stuff to the compiler that potentially breaks the standard ? well i am repeating myself - the compiler should basically not even need to know, the assembler would. (and target specific float support in the assembler should really be neither "ugly" nor hard to do.) -- Best regards, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- 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-23 00:39:33 CEST