From: groepaz (groepaz_at_gmx.net)
Date: 2002-05-21 19:48:49
Hello Ullrich, UvB> If we can bring this into a shape where it works across all target system, UvB> that would ok for me. mmmmh that shouldnt be a major problem.... except that not all targets might offer all kinds of interupts (most may have a raster- and timer- interupt though) >> uhmz... dont have the actual file handy atm (not at home) but its got >> everything that is available in the kernal: UvB> Bad word: kernal :-) eh? its THE key to short code on any embedded system AFAIK :=P Also codesize is one of the MAJOR concerns when using cc65, so for heavens sake i'd say use the kernal whenever possible. how is that issue different from stuff like disc/file i/o for example? UvB> Remember: cc65 is not C64 only. I know that it seems wasteful to add extra UvB> floating point routines if there is already something like that in the (C64-) UvB> kernal, but there are other platforms that don't have floating point support UvB> in a ROM. well its perfectly portable across all cbm-machines - and AFAIK all kernals of other homecomputers have some kind of floating-point support in their kernals aswell so simelar wrappers could be written. and if they dont have, you are still free to write a complete solution yourself. not using the c64's (or cbm's for that matter) kernal because of that reason would mean adding in a KB or more of code just for that one or two floating-point variables your code uses. and that IS wasteful, actually it makes floats completely useless when the code needed to support them is larger than the table i wanted to calculate by using them. UvB> There may also be platforms that have a different floating point UvB> format/interface. yes indeed, and NOT supporting those (thats what you are suggesting by saying one should create a standalone generic version) would lower the actual usefulness of floats a LOT. any assembler coder who has used floats before probably has a bunch of useful routines laying around which do OFCOZ interface to the kernal and use its floating-point format aswell - not only c64 coders i bet my arse :=) UvB> For example, how do you expect printf to work consistent, if UvB> some kernal function is called for float -> string conversion? one thing i learned when programming C is that you generally DONT expect printf to work even close to consistent ;=P moreover, that statement is true when using floats in printf :=)) however, a non-consistant string conversion is still better than none - and you could ofcoz always create your own 100% standard compliant routine once you really need it. UvB> And, if you UvB> decide to code this separately, how do you deal with different floating point UvB> formats? easy (more or less) if the assembler knows about the specific target-format... let the compiler handle them as "real" floats and make the assembler support some directive ".float" that works simelar to ".byte" but which inserts a floating-point number in the format of the selected target. that could even achive compatibility on assembler level and only the actual routines doing arithmetics on them would need to be target-specific. UvB> And at least, there's a good chance that the kernal routines will not UvB> work like expected by the C standard. yes, true - but who carez? there may be a loss of precision and maybe the one or other really minor thing - but would it really seriously break any code? its not like you would be porting that old 3d engine of yours which requires floats to be perfectly accurate. you arent really seriously suggesting to implement a full IEE compliant floating-point emulator that passes all tests are you ? That may be a nice tech-demo, but completely useless for real use (large and slow, just what we like ,=P) i do however not see your problem at all.... if the assembler knows about the targets float-format and the compiler spills calls to the floating-point routines accordingly, you could easily support that "non accurate" kernal stuff and a real, standard compliant (and dead slow ;=P) library aswell - without even bothering about how these libraries are actually implemented, how (or if) they work and what kind of float-format they use - that should all be up to the user imho. -- 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-21 19:47:45 CEST