From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-05-22 09:15:17
Hi!
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?
IMHO the problem is in the way you're using to achieve the desired result. If
you want some library to be portable, it is the wrong way, to write a
collection of highly system dependent modules and then try to make it portable
afterwards. With a few rare exceptions this will not work, or will be quite
ugly at least. If you start with portable code and then try to make it faster
by using system dependent stuff, the result will be much better.
The real world gives you many examples for this: If you start coding a program
that should end up to be ported to several platforms, probably the worst idea
of all would be to go ahead and code it using Visual Studio for Windows and
MFC. There are (some) programs that started like this and were ported to other
platforms, and all these programs suck.
The approach I suggest is to write a portable library first. If you can use
system depdendent stuff later to make it faster and shorter: good! If not,
then you do still have a solution that works on all platforms.
I admit that in theory, your approach and mine should both achieve the same
results. But I've tried both ways myself, and my experience is that - starting
with something unportable - it is much more difficult to make it portable
later.
> 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.
The situation would be the same as with ints or longs: If you use float
multiplication, the linker would add the necessary routine and may be some
support stuff, but nothing else. So you pay only for the stuff, you do really
use.
> 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.
This is not enough. The C standard requires, that computations done in the
compiler generate the same results as computations done at runtime - which
does usually mean that the compiler MUST use the same float representation as
the target machine.
If you're using IEEE floats for example, this is not a problem, since most
of todays platforms use it. If the compiler has to emulate all of the
different and non standard floating point formats, this would be - uhmm -
"inconvenient" :-)
> you arent really seriously suggesting to implement a full IEE
> compliant floating-point emulator that passes all tests are you ?
Yes, I do.
> That
> may be a nice tech-demo, but completely useless for real use (large
> and slow, just what we like ,=P)
Why do you expect such a library to be slower than what the CBM kernal has?
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 09:15:42 CEST