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.

Third, one has to be careful when reading older articles concerning VB's
p-code implementation. It has evolved dramatically over the years. What you
see with VB5/6 is a far better product than what we had with VB1/4. Another
complication is P-Code is undocumented. There were tech papers available for
earlier versions, but since then MS really tighten down the hatches. Much of
what you will read is really just a 'best guess'.

Often MS's p-code is sneered at based on the delusion that it is
'interpreted', but it is a very different advanced technology. So much so
that you will find earlier developers hoping that MS would expand the
technology to other languages and environments. That was when Java-type
common-code, run everywhere, language/environments were coming in vogue. In
many ways MS had a step on the competition with this kind of technology.
There are reasons MS's implementation of Java ran circles around Sun's.

You will also find that when the hype and calls for a native compiler were
the loudest, there were several articles by VB gurus suggesting that one
should be - "careful for what you wish for". <g>

P-Code runs faster than native code (with the exceptions others have noted).
It compiles into a smaller executable. It is often more robust and presents
fewer surprises - if it runs in the IDE, it will run in the wild. For many
reasons it should be the average VBers first choice when making an
executable.

hth
-ralph


.

Relevant Pages

  • Re: Native Code vs PCode
    ... of a virtual machine and its dispatching of soft instruction codes, ... how this p-code is executed. ... interpretation, but I took that to be obvious. ... There is no JIT compiler involved. ...
    (microsoft.public.vb.general.discussion)
  • Re: OT:aside to Bob - learning Pascal?
    ... the DG used 'P-Code' but then it was 'Pseudo' ... If not the actual technology - then the term. ... It is possible that the 'native code' compiler in VB is not very ...
    (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: Native Code vs PCode
    ... >> 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 ... > code but there is p-code runtime engine instead. ...
    (microsoft.public.vb.general.discussion)
  • Re: Native Code vs PCode
    ... > 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 ... code but there is p-code runtime engine instead. ...
    (microsoft.public.vb.general.discussion)