Date : Thu, 15 Dec 2011 07:17:49 +0100
From : rick@... (Rick Murray)
Subject: 32016 + 32082
On 14/12/2011 23:26, Patrick Kaell wrote:
> Almost every BBC Micro compiler which I am aware of [snip list] generates
> byte code instead of native 6502 code.
Would this not perhaps be "the lazy approach"? Once you have the core of
a good solid bytecode interpreter, it is rather less difficult to paste
in translation from C, from Fortran, from BCPL, from Lisp, from Logo,
from Pascal. Hell, they probably could have mean a BASIC one too, if it
wasn't for the fact that gains might have been somewhat less impressive...
> This byte code is then running in a virtual machine.
For sure, optimising for a 6502 would be painful, what with two
registers and a 256 byte stack. I mean, you *could* just stack
everything on procedure entry, but how much space do you have? On a
Master (BeebEm), I threw together a program, namely:
[ OPT 2 : TSX : RTS ]
and it told me the default location for the stack pointer when in BASIC
doing nothing is &ED. If we assume Acc is corruptable and functions take
five bytes (16 bit address, flags, X, Y) then that means we can
comfortably nest around 40 functions. Assuming nothing else touches the
stack, but with optimisation, we might rely rather more upon stack
behaviour. Which, er, then needs to be kept track of.
Yeah, I can see why they went the bytecode route. ;-)
> Please try writing a benchmark in C and compile it on the Beeb using
> Acornsoft C or Beebug C.
I have neither. Sorry.
> A 2MHz 8bit 6502 running BBC BASIC could easily outperform a 6MHz 16bit
> 80286 running GW-BASIC.
Well, the earlier members of the x86 family were bloody horrible. I
remember looking to the 8088 (or was it 8086) at college and I don't
know what frightened me most. Pick:
1. Shared data/address bus, so any fancy gains would be clobbered in
I/O with the rest of the world.
2. The irregular (1:3) clocking, and I was the only one that noticed.
[I think I was the only one that bothered to read the datasheet]
3. Interrupts get serviced in a mere... what was it, 78 cycles? But,
like the Z80, cycles aren't clock ticks but some other seemingly
arbitrary measurement.
So there was World+Kitten sitting at Nimbus workstations, while I dug a
Beeb out of the cupboard. To add insult to injury, I coded with
*nothing* and saved my stuff on a cassette tape [record-capable walkman,
as it happens] They used some dead-early TurboPascal and fought over
floppy discs as the LAN was so unreliable. The first project was a
practical one, to design software to read up to four push buttons for a
competition gameshow type thing. The computer must respond to the press,
lock out the others, illuminate a lamp to indicate who pressed first,
and display on the screen the timings of all of the presses. Plus, a
fifth button to reset the gadget. In testing, the x86 (I think clocking
something weird like 7.76MHz) worked about 3/4 of the time, but if you
pressed two buttons too fast, it could not distinguish. This was
'patched' using a little logic board to run a flip-flop to freeze out
other inputs, but then the timing facility was disabled. The Beeb, on
the other hand, worked every time, even when trying to press both
buttons at the same time. This is with an assembler program running on
top of the MOS, with the contraption plugged into an I/O board on the
PCs, or the Beeb's user port.
I did cheat slightly. The initial spec was to poll the interface to
detect a change in state, but it was determined better to wire-OR the
inputs to kick an IRQ line. I ignored this and just loop-polled the
6522. After all, it only takes an LDA &FE60 followed by a CMP and a
branch. ;-)
Disclaimer: It has been suggested that while the early x86 took crappy
to new heights, the 8259 PIC pretty much wouldn't have helped. I didn't
delve into the hardware to try to work out why. Wasn't interested.
Best wishes,
Rick.
--
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...