Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: Problems with EGCS 1.1 vs GCC 2.7.2.3 | Date | Sat, 2 Jan 1999 22:36:43 +0100 (MET) |
| |
"A month of sundays ago Michael Meissner wrote:" > > it would be much faster if they would do things regularly and > > predictably so that I could just map whole stack regios across. When > > And such calling sequences are much slower, so you are penalizing maybe 90% or > 99% of the code to get relief in one area. Deal with it (I'm not unsympathetic > to your pleas, I just don't think the world is going to slow down to accomidate > special cases).
In my (hastily formed) opinion, it would be more sensible to push the optimization one level lower down, so that compiler writers didn't have to worry about it and application programmers could stop puzzling about "volatile" and "register" (and I could use indirection to pass varargs :-). The top (bottom?) of the stack should be prefetched by the microcode into the L1 cache on execution of the preceding jsr or return or whatever, and end of worry. Maybe even start preloading one register on spec? I know we are going to need the args and the processor logic should predict it too. Does it? In that case the latency is lower than your explanation would suggest.
Technicalities aside, the entire risc experience suggested that doing things simply and fast was better than optimizing a dozen "common cases". I understand that we don't have any say in a lot of this because the ABI is there, but there are usually some options available to both compiler writer and applications programmer. And in the case of linux, we have even more control than usual. I only ask you to bear these sorts of considerations in mind the next time you _have_ a choice. I'm actually sure you do - you most of all people must know how complicatedly awful some of the schemes are, and how much good they did in the longer run.
Whew .. now to get back to work. Gotta check out if I broke solaris or irix with the c++ port.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |