Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: TC++: "floating point formats not linked"
Message-ID: <15332@smoke.brl.mil>
Date: 26 Feb 91 20:10:34 GMT
References: <268@nazgul.UUCP> <15316@smoke.brl.mil> <1991Feb26.085503.14893@athena.mit.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 23

In article <1991Feb26.085503.14893@athena.mit.edu> scs@adam.mit.edu writes:
>(Either my compiler is derived from the one Doug worked on after
>all, or his mods would have arranged for a fltused in this last
>case as well, which couldn't hurt.)

The latter, to accommodate subtle cases that could cause problems.

Another thing I did, which so far as I know was unique to my variant
of Ritchie's compiler, was to arrange that upon entry to a function
that made any use of floating point (again relying on the "fltused"
flag), after the stack pointer was adjusted to allow room for autos,
I output a "TST (SP)" instruction.  The point of this was to force
a segmentation violation at that point, in cases where the stack had
just been grown past the current maximum size, rather than later
when a floating-point instruction might have triggered the
segmentation violation trap.  This was necessary on the PDP-11/34,
which did not maintain enough state information to be able to
successfully restart all floating-point instructions that could have
caused such a trap.  (Basically I had borrowed the PDP-11/45 UNIX
instruction restart code and asynchronous floating-point processor
support and folded it into the PDP-11/40 UNIX kernel.  There were
some subtle 11/40 vs. 11/34 differences that had to be addressed
also.)