 by Software Evolutions

Please mail any results produced by this program to:

M.Seifert@t-online.de



Many thanks to (in no particular order):

 James Stevens
  for running several tests with his Kinetic upgrade

 Chris Terran
  for running several tests with his R7500

 Christopher Whytehead
  for running !SICK on several different (mainly older) machines and thus
  helped a lot to fix lots and lots of bugs in !SICK (you'll find all those
  fixes  in the 'Changes' file [V1.14 to 1.18])

===============================================================================

Here's a short description of the result file:

.---------------.
| Result Values |
'---------------'

These values are for 'internal use' only. They represent some of the results
in a (more or less) encoded form. These values are especially usefull (to the
author) if there goes anything wrong with the checks performed later on.

.-----------.
| Guesswork |
'-----------'

Based on several results !SICK tries to guess which computer it is running on.
It tries to detect the _original_ type, i.e. it should report a RiscPC 600 even
if there is a StrongARM fitted. Unfortunately !SICK sometimes gets it wrong...

.-----------.
| Processor |
'-----------'

Several information about the present main processor, e.g. model, revision and
clock frequency and coprocessor (FP and/or PC card) are given here.



The following architectur versions are detected:

Version 1
  This version was implemented by ARM1, and was never used in a commercial
  product. It contains:
   the basic data-processing instructions (not including multiplies)
   byte, word and multi-word load/store instructions
   branch instruction, including a branch-and-link instruction
   a software interrupt instruction
   26-bit address space

Version 2
  This version extended architecture version 1 by adding:
   multiply and multiply-accumulate instructions
   coprocessor support
   two more banked registers in fast interrupt mode

Version 2a
  This is a slightly later variant of version 2 which added:
   atomic load-and-store instructions called SWP and SWPB

Version 3
  This architecture version extended the addressing range to 32 bit. As a
  result the following changes occured:
   two instructions (MRS and MSR) were added to allow the new CPSR and SPSRs
    to be accessed
   the functionality of instructions previously used to return from exceptions
    was modified to allow them to continue to be used for that purpose
   new processor modes added to make it possible to use Data Abort, Prefetch
    Abort and Undefined Instruction exceptions effectively
   Backward-compatibility support for the 26-bit architecture

Version 3G (not reported by !SICK)
  A variant of architecture version 3 without backward-compatibility support
  for the 26-bit architecture

Version 3M
  A variant of architecture version 3 with long multiply instructions

Version 4
  This version extended architecture version 3 by adding:
   halfword load/store instructions
   instructions to load and sign-extend bytes and halfwords
   a new privileged processor mode that uses the User mode registers
   backward-compatibility support for 26-bit architectures is no longer
    obligatory

Version 4T
  This is the variant of architecture version 4 with Thumb support and thus
  adds:
   an instruction to transfer to Thumb state

Version 4xM/4TxM
  A variant of architecture version 4/4T without long multiply instructions

Version 5/5T
  This version extends architecture 4 by adding instructions and slightly
  modifying the definitions of some existing instructions:
   allow the same code generation techniques to be used for non-T variants as
    for T variants
   adds a "count leading zeros" instruction
   adds a software breakpoint instruction
   adds more instruction options for coprocessor designers

Version 5xM/5TxM
  A variant of architecture version 5/5T without long multiply instructions



Processor bugs reports whether several (known) bugs are present with the actual
processor. The bugs checked for are:

RRX:            The ARM prototype (ARM1) had a bug when executing the RRX
                shift. If bit 31 of the register was set and bit 0 was clear
                before the shift took place, it set the Carry flag.

Mode change:    With the ARM2, when the processors mode is changed, it
                accesses the banked register (R8-R14) of the previous
                processor mode in the following instruction.

LDM^:           With ARM2 and ARM3, when loading user bank registers with an
                LDM^ in a non-user mode, it accesses the banked register
                (R8-R14) of the previous processor mode in the following
                instruction.

LDM/STM:        With ARM2 and ARM3, only the address of the first transfer of
                a LDM or STM is checked for an address exepction; if
                subsequent addresses over-flow or under-flow into illegal
                address space they will be truncated to 26 bits but will not
                cause an address exception trap.

STM^:           The StrongA110 (of revision J or K) has a bug in the User
                Register Store Multiple instruction (STM^). This is the STM
                that is used to store user mode registers while in a privileged
                mode. If the STM^ is executed while a data cache fill is
                completing the store address for all but the first register
                may be wrong.

Istream abort:  The StrongARM110 (of revision less than S) have a bug in
                Istream Aborts. The conditions needed to cause the bug are:

                1. A LDR or LDM to the PC that is the last instruction in a
                   protection region, (last instruction of a page or subpage).

                2. The next location after the LDR/LDM to PC is not readable
                   because of permission or domain violation but is a valid
                   section, large page or small page.

                3. The translation buffer entry for the location after the
                   LDR/LDM to PC, is in the instruction translation buffer.

                4. The data being loaded to the PC is in the data cache.

                5. The data translation buffer entry for the data being loaded
                   into the PC is in the data translation buffer.

                If these conditions are all met, and the LDR/LDM is executed,
                an Istream Abort will be taken. The reported PC for the Istream
                Abort will be the value loaded into the PC by the load
                instruction minus 4.

LDMIB:          There is an 'anomaly' (as Intel used to call it) with all ARM
                processors before ARM9 and StrongARM110 revision T. The Rn
                register may be incorrectly updated when a Data Abort occurs
                during a LoaD Multiple registers, Increment Before (LDMIB)
                instruction if:

                1. The register list to be updated includes the base address
                   register Rn, i.e.
                   LDMIB Rn,{register list including Rn}

                2. The LDMIB causes a data abort.

                2. At least one register is loaded successfully prior to the
                   abort.

                This problem especially affects environments that use demand-
                paged memory-management schemes, e.g. Linux. (This is the
                famous bug which prevents lazy task swapping of RISC OS 4 to
                work with machines equipped with a StrongARM before revision T.)

MSR:            All(?) StrongARMs have a bug which lets them execute an
                instruction, which follows a MSR, twice, if the following is
                true:

                1. the ARM is in a non-USR mode

                2. the MSR is _not_ executed

                3. the MSR would write to the control field (e.g. CPSR_c)

                4. the MSR is _not_ the last instruction of a cache load

                (This bug tends to show up if one tries to write code which is
                compatible with 26-bit and 32-bit-only processors.)

.--------------------.
| System Performance |
'--------------------'

"A benchmark is like sex. Everybody wants it, everybody is sure how to do it,
but nobody can agree on how to compare performance." (Malgorzata Nowak AMD PR
Poland)

A few basic checks are done to show some aspects of the performance of the
system. These are:

- The well known Dhrystone 2.1 benchmark. This gives the integer performance of
  the processor. As it is quite small, it sits entirely in the cache of the ARM
  and thus doesn't take memory access speeds into account at all (except with
  ARM2 of course).

- For the floating point performance check the Whetstone benchmark is used.
  Again this is quite small, and sits entirely in the cache of the ARM.

- A few checks are done to measure the read and write access speeds to the main
  memory and the video memory.

Of course several aspects of system performance are not covered by this, e.g.
harddisc performance or 'screen output' performance (especially if an
additional video card is involved).

.---------.
| Remarks |
'---------'

If there were any events worth noticing, they are listed here.
