+/*
+ * Project: libFIRM
+ * File name: ir/tv/tv.h
+ * Purpose: Representation of and static computations on target machine
+ * values.
+ * Author: Mathias Heil
+ * Modified by:
+ * Created:
+ * CVS-ID: $Id$
+ * Copyright: (c) 2003 Universität Karlsruhe
+ * Licence: This file protected by GPL - GNU GENERAL PUBLIC LICENSE.
+ */
+
/**
* @file tv.h
*
* Declarations for Target Values.
*/
-/* $Id$ */
-
-/*
-Discussion of new interface, proposals by Prof. Waite:
-(email of 13.6.2001)
-> 1. You say that you plan to replace the tv module. That replacement is
-> absolutely essential for an ANSI C translator: Section 6.1.3.2 of the
-> standard says that the representation of an integer_constant depends
-> upon its value as well as any suffixes that are attached to it. The
-> possible Firm modes for such a constant are i, I, l, and L. The
-> current tv module provides only one integer conversion routine, and
-> that requires conversion by the client. Since the type of the value
-> argument is long, this may preclude the representation of an unsigned
-> long constant.
->
-> There is a similar problem with floating constants. Floating
-> constants can be suffixed in C, and the mode depends upon the suffix.
-> It can indicate that the constant is of type long double, which your
-> current tv module is incapable of representing.
->
-> Your tv module interface accepts two kinds of information: modes and
-> values. Values obtained from the program text might be uninterpreted
-> strings, strings interpreted as integers, and strings interpreted as
-> reals. Values provided by the compiler are usually integers. Modes are
-> always Firm modes. It seems to me that the tv module should provide
-> tarval* constructors for three of the four kinds of values. Each of these
-> constructors should have an ir_mode parameter and one or more parameters
-> appropriate for the kind of value. As is currently the case, one
-> constructor should be provided for both compiler-generated integers and
-> source strings interpreted as integers. (This avoids problems of
-> different conversion radices -- the client does the conversion.) For
-> symmetry, the constructor for source strings interpreted as reals should
-> accept a long double parameter and require the client to do the
-> conversion.
-
-*/
-
#ifndef _TV_H_
#define _TV_H_
* Internal representation for machine values.
*
* AUTHORS
- * Christian von Roques
* Matthias Heil
*
* DESCRIPTION
tarval *new_tarval_from_entity (entity *ent, ir_mode *mode);
/**
- * Returns the associated entity of a tarval.
+ * Returns the associated entity of a tarval. Asserts if tarval does not
+ * contain an entity.
*/
+#define get_tarval_entity tarval_to_entity
entity *tarval_to_entity(tarval *tv);
/**
* The sort member of the struct mode defines which operations are valid
*/
-/** Negation of a tarval. */
+/** bitwise Negation of a tarval. */
+tarval *tarval_not(tarval *a);
+
+/** arithmetic Negation of a tarval. */
tarval *tarval_neg(tarval *a);
/** Addition of two tarvals. */
TVO_OCTAL, /**< use octal representation */
TVO_BINARY, /**< use binary representation */
TVO_FLOAT, /**< use floating point representation (i.e 1.342e-2)*/
- TVO_HEXFLOAT, /**< use hexadecimal floating point representation (i.e 0x1.ea32p-12)*/
+ TVO_HEXFLOAT /**< use hexadecimal floating point representation (i.e 0x1.ea32p-12)*/
} tv_output_mode;
/**
* This structure contains helper information to format the output
- * of a tarval of an mode.
+ * of a tarval of a mode.
*/
typedef struct tarval_mode_info {
tv_output_mode mode_output; /**< if != TVO_NATIVE select a special mode */