In my last post I talked about Pl/I programming, which I’ve again fallen in love with, and the speed of my small engineering programs on my Z80 single board computer compared to a modern PC.

I was actually incorrect in my last post – the program is not 4000 times slower than a PC. In fact, the PC version was so quick one could not really time it by hand. There are tools on Unix boxes to time program execution, but I didn’t use them. However, a more realistic estimate of the larger data set would be about 1/2 second, not 1 second. That means my little Z80 program was 4000 x 2 or 8000 time slower (at least).

But something else about that program has been bothering me for the past few days. I mentioned in my last post how the ‘exp’ (or ‘**’) operation had a bug that prevented the double precision version working with negative numbers. Normally, there’s no problem – for example square -2 and you get +4. Cube -2 and you get -8. It’s all just serial multiplication, so it bothered me that it was not working. My fix was to add ‘abs’ before the term to remove any negative value; that worked, but I wasn’t happy with the fix as it wasn’t ‘totally correct’ from an aesthetic standpoint.

The solution was to return to my programming roots. Back in the early 1980’s I worked writing Reservoir Simulation programs. These huge FORTRAN programs could consume every calculation cycle of very, very large computers. Optimization beyond what a compiler was capable of became essential. There were many tricks we used to squeeze every bit of performance out of such programs.

One technique involved removing subroutine calls when possible by ‘in lining’ code. It’s ugly, and counter to all ‘structured programming’ rules, but it does work. Another technique analyzed operations; division is much more ‘expensive’ (in CPU cycles) than multiplication, with addition being about the cheapest. Loops have set-up time, so ‘unrolling’ loops might also be done in simple cases.

My analysis of this particular PL/I program showed the line with the error in it had multiplication, division, and that exponentiation. Now I added a call to the ‘abs’ function. I knew there was a way to fix both and make it run faster… convert ‘exp’ (or ‘**’) into serial multiplication and remove the ‘abs’ call. It would not only fix the negative value error (multiply always works) but remove two function calls and their related overhead (push stack, pop stack).

I decided to write a new function ‘doexp()’ which used a loop to perform the serial multiplication. I knew I was adding the overhead of a new function, but removing two function calls and a (supposed) complex general-purpose exponentiation routine. It won’t work for fractional exponents, but this program was always limited to whole number exponents anyway.

The new function coded, I tried the smaller data sets. All reported a roughly 1.5 time speed improvement. I then ran the big data set, and early timing of the time steps shows it’s running 2 times faster than the original program. The entire job, which would have taken 2.8 days, will now run in 1.4 days. For program tuning, this is a huge improvement.

As the post title says, it matters to me. It was also great fun to see it work.

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…

I’ve already posted about the fun I’m having with the Z80 singleboard computer (kit from CPUville) recently.

In addition to a FORTRAN compiler (Microsoft F80), I added the High Tech C compiler. I’ve written programs in FORTRAN, C and 8080 Assembler. I’ve used both the CP/M 2.2 ASM assembler and the M80 assembler that came with the F80 compiler. Except for one instance where my port reading assembly program won’t actually read the port, it’s been fun and games.

I’ve even created assembler programs that can be called from FORTRAN (the aforementioned port reading routine).

Last week, while exploring the various archives of CP/M software, especially compilers, I spied the DEC PL/I compiler. That looked really promising.

Back at my first job after my B.Sc., I worked at an IBM shop that sent me on a PL/I course. Afterward I spent the next year writing software in PL/I for a pair of IBM 3033 mainframes. It was all great fun.

Finding a working PL/I compiler was too good to pass up, so I grabbed the archive and beamed them to the Z80. After a bit of digging, I found my 1980 PL/I reference book, “PL/I Structured Programming” by Joan K. Hughes (2nd edition, Wiley, 1973). After reading through it to refresh my memory, I started building a few PL/I programs, following the examples in the book and then the chapter problems.

Some features of the IBM compiler were not available in the DEC (CP/M) version, but I had the DEC PL/I documentation to help me with the transition. Eventually I had written several working PL/I programs.

The past few days I’ve been playing with a Taylor series program for calculating Sin(x) (x in radians). I have the program working, but the answers diverge from ‘actual’ values in the range PI to 2PI. I had full debugging in the code, but could not really see the reason.

I decided to try converting the PL/I program to C, and then running it on a modern C compiler on one of my Ubuntu 18.04 servers.

SURPRISE!!! The C program has the exact same divergence! Even switching from ‘float’ to ‘double’ didn’t remove the divergence in the C program on a modern machine. I’ll definitely have to investigate further.

Just for fun I then took the working C program and beamed the code over to the Z80. The High Tech C compiler is sound, so it compiled the program easily. The run on the Z80 gave the exact same answers (with a small nod to precision on various platforms) as both the C/Linux version and the PL/I CP/M version. It’s either a really difficult to find coding mistake in my work, or a real phenomenon. As I said, I’ll have to investigate.

Where it all gets cute is timings. On the Linux box (big AMD 6-core server with loads of memory) the C program runs so fast it would be timed in milliseconds were I to try. Certainly faster than one could manually time it. The PL/I program on the Z80 takes 3min, 40.15 seconds to run. What was a surprise is the C program on the Z80 took 5min, 34.40 seconds! I never expected a C program to be that much slower than the PL/I program.

Now that I have FORTRAN, PL/I, C and Assembler all working, time to continue playing.

One last thing: I found a printing “bug” in the PL/I textbook. The formula for the Sin(x) Taylor series has two major errors. First, the terms have a denominator that is (2n+1)! (factorial), or 3!, 5!, 7!, 9! in the expanded formula found in the book. But some typesetter must have thought that an error, as the book has replace the ! with 1, giving denominators of 31, 51, 71 and 91. Not a small error when you are coding!. The other error is the terms alternate in sign (-1**n) so x-a+b-c+d and so on. The book had all + signs.

When debugging the massively incorrect results, I simply did a google search on ‘series solution of sin(x)’ and found the correct formula, then coded that. It is that corrected formula that still diverges from actual results for values of ‘x’ greater than PI.

During the Christmas break I built the CPUville Z80 single board, plus the ‘slow board’ which is really a really nice ‘blinkenlights’ display board for the Z80 single board. That was a fun build.

I also built the CPUville 8-bit computer (3 boards) plus register display board and added that to a separately built Z80 single board (with Z80 replaced by the 8-bit boards). That was also a fun build.

But the real fun began with the Z80 single board once I added an IDE 40-pin to CF (compact flash) controller board with a 4+ GB CF card. Following the CPUville instructions, I was able to modify/compile/install CPM 2.2 on the CF card giving me 4 large “hard disk” CP/M partitions.

THEN… I started playing. After reading a few CP/M manuals, I began to learn my way around the system. ED was perhaps the hardest to learn, only because the first manual neglected to mention that the display buffer was NOT filled ‘on entry’. One has to type ‘#A’ to load it with the file contents before you can see/edit anything.

I started with a few Z80 (or 8080) assembler programs, then found and loaded FORTRAN (F80). I then spent days playing with my FORTRAN programs that I wrote in the 1980’s during my Engineering degree and post-grad courses. Interestingly, they compiled and linked easier than when I tried them on the PiDP8 replica I built several years ago. The version of FORTRAN in F80 was just a bit more modern than the FORTRAN IV on the PiDP8, making things much easier and more fun.

Last week I found an loaded High Tech C compiler on the Z80. I compiled a few C programs from my earlier C programming days, as well as a few versions of the “calculate PI to N digits” programs. Again, tons of fun.

The interesting bits came trying to install the C compiler. It’s a lot of files, and when I tried loading them individually via “PCGET”, they crashed the terminal program. Seeking a better solution, I tried LZH unpack programs (didn’t work on modern LZH files), and eventually found that using modern WINZIP and an old CP/M UNZIP18.COM program, I was able to load whole groups of files to the Z80 and then unzip them in place. The only condition is that the CP/M unzip does not understand ‘modern’ zip methods, so you must zip them on the PC (Windows 7 in my case) with NO COMPRESSION.

The other ‘gotcha’ I discovered tonight is that you must be sure the ZIP files are named in CAPITAL letters. If you unzip lowercase named files on the Z80, they remain lowercase and kind of ‘disappear’ to CP/M. I could not even delete them until I asked on the ‘comp.os.cpm’ google group and was told about NSWEEP (or NSWP.COM). That program was able to delete them easily. I then rebuilt the zip with uppercase file names and it was fine.

So onward and upward with this wonderful true Z80 computer running CP/M 2.2, with FORTRAN, C and 8080/Z80 assembler.