harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Date Tue, 11 Mar 2008 13:29:37 GMT
+1 from me with the exception of BOOLEAN. Can we make it 32-bit always
and not sizeof(void*)? VME gurus opinions?

Pavel.

On 3/11/08, 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?
>
> --
> 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
> >
>


-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division
Mime
View raw message