4 ms·
I hope we agree that alternative mnemonics don't change anything essential about the code, so the equation "kind of" still holds. You have a point that it's har
by codeflo 5y ago
I hope we agree that alternative mnemonics don't change anything essential about the code, so the equation "kind of" still holds. You have a point that it's hard to formulate this precisely.
- archi42 5y agoAbsolutely. I tried, but gave up and decided to spent my saturday morning with the familiy instead ;-) I think a huge problem is how it is easy to mix up assembly that gets "processed" to /machine/ instructions with another kind of assembly that gets "processed" to VM ops. Which then get compiled again (usually JIT) before being executed. ILAsm is a nice example for that: It's some kind of assembly language, and you could probably go right down to x86 instructions (at least with little change). But you'll never do that. Simply because it is a stack language; and while you can produce e.g. x86 opcodes that "do the right thing", the whole stack traffic will kill performance. Instead, the VM will push the opcode stream through a (I guess JIT?) compiler: Small functions will be inlined, others will get a prologe and epiloge, parameters and return values are arranged according to the ABI's calling conventions. And then there will be all the usual register allocation stuff. [edit] And a lot of other magic. [/edit] Still, the original input is pretty much an assembly language.