Re: How about in INC opcode

[boldt@xxxxxxxxxx]

Don wrote:
>OK, it's been a while since I've studied compiler construction theory
>here, but, since the interpretation process in effect parses and
>translates the the command into some machine runnable instrucion(s), I
>don't see the strength in the interpreted vs compiled line of thought
>here...What am I not seeing? (caveat: I'm still only on cup 2 of coffee
>this morning...:)
>
>I would submit that if you can interpret it, you can compile it; and via
>compilation you gain performance.

Some good questions!

You're probably thinking of 1980's vintage Basic that could be
compiled for a performance boost.

Here's one way of looking at the difference:  Compilers are
geared towards optimizing run-time performance, and so lots
of stuff is done during compile time to achieve that goal.
For example, storage locations are assigned for variables
and intermediate results.  However, as the functionality of
the language increases, the complexity of the storage
management increases as well.  Already in RPG, there are
situations where we have to assume worst case possibilities
in the allocation of temps and make them very big!

In an interpreted language, all memory is managed dynamically.
For example, if the split function yields an array of seven
items, it only needs to allocate a seven element array from
the interpreters storage pool.  The Perl interpreter uses a
reference counting mechanism, and so knows when that array is
no longer needed and automatically returns the array to the
pool.

Another difference is that compiled languages are typically
strongly typed, which can help the compiler generate optimal
code.  Interpreted languages, like Perl and Rexx are
"typeless" languages, in that the value of a variable
determines how it can be used, not the type.  For example,
consider the Perl statement $x=$y+1.  The statement really
only makes sense when $y contains a numeric value.  Basically,
the value is converted from string form to integer or float,
the addition is performed, and the number is converted back
to string form.  (At least Basic knew that a variable was
either a number or a string, and so a compiler could easily
generate optimal code!)

Also, in Perl and Rexx, you can construct statements on the
fly and run them dynamically.  This is powerful, but also
potentially dangerous - many web hacks take advantage of
this feature of Perl.  (Note that there is a "taint" option
that can detect potentially dangerous security holes.)

There are "compilers" for Perl and Rexx, but since
practically the entire run-time library has to be carried
around anyways, and you always have the possibility of
dynamically created statements, there really isn't much
point to compiling these languages.  And as I pointed out
before, Perl apps (at least when properly written) tend to
perform favorably to C++ anyways.  Furthermore, compiled
programs work only on the platform targetted by the compiler.
A normal plain-text Perl or Rexx program will run on any
platform (provided it has the interpreter installed).

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---