RWilson@acorn.co.uk (02/22/90)
ARM surfaces again on comp.arch - wonders will never cease :-) ]A related observation: the Acorn ARM has pre/post-increment/decrement (all 4 ]combinations). You don't have to pay a penalty in cycles for using them. ]The ARM is a RISC. ]Ge' Weijers You do pay a slight penalty - instruction code density vs address offset. The extra bits of control for pre/post & inc/dec use up some bits that might have been used for a bigger address offset. Studies showed.... }This is indeed addressing modes, but as any load can be done in one cycle, }Torben Mogensen (torbenm@diku.dk) Actually, due to all sorts of memory pipeline breaks, all loads in ARM are 3 cycles, all stores are 2 cycles. (for the interested, ARM has a pipelined memory bus: the address in cycle a refers to the data xferred at the start of cycle b - at which time ARM is already presenting a new address for cycle b. This - since load requires one to look at the target, get the value and then get the next instruction - means 3 cycles of the bus are spent on the load. And it was simpler to make this 3 cycles internally - avoiding the extra ports which might have been needed for pre/post & inc/dec - since we weren't thinking of building ARM3 at the time (1984) (a good guess on the part of Randell Jesup). Stores can be done in 2 cycles since the processor needn't wait while the data whizzes about. Looking at ARM address traces on a logic analyser can be very exciting :)). >correction - (single register) loads on an ARM take three or four cycles, >depending on the alignment of the next instruction in the pipeline. >MEMC (the memory controller in the ARM chipset) loads 4 32-bit words at a >time, so that relatively slow memories may be used, however this means >that any out of sequence loads require an extra cycle to be inserted in >order to reload. >Alasdair McIntyre (aiadrmi@uk.ac.edinburgh.castle) As stated above, as far as ARM is concerned load is always 3 cycles. The memory controller transfers data to and from DRAMs using page mode to speed up many cycles. But the column address is also used for late translation of the virtual address which limits the number of page mode cycles in a row to 3 - when we have to do a new row address. Page mode cycles are sequential "S" cycles, non-page mode are non-sequential "N" cycles. ARM provides an advance warning signal to the memory controller when it breaks sequentiality. Clearly LDR breaks, so it takes N, N, S. Clever logic in MEMC rescues the second N, turning it into an S where possible. STR always does N, N - coincidentally the same time as LDR in current systems where N=2*S, but for different reasons. As Alasdair states, the multiple transfer instructions have the same timing as the single transfer instructions for just one register. Each additional value transferred then takes an extra S cycle. LDM instructions are thus able to operate at nearly peak memory bandwidth. >Using this technique the maximum sustained data rate achievable for a block >move operation is over 11 Mbytes/sec on an 8MHz ARM for a word aligned transfer >Alasdair McIntyre (aiadrmi@uk.ac.edinburgh.castle) Now current Acorn volume market machines have just about the slowest DRAM obtainable. N=250nS, S=125nS. Bus bandwidth is maximised by N+3S repeated, coming in at 25.6MBytes per second. And LDM/STM of (say) 8 registers gets very close to this, so an Acorn A3000 (649 pounds) can pick up memory *and put it down again* at around the speed mentionned - provided the video system isn't after the memory bandwidth as well! But these aren't ARM limits (or even MEMC limits). I'm using a research prototype machine with N=166nS, S=83nS. A bus bandwidth of 38.4MBytes per second. And its DRAMs are just a bit less affordable :-). Naturally ARM3 refills cache lines using the N+3S transfer method. Thus speeding up LDR instructions to related addresses. Third party ARM3 upgrades to Acorn machines are circa 500 pounds.... (and falling) =Remember, the guiding principle of architecture design is not "is it RISC", =it's "is it faster" (with a little "is it cheaper", "is it easier to =program", "is it reliable", etc thrown in.) =Randell Jesup (jesup@cbmvax.cbm.commodore.com) ARM and its related chip set were designed on a "total system design" principle. With a great deal of "is it cheaper?" thrown in, since our objective was to make a true 32 bit computer with performance, hardware memory management, colour bit mapped screens and flexible IO, as cheap as possible. RISC just happened to fit the bill on the processor end of things (68020's cost as much as the whole of the rest of the system put together in 1984), but many other considerations and technologies were valuable. Like we also wanted to make the assembly language easy to write in, the overall system readily manufacturable, the amount of people time to design the chips tractable.... So we ended up with (strange?) things like MEMC with no data bus, VIDC with no address bus. And zillions of lines of ARM Assembler (it turned out so easy to write...). --Roger Wilson
jhallen@wpi.wpi.edu (Joseph H Allen) (02/23/90)
In article <1713@acorn.co.uk> RWilson@acorn.co.uk writes:
[Arm info]
Whose bright idea was it to put the flag bits in the upper half of the PC?
Sure it saves a store in the interrupt handling but now ARM is stuck with only
26 address lines (or whatever it was)...
(otherwise, I like ARM very much. A RISC processor you can actually program
assembly language in! How fast is the latest ARM these days?)
--
"Come on Duke, lets do those crimes" - Debbie
"Yeah... Yeah, lets go get sushi... and not pay" - Dukejkenton@pinocchio.encore.com (Jeff Kenton) (02/27/90)
From article <8948@wpi.wpi.edu>, by jhallen@wpi.wpi.edu (Joseph H Allen): > > (otherwise, I like ARM very much. A RISC processor you can actually program > assembly language in! How fast is the latest ARM these days?) Motorola's 88000 is pretty nice for writing assembly language, and MIPS looks decent too, although I haven't tried it. No opinion on SPARC, but Intel's 860 looks a little baroque. Any other opinions? We haven't had a good religious war in a week or two. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - jeff kenton --- temporarily at jkenton@pinocchio.encore.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
scoii@mips.COM (Randy Scofield) (02/27/90)
In article <11245@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes: >From article <8948@wpi.wpi.edu>, by jhallen@wpi.wpi.edu (Joseph H Allen): >> >> (otherwise, I like ARM very much. A RISC processor you can actually program >> assembly language in! How fast is the latest ARM these days?) > >Motorola's 88000 is pretty nice for writing assembly language, and MIPS looks >decent too, although I haven't tried it. No opinion on SPARC, but Intel's 860 >looks a little baroque. <stuff deleted> >Any other opinions? We haven't had a good religious war in a week or two. >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > jeff kenton --- temporarily at jkenton@pinocchio.encore.com >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - It is true that I am biased, so I usually stay out of such conversations. I believe the Rx000 family is well suited to assembly code writing. I like general purpose resisters, and lots of them. Since the compiler guys take care of all the interlock issues, the source code is pretty simple. And simple is best, unless all you do is write assembly code, and need job security. :-] And besides, once you have felt the response time on a Mips based machine, there is no going back!! Randy -- - Randy Scofield (disclaimer:**I speak for me, etc) UUCP: {ames,decwrl,prls,pyramid}!mips!scoii USPS: MIPS Computer Systems, 930 Arques, Sunnyvale, CA 94086, (408) 991-0232
csimmons@jewel.oracle.com (Charles Simmons) (02/28/90)
In article <11245@encore.Encore.COM>, jkenton@pinocchio.encore.com (Jeff Kenton) writes: > Motorola's 88000 is pretty nice for writing assembly language, and MIPS looks > decent too, although I haven't tried it. No opinion on SPARC, but Intel's 860 > looks a little baroque. > > Any other opinions? We haven't had a good religious war in a week or two. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > jeff kenton --- temporarily at jkenton@pinocchio.encore.com > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Of course, we note that on the MIPS processor, it's kind of foolish to program in assembly language. There isn't much that you can do in assembly language that you can't get the compiler to do for you. -- Chuck
rpw3@rigden.wpd.sgi.com (Rob Warnock) (03/01/90)
In article <11245@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes: +--------------- | From article <8948@wpi.wpi.edu>, by jhallen@wpi.wpi.edu (Joseph H Allen): | > (otherwise, I like ARM very much. A RISC processor you can actually program | > assembly language in! How fast is the latest ARM these days?) | Motorola's 88000 is pretty nice for writing assembly language, and MIPS looks | decent too, although I haven't tried it. No opinion on SPARC, but Intel's 860 | looks a little baroque. | Any other opinions? We haven't had a good religious war in a week or two. +--------------- I really enjoyed programming Am29000 assembler, once I had gotten used to a real 3-address machine. (Of course I am biased. I was a consultant to AMD at the time...) It took me a while to quit thinking of it as a stuttering 2-address machine -- at first I found myself writing everything as "<op> <dest>, <dest>, <src>". But then the "shape" of the instruction set started sinking in, and I soon learned to use the 3-addr-ness to save instructions (cycles). (Though, just because of what is typically being computed, one still ends up writing many "2-address" instructions.) Overall, it feels really "clean". -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311