[bitc-dev] Choice of runtime/VM

[Ben Kloosterman]

 >> I don’t think its that limiting  , There are a number of languages
 >that target CIL and the worst case they add some metadata that the JIT
 >or CIL to LLVM converter can read ( while not “correct”  it won’t be
 >that ugly ) .
 >
 >Plausible. The main concerns I have are concurrency-driven constraints
 >and unboxed unions. Can you suggest how one would annotate the unboxed
 >unions?

C# already does something  like this via field offset but it looks dodgy
...at least in terms of the CLR IR something can be done under the covers.

Eg 

[StructLayout(LayoutKind.Explicit)]
public struct PACKET
{
// snipped
  [FieldOffset(12)]
  public byte[] pbData

  [FieldOffset(12)]
  public ushort[] pwData;
} 

In the IL 
TypeDef #1 (02000002)
-------------------------------------------------------
	TypDefName: InProc_thr.PACKET  (02000002)
	Flags     : [Public] [ExplicitLayout] [Class] [Sealed] [AnsiClass]
[BeforeFieldInit]  (00100111)
	Extends   : 01000001 [TypeRef] System.ValueType
	Field #1 (04000001)
	-------------------------------------------------------
		Field Name: pbData (04000001)
		Flags     : [Public]  (00000006)
		CallCnvntn: [FIELD]
		Field type:  SZArray UI1
		Offset : 0x0000000c

	Field #2 (04000002)
	-------------------------------------------------------
		Field Name: pwData (04000002)
		Flags     : [Public]  (00000006)
		CallCnvntn: [FIELD]
		Field type:  SZArray UI2
		Offset : 0x0000000c


Note 2 fields overlapping at FieldOffset12. 

I don’t really understand the concurrency issues you mention however that’s
probably my ignorance as I'm not a language expert.

As I have stated you can do quite a bit of non GC work with C#  but it’s a
black art ( I learned some techniques from the Singularity source) .. 

  static int Main()
  {
        short *ptrShort = stackalloc short [50];  // can be user defined
struct
	  workWithData( ref ptrShort[5] );  
	
  } 

All of this runs on the stack ( native)  ,where I get stuck  is the runtime(
string!)  and lack of support for interfaces  ( I can live without
inheritance  , but interfaces are so nice for maintability and testing) as
this invariably results in boxing. Whereas with C++ you can use a base
abstract class.  

>Ben: I'm not opposed to targeting CLR. In fact, I've been paying some
 >attention to that. I *am* pretty well opposed to using CLR as an
 >intermediate form for native code.

Im not opposed to LLVM either just like to know the pros and cons hence my
prodding as it affects me as well. It's probably a good idea to use neither
LLVM or CIL as the IR  and then convert and test what happens .  I know the
mono guys have had a lot of issues with LLVM IR for some things ( generics
and interfaces specifically) , though the IR team has finally ( last few
years) taken the criticism and update LLVM IR with useful things like
metadata.. 

 >
 >As to "associated with Microsoft", I survived that; BitC would too.
 >

:-) 

Regards, 

Ben