[Top][All Lists]

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

Re: Target native layer

From: Dr. Torsten Rupp
Subject: Re: Target native layer
Date: Wed, 11 Aug 2004 12:37:39 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Dear Roman,

1. We get rid of the TARGET_* layer (because we don't use it), and the
folks at AICAS could keep it on their own (much like some specialities
in kaffe, gcj and sablevm are handled). Of course, this would make
synchronizing their sources with the sources of GNU CP more difficult.

I assume if TARGET_* is removed, aicas have to do their own development of the native code. This would be possible, but of course this would not be very useful. For aicas it would be difficult, because we are almost "kicked-out" of the project (at least for the native code).

2. AICAS could contribute all their TARGET_* layer using code to GNU CP.
This way this layer would kinde make sense to GNU CP hackers. Maybe we
all can help to get rid of it nevertheless, but keep CP portable on
those rare systems.

You are right, we are late with contributing more layers. Because of limited manpower we still did not contributed some more layers, e.g . Solaris. We like to do this.

3. I dunno about the details, but we could go with a hybrid system: Most
of the portable stuff goes into the generic layer and is
autoconfiscated, like it was discussed to great lengths now.

The generic target is already doing this (at least partially). It is designed to use autoconf results to select the right OS-function or the right constants. Thus most of the code is located there. And that is also the reason why Linux seems to be "empty". It is not empty, it includes the generic cases of the target layer, thus there is not special implementation in Linux (please have a look at the final "include"-statement at the end of the files). If needed we can rename "generic" into "Linux" and discard the current "Linux". I do not want to do this, because this would look like the layer is limited to "Linux-like" systems.

In really
extreme cases the TARGET_* layer could be used.

The extrem cases are the problem. I spend a lot of time to handle such cases and it is difficult to do this with autoconf only. If you only use Unix-like systems, probably you will not run into this problem, thus autoconf only is nice. But imho soon you like to use other systems, too, e. g. Windows or embedded systems it becomes a challange. I can imagine it is difficult for someone to understand my viewpoint, if that person is not developing software for embedded systems.

- get rid of (multiline) macros where feasible,

Of course it would be possible to remove the "linefeeds", but that would not help (imho it would make it even more difficult to read).

I have the following suggestion:

Because the multiline-macros are to difficult to handle, we can replace that macros e. g. by direct function-calls. Thus a macro would become some "alias" only. We also can change (shorten) the names. For this we have to change the generic implementation. The advantages would be:

- debugging is possible
- type-safety
- easier to read

and for aicas

- we can keep most of the code we already have written
- we can continue to participate in Classpath

For aicas this would be some compromise, because we can still use the target-layer. What would be still important is, that in the native _no_ OS-specific feature is used directly, like constants or datatypes or OS-functions calls. With such a implementation we can survive.

What do you think?

- shorten macro names,

Please make some suggestion. If TARGET_NATIVE is to long, what about

NC or

Please take care that there is some risk for naming-collisions if the
name becomes to short (thus "OS" would probably be a bad choice).

- group files together more intelligently and

I do not understand what is wrong with the current grouping. The grouping is done by function-types, e. g. file, network, memory and so on. How to make it better/more clear?

- reduce (better: completely avoid) redundant code (bugs

Ok. There are some parts of the layer which could be improved. If we decide to keep the target layer in the code, then we should do these improvements.



reply via email to

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