Officially, the Z80 single board computer from CPUville has a 1.8432 MHz crystal clock. Compare that to a modern PC running multi-megahertz clocks and it’s pretty slow indeed. But sometimes the real test is in running ‘real programs’.

As stated in prior posts, I’ve been playing with PL/I on my Z80 single board computer under CP/M 2.2, and I love it. PL/I is turning out to be the amazing and fun language I learned back in 1980, and it’s a blast. One thing I really love about PL/I is the total control over output, done easily with output formatting capabilities, plus the really great error handling.

I had an obscure bug in my latest program; a multi-phase concentration-with-time program from my Engineering graduate days. It would not run on one of the numerous test data sets, instead crashing immediately with ‘Error 3’. Looking up the error, it says: ‘A transcendental function argument is out of-range.’ Some help. However, transcendental functions include exponentiation, and the program had just such a line. Typical debugging means putting in a bunch of print statements and then wading through reams of output to try and trace the problem.

In PL/I, you can use the ‘on’ construct to trap errors. So by adding a ‘on error(3) begin… end;’ I was able to immediately isolate the subroutine where the error occurred and yes, it was the exponentiation line. Now adding some print statements made sense, and I quickly found that in double-precision, squaring a negative number was causing the problem. Now squaring a negative number is legal (the result is positive), so I had to find a fix. Fortunately using the ‘abs’ function solved the problem for this case as no real data (i.e. fluid concentration) should be negative in the runs. With the problem fixed, time to run all the example cases.

All but one ran in decent time. But problem 10, which has 600 time steps, was still going after two days. With no console output, I wasn’t sure if the program had crashed or was just taking a long time.

A few more print statements (with a debug flag to turn them off later), and a stopwatch, and I found this particular run was taking 6.44 seconds per time step. With 600 time steps in the run, that’s 4040 seconds or 67.3 hours (2.8 days!). No wonder I thought it was taking a while.

So about slowness… when I was wondering if the run was ‘broken’ or not, I ran the test case on my Win7 PC (in FORTRAN, but close enough). It was so fast you could not really time it. Let’s say for argument sake it took 1 second. That makes the Z80 4040 TIMES SLOWER!

Oh well, this is all about fun, so waiting for the full run on the Z80 will be something to wait for. Until next time…