On Tue, 20 Aug 2013 18:34:24 +0200 "Luís Marques" <l...@luismarques.eu> wrote:
> 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: > I think what the discussion here (both sides) ultimately amounts to is this: Some "native" languages (ie, generates CPU opcodes) have strong support for low-level control (C/C++/D), and other native languages have weaker support for low-level control (a native compiler for C#/Java). Languages designed to run on a VM like JVM/.NET (but not VMs like LLVM IM, VirtualBox or "macro-assembly" opcodes) tend to have inherently weaker support for low-level control due to the VM. Such languages will likely continue having weaker low-level ability even when using true native compilation.