Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!anise.acc.com!news From: lars@salt.acc.com (Lars J Poulsen) Newsgroups: comp.arch Subject: Re: Register usage Message-ID: <1RcY6x#64Zq3Y=news@anise.acc.com> Date: 30 May 89 20:49:07 GMT References: <259@mindlink.uucp> <25382@ames.arc.nasa.gov> Sender: news@anise.acc.com (news administrator) Organization: Advanced Computer Communications, Santa Barbara, California Lines: 33 In article <25382@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >>I agree that 256 registers were probably too many, because the compiler had >>trouble using more than about 60 typically. In article mcg@mipon2.UUCP (Steven McGeady) writes: >This, IMHO, is one of the greatest flaws of the 29k - it exposes 192 >(actually 256) architectural registers. > >The 960, on the other hand, exposes 32 general registers architecturally, From a humble applications programmer, who occasionally has written a bit of kernel code: The biggest pain with an architecture that exposes too large a register file is saving and restoring on context switches. While interrupt service routines can ignore this and store only what they need, context switches require storing of the entire register set. Or do people really feel that the processors today are fast enough that scheduling pre-emption is too rare to influence the selection of register file size ? Many years ago I switched from working on (then) Univac-1100 to PDP-11's and VAXen; the 1100 had about 44 visible registers in the user set; few programs really used more than half of them; worse yet, they were asymmetric, with different properties between the three major groups. The VAX instruction set got more mileage out of its 16 general registers than the Univac got out of its 44, and saved many cycles on register save/restores. / Lars Poulsen (800) 222-7308 or (805) 963-9431 ext 358 ACC Customer Service Affiliation stated for identification only My employer probably would not agree if he knew what I said !!