runtime/{arm-linux-os,interrupt}.c: Use sigaltstack() on ARM.

  * On ARM, due to a general lack of registers, we use the
hardware stack pointer for our control stack pointer... on a boxed
control stack, which is bad enough.  We then use an expand-up
stack while C expects an expand-down stack.  If we don't set up an
altstack then when a signal arrives our control stack gets
clobbered.

  * Set up an altstack using sigaltstack() when initializing each
thread.

  * And register the signal handler using SA_ONSTACK to cause a
stack swap when a signal arrives while we're on the main stack.
We can't simply enable LISP_FEATURE_C_STACK_IS_CONTROL_STACK here
because they're actually separate stacks, they just happen to use
the same stack pointer at various times.

  * We're almost certainly going to have more trouble with this
going forward, but this should be sufficient to cover error traps,
GC triggers, and so on...  But probably not quite enough to cover
a control stack overrun gracefuly.
compiler/arm/static-fn: Rough-in based on SPARC backend.

  * The SPARC calling convention is closest to ours, so rough in
based on that.

  * Our passing convention for LRA and OCFP is on-stack, so tweak
the stack-frame creation logic to account for this.

  * And it turns out that we only ever use 1-arg and 2-arg static
functions, so don't bother creating more template VOPs than that.
compiler/arm/{arith,parms}: Define static-funs for TWO-ARG-[<>].

  * The first two cases that we encounter, the observed symptom
being a stack overflow with all the stack frames being for the
same function (in these cases, either < or >).

  * A full call to < or > goes to the defined function in
code/numbers.  This function does a pairwise operation to break it
down to where the compiler can be somewhat intelligent.

  * A pairwise call to < or > with sufficient and compatible type
information and a defined VOP will be open-coded.  Otherwise, a
full call to < or > is compiled...  Unless there's a defined
static-fun, in which case a slightly different call is assembled
to the TWO-ARG-whatever version, which does a type-dispatch to
trigger the appropriate open-coded version (or other noise if the
types really aren't compatible, such as a FIXNUM against a BIGNUM).

  * Of course, if the VOP for an open-coded version is missing
(such as, say, > for two SINGLE-FLOAT args) then we end up with a
blown control stack showing all the stack frames for the same
TWO-ARG-whatever function.

  * In the latter case (blown stack, TWO-ARG-whatever), fire up
GDB, set a breakpoint at the start of the function in question,
and check on the args to see what they are.  Or just desk-check
the backend to see which (if any) relevant VOPs are missing.
compiler/arm/{insts,vm}: Fix up float register damage.

  * First, the register spaces overlap, meaning that they must
share an SB, and thus also the encoding for the offset space.  Fix
to share FLOAT-REGISTERS instead of having separate single and
double float register files.  Update insts to deal with the newer
encoding for double-float offsets (removing the "precision" noise).

  * Second, we've just collapsed a couple of SBs into one, so we
need to update LOCATION-PRINT-NAME.  Rather than saying S~D or
D~D, we just say F~D like on all of the other platforms (we could
get clever the way that x86oids do with the SC name, but that can
easily wait until later).

  * Third, the comments in vm.lisp about :element-size not being
valid for LOAD-TNs are just a little bit out of date.  The comment
was originally written for the PPC backend in early February 1991,
based on a similar comment in the MIPS backend from the previous
September.  PACK was updated to honor :element-size for SCs in
late February 1991.  Remove the comments.

  * And now that we have the SBs sorted out, we update the SCs to
use appropriate offsets within the SB and element sizes, following
the SPARC precedent, where they actually got it somewhat right.
make-config, compiler/arm/vm: Add feature conditions for VFP and VFPv2.

  * The overall ARM architecture has several FPU options, such as
soft-float-only, FPA (Floating Point Accelerator), at least three
generations of VFP (Vector Floating Point), plus some system based
on the x86oid MMX instruction sets.  And that's off the top of my
head.

  * Make an explicit statement that we are supporting VFPv2, and
possibly not even the original VFP, and leave hooks in place to
make it obvious what needs adjusting in order to support other FPU
options.
compiler/arm/params,compiler/generic/genesis: FPU parameter setup.

  * These parameters are based on what we do for other ports, with
commentary based on a discussion with (IIRC) pkhuong and Krystof,
and on some version of the ARM ARM for the various VFP-specific
bits.

  * Also re-enable the last bit of genesis that was disabled for
ARM systems, since we now define the various floaty bits that it
was trying to export to C header files.
compiler/arm/insts: Single-reg float load/store should use memory-operand.

  * We have an established precedent for referring to addresses in
memory from instructions: the MEMORY-OPERAND structure.

  * Fix the single-reg load/store instructions to take a memory
operand instead of a base register and offset (in downright odd
locations, at that).

  * Leave open the possibility of using a LABEL base (likely to be
too limited in applicability to be truly useful).
{assembly,compiler}/arm/array: Fix allocation padding calculation.

  * All allocations must preserve the double-word alignment on the
allocation pointer, which means that they must be a multiple of
two words in length.

  * These two cases were adding an extra word and then using BIC
in order to clear the low bits of the length, which is the usual
method for rounding up to some boundary.  However, they were using
(1- N-LOWTAG-BITS), which would be 2 and not simply LOWTAG-MASK,
which is 7.  Needless to say, alignment was not being maintained.

  * Fix, by using the correct parameters to BIC.
compiler/arm/float: Basic non-complex float moves and boxing/unboxing.

  * These are the non-complex cases for float moves, boxing, and
unboxing, largely cribbed from the PPC backend, and even tested in
some cases.
compiler/arm/float: Float comparison VOPs.

  * Cribbed from the PPC backend, updated for the realities of the
ARM architecture, lightly tested, and possibly even working.

  * One ugly bit here: We need to use FMSTAT (or whatever the more
modern replacement is) in order to get the VFP condition codes to
where they do any good for control flow.  This instruction isn't
currently known to the assembler by name, and it's not at all
obvious how to use the lower-level equivalent instruction, so
there's a bare INST WORD being used to encode FMSTAT directly.
compiler/arm/float: Float arithmetic VOPs.

  * Cribbed from the PPC backend again.

  * At least one of these has been tested and found to work, for
what it's worth.
compiler/arm/float: A whole lot of conversion VOPs.

  * All the basics, whatever-float to integer.  Whatever-float to
whatever-other-float.  Integer to whatever-float.  Whatever-float
to bits.  Bits to whatever-float.

  * Cribbed from the PPC backend, then given a good going over to
account for differences between PPC and ARM VFP architectures.
compiler/generic/primtype: Enable holding non-complex floats in registers.

  * Now that most of the floating-point noise is in place (with
the notable exceptions of mode/trap hacking and complex floats),
we can enable the whole thing by registering single-reg and
double-reg as valid SCs for the single-float and double-float
primitive types.
code/irrat: Disable all floating FFI on ARM.

  * We don't need any of this immediately, and our CALL-OUT
implementation doesn't yet include support for (single or double)
float args.
build-order.lisp-expr: Enable some more files for ARM.

  * Now that we have the floating-point support largely in shape,
we can enable the files that depend on it in one way or another...
with one exception.

  * The last file in build-order that isn't specific to some other
architecture or operating system is code/float-traps.  Which we
haven't written the VOPs to support yet.  One last file before we
can revert all of this :ARM-BOOTSTRAP noise.
compiler/arm/system: Fix VOP SET-HEADER-DATA.

  * Don't know what I was thinking when I originally set this up.
It was referencing an uninitialized temporary, bringing junk data
in as part of the array header.  Fixed, including getting rid of
the otherwise-unreferenced temporary.
compiler/arm/arith: Fix VOP BIGNUM-FLOOR.

  * This was obviously cribbed from the SPARC version, which is
fine, but whoever did the cribbing wasn't aware of (or forgot
about) the SPARC having branch-delay slots (a correctness problem)
or the ARM supporting predicated operation on almost every
instruction (an avoiding-a-branch issue).

  * Easy enough to fix once I realize what's going on.
compiler/arm/arith: Fix up VOPs ADD-W/CARRY and SUB-W/BORROW.

  * These were originally based on the MIPS backend, the absolute
worst possible precedent for such VOPs, because MIPS unlike just
about every other CPU architecture out there, doesn't have flags
(meaning that carry must be represented explicitly in a register).

  * Rewrite, loosely based on the x86 versions.
compiler/arm/arith: Fix up bidirectional inline ASH VOPs.

  * First off, use RSB from 0 instead of zeroing a register and
using SUB.

  * Second, use predicated code instead of branches.

  * Third, FAST-ASH/SIGNED=>SIGNED used the wrong register for the
shift count in one instance.
compiler/arm/arith: We have a CLZ instruction, use it for INTEGER-LENGTH.

  * Not much more to say about this, other than that I'd've liked
it if we also had an instruction for counting the number of set
bits as well.