C Benchmarks

Super cool research project!

I guess these are more to measure the 'raw' speed of the code that these compilers generate.

What, in my experience, are more relevant questions are things such as these:

• What is faster, using chars (8 bits) or ints (16 bit)? (Can the compiler properly optimize function calls through registers?)
• Can the compiler optimize the usage of 'boolean' logic? (Reduce expression logic, use flag registers (also for function return values), etc).
• Which compiler generates the smallest executables (dead-code detection, optimization, etc).
• Which compiler is faster for random access in an array? (byte alignment, etc).
• Some old compilers date all the way back to CP/M, so do the actually compilers use the full range of available Z80 feature set (for example: index registers).
• Can the compiler generate code that uses memory page swapping for programs that are larger than 64Kb?

Would be awesome if we could deduce some good 'rule of thumbs' on how to write more efficient code for these compilers

games need code like this

#define T char
struct obj { T id; T x; T y; T vx; T vy; T anim; };

void moveturtles(struct obj **arr, unsigned char arrlen) {
        unsigned char i = 0;
        struct obj *p = 0;
        for(i = 0; i < arrlen; i++) {
                p = *arr++;
                //and then many ops like this:
                p->x = p->x + p->vx;
                p->y = p->y + p->vy;
                p->anim++;
        }
}

offsetted acess to always the same struct, needs no tricky register allocator.

        ld a,(ix+x) : add (ix+vx) : ld (ix+x),a
        ld a,(ix+y) : add (ix+vy) : ld (ix+y),a
        inc (ix+anim)

it would also be ok when the compiler uses HL and INC HL DEC HL forth and back.

        ld a,(hl) : inc hl : inc hl : add (hl) : dec hl : dec hl : ld (hl),a      ;p->x = p->x + p->vx;
        inc hl 
        ld a,(hl) : inc hl : inc hl : add (hl) : dec hl : dec hl : ld (hl),a      ;p->y = p->y + p->vy;
        inc hl : inc hl : inc hl
        inc (hl)

This looks like more code but is actualy less.

So, this is the z80 gamer benchmark.
any compiler who comes close to that asm?

#define T char
struct obj { T id; T x; T y; T vx; T vy; T anim; };

void moveturtles(struct obj **arr, unsigned char arrlen) {
        unsigned char i = 0;
        struct obj *p = 0;
        for(i = 0; i < arrlen; i++) {
                p = *arr++;
                //and then many ops like this:
                p->x = p->x + p->vx;
                p->y = p->y + p->vy;
                p->anim++;
        }
}

I'll look into this after the current benchmarks are done.

I'll point out that, in zx spectrum c games, the game engines themselves have subroutines that update the sprites so this part is often done in machine code (sprite manipulation tends to be more difficult as there is no hardware assist so more functionality tends to be built into the engine itself).

But another pattern is to have these structures allocated at global scope in a fixed size array to avoid referring to them through a pointer. The fixed size represents the maximum number of objects allowed, for which memory must be allocated anyway either statically or dynamically. Then those sprite members are accessed through direct memory addresses as in "ld hl,(spr0+offset_x)" etc. A flag can be used to indicate whether a particular sprite is active or not.

In a situation where there are multiple disjoint levels, overlaying is sometimes done so that the same memory is reused for a possibly varying set of sprite objects and level data. In z88dk, at least, this is done by creating individual sections for each level using the same ORG address and assigning to each any level/sprite specific data to the corresponding section. Then required level data for each level will overlap the same address range which solves memory issues brought about by allocating data for levels without overlap. If any level needs non-zero initialization it's normally handled by decompression at the start of the level.

Another approach is possibly to use an obstack to dynamically create needed objects and destroy all at the end of a level. It's a lightweight dynamic memory allocator with zero overhead and fast (wikipedia has a poor explanation, perhaps a better one in #3 of this comment). And then you have the same sort of code as you've shown since each sprite object is again referred to via pointer.

Someone volunteered with access to the commercial IAR compiler which is great. If I can get Zilog's ZDS to work and someone steps forward with a copy of Softools, the main commercial entities will be covered.

The idea is to use array access to compute a fixed address at compile time plus an offset determined by index at runtime.

Something like:
p->x = p->x + p->vx;

Would get turned into this:
sprite[i].x += sprite[i].vx;

The sprite.x and sprite.vx offsets can be computed at compile time so what is left is an offset i*sizeof(struct sprite) that is computed at runtime. If the loop is in terms of bytes (i+=sizeof(struct sprite) as the step size) then the multiplication is gone.

I'm not sure if this would lead to better code or not and it smacks of low level byte adjustment and casting which is not as natural as a pointer solution.

I've found a number of more standard benchmarks that I will include but this idea of a "gamer's benchmark" is a really good one given that that's mostly what people do with z80s these days.

If you have any other small snippets that may be useful to test, what I'd like to do is gather a collection of these short subroutines into kernels (read: subroutines) and run them from a driver (read: main()) which can be tested for speed and size. Emphasis can be placed on each kernel by selecting the number of times each kernel is executed according to how each kernel might be called in a typical game.

In the zx scene, there are a relatively large number of games written in c (I think about 40) but none of them are open source except for a few simple ones, with one exception being the full sized game Pietro Bros. A number of games are written with a particular game engine ("Churerra") which is open source though. I'll try to take a look at these sources and see if something can be extracted from them.

That is why I use programming tips, which are really needed when programming small 8-bit machines as I noticed.
In that case I always use a pointer, assign it and then use it for accessing. Instead "sprite[i]." create a *sprite, sprite = &sprite[i], and then "sprite->". You can also assign the first element of the array to *srpite and then do sprite++ on each loop.

Another tip is to use always unsigned arithmetic unless mandatory. As signed arithmetic is handled by C-runtime instead direct instructions. There is really no problem because we can operate in this way perfectly: 16-bit unsigned "-1" is 65535, if we add unsigned 10000 + 65535 = 9999 with overflow, so it is really as substracting 1.
C compilers allow to define them i.e. unsigned x = (unsigned)-1.