On 14 October 2016 at 02:30, Timothy Sipples <sipp...@sg.ibm.com> wrote:
> No, not optimistic. Mere fact. Sun Microsystems made Java 1.0 generally
> available for download on January 23, 1996, for the Windows 95, Windows NT,
> and Solaris operating systems (three different operating systems across two
> different processor architectures). That was over two decades ago.
We're not debating the existence of Java in 1996. What you said that I
disagree with is this:
>For perspective, for over two decades (!) Java has
> compiled/compiles bytecode *every time* a Java class is first instantiated.
> The resulting native code is model optimized depending on the JVM release
> level's maximum model optimization capabilities or the actual machine
> model, whichever is lower.
This just isn't correct. The Java made available by Sun in 1996 was a
pure interpreter. They wrote C code to implement a JVM, and the
related (and in fact much larger) baggage of class loaders and such.
This C code could be compiled for just about any architecture, but it
did no converting of JVM bytecodes into native instructions. It was a
lot like the many interpreters that existed for decades before, such
as UCSD Pascal's P-code, and a number of offerings from IBM and many
others ( APL, CPS-BASIC and CPS-PL/I), TSO classic CLISTs, Rexx, and
more. In pass 1 source code is converted into some kind of internal
representation, and in pass 2 that representation is then interpreted
by native code. What the intermediate form looks like with respect to
the source language differs. Either it's a lot like the source,
cleaned up for easier machine processing (CLIST, Rexx, most BASICs),
or it's more of an easy-to-interpret virtual machine (UCSD, JVM), but
by definition it's not the native instruction set of the eventual
target machine. Sun's JVM, as documented in the 1996 book, did define
some pseudo-ops for performance reasons, but they were entirely
optional and in no way can be called compiling (JIT or otherwise).
Back in 1996, while I'm sure there were bright people thinking about
JIT compilation of JVM bytecodes into existing instruction sets, the
more general musing (in the Sun JVM book, even) was about building
hardware to directly execute -- rather than interpret -- JVM
bytecodes. That didn't happen in any commercial way to my knowledge.
> Java isn't the earliest example of a bytecode-to-native technology. IBM's
> Technology Independent Machine Interface (TIMI) proved the concept much
> earlier. TIMI traces its roots to the IBM System/38 introduced in August,
I'd say its roots go much further back to the failed Future System
(FS), that Lynne Wheeler has mentioned here many times.
> The latest TIMI technologies are found in the IBM i platform, another
> platform deservedly famous as a stable, reliable home for applications.
> Before program execution (just before, if necessary) TIMI automatically
> translates the bytecode to native code tailored for that particular
> hardware model environment, persists it, and runs it.
You're describing the Original Programming Model (OPM), which has
largely been deprecated in recent years in favour of compiling
directly into native (p-series) instructions, probably via some quite
different intermediate representation.
> TIMI is arguably even closer to ABO conceptually than Java is.
Sure. It wouldn't surprise me at all to find that the intermediate
representation used by ABO is the very same one used on the IBM i.
Certainly ABO and the IBM i compilers all come from the same lab.
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN