2007-06-12 Joel Sherrill <joel.sherrill@OARcorp.com>

	* armulator/.cvsignore, armulator/ChangeLog, armulator/Makefile.am,
	armulator/bsp_specs, armulator/configure.ac, armulator/preinstall.am,
	armulator/clock/clockdrv.c, armulator/console/console-io.c,
	armulator/console/mon-syscalls.S, armulator/include/.cvsignore,
	armulator/include/bsp.h, armulator/include/tm27.h,
	armulator/start/start.S, armulator/startup/bspstart.c,
	armulator/startup/libcfunc.c, armulator/startup/linkcmds,
	armulator/startup/swi.h, armulator/startup/syscalls.c,
	armulator/startup/trap.S: Removed.

1 files changed, 0 insertions, 93 deletions

diff --git a/c/src/lib/libbsp/arm/armulator/startup/trap.S b/c/src/lib/libbsp/arm/armulator/startup/trap.S
deleted file mode 100644
index 4021ea1d18..0000000000
--- a/c/src/lib/libbsp/arm/armulator/startup/trap.S
+++ /dev/null
@@ -1,93 +0,0 @@
-        /* Run-time exception support */
-#include "swi.h"
-
-/* .text is used instead of .section .text so it works with arm-aout too.  */
-	.text
-        .align 0
-        .global __rt_stkovf_split_big
-        .global __rt_stkovf_split_small
-
-/* The following functions are provided for software stack checking.
-   If hardware stack-checking is being used then the code can be
-   compiled without the PCS entry checks, and simply rely on VM
-   management to extend the stack for a thread.
-
-   The stack extension event occurs when the PCS function entry code
-   would result in a stack-pointer beneath the stack-limit register
-   value.  The system relies on the following map:
-
-        +-----------------------------------+ <-- end of stack block
-        | ...                               |
-        | ...                               |
-        | active stack                      |
-        | ...                               | <-- sp (stack-pointer) somewhere in here
-        | ...                               |
-        +-----------------------------------+ <-- sl (stack-limit)
-        | stack-extension handler workspace |
-        +-----------------------------------+ <-- base of stack block
-
-   The "stack-extension handler workspace" is an amount of memory in
-   which the stack overflow support code must execute.  It must be
-   large enough to deal with the worst case path through the extension
-   code.  At the moment the compiler expects this to be AT LEAST
-   256bytes.  It uses this fact to code functions with small local
-   data usage within the overflow space.
-
-   In a true target environment We may need to increase the space
-   between sl and the true limit to allow for the stack extension
-   code, SWI handlers and for undefined instruction handlers of the
-   target environment.  */
-
-__rt_stkovf_split_small:
-        mov     ip,sp   @ Ensure we can calculate the stack required
-        @ and fall through to...
-__rt_stkovf_split_big:
-        @ in:   sp = current stack-pointer (beneath stack-limit)
-        @       sl = current stack-limit
-        @       ip = low stack point we require for the current function
-        @       lr = return address into the current function
-        @       fp = frame-pointer
-        @               original sp --> +----------------------------------+
-        @                               | pc (12 ahead of PCS entry store) |
-        @               current fp ---> +----------------------------------+
-        @                               | lr (on entry) pc (on exit)       |
-        @                               +----------------------------------+
-        @                               | sp ("original sp" on entry)      |
-        @                               +----------------------------------+
-        @                               | fp (on entry to function)        |
-        @                               +----------------------------------+
-        @                               |                                  |
-        @                               | ..argument and work registers..  |
-        @                               |                                  |
-        @               current sp ---> +----------------------------------+
-        @
-        @ The "current sl" is somewhere between "original sp" and "current sp"
-        @ but above "true sl". The "current sl" should be at least 256bytes
-        @ above the "true sl". The 256byte stack guard should be large enough
-        @ to deal with the worst case function entry stacking (160bytes) plus
-        @ the stack overflow handler stacking requirements, plus the stack
-        @ required for the memory allocation routines.
-        @
-        @ Normal PCS entry (before stack overflow check) can stack 16
-        @ standard registers (64bytes) and 8 floating point registers
-        @ (96bytes). This gives a minimum stack guard of 160bytes (excluding
-        @ the stack required for the code). (Actually only a maximum of
-        @ 14standard registers are ever stacked on entry to a function).
-        @
-        @ NOTE: Structure returns are performed by the caller allocating a
-        @       dummy space on the stack and passing in a "phantom" arg1 into
-        @       the function. This means that we do not need to worry about
-        @       preserving the stack under "sp" even on function return.
-        @
-        @        Code should never poke values beneath sp. The sp register
-        @        should always be "dropped" first to cover the data. This
-        @        protects the data against any events that may try and use
-        @        the stack.
-
-        SUB     ip, sp, ip      @ extra stack required for function
-        @ Add stack extension code here.  If desired a new stack chunk
-        @ can be allocated, and the register state updated suitably.
-
-        @ We now know how much extra stack the function requires.
-        @ Terminate the program for the moment:
-        swi     SWI_Exit