ddr@cs.edinburgh.ac.uk (Doug Rogers) (01/10/91)
> > --a nice summary of why registers win-- > The reason that caches are used is because memory management is > -hard to do > -a pain in the ass > -best done with run time info The same applies to register allocation, where memory mapped registers could provide increased flexibility. Functional programmes are notoriously difficult to compile so that they use the registers efficiently so the abilty to use cache based registers is extremely attractive. This would provides the `register windowing' features automatically and allow a variable size of register set to suit the situation. The advantage of registers is however their multi-port capability allowing registers to be written to and read from within the same clock cycle. Typical super-serial designs are now using upwards of 5 ports. However even dual porting is worthwhile ( you can build a rather nice one-operand machine in this way using an accumulator and a large array of general purpose registers, this actually likes data dependancy to increase speed.) So therefore why not a special purpose multi port cache? I realise that there would be a problem with the speed of the associated memory, but because of the localised nature of access it should be possible to minimise the time delay due to this. -- Douglas Rogers JANET: ddr@uk.ac.ed.lfcs Department of Computer Science UUCP: ..!mcvax!ukc!lfcs!ddr University of Edinburgh ARPA: ddr%lfcs.ed.ac.uk@nsfnet-relay.ac.uk Edinburgh EH9 3JZ, UK. Tel: 031-650 5172 (direct line)
baum@Apple.COM (Allen J. Baum) (01/12/91)
[] >In article <4300@skye.cs.ed.ac.uk> ddr@cs.edinburgh.ac.uk (Doug Rogers) writes: I said ... some reasons that caches are used is because mem management is hard >The same applies to register allocation, where memory mapped registers >could provide increased flexibility.. Yes, but my point was that reg. allocation has a known solution- we know how to do it automagically, so we build processors that take that fact into account. >> Functional programmes are notoriously difficult to compile so that >>they use the registers efficiently so the abilty to use cache based >>registers is extremely attractive. I probably should have said something to the effect that our compilation abilities are highly developed in the areas of procedural languages, and our mainstream applications and architecture development are lead in those directions. It is not clear to me that cache based register are a win. They might be, but it not clear, and I have heard counterexamples. >The advantage of registers is however their multi-port capability.. The ATT CRISP uses essentially a multi-ported cache for their 'registers' -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
rtrauben@cortex.Eng.Sun.COM (Richard Trauben) (01/13/91)
>It is not clear to me that cache based register are a win. They might be, >but it not clear, and I have heard counterexamples. >The ATT CRISP uses essentially a multi-ported cache for their 'registers' The initial CRISP design made no attempt to keep the stack cache consistent with the memory hierarchy. Processes on different CRISP processors in an MP machine that shared a stack were asking for subsequent implementations revised this policy.if -richard
tve@sprite.berkeley.edu (Thorsten von Eicken) (01/13/91)
In article <5820@exodus.Eng.Sun.COM> rtrauben@cortex.Eng.Sun.COM (Richard Trauben) writes: >The initial CRISP design made no attempt to keep the stack cache consistent >with the memory hierarchy. Processes on different CRISP processors in an >MP machine that shared a stack were asking for >subsequent implementations revised this policy.if >-richard Huh? You want to share the call stack in an MP? Why that. Isn't the stack the one area you don't really want to share? Yes, you can pass pointers to automatic variables around, but then that's the same problem as (not) putting variables you take the address of into registers. And which subsequent implementations are you talking of? TvE