Re: Removing the TARGET_* layer or not ?

[Steven Augart]

Andy Walter wrote:
> Hi,
>
> I'm sorry for the trouble which was caused by the target layer. Actually, I'm 
> quite surprised about the massive critique now. When we asked to check it in 
> more than one year ago, there was very little feedback and the feedback we 
> got was mainly quite positive.
Andy,

Thank you for the kind note.  I think some of the difference may be 
that several of us (I'm thinking of Michael Koch in particular) now 
have been doing considerable work in C on JNI.

> We are currently preparing the native layers of
>
> - RTEMS
> - Solaris
> - embOS

> for check in into the Classpath repository next week. Especially the embOS 
> layer for file I/O illustrates some bigger differences of embedded operated 
> systems. Since embOS is unfree, I expect the RTEMS port will be more 
> interesting to most people in this list. (I have to admit that the 
> differences are not as big there).


I appreciate you preparing the native layers for inclusion into the 
classpath repository.  Is any one of those platforms a platform which 
has a compiler that lacks a 64-bit type?

General Questions:

1) Is any classpath user other than AICAS on systems where there are 
only C '89 compilers available?

2) Anyone other than AICAS on systems where there is no 64-bit type 
available?

3) Anyone other than AICAS on systems where there is no support for 
"inline"?  And, if you are, is avoiding the overhead of two or three 
function calls when performing a C call file handling functions very 
very important to you?

4) Anyone, other than AICAS, on a system that doesn't support POSIX?

If only AICAS has some of those four constraints (I suspect this is 
so), then I think the Classpath project (that's us, folks!) will have 
to look at this from a software project management point of view, and 
make a direction decision about whether it is appropriate for the 
project's native code to meet those constraints, given the negative 
consequences that follow:

The consequence of constraint (1) is that we are restricting ourselves 
to C '89.  (For example, I define a variable in gthread-jni.c that I 
do not use until about a hundred lines later.  This is complicated.) 
The consequence of constraint (2) is that all operations on a "jlong", 
except for passing them as parameters (this includes comparison for 
equality and assignment to anything other than another jlong) have to 
be wrapped with macros whose names take up half of a screen line.  The 
consequence of the two parts of constraint (3) is that we apparently 
have to define use macros for operations that on every other 
multi-platform system I've worked on are handled via a uniform 
function interface (such as Mozilla's "nspr" portable runtime).   The 
consequence of (4) is that we have to worry about multi-platform 
support for what would otherwise be simple calls to open(2), seek(2), 
and fstat(2).

The megative consequences of all of these put together is to hide bugs 
that would otherwise be obvious to experienced C programmers, and to 
discourage some programmers from working on the native code.  This is 
 the case because the JNI code in Classpath is not really written in 
C.  It's written in a stack of macros on top of macros on top of 
macros, which eventually turn into C.

I am looking forward to learning more about the portability needs of 
the many projects that use Classpath.

--
Steven Augart

Jikes RVM, a free, open source, Virtual Machine:
http://oss.software.ibm.com/jikesrvm