>I don't directly remember decimal floating point arithmetic routines,
>but other things imply they were there.
>However, I know my (****ny new?) MS F77 Fortran complier has such a
>library (decmath.lib), as well as binary floating point and others.
AFAIK MS Fortran 3.3 DECMATH.LIB uses the 80x86 packed BCD math
instructions.
ALTMATH is compromise math lib for machines without x87s which runs faster
than 87 emulation, but lower precisions.
MATH.LIB is the 87 emulation and 8087.LIB uses the x87 (and dies horribly
if not present IIRC).
But harking back to Steve Lionel's original response, not only are the
WinXX APIs much
fuller than the INT 21H API of DOS, the library granularity is much poorer
these days.
It take effort and thought to properly generate fine granularity
libraries. Just like it
too effort to sup****t multiple math library options. Most compiler
vendors can't justify
that effort these days because they need to concentrate efforts on other
things (such as
chasing the latest API changes from MS or the latest new hardware features
from Intel or
AMD, just as a couple of minor examples ;-) or on implementing new
language features.
IIRC a simple F77 "hello world" was a few 10s of k with any of the 16 bit
MS Fortrans,
but about 1/8 Meg with FPS4, and close to 1/4M with DVF5.
The trouble with DLLs for the runtime is the issue of "DLL Hell". So long
as you are
the *only* thing on the system using that runtime DLL, no matter how many
programs you
have using it, fine. But as soon as another vendor's proggie uses it,
then the possibility
of versionitis arises. ANd "DLL Hell" is nothing but extreme versionitis.
No, I prefer everything statically linked in. And I hate the EXE bloat
that results,
but I find that less problematic than the problems of DLLs. But limiting
EXE size
by employing DLLs is a viable alternative, if you are willing to put up
with the problems
that potentially arise.
|
