Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!hsdndev!rice!uupsi!sunic!dkuug!diku!torbenm
From: torbenm@diku.dk (Torben [gidius Mogensen)
Newsgroups: comp.sys.acorn
Subject: Re: Memory handling
Message-ID: <1991Apr17.091856.26177@odin.diku.dk>
Date: 17 Apr 91 09:18:56 GMT
References: <1991Mar20.143227.247@ecc.tased.oz.au> <1991Mar22.171119.11147@ifi.uio.no> <6079@acorn.co.uk> <4826@syma.sussex.ac.uk>
Sender: news@odin.diku.dk (Netnews System)
Organization: Department of Computer Science, U of Copenhagen
Lines: 51

gavinw@syma.sussex.ac.uk writes:

>The design of the ARM makes
>the use of base+offset descriptors less natural than straight
>addresses as descriptors, because writeback modifies the base
>address instead of modifying the offset register.

>Two enhancements to future ARMs that I would like to see are

>i) 'modify offset-register' writeback addressing-modes
>ii) trap register-values-outside-given-range to speed up range
>checking.

>-- Gavin Wraith

In the LDR and STR instructions, when you use the [Rn,Rm]! or [Rn],Rm
modes to get base+offset addressing, there is no requirement to have
Rn be base and Rm be offset - you might as well have Rm be base and Rn
be offset, and thus get offset-register writeback. However, I don't
think this is what you want, as the new offset-register is now not an
offset to the base register. If you want to modify the offset you
would want an address calculation with three values: base+offset+index, 
and write offset+index back to the offset register. This requires two
additions and a writeback after the first, and can thus not be
accomodated in the present cycle count of the LDR and STR instructions.
An alternative solution (more in the RISC philosophy) is to use two
instructions: ADD offset,offset,index; LDR Rd,[base,offset]. This is
likely to have the same cycle count as a single instruction would.

As for trapping register-values-outside-given-range, this would
require a LOT of extra hardware in the CPU: two extra registers for
each present registers and extra ALUs for range checking. A much
better solution is to trap addresses out of range in load and store
instructions. This would be logically be handled by MEMC. An idea
would be to allocate a page for each array, and let MEMC trap
addresses outside this range. This would require two things not
present in the current architecture: variable sized pages, and the
ability of load/store instructions to specify a page number. It would,
however, allow all arrays to start at logical address zero (in the
page). Addressing modes could be "Page Rp,[#m]", "Page Rp,[Rm]" and
"Page Rp,[Rm,shift #s]", the idea being that the Rn register in the
present addressing modes would refer to a page rather than being a
base address. This would require only one extra bit in the LDR/STR
instructions. As for hardware, the CPU must be able to use page+offset
addressing modes in addition to logical addresses, and the MEMC must
be able to handle (a large number of) variable sized pages.

I believe this is far out of the range of likely developments for the
ARM, but could be used in less "RISCy" designs.

	Torben Mogensen (torbenm@diku.dk)