Re: Native Code vs PCode
- From: "Ralph" <nt_consulting64@xxxxxxxxx>
- Date: Sat, 3 Sep 2005 18:02:30 -0500
"sali" <gabor.salai@xxxxxxxxxx> wrote in message
news:O70V7%23MsFHA.912@xxxxxxxxxxxxxxxxxxxxxxx
> ----- Original Message -----
> From: "Ralph" <nt_consulting64@xxxxxxxxx>
> Newsgroups: microsoft.public.vb.general.discussion
> Sent: Saturday, September 03, 2005 6:37 PM
> Subject: Re: Native Code vs PCode
>
>
> >
> > "Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> message
> > news:%23zGUkI7rFHA.1252@xxxxxxxxxxxxxxxxxxxxxxx
> > > I guess you haven't seen any of the previous threads on this subject,
> e.g.
> > >
> >
>
http://groups.google.ie/group/microsoft.public.vb.general.discussion/browse_
> frm/thread/0d579a81dc11e19c/117fe49d249e3c8a?hl=en#117fe49d249e3c8a
> > >
> > > The point being that P-code is interpreted rather than being converted
> to
> > > native code via a JIT compiler
> > >
> > > Tony Proctor
> > >
> > <snipped>
> >
> > I was going to let this go, for as a 'high-level' view it is mildly
> useful.
> > However, much of the mythology and confusion concerning VB PCode comes
> from
> > taking the above view and then attempting to extrapolate performance and
> > implementation issues from it.
> >
> > First off, VB's version of P-Code is MS's own highly optimized
proprietary
> > implementation of "pseudo code". While it has roots in BASIC's
> historically
> > interpreted environment and Dr. Wirth's original concept, it is a unique
> > product. Any similarity to Java and .Net, or to archaic 'interpreted'
> > languages (early BASICs included) is purely superficial and attempts at
> > homomorphism will lead to erroneous conclusions.
> >
> > Second, when a VB6 application is compiled to P-Code the result is a PE
> COFF
> > executable file. It makes 'service' calls to the VBRuntime Dll the same
as
> > native compiled code. Albeit, often not the same calls and with somewhat
> > strange setups before and after if you are used to VC, but "native"
calls
> > none the less. There is no special invocation of a separate VB Runtime
> > process - no separate 'engine' running in the back room. The runtime
> doesn't
> > magically create any new assembly either - it just runs code with the
> > supplied data (parameters, stack, memory) like any other library
> procedure.
> > In effect the 'interpretation' or 'translation' has already been done at
> > compile time - there is no intermediate process going on, no
'conversion'
> to
> > machine code - it is machine code.
> >
> > P-Code is not 'interpreted' at runtime. There is no JIT compiler
involved.
> P
> > eriod.
> >
>
> is p-code placed into "code" or "data" segment of process?
>
> if it is in "data" then p-code is "interpreted" on one way or another ...
>
Pull out your favorite PE COFF viewer and take a look.
There is no more 'interpretation' than what goes on when a call to a method
in GUI.DLL is 'interpreted' to present a specific window or control. I
suppose you could look at things that way. But it seems a bit
transcendental.
-ralph
.
- Follow-Ups:
- Re: Native Code vs PCode
- From: sali
- Re: Native Code vs PCode
- From: sali
- Re: Native Code vs PCode
- References:
- Native Code vs PCode
- From: Ivan Debono
- Re: Native Code vs PCode
- From: Tom Esh
- Re: Native Code vs PCode
- From: M. Posseth
- Re: Native Code vs PCode
- From: Tony Proctor
- Re: Native Code vs PCode
- From: Ralph
- Re: Native Code vs PCode
- From: sali
- Native Code vs PCode
- Prev by Date: Re: Where Do I Find the WebBrowser Control?
- Next by Date: Re: What is 'managed code'?
- Previous by thread: Re: Native Code vs PCode
- Next by thread: Re: Native Code vs PCode
- Index(es):
Relevant Pages
|