ack/doc/sparc/2

.so init
.nr H1 1
.NH
CLOSE-UP LOOK
.NH 2 
What is EM?
.PP
As the abstract of the IR-81 rapport on EM
.[ [
description of a machine architecture
.]]
says: \*(OQEM is a family
of intermediate languages designed for producing portable compilers.\*(CQ
Because EM is to be used on a wide range of languages and processors,
the instruction set is kept simple enough to allow easy translation to,
or interpretation on, almost any processor. Yet it is also powerful enough
to accommodate easy translation from almost any block-structured language.
.PP
Even though EM was designed in the early 1980s, it
is based on
.\" already shows strong signs of being influenced by
the (then innovative) RISC architecture. All instructions
have 0 or 1 operands, there are no fancy addressing modes as in the
68020's\*(Si move.w a3(_array,d3.w*2), -(sp)\*(So, no explicit registers,
although instructions for higher languages
such as array-operations, multiway branches (case) and
floating point operations are provided.
.PP
To fully understand the discussion in the following chapters,
the reader should at least have some knowledge of EM.
.NH 2
What is SPARC?
.PP
According to Sun's RISC tutorial: \*(OQSun Microsystems has designed a RISC
architecture, called SPARC, and has implemented that architecture with
the Sun-4 family of supercomputing workstations and servers. SPARC stands
for Scalable Processor ARChitecture, emphasizing its applicability to
large as well as small machines.\*(CQ
.PP
In sharp contrast to EM, SPARC does have
explicit registers (31 integer and 32 floating point, all of which
are 32 bits wide) and
does not support any high level language operations: it does not even have
multiplication or division instructions. Because the SPARC design is
very straightforward, all instructions could be hard-coded (no microcode
involved) to
provided extremely high performance. All register-to-register operations
require exactly one clock cycle, and all register-to-memory and
memory-to-register operations require two clock cycles, one to retrieve
the instruction and one to access external memory. At a clock speed of
over 20 MHz this means that you can achieve well over 10 VAX MIPS:
more than 4 times the speed of a 15 MHz 68020 used in the Sun3/50.
.PP
As above, the reader should also have some general knowledge about
the SPARC processer to be able to understand the following chapters.
.NH 2
What exactly is a (fast) backend?
.PP
To put in the simplest of ways: a (fast) backend is a set of routines to
translate EM code to code that will run 'on the metal' (for example the SPARC
processor). The distinction between full-fledged backends (code generators)
.[ [
The table driven code generator
.]]
and fast backends (code expanders)
.[ [
The Code Expander Generator
.]]
is related to
the compilation-time vs. run-time trade off. Code generators generate
efficient code and code expanders generate code very efficient.
For details about code expanders see also
.[ [
The design of very fast portable compilers
.]].
.PP
The reasons for us to implement a code expander are numerous: Our first reason to
implement a code expander, rather than a code generator was that implementing a
code expander would be hard enough already. Code generators only give
more problems and there were already enough problems to be solved. Secondly,
we knew we would never be able to compete with original SPARC compilers due
to loss of information in the frontends (see also chapter 5). By implementing
a code expander we might be able to outrun the existing compilers on a
completely different terrain: compile speed.
.PP
The third 'reason' to implement a code expander lies a little deeper and was
not discovered until we had actually started the implementation... It was only
then that we found out that for certain architectures, such as the SPARC,
the idea behind the code-expander is not necessarily inferior to that
behind a code-generator. It seems that for highly orthogonal instruction
sets it is possible to generate near optimal code without using the
code-expander. We have to say, however, that this is only true for our
optimized version of the code-expander. With the original code-expander
it would not have been possible to generate near-optimal code for the
SPARC processor.
.NH 2
So, what are the main differences between EM and SPARC?
.PP
The main
difference between EM and SPARC is the stack versus register orientation.
The other differences, such as the presence of high level language
operations in EM, can easily be overcome by subroutines,
or small pieces of in-line SPARC code.
The design-part of this project mostly concentrates on
building a bridge between EM's stack and SPARC's registers.
.PP
In the next chapter we will make a list of all our design problems which
will then be discussed in chapter 4.
.bp