PandA-2024.02
examples
hls_study
dfsin
not-optimized
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
typedef
unsigned
int
uint32
;
62
typedef
signed
int
int32
;
63
64
/*----------------------------------------------------------------------------
65
| Each of the following `typedef's defines a type that holds integers
66
| of _exactly_ the number of bits specified. For instance, for most
67
| implementation of C, `bits16' and `sbits16' should be `typedef'ed to
68
| `unsigned short int' and `signed short int' (or `short int'), respectively.
69
*----------------------------------------------------------------------------*/
70
typedef
unsigned
short
int
bits16
;
71
typedef
unsigned
int
bits32
;
72
typedef
unsigned
long
long
int
bits64
;
73
typedef
signed
long
long
int
sbits64
;
74
75
/*----------------------------------------------------------------------------
76
| The `LIT64' macro takes as its argument a textual integer literal and
77
| if necessary ``marks'' the literal as having a 64-bit integer type.
78
| For example, the GNU C Compiler (`gcc') requires that 64-bit literals be
79
| appended with the letters `LL' standing for `long long', which is `gcc's
80
| name for the 64-bit integer type. Some compilers may allow `LIT64' to be
81
| defined as the identity macro: `#define LIT64( a ) a'.
82
*----------------------------------------------------------------------------*/
83
#define LIT64( a ) a##LL
84
85
/*----------------------------------------------------------------------------
86
| The macro `INLINE' can be used before functions that should be inlined. If
87
| a compiler does not support explicit inlining, this macro should be defined
88
| to be `static'.
89
*----------------------------------------------------------------------------*/
90
#define INLINE
int16
int int16
Definition:
SPARC-GCC.h:60
flag
int flag
Definition:
SPARC-GCC.h:58
uint32
unsigned int uint32
Definition:
SPARC-GCC.h:61
bits16
unsigned short int bits16
Definition:
SPARC-GCC.h:68
int32
signed int int32
Definition:
SPARC-GCC.h:62
int8
int int8
Definition:
SPARC-GCC.h:59
bits32
unsigned int bits32
Definition:
SPARC-GCC.h:69
sbits64
signed long long int sbits64
Definition:
SPARC-GCC.h:71
bits64
unsigned long long int bits64
Definition:
SPARC-GCC.h:70
Generated on Mon Feb 12 2024 13:02:48 for PandA-2024.02 by
1.8.13