[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.