proctype.html

关于ARM汇编的非常好的教程

switch itseld from little-endian operation to big-endian operation. The 33MHz version offers
around 28MIPS (0.84 MIPS/MHz).
<center><img src = "../images/assembler/arm610.jpeg" width=313 height=208 alt="JPEG 22K" border=2><br>
<font size = "-1"><i>The RiscPC ARM610 processor card</i></font>
<font size = 1><i><br>(original picture by Rick Murray, &copy; 2002)</i>
</font><br>
</center>
<p>&nbsp;<p>


<h2>ARM 710 (v3)</h2>

As an enhancement of the ARM610, the ARM 710 offers an increased cache size (8K rather than 4K),
clock frequency increased to 40MHz, improved write buffer and larger TLB in the MMU.<br>
Additionally, it supports CMOS/TTL inputs, Fastbus, and 3.3V power but these features are not
used in the RiscPC.<br>
Clocked at 40MHz, it offers about 36MIPS (0.9 MIPS/MHz); which when combined with the additional
clock speed, it runs an appreciable amount faster than the ARM 610.
<center><img src = "../images/assembler/sidebyside.jpeg" width=320 height=181 alt="JPEG 16K" border=2><br>
<font size = "-1"><i>ARM710 side by side with an 80486, the coin is a British 10 pence coin.</i></font>
<font size = 1><i><br>(original picture by Rick Murray, &copy; 2001)</i>
</font><br>
</center>
<p>&nbsp;<p>


<h2>ARM 7500</h2>

The ARM7500 is a RISC based single-chip computer with memory and I/O control on-chip to minimise
external components. The ARM7500 can drive LCD panels/VDUs if required, and it features power
management. The video controller can output up to a 120MHz pixel rate, 32bit sound, and there are
four A/D convertors on-chip for connection of joysticks etc.<br>
The processor core is basically an ARM710 with a smaller (4K) cache.<br>
The video core is a VIDC2.<br>
The IO core is based upon the IOMD.<br>
The memory/clock system is very flexible, designed for maximum uses with minimum fuss. Setting up
a system based upon the ARM7500 should be fairly simple.
<p>&nbsp;<p>


<h2>ARM 7500FE</h2>

A version of the ARM 7500 with hardware floating point support.
<br>
<center><img src = "../images/assembler/stb_cpurom.jpeg" width=360 height=254 alt="JPEG 27K" border=2><br>
<font size = "-1"><i>ARM7500FE, as used in the Bush Internet box.</i></font></br>
<font size = 1><i><br>(original picture by Rick Murray, &copy; 2002)</i></font></center>
<p>&nbsp;<p>


<h2>StrongARM / SA110 (v4)</h2>

The StrongARM took the RiscPC from around 40MHz to 200-300MHz and showed a speed boost that was
more than the hardware should have been able to support. Still severely bottlednecked by the
memory and I/O, the StrongARM made the RiscPC fly. The processor was the first to feature
different instruction and data caches, and this caused quite a lot of self-modifying code to
fail including, amusingly, Acorn's own runtime compression system. But on the whole, the
incompatibilities were not more painful than an OS upgrade (anybody remember the RISC OS 2 to
RISC OS 3 upgrade, and all the programs that used SYS OS_UpdateMEMC, 64, 64 for a speed boost
froze the machine solid!).<br>
In instruction terms, the StrongARM can offer half-word loads and stores, and signed half-word
and byte loads and stores. Also provided are instructions for multiplying two 32 bit values
(signed or unsigned) and replying with a 64 bit result. This is documented in the ARM assembler
user guide as only working in 32-bit mode, however experimentation will show you that they work
in 26-bit mode as well. Later documentation confirms this.<br>
The cache has been split into seperate instruction and data cache (Harvard architecure), with
both of these caches being 16K, and the pipeline is now five stages instead of three.<br>
In terms of performance... at 100MHz, it offers 114MIPS which doubles to 228MIPS at 200MHz
(1.14 MIPS/MHz).
<center><img src = "../images/assembler/sa110lart.jpeg" width=325 height=244 alt="JPEG 36K" border=2><br>
<font size = "-1"><i><a href="http://www.aleph1.co.uk/armlinux/LART/">A StrongARM mounted on a LART board.</a></i> <font color = "red" size = "-1">[EXTERNAL LINK]</font></font>
</center>
<p>

In order to squeeze the maximum from a RiscPC, the Kinetic includes fast RAM on the processor
card itself, as well as a version of RISC OS that installs itself on the card. Apparently it
<i>flies</i> due to removing the memory bottleneck, though this does cause 'issues' with DMA
expansion cards.<br>
<center><img src = "../images/assembler/kinetic.jpeg" width=449 height=302 alt="JPEG 50K" border=2><br>
<font size = "-1"><i>A Kinetic processor card.</i></font>
</center>
<p>&nbsp;<p>



<h2>SA1100 variant</h2>

This is a version of the SA110 designed primarily for portable applications. I mention it here
as I am reliably informed that the SA1100 is the processor inside the 'faster' Panasonic
satellite digibox. It contains the StrongARM core, MMU, cache, PCMCIA, general I/O controller
(including two serial ports), and a colour/greyscale LCD controller. It runs at 133MHz or 200MHz
and it consumes less than half a watt of power.
<p>&nbsp;<p>&nbsp;<p>



<h2>Thumb</h2>

The Thumb instruction set is a reworking of the ARM set, with a few things omitted. Thumb
instructions are 16 bits (instead of the usual 32 bit). This allows for greater code density in
places where memory is restricted. The Thumb set can only address the first eight registers, and
there are no conditional execution instructions. Also, the Thumb cannot do a number of things
required for low-level processor exceptions, so the Thumb instruction set will always come
alongside the full ARM instruction set. Exceptions and the like can be handled in ARM code, with
Thumb used for the more regular code.
<p>&nbsp;<p>&nbsp;<p>



<h1>Other versions</h1>

These versions are afforded less coverage due, mainly, to my not owning nor having access to any
of these versions.<br>
While my site started as a way to learn to program the ARM under RISC OS, the future is in
embedded devices using these new systems, rather than the old 26 bit mode required by RISC OS...
<br>...and so, these processors are something I would like to detail, in time.
<p>

<h2>M variants</h2>

This is an extension of the version three design (ARM 6 and ARM 7) that provides the extended
64 bit multiply instructions.<br>
These instructions became a main part of the instruction set in the ARM version 4 (StrongARM,
etc).
<p>&nbsp;<p>


<h2>T variants</h2>

These processors include the Thumb instruction set (and, hence, no 26 bit mode).
<p>&nbsp;<p>


<h2>E variants</h2>

These processors include a number of additional instructions which provide improved performance
in typical DSP applications. The 'E' standing for &quot;Enchanced DSP&quot;.
<p>&nbsp;<p>&nbsp;<p>



<h2>The future</h2>

The future is here. Newer ARM processors exist, but they are 32 bit devices.<br>
This means, basically, that RISC OS won't run on them until all of RISC OS is modified to be
32 bit safe.
As long as BASIC is patched, a reasonable software base will exist. However all C programs will
need to be recompiled. All relocatable modules will need to be altered. And pretty much all
assembler code will need to be repaired. In cases where source isn't available (ie, anything
written by Computer Concepts), it will be a tedious slog.<br>
It is truly one of the situations that could make or break the platform.
<p>

I feel, as long as a basic C compiler/linker is made FREELY available, then we should go for it.
It need not be a 'good' compiler, as long as it will be a drop-in replacement for Norcroft CC
version 4 or 5. Why this? Because RISC OS depends upon enthusiasts to create software, instead
of big corporations. And without inexpensive reasonable tools, they might decide it is too much
to bother with converting their software, so may decide to leave RISC OS and code for another
platform.
<p>

I, personally, would happily download a freebie compiler/linker and convert much of my own code.
It isn't plain sailing for us - think of all of the library code that needs to be checked. It
will be difficult enough to obtain a 32 bit machine to check the code works correctly, never
mind all the other pitfalls. Asking us for a grand to support the platform is only going to
turn us away in droves. Heck, I'm still using ARM 2 and ARM 3 systems. Some of us smaller coders
won't be able to afford such a radical upgrade. And that will be VERY BAD for the platform. Look
how many people use the FREE user-created Internet suite in preference to commercial
alternatives. Look at all of the support code available on
<a href="http://www.arcade.demon.co.uk">Arcade BBS</a> <font color = "red" size = "-1">[EXTERNAL LINK]</font>. Much of that will probably go, yes. But
would a platform trying to re-establish itself <i>really</i> want to say goodbye to the rest?<br>
I don't claim my code is wonderful, but if only one person besides myself makes good use of it -
then it has been worth it.
<p>&nbsp;<p>


<a href="32bit.html">Click here to learn more on 32 bit operation</a>
<p>&nbsp;<p>


<hr size = 3>

<a href="index.html#03">Return to assembler index</a>

<hr size = 3>
<address>Copyright &copy; 2002 Richard Murray</address>
</body>
</html>