4 ms·

> Well the ARM's original goal was to run BBC BASIC faster than the BBC B could run assembly code. That seems an unlikely goal given BBC BASIC was interpreted!

> Well the ARM's original goal was to run BBC BASIC faster than the BBC B could run assembly code. That seems an unlikely goal given BBC BASIC was interpreted! Happy to be proven wrong but I've never heard one of the original team say that.

pjmlp 1y ago
It could be the point of what optimizations would be possible on the interpreter. One of the optimizations Google introduced on Android 7, when they backtracked for AOT at installation time introduced in Android 5, was that the DEX interpreter was rewriten from scratch in cleverly manually written Assembly, before handing it over to the JIT/AOT infrastructure. BBC Basic was also one of the few that allowed direct inline Assembly, instead of having to go through DATA blocks.
- klelatti 1y ago
  BBC BASIC wasn't JIT'd etc so not sure how all the Android comparisons come in! Just to make the comparison more concrete the ARM1 ran at 8MHz and was 32-bit and with a lot more registers compared to the BBC Micro's 6502 running at 2MHz. It was a lot faster but not fast enough to make BBC BASIC run at BBC Micro Assembly language speed.
  - pjmlp 1y ago
    Missed the part about writing interpreters in Assembly? Most folks nowadays wouldn't even think that is an option, hence the comparison with a product several decades later doing that instead of C kind of approach. Back to ARM v1, maybe the design did take into account how to improve the developer's life of those writing in Assembly, which was critical for implementation of the whole userspace, meaning BBC Basic.
Someone 1y ago
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.
- klelatti 1y ago
  The interpreter is doing a lot that you’ve not mentioned here; parsing the BASIC source code for example.
  - guenthert 1y ago
    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.
    - tomatocracy 1y ago
      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.
  - tom_ 1y ago
    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.
- JdeBP 1y ago
  There was no self-modifying code. BBC BASIC was in ROM.
Lio 1y ago
Sophie Wilson discusses it here[1] but I've read it in other places too. You'll have to find them yourself though. > The second thing they didn’t do was that they weren’t fast, they weren’t easy to use. We were used to programming the 6502 in the machine code and we rather hoped that we could get to a power level such that if you wrote in a higher level language you could achieve the same types of results. So you could write 3D graphics games. You could do whatever you wanted to do without having to go all the way down to assembly language and for these processors that were on sale at the time that wasn’t true. They were too slow. So between the two things we felt we needed a better processor. https://archive.computerhistory.org/resources/access/text/2012/06/102746190-05-01-acc.pdf https://archive.computerhistory.org/resources/access/text/20...
- klelatti 1y ago
  Thanks for the quote which is very interesting. Not being pedantic but this isn’t quite what your original comment said. Sophie is saying ‘same type’ of results and not having to use assembly for certain applications which doesn’t imply that BASIC on ARM would be faster than 6502 assembly just that it was fast enough for their purposes. I think it’s possible that some applications would be faster - floating point for example due to the ARM’s 32 bit registers and the 6502’s lack of even 16 bit arithmetic - but probably not in general.
  - TheOtherHobbes 1y ago
    You have to remember these 1980s processors were ridiculously slow by modern standards, and "same type of results" implies a ballpark goal that was impressively aspirational on its own terms. The details of "Does that mean the same speed, or faster?" weren't really relevant, because the speed difference was anywhere between 10X and 100X - which was an astounding, if rather fuzzy, target. ARM 1 got surprisingly close to that out of the gate, with the added benefit of being unexpectedly power efficient.

pjmlp 1y ago

It could be the point of what optimizations would be possible on the interpreter. One of the optimizations Google introduced on Android 7, when they backtracked for AOT at installation time introduced in Android 5, was that the DEX interpreter was rewriten from scratch in cleverly manually written Assembly, before handing it over to the JIT/AOT infrastructure. BBC Basic was also one of the few that allowed direct inline Assembly, instead of having to go through DATA blocks.

klelatti 1y ago
BBC BASIC wasn't JIT'd etc so not sure how all the Android comparisons come in! Just to make the comparison more concrete the ARM1 ran at 8MHz and was 32-bit and with a lot more registers compared to the BBC Micro's 6502 running at 2MHz. It was a lot faster but not fast enough to make BBC BASIC run at BBC Micro Assembly language speed.
- pjmlp 1y ago
  Missed the part about writing interpreters in Assembly? Most folks nowadays wouldn't even think that is an option, hence the comparison with a product several decades later doing that instead of C kind of approach. Back to ARM v1, maybe the design did take into account how to improve the developer's life of those writing in Assembly, which was critical for implementation of the whole userspace, meaning BBC Basic.

Someone 1y ago

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.

klelatti 1y ago
The interpreter is doing a lot that you’ve not mentioned here; parsing the BASIC source code for example.
- guenthert 1y ago
  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.
  - tomatocracy 1y ago
    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.
- tom_ 1y ago
  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.
JdeBP 1y ago
There was no self-modifying code. BBC BASIC was in ROM.

Lio 1y ago

Sophie Wilson discusses it here[1] but I've read it in other places too. You'll have to find them yourself though. > The second thing they didn’t do was that they weren’t fast, they weren’t easy to use. We were used to programming the 6502 in the machine code and we rather hoped that we could get to a power level such that if you wrote in a higher level language you could achieve the same types of results. So you could write 3D graphics games. You could do whatever you wanted to do without having to go all the way down to assembly language and for these processors that were on sale at the time that wasn’t true. They were too slow. So between the two things we felt we needed a better processor. https://archive.computerhistory.org/resources/access/text/2012/06/102746190-05-01-acc.pdf https://archive.computerhistory.org/resources/access/text/20...

klelatti 1y ago
Thanks for the quote which is very interesting. Not being pedantic but this isn’t quite what your original comment said. Sophie is saying ‘same type’ of results and not having to use assembly for certain applications which doesn’t imply that BASIC on ARM would be faster than 6502 assembly just that it was fast enough for their purposes. I think it’s possible that some applications would be faster - floating point for example due to the ARM’s 32 bit registers and the 6502’s lack of even 16 bit arithmetic - but probably not in general.
- TheOtherHobbes 1y ago
  You have to remember these 1980s processors were ridiculously slow by modern standards, and "same type of results" implies a ballpark goal that was impressively aspirational on its own terms. The details of "Does that mean the same speed, or faster?" weren't really relevant, because the speed difference was anywhere between 10X and 100X - which was an astounding, if rather fuzzy, target. ARM 1 got surprisingly close to that out of the gate, with the added benefit of being unexpectedly power efficient.