![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Slightly cooler
Jul. 21st, 2011 09:19 pmThe heat warning has been withdrawn for anyone north of Joliet or thereabouts. We've made it down to 79 degrees in fact, though it's going back up to the high 80s tomorrow and the 90s on the weekend again.
Today was also a half day, as usual, which helps somewhat to make up for the horrors of Wednesday. I also found the oddity that was making my test C program misfire, so as of this morning it works. One problem was an oversight on my part as I converted the algorithm from my original Fortran 77 code. I forgot to subtract from one at a certain place in the code. Putting that back made the program work correctly when compiled by gcc on Linux. So I happily imported it back into the TRS-80 model 4 emulation where this odyssey started. It compiled, but the numeric results were worse than ever. Now I had identical source code that worked with gcc but failed with MC. I narrowed it down to either the sqrt() or the pow() function, and wrote a test program to try them with various values and report the results. It was pow(). Though the documentation for the function rather vaguely seems to promise that it will accept any valid numeric values and return a double precision floating point, in fact it stumbles in MC if one of the values is passed in as an integer. So for instance, 2.02 if expressed as pow(2.0,2) was returning 1.000000... while given as pow(2.0,2.0) was returning the correct value of 4.000000... At least it was easy to fix, and make a note on the appropriate page in the language reference.
The test code, which was written to determine the speed, dynamic range, and precision of a Fortran compiler, does the same for a C compiler. Both the Fortran and the C version run on Linux (gfortran and gcc respectively) in a fraction of a second to produce the same results. My Alphas are a bit slower at that level of precision, but can go to almost double the level of precision (taking even longer, though.) An emulated VAX is quite a bit slower than my Pentium 4 (10 minutes or so compared to a second or two) and produces much the same results. Going back to the TRS-80, which is a Z80A at 4MHz (yes, MHz, not GHz and only an 8-bit processor) is even slower as you would expect. It achieves the same precision as the P4 under Linux, but needs 70 minutes to complete the calculations. It's a tribute to the authors of the LS-DOS operating system and MC compiler though. They were doing very well back in 1985. At that time, I received my first desktop PC for use at work, replacing an IBM 3279 terminal. I promptly ran some benchmarks of my own design on the IBM PC, the VAX 8200, and my TRS-80 model 4P. The VAX won, of course, but the IBM PC (8088 at that time, and I believe the clock speed was 16MHz) was a draw against the 4MHz Z80A in the TRS-80. Each was slightly ahead at some tasks and slightly behind at others, but the Z80A made a darned good showing. I later "hot-rodded" that machine by replacing the CPU with a Hitachi 64180 (I think that was the right designation) that featured additional instructions and banked and cached memory. It wasn't a whole lot faster, but the extra features were usable on the LS-DOS system, making it quite a powerful working environment. More than once I expressed a wish that I could have the Model 4P at work instead of the IBM.
Guess it's bed time. We need to do chores early tomorrow so Gary can get to a rehearsal by 9 am. And I need to remember to take an alternate route to work. Pavement resurfacing is making a major snarl on US14 now, something that is very unusual around here.
Today was also a half day, as usual, which helps somewhat to make up for the horrors of Wednesday. I also found the oddity that was making my test C program misfire, so as of this morning it works. One problem was an oversight on my part as I converted the algorithm from my original Fortran 77 code. I forgot to subtract from one at a certain place in the code. Putting that back made the program work correctly when compiled by gcc on Linux. So I happily imported it back into the TRS-80 model 4 emulation where this odyssey started. It compiled, but the numeric results were worse than ever. Now I had identical source code that worked with gcc but failed with MC. I narrowed it down to either the sqrt() or the pow() function, and wrote a test program to try them with various values and report the results. It was pow(). Though the documentation for the function rather vaguely seems to promise that it will accept any valid numeric values and return a double precision floating point, in fact it stumbles in MC if one of the values is passed in as an integer. So for instance, 2.02 if expressed as pow(2.0,2) was returning 1.000000... while given as pow(2.0,2.0) was returning the correct value of 4.000000... At least it was easy to fix, and make a note on the appropriate page in the language reference.
The test code, which was written to determine the speed, dynamic range, and precision of a Fortran compiler, does the same for a C compiler. Both the Fortran and the C version run on Linux (gfortran and gcc respectively) in a fraction of a second to produce the same results. My Alphas are a bit slower at that level of precision, but can go to almost double the level of precision (taking even longer, though.) An emulated VAX is quite a bit slower than my Pentium 4 (10 minutes or so compared to a second or two) and produces much the same results. Going back to the TRS-80, which is a Z80A at 4MHz (yes, MHz, not GHz and only an 8-bit processor) is even slower as you would expect. It achieves the same precision as the P4 under Linux, but needs 70 minutes to complete the calculations. It's a tribute to the authors of the LS-DOS operating system and MC compiler though. They were doing very well back in 1985. At that time, I received my first desktop PC for use at work, replacing an IBM 3279 terminal. I promptly ran some benchmarks of my own design on the IBM PC, the VAX 8200, and my TRS-80 model 4P. The VAX won, of course, but the IBM PC (8088 at that time, and I believe the clock speed was 16MHz) was a draw against the 4MHz Z80A in the TRS-80. Each was slightly ahead at some tasks and slightly behind at others, but the Z80A made a darned good showing. I later "hot-rodded" that machine by replacing the CPU with a Hitachi 64180 (I think that was the right designation) that featured additional instructions and banked and cached memory. It wasn't a whole lot faster, but the extra features were usable on the LS-DOS system, making it quite a powerful working environment. More than once I expressed a wish that I could have the Model 4P at work instead of the IBM.
Guess it's bed time. We need to do chores early tomorrow so Gary can get to a rehearsal by 9 am. And I need to remember to take an alternate route to work. Pavement resurfacing is making a major snarl on US14 now, something that is very unusual around here.
