Retro (and new) Benchmarks on my Ruby816 board

[drogon]

For no real reasons I decided to run some benchmarks on my somewhat retro Ruby816 SBC computer. It’s a 65C816 CPU running in 8-bit mode with various BASICs and in 16-bit mode running a 32-bit VM to support BCPL. It runs at 16Mhz and has 512KB of RAM (only 64KB accessible in 8-bit mode though)

I was mostly interested in how much faster BCPL was. The result was that it is faster, but not always (bother).

I put together a blog post on my own site about it all, but I’ll put the results table here:

It wasn’t always easy to do some of them in floating point in BCPL, and I gave-up with the Byte Sieve one, but do note that 2 were slower in BCPL than in BBC Basic4…

There is a link to the source code on my blog posting for anyone who cares to look.

Which is here:

https://projects.drogon.net/retro-basic ... enchmarks/

Cheers,

-Gordon

[leepivonka]

Here are some FORTH entries for the list.
These were run on a 65816 simulator with a cycle counter that FORTH can read. The times reported are # of cycles divided by 16000000 to get seconds.
There is no math coprocessor used - the floating-point operations are all coded in 65816 using a 32 bit mantissa.
The FORTH is subroutine threaded with a cell size of 16bits.

Code: Select all

                        BBC Basic 4     Forth FP        Forth Int       BCPL Fp         BCPL Int

R/F1                    0.06            .043            .0012           .023            .023
R/F2                    0.26            .052            .0013           .188            .022
R/F3                    0.68            .288            .093            .551            .159
R/F4                    0.68            .140            .010            .577            .167
R/F5                    0.72            .141            .011            .595            .182
R/F6                    1.17            .345            .018            .709            .295
R/F7                    1.86            .527            .035            .798            .385
R/F8                    3.35            1.830           1.784           1.377           1.248
byte sieve              5.07            1.232           .080                            .647
noels retro lab         1.90            .772            .035            2.837           .363
prime cruncher          46.18           22.611          .157            53.980          6.252
mandelbrot              46.70           13.467          2.170           26.000          10.400

Attached are the console log files, edited to include annotations on the disassemblys of the FORTH words.

[GARTHWILSON]

drogon wrote:

It’s a 65C816 CPU running in 8-bit mode with various BASICs and in 16-bit mode running a 32-bit VM to support BCPL. It runs at 16Mhz and has 512KB of RAM (only 64KB accessible in 8-bit mode though)

Native mode gives access to all 16MB of memory map even with registers set to the 8-bit size.  Am I forgetting something?

[leepivonka]

I think Drogon means that the BASICs are written for 6502.
Without using the new 65816 instructions or addressing modes, code can only address bank 0 (64KBytes).
Using the new 65816 instructions & addressing modes, both emulation & native mode code can address all 16MBytes.

[GARTHWILSON]

You're right.  No need to even go into native mode.

[drogon]

GARTHWILSON wrote:

You're right.  No need to even go into native mode.

I tried to keep the system in native mode, dropping the registers to 8-bits when calling the old BASICs but the issue is that most of them fiddle with the stack pointer which breaks things, so I changed my OS which runs in native mode to drop into emulation mode when it calls a "ROM" then its up to the ROM to go back to native mode - if it needs to. This makes the BBC Basic ROMs run unchanged and while I could change EhBASIC and CBM Basic (we have the sources) I just couldn't be bothered.

Cheers,

-Gordon

[BigDumbDinosaur]

Register sizes are not “modes.” Modes are emulation and native. The 65C816 has the same personality in native mode regardless of register sizes.

Note that in emulation mode, it is still possible to use the B-accumulator as a data store via the XBA instruction. Also, TCD, TDC, TCS and TSC result in a 16-bit transfer in emulation mode, although manipulating the stack pointer in this fashion won’t affect the most significant byte.

[BigEd]

Just in case one had the time and energy and motivation, there's Acorn's BAS128 and John Kortink's 816 port of Acorn's Basic (4r32 plus fixes, I think) both of which arrange to make memory accesses into a separate 64k space. Unless perhaps John's allows for more than 64k. And then there's the (probably previously mentioned) port of Acorn's '816 Basic for the Communicator.

[drogon]

BigEd wrote:

Just in case one had the time and energy and motivation, there's Acorn's BAS128 and John Kortink's 816 port of Acorn's Basic (4r32 plus fixes, I think) both of which arrange to make memory accesses into a separate 64k space. Unless perhaps John's allows for more than 64k. And then there's the (probably previously mentioned) port of Acorn's '816 Basic for the Communicator.

The Acorn 816 thing is in Acorns MASM format and it might need some tools to convert it to something I can assemble elsewhere - unless I re-create the build environment - not sure which would take the least energy...

and I've not been able to find JKs sources online..

There was someone else working on an '816 Basic for the Foenix project but I think that stalled at some point, so maybe one day we'll get a nice portable BASIC for the '816, so who knows.

-Gordon

[rwiker]

The Foenix 816 Basic is here: https://github.com/pweingar/BASIC816

There's also the 816 Basic for the Acorn Communicator: https://github.com/dominicbeesley/CommunicatorBasic100

The Communicator Basic might be a good choice for Ruby! (I've looked briefly at it, thinking about porting it to the Foenix C256.)

[drogon]

rwiker wrote:

The Foenix 816 Basic is here: https://github.com/pweingar/BASIC816

Thanks - but last time I looked it was somewhat unusable - and now - the same:

Quote:

Current Status

The BASIC interpreter is in a very primitive (and unstable) state at the moment.

rwiker wrote:

There's also the 816 Basic for the Acorn Communicator: https://github.com/dominicbeesley/CommunicatorBasic100

The Communicator Basic might be a good choice for Ruby! (I've looked briefly at it, thinking about porting it to the Foenix C256.)

Ah. That's not one I was aware of - I'll have a look, thanks.

-Gordon

[Windfall]

BigEd wrote:

Just in case one had the time and energy and motivation, there's Acorn's BAS128 and John Kortink's 816 port of Acorn's Basic (4r32 plus fixes, I think) both of which arrange to make memory accesses into a separate 64k space. Unless perhaps John's allows for more than 64k.

It does. It basically gives all variables a 24 bit address, from 64 KB upwards.

[BigEd]

Ah, thanks!

[cjs]

FWIW, I started this gitlab.com/retroabandon/bascode repo quite a while back for, among other things, that infamous mandel.bas program of yours (drogon) on various computers and benchmark results of it. I've not done anything there in ages, but litwr has reguarly been committing updates, incuding some of Chromatix's floating point tests.

If anybody else feels they can contribute and wants access to throw stuff in there, just send me a PM.