harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: svn commit: r634547 [2/2] - in /harmony/enhanced/drlvm/trunk/vm: em/src/ include/open/ interpreter/src/ jitrino/src/codegenerator/ia32/ jitrino/src/codegenerator/ipf/ jitrino/src/jet/ jitrino/src/shared/ jitrino/src/vm/ vmcore/build/ vmcore/src/c
Date Sat, 08 Mar 2008 09:18:38 GMT
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

Mime
View raw message