3 ms·

What is the question?

by marvy 11y ago

graycat 11y ago
The question was: > So, how do I connect what that .NET Framework 4.0 VBC.EXE does with the discussion in the OP?
- MichaelGG 11y ago
  It doesn't at the moment. .NET Native only applies to Windows Store (metro) apps. But in theory, it would work like a super-powered ngen.exe does (look up ngen if you don't know). But instead of still requiring a runtime installed, .NET Native will also link in the required bits of the runtime statically (the GC for instance). This model is old and has been discussed quite a bit. Mono has supported it for a long time. MS has been ideologically opposed to it for over a decade and only just recently reversed their opinion, probably due to limited resources on low-end devices that MS has now realised are important.
- msbarnett 11y ago
  The VB compiler compiles your code, not into native machine code, but into an intermediate representation targeting the virtual machine defined by the Common Language Runtime. This intermediate representation is known as CIL (Common Intermediate Language), and it is the bytecode that the .Net CLR then JITs at runtime. This article is about compiling .Net code direct to machine code and skipping the whole CIL/CLR/JIT chain.
  - graycat 11y ago
    Thanks for the progress. I've used virtual machines for decades, e.g., IBM's VM with the interactive CMS (Conversational Monitor System). In what sense is the Microsoft CIL/CLR a virtual machine? E.g., does it have any security properties, e.g., restrictions via some attribute control lists? The CLI is a virtual machine only in the sense that the byte codes are not actual machine instructions for any real processor core but are just some intermediate code instructions for an imaginary machine that does not really exist and, in that sense, is virtual? So, on Windows, say 7, 8.1, 10, Windows Server of some year, etc., suppose I take a file A.VB I've typed in with Visual Basic .NET source code, give that file A.VB to the .NET program VBC.EXE, which is in the collection of .NET files, and get out from running VBC.EXE file A.EXE. Now A.EXE has CIL byte code? Why byte code? Or, in what sense can each code be only one byte long? Does this byte code mean that it would be the same for running on 32 bit Intel x86 processors, 64 bit Intel processors, ARM processors, etc.? The CLR part is mostly run time, that is, code my program A.VB and A.EXE needs to run, that is, in old terms, a library to be linked in via a linkage editor? Then with .NET on Windows, the JIT work also plays the role of a linkage editor? One old trick was, don't even bring in the code to be linked and, really, don't even link to that code and, instead, as the program runs and such code gets called, that is, an attempt is made to use it, in case that happens (which maybe often it won't), there is a software fault, interrupt, or some such and the JIT code, still in Windows and still available to run, only then, after the interrupt, actually gets and links the code that is needed but so far was missing? Another old trick was, really, never bring that library code in the user's program, do link to it, but have the code it part of the user's address space that is shared with all the user address spaces or even in another security ring -- maybe Microsoft is also doing some such trick? I just outlined the Windows Global Cache, e.g., mostly from DLLs instead of EXEs? Okay, I can see the point, as in the OP, of the effort for native. Indeed, I've suspected that on Windows frequently used programs are kept in a cache somewhere and, likely, ready to read into an address space or part of a process as fast as possible, maybe even with the usual address relocation work already done. So, this looks like an under the covers version of native for Windows? Ah, I just looked up Microsoft's ngen, and maybe what I just described was ngen? I've seen no very clear documentation of these issues. I've been guessing at what happens, and that's not so good. Thanks for the tutorial.
    - wvenable 11y ago
      Some of your questions are because there is a lot of overloaded terminology. Virtual Machine, for example, has two meanings: 1) A system virtual machine provides a complete system platform which supports the execution of a complete operating system (OS).[1] These usually emulate an existing architecture, and are built with the purpose of either providing a platform to run programs where the real hardware is not available for use (for example, executing on otherwise obsolete platforms), or of having multiple instances of virtual machines leading to more efficient use of computing resources, both in terms of energy consumption and cost effectiveness (known as hardware virtualization, the key to a cloud computing environment), or both. 2) A process virtual machine (also, language virtual machine) is designed to run a single program, which means that it supports a single process. Such virtual machines are usually closely suited to one or more programming languages and built with the purpose of providing program portability and flexibility (amongst other things). An essential characteristic of a virtual machine is that the software running inside is limited to the resources and abstractions provided by the virtual machine—it cannot break out of its virtual environment. The CLI is the second type of virtual machine and something like VirtualBox, VMware, and IBM mainframe VM's are the first kind. > Why byte code? Or, in what sense can each code be only one byte long? Again, it's not "byte code" it's "bytecode" which is defined here: https://en.wikipedia.org/wiki/Bytecode https://en.wikipedia.org/wiki/Bytecode "Bytecode, also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter"
      - graycat 11y ago
        Thanks. Okay, I know some about the details of IBM's VM and a little about VMware. I have wondered: The way VM has worked on IBM mainframe instruction set has been partly due to an accident of the design of that instruction set and, then, some extensions for VM. Really, that way, tough for the program running to know if it is running as a virtual machine or not. So, in particular, the program running on VM can be using privileged instructions and not know that it doesn't really have access to the real hardware. So I've wondered if the Intel x86 instruction set also has this accident and, thus, can run operating systems that use privileged instructions but not know they are running on a VM. Or maybe the ability to run on a VM was from some extensions to the Intel instruction set. Do you know? Does the Microsoft CLI/CLR software have some security features beyond just any native program in, say, Fortran or assembler running in an address space, process, or whatever Microsoft calls where a program runs? I'm beginning to get the prerequisites for reading the OP, that is, understanding what the long standard alternative to native code has been. Heck, I can understand native code -- at one time I entered some simple programs via the computer console sense switches. And I printed out the object listing from a Fortran compiler and went over the machine language instructions one by one. I discovered that even for some simple code and a good Fortran compiler, assembler could be faster by a factor of several. Just read the Wikipedia article. Nice and easy. Thanks.

What is the question?

by marvy 11y ago

What is the question?

graycat 11y ago

The question was: > So, how do I connect what that .NET Framework 4.0 VBC.EXE does with the discussion in the OP?

MichaelGG 11y ago
It doesn't at the moment. .NET Native only applies to Windows Store (metro) apps. But in theory, it would work like a super-powered ngen.exe does (look up ngen if you don't know). But instead of still requiring a runtime installed, .NET Native will also link in the required bits of the runtime statically (the GC for instance). This model is old and has been discussed quite a bit. Mono has supported it for a long time. MS has been ideologically opposed to it for over a decade and only just recently reversed their opinion, probably due to limited resources on low-end devices that MS has now realised are important.
msbarnett 11y ago
The VB compiler compiles your code, not into native machine code, but into an intermediate representation targeting the virtual machine defined by the Common Language Runtime. This intermediate representation is known as CIL (Common Intermediate Language), and it is the bytecode that the .Net CLR then JITs at runtime. This article is about compiling .Net code direct to machine code and skipping the whole CIL/CLR/JIT chain.
- graycat 11y ago
  Thanks for the progress. I've used virtual machines for decades, e.g., IBM's VM with the interactive CMS (Conversational Monitor System). In what sense is the Microsoft CIL/CLR a virtual machine? E.g., does it have any security properties, e.g., restrictions via some attribute control lists? The CLI is a virtual machine only in the sense that the byte codes are not actual machine instructions for any real processor core but are just some intermediate code instructions for an imaginary machine that does not really exist and, in that sense, is virtual? So, on Windows, say 7, 8.1, 10, Windows Server of some year, etc., suppose I take a file A.VB I've typed in with Visual Basic .NET source code, give that file A.VB to the .NET program VBC.EXE, which is in the collection of .NET files, and get out from running VBC.EXE file A.EXE. Now A.EXE has CIL byte code? Why byte code? Or, in what sense can each code be only one byte long? Does this byte code mean that it would be the same for running on 32 bit Intel x86 processors, 64 bit Intel processors, ARM processors, etc.? The CLR part is mostly run time, that is, code my program A.VB and A.EXE needs to run, that is, in old terms, a library to be linked in via a linkage editor? Then with .NET on Windows, the JIT work also plays the role of a linkage editor? One old trick was, don't even bring in the code to be linked and, really, don't even link to that code and, instead, as the program runs and such code gets called, that is, an attempt is made to use it, in case that happens (which maybe often it won't), there is a software fault, interrupt, or some such and the JIT code, still in Windows and still available to run, only then, after the interrupt, actually gets and links the code that is needed but so far was missing? Another old trick was, really, never bring that library code in the user's program, do link to it, but have the code it part of the user's address space that is shared with all the user address spaces or even in another security ring -- maybe Microsoft is also doing some such trick? I just outlined the Windows Global Cache, e.g., mostly from DLLs instead of EXEs? Okay, I can see the point, as in the OP, of the effort for native. Indeed, I've suspected that on Windows frequently used programs are kept in a cache somewhere and, likely, ready to read into an address space or part of a process as fast as possible, maybe even with the usual address relocation work already done. So, this looks like an under the covers version of native for Windows? Ah, I just looked up Microsoft's ngen, and maybe what I just described was ngen? I've seen no very clear documentation of these issues. I've been guessing at what happens, and that's not so good. Thanks for the tutorial.
  - wvenable 11y ago
    Some of your questions are because there is a lot of overloaded terminology. Virtual Machine, for example, has two meanings: 1) A system virtual machine provides a complete system platform which supports the execution of a complete operating system (OS).[1] These usually emulate an existing architecture, and are built with the purpose of either providing a platform to run programs where the real hardware is not available for use (for example, executing on otherwise obsolete platforms), or of having multiple instances of virtual machines leading to more efficient use of computing resources, both in terms of energy consumption and cost effectiveness (known as hardware virtualization, the key to a cloud computing environment), or both. 2) A process virtual machine (also, language virtual machine) is designed to run a single program, which means that it supports a single process. Such virtual machines are usually closely suited to one or more programming languages and built with the purpose of providing program portability and flexibility (amongst other things). An essential characteristic of a virtual machine is that the software running inside is limited to the resources and abstractions provided by the virtual machine—it cannot break out of its virtual environment. The CLI is the second type of virtual machine and something like VirtualBox, VMware, and IBM mainframe VM's are the first kind. > Why byte code? Or, in what sense can each code be only one byte long? Again, it's not "byte code" it's "bytecode" which is defined here: https://en.wikipedia.org/wiki/Bytecode https://en.wikipedia.org/wiki/Bytecode "Bytecode, also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter"
    - graycat 11y ago
      Thanks. Okay, I know some about the details of IBM's VM and a little about VMware. I have wondered: The way VM has worked on IBM mainframe instruction set has been partly due to an accident of the design of that instruction set and, then, some extensions for VM. Really, that way, tough for the program running to know if it is running as a virtual machine or not. So, in particular, the program running on VM can be using privileged instructions and not know that it doesn't really have access to the real hardware. So I've wondered if the Intel x86 instruction set also has this accident and, thus, can run operating systems that use privileged instructions but not know they are running on a VM. Or maybe the ability to run on a VM was from some extensions to the Intel instruction set. Do you know? Does the Microsoft CLI/CLR software have some security features beyond just any native program in, say, Fortran or assembler running in an address space, process, or whatever Microsoft calls where a program runs? I'm beginning to get the prerequisites for reading the OP, that is, understanding what the long standard alternative to native code has been. Heck, I can understand native code -- at one time I entered some simple programs via the computer console sense switches. And I printed out the object listing from a Fortran compiler and went over the machine language instructions one by one. I discovered that even for some simple code and a good Fortran compiler, assembler could be faster by a factor of several. Just read the Wikipedia article. Nice and easy. Thanks.