[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing the TARGET_* layer or not ?

From: Steven Augart
Subject: Re: Removing the TARGET_* layer or not ?
Date: Fri, 06 Aug 2004 01:47:02 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

Michael Koch wrote:

[...] When I wanted to do the needed changes I stumbled over the TARGET_* layer which adds (in my eyes) some unneeded complexity. It makes it more hard to read the code and all the stuff seem to be implemented either in target/generic or target/Linux with no real rule what have to go where. It's just difficult to understand. In fact I try to understand it since a long time and always fail because of its "indirectness". Personally I think some AUTOCONF checks would be more appropriate and would make the code much more readable and bugfixable. There are some known bugs in it but noone attacked them because none understands the code it seems.

You expressed my own feelings very well, Michael. I found the TARGET_ layer very unintuitive. Perhaps if I understood the problems of these embedded systems that use unfree compilers, I might feel differently.

Part of the problem is that Classpath is currently targeted to C '89/C '90, not to C '99. So we don't get features like 64-bit integers. Perhaps if we were to go over to the newer standard (now five years old!), we could dispense with stuff like:
 #define TARGET_NATIVE_MATH_INT_UINT64_TO_UINT32(v) ((jint)(v))
which appears in generic/target_generic_math_int.h.

(I would also like to point out that the above definition appears wrong to me -- it casts the (unsigned 64 bit) value v to a signed integer. I have my copy of the ANSI C '89 standard back at the office, so I can't quote the standard section on it.)

A great many of the operations in generic/target_generic_math_int.h don't seem to be used by Classpath. I wonder whether AICAS uses this stuff on a variety of systems, not just GNU Classpath.

If we are going to be using this stuff, we need a clear justification for it. I would suggest that we create subdirectories for a couple of these embedded platforms that Classpath is running on, and populate them, so that we can see what these extreme cases actually look like. As I understand matters, if AICAS is distributing software that uses Classpath on such platforms, then they also must be distributing the source code for the portability layer that Classpath requires in order to work on those platforms. If so, then we should have that all in the source tree, so that we can see why this is needed. Does this make sense? (It's almost two in the morning here in New York, so it may not :))

--Steve Augart

reply via email to

[Prev in Thread] Current Thread [Next in Thread]