harmony-dev mailing list archives

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

Ah yes, it is fixed size in portlib:
typedef U_32 BOOLEAN;
I believe there is no use case for platform-size boolean :)

>
> 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