Christophe Lyon | 073831a | 2011-01-24 17:37:40 +0100 | [diff] [blame] | 1 | ARM Neon reference tests |
| 2 | ======================== |
| 3 | This package contains extensive tests for the ARM/Neon instructions. |
| 4 | |
| 5 | It works by building a program which uses all of them, and then |
| 6 | executing it on an actual target or a simulator. |
| 7 | |
| 8 | It can be used to validate the simulator against an actual HW target, |
| 9 | or to validate C compilers in presence of Neon intrinsics calls. |
| 10 | |
| 11 | The supplied Makefile enables to build with both ARM RVCT compiler and |
| 12 | GNU GCC (for the ARM target), and supports execution with ARM RVDEBUG |
| 13 | on an ARM simulator and with QEMU. |
| 14 | |
| 15 | For convenience, the ARM ELF binary file (as compiled with RVCT) is |
Christophe Lyon | bfab383 | 2012-05-11 15:14:44 +0200 | [diff] [blame] | 16 | supplied (compute_ref.axf), as well as expected output (ref-rvct.txt). |
| 17 | |
| 18 | A second file containing expected output is also supplied: |
| 19 | ref-rvct-neon.txt, which contains only the results of the Neon |
| 20 | instrinsics tests. It is aimed at being used to check GCC's results, |
| 21 | since this compiler does not support the integer & dsp builtins whose |
| 22 | results are also present in ref-rvct.txt. |
Christophe Lyon | 073831a | 2011-01-24 17:37:40 +0100 | [diff] [blame] | 23 | |
| 24 | Typical usage when used to debug QEmu: |
| 25 | $ make all # to build the test program with ARM rvct and execute with QEmu |
| 26 | $ make check # to compare the results with the expected output |
| 27 | |
| 28 | |
| 29 | Known issues: |
| 30 | ------------- |
Christophe Lyon | eb8034b | 2012-05-09 17:06:10 +0200 | [diff] [blame] | 31 | Some tests currently fail to build with GCC/ARM: |
Christophe Lyon | 073831a | 2011-01-24 17:37:40 +0100 | [diff] [blame] | 32 | - missing include files: dspfns.h, armdsp.h |
| 33 | |
Christophe Lyon | 4a6e5cc | 2014-06-03 22:47:52 +0200 | [diff] [blame] | 34 | As GCC/ARM provides no support for the |
| 35 | Neon_Cumulative_Saturation/fpsrc register, auxiliary accessor |
| 36 | functions have been implemented in stm-arm-neon-ref.h. |
Christophe Lyon | 073831a | 2011-01-24 17:37:40 +0100 | [diff] [blame] | 37 | |
| 38 | Engineering: |
| 39 | ------------ |
| 40 | In order to cover all the Neon instructions extensively, these tests |
| 41 | make intensive use of the C-preprocessor, to save maintenance efforts. |
| 42 | |
| 43 | Most tests (the more regular ones) share a common basic structure. In |
| 44 | general, variable names are suffixed by their type name, so as to |
| 45 | differentiate variables with the same purpose but of differente types. |
| 46 | Hence vector1_int8x8, vector1_int16x4 etc... |
| 47 | |
| 48 | For instance in ref_vmul.c the layout of the code is as follows: |
| 49 | |
| 50 | - declare input and output vectors (named 'vector1', 'vector2' and |
| 51 | 'vector_res') of each possible type (s/u, 8/16/32/64 bits). |
| 52 | |
| 53 | - clean the result buffers. |
| 54 | |
| 55 | - initialize input vectors 'vector1' and 'vector2'. |
| 56 | |
| 57 | - call each variant of the intrinsic and store the result in a buffer |
| 58 | named 'buffer', whose contents is printed after execution. |
| 59 | |
| 60 | One can then compare the actual result with the expected one. |