25 Apr
2024
25 Apr
'24
9:43 a.m.
Hi,
As some of you may recall, a few years ago I asked for assistance
reading a 9 track tape containing IBM S/360 source for Martinus
Veltman's computer algebra program, Schoonschip
(https://en.wikipedia.org/wiki/Schoonschip). With Chuck's assistance,
we recovered all the code from the tape. After working with the
principals involved, I am pleased to announce that the source code is
now publicly available at:
https://vsys.physics.lsa.umich.edu/
Actually, I was always more interested in the original CDC 6600 source
code, as that is the more historically significant code. While that
was not contained on the 9 track tape, I did receive a copy from the
Veltman family, and that is also available from the above website.
I have limited experience with big iron, but I had very good success
getting Schoonschip compiled and running on dtCyber. Veltman also
provided example Schoonschip programs (YNGLING), and as far as I can
tell they run perfectly in CDC Schoonschip on dtCyber. However, I
have not been fully successful in getting IBM Schoonschip to run on
hercules under OS/360 MVT. The main issue I had was that the Fortran
part of Schoonschip uses REAL*16, which apparently requires the H
extended Fortran compiler that does not seem to be freely available.
I did patch the Fortran code to avoid extended precision and managed
to get Schoonschip running, but it would sometimes crash on some input
files. I do not know if that is a problem with my patches or an
actual bug in the original code (as the IBM version of Schoonschip was
still a work in progress at the time development stopped).
In any case, anyone who is interested is welcome to have their own go
at the code. The third evolution of Schoonschip (m68k code, which was
written after Veltman came to the University of Michigan) is also
available at the same website.
- jim
--
James T. Liu, Professor of Physics
3409 Randall Laboratory, 450 Church Street, Ann Arbor, MI 48109-1040
Tel: 734 763-4314 Fax: 734 763-2213 Email: jimliu(a)umich.edu
25 Apr
25 Apr
9:53 a.m.
On Apr 25, 2024, at 9:43 AM, James Liu via cctalk
<cctalk(a)classiccmp.org> wrote:
Hi,
As some of you may recall, a few years ago I asked for assistance
reading a 9 track tape containing IBM S/360 source for Martinus
Veltman's computer algebra program, Schoonschip
(https://en.wikipedia.org/wiki/Schoonschip). With Chuck's assistance,
we recovered all the code from the tape. After working with the
principals involved, I am pleased to announce that the source code is
now publicly available at:
https://vsys.physics.lsa.umich.edu/
Neat. I vaguely remember that program name from long ago, though I haven't used it.
(Part of why it's familiar is that it's a nice Dutch word hard to pronounce for
most others... :-) )
I wonder how difficult it would be to port to a present-day compiler like gfortran.
paul
10:17 a.m.
On Thu, Apr 25, 2024 at 9:54 AM Paul Koning via cctalk
<cctalk(a)classiccmp.org> wrote:
Neat. I vaguely remember that program name from long ago, though I haven't used it.
(Part of why it's familiar is that it's a nice Dutch word hard to pronounce for
most others... :-) )
Done on purpose of course :-)
I wonder how difficult it would be to port to a
present-day compiler like gfortran.
I think the code is mostly interesting for historical reasons. It was
originally written mostly in COMPASS assembly with the Fortran
handling input/output sort of stuff and then translated (in a somewhat
unusual manner) into IBM BAL by Hugo Strubbe. Later, when Tini
realized that the CDC mainframes were on their way out, he ported
Schoonschip to m68k assembly. In fact, he wrote his own m68k
toolchain (ie assembler and linker) in order to do so!
Tini Veltman is probably best known for his work on dimensional
regularization and the Standard Model which led to his Nobel Prize.
However, he also had a computing side to him. Of course, he had his
own way of doing things .. like not trusting any high level languages.
He was apparently quite proud of optimizing his code for the CDC 6600.
But tying Schoonschip to the bare metal is probably one of the main
reasons it hasn't survived beyond an important historical milestone.
- jim
--
James T. Liu, Professor of Physics
3409 Randall Laboratory, 450 Church Street, Ann Arbor, MI 48109-1040
Tel: 734 763-4314 Fax: 734 763-2213 Email: jimliu(a)umich.edu
4:27 p.m.
Looking at the webpage for the CDC version, I noticed the comment about SB0 B0 vs. NO and
the "lore" about the divide unit. That issue is reported in Thornton's
book. It wouldn't surprise me if it were a real issue on the "preproduction
serial number 3" system where that code was first created.
It clearly was fixed soon after, though. In the 6600 block diagrams manual where the flow
of the execution machinery is documented in detail, it's quite clear that NO does not
do any functional unit reservations (but SB0 does). So at least starting with serial
number 8, and possibly on earlier machines after suitable FCOs were applied, NO is indeed
the preferred pass instruction. On the other hand, 30 bit pass has by convention been
done with SB0 B0+0, suggesting it's faster to do that than to do two NO instructions.
I guess that's right in the absence of increment unit conflicts: 3 minor cycles for
the SB0 vs. 4 for the pair of NO instructions.
paul
26 Apr
26 Apr
12:49 p.m.
On Apr 25, 2024, at 4:27 PM, Paul Koning via cctalk
<cctalk(a)classiccmp.org> wrote:
Looking at the webpage for the CDC version, I noticed the comment about SB0 B0 vs. NO and
the "lore" about the divide unit. That issue is reported in Thornton's
book. It wouldn't surprise me if it were a real issue on the "preproduction
serial number 3" system where that code was first created.
It clearly was fixed soon after, though. In the 6600 block diagrams manual where the
flow of the execution machinery is documented in detail, it's quite clear that NO does
not do any functional unit reservations (but SB0 does). So at least starting with serial
number 8, and possibly on earlier machines after suitable FCOs were applied, NO is indeed
the preferred pass instruction. On the other hand, 30 bit pass has by convention been
done with SB0 B0+0, suggesting it's faster to do that than to do two NO instructions.
I guess that's right in the absence of increment unit conflicts: 3 minor cycles for
the SB0 vs. 4 for the pair of NO instructions.
paul
Thinking about the NO instruction: it sure seems odd that it takes 3 cycles given that it
doesn't reserve anything. You'd think it would just take up an issue cycle but
nothing else, i.e., 1 minor cycle total. If that were the case then two NO instructions
would be the correct way to do 30 bit padding.
Curious. Something to look at some day.
paul
447
days inactive
448
days old
4 comments
2 participants
participants (2)
-
James Liu -
Paul Koning