Re: Removing the TARGET_* layer or not ?

[Ingo Prötel]

Hi,

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() {
>   exp_a;
>   exp_b;
>   exp_c;
> }
>
> of which exp_b is not portable. Then make a function call out of it:
>
> func() {
>   exp_a;
>   do_b();
    TARGET_NATIVE_B();  // this is what it currently looks like
>   exp_c;
> }
>
> and define the function in a file in a file in an OS-specific subdir.
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.
> But:
> 1. IMO this it is still better to write readable code (hey, this is free
> software and the code is supposed to be read).
> 2. a compiler should (when in optimization mode) try to inline such
> small function calls.
I guess that might work with gcc on  Linux / Solaris but as a general rule?
> As I said: I strongly vote for the removal of the TARGET_* stuff and go
> with a good,readable,debuggable,etc design instead.
>
> Best regards,
> Roman

Ingo

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