PandA-2024.02
SPARC-GCC.h
Go to the documentation of this file.
1 /*
2 +--------------------------------------------------------------------------+
3 | CHStone : a suite of benchmark programs for C-based High-Level Synthesis |
4 | ======================================================================== |
5 | |
6 | * Collected and Modified : Y. Hara, H. Tomiyama, S. Honda, |
7 | H. Takada and K. Ishii |
8 | Nagoya University, Japan |
9 | |
10 | * Remark : |
11 | 1. This source code is modified to unify the formats of the benchmark |
12 | programs in CHStone. |
13 | 2. Test vectors are added for CHStone. |
14 | 3. If "main_result" is 0 at the end of the program, the program is |
15 | correctly executed. |
16 | 4. Please follow the copyright of each benchmark program. |
17 +--------------------------------------------------------------------------+
18 */
19 /*============================================================================
20 
21 This C header file is part of the SoftFloat IEC/IEEE Floating-point Arithmetic
22 Package, Release 2b.
23 
24 Written by John R. Hauser. This work was made possible in part by the
25 International Computer Science Institute, located at Suite 600, 1947 Center
26 Street, Berkeley, California 94704. Funding was partially provided by the
27 National Science Foundation under grant MIP-9311980. The original version
28 of this code was written as part of a project to build a fixed-point vector
29 processor in collaboration with the University of California at Berkeley,
30 overseen by Profs. Nelson Morgan and John Wawrzynek. More information
31 is available through the Web page `http://www.cs.berkeley.edu/~jhauser/
32 arithmetic/SoftFloat.html'.
33 
34 THIS SOFTWARE IS DISTRIBUTED AS IS, FOR FREE. Although reasonable effort has
35 been made to avoid it, THIS SOFTWARE MAY CONTAIN FAULTS THAT WILL AT TIMES
36 RESULT IN INCORRECT BEHAVIOR. USE OF THIS SOFTWARE IS RESTRICTED TO PERSONS
37 AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ALL LOSSES,
38 COSTS, OR OTHER PROBLEMS THEY INCUR DUE TO THE SOFTWARE, AND WHO FURTHERMORE
39 EFFECTIVELY INDEMNIFY JOHN HAUSER AND THE INTERNATIONAL COMPUTER SCIENCE
40 INSTITUTE (possibly via similar legal warning) AGAINST ALL LOSSES, COSTS, OR
41 OTHER PROBLEMS INCURRED BY THEIR CUSTOMERS AND CLIENTS DUE TO THE SOFTWARE.
42 
43 Derivative works are acceptable, even for commercial purposes, so long as
44 (1) the source code for the derivative work includes prominent notice that
45 the work is derivative, and (2) the source code includes prominent notice with
46 these four paragraphs for those parts of this code that are retained.
47 
48 =============================================================================*/
49 
50 /*----------------------------------------------------------------------------
51 | Each of the following `typedef's defines the most convenient type that holds
52 | integers of at least as many bits as specified. For example, `uint8' should
53 | be the most convenient type that can hold unsigned integers of as many as
54 | 8 bits. The `flag' type must be able to hold either a 0 or 1. For most
55 | implementations of C, `flag', `uint8', and `int8' should all be `typedef'ed
56 | to the same as `int'.
57 *----------------------------------------------------------------------------*/
58 typedef int flag;
59 typedef int int8;
60 typedef int int16;
61 
62 /*----------------------------------------------------------------------------
63 | Each of the following `typedef's defines a type that holds integers
64 | of _exactly_ the number of bits specified. For instance, for most
65 | implementation of C, `bits16' and `sbits16' should be `typedef'ed to
66 | `unsigned short int' and `signed short int' (or `short int'), respectively.
67 *----------------------------------------------------------------------------*/
68 typedef unsigned short int bits16;
69 typedef unsigned int bits32;
70 typedef unsigned long long int bits64;
71 typedef signed long long int sbits64;
72 
73 /*----------------------------------------------------------------------------
74 | The `LIT64' macro takes as its argument a textual integer literal and
75 | if necessary ``marks'' the literal as having a 64-bit integer type.
76 | For example, the GNU C Compiler (`gcc') requires that 64-bit literals be
77 | appended with the letters `LL' standing for `long long', which is `gcc's
78 | name for the 64-bit integer type. Some compilers may allow `LIT64' to be
79 | defined as the identity macro: `#define LIT64( a ) a'.
80 *----------------------------------------------------------------------------*/
81 #define LIT64( a ) a##LL
82 
83 /*----------------------------------------------------------------------------
84 | The macro `INLINE' can be used before functions that should be inlined. If
85 | a compiler does not support explicit inlining, this macro should be defined
86 | to be `static'.
87 *----------------------------------------------------------------------------*/
88 #define INLINE
int int16
Definition: SPARC-GCC.h:60
int flag
Definition: SPARC-GCC.h:58
unsigned short int bits16
Definition: SPARC-GCC.h:68
int int8
Definition: SPARC-GCC.h:59
unsigned int bits32
Definition: SPARC-GCC.h:69
signed long long int sbits64
Definition: SPARC-GCC.h:71
unsigned long long int bits64
Definition: SPARC-GCC.h:70

Generated on Mon Feb 12 2024 13:02:48 for PandA-2024.02 by doxygen 1.8.13