3 ms·
Couldn't the various JIT languages piggyback on the CLR? That is, they wouldn't JIT to ARM, but compile to CLR and then execute that. Of course, that's some mi
by pgeorgi 15y ago
Couldn't the various JIT languages piggyback on the CLR? That is, they wouldn't JIT to ARM, but compile to CLR and then execute that.
Of course, that's some mighty overhead for "just one" platform.
- kevingadd 15y agoYeah, but there isn't a 1-1 correspondence between CLR bytecode and native instructions. If you want to access SIMD instruction sets on x86, x64 or ARM, the CLR won't let you do that.
- pgeorgi 15y agoIdeally the CLR takes care of that (it's in Microsoft's own interest to have it create good native code) I don't mean to translate "mov eax, ecx" to the CLR bytecodes of "ecx = eax;", but targetting CLR as kind of a CPU in its own right (with whatever capabilities it has).
- deleted 15y ago[deleted]
- jules 15y agoDynamic code generation is also disabled on the CLR in Metro. I ran into this when trying to port a compiler/IDE to Metro (i.e. NO reflection.emit/codedom/roslyn). It's basically impossible to write developer tools on Metro, in C++ or in C# doesn't matter. The best performing option is actually compiling to Javascript running in the browser...
- pjmlp 15y agoThis is just someone whining about not being able to use their favorite language for all tasks. Just use a language has implementations that target native code or MSIL, problem solved. A professional developer makes use of the best tool for the job, among the set of available ones.
- malkia 15y agoThere is no "best tool" for the job. Used to be that you've had one tool for the job 50 years ago, now you have 50 tools for the same job. And 500 more, And 5000 coming...