A project log for Targeting SDCC to the 8080

Writing a code generator for the 8080 microprocessor for Small Device C Compiler (SDCC)

Ken YapKen Yap 10/14/2019 at 00:312 Comments

This log may change as I understand better how it works.

Now we come to the key step which the backend must pass otherwise it's useless — checking that the code generated is correct. SDCC comes with a formidable suite of regression tests. The procedure is simple, compile a test program, run it in a simulator (sz80), and output messages for failing tests. The test programs look like this made up example:

i = 2;
if ((i + i) != 4)
  error("Failed add");

Of course a whole range of code from the simple up to the complex like pointer access is tested. A test harness runs all the tests and summarises the results. It should be automated so that continuous integration can check that a code change hasn't made things worse.

But how is error() implemented? We could make it equivalent to a printf(), but what if we aren't sure that we have a working printf()? The solution is to generate a trap instruction for the error() which is handled by the simulator and ensures that we always see output. Unless the program crashes, in which case the output won't match either.

As an aside, there are compiler options to output the original source lines and iCode as comments in the assembler code so when a test fails one can look at the generated code and work out what were the incorrect assumptions.

So TODO number 3 is to get the 8080 backend to pass the regression tests, and with various options. That sentence means a lot of iterated work!

That's the end of the logs for the moment. I just have to collect some round tuits, roll up my sleeves and work on the TODOs.


Thomas wrote 10/14/2019 at 17:19 point

uCsim provides several options for running tests. Traps are good but breakpoints might also work. In that case, however, you'd have to define breakpoints based on addresses from the linker output file.

  Are you sure? yes | no

Ken Yap wrote 10/14/2019 at 18:07 point

I think this is all already automatically set up by SDCC's test suite and one just has to say make tests or something like that, There are a ton of tests so it would be infeasible to interact directly with the simulator to set breakpoints.

But you reminded me to mention the compiler options to add the source and iCode as comments in the assembler code.

  Are you sure? yes | no