Re: String to int conversion

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Old Pedant" <OldPedant@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:96D64B35-E13A-47DF-86C1-BCF2A81E46B1@xxxxxxxxxxxxxxxx

"Al Dunbar" wrote:

Since vbscript is an interpreter rather than a compiler,

Sorry, Mr. Dunbar, but you are quite wrong.

It is clear from what follows that you have more specific knowledge of the
innards, so to speak, so I will defer to you on most points...

VBScript code *IS* compiled--into a byte code with tokens just such as I
showed.

Please trust me on this. I worked at ChiliSoft (which was then bought by
Sun) and we licensed version 3 of both VBScript and JScript from
Microsoft.
Yes, the C++ source code. We ported it from Windows to Unix and Linux and
even the IBM Mainframe (yes, I did that one...even to handling EBCDIC
characters and the IBM Mainframe's non-ANSI floating point arithmetic).

As inefficient as VBS is, it would be an order of magnitude or more slower
if it were a "true interpreter." Heck, even Microsoft's QBASIC (of 1990's
vintage) wasn't a "true interprete."

OK, well here there may be semantic dragons...

in my philosophy, Horatio, a compiler takes source code and produces an
executable file. In other words, compile once, run many times - on many
different days - possibly on different computers. The executable file (in my
world according to my definitions) is either actual machine code or
something very close to it. *VERY* close. Close enough, in fact, to be
executable by the O/S without need of any components not included as part of
the O/S. Early on this meant that I/O functions were generally taken care of
by calls to I/O routines integral to the O/S.

By contrast, an interpreter produces its results by some other means. Hey, I
once wrote a rudimentary (*very* rudimentary and very task-specific and
limited) interpreter in a combination of Fortran IV and Data General
Assembler, but I digress...

If compiled, VBScript is obviously not compiled in the sense that I use the
word. Now, if it *was* converted in chunks into actual machine code to be
held in memory to be executed by the processor, then I would readily (if
grudgingly) admit this was a compilation process.

But your (very interesting) description of the process still sounds to my
naive ears more like interpretation than compilation - again, based on my
meaning of the terms. To me, the intermediate string of byte codes and
tokens is not so much a compilation (as into machine code) as some kind of
analysis of the source code that itself will ultimately be "interpreted" yet
again by the loop that processes the byte codes into a sequence of actions
that it carries out using its own code.

So it is the byte code, generated by the compliation process, that is then
interpreted.

HA! at least I got half of the equation right - there is a certain level of
interpretation involved...

No different, in principle, than how Java ".class" files can be
executed by a byte code interpreter if you don't have a "JIT" (Just In
Time)
compiler available. (And, in fact, early Java implementations *did*
interpret the byte code when in debug mode. Yes, I worked on one of
those,
too.) No different than the way that .NET's CLR (Common Language Runtime)
byte code could be interpreted (though I don't know of any such
interpreter).

Again, we are obviously hoist by our own semantic petards here - yours
appear to be somewhat more updated than mine. ;-)

<snip>

For one thing, X
is a variant, a variable type unknown to the underlying machine. For
another, programs that actually consist of machine code, whether
hand-coded,
assembled, or compiled, exist in a context that only exists when the
entire
program is there. Think of loops and branches: if the machine code you
want
to jump to no longer exists because each statement is "compiled",
executed,
then thrown away, where should it be branching to?

Again, you are dead wrong. A VBS "file" is compile *as a unit* into a
pseudo-file of byte code.

Again, if that byte code file were saved as a separate file, I might have
allowed my arm to be twisted into agreeing this was a compiler. Even the
rudimentary interpreter I mentioned developing in Fortran and etc actually
produced an intermediate file that was then interpreted by another program.
Because it was so much closer to the source than to a machine-code
equivalent, I still considered it an interpreter.

So *all* the byte code is there. And a jump to is
jumping to a known point within that byte code pseudo-file.

Granted. Because I have insufficient knowledge of the internals to launch a
credible disagreement. But, yes, I do see the point.

<snip>

The gist of my reply is that you are possibly underestimating the number
of
actual machine-level instructions that will be executed (in whatever
manner)
in order to execute however many lines exist in the script.

Well, now, that might be true. Only because I was trying to err on the
conservative side. But I'd stake my software engineer's reputation that I
am
off by less than half an order of magnitude.

Seems a safe bet, somehow...

But that is a moot point with scripting. I believe that the only way
available to make one's code run faster is to ensure one's algorithms are
the best and most efficient, and to recognize the contribution of other
components that, in addition to adding functionality, also suck up
resources. This includes things like the o/s itself, other tasks and
processes running, intermediary COM objects such as FSO, etc. etc.

Or write using a truly compiled language, of course. But then the other
components won't be any faster. So whether you see a dramatic improvement
or
not depends on how much of your time is spent in your own code and how
much
in the components.

I am familiar enough with the concept of code optimization to understand
that, for example, one's best improvements generally come from improving the
code that uses the largest chunks of execution time. From past experiences
this was mainly the code in the innermost loops. IMHO, if one writes purely
computational code that is sluggish enough to actually require optimization,
that is when it is time to switch to a true compiled language - or at least
some other system most suitable to the problem space.

If a SQL query takes 3 minutes to execute and 100 milliseconds for
VBScript
to produce a report therefrom, reducing the VBS time to zero milliseconds
will have no measurable impact on the overall system.

Of course. By its very nature, vbscript is often used as the glue between
other components and processes, where its value is in producing a workable
and manageable result, not breaking land-speed records.

It is interesting to note that, with the exception of this thread and a
few
others over the years, there has been very little effort devoted to this
minutae, even from those that could, if they were of a mind, add some
technical info to the discussion.

You just haven't been visiting the same forums I have. <grin/>

Apparently not, but I will have a peek thanks to the links in your next
reply.

No, you are right. Most people don't care about the minutiae.

I used to be most interested in that stuff than I currently am. I'm not sure
whether that is coming from advancing years, increased maturity (hah!), the
recognition that there might be better uses of my time, or what have you.
But I do enjoy being drawn into the occasional related discussion. In fact,
that was the main appeal of my four MVP awards in scripting. That and the
fact that I always felt humbled by the detailed knowledge of other MVPs I
had the honour of meeting, whether virtually or in person.

Thanks for straightening me out on a few things. How stultifying it would be
to be right all the time!

/Al

Bill Wilkinson
ex-Chilisoft
ex-Sun
even ex-MS

p.s.: And version 5 of VBS shows measurable--though not
enormous--improvement over the version 3 I worked on.


.

Relevant Pages

  • Re: Build your own Forth for Microchip PIC (Episode 837)
    ... the unreasonablly small hardware stack size for my particular target. ... You are handcuffed in the sense that you would like to be able to download small amounts of code into ram and execute it. ... because once you do away with the inner interpreter, ... An optimizing compiler isn't a post-processor, it's an *alternative* to another kind of compiler. ...
    (comp.lang.forth)
  • Re: String to int conversion
    ... byte code could be interpreted (though I don't know of any such interpreter). ... be converted to the equivalent set of native machine code. ... In ASP, in fact, it is the byte code form of a compiled ASP page that is ... calls the compiler and then passes the byte-code buffer returned from the ...
    (microsoft.public.scripting.vbscript)
  • Re: Minimal Forth
    ... The command loop invokes the compiler, and when the compiler returns it executes whatever is in the command buffer. ... It may be possible to execute the same source code either directly by an interpreter or by compiling it and then executing the machine code produced. ...
    (comp.lang.forth)
  • Re: sml for newbies
    ... > compiler. ... may give the /impression/ that what you have is an interpreter. ... to machine code and the generated machine code is then executed. ...
    (comp.lang.ml)
  • Re: Macros etc Was: DISFAVORED
    ... interpreter is simple enough that you can write your own easily too. ... compiler version when you're interpreting you ignore it and keep going? ... execute during compilation. ... Text macros take too ...
    (comp.lang.forth)