harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Date Tue, 11 Mar 2008 14:52:40 GMT
On Tue, Mar 11, 2008 at 9:22 PM, Alexey Varlamov
<alexey.v.varlamov@gmail.com> wrote:
> Guys,
>
>  Thanks for raising this theme. I'd like to generalize the issue, as we
>  have too much duplicating type definitions (in DRLVM in particular),
>  mixing both in inter-component interfaces and in implementations. This
>  is confusing and inconvenient, I suggest we adopt a single type system
>  in all components. So now we have:
>
>  1) portlib types (BOOLEAN, UDATA/IDATA, I_8/U_8 ... U_64/I_64) -
>  is the sole type system allowed in classlib now and used for public interfaces.
>  2) DRLVM types (Boolean, POINTER_SIZE_INT/POINTER_SIZE_SINT,
>  int8/uint8 ... int64/uint64) -
>  is widely used in DRLVM. I have to admit, the naming is inconsistent
>  and clumsy, sometimes provoking use of alternative definitions like
>  "int_ptr".
>  3) Scattered definitions to complement C++ type system like "int_ptr",
>  etc. I assume there is a common agreement to keep export interfaces
>  C-compliant so no way to rely on C++ specific types.
>  4) JNI types (jboolean/jint/jlong/jobject etc);
>  Well, I added the JNI types only because Alexei suggested to reuse
>  them. IMO they are not suitable for general adoption in C/C++ code:
>  - they are incomplete, e.g. no unsigned types and no platform-size int type;
>  - the jni_types header defines other non-relevant types specific for
>  JNI, and we should avoid cluttering general namespace.
>  5) APR provides a set of primitive types, yet it is incomplete for JVM building.
>
>  So the most reasonable way to unify the type systems is to switch
>  (DRLVM's code) to types provided by classlib's portlibrary. What do
>  you think?

Consistent type definition is definitely good. Btw, what's the
POINTER_SIZE_INT counterpart in port library?

Thanks,
xiaofeng
>  --
>  Alexey
>
>  08.03.08, Gregory Shimansky<gshimansky@apache.org> написал(а):
>  > On 8 марта 2008 Ilya Berezhniuk wrote:
>  > > Gregory,
>  > >
>  > > Yes, Boolean is a synthetic type, but it's defined as 'unsigned'.
>  > > UDATA represents BOOLEAN type which is used in few places only for
>  > > HyThread compatibility.
>  >
>  > Ah I see. I've confused these boolean definitions. I am starting to think
>  > we've got by far too many different booleans... :)
>  >
>  > > I agree with some Alexei's thoughts: in pure C interface we can use
>  > > C-style return values, i.e. use 0 as success (for boolean result) and
>  > > 0 for failure (when a pointer should be returned).
>  > >
>  > > Thanks,
>  > > Ilya.
>  > >
>  > > 2008/3/8, Gregory Shimansky <gshimansky@apache.org>:
>  > > > On 7 марта 2008 Mikhail Fursov wrote:
>  > > >  > Alexey,
>  > > >  > there is a problem with this commit.
>  > > >  > Some of methods that returns Boolean (that is 'unsigned') are
>  > > >  > described as 'bool' in vm_interface.h
>  > > >  > It's not the same and causes problems. For example I found that
H2092
>  > > >  > fails now in debug mode on Linux because of 'field_is_volatile'
>  > > >  > method.
>  > > >
>  > > > I see 3 different problems with 3 different used approaches
>  > > >
>  > > >  1. bool is a C++ type an cannot be used in a pure C interface. Don't
>  > > > tell me about extended C standards. Period.
>  > > >  2. Boolean is a synthetic type which is actually UDATA that corresponds
>  > > > to POINTER_SIZE_INT and this means by far unoptimal decision for a type
>  > > > that holds a single meaning bit.
>  > > >  3. jboolean is a type defined for Java only.
>  > > >
>  > > >  As long as we work on Java jboolean is the most universal definition
>  > > > since it is actually specified. In case JIT code may be reused for other
>  > > > code we might invent jitboolean to be equal in definition to jboolean
>  > > > both in spec and code. I would vote for such approach.
>  > > >
>  > > >  --
>  > > >
>  > > > Gregory
>  >
>  >
>  >
>  > --
>  > Gregory
>  >
>



-- 
http://xiao-feng.blogspot.com
Mime
View raw message