Re: [cp-patches] Patch JCL_realloc()] (late, because accidently sent to wrong address)
Dear Brian, (and I thought we agreed to get rid of these kind of macros and would use normal functions as much as possible in the future.) When I remember right, the agreement was not to remove the macros completely, but instead make them into alias-names for target specific implementations of some OS-function. I believe Mark is correct here, we agreed to turn the macros into real functions for debugging purposes. And we'll probably use autoconf feature testing for portability. Getting to the alias-names of some OS-function is a first step and then convert them into real functions. When I understand the message from Michael from Aug-11-2004 right, we agreeded _not_ to remove the macro names completely (that would mean aicas will be kicked out from Classpath native code; I tried to explain this and why the macros are so important for aicas already in several messages), but instead make the following changes: [part from the orignal message] --- cut --- 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. I like this idea. In fact I had the same in mind. --- cut --- Based on this idea I developed a POSIX-target layer. Unfortuantelly I'm currently to busy with my daily work, thus I still could not prepare the needed patches (which is also a difficult work). Soon I will have enough time I like to do this. Sincerely, Torsten ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] Patch JCL_realloc()] (late, because accidently sent to wrong address)
Am Dienstag, 16. November 2004 10:46 schrieb Torsten Rupp: Dear Brian, (and I thought we agreed to get rid of these kind of macros and would use normal functions as much as possible in the future.) When I remember right, the agreement was not to remove the macros completely, but instead make them into alias-names for target specific implementations of some OS-function. I believe Mark is correct here, we agreed to turn the macros into real functions for debugging purposes. And we'll probably use autoconf feature testing for portability. Getting to the alias-names of some OS-function is a first step and then convert them into real functions. When I understand the message from Michael from Aug-11-2004 right, we agreeded _not_ to remove the macro names completely (that would mean aicas will be kicked out from Classpath native code; I tried to explain this and why the macros are so important for aicas already in several messages), but instead make the following changes: I wouldn't call this a decision. Based on this idea I developed a POSIX-target layer. Unfortuantelly I'm currently to busy with my daily work, thus I still could not prepare the needed patches (which is also a difficult work). Soon I will have enough time I like to do this. The main problem is that we have to get two groups under one hat. I still have to look into the code you sent to in private. Sorry, I had no time to do it yet. Michael -- Homepage: http://www.worldforge.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] Patch JCL_realloc()] (late, because accidently sent to wrong address)
Dear Mark, * native/jni/classpath/jcl.h, native/jni/classpath/jcl.c, native/jni/java-io/java_io_VMFile.c: Inserted native layer macros for OS functions, added parameter for old memory size to JCL_realloc() to be able to make an malloc() on system where no realloc() is available. I don't really get this patch. There is a lot of changes, reformatting, in this patch that make it difficult to see what is really going on. The patch also uses TARGET_NATIVE_MEMORY_ALLOC and TARGET_NATIVE_MEMORY_REALLOC macros which we never define Oh...sorry again. I accidently ignored to add native/target/generic/target_generic_memory.h and native/target/Linux/target_native_memory.h where these macros are included. Unfortunatelly it is very difficult for me to make simple patches with only a single set of changes (like requested by Michael), because usually I make the system running here including all needed changes. Then I have to do backsteps to make several single patches for some general change (e. g. replacement of OS functions). This took a lot of time and obviously this could also fail. I would like to supply patches with all needed changes included to avoid missing parts, but this seems to be to complex on the other side? (and I thought we agreed to get rid of these kind of macros and would use normal functions as much as possible in the future.) When I remember right, the agreement was not to remove the macros completely, but instead make them into alias-names for target specific implementations of some OS-function. I prepared a POSIX layer which should replace the generic layer with this approach. Each macro simply call a target specific native function resp. the POSIX compliant function (the POSIX layer use autoconf results). For us the native macors are very important, because we do not have a complete autoconf for all systems. Most of our systems are embedded systems with cross-compilers and there are many difficulties when using autoconf, e. g. functions which are available, but can not be used, broken system headers, different compiler options (autoconf is based on gcc-compatible compiler). If the macros would be discarded in Classpath, I see no way for us to go on with native code in Classpath. We should probably use autoconf to properly support systems that don't have a working realloc implementation. Autoconf has the following support for it: Macro: AC_FUNC_REALLOC If the realloc function is compatible with the GNU C library realloc (i.e., `realloc (0, 0)' returns a valid pointer), define HAVE_REALLOC to 1. Otherwise define HAVE_REALLOC to 0, ask for an AC_LIBOBJ replacement for `realloc', and define realloc to rpl_realloc so that the native realloc is not used in the main project. See AC_FUNC_MALLOC for details. For a cross-compiler system a test usually can not be executed, only compilation is possible. But for this specific case of realloc(), this is not sufficient, because the functions exists, but does not work. I see no way with autoconf to solve this problem (ideas are welcome). Thus that is the reason, why it is so important for me to be able to replace some specific target OS function by another implementation (e. g. malloc() and free()). Of course it would be possible to use some #ifdef-construct to handle this case, but imho this would make the code more complex (for each OS function a target-specific alternative function have to be integrated in a big #ifdef-#elsif-#else statement) and some manual setting of autoconf-values is needed (how to do this?). One other example: I yust reviewed classpath/native/jni/java-util/java_util_VMTimeZone.c where the time-zone id is detected (Java_java_util_VMTimeZone_getSystemTimeZoneId). This function is not portable to some of our systems (e. g. time(), mktime(), localtime() can not be used, even they are available, because the returned values are wrong). Also the function is already very complex, because there are 5 different autconf-values used. Of course the function may run on many Unix-like systems, but because only half of our systems are Unix-like, the function is useless on the others. My proposal - as discussed some time ago in the mailing list - is to keep the structure of the target native layer with the macros, but change the content into function calls which use autoconf whenever possible. This would keep the code flexible enough for strange systems (e. g. someone can replace functions for a specific target), too, but also readable and debuggable. Best regards, Torsten PS: I will send a new patch soon as possible, ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] Patch JCL_realloc()] (late, because accidently sent to wrong address)
On Mon, 2004-11-15 at 05:44, Dr. Torsten Rupp wrote: Dear Mark, (and I thought we agreed to get rid of these kind of macros and would use normal functions as much as possible in the future.) When I remember right, the agreement was not to remove the macros completely, but instead make them into alias-names for target specific implementations of some OS-function. I believe Mark is correct here, we agreed to turn the macros into real functions for debugging purposes. And we'll probably use autoconf feature testing for portability. Getting to the alias-names of some OS-function is a first step and then convert them into real functions. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
