double-float-bits for x86/sse2. This gives x86 the same
micro-optimizations that were available for sparc and ppc.


 o code/kernel.lisp:
   o Enable fast double-float-bits using the vop instead of calling
     double-float-high-bits/double-float-low-bits. 

 o compiler/float-tran.lisp:
   o Make fast-unary-ftruncate known to compiler and enable optimizer
     for it. 
   o Make double-float-bits known to compiler

 o compiler/x86/float-sse2.lisp:
   o Implement fast-unary-ftruncate for singles and doubles.
   o Implement double-float-bits.

srctran.lisp::
 * The optional convert-type arg is always true, so remove it and
   update the local functions to convert always.
 * Clean up some comments as well.

float-tran.lisp::
 * Fix up one place where we were supplying a value for the optional
   convert-type arg.

o Convert x/n to x*(1/n) when n is a power of two since 1/n has an
  exact representation.
o Convert 2*x to x+x.

entries with just the file path, removing the revision number, date,
author and state.  The actual information is now computed during
compilation and stored in the fasl itself.  (See ticket:48.)

to see what's happening.

case of a negative real to an integer power.  Previously, this case
wasn't handled.

may get confused with source locations if the reader macros are
installed.

boot-2010-02-1 as the bootstrap file.  You should probably also use
the new -P option for build.sh to generate and update the po files
while building.

everywhere except for x87 builds since there is a possible roundoff
issue due to the 80-bit registers for x87.

This is some 2-3 times faster than the existing fround function.

code/float.lisp:
o Implementations of %unary-fround/single-float,
  %unary-fround/double-float, and %unary-fround.  Declare the first
  two as inline too.

compiler/float-tran.lisp:
o Tell compiler about %unary-fround.
o Transform fround to a call to %unary-fround.
o Transform %unary-fround to special versions for single and double
  float arguments.

amd64-dd-branch.

sources.  No real attempt has been made to make it work, but the
cross-compile does create a kernel.core, and the C code compiles (on
openSuSE 10.3).  The resulting kernel.core does not yet work.

Use cross-x86-amd64.lisp as the cross-compile script.  This is
intended to be cross-compiled using the 20a release for Linux, and
only supports x87.  The sse2 support has not be ported yet.

tools/cross-scripts/cross-x86-amd64.lisp:
o Update cross-compile with some missing constants, and frob new
  symbols.

tools/clean-target.sh:
o Remove amd64f files too.

code/pred.lisp:
o Define predicates for double-doubles for bootstrapping to work
  around recursive known function problems with these predicates.

code/sap.lisp:
o Define int-sap with (unsigned-byte 64) type declaration.  (May not
  be needed?)

code/unix-glibc2.lisp:
o Build fails defining map_failed to (int-sap -1).  Just hard-wire to
  0 for now so we can build.

compiler/float-tran.lisp:
o Add missing conditional for %complex-double-double-float.

compiler/amd64/float.lisp:
o Merge double-double support for amd64.  Not really tested yet.

compiler/amd64/parms.lisp:
o Update to match x86 build.  In particular, get the space address
  correct and update the static symbols.

compiler/amd64/type-vops.lisp:
o DYLAN-FUNCTION-HEADER-TYPE no longer exists.

compiler/amd64/vm.lisp:
o Add double-double storage classes and register definitions.

lisp/Config.amd64:
o Bring in line with Config.x86 and friends.

lisp/Linux-os.c:
o Bring amd64 code up-to-date with x86/linux code.

lisp/Linux-os.h
o Need to include sys/ucontext.h to get ucontext defined.  (Why?)
o Also define __USE_GNU so we get the register offsets in the ucontext
  defined.  (Why?)

lisp/amd64-arch.c:
o Change struct sigcontext to os_context_t.
o Use SC_PC instead of context->sc_pc.
o Merge some changes in from x86 version, like SC_EFLAGS.  May need
  more work.

lisp/amd64-assem.s:
o Use rbx instead of ebx for jmp.

lisp/amd64-lispregs.h:
o Define SC_REG, SC_PC, SC_SP using the new x86 style.

lisp/backtrace.c:
o Remove inline assembly for now until I figure out what the amd64
  version should be.

lisp/gencgc.c:
o Conditionalize out weak hash table support for now.

lisp/gencgc.h:
o Set PAGE_SIZE for amd64.  (Is 4096 right?)

lisp/globals.h:
o Export current_dynamic_space_free_pointer and
  current_auto_gc_trigger like for x86.

code/exports.lisp:
o Import STREAM:SET-SYSTEM-EXTERNAL-FORMAT into the EXT package.
o Define and export %sin-quick, %cos-quick, and %tan-quick only for
  x87 builds.

compiler/float-tran.lisp:
o Only apply defknowns and deftransforms for %sin-quick, %cos-quick,
  and %tan-quick for x87 builds.

o Add vop for conjugate of complex single and double floats.

compiler/float-tran.lisp:
o Disable deftransform for conjugate.  All platforms with complex fp
  vops support conjugate.

o Sparc has a vop for complex conjugate, so we can disable the
  deftransform.
o Both sparc and x86 have a vop to do float - complex, so disable that
  transform too.

compiler/sparc/float.lisp:
o Fix the float-complex vop to do the right thing wrt contagion.
o Remove some old commented out vop for complex*complex and
  complex/complex.

  - complex + real
  - complex - real
  - real + complex
o Clean up comments and fix erroneous ones.

o Declare POLY-EVAL and POLY-EVAL-1 as maybe-inline functions so they
  can be semi-inlined.

code/irrat.lisp:
o I don't think there's any real reason to make the local function
  REAL-EXPT inline.  It's very big and local function call is already
  good enough.

compiler/float-tran.lisp:
o Change some functions to be maybe-inline instead of inline to save
  on space for the the larger double-double functions:  SUB-DD,
  SUB-D-DD, SUB-DD-D, SPLIT.  Semi-inline should be good enough for
  these large functions, saving on cache memory, local function
  calling sequence should be good enough.

o Use ETYPECASE instead of TYPECASE when defining %COMPLEX-foo-FLOAT.

to code/float.lisp because we need this early in the build process to
handle float types.

This might cuase problems with bootstrapping double-double floats!

:complex-fp-vops is not defined.

o Remove the deftransform for real + complex and real * complex.
o Always enable the transform for real - complex.

x86/float-sse2.lisp:
o Add vop to do real + complex
o Add vop to do real * complex

o Change the other complex arithmetic deftransforms not to use REAL as
  the type of an argument.  It should be the same as the complex
  argument.  Without this, the deftransforms were causing infinite
  loops during compilation where the deftransforms kept changing the
  code.

  (defun foo (z)
    (declare (double-float z))
    (+ (complex 0 1) z))
o For now, don't convert real*complex to complex*real.  Expand it out
  explicitly.

sse2-packed-2008-11-12).

o Recursively call RANDOM for the integer case to let the deftransform
  handle the case.

compiler/float-tran.lisp:
o Remove comment about modifying RANDOM to match the deftransform.
  We're automatically in sync now.

  Fix bug in deftransform where the case for x86 and num-high >
  random-fixnum-max was never used.  We now always use the bignum
  multiply code for all platforms and use that for all cases for which
  the deftransform applies.

  Simplify the constant-continuation case too so we don't have to the
  check.  I think the bignum multiply version does not have the bias
  problem that rem has.

code/rand-mt19937.lisp:
  Change the RANDOM function to compute the same value as the
  deftransform would.

general-info/release-19f.txt:
  Update

Make a note that both the function and the deftransform should be
synchronized to match.  This change also changes the sequence of
numbers produced.

  operations.  The deftransforms were causing type-derivation to
  return DOUBLE-DOUBLE-FLOAT for everything.  Use the suggestion from
  Rob: Wrap the result of the deftransform in a TRULY-THE form and use
  the node derived type for the type.
o The FLOAT-SIGN deftransform for DOUBLE-DOUBLE-FLOAT should be
  conditioned on the DOUBLE-DOUBLE feature.
o Remove old unused deftransform for * for two double-double args.

specifiers.

To see this, try the following:

(defun foo (x)
  (declare (type (real 0) x))
  (expt 2 x))

(compile 'foo)

(describe 'foo)

You get error that 0 is not an appropriate type for a double-float specifier.

be the largest possible number.

used instead of %sin and friends.  Simple tests showed that they gave
bad answers (values > 1 or exceptions) for numbers greater than 2^63
(2^62 for tan).

o Add INHIBIT-WARNINGS for the core double-double routines to get rid
  of warnings about boxing numbers.  I'm pretty sure the routines are
  all doing what they're supposed to do.

(nonexistent) block.

o Handle signed-zeroes for addition, subtraction, and multiplication
  of double-double floats.  That is, return the correct signed zero
  for the result.
o Try to handle overflow in addition, multiplication, and division by
  returning infinity, if the overflow or divide-by-zero trap is
  disabled.  This is done by looking to see what the corresponding
  double-float operation would return.  This probably needs more work.

code/irrat-dd.lisp:
o Remove the careful-mul stuff from dd-complex-atanh since we handle
  signed zeroes better now during double-double multiplication.

o Add vops to do fused multiply-add and fused multiply-subtract.
  (Only double-float supported.)
o Add defknown's for these translations.

compiler/float-tran.lisp:
o Used fused multiply-subtract for two-prod and two-sqr instead of the
  split function.

(defun f (x y)
   (declare (fixnum x y))
   (expt x y))

caused an error because we weren't handling member types correctly.

type of:

    (defun foo3 (x y)
      (declare (type (double-float (0d0) 1d0) x)
	       (type (double-float (0d0)) y))
      (expt x y))

to be (double-float 0d0 1d0), i.e, including -0.0, but that's not
possible.  With this fix, the result type is (or (member 0d0)
(double-float (0d0) 1d0)), which is better.