Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!hp4nl!eutrc3!rcbaps
From: rcbaps@eutrc3.UUCP (Pieter Schoenmakers)
Newsgroups: comp.arch
Subject: ARM 'problems' (was: Re: Criteria for comparing RISC processors)
Keywords: RISC, Acorn, ARM
Message-ID: <600@eutrc3.UUCP>
Date: 21 Apr 89 19:05:50 GMT
References: <2368@ogccse.ogc.edu> <596@eutrc3.UUCP> <132@marvin.moncam.co.uk>
Reply-To: rcbaps@eutrc3.UUCP (Pieter Schoenmakers)
Organization: Eindhoven University of Technology, The Netherlands
Lines: 33

In article <132@marvin.moncam.co.uk> paul@moncam.co.uk (Paul Hudson) writes:
>
>Problems: Max 4Mb memory with current memory controller.
           Acorn are said to have a beast with two MEMCs fitted, giving 8Mb
           of RAM. Not a neat way but it works. They should produce a new
           MEMC with a larger page-table.
>	  32 Kbytes page size.
           Right.
>	  Poor 16 bit support (a problem with some peripherals).
           Since you've worked with Acorn, you probably know why this
           is. Did you ever take a look at the application sheet of the IOC?
           I don't see any problem.
>	  No DMA support.
           Standard answer: the processor is quick enough to handle (D)MA
           itself. Not a very good answer; there is a better one: design
           a coprocessor, which can handle the DMA stuff in 3 cycles
           (1 instr. fetch, 1 data fetch and 1 data store).
>	  High-resolution screens steal a lot of bandwidth.
           This problem has become less of a problem since Acorn have anounced
           the ARM version 3: 4kb instr. & data caches. This makes the ARM
           need less bandwitdh (obvious remark!).
>	  No delayed branch.
           right?
>
>Conclusion.
> In the right application, unbeatable. Not my choice for a workstattion.
>
Pitty... :-)

>Disclaimer: I used to work for Acorn, and have writtern (the back end of) a
>compiler for the beast. Thus the above may be disillusionmemnt

Tiggr