From: groepaz (groepaz_at_gmx.net)
Date: 2002-05-22 15:15:01
Hello Ullrich, Wednesday, May 22, 2002, 9:15:17 AM, you wrote: UvB> Hi! UvB> On Tue, May 21, 2002 at 07:48:49PM +0200, groepaz wrote: >> how is that issue different from stuff like disc/file i/o for example? UvB> IMHO the problem is in the way you're using to achieve the desired result. If UvB> you want some library to be portable, it is the wrong way, to write a UvB> collection of highly system dependent modules and then try to make it portable UvB> afterwards. With a few rare exceptions this will not work, or will be quite UvB> ugly at least. If you start with portable code and then try to make it faster UvB> by using system dependent stuff, the result will be much better. UvB> The real world gives you many examples for this: If you start coding a program UvB> that should end up to be ported to several platforms, probably the worst idea UvB> of all would be to go ahead and code it using Visual Studio for Windows and UvB> MFC. There are (some) programs that started like this and were ported to other UvB> platforms, and all these programs suck. myohmyohmy 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. 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. and yes i know its nice to have portable libraries aswell, but you know it yourself that most libraries cant be portable at all - except they dont cover any system-specific tasks (say sound, say grafics, say i/o). the only difference i can see for the floats here would be that they are _usually_ not such a target-specific thing, although also there have been exceptions to the rule in the past. UvB> The approach I suggest is to write a portable library first. If you can use UvB> system depdendent stuff later to make it faster and shorter: good! If not, UvB> then you do still have a solution that works on all platforms. yeah, a theoretically nice, but practically unuseable solution. slow and large.... sounds like windoze(tm) to me ;=P (however the "knock something up that works everywhere and if you cant improve it later so be it" thing reminds me of linux desktop ;=DDD) UvB> I admit that in theory, your approach and mine should both achieve the same UvB> results. But I've tried both ways myself, and my experience is that - starting UvB> with something unportable - it is much more difficult to make it portable UvB> later. the point is, theres no point in makeing _the library_ portable - except for the heck of it. 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. >> 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. UvB> The situation would be the same as with ints or longs: If you use float UvB> multiplication, the linker would add the necessary routine and may be some UvB> support stuff, but nothing else. So you pay only for the stuff, you do really UvB> use. yes ofcoz, i know.... that still means that in whatever reallife situation that needs one or two floats for certain calculation you need to include almost the full floatingpoint emulator (minus the trig. functions obviously which arent really part of the emulator anyway). >> 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> This is not enough. The C standard requires, that computations done in the UvB> compiler generate the same results as computations done at runtime - which UvB> does usually mean that the compiler MUST use the same float representation as UvB> the target machine. UvB> If you're using IEEE floats for example, this is not a problem, since most UvB> of todays platforms use it. If the compiler has to emulate all of the UvB> different and non standard floating point formats, this would be - uhmm - UvB> "inconvenient" :-) again, noone will go port that highly accurate 3d engine to some old 8bit machine. thats a pretty theoretical accuracy argument that would for 99.9% never break any reallife code. and again, if you really need that accuracy, you may still snap in your fully standard compliant IEE float emulator. >> you arent really seriously suggesting to implement a full IEE >> compliant floating-point emulator that passes all tests are you ? UvB> Yes, I do. *ouch* UvB> Why do you expect such a library to be slower than what the CBM kernal has? i disassembled the entire kernal routines for that matter... those are large and slow already, and they provide less accuracy then IEE would require. so yes, i really expect routines that deal with more data to be even slower and probably larger aswell. the kernals routines already make more than one stunt to achive their relativly small codesize - which is still quite large comparing to other routines. btw talking of accurracy.... even a stripped down version of the kernal routines (2 byte floats) worked perfectly fine and accurate enough for me in quite a bunch of programms..... whythehell would i even consider using IEE floats here? to bloat my code and make it 10 times slower? -- 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-22 15:14:20 CEST