OT; Will MS kill .NET ?

["Luís]

On Tuesday, 20 August 2013 at 13:37:00 UTC, Paulo Pinto wrote:
> Native code has nothing to do with systems programming or the 
> mapping of one-to-one from language to microprocessor 
> instructions.

At least in the context of "fully native" and C#, which we were 
discussing, I disagree. See below.

> Before the Java and .NET craziness, VM everywhere, all 
> mainstream compilers generated native code.
>
> Had Sun and Microsoft decided to generate native code instead 
> of their current solution, we wouldn't even be discussing this.

If I understand your point, you are defining (fully?) native as 
simply generating CPU opcodes and executing those directly. But I 
think this definition can be unhelpful, because there is an 
equivalence and a continuum between code and data. For instance:

   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.

   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).

   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.

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

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".

A VM is just a conceptual machine. Although we tend to use the 
term in a more restricted way, x86 and x64 are also VMs (which a 
microcoded CPU does not actually implement in "hardware"!)