4 ms·

> So, anything that uses a JIT, such as the LLVM JIT, is not "native"? Correct. > Are programs written in C# not native, even on Windows? No they are not, be

> So, anything that uses a JIT, such as the LLVM JIT, is not "native"? Correct. > Are programs written in C# not native, even on Windows? No they are not, because .Net uses an intermediate representation, being Windows and Microsoft confers no magic "native"-ness. > Are programs in Java for Android not native, even though it is the language much of the OS is written in and what the standard UI toolkit is built for? Programs in Java for Android are not native. Much of the kernel (Linux) is written in C. According to "Francesco Iovine, AndroidStudio lover" over at Quora[0] the UI toolkit is written in Java and the virtual machines (Dalvik and Art) are written in C++. > Is Emacs not native? Emacs is a strange and evil beast whose name we shall not invoke. No, but seriously – I imagine Emacs is a hybrid native / Emacs lisp program. Many programs with embedded scripting languages are hybrid beasts but they ought to be thought of as native apps if they are compiled for a certain bare metal hardware platform. I presume the core of Emacs is C. Ergo, native. > Does it really matter if the runtime (which is machine code) was made by the compiler developer or by the application developer in some cases? Yes, I believe it does matter. > I feel like there's an arbitrary line, and it's not entirely useful distinction to make. No, I don't believe it's arbitrary. > A native app can be big and slow and ugly and fail to follow the OS UI guideliness. An app with a runtime can be small(ish) and fast and beautiful and strictly adhere to the UI guidelines for the OS in question. I want the small, fast, beautiful, app with standard UI behavior, no matter whether it's delivered with a runtime embedded or built from C/C++ (and a few others) and without a JIT. True. But that is neither here nor there, that's a whole other issue. > I mean, we're just arguing semantics here, which is kinda silly. No, we are not. A native app is one which is either hand-crafted assembly for a specific hardware platform or compiled ahead of time targeting a specific platform. Native code is non-portable, the source code might be portable, but generally is not unless care is taken. Assembly code is never portable. Non-native (whether by VM: Java, C#, … or interpreted: Ruby, Python, …) tends to be more portable. [0] https://www.quora.com/What-programming-language(s)-is-Android-written-in https://www.quora.com/What-programming-language(s)-is-Androi...

kazinator 9y ago
Suppose I write a C program and then deploy it on a target machine where it is continuously running thereafter. Then I develop a loadable module (.so) which I compile, upload to the target and get the C program to load it with dlopen. Is that native or not? If it's native, why isn't JIT to machine code not native? Because of the convenience of all of the above happening on a fine-grained level (individual functions), and all on the target machine? Also, what is "compiled ahead of time"? Ahead of what time? Why is that specific time important? Obviously, code is compiled ahead of its compiled image being run; the compiled version cannot be run any sooner. Any JIT-ted function is compiled ahead of being called. On most operating systems, we can load programs after the OS boots. Those programs can be developed after the OS booted. I think that the only true definition of "native" is that the program image was compiled before the hardware was built and turned on for the first time, and was present in its ROM. Anything else is not "ahead of time" and not native, damn it! Installing a program on your PC is just a form of JIT. The system was fired up without that program being there, and the program was snuck in just moments before the user's intent to use that program. Not ahead of the True Scotsmans proper time: the time when components were stuffed into the circuit board and it was powered up.
- chrisseaton 9y ago
  I think you're looking a bit too manically for holes in what is a pretty informal term that's useful in everyday discussions. It's not a mathematical proof that you're a genius for finding a gap in.
  - kazinator 9y ago
    The term is misused. Native means "native machine code", in any shape or form with no interpretation layer in between. OP seems to be confused between native vs. non-native axis and monolithic/static vs. modular/dynamic. If the software image is compiled in its entirety before being installed on a target, that is "monolithic". If parts of it can be dynamically loaded, it is "modular". Dynamic loading of functions with JIT is just heaping on more modularity: hyper-modular. A situation involving JIT is non-native only in the sense or to the extent that there is non-JIT-ted code in the image. If there is an interpreter so that some things execute without being JITted, those things are not native.
    - igravious 9y ago
      I don't believe that the term is not misused. What is happening perhaps is that you disagree with the term. And that's fine, that's your prerogative. I don't think that I am confused.
pjmlp 9y ago
> No they are not, because .Net uses an intermediate representation, being Windows and Microsoft confers no magic "native"-ness. So AS/400 applications are not native, given that they use an intermediate representation with a kernel level JIT? Same applies to other mainframes that use a micro-coded CPU to execute the portable binaries using intermediate representation on their executables. This includes C and C++ on those platforms, by the way. .NET has had AOT support since early days, even though NGEN is not that good. > Programs in Java for Android are not native. Java is AOT compiled to native code on installation on Android 5 and 6. https://source.android.com/devices/tech/dalvik/#AOT_compilation https://source.android.com/devices/tech/dalvik/#AOT_compilat... Starting with Android 7, it is interpreted in a tight Assembly interpreter, JITted with PGO, finally AOT compiled into a code cache. https://source.android.com/devices/tech/dalvik/jit-compiler https://source.android.com/devices/tech/dalvik/jit-compiler There are AOT compilers available for Java and C#, just as there are interpreters for C and C++.
- igravious 9y ago
  hi pjmlp! love reading your comments :) > So AS/400 applications are not native, given that they use an intermediate representation with a kernel level JIT? Thanks for making me read up on AS/400 (or System i as IBM now calls[0] it.) I found this article: [TIMI – Protecting Investments and Integrity in IBM i](http://ibmsystemsmag.com/blogs/you-and-i/archive/timi-protecting-investments-and-integrity-in-ibm-i/ http://ibmsystemsmag.com/blogs/you-and-i/archive/timi-protec...) – it says, “Each program that is compiled on IBM i gets turned into a set of TIMI instructions. Essentially, it gets compiled down to a set of intermediate code. For decades, that’s been a pretty common step for a compiler to take – get to an intermediate representation of the program before creating the machine-level instructions. One big difference, though, is that the compiler on IBM i does not go any further. It leaves the intermediate code connected to the program object, and then the lower levels of IBM i act on the intermediate code to translate it into the instructions used by the Power hypervisor and Power processor beneath the OS. IBM i does this only when necessary, not every time the program executes. Typically, the translation takes place once when the program is moved from one release of the operating system to a later one, and never again while it runs on that later release.” > Java is AOT compiled to native code on installation on Android 5 and 6. Then by your reasoning and terminology I think you'd also call IBM's tech AOT compiled, not JIT'd given that it happens once per OS release or app move, not each time the app is executed. And I would say that the applications that get delivered this way on AS/400 and Android 5 and 6 are delivered as non-native (intermediate code as the article says). And then get translated AOT to native which is stored somewhere else and the non-native code is kept around. Neat, I didn't know that about Android 7 and Dalvik. Is it the same for Art? > There are AOT compilers available for Java and C#, just as there are interpreters for C and C++. This I did know. :) Always welcome your insights, thanks! [0] https://en.wikipedia.org/wiki/IBM_System_i https://en.wikipedia.org/wiki/IBM_System_i
jhgb 9y ago
>> So, anything that uses a JIT, such as the LLVM JIT, is not "native"? > Correct. Oh, come on. You can't seriously believe this nonsense. A native C++ program embedding (for example, to parametrically specialize some constructs at run time) an LLVM JIT which is in C++ again is going to be as native as they come. > I presume the core of Emacs is C. Ergo, native. And that C++ program I mentioned isn't, according to you, even though most of Emacs is delivered in interpreted byte code form. And if Emacs stated JITting the bytecode, it would cease being native. You really seem to have some weird and/or inconsistent definitions.

kazinator 9y ago

Suppose I write a C program and then deploy it on a target machine where it is continuously running thereafter. Then I develop a loadable module (.so) which I compile, upload to the target and get the C program to load it with dlopen. Is that native or not? If it's native, why isn't JIT to machine code not native? Because of the convenience of all of the above happening on a fine-grained level (individual functions), and all on the target machine? Also, what is "compiled ahead of time"? Ahead of what time? Why is that specific time important? Obviously, code is compiled ahead of its compiled image being run; the compiled version cannot be run any sooner. Any JIT-ted function is compiled ahead of being called. On most operating systems, we can load programs after the OS boots. Those programs can be developed after the OS booted. I think that the only true definition of "native" is that the program image was compiled before the hardware was built and turned on for the first time, and was present in its ROM. Anything else is not "ahead of time" and not native, damn it! Installing a program on your PC is just a form of JIT. The system was fired up without that program being there, and the program was snuck in just moments before the user's intent to use that program. Not ahead of the True Scotsmans proper time: the time when components were stuffed into the circuit board and it was powered up.

chrisseaton 9y ago
I think you're looking a bit too manically for holes in what is a pretty informal term that's useful in everyday discussions. It's not a mathematical proof that you're a genius for finding a gap in.
- kazinator 9y ago
  The term is misused. Native means "native machine code", in any shape or form with no interpretation layer in between. OP seems to be confused between native vs. non-native axis and monolithic/static vs. modular/dynamic. If the software image is compiled in its entirety before being installed on a target, that is "monolithic". If parts of it can be dynamically loaded, it is "modular". Dynamic loading of functions with JIT is just heaping on more modularity: hyper-modular. A situation involving JIT is non-native only in the sense or to the extent that there is non-JIT-ted code in the image. If there is an interpreter so that some things execute without being JITted, those things are not native.
  - igravious 9y ago
    I don't believe that the term is not misused. What is happening perhaps is that you disagree with the term. And that's fine, that's your prerogative. I don't think that I am confused.

pjmlp 9y ago

> No they are not, because .Net uses an intermediate representation, being Windows and Microsoft confers no magic "native"-ness. So AS/400 applications are not native, given that they use an intermediate representation with a kernel level JIT? Same applies to other mainframes that use a micro-coded CPU to execute the portable binaries using intermediate representation on their executables. This includes C and C++ on those platforms, by the way. .NET has had AOT support since early days, even though NGEN is not that good. > Programs in Java for Android are not native. Java is AOT compiled to native code on installation on Android 5 and 6. https://source.android.com/devices/tech/dalvik/#AOT_compilation https://source.android.com/devices/tech/dalvik/#AOT_compilat... Starting with Android 7, it is interpreted in a tight Assembly interpreter, JITted with PGO, finally AOT compiled into a code cache. https://source.android.com/devices/tech/dalvik/jit-compiler https://source.android.com/devices/tech/dalvik/jit-compiler There are AOT compilers available for Java and C#, just as there are interpreters for C and C++.

igravious 9y ago
hi pjmlp! love reading your comments :) > So AS/400 applications are not native, given that they use an intermediate representation with a kernel level JIT? Thanks for making me read up on AS/400 (or System i as IBM now calls[0] it.) I found this article: [TIMI – Protecting Investments and Integrity in IBM i](http://ibmsystemsmag.com/blogs/you-and-i/archive/timi-protecting-investments-and-integrity-in-ibm-i/ http://ibmsystemsmag.com/blogs/you-and-i/archive/timi-protec...) – it says, “Each program that is compiled on IBM i gets turned into a set of TIMI instructions. Essentially, it gets compiled down to a set of intermediate code. For decades, that’s been a pretty common step for a compiler to take – get to an intermediate representation of the program before creating the machine-level instructions. One big difference, though, is that the compiler on IBM i does not go any further. It leaves the intermediate code connected to the program object, and then the lower levels of IBM i act on the intermediate code to translate it into the instructions used by the Power hypervisor and Power processor beneath the OS. IBM i does this only when necessary, not every time the program executes. Typically, the translation takes place once when the program is moved from one release of the operating system to a later one, and never again while it runs on that later release.” > Java is AOT compiled to native code on installation on Android 5 and 6. Then by your reasoning and terminology I think you'd also call IBM's tech AOT compiled, not JIT'd given that it happens once per OS release or app move, not each time the app is executed. And I would say that the applications that get delivered this way on AS/400 and Android 5 and 6 are delivered as non-native (intermediate code as the article says). And then get translated AOT to native which is stored somewhere else and the non-native code is kept around. Neat, I didn't know that about Android 7 and Dalvik. Is it the same for Art? > There are AOT compilers available for Java and C#, just as there are interpreters for C and C++. This I did know. :) Always welcome your insights, thanks! [0] https://en.wikipedia.org/wiki/IBM_System_i https://en.wikipedia.org/wiki/IBM_System_i

jhgb 9y ago

>> So, anything that uses a JIT, such as the LLVM JIT, is not "native"? > Correct. Oh, come on. You can't seriously believe this nonsense. A native C++ program embedding (for example, to parametrically specialize some constructs at run time) an LLVM JIT which is in C++ again is going to be as native as they come. > I presume the core of Emacs is C. Ergo, native. And that C++ program I mentioned isn't, according to you, even though most of Emacs is delivered in interpreted byte code form. And if Emacs stated JITting the bytecode, it would cease being native. You really seem to have some weird and/or inconsistent definitions.