123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109 |
- .In
- .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
|