Close

Benchmarking SPAM-1 using Mandelbrot

A project log for SPAM-1 - 8 Bit CPU

8 Bit CPU in 7400 with full Verilog simulator and toolchain

john-lonerganJohn Lonergan 07/14/2022 at 16:463 Comments

I've been wondering about how one homebrew CPU arch compares to another. How the memory addressing modes contribute, or which ALU ops are worth implementing or Harvards vs VN.

Anyway I came across Matt Heffernan's 8 Bit Battle Royale channel where he discusses multiple popular commercial machines and I decided it would be interesting to see how SPAM-1 stacks up.

The first step is to figure out how to do 16 bit fractional arithmetic on an 8 bit CPU like SPAM-1 that has no concept of floating point or even 16 bits. In the video Matt mentions using fixed point integer arithmetic and then presents an assembly language impl of mMandelbrot, but that's too far too fast for me to learn from.

So I wrote my own "C" fixed point integer impl of mandelbrot using "8.8" encoding in 16 bits which I should be able to translate to my existing SpamCC compiler and which I should also be able to code in SPAM-1 assembly for speed comparison purposes. I wrote it in 'C' because I want to quickly understand the "8.8" arithmetic and because I expect GCC to be bug free, unlike SpamCC.

The Fixed point Integer implementation I came up with is at  https://github.com/Johnlon/mandelbrot   and there is also a line by line equivalent floating point impl for comparison and learning purposes.

I'll see if I can get SpamCC to implement the same thing. I pretty much expect this to show up a bug in the SpamCC compiler - but then that's a good thing.

.........,,,,,,,,,,,,,,,,,,,,,,,
........,,,,,,,,,,,,,,,,,,,,,,,,
.......,,,,''''''''''',,,,,,,,,,
......,,,'''''''~~=<=~'',,,,,,,,
.....,,'''''''~~~=+[<+~~'',,,,,,
....,,'''''''~~~=+/  ;==~'',,,,,
....,''''''~~~=x/o&  /;:/~'',,,,
...,''''''~===+[        /=''',,,
...''''~= ++::/         /+~''',,
...'~~~=+[ X /           +~''',,
...~~~+:/o               =~''',,
...                     :=~''',,
...~~~++/?               =~''',,
...'~~~=+;   <           +~''',,
...''''~=&::::/         <+~''',,
...,''''''~===+/        /=''',,,
....,''''''~~~= / &  ?[:&~'',,,,
....,,'''''''~~~=+/  [==~'',,,,,
.....,,'''''''~~~=+[<+~~'',,,,,,
......,,,'''''''~~=&=~~',,,,,,,,
.......,,,,''''''''''',,,,,,,,,,
........,,,,,,,,,,,,,,,,,,,,,,,,

Discussions

John Lonergan wrote 07/24/2022 at 12:54 point

Yeah as a measure of CPU perf excl Graphics

In the Matt Heffernan vids he didn't optimise ASM for each CPU until a partial attempt in last video. 

I think any useful comparison must be optimised for the CPU features, isn't that the point.

  Are you sure? yes | no

kaimac wrote 07/24/2022 at 21:46 point

A lot of these benchmarks were designed to test how fast the system's BASIC was, I think. But if you're writing assembly, yeah, you might as well optimise it as much as you can.

I'd like to give this Mandelbrot program a go, if I can get my head around this fixed point stuff

  Are you sure? yes | no

kaimac wrote 07/24/2022 at 12:28 point

There's also the Byte sieve - I found this article which has a big table of results for lots of different machines and languages, including C and assembly.

https://archive.org/details/byte-magazine-1983-01/page/n291/mode/2up

  Are you sure? yes | no