Re: Removing the TARGET_* layer or not ?

[Steven Augart]

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