Date   : Wed, 14 Dec 2011 23:26:18 +0100
From   : sparc@... (Patrick Kaell)
Subject: 32016 + 32082

> Apart from one deplorable result, I find it interesting that, on the
> whole, the 6502 co-processor holds its own fairly well.


 > Apart from one deplorable result, I find it interesting that, on the
 > whole, the 6502 co-processor holds its own fairly well.

The 6502 scored pretty well with hand-optimized machine code and the BBC 
BASIC interpreter is without doubt a piece of heavily optimized machine 
code.

But it is pretty difficult to write a good code generator for the 
3-register 6502. Almost every BBC Micro compiler which I am aware of 
(Acornsoft BCPL, Acornsoft ISO Pascal, Acornsoft LISP, Acornsoft C, 
Beebug C, etc.) generates byte code instead of native 6502 code. This 
byte code is then running in a virtual machine. The only exception I am 
aware of is "Small C", which generates only crude non optimized 6502 code.

Even the 8-bit 8080/Z80 had a version of Turbo Pascal generating native 
code under CP/M.

The Acorn 32016 co-processor came with high-level compilers (C, Pascal, 
Fortran, LISP). Please try writing a benchmark in C and compile it on 
the Beeb using Acornsoft C or Beebug C. Then compare it with the 32016. 
The BASIC benchmarks are too 6502 friendly. A 2MHz 8bit 6502 running BBC 
BASIC could easily outperform a 6MHz 16bit 80286 running GW-BASIC.

When Acorn was looking for a successor to the 6502, they were evaluating 
processors like 68000, 32016 and 80286. But the performance of these 
processors were disapointing compared to the 6502 (especially the 
interrupt latency). This was the very reason why Acorn decided to 
develop the ARM.

Regards,

Patrick Kaell