Re: P-Code and virtual machines

>>[Stack machines seem inappropriate for C.]


In article 94-04-027 lrau@migration.com writes:
>[Isn't the AT&T Hobbit a stack machine?
> Experiments showed C programs relied on function calls...]


The Hobbit is based on the earlier CRISP


%A David R. Ditzel
%A Hubert R. McLellan
%T Branch Folding in the CRISP Microprocessor: Reducing Branch Delay
to Zero
%J Proceedings of the 14th Annual International Symposium on Computer
Architecture; Computer Architecture News
%V 15
%N 2
%D June 1987
%P 2-9


%A David R. Ditzel
%A Hubert R. McLellan
%A Alan D. Berenbaum
%T The Hardware Architecture of the CRISP Microprocessor
%J Proceedings of the 14th Annual International Symposium on Computer
Architecture; Computer Architecture News
%V 15
%N 2
%D June 1987
%P 309-319


The CRISP, and, presumably the Hobbit, dynamically compiles (for a very
simple interpretation of the word `compiles') machine code into microcode
that is optimized and cached (tagged by pc and sp) in a microcode cache.
The machine language supports sp-relative operand addressing that is
turned in to microcode that references a register file or, if necessary,
which performs loads and stores. (The register file size can vary from
implementation to implementation, the machine code to microcode compiler
takes care of the details.)


Early experiments showed C programs make heavy use of function calls,
hence the CRISP register windows and the SPARC register windows.


%Q Sun Microsystems
%T The SPARC Architecture Manual Version 8
%R Sun Microsystems Part Number 800-1399-12
%D January 1991


Note, though, that compiler optimizations can drastically change the
makeup of procedure calls, and thus the relative wins of various hardware
schemes.


This also points out a problematic loop in every design cycle in a field
of moving technologies, in particular for computers: the systems we design
for tomorrow generally push the envelope in only one area. Thus,
compilers do better optimizations around today's architectures, but may
perform poorly on tomorrow's architectures. Hardware may do a better job
of running today's workload but not of running tomorrow's workload. There
isn't really any way around this problem since changing many things at
once takes more work and thus also takes longer than making incremental
changes. But it's a trend that's good to keep in mind, both in design
(how much do I optimize around branch delay slots, when tomorrow's
machines may not have them?) and in criticizing yesterday's designs (why
did they do *that*!?).


;-D on ( Building the perfect beast ) Pardo
--

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