Re: [cp-patches] [RFC,Concept proposal]: Easing "target" dependency

[Roman Kennke]

Hi Guilhem,

> I would like to propose a code split to split the java interface from 
> accessing syscalls in File IO (and generally for all native IO). Some VM 
> may want (like us in kaffe) to change the way syscalls are called 
> without touching the java interface logic. So I am proposing to keep the 
> basic skeleton of the target layer but put the real code not in macro 
> but in real C functions. That way we will be able to add autoconf macros 
> without bothering the java interface and if some persons still want to 
> use the TARGET layer it is possible by simply using the macro inside the 
> C functions.

The macros have been introduced in favour of functions because at that
time some compilers didn't support inlining properly (and on some
targets we have here still don't). I generally agree that we can replace
most of the function-like macros with real inline functions. For
performance-sensitive parts however I would rather be a bit more
conservative (for the crazy compilers on some of the more exotic
platforms). Also I would not throw away the target macros, most of them
are actually quite important for portability. I will comment on some
changes so you better understand the problems:

>  /* FIXME: This can't be right.  Need converter macros. */
> -#define CONVERT_JLONG_TO_INT(x) TARGET_NATIVE_MATH_INT_INT64_TO_INT32(x)
> -#define CONVERT_INT_TO_JLONG(x) TARGET_NATIVE_MATH_INT_INT32_TO_INT64(x)
> +#define CONVERT_JLONG_TO_INT(x) ((int)(x))
> +#define CONVERT_INT_TO_JLONG(x) ((jlong)(x))

This won't work for systems that don't have a 64bit datatype. On systems
with 64bit datatypes the removed macro would expand to the cast that you
inserted, but for systems without 64bit types we need to expand to a
converter function or something other.
 
> -      flags =
> -     TARGET_NATIVE_FILE_FILEFLAG_CREATE |
> -     TARGET_NATIVE_FILE_FILEFLAG_READWRITE;
> -      permissions = TARGET_NATIVE_FILE_FILEPERMISSION_NORMAL;
> +      flags = O_CREAT | O_RDWR;
> +      permissions = FILEPERMISSION_NORMAL;

What should we do on systems without O_CREAT and O_RDWR? Or even worse,
when we have both, but have a different meaning? We have seen both
cases, the macros are there for a reason... In general, for portability
we may not have OS specific constants or datatypes in our code and
should instead have them replaced by a macro or converter function. A
function however would be overkill for converting constants IMO.

> -      return TARGET_NATIVE_MATH_INT_INT64_CONST_MINUS_1;
> +      return -1;

Again, this is not portable on systems without 64bit datatypes. On
systems with 64bit types this would expand to '-1' and on systems
without to 'struct {hi=-1; lo=0xff;}' for emulating 64bit.

> -  while (result != TARGET_NATIVE_OK);
> +  while (result != 0);

This is a question of style. What does 0 mean? It worked? Or it failed?
TARGET_NATIVE_OK is simply more speaking than 0.

> -      TARGET_NATIVE_FILE_AVAILABLE (native_fd, bytes_available, result);
> -      if (result != TARGET_NATIVE_OK
> -       && (TARGET_NATIVE_LAST_ERROR ()
> -           != TARGET_NATIVE_ERROR_INTERRUPT_FUNCTION_CALL))
> +      result = javafileio_available (native_fd, &bytes_available);
> +      if (result != 0 && result != EINTR)

error codes (errno) are also system specific. There are a number of
values that don't exist on all systems. See also target_native.h

>         JCL_ThrowException (env, IO_EXCEPTION,
> -                           TARGET_NATIVE_LAST_ERROR_STRING ());
> +                           strerror(result));

This does also not work on all systems. There are system functions that
don't work via errno and strerror() (like some of the dl* functions).

These comments should serve as examples to show why the target macros
are so important. I think we could agree on the following:

- replace function-like macros with inline functions (preferably don't
touch performance-sensitive parts for now)
- shorten some macro names to improve readability

I think we should not decrease portability by introducing changes like
the above mentioned. This would certainly hurt Kaffe, which is also
ported to a wide range of systems. The macros are there for a reason,
which is always that things are not working on all platforms like they
do on Unix. For portability we must keep the following in mind:
- we don't have all datatypes on all platforms, like 64bit types or
double
- we don't have all constants on all systems, like error codes
- we don't have the same functions on all systems, at best we could
assume Ansi C, with restrictions even there (i.e. I/O; not all systems
have a screen and want to redirect to a serial port or something
similar)
- not all systems have the same features, like varargs for macros,
attributes for variables, inlines, etc.

Cheers, Roman

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil