[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
T without 68881?
Date: Mon, 27 Jun 88 16:40:08 CDT
From: mark@mcc.com (Mark Scheevel)
Posted-Date: Mon, 27 Jun 88 16:40:08 CDT
An attempt to run the resulting executable on a Sun 3/50 produces a
message like
MC68881 floating-point not available -- program requires it
Since I didn't (and still don't!) know when in the build process
floating-point dependencies are introduced, I tried this morning to
use sunbuild.t and build a new version from the ground up (again using
the float.o produced with the -fsoft option). Unfortunately, this new
system still fails the same way. Some simple timing comparisons on my
3/110 indicate that the old (hard fp) system and the new (soft fp)
system differ, and that the new system is somewhat slower, although
not as much slower as I expected (maybe 20% to 40%). (By the way,
division is *faster* than multiplication on both systems; does it do
less type-testing or something?) Is my compiler doing something funny
and still emitting 68881 code, or is there a magic option that I need
to supply to ld, or am I simply out of luck?
I think doing what Jim Hunt suggested should do the trick. The soft floating
point is not that much slower because T floating point is painfully slow
anyway. This is because it is not open-coded. It may be fixed in the
next release. As for division being faster than multiplication, you'll have
to ask Sun about that. Any difference is is the code from float.c.
And while I have your attention...
I've also been playing with the foreign code interface. I have been
able to get my simple examples to work, *as long as* I run the
load-foreign expression interactively. If I try to bury the
load-foreign inside a file such as
(herald test)
(load-foreign 'junk.o) ;; defines foo, say
(define-foreign foreign-foo (foo (in rep/integer)) rep/integer)
the compiled file breaks during loading with this message:
** Error: foreign procedure "_foo" does not exist in file "/nfs/users/st/mark/t3.1/tsystem/xt"
If I run the load-foreign "by hand" before loading a compiled file
without the load-foreign in it, everything works fine. Is this a bug,
or do I have an incorrect model of how load-foreign and define-foreign
interact with the compiler?
The problem is that names from define-foreign are looked up as the file is
being loaded, before the top-level forms are executed. You will have to put
the load-foreign elsewhere.
-David