FIGnition now has the new interpreter, written in Assembler! It can run at speeds comparable to a real, early 80s 8-bit CPU up to more than 340KIPs!
The Benchmarks are simple adaptations of the original BYTE / Personal Computer World Benchmarks (with the exception of the floating point tests). The benchmark tests are now attached.
An indication of the graphics performance is given below:
I make claims of up to >340 KIPS when none of the benchmarks report that figure. That's because loop itself is relatively slow at only 74KIPS (see bm1). Consider bm3L, it executes 9 simple instructions per loop + loop and does this 1000 times. So, the 9000 simple instructions take 0.04-0.014 = 0.026s, which is 346KIPs. Similarly, bm5-bm4 tells us that we can do 1000 call/returns in 0.028s, which means each call+return takes 28µs (equivalent to a 0.96MHz Z80). Pixel plotting takes 0.11s to do 2400 pixels, and since there's 2 simple instructions+loop: the remaining code takes: 2.4*(2*0.03/9+0.02) = 0.064s, leaving 0.036s for plotting 2400 pixels, that's 66KPixels/s (lower than the effective KIPS).
The upshot though is that FIGnition can achieve performances in the same ball-park as real 8-bit micros from the late 70s/early 80s. The challenge is SRAM access, which is terribly slow at 0.9µs/2.7µs (sequential/non-sequential). Against this FIGnition prefetches the next byte while processing the previous one; makes use of internal RAM; performs 16-bit arithmetic as standard and of course, implements much of the functionality (such as displaying text, graphics and memory moves) via its fast internal Flash. As a result a simple instruction execution cycle takes a little less than 30 AVR cycles (e.g. for and) which means 10.7MHz is used for the display, leaving 9.3MHz for user-code.
Since firmware 0.9.8 has been available, FIGnition supports a simple xor-based blitter which can move bitmaps at a rate of roughly 12622 tiles per second (or 252.44 tiles per 50Hz frame). Each move consists of two blit operations (one to erase an old bitmap and the other to blit a new bitmap). Let's compare this with, say a similar xor blitter for a VIC-20 operating with a bitmapped screen, ignoring colour RAM. In the assembly code provided on this page; a VIC-20 requires 50µs/scan + 41µs per extra column. So, a 16x16 pixel (4 tile) sprite requires: 1.641ms giving a simple blit rate of 2437 tiles per second, meaning that 1218tiles can be moved which is about 24.4 tiles per frame; about 10x slower than a FIGnition.
**(The KIPS calculations for bm2 to bm7 were incorrectly calculated here).