Xref: utzoo comp.arch:13898 comp.lang.c:25904 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!newstop!texsun!texbell!sugar!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.arch,comp.lang.c Subject: Re: RISC Machine Data Structure Word Alignment Problems? Keywords: risc sun Message-ID: <..Q11IDxds13@ficc.uu.net> Date: 14 Feb 90 04:42:47 GMT References: <111@melpar.UUCP> <1990Jan21.224826.1699@esegue.segue.boston.ma.us> <1925@l.cc.purdue.edu> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 15 In article <1925@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > This is another situation where the procedure is extremely slow in software. > If the appropriate hardware were provided, this would not be a problem. But > would the machine then be RISC? Who cares if it's RISC, CISC, VLIW, or a bunch of elves with abaci? If it's fast enough, fine. If it's not, unroll the loop to the LCD of the struct size and the data size. If that doesn't do it, recode in assembler. Then get a faster machine (where faster is defined in terms of the problem you have to solve: if the problem involves moving weird numbers of bits around all the byte ops in the world won't help you). Maybe a coprocessor would help (like having a disk controller to convert NRZ into MFM instead of doing it yourself). Most of the time this particular operation isn't a bottleneck, so who cares how fast it is? -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'