Re: Java virtual machine as target language for C/C++

wws@renaissance.cray.com (Walter Spector)
25 May 1996 23:58:58 -0400

          From comp.compilers

Related articles
[17 earlier articles]
Re: Java virtual machine as target language for C/C++ dmoisan@shore.net (1996-05-14)
Re: Java virtual machine as target language for C/C++ rfg@monkeys.com (1996-05-19)
Re: Java virtual machine as target language for C/C++ moresys@world.std.com (1996-05-19)
Re: Java virtual machine as target language for C/C++ pardo@cs.washington.edu (1996-05-19)
Re: Java virtual machine as target language for C/C++ robison@kai.com (Arch Robison) (1996-05-21)
Re: Java virtual machine as target language for C/C++ pardo@cs.washington.edu (1996-05-24)
Re: Java virtual machine as target language for C/C++ wws@renaissance.cray.com (1996-05-25)
Re: Java virtual machine as target language for C/C++ tmb@best.com (1996-05-26)
Re: Java virtual machine as target language for C/C++ dw3u+@andrew.cmu.edu (Daniel C. Wang) (1996-05-27)
Re: Java virtual machine as target language for C/C++ dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-06-08)
Re: Java virtual machine as target language for C/C++ d.love@daresbury.ac.uk (Dave Love) (1996-06-13)
Re: Java virtual machine as target language for C/C++ bos@serpentine.com (1996-06-14)
Re: Java virtual machine as target language for C/C++ cdg@nullstone.com (1996-06-21)
| List of all articles for this month |
From: wws@renaissance.cray.com (Walter Spector)
Newsgroups: comp.compilers
Date: 25 May 1996 23:58:58 -0400
Organization: Cray Research, Inc.
References: 96-05-036 96-05-081
Keywords: architecture

khays@sequent.com (Kirk Hays) wrote:
>Remember, there is no problem in CS that can't be solved by another
>level of indirection.


dmoisan@shore.net wrote:
>True enough. Pascal for the CDC 170 did this too; the 170 has NO
>stack and no native recursion (fine for Fortran, bad for Pascal). I
>suspected that Pascal implementation (I can't remember whose it was,
>but I don't think it was CDC's) built a jump stack.


The run-time environment did not normally keep a run-time stack around,
as it wasn't required for Fortran or COBOL. Pity, as it would have saved
a lot of people a lot of work...


However ALGOL, PASCAL, LISP, and others all implemented dynamic memory
management. For an amusing anecdote, see Hennesy and Patterson's book
on Computer Architecture (1st edition). There is a chart on ALGOL
performance vs. Burroughs - a machine designed to run ALGOL. The 6600
creamed the Burroughs machine. Changed Patterson's whole outlook on
computer architecture.


>If I remember my COMPASS (CDC assembly), there wasn't indirect
>addressing so that programs that needed it actually built a jump
>instruction with the desired address and branched to that instruction.


You may be thinking of how the return jump instruction worked. It was
also possible to branch to a B register. In Fortran, for certain
known intrinsic functions, they avoided the normal RJ instruction
and simply stored the next instruction parcel address in a B register
and jumped. To return, they branched to the B register. FAST and
no memory access required.


And of course indirect addressing was easy for data. Stuff anything
you want in the appropriate A register.


>The 170 was an old archaic processor (no stack, but floating point!)
>but I loved it! (Within its limits, the orthogonality was quite good
>and code generation was relatively easy.)


It should be - it's roots lie in the famed CDC 6600 - the first
RISC machine. Seymour Cray knew what he was doing.


>Background: I'd used the Cyber in college and wrote a Pascal
>compiler--unheard-of for undergrads there--for my senior project. I'd
>planned on using the scheme I mentioned but I only got 70% finished by
>the end of the term. :(


Impressive!


Wirth's original PASCAL compiler was implemented on one of these machines.


Walt
--
Walt Spector
(wws@renaissance.cray.com)
Sunnyvale, California
_._ _._ _.... _. ._.


--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.