Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: net.arch Subject: Re: Orphaned Response Message-ID: <5100075@ccvaxa> Date: Tue, 13-May-86 19:42:00 EDT Article-I.D.: ccvaxa.5100075 Posted: Tue May 13 19:42:00 1986 Date-Received: Sun, 25-May-86 14:23:26 EDT References: <5100066@ccvaxa> Lines: 38 Nf-ID: #R:ccvaxa:5100066:ccvaxa:5100075:000:1550 Nf-From: ccvaxa.UUCP!aglew May 13 18:42:00 1986 >/* Written 7:08 pm Apr 29, 1986 by mac%uvacs@uvacs.UUCP in net.arch */ >> .... Losing indexing for array accesses isn't too bad, since >> just about every expensive array operation can be written using >> pointers instead of indexes (post-increment doesn't require a >> carry to perform a memory address). > >No semi-random access by subscripts? Your machine is to be >programmed exclusively in C or assembler, never Fortran. The Fortran codes to worry about are the matrix processing codes, like the Livermore loops. A hell of a lot of money has been spent figuring out how to vectorize, and use other optimizations, for these - you can almost buy them off the shelf. > >> So what can you do? Adding an index register in slows down the rest of your >> instruction set, > >Even when you don't index? Yep. (1) a short pipeline machine - pipeline stage has to be the size of an addition. (2) add extra pipeline stages to absorb the addition - since there is nearly always a chain from the front to the back of the pipe, you've slowed it down again. >> .... and, if memory is cheap, you might be willing to pad out a >> lot more of your structures, to get a speed increase. > >or use a separate add instruction. Slow. That's the point - if you aren't worried about speed you can use the ADD, and get all the flexibility you want. If you are worried about speed, then you could use the OR. Now, if a separate register-to-register OR instruction were faster than a register-to-register ADD... too bad asynchronous systems are out of fashion.