[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

T without 68881?



> I don't know why this would not work.  How did it fail?  In any event, it 
> should not be a big deal to rebuild the system using the sunbuild.t script.
> I assume you have t3.1?
> 
> 	-David

The simple-minded approach was to recompile float.o with the -fsoft option
(I'm using a Sun 3/110, SunOS 3.2 [don't ask me why we're so far
behind the times]):

  obi-wan# cd t3.1/tsystem
  obi-wan# mv float.o hard-float.o
  obi-wan# cc float.c -c -fsoft -o float.o
  obi-wan# xt -h 11000000
  > ((*value t-implementation-env 'system-suspend) 'new nil)
  > (exit)
  obi-wan# linkt new.o new

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?


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?

--Mark