Cobra Forums

Cobra Command Line svn:2874 (post 0.9.3) / 2012-12-16
Copyright (C) 2003-2012 by Cobra Language LLC.

OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
CLR Platform: .NET
CLR Version: 4.0.30319.17929

Code: Select all

1    class Program
2        shared
3
4            def add(x, y) as dynamic
5                return x + y
6      
7            def main
8                print '*****Fun with type conversions *****'
9                numb1 as int16 = 9
10               numb2 as int16 = 10
11               print '[numb1] + [numb2] = [.add(numb1, numb2)]'


When I run the above, I experience...

Unhandled exception: Cobra.Core.UnknownMemberException: obj=9 (Int16), nam
e='op_Addition or op_Addition_Int16_Int16', type=System.Int16
in Cobra.Core.CobraImp.DynamicOp(String opMethodName, Object value1, Object va
lue2, Boolean promote)
in Cobra.Core.CobraImp.DynamicOp(String opMethodName, Object value1, Object va
lue2)
in Program.Main() в c:\workspace_Cobra\TypeConversions\Program.c
obra:line 11

Yeees.

cobra fails in this manner because the cobra RunTimeLib doesnt have support for dynamically typed operations (addition in this case) on int16 types.
Int32 are fully supported so a workaround would be casting or otherwise using Int32 types in your call ( or explicitly typing your .add method)

I'm not sure what the intention is here, as to fully support dynamic types and arithmetic operations in this manner suggests a combinatorial explosion of RTL support methods (number of arithmetic operations * number-of-numeric-types-factorial/2).

perhaps this could be better supported using a genericised RTL support method and some changes to codegen to use it (??)
Chuck?

I'm taking a look. There's no good way in .NET to constrain a generic parameter to "any sized" int, but there are possibly some other options.

It is unusual to see 16-bit ints and dynamic used together. The motivation for small ints is usually efficiency and the motivation for dynamic is flexibility at the cost of efficiency.

Off the top of my head I was thinking more along the lines of a RTL method genericised by type

Code: Select all

static public T1 op_Add<T1, T2>(T1 a, T2 b) {
   return a + b;
}


then the code gen rather than generating an exact named by type RTL method call
op_Add_int16_int16(a,b)
generates a type specified (type collapsed?) call to the generic method
op_Add<int16, int16>(a,b)

The other thought would be to have the RTL method use the widest or most common type ( int32 or int64) with a generic name
and rely on the compiler to match the call widening the args as it can - other parts of the RTL seem to use that (??)

Code: Select all

static public int32 op_add( int32 a, int32 b) { return a + b; }


code gen just calls op_add with the narrower typed ints - compiler auto widens

or alternatively codegen explicitly casts the ints to the wider type into the call and casts back down (perhaps with masking) on receipt

Code: Select all

(int16)op_Add((int32)a. (int32)b)


Looks like we already knew about this - theres an existing ticket for this already
ticket:171

I fixed this, at least for some cases. Since .NET runs on 32-bit (and 64-bit) systems, the run-time code will now promote to 32-bit ints before performing the operation which I think will be sufficient. 16-bits saves memory when packed in arrays and such, but there is no performance improvement for a 32-bit chip.

There may be other cases awaiting our attention, but at least this one is resolved (along with int8, and also X unsigned).

Does promoting break bitmasking on if conditions?

I don't see how it would, but if you had a specific case in mind, throw me some code.

Okay, I tried to come up with an example off the top of my head but I couldn't. I feel like getting more bits than expected will introduce bugs. I'm gonna play with this...

edit: Well, seems fine. The best I could do was muck it up trying to cast the result back to int16. Also, after a bit of reading this is how it works when strongly typed anyways Doh!

Btw I doubt people who are doing bitwise operations are using dynamically typed data. Partial classes, extension methods, multi-line strings and autocompletion are all 100 X more interesting.