On Tue, Mar 11, 2008 at 9:22 PM, Alexey Varlamov <[EMAIL PROTECTED]> 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<[EMAIL PROTECTED]> написал(а): > > 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 <[EMAIL PROTECTED]>: > > > > 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
