cik@l.cc.purdue.edu (Herman Rubin) (05/24/89)
In article <7040@cg-atla.UUCP>, morrison@cg-atla.UUCP (Steve Morrison) writes: ...................... > One motto was stressed over and over again in a course I took on > Software Enginerring back in the seventies: "The goal of Software > Engineering isn't to make good programmers better, it's to make > average programmers as productive as the best." This is utter nonsense. It makes just as much sense to try to make an average baseball player a Babe Ruth, an average soccer player a Pele, or an average physics student an Einstein. This can only be done by disabling the talents of the good. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
tainter@ihlpb.ATT.COM (Tainter) (05/25/89)
In article <1316@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >In article <7040@cg-atla.UUCP>, morrison@cg-atla.UUCP (Steve Morrison) writes: >> Software Enginerring back in the seventies: "The goal of Software >> Engineering isn't to make good programmers better, it's to make >> average programmers as productive as the best." >This is utter nonsense. It makes just as much sense to try to make >an average baseball player a Babe Ruth, an average soccer player a Pele, >or an average physics student an Einstein. ^^^^^^^^^^^^^ shouldn't be student, ya know Actually, there is a subtle modifier missing from the original statement: "The goal of Software Engineering isn't to make good programmers better, it's to make average programmers as productive as the best ARE CURRENTLY." ^^^^^^^^^^^^^ The assumption is that the best will continue to get better, regardless. The average >Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 --johnathan.a.tainter--
callen@inmet (06/01/89)
The AMD 29000 has two categories of registers, "local" and "global." The local registers are used as a "stack cache" (another name for a register window, if you ask me); the global registers can either be made available to the application OR protected and used in, say, interrupt routines. -- Jerry Callen ...!uunet!inmet!callen callen@inmet.inmet.com
aglew@mcdurb.Urbana.Gould.COM (06/02/89)
>The cut line for scratch registers is directly proportional to the memory >latency. The longer your latency the more registers, and concurrently >handled computation, you need to mask it. > > >brooks@maddog.llnl.gov, brooks@maddog.uucp I should probably learn to shut up before I have published my research, but... scratch registers do not necessarily have to appear as register numbers in the instruction set.
aglew@mcdurb.Urbana.Gould.COM (06/02/89)
>From time to time, I have seen the argument that large register files slow >down context switches. Yes and no. If you are looking at general purpose >operating systems like Unix, register saves are a very small part of the >cost of a context switch. Last week I saw an ad for a real time version >of Unix with a guaranteed response time (switch to kernel to high priority >process) of 5 milliseconds. Now, for the sizes of register files we are >talking about, a register save is about 1/1000th to 1/100th of the total time. > > Hugh LaMaster, m/s 233-9, UUCP ames!lamaster I worked on a RT UNIX where I *measured* context switch times of 250 microsecs. These were typical minimums, but not guaranteed. On this process memory accesses were at least 600 ns, so saving 16 registers was at least 3%. Not to mention that the first register save was nearly always a TLB miss.