109 lines
4.7 KiB
Text
109 lines
4.7 KiB
Text
.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 well over 10 VAX MIPS can be achieved:
|
|
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
|