A Comparison Of The Archimedes And BBC Ranges
(from a programmer's point of view)
By M.T.Farnworth (I.D. 16C)
A non-programmer would probably consider this a cut and dried argument.
The Archimedes would appear the obvious winner in any competition, however
it turns out that this is not necessarily the case.
We will start with a look at high level languages.
On both the Archimedes and BBC these are plentiful. BASIC is built into
all machines, and other major languages such as C and Pascal are
available. It should be pointed out however that although there are many
languages for the BBC their availability is falling due to
discontinuation. Also most of the languages are a later version on the
Archimedes.
When programming in high level languages one of the first factors to
consider is the memory which is available, as this results in obvious
limits. The Archimedes would appear to be the clear winner in this
category but again this is not necessarily true. One problem that I have
found with the Archimedes is that vast amounts of memory are grabbed for
all sorts of things. The best example of this is the "Module area" which
takes 544K on my machine straight away. As it happens I am on a 4MB
machine so this does not affect performance. However on some of the small
1Mb machines this would leave you with about 400K for BASIC programs after
some memory has been set aside for the screen display. This would appear
an unbeatable amount of memory compared to what the standard BBC gives
(about 24K if you're lucky), however DGS informs me that with his 1Mb
32016 Second Processor he can get well over 900K for BASIC programs.
Whilst of course the 32016 cannot compete with the ARM2 or ARM3
(processors currently in the Archimedes range) this larger memory base can
prove more useful as less disk access is necessary. It should also be
considered that DGS obtained his second processor for #100 + VAT and that
included a copy of Fortran, Lisp, C, BBC BASIC and ISO Pascal. A similar
amount of programming software for an Archimedes would cost at least #500
just for the software.
Another thing that should be considered when writing programs is who they
are for. If you wish to use them on different machines then you must go
for what would be considered standard. In this case the 32016 falls down
because it is somewhat scarce and as such few people have them. So a
program written for use on it could not be widely distributed. [ But
anything written in standard high-level languages is supposed to be
totally portable. ]
I would now like to consider the implementation of Assembly Language on
both machines. Both have an assembler built into BASIC. Here the
similarity ends however.
One thing that I think I should point out here is that due to the speed of
the Archimedes in high level languages I have found that Assembly Language
is mainly unnecessary and as such I have stuck with BASIC. [ Although for
certain tasks Arch BASIC can be up to 100 TIMES SLOWER than BBC assembly
language, or so I'm told. ]
When first studying an Archimedes Assembly Language manual the whole idea
of the speed and power seems quite exciting. First there is the speed
which could be anything from 4 million instructions per second to 13.5
million instructions per second (depending on your processor). Then there
is the fact that you can deal in 32 bits at a time instead of 8.
Multiplication is also a single instruction. Also available are such
operations as adding two registers together having first multiplied the
second by any integer value (eg R3=R2+R1*4) all in one instruction. 15
32-bit registers at any time all of which can be used in any way. There is
also a barrel shift operation which can be used at the same time as most
other operations. Another new concept is that of conditional instructions
which only execute if a flag is in a certain state. This rids you of all
the branching that used to be necessary. There are of course a vast number
of additional operating system calls which cater for most of the areas
which were missing on the BBC. They are now known as SWIs (SoftWare
Interrupts).
All this however conceals certain problems. One of these showed up in a
Micro User when building a sound sampler. Whilst on the BBC it was simple
task of reading a memory location and then storing the data, on the
Archimedes it was necessary to first enter Supervisor Mode, and then read
the memory location required. The Archimedes solution may sound not much
more difficult but it did in fact require a considerable amount more
knowledge and the use of vectors.
My next comment is about the way in which the ARM processor handles its
data. To perform an operation on a piece of data it must first be loaded
into a register, and then if the result is to be stored it needs to be
stored again. In other words, all the useful commands which existed on the
6502 allowing you to add the contents of a memory location (which could be
indexed) to the accumulator directly and simply have gone.
Another annoying feature is that of limitations on immediate constants.
Even though the ARM is a 32-bit processor it is not possible to use a
32-bit immediate constant as all instructions are 32 bits in length and
once the instruction is encoded there are only 12 bits left. The constant
is therefore coded as an 8-bit data field followed along with a 4 bit
position field. It is therefore impossible to use certain values such as
257.
This problem can of course be solved by simply storing the immediate
constant in memory and then loading it into a register.
When accessing memory it must be done using at least one register. That
register may be the PC (program counter) which points to the instruction
which is to be executed (if pipelining is ignored) and an offset would be
used. This makes it easy to write relocatable code (one of the great
advantages). The offset can be a register or an immediate constant (which
must be no more than about 4096 instructions either way).
It is when you wish to access a memory location which cannot be stored as
an immediate constant that it becomes a nuisance. It is then necessary to
load into a register the memory location from memory and then use that
register to point to the memory location which you wish to load the data
from.
Perhaps I have dwelled on the disadvantages of machine code on the
Archimedes a little too long, but then I did get used to the 6502 and as a
result the ARM seems a little awkward, however as can be seen when
programmed properly the Archimedes can give outstanding results.
One question I have to programmers who are keen on the idea of the ARM
multiply command is: How many times have you used multiplication in a
machine code program?
Over all I would say that anybody who wishes to play about with ports and
add their own hardware expansions should stick to the BBC as it has a
whole variety of ports which the Archimedes lacks as standard and they are
easier to access directly. If however you are into high level languages
and need the speed then generally the Archimedes is a clear winner. When
it comes to Assembly Language both machines are awkward in different areas
and the choice is not so clear cut as it may seem. If you have not learnt
Assembly Language before then you should start on the Archimedes, if
however you are used to the 6502 then do not expect the transition to be
an easy one.
(If there are any mistakes in what I have said then please do not hesitate
to contact me.)
You can contact me via 8BS, or by writing to me:
M.T.Farnworth
The Queen's College
Oxford
OX1 4AW
(between 7 Oct and 4 Dec 1992)
or
M.T.Farnworth
27 Hunt St
Atherton
Manchester
M29 9JF
(at any time)
N.B. Any messages sent to me via either address during term time could
have a slow response time so please be patient.