stack. Otherwise, inexplicable floating-point errors can occur. An
example of such an error can be created by typing `-1e-194' at a
freshly-booted scheme.
The actual problem is somewhat involved. The C compiler assumes that
all of the floating-point registers are empty on the entry to any
procedure. As a consequence of this assumption, it feels free to use
all 8 of the registers. However, if this assumption is violated, a C
procedure that uses too many registers will signal a floating-point
stack overflow.
However, the Scheme compiler does not follow this convention; more
precisely, since it was originally designed to use reasonable
floating-point hardware, in which the floating-point registers are
organized as a bank of registers rather than a stack, it doesn't do
anything about popping registers when it is done with them. As a
consequence, floating-point operations generated by the Scheme
compiler often leave values on the floating-point stack.
To work around this without redesigning the compiler, the
compiled-code interface clears out the stack whenever it transfers
between C and Scheme code. The bug fixed by this revision was a
transfer point that did not have code to clear out the stack.
### -*-Midas-*-
###
-### $Id: i386.m4,v 1.46 1997/05/01 01:26:16 cph Exp $
+### $Id: i386.m4,v 1.47 1997/05/05 06:59:35 cph Exp $
###
### Copyright (c) 1992-97 Massachusetts Institute of Technology
###
\f
define_hook_label(scheme_to_interface)
define_debugging_label(scheme_to_interface)
+IF387(`
+ OP(cmp,l) TW(IMM(0),ABS(EVR(i387_presence)))
+ je scheme_to_interface_proceed
+ ffree ST(0) # Free floating "regs"
+ ffree ST(1)
+ ffree ST(2)
+ ffree ST(3)
+ ffree ST(4)
+ ffree ST(5)
+ ffree ST(6)
+ ffree ST(7)
+scheme_to_interface_proceed:
+')
ifdef(`HACK_SEGMENT_REGS',
` OP(push,l) LOF(36,regs) # 4th utility arg
OP(push,l) REG(eax) # Save utility index