Re: Native Code vs PCode




"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


.



Relevant Pages

  • Re: NatiVe Code or P Code question
    ... >> It's nice to have the native code option, but truth is I've seen very ... the P-code is sensitive to changes in the interpreter subsystem. ... been the result of an 'interpretation stage' of the 'runtime' of older ... Most differences between PCode and Native Code will be based on ...
    (microsoft.public.vb.general.discussion)
  • Re: Native Code vs PCode
    ... Subject: Re: Native Code vs PCode ... VB's version of P-Code is MS's own highly optimized proprietary ... > In effect the 'interpretation' or 'translation' has already been done at ... There is no JIT compiler involved. ...
    (microsoft.public.vb.general.discussion)
  • Re: VB6, VB2005, or Something Else?
    ... and the native code execs to be not much larger. ... to a pcode exec and to a native code exec. ... C compiler. ...
    (microsoft.public.vb.general.discussion)
  • Re: Why does activex control run 3x+ faster in vb5 than .net?
    ... it generates MSIL NOT native CPU code. ... of what you want to say - MSIL is NOT native code. ... I don't get where I went wrong with that interpretation. ... There is only a just in time COMPILER that compiles the ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Java on the Apple2 and C64
    ... The encoding of Java bytecodes is much looser, ... One would think compiler technology had advanced in 20 years and the advantage a Java compiler would have by running on *big iron* vs. a p-system based Pascal compiler should give the edge to Java. ... interpretation is only inefficient when used in a way ... Having to compile to a bytecode ruins the interactivity and some semantics and still leaves you having to interpret the output, ...
    (comp.sys.apple2)