Re: Removing the TARGET_* layer or not ?

[Andrew Haley]

Ingo Prötel writes:

 > Roman Kennke wrote:
 > > 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.

I guess as long as we're stuck with C90 we can't use inline.
Am I right in thinking that GNU Classpath targets C90?

IMO, we shouldn't really be designing Classpath around the
infelicities of unfree compilers.

> > 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.

Macros are bad for a bunch of reasons, esp. debuggability and type
safety.

 > 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?

Well, that's the question: do we make Classpath harder to debug / read
in order to optimize the performance of some unfree C compilers?

Andrew.