Re: Native Code vs PCode

----- 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 ...




.

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: Control Flow Stack deficiencies
    ... native code (not p-code) would consider the use of code generation ... I did not say that it's bizarre that the authors of a Pascal compiler ... There's nothing about failing *ever* to use a jump table that's ...
    (comp.lang.forth)
  • Re: Native Code vs PCode
    ... > Subject: Re: Native Code vs PCode ... There is no JIT compiler ... There is no more 'interpretation' than what goes on when a call to a method ...
    (microsoft.public.vb.general.discussion)
  • Re: Native Code vs PCode
    ... > a disagreement over the term "interpret". ... > how this p-code is executed. ... > form of run-time translation of p-code to native code, ... There is no JIT compiler ...
    (microsoft.public.vb.general.discussion)
  • 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. ... but it is a very different advanced technology. ...
    (microsoft.public.vb.general.discussion)
Loading