[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
TARGET or
NATIVE or
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
multiplication!!).
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.
Sincerely,
Torsten
- Target native layer, Dr. Torsten Rupp, 2004/08/10
- Re: Target native layer, Mark Wielaard, 2004/08/10
- Re: Target native layer, Roman Kennke, 2004/08/10
- Re: Target native layer,
Dr. Torsten Rupp <=
- Re: Target native layer, Michael Koch, 2004/08/11
- Re: Target native layer, Dr. Torsten Rupp, 2004/08/12
- Re: Target native layer, Michael Koch, 2004/08/12
- Re: Target native layer, Dr. Torsten Rupp, 2004/08/12
- Re: Target native layer, Michael Koch, 2004/08/12