Stuart Cheshire
Sidney Sussex College
In fact, less work was completed than had been hoped for.
This was because of two reasons: the difficulty in deciding the most efficient way to rewrite routines in C, and reluctance to get involved with the difficulties of maintaining parallel development on two systems.
The latter occurred as a consequence of looking closely at each individual part of the code, especially in the light of considering how best to implement them in a high level language. When writing assembler it is hard not to allow fears about implementation difficulties to prejudice decisions about the kind of algorithm to use. While reappraising the situation from the standpoint of a high level language, I often realized that there might be better ways of doing certain things. The most visible example of this is the rewriting of the network code which allowed the speed to be increased from a previous maximum of 4800 baud to the present 19200 baud. The desire to improve various things such as this caused me to keep returning to the BBC to rewrite parts of the code before continuing with the conversion to the Macintosh. I did not want to get into the situation of working to convert a routine into C which was going to be rewritten later anyway. I wanted to have the BBC version totally finished before producing the Macintosh version but the very act of beginning to do the conversion caused me to realize that the BBC version was not as completed as I had thought it was.
The former problem had not been expected. C is usually regarded as a fast, efficient language, a dirty language not actually very far removed from assembler. Closer comparison with my assembly code showed it to be not so efficient after all. The assembler routines are extremely efficiently coded, and almost all take their parameters in registers, and return their results in registers[44]. C calling conventions are grossly inefficient compared with this[45] and even now I am not sure whether the finished program in C on the 68000 will be able to run as fast as the assembler on the 6502. It would be a pity if a machine like the Macintosh was unable to match the smooth movement of graphics produced on the BBC. Current games on the Macintosh seem to suggest that this is the case, but that may just be because they are all extremely badly written.
The solution which has been used so far is to implement most of the small, frequently called routines (such as putmapcell, getmapcell, coordinate conversion etc.) as macros, so that the inefficient stack-based calling conventions are not invoked when they are used.
The program has reached a state of being able to communicate on the network, but not all the the core code has been written and none of the graphics code.