Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: comp.arch Subject: Re: Wirth's challenge (was Re: RISC Message-ID: <28200082@ccvaxa> Date: 24 Dec 87 19:15:00 GMT References: <12181@orchid.waterloo.edu> Lines: 51 Nf-ID: #R:orchid.waterloo.edu:12181:ccvaxa:28200082:000:2792 Nf-From: ccvaxa.UUCP!aglew Dec 24 13:15:00 1987 ..> Peter Schachte ...!sun!quintus!pds, and others, responding and amplifying ..> my statement that scientific processors (general purpose processors) ..> can do special purpose work as fast as other processors. Tagged Operations: As Peter points out, a natural way to support tags is to place them in the high order bits, and have an architecture that ignores, say, the top 4 bits. I work on such an architecture, and we have a common LISP that takes advantage of it. Except that it was a pain to port this LISP to a new machine that ignored fewer of the top order bits (is that correct Brian, Scott?) Of course, another way is to put the tags in the low order bits, since tagged systems usually don't need object addresses of byte granularity - the smallest object is usually a word or two. Lately, I have been thinking that the best thing to do is to implicitly AND mask all addresses with a loadable ADDRESS_MASK value. The AND masking can be done by dedicated gates away from the ALU, and so shouldn't stretch your critical path (although it is close to the critical memory address generation, I think that it would fall in the slack at the end of one pipeline stage). The biggest advantage of of ADDRESS_MASK would be that it would let you support applications with different ideas of the shape of the address on the same machine; and it would provide a way for you to increase the address space while still letting old, broken programs that rely on overflow of a 32 bit quantity to work. Ie. programs that rely on addresses being 32 bits would have an address mask 0x0FFFFFFFF; programs that rely on addresses being 40 bits would be 0x0FFFFFFFFFF; and so on. There are quite a few programs that rely on 24 bit and 16 bit addresses, even now. Hardware would, of course, limit the values that can be loaded into the ADDRESS_MASK - 32 bits now, but tomorrow 40 bits, then 48 bits, and so on. Using ADDRESS_MASK for tags is obvious: If you are using 2 bits of high order tags on a 32 bit machine, set your mask to 0x3FFFFFFF; if you are using 2 bits of low order tags, and you want to avoid a misaligned address trap, set mask to 0xFFFFFFFA. This is not unlike the LOAD-TAGGED instructions in SPARC and SPUR and SOAR; the main difference is that the architecture does not force any decisions, as to the size of the tag, etc., onto the implementor of the tagged language system. Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@mycroft.gould.com ihnp4!uiucdcs!ccvaxa!aglew aglew@gswd-vms.arpa My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.