| The documentation files are included here on the CD for your perusal. However, to get the tools (which are aimed at C programmers) you will have to visit the RISCOS Ltd Web site and register: point your browser at http://www.riscos.com/download/. |
|
|
Beating at the heart of the computer in front of you is the central processor unit, the ARM silicon chip, a collection of transistors that convert codes into logical operations.
The ARM chip knows that one code value, read from memory, means add two numbers together, and that another code means subtract them. The Intel x86 chip in your neighbour's PC works in the same way, but the codes are different; the code that means add to the ARM means something else to the x86.
Things are made a bit more complex because each chip has different features that the codes can control. Chief amongst these is the number of registers inside the chip. A register is a numeric value that is retained inside the chip rather than in memory. Accessing registers is fast; accessing memory is slow.
Anyway, as long as the codes remain the same, everything can carry on in its merry way. But what if someone decided to change the codes...?
Why might they do that? Well, in the case of the x86 chip, the original versions could only access 1Mb of memory. When it became apparent this was not enough, all sorts of clever methods for accessing more memory were invented, but eventually Intel made a new chip that could access more memory.
When they did this they could have completely abandoned the old codes, but, with a vast library of software in existence, no-one would have bought their new chip if they had done so. The new chip was therefore made compatible with the old one. To this very day, the latest Pentium IV can still execute the code for the original 8086 chip.
However, silicon was expensive back then, and so Acorn made an elegant simplification to the chip: the register which points at the code being executed was combined with a register that shows information about the result of operations. As a result, the chip can only execute code in 26 bits' worth of memory addresses, which equates to 64Mb.
Time went by, and the ARM chip was used in other things besides desktop computers. Silicon became cheaper, and the ARM chip was improved. One improvement was to split up the combined register and allow a full 32 bits for addressing code. As with the x86, compatibility with the old codes was maintained, and newer ARM chips could work in '26-bit mode' (the old codes) or '32-bit mode' (the new ones).
RISC OS, along with all the programs you use under it, dates from the early days and works in 26-bit mode.
Yet more time went by, and it became apparent that 26-bit mode was a waste of silicon space; no-one used it in new products, because 32-bit mode was superior, so it was dropped from new ARM chips.
The point here is that RISC OS counted for nothing in these calculations. Had the RISC OS market been anywhere near as large as the PC market, 26-bit mode compatibility would have been retained forever.
So, if the silicon was only to support 32-bit mode in the future, then RISC OS would have to change to work on it. Everyone has known about this for some time. However, converting RISC OS to 32-bit mode was too big a project for Acorn, although efforts were made to make new code easily convertible.
As the saga of Acorn's demise, the appearance of RISCOS Ltd and the take-over of RISC OS by Pace unfolded, it was to be Pace who would take on this project.
With existing ARM chips and computers, there isn't much to gain from using 32-bit mode. However, new, faster ARM chips are about to become available, and they only work in 32-bit mode, so you are most likely to encounter 32-bit mode RISC OS in the future on a new machine.
If someone gave you such a mythical machine, what would you notice as you installed your old programs?
Quite simply, most of them would not work. The only programs which will transfer with no problems are those written in interpreted languages: if you like, written in another set of codes which are not directly understood by the ARM chip. That's mostly Basic programs (Java would be another example). Pure Basic programs will be OK, but even then, many Basic programs also include a few pieces of ARM code.
Another category is software which is written in compiled languages: C, Pascal and so on; for these, the compiler converts the source into ARM code. As long as you have a 32-bit mode compiler for the language, then all you have to do is recompile the program to make it work.
Finally, there are programs which are written directly in ARM code. With these, the better the programmers were at squeezing the last bit of performance out of the code, the harder its conversion to 32-bit mode is likely to be. The two classic examples of this sort of program are Impression and ArtWorks.
A computer with no software is not much good. So what can be done?
Another direction is to allow 26-bit code to run on 32-bit machines. One way is to emulate a 26-bit processor on a 32-bit machine. In that way, the 32-bit processor interprets the 26-bit code. This is the same idea as the old Acornsoft PC emulator program, which emulated x86 code on the ARM. The snag which lead to that program's being abandoned is that emulation is slow. It does have to be said that new ARMs are so much faster than old ones that this may not be a problem, and not a great deal of work will actually need to done in emulation, so the potential problem is not nearly as great.
It might be possible to build emulation into a 32-bit version of RISC OS so that 26-bit code is automatically emulated and 32-bit code runs at full speed. There is a precedent for this in the way that Apple managed the changeover from the Motorola 68000-series processors to the PowerPC processor in the mid-1990s.
The usual alternative to interpretation is compilation. Instead of working out each instruction as it is encountered, the whole program is converted once, resulting in a 32-bit mode program. The problem with compilation is that the result of some code cannot be determined until it is run, so the success of this approach may depend on how the code is written.
An area where this idea probably would work is with programs written in C. This is because the code generated by compilers is more consistent than that produced by human ARM coders. You may think that any program written in C only needs recompiling; however, in many cases the original C source code is now lost.
The final possibility is hardware emulation: having two processors, one a 32-bit mode ARM, and the other a 26-bit mode ARM. Any 26-bit mode code encountered would be run on the 26-bit processor (analogous to the PC card of the Risc PC).
It will be interesting to see which of these techniques will dominate. One problem is that Pace does not need any kind of solution for 26-bit mode programs, and all the solutions require substantial programming effort and possibly changes to RISC OS to make operation transparent.
Although one can imagine a RISC OS desktop world with no Impression or ArtWorks, once 32-bit machines appear and the problems are understood I think it is quite probable that such programs will be made to work, even if someone has to go through the code by hand (discounting the possibility of Computer Concepts doing the work or opening up the source code to others).
On a personal note, give me a 32-bit machine and I'll have all my software working inside a day. I've already done preliminary work, but it's hard to write software without being able to test it.
Yet another aspect is software built into podules: SCSI cards, Laser Direct interfaces and so on. The point with these is that new machines won't have a podule bus and so any such cards will be redundant.
|
|
|
||
|
The documentation gives an insight into how Pace has decided to implement 32-bit RISC OS. From the discussion above, you might think that it was just a matter of converting from one lot of codes to another. However, architectural issues mean that other subtle changes have been made. These may make the schemes for running 26-bit code on 32-bit hardware rather harder to implement.
The main principle is that code should be mode-neutral; programs should run as well in 26-bit mode as in 32-bit mode. Another decision is that a given copy of RISC OS will be in 26-bit or 32-bit mode. In other words, a program won't find itself running in 26-bit mode at one time and then in 32-bit mode at a later time.
That permits the ultimate way of making a program mode-neutral: looking at what mode the ARM is running in and then loading one of two complete versions of the program. However, much interest will centre around writing code which is truly mode-neutral, using clever tricks like instructions which mean different things in different modes. The Pace documents discuss this at length.
Unfortunately, the new convention that Pace has chosen for compiling C code, whilst mode-neutral, is not compatible with the C library built into RISC OS 4 or any earlier version of RISC OS. So, once 32-bit compatible versions of programs appear, they will come with a new C Library and instructions on how to install it. Presumably, anyone with a 32-bit version of RISC OS would already have the new library built in; however, users of older versions of RISC OS will have to install the new C Library.
What can you do about 32-bit mode right now? If you go to the http://www.riscos.com/download/ Web site you can apply for the material made available by Pace. The documentation supplied with it (and here) is comprehensive, and I don't think I can add anything to it. Once 32-bit mode RISC OS is available, there will be a lot to discover and say. Computer Science often ends up as an experimental discipline; however good the documentation, it won't cover every eventuality.
Given the 32-bit material, you can (if your program is written in C) compile a mode-neutral version of it, and see if it runs. Most C programs are going to contain some assembly language code, which you can make mode-neutral by following the documents supplied. Load the new shared C library and test your program. Of course, all this proves is whether it works in 26-bit mode.
It may also be interesting to load the new shared C library and see if any existing unmodified programs go wrong.
32-bit mode is the future of RISC OS, and when it is available, along with new hardware, there should be some interesting and exciting times. Unfortunately, some people (recalling the ancient curse "may you live in interesting times") will avoid the new developments, making the number of RISC OS users even smaller.
