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
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
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
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
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