OT; Will MS kill .NET ?

[pjmp]

On Tuesday, 20 August 2013 at 16:34:26 UTC, Luís Marques wrote:
> ...
>
>   1. Compiler generates x86 code, which is executed directly by 
> the CPU, and nearly all the source program operations (setting 
> a variable, calling a function, etc.) are encoded directly in 
> the produced code. E.g. setting a variable is done directly 
> with a "mov" opcode.

Agree.

>
>   2. Compiler generates x86 code, which is executed directly by 
> the CPU, but some program operations are done indirectly using 
> helper functions/code which was not described in the source 
> code. E.g. setting a variable with memcpy (silly example), 
> creating a closure (actual D example, which uses a D runtime 
> function).

Agree.

>
>   3. The compiler generates x86, which is executed directly by 
> the CPU, but a lot of the source program logic is encoded as 
> data or calls to helper functions. This tends to happen when 
> you try to produce native code for scripting languages: instead 
> of dispatching bytecode operations using a switch(...) as you 
> would do in a typical interpreter, you call/execute helper code 
> directly (so we are still "native" in a certain sense). But the 
> program logic (e.g., "a+b") mostly happens in those helper 
> functions/code the compiler generates, because the semantics of 
> the language (e.g. prevent overflows when multiplying big 
> numbers by converting to arbitrary precision) demand those 
> operations, which don't have direct counterparts in the CPU ISA.

Your example for overflows means Turbo Pascal and Ada do not
compile to native code, right?

Because their runtime libraries do have numeric and bounds 
checking
code.

In this example you're mixing interpreter with native code.

>
>   4. You refactor those helper functions in a VM, and generate 
> bytecode which when interpreted will call them, instead of 
> calling them directly.

This is not native code.

>
> Etc. My point was that when the source language semantics 
> allows you to express constructs which can be directly and 
> efficiently executed by the CPU ISA ("systems programming" 
> would be an extreme of that) then you can probably say that you 
> are being "fully native" (bar assembly language programming). 
> When your Turing complete language can never be efficiently 
> executed by the underlying phyisical machine, even if the 
> compiler produces native CPU opcodes, then I think that is not 
> "fully native".

So this means even C is not fully native, because there are CPUs
that don't map directly to C instructions and require more help
from the C runtime library.