On 09-May-2002, Goldfarb, Christopher <[EMAIL PROTECTED]> wrote:
> -----Original Message-----
> From: Fergus Henderson [mailto:[EMAIL PROTECTED]]
>
> > On 09-May-2002, Goldfarb, Christopher <[EMAIL PROTECTED]>
> wrote:
> >> I was describing the CLR process model and how it differs from the JVM,
> >> specifically in how the runtime JITs to a file for later retrieval
> instead
> >> of recompiling each time.
> >
> > What makes you think that?
>
> Let me clarify - I'm not talking about "recompiling" an app from syntax
> candy (C# for instance) to IL, but rather when the runtime du jour executes
> a given app for the first time. My understanding was that by default, the
> runtime JITs into durable format those sections of the IL that are being
> executed, on the fly. Next time around, those instructions are already
> compiled and available to be served up (assuming the IL date/timestamp
> hasn't changed).

Next time around some loop within the program, yes.
But if by "next time around" you meant the next time the program is executed,
then your understanding was wrong.

The generated native code is stored in memory during the execution of
the process, but when the process exits, it is discarded.

> >> Thinking on this later, I'm wondering if there are any instances where the
> >> runtime generates raw machine code and leaves the umbrella of OS calls.  I
> >> can't imagine this would be the case.  Can someone clarify for me?
> >
> > It's certain machine code that gets generated, but the generated code
> > contains only user-mode instructions, including calls to the OS API,
> > not privileged instructions such as port I/O.
>
> Doesn't this conflict with the response from "dotnetrotor":
>
> "Rotor on FreeBSD uses a platform adaption layer (PAL), which abstracts
> the API calls for easy porting. If you look in the source for Rotor
> you'll see that the JITter does generate native x86 code."

No, it doesn't conflict.

> Aren't native x86 bits considered priviledged instructions?

No, not from the point of view of the OS or the hardware.
I think you are confusing the different levels.

As far as the OS and the hardware are concerned, there are two kinds of
x86 instructions: the normal unprivileged instructions, such as "add",
"mul", "mov", etc., which can be used by any process, and special
privileged instructions, such as "inb", "outb", etc., which can only be
executed by the kernel and device drivers.  User-level processes which
want to do I/O will normally invoke the kernel via a system call, and
then the kernel will execute the necessary priveleged instructions on
behalf of the user-level process.

The CLR is another layer on top.  To the CLR, "raw instructions" are in
a sense priveleged.  But to the OS, they're not.

--
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Reply via email to