2008/3/11, Pavel Pervov <[EMAIL PROTECTED]>: > +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 <[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? > > > > -- > > 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 > > > > > > > > -- > Pavel Pervov, > Intel Enterprise Solutions Software Division >
