Hacker News Reader

Comment by Someone | Hacker News Reader

The ARM1 ran at 6MHz, three times as fast as the 6502 in the BBC B.

It also had more (16 user registers vs, counting optimistically, 3) and larger (32 bit vs 8bit) registers, compared to the 8 bit registers of the 6502, and a 3-stage pipeline.

I expect that means the BASIC interpreter kept the current program position in a register, where the 6502 one used memory (likely in self modifying code), and could fetch the next token in a single cycle vs at least 5 or so for the 6502 version.

Having a faster CPU and more memory also may have meant they could be smarter in the way programs get stored.

I guess all that combined means there are programs were that goal can be met, for example programs computing a Mandelbrot image.

ARM2 added a hardware multiplier.

View on HN

There was no self-modifying code. BBC BASIC was in ROM.

I don't know the internals of BBC BASIC, but many Microsoft-derived BASICs do keep track of the current location in the program text with self-modifying code; the routine is copied to a reserved portion of zero page on 6502 machines for speed. On the C64 this routine lives at $0073 and the pointer is at $007a. Because it's in RAM, this makes it a popular location for wedging in additional behaviour or commands (hence the term "wedge" for such extensions). On some systems like the PET, this was the only way to accomplish it.

BBC BASIC is not Microsoft BASIC. You cannot reason about the operation of BBC BASIC from only knowing about Microsoft BASIC.

Whereas I suspect that I am nowhere near the only person on this page who once disassembled ROMs on a BBC Micro. We can state, in contrast, that there was no such self-modifying code. Again, BBC BASIC was in ROM.

Those lucky enough to have a copy of Jeremy Ruston's book after all of these years, or the retrocomputing enthusiasts who still have working Beebs, could even tell you exactly where in ROM the code was that fetched the next token for execution.

I never actually owned a copy of the book, and somewhat envy anyone who still has a copy; although to compensate I do have part of one of my own disassembly listings still, buried somewhere. (-:

I made no claim it was. I was pointing out that ROM BASICs on 6502s have kept track of the current pointer in self-modifying code by copying the relevant section to RAM. Just because it originated in ROM doesn't mean it doesn't. Thank you for explaining the situation with BBC BASIC.

The interpreter is doing a lot that you’ve not mentioned here; parsing the BASIC source code for example.

You can probably make it happen. If your program uses all the same tricks that worked with 6502 BBC BASIC to reduce the interpreter overhead, the ARM BASIC version will run as well as it can. Then imagine your program does a lot of integer maths with the resident integer variables, multiplication in particular, and (for whatever reason) it needs the full 32 bit integer precision - I'm sure you would stand a chance! 32 bit operations are cheap on the ARM, and it's got a multiply instruction. No such luck with the 6502.

Er, the parsing is done ahead of time. The BASIC interpreters then were byte-code interpreters; the one of the beeb a particular fast one.

I know nothing about the first ARM, but ARM2 of Archimedes (anno 1987) was significantly faster than a MC68k (both at 8MHz), both much faster than a 6502 at one (typical) or two (in the beeb) MHz.

A BASIC interpreter using the ARM 1 or 2 might not have been literally faster than machine code on a 6502 (certainly not for some silly micro benchmarks), but, the stated goal, allowing high level programming where earlier assembly was required, certainly was met.

The early 8MHz ARM2-based Archimedes machines arguably also outperformed contemporary 16/20MHz 80386 machines (due to the x86-based machines being slower to access RAM before the advent of on-motherboard cache and zero waitstate RAM) as well.

Reply on news.ycombinator.com