Re: Native Code vs PCode
- From: "Ralph" <nt_consulting64@xxxxxxxxx>
- Date: Sun, 4 Sep 2005 11:40:00 -0500
"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:eBekFYVsFHA.2948@xxxxxxxxxxxxxxxxxxxxxxx
> Steady on Ralph! We're saying the same basic (<grin>) thing here, apart
from
> a disagreement over the term "interpret". I'm using the term in the
context
> of a virtual machine and its dispatching of soft instruction codes, which
is
> how this p-code is executed. This is obviously distinct from source-level
> interpretation, but I took that to be obvious.
>
> I personally wasn't trying to denigrate VB or it run-time environment. I
> have a large experience with proprietary soft instruction codes and their
> virtual machines. I mainly wanted to emphasise that there's no JIT or
other
> form of run-time translation of p-code to native code, and you've
confirmed
> you agree with that here.
>
> Tony Proctor
>
Yes, of course we would agree on how pcode is actually implemented.
I never meant to suggest otherwise, nor to target your post personally, only
that the terms "interpret" and "JIT" are often charged by experience with
other language platforms and that erroneous conclusions are often the
result.
This is in many cases a difficult media, because of the limitations in space
and the wordsmithing abilities of its general participants. (The latter is
especially applicable to me. <g>) When one aims at a short unity of effect,
one often comes across as shrill, combative, or worse - pedantically ill
tempered.
<g>
-ralph
> "Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
> news:OuidnZ2dnZ1UyULTnZ2dnfJChN6dnZ2dRVn-052dnZ0@xxxxxxxxxxxxxxx
> >
> > "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
> >
> >
>
>
.
- Follow-Ups:
- Re: Native Code vs PCode
- From: Tony Proctor
- 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: Tony Proctor
- Native Code vs PCode
- Prev by Date: Re: Detecting ComboBox change
- Next by Date: Re: Native Code vs PCode
- Previous by thread: Re: Native Code vs PCode
- Next by thread: Re: Native Code vs PCode
- Index(es):
Relevant Pages
|
