Several Topics - Nov. 19, 2013

[glen herrmannsfeldt]

In comp.lang.fortran Rainer Weikusat <rweikusat at mobileactivedefense.com> wrote:
> glen herrmannsfeldt <gah at ugcs.caltech.edu> writes:
>> In comp.lang.fortran E.D.G. <edgrsprj at ix.netcom.com> wrote:
>>>>> "E.D.G." <edgrsprj at ix.netcom.com> wrote in message 
>>>>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at earthlink.com...
>>> Posted by E.D.G. on November 19, 2013
  
>>> 1.  PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN
  
 (snip)

>>>       This program translation project has become one of the most 
>>> surprisingly successful programming projects I have worked on to date.  A 
>>> considerable amount of valuable information has been sent to me by E-mail in 
>>> addition to all of the information posted to the Newsgroups.

(snip, I wrote)

>> In general, language processors can be divided into two categories
>> called compilers and interpreters.  Compilers generate instructions for
>> the target processors. Interpreters generate (usually) an intermediate
>> representation which is then interpreted by a program to perform the
>> desired operations. That latter tends to be much slower, but more
>> portable.

>> There are a few langauges that allow dynamic generation of code, which
>> often makes compilation impossible, and those languages tend to be
>> called 'interpreted langauges'.
 
> These two paragraphs use the same terms in conflicting ways and the
> assertions in the second paragraph are wrong: Lisp is presumably the
> oldest language which allows 'dynamic code creation' and implementations
> exist which not only have a compiler but actually don't have an
> interpreter, cf
 
> http://www.sbcl.org/manual/index.html#Compiler_002donly-Implementation
 
> The main difference between a compiler and an interpreter is that the
> compiler performs lexical and semantical analysis of 'the source code'
> once and then transforms it into some kind of different 'directly
> executable representation' while an interpreter would analyze some part
> of the source code, execute it, analyze the next, execute that, and so
> forth, possibly performing lexical and semantical analysis steps many
> times for the same bit of 'source code'.

OK, but many intepreters at least do a syntax check on the whole file,
and many also convert the statements to a more convenient internal
representation.

For an example of something that can't be compiled, consider TeX which
allows the category code of characters to be changed dynamically.

I once wrote self-modifying code for Mathematica, where the running code
(on what Mathematica calls the back end) asked the front end (which does
editing of input data) to change the code. 
 
> Some compilers produce 'machine code' which can be executed directly by
> 'a CPU', others generate 'machine code' for some kind of virtual machine
> which is itself implemented as a program. The distinction isn't really
> clear-cut because some CPUs are designed to run 'machine code'
> originally targetted at a virtual machine, eg, what used to be ARM
> Jazelle for executing JVM byte code directly on an ARM CPU, some virtual
> machines are supposed to execute 'machine code' which used to run
> 'directly on a CPU' in former times, eg, used for backwards
> compatibility on Bull Novascale computers.

Yes. There are also systems that do simple processing on each statement,
with no interstatement memory. Converting numerical constants to
internal form, encoding keywords to a single byte, and such. 

It is interesting to see the program listing look different than the way
it was entered, such as constants coming out as 1e6 when you entered
it as 1000000.  The HP2000 BASIC system is the one I still remember.

The popular microcomputer BASIC systems, mostly from Microsoft, allowed
things like:

IF I=1 THEN FOR J=1 TO 10
PRINT J
IF I=1 THEN NEXT J

If you left out the IF on the last line, it would fail when it reached
the NEXT J statement if the FOR hadn't been executed. Compare to C:

if(i==1) for(j=1;j<=10;j++) {
   printf("%d\n",j);
}

A compiler would match up the FOR and NEXT at compile time. Many 
interpreters do it at run time, depending on the current state.

I also used to use a BASIC system that allowed you to stop a program
(or the program stopped itself), change statements (fix bugs) and
continue on from where it stopped. Not all can do that, but pretty
much compilers never do.
 
> Prior to execution, Perl source code is compiled to 'machine code' for a
> (stack-based) virtual machine. Both the compiler and the VM are provided
> by the perl program. There were some attempts to create a standalone
> Perl compiler in the past but these never gained much traction.

And, importantly, the code runs fairly slow. Some years ago, I was
working with simple PERL programs that could process data at 1 megabyte
per minute. Rewriting in C, I got one megabyte per second. It is not too
unusual to run 10 times slower, but 60 was rediculous.

-- glen