Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin From: hrubin@pop.stat.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: RISC vs. CISC -- SPECmarks Message-ID: <11602@mentor.cc.purdue.edu> Date: 30 Apr 91 13:19:26 GMT References: <1991Apr22.044553.16805@mp.cs.niu.edu> <3423@charon.cwi.nl> Sender: news@mentor.cc.purdue.edu Lines: 25 In article <3423@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes: > In article <11412@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > > The CYBER 205/ETA 10 is a vector pipeline machine, with the most versatile > > vector architecture I know of. With slight modification, it would be able > > to handle in a single instruction vectors of arbitrary length, and one does > > not have to worry about alignment of vectors in vector registers. > And now consider what occurs on a page fault in the middle of an instruction! > A single vector instruction can create over 45 page faults. Still worse if > you only run out of the (16) associative registers used to cache page table > entries (half page faults?). Do you think that the hardware designers were not aware of these problems? Unless the user can manage page boundaries, page faults are likely to occur with any kind of vector instruction. It may be possible for the hardware to anticipate page faults and decrease the losses associated with them, and doing the same vector instructions in any other way will produce as many page faults. I agree that on vector register machines, one can often rearrange the code to reduce page faults. But the alignment problems are quite massive, and the bookkeeping is not inconsiderable, especially if there is a shortage of scalar registers. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)