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 (between 7 Oct and 4 Dec 1992) or M.T.Farnworth (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.