| |
| ▲ | Lio 3 days ago | parent | next [-] | | 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/20... | | |
| ▲ | klelatti 3 days ago | parent [-] | | 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 3 days ago | parent [-] | | 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. |
|
| |
| ▲ | Someone 3 days ago | parent | prev | next [-] | | 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. | | |
| ▲ | JdeBP 3 days ago | parent | next [-] | | There was no self-modifying code. BBC BASIC was in ROM. | | |
| ▲ | classichasclass 3 days ago | parent [-] | | 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. | | |
| ▲ | JdeBP 3 days ago | parent [-] | | 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. (-: | | |
| ▲ | classichasclass 3 days ago | parent [-] | | 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. |
|
|
| |
| ▲ | klelatti 3 days ago | parent | prev [-] | | The interpreter is doing a lot that you’ve not mentioned here; parsing the BASIC source code for example. | | |
| ▲ | guenthert 3 days ago | parent | next [-] | | 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 3 days ago | parent [-] | | 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_ 3 days ago | parent | prev [-] | | 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. |
|
| |
| ▲ | pjmlp 3 days ago | parent | prev [-] | | 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 3 days ago | parent [-] | | 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 3 days ago | parent [-] | | 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. |
|
|
|
