OMG I was trying to fix some dumb java asm thing I was making while playing this in the background and didn't realize the method was static cuz I stayed up all night xD. When u mention static invocation doesn't have a this pointer it made me realize that is whats wrong. My dumbass didn't realize it was static for ages and thought maybe it was somehow making the first local var index the first method param. Thank you so much idk how long I would of been stuck with that
Nice talk! Short question: 32:00: Instruction Index 8: Why is the long variable l2 loaded from constant pool index #3? I thought it should have been #4 Follow up question: How does the constant pool for this particular example look like? Thanks you!
From the sparse explanation about arguments on calls and return values it remains unclear to me weather the VM implements the return stack separately from the data/calculation stack or there is some hidden is going on in the shades. So what is it then for real about argument passing and return addresses on the stack? Another aspect unclear to me: In 31:41 arguments come as arguments in local variables, but when the call is presented (34:09) the arguments are provided by pushing on the stack, instead of of being passed as arguments in the locals registers. What is it now for real? On the stack or as arguments or in the locals registers? Just wondering ...
If I understand this correctly, unlike in C, the references are not to memory addresses but to stuff like classes. Thus the limit is not to the amount of memory you can address, but to the number of classes you can reference, and that number is never gonna get to the max you can address with 32 bits
There is iload instruction, which takes 1 byte operand. The operand is locals index. So instead of iload_4 (1-byte instruction) it will be iload 4 (1-byte instruction + 1-byte operand).
This Java Bytecode is Like C. Your God: Nothing Better Than C. Its Very Portable. Works on X86, ARM, PowerPC, Sparc. The Dalvik / Android Byte Code is Like C++. Less Portable. Will Only work on Sony's ARM CPU's and Intel. Wont work Well on PowerPC, Sparc.
Literally stumbled upon this but ended up watching the whole thing cuz of how brilliantly he explained it. Hats off 👏
Did he? It all was nice, but that's all, still there was a looot of unclear things here...
That was bloody brilliant, thank you soo much.
🔙
0
Thank you so much. Loved your presentation and learning from you
Wow, that is brilliant. Thanks !
Great talk!
OMG I was trying to fix some dumb java asm thing I was making while playing this in the background and didn't realize the method was static cuz I stayed up all night xD. When u mention static invocation doesn't have a this pointer it made me realize that is whats wrong. My dumbass didn't realize it was static for ages and thought maybe it was somehow making the first local var index the first method param. Thank you so much idk how long I would of been stuck with that
excellent explanation!!!
sometimes, the UA-cam algorithm can do wonders. i like it.
thanks for such an awesome talk... :)
now it actually seems easier than asm.
Nice talk! Short question:
32:00:
Instruction Index 8: Why is the long variable l2 loaded from constant pool index #3? I thought it should have been #4
Follow up question: How does the constant pool for this particular example look like?
Thanks you!
why did you think it should've been #4?
Because #3 is the first part of the double, #4 is the second part, likely implicit
god i love this speaker so much
Very lucid explanation. But the video would've looked a lot nicer if the slides were placed on the left and the speaker on the right.
Does anyone here knows how do you make a new Scanner and ask the user for input in Jasmin bytecode?
From the sparse explanation about arguments on calls and return values it remains unclear to me weather the VM implements the return stack separately from the data/calculation stack or there is some hidden is going on in the shades. So what is it then for real about argument passing and return addresses on the stack?
Another aspect unclear to me: In 31:41 arguments come as arguments in local variables, but when the call is presented (34:09) the arguments are provided by pushing on the stack, instead of of being passed as arguments in the locals registers. What is it now for real? On the stack or as arguments or in the locals registers? Just wondering ...
Thanks for pointing that out; I actually came here just for that
But I don't think JVM has registers to work with
started off really well but was really rushed after about the 40th minute :/
@8:31
I don't understand..
Why he said the program does not use CPU register?
Only use the stack to add two numbers together?
How is that possible?
JVM is an abstraction over a CPU.
The underlying machine code that translated from the byte code will use registers.
But in JVM there are no registers
How can the JVM has a heap of more than 4GB? Surely in 64-bit mode, references use "2 slots".
If I understand this correctly, unlike in C, the references are not to memory addresses but to stuff like classes. Thus the limit is not to the amount of memory you can address, but to the number of classes you can reference, and that number is never gonna get to the max you can address with 32 bits
The audio is kind of low :(
How will locals up to 4 will be written? for example iload_4 and iload_5?
There is iload instruction, which takes 1 byte operand. The operand is locals index. So instead of iload_4 (1-byte instruction) it will be iload 4 (1-byte instruction + 1-byte operand).
12:29 I thought for a second he said “act sus” xD
CLASS
So source code is for babies I wanna know bytecode and why it’s how it is
next time please normalize audio, I barely can hear him
Use of red as means to highlight code was a very stupid idea.
9:20 in, just a future reference for myself
future
can't hear anything
20:00:00
This Java Bytecode is Like C. Your God: Nothing Better Than C. Its Very Portable. Works on X86, ARM, PowerPC, Sparc.
The Dalvik / Android Byte Code is Like C++. Less Portable. Will Only work on Sony's ARM CPU's and Intel. Wont work Well on PowerPC, Sparc.
Speak louder it's not audible
9 Comments
So much inefficient bytecode, mainly due to poor desing. I know it's from 1995, but still...
This talk is a torture