Relearning MSX

That's great, I strongly believe that C is a fine language for developing applications for MSX in the many cases where you don't need the top processing speed that direct assembler provides (and it is very easy to mix assembler and C anyway). I do cross development using sdcc, but developing directly in the MSX is fun too and these articles are comprehensive and thorough. Good work!

The simplest tool that I have developed in C is probably geturl, it is small and it doesn't have any dependencies on UNAPI.

Can you post the code in order to take a look at it?

I did a quick test with MSX-C and the results match yours. I wrote your Pascal benchmark like this:

BENCH.C

#include <stdio.h>

char    main(argc, argv)
int     argc;
char    *argv[];
{
        int     i, j, s;

        s = 0;

        for (i = 1; 1 <= 10000; i++) 
                for (j = 1; j <= 100; j++)
                        s++;

        printf("%u", s);
}

This program ran in 41.95 seconds in Z80 mode and 6.32 seconds in R800 DRAM mode.

However, the inner loop doesn't need to use a 16-bit variable, so we can declare it as char:

BENCH2.C

#include <stdio.h>

char    main(argc, argv)
int     argc;
char    *argv[];
{
        int     i, s;
        char    j;

        s = 0;

        for (i = 1; 1 <= 10000; i++) 
                for (j = 1; j <= 100; j++)
                        s++;

        printf("%u", s);
}

This version runs in 15.35 seconds in Z80 mode and 2.63 seconds in R800 DRAM mode.

See this in action in this video:

https://www.youtube.com/watch?v=bEaFk6WYZRs

In any case, I still believe that under normal conditions MSX-C will be faster (or at least comparable) to SDCC because of the way it handles function calls: MSX-C passes as many parameters as possible via CPU registers, while SDCC always uses the stack. C programs are mostly calls to functions, so I think this is relevant.

Could you please prepare another benchmark that uses functions so we can compare?

I've prepared a simple benchmark to test function calls. This is the code:

#include <stdio.h>

#define void    char;

typedef unsigned u_int;

u_int   sum(a, b)
u_int   a;
u_int   b;
{
        return ((a << 1) + (b >> 1));
}

u_int   shift3(a)
u_int   a;
{
        return (a << 3);
}

void    count(add)
u_int   *add;
{
        (*add)++;
}

char    main(argc, argv)
int     argc;
char    *argv[];
{
        u_int   i, val, counter, result;

        /* Init */
        val = 2000;
        counter = 0;
        result = 0;

        /* Loop */
        for (i = 1000; i < 60000; i++) {
                count(&counter);
                val = shift3(val);
                result = sum(i, val);
        }

        printf("Counter: %u\n", counter);
        printf("Result : %u\n", result);
}

Compiled with openMSX this code runs in 2,8 seconds in R800 DRAM mode and 15,90 seconds in Z80 mode. Can you please try the same with SDCC?

Here's the video showing the compilation and results under openMSX:

https://www.youtube.com/watch?v=nbA08FDMPFw

Interesting. And probably the difference we saw in the first benchmark we did was the result of SDCC's optimization. It probably noticed that the loop counter could be an 8-bit valus instead of 16. We could tell if we look at the binary.

MSX-C was released before ANSI C and it only understands K&R syntax.

It's one of my pet peeves. K&R C doesn't have the void type.I think void is nice because it helps you understand that a function doesn't return anything. Since the type doesn't exist in this version of C I just typedef it to be equivalent to char. It doesn't serve any purpose other than making the code look a bit nicer.

That's amazing! Thanks for sending the files. I'll see what differences there are between the two assembler files.

Did you use the MSX-DOS version of HiTech C, or the cross-compiler?

unfortunately all functions have code at least and here sdcc is faster than msx-c. a lot
i think sdcc does a better job in code generation. can we compare the assembly code generated for the "body" of a function?
( a function with a decent cyclomatic complexity not a simple for cycle on char variable)

This was a great series of articles. Too bad the author does not write new articles anymore...