[Top][All Lists]

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

Re: Removing the TARGET_* layer or not ?

From: Ingo Prötel
Subject: Re: Removing the TARGET_* layer or not ?
Date: Wed, 04 Aug 2004 18:15:33 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Michael Koch wrote:
Am Mittwoch, 4. August 2004 10:06 schrieb Ingo Prötel:


Roman Kennke wrote:

Am Di, den 03.08.2004 schrieb Ingo Prötel um 15:39:

Hi Michael,

Michael Koch wrote:

Hi list, hi Ingo,

I just started porting/testing GNU classpath to solaris (2.6).
Its not really different to other unices (we currently support
linux and *BSD) but some things are. 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.

Ingo: Now my question are you really using the TARGET_* system
or is it only rotting around in GNU classpath ? I really wonder
if some AUTOCONF macros would be more helpful for you ?

Yes, the TARGET-layer is in active use here.

The TARGET-layer has two advantages:
1. It makes JNI-code more readable,
2. It makes porting simple.

It makes JNI-code more readable because whenever a native
function is called there is only one macro call. The other
possibility would be that one has ifdefs for every system
(possibly for every system+architecture) that one wants to
support with this code. This would make the JNI-code difficult
to read.

It makes porting easier in that one can reuse generic macros and
only needs to override specific macros that differ for a given
new system. And this all can happen without modifing the actual
JNI-code. So the main step in porting is creating a new
subdirectory in tartget name it Solaris. Copy over all the files
in the Linux target. Add this to the include path. Then just
work on the error that the compiler will find and where
necessary create Solaris specific macros.

If there is interest we could provide our Solaris, Darwin, and
MinGW TARGET-layer. This would probably help to understand how
this layer is helpful. In any case we can help if anyone needs
help understanding the code.

I have thought about how I would design this stuff in order to
write portable code:
1. first of all, try to stick to POSIX standard stuff ;)
2. Of course there are situations where this won't do. In this
case I would split out the non-portable stuff on a case-by-case
basis in the following scheme: Suppose you have the following
expressions in a function (pseudocode):

func() {

of which exp_b is not portable. Then make a function call out of

func() {

    TARGET_NATIVE_B();  // this is what it currently looks like


and define the function in a file in a file in an OS-specific

This is actually what the whole idea is about. Except that macros
are used instead of functions. The problem with functions is that
many embedded compilers cannot inline function calls. This would be
ok if the overhead would really be only one function call but if
you got through the JNI-code and replace every TARGET-macro with a
function call you will see that there are more function calls
involved. Maybe we could get some mixed mode where we leave the
macros in place and the macros for Linux just point to functions.
This would make the Linux code more debuggable.

the autotools should check for OSs/arches and include the correct
subdirs here. These functions must be kept minimal, in order to
avoid the effect that Michael mentioned, where you have to fix a
bug multiple times.

If one fixes a bug in the generic part it will be automatically
picked up in every system that uses the generic stuff. If a system
does not use the generic stuff most likely there will be no system
that will depend on this bug fix. Especially if one fixes a bug
somewhere this might as a side effect break another system that
depends on the bogous behavior. There is no way of testing it if
one doesn't have a target setup to test it on. So sometimes this
sort of isolation is good.

Note, that with this system we would avoid the use of macros
altogether (You see, I don't like them ;) I better go with a
well-thought-out design). Sure, there is the 'overhead' of 1
additional function call.

That is basically on function call for every TARGET-macro.

I'm not a friend of this one-OS-one-dir approach. I would more test for features with autoconf and use the features if present. This makes it more easy to port to another arch. When the feature is available there, use it. If not, add some code to make it work.

The advantage of having one-OS-one-dir is that one knows which files are involved. Otherwise one needs the latest autoconf run to determine all the variables to figure out what parts of the code actually runs. Or do I have it wrong?

The TARGET api is really not intutive and the very long MACRO names makes it even harder to understand. Sometimes the names just badly choosed. The "Linux" layer is full of bugs. And I suppose your other ports are too because they are copies of the "Linux" layer. Some bugs are fixed in the classpath version of "Linux". I wonder how many of them were ported to you other ports. When an autoconf approach you wouldnt even think about this. I know that with the autoconf approach the patches need a closed review and more testing before they go in but IMO this is much better then duplicatin bugs over several trees.

I actually didn't consider long names a problem since there is word completion every where. If the names are badly chosen the can be changed. They actually follow a convention:(Quote form the readme.txt)
  The naming pattern for native macros is like follows:

    TARGET_NATIVE_<module name>_<macro name>

  where <module name> is a name of a module, e. g. FILE; <macro name> is
  the name of the specific native macro, e. g. OPEN_READ.

I guess the TARGET_NATIVE_ part could be shortend.

I was pretty surprised when ypu wrote yesterday, that you have more "ports" then just "Linux". Why don't you submitted them ? I think it would be a very good idea to support as much OSes upstream as possible, even Plan9 and QNX and ...

I will see what I can put in. Though I don't think we have Plan9 (At least I 
don't know it). But we have an RTEMS port.


Ingo Prötel                                          address@hidden
aicas GmbH                              
Haid-und-Neu-Str. 18                        phone   +49 721 663 968-32
76131 Karlsruhe                             fax     +49 721 663 968-93

reply via email to

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