From: Götz Lindenmaier <goetz@ipd.info.uni-karlsruhe.de>
Date: Tue, 19 Aug 2003 09:29:34 +0000 (+0000)
Subject: ???
X-Git-Url: http://nsz.repo.hu/git/?a=commitdiff_plain;h=d7cbb84770860c70a90e96ae3bd4350d24e20120;p=libfirm

???

[r1705]
---

diff --git a/ir/tv/tv.c b/ir/tv/tv.c
index c78fd433d..518bc8afd 100644
--- a/ir/tv/tv.c
+++ b/ir/tv/tv.c
@@ -6,7 +6,6 @@
 /****i* tv/implementation
  *
  * AUTHORS
- *    Christian von Roques
  *    Matthias Heil
  *
  * NOTES
diff --git a/ir/tv/tv.h b/ir/tv/tv.h
index a8c2531c3..e187be10f 100644
--- a/ir/tv/tv.h
+++ b/ir/tv/tv.h
@@ -6,41 +6,6 @@
 
 /* $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_
 
@@ -56,7 +21,6 @@ Discussion of new interface, proposals by Prof. Waite:
  *   Internal representation for machine values.
  *
  * AUTHORS
- *    Christian von Roques
  *    Matthias Heil
  *
  * DESCRIPTION
diff --git a/ir/tv/tv_t.h b/ir/tv/tv_t.h
index c6b7c4691..1f042ab80 100644
--- a/ir/tv/tv_t.h
+++ b/ir/tv/tv_t.h
@@ -1,10 +1,9 @@
-/* Declarations for Target Values.
-   Copyright (C) 1995, 1996 Christian von Roques */
+/* Declarations for Target Values. */
 
 /**
 * @file tv_t.h
 *
-* @author Christian von Roques
+* @author Mathias Heil
 */
 
 /* $Id$ */