Re: Removing the TARGET_* layer or not ?

[Michael Koch]

Am Mittwoch, 4. August 2004 10:27 schrieb 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?

It's not bad to support other compilers too but this should should not 
be used to make the code unreadable and hard to understand. If its 
hard to achieve better drop support for some compilers.


Michael