12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182 |
- .In
- .nr H1 2
- .NH
- PROBLEMS
- .NH 2
- Maintain SPARC speed
- .PP
- If we want to generate SPARC code, we should try to generate efficient code
- as fast as possible. It would be quite embarrassing to find out that the
- same program would run faster on a Motorola 68020 than on a SPARC processor,
- when both operate at the same clock frequency.
- Looking at some code generated by Sun's C-compiler and optimizing assembler,
- we can spot a few remarkable characteristics of the generated SPARC code:
- .IP -
- There are almost no memory references
- .IP -
- Parameters to functions are passed through registers.
- .IP -
- Almost all delay slots\(dg
- .FS
- \(dg For details about delay slots see the SPARC Architecture Manual, chapter 4, pp. 42-48
- .FE
- are filled in by the assembler
- .LP
- If we want to generate efficient code, we should at least try to
- reduce the number of memory references and use registers wherever we can.
- Since EM is stack-oriented it references its stack for every operation so
- this will not be an easy task; a suitable solution will however be given in
- the next chapter.
- .NH 2
- Increase compilation speed
- .PP
- Because we will implement a code expander (fast backend) we should keep
- a close eye on efficiency; if we cannot beat regular compilers on producing
- efficient code we will try to beat them on fast code generation.
- The usual trick to achieve fast compilation is to pack the frontend,
- optimizer, code-generator and
- assembler all into a single large binary to reduce the overhead of
- reading and writing temporary files. Unfortunately, due to the
- SPARC instruction set, its relocation information is slightly bizarre
- and cannot be represented with the present primitives.
- This means that it will not be possible to generate the required output
- format directly from our backend.
- .PP
- There are three solutions here: generate assembler code, and let an
- existing assembler generate the required object (\fI.o\fR) files,
- create our own primitives than can handle the SPARC relocation format, or
- do not use any of the addressing modes that require the bizarre relocation.
- Because we have enough on our hands already we will
- let the existing assembler deal with generating object files.
- .NH 2
- Convert stack to register operations
- .PP
- As we wrote in the previous chapter, for RISC machines a code expander can
- produce almost as efficient code as a code generator. The fact that this is
- true for stack-oriented RISC processors is rather obvious. The problem we
- face, however, is that the SPARC processor is register, instead of
- stack oriented. In the next chapter we will give a suitable solution to
- convert most stack accesses to register accesses.
- .NH 2
- Miscellaneous
- .PP
- Besides performance and \fI.o\fR-compatibility there are some other
- peculiarities of the SPARC processor and Sun's C-compiler (henceforth
- simply called \fIcc\fR).
- .PP
- For some reason, the SPARC stack pointer requires alignment
- on 8 bytes, so it is impossible to push a 4-byte integer on the stack
- and then \*(Sisub 4, %sp\*(So\(dd.
- .FS
- \(dd For more information about SPARC assembler see the Sun-4 Assembly
- Language Reference Manual
- .FE
- This too will be discussed in the next chapter, where we will take a
- more in-depth look into this problem and also discuss a couple of
- possible solutions.
- .PP
- Another thing is that \fIcc\fR usually passes the first six parameters of a
- function-call through registers. To be \fI.o\fR-compatible we would have to
- pass the first six parameters of each function call through registers as well.
- Exactly why this is not feasible will also be discussed in the next chapter.
- .bp
|