Benchmarking
8 views
Skip to first unread message
Michael Thompson
Aug 7, 2017, 9:05:39 AM8/7/17
to PDP-12 Restoration Project
I found this WWW page: http://www.roylongbottom.org.uk/whetstone.htm
It includes PDP-8/I and PDP-8/e Whetstone benchmarks, so someone managed to get it to run on a PDP-8.
Our PDP-12 has EAE, but no hardware floating point, yours probably has EAE too. Our 8/I has no EAE or floating point. My 8/e has no EAE or floating point installed, but I do have two sets of EAE boards that need to be repaired.
If you can get the Whetstone benchmarks to compile for the PDP-8 I can run it on the systems that I have access to, and I am sure that we can get plenty of volunteers to run it on other systems. It would be interesting to find someone who has a working floating point processor for the 8/I or 8/a and see what different it makes in the benchmarks.
You can create an RK05 image with the benchmark source code, compilers, and compiled code, and post it on you blog site.
--
Michael Thompson
Dawson Rosell
Aug 7, 2017, 12:01:06 PM8/7/17
to Michael Thompson, PDP-12 Restoration Project
Awesome! I am having problems getting the ALGOL compiler to work on the PDP-12, so I think I will just write a Fortran version and make an image with that version on it. I found source code for ALGOL 60 and Fortran 90. So with those two I will be able to write a Fortran IV version.
It looks like it was originally run in Fortran on the PDPs, meaning there had to have been a Fortran IV version of the source...which I haven't been able to find yet.
Michael Thompson
Aug 7, 2017, 12:29:29 PM8/7/17
to Dawson Rosell, PDP-12 Restoration Project
If I have a few minutes I will see if I can get Algol to work.
It would also be interesting to benchmark a simulated PDP-8 under SIMH.
I think that Doug has a floating point processor for his PDP-8/a.
It would be interesting to see how much difference that makes.
--
You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.
Michael Thompson
Michael Thompson
Aug 9, 2017, 8:23:35 AM8/9/17
to Dawson Rosell, PDP-12 Restoration Project
Dawson,
The file decus-8-213_6-pb is the compiler. Using SIMH I can get it to run and display the OPT- prompt. I attached an example ALGOL program to the paper tape reader, and entered "R" to get it to compile. It runs forever, and sometimes generates a "compiled" file that just contains 0x80 leader characters.
Have you had any more success than that?
On Mon, Aug 7, 2017 at 12:01 PM, Dawson Rosell <rose...@d.umn.edu> wrote:
--
You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.
Michael Thompson
Michael Thompson
Aug 10, 2017, 8:12:31 PM8/10/17
to Dawson Rosell, PDP-12 Restoration Project
Did you already find this document and FORTRAN files?
On Mon, Aug 7, 2017 at 12:01 PM, Dawson Rosell <rose...@d.umn.edu> wrote:
--
You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.
Michael Thompson
CLASystems
Aug 11, 2017, 12:56:30 AM8/11/17
to Michael Thompson, Dawson Rosell, PDP-12 Restoration Project
The Fortran IV run-time system doesn't really use the EAE when simulating the FPP-12/FPP-8/A hardware in the runtime system, but it does take advantage of having the MQ. On the older machines, you get the MQ when you have EAE, but that is all they optimize for, etc.
Also, this does NOT work on the straight-8 or LINC-8. Why? Because only on those two, even having EAE, the SWP instruction does not work! You can do MQL and you can do MQA, but only on the 8/I and up can you do MQL!MQA and that makes the SWP function. The reason has been traced to the way the built-in 03/04 console interface "owns" some of the gates on the low-order 8-bits of the major registers. Thus, it's something like the SWP only works partially on the high-order 4 bits, but not so on the low-order 8 bits or something like that. In any case, this is the sore point about why some programs that need EAE cannot run on the straight PDP-8. It is notable that POLY SPACEWAR avoids the need, and in a couple of places the code is modestly longer/slower as a result.
On an unrelated matter, for the benefit of T?D8E support and assuming the reasonable assumption the TD8E is running on the PDP-8/E, I was trying to develop a smaller or faster or both .XOR. routine as part of the .EQU. checksum calculation. I recently found the code that does eliminate some overhead the DEC routines had because they failed to observe that the EQU is the one's complement of ,EQU. that can be done all at the end because you do a 12-bit calculation, and then at the end two halves are XORed to each other, etc. Each word cycle thus does not need a CMA coming in and another one before exiting, etc. A needless blunder, and I do not have to re derive the code, etc.
But the inner problem was this: Since we have the MQ and SWP etc., can we make the XOR smaller or faster? I tried and it flunked both ways! Yes, the MQ doesn't help either speed or size. I think the best I could do was the same length and a cycle SLOWER. Intuitively, this is not satisfying. I would like someone to corroborate this if possible, but the code the TD8E uses for all programming seems to be the best; there are I think two minor variations, but they are equal size and speed, so pick one. Either seems to be the best and the MQ cannot help.
But in many simulations, having the MQ is really handy, including an EAE simulator or subset theireof. This just doesn't happen to be one.
Just some food for thought regarding speed if you do not have the FPP hardware:
DEC purchases what is known as FORTRAN II from a third-party. First it was interfaced to the Disk Monitor System by a patch, and then Richard Lary did a similar hook set to make it work with OS/8. This is the compiler that produced SABR pseudo-assembler [it's almost, but not quite because it needs fixups and "threaded code" in spots, etc.].
Now, while Fortran II is not much of a language, there is a user package that makes it into FORTX at the compiler level. From what I have heard, FORTX is within a smidgen of Fortran IV and may have some extensions the DEC Fortran IV actually lacks. I believe somewhere the FORTX replacemente files are available [and I wouldn't mind having a copy of this regardless for my Ibiblio archive].
There is a reasonable chance that the compiled binary from FORTX source code will run FASTER than simulating the FPP-12 when you really don't have it. This may be a useful consideration as it is discussed here, etc.
Finally, MACREL was originally developed to be part of an "ultimate" Fortran IV assembler output much different from even SABR, not just the notion of what language, but the run-time would be even better with the realistic understanding of no FPP hardware emulated or real. There are arguments that the FPP hardware structure is sub-optimal but fixated to the format the hardware uses. By abandoning that restriction, a better Floating design can be done.
Also, this does NOT work on the straight-8 or LINC-8. Why? Because only on those two, even having EAE, the SWP instruction does not work! You can do MQL and you can do MQA, but only on the 8/I and up can you do MQL!MQA and that makes the SWP function. The reason has been traced to the way the built-in 03/04 console interface "owns" some of the gates on the low-order 8-bits of the major registers. Thus, it's something like the SWP only works partially on the high-order 4 bits, but not so on the low-order 8 bits or something like that. In any case, this is the sore point about why some programs that need EAE cannot run on the straight PDP-8. It is notable that POLY SPACEWAR avoids the need, and in a couple of places the code is modestly longer/slower as a result.
On an unrelated matter, for the benefit of T?D8E support and assuming the reasonable assumption the TD8E is running on the PDP-8/E, I was trying to develop a smaller or faster or both .XOR. routine as part of the .EQU. checksum calculation. I recently found the code that does eliminate some overhead the DEC routines had because they failed to observe that the EQU is the one's complement of ,EQU. that can be done all at the end because you do a 12-bit calculation, and then at the end two halves are XORed to each other, etc. Each word cycle thus does not need a CMA coming in and another one before exiting, etc. A needless blunder, and I do not have to re derive the code, etc.
But the inner problem was this: Since we have the MQ and SWP etc., can we make the XOR smaller or faster? I tried and it flunked both ways! Yes, the MQ doesn't help either speed or size. I think the best I could do was the same length and a cycle SLOWER. Intuitively, this is not satisfying. I would like someone to corroborate this if possible, but the code the TD8E uses for all programming seems to be the best; there are I think two minor variations, but they are equal size and speed, so pick one. Either seems to be the best and the MQ cannot help.
But in many simulations, having the MQ is really handy, including an EAE simulator or subset theireof. This just doesn't happen to be one.
Just some food for thought regarding speed if you do not have the FPP hardware:
DEC purchases what is known as FORTRAN II from a third-party. First it was interfaced to the Disk Monitor System by a patch, and then Richard Lary did a similar hook set to make it work with OS/8. This is the compiler that produced SABR pseudo-assembler [it's almost, but not quite because it needs fixups and "threaded code" in spots, etc.].
Now, while Fortran II is not much of a language, there is a user package that makes it into FORTX at the compiler level. From what I have heard, FORTX is within a smidgen of Fortran IV and may have some extensions the DEC Fortran IV actually lacks. I believe somewhere the FORTX replacemente files are available [and I wouldn't mind having a copy of this regardless for my Ibiblio archive].
There is a reasonable chance that the compiled binary from FORTX source code will run FASTER than simulating the FPP-12 when you really don't have it. This may be a useful consideration as it is discussed here, etc.
Finally, MACREL was originally developed to be part of an "ultimate" Fortran IV assembler output much different from even SABR, not just the notion of what language, but the run-time would be even better with the realistic understanding of no FPP hardware emulated or real. There are arguments that the FPP hardware structure is sub-optimal but fixated to the format the hardware uses. By abandoning that restriction, a better Floating design can be done.
Just in terms of stand-alone FPP packages and interpreters, there are multiple incompatible packages with different goals, more precision, less exponent range, etc. EAE uased or not, and the instruction set of the simulated package uses PDP-8 MRI type addressing or it does not. The package used in for example the 4K and 8K BASIC uses relative addressing which makes it interesting where storage goes relative to the routines that need it, etc. [Isn't that the way the Nova instructions work?]
I don't know where they were going, but the project was canned, and Stan Rabinowitz just kept playing with MACREL and used it to add features to the 16K TECO that internally swaps section using the old multiple .XOR. trick. [If you .XOR. three times, you have swapped two sets of data without using a temporary buffer!]. I think there were at least three 'swap segments" in 16K but a swap was the three XOR trick and no actual temp storage, etc.
Bottom line, XOR can be a good thing [or a very bad one[.
cjl
I don't know where they were going, but the project was canned, and Stan Rabinowitz just kept playing with MACREL and used it to add features to the 16K TECO that internally swaps section using the old multiple .XOR. trick. [If you .XOR. three times, you have swapped two sets of data without using a temporary buffer!]. I think there were at least three 'swap segments" in 16K but a swap was the three XOR trick and no actual temp storage, etc.
Bottom line, XOR can be a good thing [or a very bad one[.
cjl
"In the future, OS/2 will be on everyone's desktop"
Bill Gates, 1992
Bill Gates, 1992
Reply all
Reply to author
Forward
0 new messages