Path: utzoo!attcan!uunet!lll-winken!lll-tis!mordor!joyce!ames!vsi1!altnet!altos86!elxsi!beatnix!robert From: robert@beatnix.UUCP (Robert Olson) Newsgroups: comp.arch Subject: Re: Are all RISCs the same? Message-ID: <904@elxsi.UUCP> Date: 12 Sep 88 05:44:50 GMT References: <6930@aw.sei.cmu.edu> <28200198@urbsdc> Sender: news@elxsi.UUCP Reply-To: robert@beatnix.UUCP (Robert Olson) Organization: ELXSI Super Computers, San Jose Lines: 50 > However, in the middle range of the market, minicomputers and super-minis, >there are a lot of people who want *BOTH* real-time and conventional >performance. Some do not want it at the same time - eg. a computer site >that "officially" buys a computer to run a simulation that takes over all >the computers on site for maybe a few hours to a day per month -- but also >wants to use the computers that run this dedicated simulation for regular >engineering and office work during the rest of the time. > Others want RT and conventional capabilities at the same time, because >somebody has to develop on the machine, make reports, etc., and the company >doesn't want the hassle of handling two totally different development and >target systems. Different configurations, perhaps, but even that isn't >always acceptable. A large number of our customers fall into the above categories. >> ... stuff about cute tricks with SPARC register windows... > >This mode of using register windows is one of the most attractive to the RT >side of me. Note that the AMD29000 can do it this way too. Ie. you are basically >using the register windows as non-overlapping disjoint register files. > But then the conventional side of me takes over. Larger register files, >for windows or other, implies slower registers. Is it worthwhile? Probably not. >Disjoint register files at least imply the possibility of powering off some >sections of the file - although I suppose that it could be done for >register windows. The really big win will come if someone makes a register >file of N sets of M registers, that can turn off or disable or not require >address lines to the inactive N-1 sets, so that the active set of M registers >runs at a speed comparable to that of register file that only has M regs. There are a couple of interesting things about our new CPU which were designed specifically for the customers described above. First, the megabyte cache is partitionable among up to 8 processes (actually, slightly more complicated than that.) It is a direct mapped cache so that the interested realtime programmer can statically allocate his data, if so desired. ("hard" realtime people eat nails for lunch.) The scheduling issues were discussed in my previous note. The other thing, the implications of which I don't yet fully understand, is that access time to data in cache is the same as access to data in a register. The instruction set allows one of the source operands to be a generalized address of the usual sort - i.e., base, base + displacement, base + index plus displacement, and so forth. The access time for data in the cache is one cycle, without regard for the complexity of the address mode. Since everything (practically every instruction) is one cycle, you are encouraged to use the most complex address modes and most powerful instructions that make sense, as they squeeze out RISCish instructions that would consume extra cycles. They also seem to reduce the demand for registers by reducing the penalty for not having something in a register, although there is still a penalty. Naturally, these are expensive RAMs and an expensive CPU. My point is that, in our CPU at least, there are interesting things going on in the never-ending war between the levels of the memory heirarchy.