On Tue, 20 Aug 2013 18:34:24 +0200
"Luís Marques" <luis@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.

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.

On Tuesday, 20 August 2013 at 16:07:00 UTC, Kagamin wrote:
> http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx
> How would you implement this in native code?

Like we use to do in the old days when we were forced to rewrite Assembly on the fly.

Allocate a memory buffer with the required sizes and perform the required set of initializations.

This is no different than constructing C++ classes during runtime, initializing the required helper structures like vtbl and calling constructors.

Nothing that cannot be done with either a set of helper functions on the language runtime, or generating inline code.

Yes, I am aware that this requires the ability to execute code from the data segment.

--
Paulo

On 8/20/2013 3:18 PM, Paulo Pinto wrote:
> On Tuesday, 20 August 2013 at 16:07:00 UTC, Kagamin wrote:
>> http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx How would you implement this in native code?
> 
> Like we use to do in the old days when we were forced to rewrite Assembly on the fly.
> 
> Allocate a memory buffer with the required sizes and perform the required set of initializations.
> 
> This is no different than constructing C++ classes during runtime, initializing the required helper structures like vtbl and calling constructors.
> 
> Nothing that cannot be done with either a set of helper functions on the language runtime, or generating inline code.
> 
> Yes, I am aware that this requires the ability to execute code from the data segment.
> 
> -- 
> Paulo

Isn't the approach you're describing *much* more error-prone than the example above?

On Thursday, 22 August 2013 at 01:40:05 UTC, Gambler wrote:
> On 8/20/2013 3:18 PM, Paulo Pinto wrote:
>> On Tuesday, 20 August 2013 at 16:07:00 UTC, Kagamin wrote:
>>> http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx
>>> How would you implement this in native code?
>> 
>> Like we use to do in the old days when we were forced to rewrite
>> Assembly on the fly.
>> 
>> Allocate a memory buffer with the required sizes and perform the
>> required set of initializations.
>> 
>> This is no different than constructing C++ classes during runtime,
>> initializing the required helper structures like vtbl and calling
>> constructors.
>> 
>> Nothing that cannot be done with either a set of helper functions on the
>> language runtime, or generating inline code.
>> 
>> Yes, I am aware that this requires the ability to execute code from the
>> data segment.
>> 
>> --
>> Paulo
>
> Isn't the approach you're describing *much* more error-prone than the
> example above?

It is the compiler that generates the code, what is error prone about it?


--
Paulo