From atobia at ca.ibm.com  Thu Feb 11 20:47:33 2016
From: atobia at ca.ibm.com (Tobi Ajila)
Date: Thu, 11 Feb 2016 15:47:33 -0500
Subject: considering the LDL
Message-ID: <201602112047.u1BKlefi010269@d01av04.pok.ibm.com>


In your "Java-centric foreign metadata" document you mention that
carrier types are chosen such that they "can efficiently represent
all possible values of the imported C type". Based on the examples I
assume the carrier types for all C native types are Java primitives
and for the special case (C's unsigned long long int) a boxed Number
object. Is this correct?

What about nested structures and pointers? In the following example
what are the carrier types of ptrField and nestedField?

struct Foo {
   struct Bar *ptrField;
   struct {
     int x, y;
   } nestedField;
};

> == types
>
> Are registers just bundles of bits and bytes, or do they have kinds?
> If they don't have kinds, then the LDL can remain silent about
> kinds also, since memory blocks don't have kinds either.
> I'd prefer it this way; leave it to the register allocator and
> code generator to pick register kinds.

If there are no types in the LDL how do we differentiate between
float and scalars when doing function calls? Is the calling convention
implied by the carrier type?

> Vladimir is experimenting with handling types larger
> than 64 bits from Java.  The basic building block is a type
> called Long2 (or Long4 or Long8) which carries a tuple of
> longs, without assigning them any semantics.  These types
> allow us to work with APIs that work on vector types,
> including APIs like intrinsic functions in <immintrin.h>.

Will Long2 be a primitive type, an object or a value type
representing 128 bits?

Are you suggesting that the JVM should be able to make calls to
intrinsic functions? or will we define a set of operations in Java,
similar to those found in <immintrin.h>, that can be applied to Long2?
Calling intrinsic functions from the JVM would be very inefficient.
Also, intrinsic functions have a very specific calling convention,
where will information about this be encoded?

Do you have any other use cases in mind for types larger than the
existing Java primitives?

Regards,
--Tobi