I have a following code snippet in Kotlin:
val pair: Pair<Char,Char> = 'z' to 'z'
val comparison = pair.first.compareTo(pair.second)
println(comparison)
It fails at the second line with the following exception when I try to run it:
java.lang.ClassCastException: java.lang.Character cannot be cast to java.lang.Number
IDE (IntelliJ) doesn't complain about any wrong type. The issue is somehow related to the fact that Chars are coming from Pair<Char, Char> because 'z'.compareTo('z') works fine. Do you know how Kotlin resolves the following call?
I'm using Kotlin 1.0.4
TL;DR Apparently, this is a compiler bug.
The reason for this behavior lies in the bytecode that the Kotlin compiler generates for these two calls. (If you use IntelliJ IDEA, you can inspect the bytecode using the bytecode viewing tool).
First, the bytecode generated for the 'z'.compareTo('z') call is:
LINENUMBER 10 L3
BIPUSH 122
BIPUSH 122
INVOKESTATIC kotlin/jvm/internal/Intrinsics.compare (II)I
It calls kotlin.jvm.internal.Intrisics.compare() that compares two Ints, and the Chars are pushed to the stack directly as Ints (BIPUSH means push byte as integer).
But if you look at the bytecode for pair.first.compareTo(pair.second), you will find something like this:
ALOAD 1
INVOKEVIRTUAL kotlin/Pair.getFirst ()Ljava/lang/Object;
CHECKCAST java/lang/Number
INVOKEVIRTUAL java/lang/Number.intValue ()I
ALOAD 1
INVOKEVIRTUAL kotlin/Pair.getSecond ()Ljava/lang/Object;
CHECKCAST java/lang/Number
INVOKEVIRTUAL java/lang/Number.intValue ()I
INVOKESTATIC kotlin/jvm/internal/Intrinsics.compare (II)I
It calls kotlin.jvm.internal.Intrisics.compare, too, but here's what it tries to do before:
Get the component from the pair (the ALOAD 1 and INVOKEVIRTUAL ... lines)
Check that the object can be cast to Number (CHECKCAST ...)
Take java.lang.Number.intValue() (INVOKEVIRTUAL ...)
The second and the third lines are the culprit, Char is not a Number. It simply looks like the compiler generated incorrect bytecode for this comparison (it would be correct for the Number types, seems like Char is just not handled separately).
There is an issue about this in the Kotlin issue tracker, it will likely be fixed in future releases.
To fix the call in your code for now, you can convert the Chars manually before the call:
pair.first.toInt().compareTo(pair.second.toInt())
Related
I am reading the programming for the Java Virtual Machine by Joshua Engel, and I tried typing in one of the examples in the book. I understand that the book uses Oolong, and I am using Jasmin, however for such a simple example, and because the syntax of Oolong and Jasmin are so similar, I don't see why this doesn't work. As a side note, I haven't been able to find anything about the difference in syntax between Oolong and Jasmin. Could anyone point me towards a resource like this?
Here's the code, exactly as it is in the book:
.class Test
.method static run()I
bipush 9
bipush 6
imul
ireturn
.end method
And when I run Jasmin on this, I get the following errors:
Test.j:2: Warning - Syntax error.
.method
^
Test.j:2: Error - Couldn't repair and continue parse.
.method
^
So what is it that I'm doing wrong?
Jasmin requires .super keyword after .class.
The following code should compile fine:
.class Test
.super java/lang/Object
.method static run()I
bipush 9
bipush 6
imul
ireturn
.end method
I am implementing futures in Pharo. I came across this website http://onsmalltalk.com/smalltalk-concurrency-playing-with-futures. I am following this example and trying to replicate it on Pharo. However, I get to this point the last step and I have no idea what ">>" means: This symbol is not also included as part of Smalltalk syntax in http://rigaux.org/language-study/syntax-across-languages-per-language/Smalltalk.html.
BlockClosure>>future
^ SFuture new value: self fixTemps
I can see future is not a variable or a method implemented by BlockClosure. What should I do with this part of the code to make the promises/futures work as indicated at http://onsmalltalk.com/smalltalk-concurrency-playing-with-futures? I cannot add it on the Playground or as a method to my Promise class as it is, or am I missing something?
After adding the future method to BlockClosure, this is the code I try on the PlayGround.
value1 := [200 timesRepeat:[Transcript show: '.']. 6] future.
value2 := [200 timesRepeat:[Transcript show: '+']. 6] future.
Transcript show: 'other work'.
Transcript show: (value1 + value2).
Date today
The transcript displays the below error instead of the expected value of 12.
UndefinedObject>>DoIt (value1 is Undeclared)
UndefinedObject>>DoIt (value2 is Undeclared)
For some reason that it would be nice to learn, there is a traditional notation in Smalltalk to refer to the method with selector, say, m in class C which is C>>m. For example, BlockClosure>>future denotes the method of BlockClosure with selector #future. Interestingly enough, the expression is not an evaluable Smalltalk one, meaning, it is not a Smalltalk expression. It is just a succinct way of saying, "what comes below is the source code of method m in class C". Just that.
In Smalltalk, however, methods are objects too. In fact, they are instances of CompiledMethod. This means that they can be retrieved by sending a message. In this case, the message is methodAt:. The receiver of the message is the class which implements the method and the argument is the selector (respectively, C and #m, or BlockClosure and #future in your example).
Most dialects, therefore, implement a synonym of methodAt: named >>. This is easily done in this way:
>> aSymbol
^self methodAt: aSymbol
This puts the Smalltalk syntax much closer to the traditional notation because now BlockClosure>>future looks like the expression that would send the message >> to BlockClosure with argument future. However, future is not a Symbol unless we prepend it with #, namely #future. So, if we prefix the selector with the # sign, we get the literal Symbol #future, which is a valid Smalltalk object. Now the expression
BlockClosure >> #future
becomes a message, and its result after evaluating it, the CompiledMethod with selector #future in the class BlockClosure.
In sum, BlockClosure>>future is a notation, not a valid Smalltalk expression. However, by tweaking it to be BlockClosure >> #future, it becomes an evaluable expression of the language that returns the method the notation referred to.
ByteCode：ldc pushes a one-word constant onto the operand stack.
ldc takes a single parameter, , which is the value to push.
Most of the bytecodes in JVM can figure out their name by the code description. However, the ldc, I don't see any clue.
It is Load Constant. It loads an item from the constant pool onto the stack. The available types are:
int
float
java.lang.String
java.lang.Class
The Java 7 JVM added java.lang.invoke.MethodType and java.lang.invoke.MethodHandle.
The special variant ldc2_w will load an item of either long or double type onto the stack.
I suppose it is LoaD Constant but I do not have any reference.
The IAR compiler for ARM Cortex-M3 provides inline assembly. How can one store the address of a specific function to a location on the stack?
The C code would like this
void tick();
void bar()
{
int x;
// modify a value on stack
(&x)[4] = &tick;
}
While this works in general it is optimized away by the compiler in release build. I have tried to code it with inline assembly
void bar()
{
int x;
asm("ldr r0,%0" : : "i" (&tick));
asm("str r0,[sp+#0x10];
}
The ldr instruction is not accepted by the IAR compiler. The problem is that this instruction requires an addressing mode with a register and offset. The actual address of the function tick is store behind the function and the ldr instruction holds only the offset to the memory location the holds the actual address. The disassembly is similar like this:
ldr r0,??tick_address
str r0,[sp+#0x10]
bx lr ; return
??tick_address dd tick
How do I get the address of tick immediately to a register to use it for the stack manipulation?
GNU GCC inline assembly can do mere assignments via pseudo-empty asm() statements, like:
asm("" : "=r"(foo) : "0"(tick));
This tells the compiler:
The variable foo is to be taken from a register after the inline assembly block
The variable tick is to be passed in - in the same register (argument zero)
The actual choice of which register is to be used is completely left to the compiler.
The trick here are the output and input constraints - we just alias the (one and only) input to the output, and the compiler will, on its own, choose a suitable register, and generate the instructions necessary to load / store the respective variables before / after the "actual" inline assembly code. You could even do:
asm("" : "=r"(foo1), "=r"(foo2) : "0"(tick1) , "1"(tick2));
to do two "assignments" in a single inline assembly statement.
This compiler-generated "set the inputs, retrieve the outputs" code generation happens even if the actual inline assembly is empty (as here).
Another example: Say you want to read the current program counter - the PC register. You can do that on ARM via two different inline assembly statements:
asm("" : "=pc"(foo));
asm("mov %0, PC" : "=r"(foo));
This is not 100% identical; in the second case, the compiler knows that whatever register it wants to see foo in after the asm, it'll find it there. In the former, the compiler knows that were it to use foo after the statement, it needs to retrieve it from PC. The difference between the two would be if you did:
uintptr_t *val;
uintptr_t foo;
asm("" : "=pc"(foo));
*val = foo;
In this case, the compiler can possibly identify that this can be turned into a single str [R...], PC because it knows foo is in pc after the asm. Were you to write this via
asm("mov %0, PC" : "=r"(foo));
*val = foo;
the compiler would be forced to create (assuming it chooses R0 / R1 for foo/val):
MOV R0, PC
STR [R1], R0
The documentation for this behaviour is largely in the "Extended ASM" section of the GCC manuals, see the example for the contrived combine instruction.
There is no assignment the variable x in your code, therefore it's value is undefined and setting foo to an undefined value isn't required to change foo.
You need to assign the value to the variable, not to some memory location you assume the compiler use to implement it.
I wonder how variables marked as final are interpreted by Groovy (in 1.8.0, 1.8.1). I know that it makes sense in Java and it is possible to improve the performance and -- of course -- help to avoid stupid mistakes. I would like to learn if final may help the java compiler to optimize a program written in Groovy. I wonder if Groovy transformers preserve the final markings for variables.
It doesn't appear that groovyc will inline final variables the way javac does. I created two test scripts, one using final and one not:
final String message = "Hello World"
println message
String message = "Hello World"
println message
javap -c produced the same output for both classes:
0: invokestatic #18; //Method $getCallSiteArray:()[Lorg/codehaus/groovy/runtime/callsite/CallSite;
3: astore_1
4: ldc #58; //String Hello World
6: astore_2
7: aload_1
8: ldc #59; //int 1
10: aaload
11: aload_0
12: aload_2
13: invokeinterface #63, 3; //InterfaceMethod org/codehaus/groovy/runtime/callsite/CallSite.callCurrent:(Lgroovy/lang/GroovyObject;Ljava/lang/Object;)Ljava/lang/Object;
18: areturn
19: nop
javac optimized away the astore/aload:
Without final:
0: ldc #2; //String Hello World
2: astore_1
3: getstatic #3; //Field java/lang/System.out:Ljava/io/PrintStream;
6: aload_1
7: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
10: return
With final:
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3; //String Hello World
5: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
All that said, if performance is paramount, Groovy is a poor choice to begin with. Inlining final variables won't save you from the overhead of using reflection for method calls.
As Justin has said, if the optimisations that the compiler performs for final variables are important to you, then you shouldn't be using Groovy.
However, if the performance of Groovy is good enough, then it is still useful to mark variables final for two reasons:
Protecting your class' invariants, i.e. making sure that a value cannot be changed after object construction. Java enforces this at compile-time, Groovy only enforces this at runtime, but this is better than silently allowing an immutable value to be changed
Documentation. Users of your class can easily see which values they are allowed to change
Original post: Bug is open
not yet. but it might in a future, so I still mark them if appropriate.
https://issues.apache.org/jira/browse/GROOVY-1628
Update post: Bug is "Fixed" in 2.5.x
GROOVY-1628 - Inconsistent checking of final has been marked as "Fixed" on 2015-03-13 with "Fix Version/s" set to "2.5.0-beta-1".