|
|
|
| Authored by: Ian Al on Monday, May 21 2012 @ 04:04 AM EDT |
Everyone makes comparisons with other languages and different implementations.
I wanted to get folk to look at the reality of the language source code to
execution process.
No matter what the language, they all have to go through the same steps. I put
the line numbers in to represent the need for text checking and the stripping of
source code characters that are irrelevant to execution. I grouped the IF, THEN
and GOSUB to represent a conditional jump.
The whole thing was not an exercise in Basic source code writing, but to draw
out that the basis of all higher level language execution reduces to loading
values from memory into the processor, saving from the processor to memory and
arithmetic and conditional jumps within the processor. The memory addresses and
the processor can be virtual or native.
Whether 'compiled' or 'interpreted', the first step is to strip the line
numbers, superfluous characters and parse the text to check for syntax and
identify data and logical instructions.
The next step might be integrated into the run-time platform or may be split out
as part of the 'compilation'. It reduces the source code into a compacted
version. 'Compiled' Basic turns the logical instructions into tags and compacts
the data. I'm not sure if programmer-chosen labels are similarly compacted: I
suspect not, but it is a detail.
'Compiled' Java compacts the data and logical instructions, but leaves the
virtual processor instruction symbolic references, methods and other text-based
labels intact in the class file. The class files are loaded and executed in the
JVM. At the start of execution of the program, the run-time platform carries out
the final 'compilation' stage which is the resolution of all remaining labels
into numeric values including all the processor logical instructions.
The interpreted Basic platform does the whole job of syntax checking, line
number stripping, resolution of all text labels and conversion of processor
logical instructions at run time. However, the processor logical instructions
are not the natural machine code. They are virtual instructions constructed from
natural machine code blocks and accessed by lookup or index tables. In fact, the
'executable' is a mixture of machine codes for logical math and numeric values
for data and also for representation of APIs into the operating system for I/O.
The Basic tags are the equivalent of the machine code instructions in the
platform.
The question is, is the interpreted Basic platform based on a virtual processor?
If it is, does the resolution of the virtual processor machine code instruction
text labels at run time constitute an infringement of '104?
The general 'source code to execution' issue applies to all higher level
languages. There are things that have to be done in order to execute every
higher level language. There are only two choices; do the machine code stuff on
a virtual processor or do the machine code stuff directly on the native
processor.
Comparision with object oriented languages, platforms that declare the use of a
virtual processor (often for its cross-platform capability), and platforms that
claim to be interpreted or compiled is irrelevant. How they describe the
platform is not the point. The point is how the platform is actually
implemented.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | Parent | # ]
|
| |
| Authored by: bprice on Monday, May 21 2012 @ 07:08 AM EDT |
If you really want to dig into this type of thing, I would suggest
browsing through some used book stores for a few old books on the UCSD P-System.
P-System predates Java by quite a bit, but implemented a Java-like "VM" which
offered "write once run anywhere" on a great variety of hardware. That's not to
say the two are identical, (they're not), but some of the basic principles are
the same.
And Pascal-P, the foundation of the UCSD P-system by
some years, makes the story even more pertinent..
Klaus Wirth's students at
the Swiss Federal Technical University (ETH) in Zürich developed Pascal P
as a portable Pascal system, primarily to aid in porting the language to new
machines. It was written on the CDC-6400, using Wirth's native CDC-6400
compiler, and distributed worldwide under a BSD-type license. The VM was
written in Pascal, and needed to be ported into whatever, but then Bob's your
uncle. To port further, as most of us did, you modified the Pascal-P compiler
to generate native code, then get off the VM and into the native
environment.
There was an announcement in Pascal News (thanks again, Andy
Mickel and Jim Miner), in 1973 or so.
I got my copy from ETH on magtape ($35
IIRC); Ken Bowles at UCSD probably got his the same way.
I ported Pascal to
B6700 and to B4700 by translating the ETH VM into B6700 Algol and into B4700
COBOL(!); Ken and his students also did a B6700 port and then went for micros
– I know not what language(s) they used for the micro VMs. IIRC, Arthur
Sale at University of Tasmania started with the ETH work to do their own B6700
native implementation.
The Burroughs B6700 and B4700 efforts finished the
development of native Pascal compilers for their respective architectures; the
UCSD efforts modified the bytecode (named P code) to allow for acceptable
performance on a micro. It's not clear to me when the other languages were
added to the architecture.
The bottom line: The UCSD P-System was a
write-once-run-anywhere enhanced derivative of a previous WORA
implementation. ---
--Bill. NAL: question the answers, especially mine. [ Reply to This | Parent | # ]
|
|
|
|
|
