.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