Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
IBM System /360 nostalgia
212 views
Skip to first unread message
robin....@gmail.com
Jul 19, 2012, 10:12:45 PM7/19/12
to
On Friday, 20 July 2012 04:03:43 UTC+10, John Levine wrote:
> On a 360/30, the MVC to move a 100 character field took 330us, or 355
> if it used EX to set the field length. Do a 20 of those for a 2K disk
> block and it's 6ms just to move the data, an appreciable fraction of
> the time to do the disk I/O. These days, moving that much data is
> probably under 50us, so who cares?
The model 30 was a small entry-level machine, and wasn't particularly fast.
Comparable figure for a first-generation machine (1955)
to move 100 characters took 512uS.
Model 40/44 and 50 timings were somewhat better.
> On a 360/30, the MVC to move a 100 character field took 330us, or 355
> if it used EX to set the field length. Do a 20 of those for a 2K disk
> block and it's 6ms just to move the data, an appreciable fraction of
> the time to do the disk I/O. These days, moving that much data is
> probably under 50us, so who cares?
The model 30 was a small entry-level machine, and wasn't particularly fast.
Comparable figure for a first-generation machine (1955)
to move 100 characters took 512uS.
Model 40/44 and 50 timings were somewhat better.
John Levine
Jul 20, 2012, 1:07:40 AM7/20/12
to
L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
assuming they were word aligned, probably twice that if they weren't.
For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
EX.
But remember that the point of the 360 series was that programs worked
the same way on all the models, so the code had to be designed so it
would work adequately even at the low end.
R's,
John
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
glen herrmannsfeldt
Jul 20, 2012, 2:23:34 AM7/20/12
to
John Levine <jo...@iecc.com> wrote:
(snip, someone wrote)
otherwise, or use an IC, STC loop.
S/370 allowed for slow access to unaligned operands.
> But remember that the point of the 360 series was that
> programs worked the same way on all the models, so the
> code had to be designed so it would work adequately even
> at the low end.
Most of the "work the same way" conveniently exclude timing,
and also memory size.
Many utilities, and also the PL/I (F) compiler, were designed
to run in small memories, though not necessarily fast.
PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
At the end of each compilation, it tells you the minimum
amount of memory to keep the symbol table in core.
(It will happily write it to disk, if needed.)
-- glen
(snip, someone wrote)
>>Model 40/44 and 50 timings were somewhat better.
> The model 44 is hard to compare since it didn't have MVC, a loop like
> L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> assuming they were word aligned, probably twice that if they weren't.
> For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
> EX.
For S/360, operands had to be aligned. It would take lots of shifts
> The model 44 is hard to compare since it didn't have MVC, a loop like
> L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> assuming they were word aligned, probably twice that if they weren't.
> For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
> EX.
otherwise, or use an IC, STC loop.
S/370 allowed for slow access to unaligned operands.
> But remember that the point of the 360 series was that
> programs worked the same way on all the models, so the
> code had to be designed so it would work adequately even
> at the low end.
and also memory size.
Many utilities, and also the PL/I (F) compiler, were designed
to run in small memories, though not necessarily fast.
PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
At the end of each compilation, it tells you the minimum
amount of memory to keep the symbol table in core.
(It will happily write it to disk, if needed.)
-- glen
robin....@gmail.com
Jul 20, 2012, 4:52:37 AM7/20/12
to
On Friday, 20 July 2012 15:07:40 UTC+10, John Levine wrote:
> >> On a 360/30, the MVC to move a 100 character field took 330us, or 355
> >> if it used EX to set the field length. Do a 20 of those for a 2K disk
> >> block and it's 6ms just to move the data, an appreciable fraction of
> >> the time to do the disk I/O. These days, moving that much data is
> >> probably under 50us, so who cares?
> >
> >The model 30 was a small entry-level machine, and wasn't particularly fast.
> >Comparable figure for a first-generation machine (1955)
> >to move 100 characters took 512uS.
> >
> >Model 40/44 and 50 timings were somewhat better.
using those instructions available on it.
If IC and STC were available on the 44, then those would make
a better choice than L, ST, etc,
and a better loop would use
IC, STC, AR, BCTR
for speed. Or,
IC STC, BCTR
where indexing and counting are performed using the same register
that BCTR uses.
> But remember that the point of the 360 series was that programs worked
> the same way on all the models,
Only for the basic instruction set.
Programs that did not adhere to that would not work
on machines not having that particular subset of instructions.
> >> On a 360/30, the MVC to move a 100 character field took 330us, or 355
> >> if it used EX to set the field length. Do a 20 of those for a 2K disk
> >> block and it's 6ms just to move the data, an appreciable fraction of
> >> the time to do the disk I/O. These days, moving that much data is
> >> probably under 50us, so who cares?
> >
> >The model 30 was a small entry-level machine, and wasn't particularly fast.
> >Comparable figure for a first-generation machine (1955)
> >to move 100 characters took 512uS.
> >
> >Model 40/44 and 50 timings were somewhat better.
>
> The model 44 is hard to compare since it didn't have MVC, a loop like
> L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> assuming they were word aligned, probably twice that if they weren't.
> For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
> EX.
As for the model 44, it can still be compared, though obviously
> The model 44 is hard to compare since it didn't have MVC, a loop like
> L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> assuming they were word aligned, probably twice that if they weren't.
> For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
> EX.
using those instructions available on it.
If IC and STC were available on the 44, then those would make
a better choice than L, ST, etc,
and a better loop would use
IC, STC, AR, BCTR
for speed. Or,
IC STC, BCTR
where indexing and counting are performed using the same register
that BCTR uses.
> But remember that the point of the 360 series was that programs worked
> the same way on all the models,
Programs that did not adhere to that would not work
on machines not having that particular subset of instructions.
robin....@gmail.com
Jul 20, 2012, 5:07:18 AM7/20/12
to
On Friday, 20 July 2012 16:23:34 UTC+10, glen herrmannsfeldt wrote:
IIRC Watfor allowed unaligned variables, and shifted them
accordingly.
> S/370 allowed for slow access to unaligned operands.
>
> > But remember that the point of the 360 series was that
> > programs worked the same way on all the models, so the
> > code had to be designed so it would work adequately even
> > at the low end.
>
> Most of the "work the same way" conveniently exclude timing,
> and also memory size.
S/360 programs were upwards compatible.
Provided that the larger/faster target machine had the same
instruction set and at least the same amount of memory
(usually the case), then the program would run.
> Many utilities, and also the PL/I (F) compiler, were designed
> to run in small memories, though not necessarily fast.
> PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
> At the end of each compilation, it tells you the minimum
> amount of memory to keep the symbol table in core.
> (It will happily write it to disk, if needed.)
In terms of program size, IBM 360 programs and compilers weren't
designed to run in small memories. Fortran H required some 150K.
Look at DR PL/I for DOS. (24K size, ran in 8K, IIRC)
Earlier machines managed to run large programs in 500 words of
main memory (2K bytes).
> John Levine <jjjj...@iecc.com> wrote:
>
> >>Model 40/44 and 50 timings were somewhat better.
>
> > The model 44 is hard to compare since it didn't have MVC, a loop like
> > L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> > assuming they were word aligned, probably twice that if they weren't.
> > For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
> > EX.
>
> For S/360, operands had to be aligned. It would take lots of shifts
> otherwise, or use an IC, STC loop.
Not sure about that.
>
> >>Model 40/44 and 50 timings were somewhat better.
>
> > The model 44 is hard to compare since it didn't have MVC, a loop like
> > L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> > assuming they were word aligned, probably twice that if they weren't.
> > For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
> > EX.
>
> For S/360, operands had to be aligned. It would take lots of shifts
> otherwise, or use an IC, STC loop.
IIRC Watfor allowed unaligned variables, and shifted them
accordingly.
> S/370 allowed for slow access to unaligned operands.
>
> > But remember that the point of the 360 series was that
> > programs worked the same way on all the models, so the
> > code had to be designed so it would work adequately even
> > at the low end.
>
> Most of the "work the same way" conveniently exclude timing,
> and also memory size.
Provided that the larger/faster target machine had the same
instruction set and at least the same amount of memory
(usually the case), then the program would run.
> Many utilities, and also the PL/I (F) compiler, were designed
> to run in small memories, though not necessarily fast.
> PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
> At the end of each compilation, it tells you the minimum
> amount of memory to keep the symbol table in core.
> (It will happily write it to disk, if needed.)
designed to run in small memories. Fortran H required some 150K.
Look at DR PL/I for DOS. (24K size, ran in 8K, IIRC)
Earlier machines managed to run large programs in 500 words of
main memory (2K bytes).
glen herrmannsfeldt
Jul 20, 2012, 6:28:54 AM7/20/12
to
robin....@gmail.com wrote:
(snip)
(snip)
and for CPU models.
D = 16K
E = 32K
F = 64K
G = 128K
H = 256K
I = 512K
J = 1024K
K = 2048K
For CPU models, they work like roman numerals, where a
smaller value after a larger value adds, and before a larger
value subtracts.
-- glen
(snip)
(snip)
> In terms of program size, IBM 360 programs and compilers weren't
> designed to run in small memories. Fortran H required some 150K.
There is a system behind the letters, used both for programs
> designed to run in small memories. Fortran H required some 150K.
and for CPU models.
D = 16K
E = 32K
F = 64K
G = 128K
H = 256K
I = 512K
J = 1024K
K = 2048K
For CPU models, they work like roman numerals, where a
smaller value after a larger value adds, and before a larger
value subtracts.
-- glen
John W Kennedy
Jul 20, 2012, 11:20:41 AM7/20/12
to
know bugger-all about the 44.
--
John W Kennedy
"Compact is becoming contract,
Man only earns and pays."
-- Charles Williams. "Bors to Elayne: On the King's Coins"
John W Kennedy
Jul 20, 2012, 11:23:09 AM7/20/12
to
On 2012-07-20 06:23:34 +0000, glen herrmannsfeldt said:
> John Levine <jo...@iecc.com> wrote:
>
> (snip, someone wrote)
>>> Model 40/44 and 50 timings were somewhat better.
>
>> The model 44 is hard to compare since it didn't have MVC, a loop like
>> L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
>> assuming they were word aligned, probably twice that if they weren't.
>> For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
>> EX.
>
> For S/360, operands had to be aligned. It would take lots of shifts
> otherwise, or use an IC, STC loop.
This depends a great deal on whether the alignments are known ahead of time.
> John Levine <jo...@iecc.com> wrote:
>
> (snip, someone wrote)
>>> Model 40/44 and 50 timings were somewhat better.
>
>> The model 44 is hard to compare since it didn't have MVC, a loop like
>> L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
>> assuming they were word aligned, probably twice that if they weren't.
>> For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
>> EX.
>
> For S/360, operands had to be aligned. It would take lots of shifts
> otherwise, or use an IC, STC loop.
>
> S/370 allowed for slow access to unaligned operands.
>
>> But remember that the point of the 360 series was that
>> programs worked the same way on all the models, so the
>> code had to be designed so it would work adequately even
>> at the low end.
>
> Most of the "work the same way" conveniently exclude timing,
> and also memory size.
>
> Many utilities, and also the PL/I (F) compiler, were designed
> to run in small memories, though not necessarily fast.
> PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
> At the end of each compilation, it tells you the minimum
> amount of memory to keep the symbol table in core.
> (It will happily write it to disk, if needed.)
>
> -- glen
John W Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
-- Charles Williams. "Mount Badon"
John W Kennedy
Jul 20, 2012, 11:27:33 AM7/20/12
to
IBM from the beginning, but mistakes were still made.)
>> Many utilities, and also the PL/I (F) compiler, were designed
>> to run in small memories, though not necessarily fast.
>> PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
>> At the end of each compilation, it tells you the minimum
>> amount of memory to keep the symbol table in core.
>> (It will happily write it to disk, if needed.)
>
> In terms of program size, IBM 360 programs and compilers weren't
> designed to run in small memories. Fortran H required some 150K.
designed to run in 8. Even OS/360 could run in 32K (and some /very/
early statements were made about a 16K tape-resident version of OS/360).
> Look at DR PL/I for DOS. (24K size, ran in 8K, IIRC)
>
> Earlier machines managed to run large programs in 500 words of
> main memory (2K bytes).
John W Kennedy
"Only an idiot fights a war on two fronts. Only the heir to the throne
of the kingdom of idiots would fight a war on twelve fronts"
-- J. Michael Straczynski. "Babylon 5", "Ceremonies of Light and Dark"
John W Kennedy
Jul 20, 2012, 11:29:21 AM7/20/12
to
D compiler for DOS/360, for one, actually required 32K.
--
John W Kennedy
"The pathetic hope that the White House will turn a Caligula into a
Marcus Aurelius is as naïve as the fear that ultimate power inevitably
corrupts."
-- James D. Barber (1930-2004)
robin....@gmail.com
Jul 20, 2012, 12:17:45 PM7/20/12
to
On Saturday, 21 July 2012 01:20:41 UTC+10, John W Kennedy wrote:
> On 2012-07-20 02:12:45 +0000, xxxx...@gmail.com said:
>
> > On Friday, 20 July 2012 04:03:43 UTC+10, John Levine wrote:
> >
> >> the time to do the disk I/O. These days, moving that much data is
> >> probably under 50us, so who cares?
> >
> > to move 100 characters took 512uS.
I don't claim to know much about the 44.
Perhaps you could enlighten us all with your knowledge.
> On 2012-07-20 02:12:45 +0000, xxxx...@gmail.com said:
>
> > On Friday, 20 July 2012 04:03:43 UTC+10, John Levine wrote:
> >
> >> On a 360/30, the MVC to move a 100 character field took 330us, or 355
> >> if it used EX to set the field length. Do a 20 of those for a 2K disk
> >> block and it's 6ms just to move the data, an appreciable fraction of
> >> if it used EX to set the field length. Do a 20 of those for a 2K disk
> >> the time to do the disk I/O. These days, moving that much data is
> >> probably under 50us, so who cares?
> >
> > The model 30 was a small entry-level machine, and wasn't particularly fast.
> > Comparable figure for a first-generation machine (1955)
> > to move 100 characters took 512uS.
>
> > Model 40/44 and 50 timings were somewhat better.
>
> Speaking of "Model 40/44", especially in this context, shows that you
> know bugger-all about the 44.
Do you have a bee in your bonnet?
> > Model 40/44 and 50 timings were somewhat better.
>
> Speaking of "Model 40/44", especially in this context, shows that you
> know bugger-all about the 44.
I don't claim to know much about the 44.
Perhaps you could enlighten us all with your knowledge.
John W Kennedy
Jul 20, 2012, 12:56:47 PM7/20/12
to
The 44 was an unmicrocoded 32-bit machine that omitted all SS
instructions, plus BXLE, BXH, LM, STM, and EX. The 44 also offered an
optional internal disk drive (the same that was used by the 1130) for
users who didn't trust disks, but needed one for the operating system,
compiler scratch files, and resident programs. It had its own special
operating system (44PS) that offered only a ported version of FORTRAN G
and an assembler without macros (though it /did/ have full
conditional-assembly features in open code), and which was functionally
much like DOS/360, except that, like OS/360 and unlike DOS/360, it
could allocate disk files without the user having to set the exact
extents.
One funky feature was that the precision of 64-bit floating point could
be reduced by a dial on the front panel, with a corresponding increase
in speed. Since 44PS didn't offer multiprogramming, it didn't matter
that the dial affected the whole machine.
Custom hardware was available to add priority interrupts and a 32-bit
version of the Direct Control feature, and there were operating-system
extentions to match.
There was an optional compatibility feature that added BXLE, BXH, LM,
STM, and EX to the hardware, plus an invisible shadow core unit into
which you could load special software to emulate the SS instructions.
With that, you could run normal 360 software, but with some severe
performance hits and a tendency for the clock to drift. (Even with the
normal software, there was a slight clock-drift problem, because the
MVC instruction wasn't available. To reduce, but not eliminate the
problem, the 44 offered the improved interval timer option that ticked
76,800 times a second instead of 300, which was not available in other
360s in its price class.)
If the restrictions didn't bother you, the 44 gave you the performance
of a 65 at the price of a 40.
But the 40 and 44 had nothing in common but the name and the price point.
In one way, the 44 with the compatibility feature anticipated today's
z/Architecture systems, in that it implemented a large part of the
architecture in hardware, and then used that part to implement the
microcode for the rest.
--
John W Kennedy
"'Your art then,' said Vertue, 'seems to teach men that the best way of
being happy is to enjoy unbroken good fortune in every respect. They
would not all find the advice helpful.'"
-- C. S. Lewis. "The Pilgrim's Regress"
glen herrmannsfeldt
Jul 20, 2012, 3:14:50 PM7/20/12
to
John W Kennedy <jwk...@attglobal.net> wrote:
(snip, I wrote)
offset, then you IC, STC until you get aligned, then L, ST.
Otherwise, you can do like Fortran and fixup on the interrupt.
>> S/370 allowed for slow access to unaligned operands.
> Anticipated by the 85 and 195.
Yes. As previously mentioned, much of S/360 was an experiment.
The microcoded models all used different control store
technology to try out different ones. The 360/67 was an
experiment in virtual memory. The 360/85 was an experiment
in cache technology. The 91 was an experiment in many things.
And, I had almost forgotten, the 85 and 195 experiment
in unaligned access.
(snip)
-- glen
(snip, I wrote)
>> For S/360, operands had to be aligned. It would take lots of shifts
>> otherwise, or use an IC, STC loop.
> This depends a great deal on whether the alignments are known
> ahead of time.
Yes. Well, if they were known to be misaligned with the same
>> otherwise, or use an IC, STC loop.
> This depends a great deal on whether the alignments are known
> ahead of time.
offset, then you IC, STC until you get aligned, then L, ST.
Otherwise, you can do like Fortran and fixup on the interrupt.
>> S/370 allowed for slow access to unaligned operands.
> Anticipated by the 85 and 195.
The microcoded models all used different control store
technology to try out different ones. The 360/67 was an
experiment in virtual memory. The 360/85 was an experiment
in cache technology. The 91 was an experiment in many things.
And, I had almost forgotten, the 85 and 195 experiment
in unaligned access.
(snip)
-- glen
robin....@gmail.com
Jul 20, 2012, 10:01:25 PM7/20/12
to
On Saturday, 21 July 2012 01:27:33 UTC+10, John W Kennedy wrote:
> On 2012-07-20 09:07:18 +0000, rrrr...@gmail.com said:
>
> > On Friday, 20 July 2012 16:23:34 UTC+10, glen herrmannsfeldt wrote:
> >> John Levine &lt;jjjj...@iecc.com&gt; wrote:
> >>
> >>>> Model 40/44 and 50 timings were somewhat better.
> >>
> >>> The model 44 is hard to compare since it didn't have MVC, a loop like
> >>> L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> >>> assuming they were word aligned, probably twice that if they weren't.
> >>> For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
> >>> EX.
> >>
> >> For S/360, operands had to be aligned. It would take lots of shifts
> >> otherwise, or use an IC, STC loop.
> >
> > Not sure about that.
> > IIRC Watfor allowed unaligned variables, and shifted them
> > accordingly.
> >
> >> S/370 allowed for slow access to unaligned operands.
> >>
> >>> But remember that the point of the 360 series was that
> >>> programs worked the same way on all the models, so the
> >>> code had to be designed so it would work adequately even
> >>> at the low end.
> >>
> >> Most of the "work the same way" conveniently exclude timing,
> >> and also memory size.
> >
> > S/360 programs were upwards compatible.
> > Provided that the larger/faster target machine had the same
> > instruction set and at least the same amount of memory
> > (usually the case), then the program would run.
Still, 8K was a far cry from 1K and 2K memories of earlier machines.
It was actually difficult to write any significant S/360 code
that would run in what remained in a 8K or 16K system
after the OS was loaded.
An 8K system would have been principally for stand-alone systems.
Overlay techniques would have been needed for such memories.
> On 2012-07-20 09:07:18 +0000, rrrr...@gmail.com said:
>
> > On Friday, 20 July 2012 16:23:34 UTC+10, glen herrmannsfeldt wrote:
> >> John Levine &lt;jjjj...@iecc.com&gt; wrote:
> >>
> >>>> Model 40/44 and 50 timings were somewhat better.
> >>
> >>> The model 44 is hard to compare since it didn't have MVC, a loop like
> >>> L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> >>> assuming they were word aligned, probably twice that if they weren't.
> >>> For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
> >>> EX.
> >>
> >> For S/360, operands had to be aligned. It would take lots of shifts
> >> otherwise, or use an IC, STC loop.
> >
> > Not sure about that.
> > IIRC Watfor allowed unaligned variables, and shifted them
> > accordingly.
> >
> >> S/370 allowed for slow access to unaligned operands.
> >>
> >>> But remember that the point of the 360 series was that
> >>> programs worked the same way on all the models, so the
> >>> code had to be designed so it would work adequately even
> >>> at the low end.
> >>
> >> Most of the "work the same way" conveniently exclude timing,
> >> and also memory size.
> >
> > S/360 programs were upwards compatible.
> > Provided that the larger/faster target machine had the same
> > instruction set and at least the same amount of memory
> > (usually the case), then the program would run.
>
> No, sometimes speed was critical. (Strong recommendations were made by
> IBM from the beginning, but mistakes were still made.)
>
> >> Many utilities, and also the PL/I (F) compiler, were designed
> >> to run in small memories, though not necessarily fast.
> >> PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
> >> At the end of each compilation, it tells you the minimum
> >> amount of memory to keep the symbol table in core.
> >> (It will happily write it to disk, if needed.)
>
> > In terms of program size, IBM 360 programs and compilers weren't
> > designed to run in small memories. Fortran H required some 150K.
>
> And TOS/360 and DOS/360 was designed to run in 16K, and BOS/360 was
> designed to run in 8. Even OS/360 could run in 32K (and some /very/
> early statements were made about a 16K tape-resident version of OS/360).
And how many of the compilers ran in 8K? 16K?
> No, sometimes speed was critical. (Strong recommendations were made by
> IBM from the beginning, but mistakes were still made.)
>
> >> Many utilities, and also the PL/I (F) compiler, were designed
> >> to run in small memories, though not necessarily fast.
> >> PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
> >> At the end of each compilation, it tells you the minimum
> >> amount of memory to keep the symbol table in core.
> >> (It will happily write it to disk, if needed.)
>
> > In terms of program size, IBM 360 programs and compilers weren't
> > designed to run in small memories. Fortran H required some 150K.
>
> And TOS/360 and DOS/360 was designed to run in 16K, and BOS/360 was
> designed to run in 8. Even OS/360 could run in 32K (and some /very/
> early statements were made about a 16K tape-resident version of OS/360).
Still, 8K was a far cry from 1K and 2K memories of earlier machines.
It was actually difficult to write any significant S/360 code
that would run in what remained in a 8K or 16K system
after the OS was loaded.
An 8K system would have been principally for stand-alone systems.
Overlay techniques would have been needed for such memories.
robin....@gmail.com
Jul 20, 2012, 10:16:29 PM7/20/12
to
On Saturday, 21 July 2012 05:14:50 UTC+10, glen herrmannsfeldt wrote:
> John W Kennedy <j...@attglobal.net> wrote:
>
> (snip, I wrote)
> >> For S/360, operands had to be aligned. It would take lots of shifts
> >> otherwise, or use an IC, STC loop.
>
> > This depends a great deal on whether the alignments are known
> > ahead of time.
out of some of the high-end models that were prematurely
announced, and thus had to abandon those efforts.
> The microcoded models all used different control store
> technology to try out different ones.
They weren't "trying out" different ones.
Higher speeds of the faster machines required different technologies.
> The 360/67 was an
> experiment in virtual memory.
Definitely NOT an experiment, because virtual memory had
been invented and used on the Atlas in about 1961, some 5 years
before the S/360. (Yes, I know that IBM claimed to have "invented"
virtual memory, but they didn't.)
> The 360/85 was an experiment
> in cache technology.
It wasn't an "experiment". That was resorted to after the
failure of the model 80 to materialize.
> The 91 was an experiment in many things.
> And, I had almost forgotten, the 85 and 195 experiment
> in unaligned access.
Not "experiments".
> John W Kennedy <j...@attglobal.net> wrote:
>
> (snip, I wrote)
> >> For S/360, operands had to be aligned. It would take lots of shifts
> >> otherwise, or use an IC, STC loop.
>
> > This depends a great deal on whether the alignments are known
> > ahead of time.
>
> Yes. Well, if they were known to be misaligned with the same
> offset, then you IC, STC until you get aligned, then L, ST.
>
> Otherwise, you can do like Fortran and fixup on the interrupt.
>
> >> S/370 allowed for slow access to unaligned operands.
>
> > Anticipated by the 85 and 195.
>
> Yes. As previously mentioned, much of S/360 was an experiment.
No they weren't. IBM found that they couldn't get the performance
> Yes. Well, if they were known to be misaligned with the same
> offset, then you IC, STC until you get aligned, then L, ST.
>
> Otherwise, you can do like Fortran and fixup on the interrupt.
>
> >> S/370 allowed for slow access to unaligned operands.
>
> > Anticipated by the 85 and 195.
>
> Yes. As previously mentioned, much of S/360 was an experiment.
out of some of the high-end models that were prematurely
announced, and thus had to abandon those efforts.
> The microcoded models all used different control store
> technology to try out different ones.
Higher speeds of the faster machines required different technologies.
> The 360/67 was an
> experiment in virtual memory.
been invented and used on the Atlas in about 1961, some 5 years
before the S/360. (Yes, I know that IBM claimed to have "invented"
virtual memory, but they didn't.)
> The 360/85 was an experiment
> in cache technology.
failure of the model 80 to materialize.
> The 91 was an experiment in many things.
> And, I had almost forgotten, the 85 and 195 experiment
> in unaligned access.
robin....@gmail.com
Jul 21, 2012, 3:23:49 AM7/21/12
to
On Saturday, 21 July 2012 01:27:33 UTC+10, John W Kennedy wrote:
> On 2012-07-20 09:07:18 +0000, rrrrr...@gmail.com said:
>
> > On Friday, 20 July 2012 16:23:34 UTC+10, glen herrmannsfeldt wrote:
> >> John Levine &lt;jjjj...@iecc.com&gt; wrote:
> >>
> >>>> Model 40/44 and 50 timings were somewhat better.
>
> > On Friday, 20 July 2012 16:23:34 UTC+10, glen herrmannsfeldt wrote:
> >> John Levine &lt;jjjj...@iecc.com&gt; wrote:
> >>
> >>
> >>> The model 44 is hard to compare since it didn't have MVC, a loop like
> >>> L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> >>> assuming they were word aligned, probably twice that if they weren't.
> >>> For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
> >>> EX.
> >>
> >> For S/360, operands had to be aligned. It would take lots of shifts
> >> otherwise, or use an IC, STC loop.
> >
> > Not sure about that.
> > IIRC Watfor allowed unaligned variables, and shifted them
> > accordingly.
> >
> >> S/370 allowed for slow access to unaligned operands.
> >>> L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> >>> assuming they were word aligned, probably twice that if they weren't.
> >>> For the /65, an unaligned 100 byte MVC was about 40us, plus 3us for an
> >>> EX.
> >>
> >> For S/360, operands had to be aligned. It would take lots of shifts
> >> otherwise, or use an IC, STC loop.
> >
> > Not sure about that.
> > IIRC Watfor allowed unaligned variables, and shifted them
> > accordingly.
> >
> >>
> >>> But remember that the point of the 360 series was that
> >>> programs worked the same way on all the models, so the
> >>> code had to be designed so it would work adequately even
> >>> at the low end.
> >>
> >> Most of the "work the same way" conveniently exclude timing,
> >> and also memory size.
> >
> > S/360 programs were upwards compatible.
> >>> programs worked the same way on all the models, so the
> >>> code had to be designed so it would work adequately even
> >>> at the low end.
> >>
> >> Most of the "work the same way" conveniently exclude timing,
> >> and also memory size.
> >
> > Provided that the larger/faster target machine had the same
> > instruction set and at least the same amount of memory
> > (usually the case), then the program would run.
>
> No, sometimes speed was critical.
If speed was a factor, you used a faster machine
> No, sometimes speed was critical.
(which is what "upwards compatible" means).
John W Kennedy
Jul 21, 2012, 2:32:29 PM7/21/12
to
128-bit floating point. (Though there is also some evidence that
128-bit floating point was also tried on the 67. I've never seen an
explicit claim that it existed in actual hardware, but the TSS
assembler manual included some opcodes -- not the same as the ones that
were eventually used on the 85 and up. I've always supposed it was an
RPQ.)
--
John W Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like That.
...you may come to think a blow bad, because it hurts, and not because
it humiliates. You may come to think murder wrong, because it is
violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"
John W Kennedy
Jul 21, 2012, 2:46:14 PM7/21/12
to
On 2012-07-21 02:16:29 +0000, robin....@gmail.com said:
> On Saturday, 21 July 2012 05:14:50 UTC+10, glen herrmannsfeldt wrote:
>> John W Kennedy <j...@attglobal.net> wrote:
>>
>> (snip, I wrote)
>> >> For S/360, operands had to be aligned. It would take lots of shifts
>> >> otherwise, or use an IC, STC loop.
>>
>> > This depends a great deal on whether the alignments are known
>> > ahead of time.
>>
>> Yes. Well, if they were known to be misaligned with the same
>> offset, then you IC, STC until you get aligned, then L, ST.
>>
>> Otherwise, you can do like Fortran and fixup on the interrupt.
>>
>>>> S/370 allowed for slow access to unaligned operands.
>>
>>> Anticipated by the 85 and 195.
>>
>> Yes. As previously mentioned, much of S/360 was an experiment.
>
> No they weren't. IBM found that they couldn't get the performance
> out of some of the high-end models that were prematurely
> announced, and thus had to abandon those efforts.
Only the 92 was abandoned in that sense. (They also abandoned the 60,
> On Saturday, 21 July 2012 05:14:50 UTC+10, glen herrmannsfeldt wrote:
>> John W Kennedy <j...@attglobal.net> wrote:
>>
>> (snip, I wrote)
>> >> For S/360, operands had to be aligned. It would take lots of shifts
>> >> otherwise, or use an IC, STC loop.
>>
>> > This depends a great deal on whether the alignments are known
>> > ahead of time.
>>
>> Yes. Well, if they were known to be misaligned with the same
>> offset, then you IC, STC until you get aligned, then L, ST.
>>
>> Otherwise, you can do like Fortran and fixup on the interrupt.
>>
>>>> S/370 allowed for slow access to unaligned operands.
>>
>>> Anticipated by the 85 and 195.
>>
>> Yes. As previously mentioned, much of S/360 was an experiment.
>
> No they weren't. IBM found that they couldn't get the performance
> out of some of the high-end models that were prematurely
> announced, and thus had to abandon those efforts.
62, 64, 66, and 70, but those were all replaced with /better/ models,
the 65, 67, and 75.)
>> The microcoded models all used different control store
>> technology to try out different ones.
>
> They weren't "trying out" different ones.
> Higher speeds of the faster machines required different technologies.
used the entirely different TROS?
>> The 360/67 was an
>> experiment in virtual memory.
>
> Definitely NOT an experiment, because virtual memory had
> been invented and used on the Atlas in about 1961, some 5 years
> before the S/360. (Yes, I know that IBM claimed to have "invented"
> virtual memory, but they didn't.)
thing, I do not see that the Atlas had anything equivalent to their
Associative Registers (known in the 370 in greatly expanded form as the
Translation Lookaside Buffer). Also, the Atlas was a short run (total
of 4) of special-order supercomputers; the virtual-memory 360s were in
IBM's main catalog.
>> The 360/85 was an experiment
>> in cache technology.
>
> It wasn't an "experiment". That was resorted to after the
> failure of the model 80 to materialize.
>> The 91 was an experiment in many things.
>> And, I had almost forgotten, the 85 and 195 experiment
>> in unaligned access.
>
> Not "experiments".
--
John W Kennedy
John W Kennedy
Jul 21, 2012, 2:53:34 PM7/21/12
to
forget what the requirements were for BPS RPG and FORTRAN.
TOS/360 and DOS/360 Assembler D, TOS/360 and DOS/360 Fortran D, TOS/360
and DOS/360 RPG D, TOS/360 and DOS/360 PL/I D, and TOS/360 COBOL D ran
in 16K. DOS/360 COBOL D was originally targetted for 16K, but ended up
needing 32.
> Still, 8K was a far cry from 1K and 2K memories of earlier machines.
>
> It was actually difficult to write any significant S/360 code
> that would run in what remained in a 8K or 16K system
> after the OS was loaded.
>
> An 8K system would have been principally for stand-alone systems.
>
> Overlay techniques would have been needed for such memories.
OS/360 overlay only worked in full-blown MVT.
>>> Look at DR PL/I for DOS. (24K size, ran in 8K, IIRC)
>>
>>> Earlier machines managed to run large programs in 500 words of
>>> main memory (2K bytes).
John W Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
John W Kennedy
Jul 21, 2012, 2:54:53 PM7/21/12
to
happened in MS-DOS days, when so many of the same lessons had to be
learned over again.
--
John W Kennedy
"The whole modern world has divided itself into Conservatives and
Progressives. The business of Progressives is to go on making mistakes.
The business of the Conservatives is to prevent the mistakes from being
corrected."
-- G. K. Chesterton
robin....@gmail.com
Jul 21, 2012, 8:25:33 PM7/21/12
to
On Sunday, 22 July 2012 04:54:53 UTC+10, John W Kennedy wrote:
> On 2012-07-21 07:23:49 +0000, rrrr...@gmail.com said:
>
> > On Saturday, 21 July 2012 01:27:33 UTC+10, John W Kennedy wrote:
> >> On 2012-07-20 09:07:18 +0000, rrrrr...@gmail.com said:
> >>
> >> &gt; On Friday, 20 July 2012 16:23:34 UTC+10, glen herrmannsfeldt wrote:
> >> &gt;&gt; John Levine &amp;lt;jjjj...@iecc.com&amp;gt; wrote:
> >> &gt;&gt;
> >> &gt;&gt;&gt;&gt; Model 40/44 and 50 timings were somewhat better.
> >> &gt;&gt;
> >> &gt;&gt;&gt; The model 44 is hard to compare since it didn&#39;t have
> >> MVC, a loop like
> >> &gt;&gt;&gt; L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> >> &gt;&gt;&gt; assuming they were word aligned, probably twice that if
> >> they weren&#39;t.
> >> &gt;&gt;&gt; For the /65, an unaligned 100 byte MVC was about 40us,
> >> plus 3us for an
> >> &gt;&gt;&gt; EX.
> >> &gt;&gt;
> >> &gt;&gt; For S/360, operands had to be aligned. It would take lots of shifts
> >> &gt;&gt; otherwise, or use an IC, STC loop.
> >> &gt;
> >> &gt; Not sure about that.
> >> &gt; IIRC Watfor allowed unaligned variables, and shifted them
> >> &gt; accordingly.
> >> &gt;
> >> &gt;&gt; S/370 allowed for slow access to unaligned operands.
> >> &gt;&gt;
> >> &gt;&gt;&gt; But remember that the point of the 360 series was that
> >> &gt;&gt;&gt; programs worked the same way on all the models, so the
> >> &gt;&gt;&gt; code had to be designed so it would work adequately even
> >> &gt;&gt;&gt; at the low end.
> >> &gt;&gt;
> >> &gt;&gt; Most of the &quot;work the same way&quot; conveniently exclude timing,
> >> &gt;&gt; and also memory size.
> >> &gt;
> >> &gt; S/360 programs were upwards compatible.
> >> &gt; Provided that the larger/faster target machine had the same
> >> &gt; instruction set and at least the same amount of memory
> >> &gt; (usually the case), then the program would run.
> >>
> >> No, sometimes speed was critical.
> >
> > If speed was a factor, you used a faster machine
> > (which is what "upwards compatible" means).
Now that you mention it, XPL object code ran unaltered on any S/360
having sufficient memory; even ran on the RCA Spectra compatible.
> just as often
> happened in MS-DOS days, when so many of the same lessons had to be
> learned over again.
Every one of the DOS programs that I have still run on newer and
faster PCs, even on Windows XP.
For that matter, they even ran/run under both MS DOS and DR DOS.
The only DOS program that I tried under DOS mode within OS/2 also ran.
> On 2012-07-21 07:23:49 +0000, rrrr...@gmail.com said:
>
> > On Saturday, 21 July 2012 01:27:33 UTC+10, John W Kennedy wrote:
> >> On 2012-07-20 09:07:18 +0000, rrrrr...@gmail.com said:
> >>
> >> &gt; On Friday, 20 July 2012 16:23:34 UTC+10, glen herrmannsfeldt wrote:
> >> &gt;&gt; John Levine &amp;lt;jjjj...@iecc.com&amp;gt; wrote:
> >> &gt;&gt;
> >> &gt;&gt;&gt;&gt; Model 40/44 and 50 timings were somewhat better.
> >> &gt;&gt;
> >> &gt;&gt;&gt; The model 44 is hard to compare since it didn&#39;t have
> >> MVC, a loop like
> >> &gt;&gt;&gt; L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> >> &gt;&gt;&gt; assuming they were word aligned, probably twice that if
> >> they weren&#39;t.
> >> &gt;&gt;&gt; For the /65, an unaligned 100 byte MVC was about 40us,
> >> plus 3us for an
> >> &gt;&gt;&gt; EX.
> >> &gt;&gt;
> >> &gt;&gt; For S/360, operands had to be aligned. It would take lots of shifts
> >> &gt;&gt; otherwise, or use an IC, STC loop.
> >> &gt;
> >> &gt; Not sure about that.
> >> &gt; IIRC Watfor allowed unaligned variables, and shifted them
> >> &gt; accordingly.
> >> &gt;
> >> &gt;&gt; S/370 allowed for slow access to unaligned operands.
> >> &gt;&gt;
> >> &gt;&gt;&gt; But remember that the point of the 360 series was that
> >> &gt;&gt;&gt; programs worked the same way on all the models, so the
> >> &gt;&gt;&gt; code had to be designed so it would work adequately even
> >> &gt;&gt;&gt; at the low end.
> >> &gt;&gt;
> >> &gt;&gt; Most of the &quot;work the same way&quot; conveniently exclude timing,
> >> &gt;&gt; and also memory size.
> >> &gt;
> >> &gt; S/360 programs were upwards compatible.
> >> &gt; Provided that the larger/faster target machine had the same
> >> &gt; instruction set and at least the same amount of memory
> >> &gt; (usually the case), then the program would run.
> >>
> >> No, sometimes speed was critical.
> >
> > If speed was a factor, you used a faster machine
> > (which is what "upwards compatible" means).
>
> And in some cases, using a faster machine broke programs,
Such as?
> And in some cases, using a faster machine broke programs,
Now that you mention it, XPL object code ran unaltered on any S/360
having sufficient memory; even ran on the RCA Spectra compatible.
> just as often
> happened in MS-DOS days, when so many of the same lessons had to be
> learned over again.
faster PCs, even on Windows XP.
For that matter, they even ran/run under both MS DOS and DR DOS.
The only DOS program that I tried under DOS mode within OS/2 also ran.
Dennis Boone
Jul 21, 2012, 8:51:30 PM7/21/12
to
> > And in some cases, using a faster machine broke programs,
> Such as?
Addressing the wintel DOS part of your comments:
> Such as?
Motorola RSS (radio programming software) for 80s-vintage radios was
highly prone to being unable to properly communicate with the radio
on machines faster than were in production when it was written.
De
robin....@gmail.com
Jul 21, 2012, 8:53:59 PM7/21/12
to
On Sunday, 22 July 2012 04:53:34 UTC+10, John W Kennedy wrote:
> On 2012-07-21 02:01:25 +0000, rrrrr...@gmail.com said:
>
> > On Saturday, 21 July 2012 01:27:33 UTC+10, John W Kennedy wrote:
> >> &gt;&gt; and also memory size.
> >> &gt;
> >> &gt; S/360 programs were upwards compatible.
> >> &gt; Provided that the larger/faster target machine had the same
> >> &gt; instruction set and at least the same amount of memory
> >> &gt; (usually the case), then the program would run.
> >>
> >> No, sometimes speed was critical. (Strong recommendations were made by
> >> IBM from the beginning, but mistakes were still made.)
> >>
> >>>> Many utilities, and also the PL/I (F) compiler, were designed
> >>>> to run in small memories, though not necessarily fast.
> >>>> PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
> >>>> At the end of each compilation, it tells you the minimum
> >>>> amount of memory to keep the symbol table in core.
> I
> forget what the requirements were for BPS RPG and FORTRAN.
>
> TOS/360 and DOS/360 Assembler D, TOS/360 and DOS/360 Fortran D, TOS/360
> and DOS/360 RPG D, TOS/360 and DOS/360 PL/I D, and TOS/360 COBOL D ran
> in 16K.
DOS PL/I was a subset. PL/I-F couldn't run.
DOS FORTRAN and COBOL were probably subset versions.
Is that the case?
Fortran E and G required larger memories than 8K and 16K.
> DOS/360 COBOL D was originally targetted for 16K, but ended up
> needing 32.
Precisely my point.
> > Still, 8K was a far cry from 1K and 2K memories of earlier machines.
> >
> > It was actually difficult to write any significant S/360 code
> > that would run in what remained in a 8K or 16K system
> > after the OS was loaded.
> On 2012-07-21 02:01:25 +0000, rrrrr...@gmail.com said:
>
> > On Saturday, 21 July 2012 01:27:33 UTC+10, John W Kennedy wrote:
> >> On 2012-07-20 09:07:18 +0000, rrrr...@gmail.com said:
> >>
> >> &gt; On Friday, 20 July 2012 16:23:34 UTC+10, glen herrmannsfeldt wrote:
> >> &gt;&gt; John Levine &amp;lt;jjjj...@iecc.com&amp;gt; wrote:
> >> &gt;&gt;
> >> &gt;&gt;&gt;&gt; Model 40/44 and 50 timings were somewhat better.
> >>
> >> &gt; On Friday, 20 July 2012 16:23:34 UTC+10, glen herrmannsfeldt wrote:
> >> &gt;&gt; John Levine &amp;lt;jjjj...@iecc.com&amp;gt; wrote:
> >> &gt;&gt;
> >> &gt;&gt;
> >> &gt;&gt;&gt; The model 44 is hard to compare since it didn&#39;t have
> >> MVC, a loop like
> >> &gt;&gt;&gt; L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> >> &gt;&gt;&gt; assuming they were word aligned, probably twice that if
> >> they weren&#39;t.
> >> &gt;&gt;&gt; For the /65, an unaligned 100 byte MVC was about 40us,
> >> plus 3us for an
> >> &gt;&gt;&gt; EX.
> >> &gt;&gt;
> >> &gt;&gt; For S/360, operands had to be aligned. It would take lots of shifts
> >> &gt;&gt; otherwise, or use an IC, STC loop.
> >> &gt;
> >> &gt; Not sure about that.
> >> &gt; IIRC Watfor allowed unaligned variables, and shifted them
> >> &gt; accordingly.
> >> &gt;
> >> &gt;&gt; S/370 allowed for slow access to unaligned operands.
> >> MVC, a loop like
> >> &gt;&gt;&gt; L, ST, LA, BCT is about 8us per word or 200us to move 100 bytes
> >> &gt;&gt;&gt; assuming they were word aligned, probably twice that if
> >> they weren&#39;t.
> >> &gt;&gt;&gt; For the /65, an unaligned 100 byte MVC was about 40us,
> >> plus 3us for an
> >> &gt;&gt;&gt; EX.
> >> &gt;&gt;
> >> &gt;&gt; For S/360, operands had to be aligned. It would take lots of shifts
> >> &gt;&gt; otherwise, or use an IC, STC loop.
> >> &gt;
> >> &gt; Not sure about that.
> >> &gt; IIRC Watfor allowed unaligned variables, and shifted them
> >> &gt; accordingly.
> >> &gt;
> >> &gt;&gt;
> >> &gt;&gt;&gt; But remember that the point of the 360 series was that
> >> &gt;&gt;&gt; programs worked the same way on all the models, so the
> >> &gt;&gt;&gt; code had to be designed so it would work adequately even
> >> &gt;&gt;&gt; at the low end.
> >> &gt;&gt;
> >> &gt;&gt; Most of the &quot;work the same way&quot; conveniently exclude timing,
> >> &gt;&gt;&gt; programs worked the same way on all the models, so the
> >> &gt;&gt;&gt; code had to be designed so it would work adequately even
> >> &gt;&gt;&gt; at the low end.
> >> &gt;&gt;
> >> &gt;&gt; and also memory size.
> >> &gt;
> >> &gt; S/360 programs were upwards compatible.
> >> &gt; Provided that the larger/faster target machine had the same
> >> &gt; instruction set and at least the same amount of memory
> >> &gt; (usually the case), then the program would run.
> >>
> >> No, sometimes speed was critical. (Strong recommendations were made by
> >> IBM from the beginning, but mistakes were still made.)
> >>
> >>>> Many utilities, and also the PL/I (F) compiler, were designed
> >>>> to run in small memories, though not necessarily fast.
> >>>> PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
> >>>> At the end of each compilation, it tells you the minimum
> >>>> amount of memory to keep the symbol table in core.
> >>>> (It will happily write it to disk, if needed.)
>
> >>> In terms of program size, IBM 360 programs and compilers weren't
> >>> designed to run in small memories. Fortran H required some 150K.
>
> >> And TOS/360 and DOS/360 was designed to run in 16K, and BOS/360 was
> >> designed to run in 8. Even OS/360 could run in 32K (and some /very/
> >> early statements were made about a 16K tape-resident version of OS/360).
>
> > And how many of the compilers ran in 8K? 16K?
>
> BOS/360 Assembler and RPG ran in 8K, as did BPS Basic Assembler.
Those are not compilers.
>
> >>> In terms of program size, IBM 360 programs and compilers weren't
> >>> designed to run in small memories. Fortran H required some 150K.
>
> >> And TOS/360 and DOS/360 was designed to run in 16K, and BOS/360 was
> >> designed to run in 8. Even OS/360 could run in 32K (and some /very/
> >> early statements were made about a 16K tape-resident version of OS/360).
>
> > And how many of the compilers ran in 8K? 16K?
>
> BOS/360 Assembler and RPG ran in 8K, as did BPS Basic Assembler.
> I
> forget what the requirements were for BPS RPG and FORTRAN.
>
> TOS/360 and DOS/360 Assembler D, TOS/360 and DOS/360 Fortran D, TOS/360
> and DOS/360 RPG D, TOS/360 and DOS/360 PL/I D, and TOS/360 COBOL D ran
> in 16K.
DOS FORTRAN and COBOL were probably subset versions.
Is that the case?
Fortran E and G required larger memories than 8K and 16K.
> DOS/360 COBOL D was originally targetted for 16K, but ended up
> needing 32.
> > Still, 8K was a far cry from 1K and 2K memories of earlier machines.
> >
> > It was actually difficult to write any significant S/360 code
> > that would run in what remained in a 8K or 16K system
> > after the OS was loaded.
Peter Flass
Jul 22, 2012, 5:09:34 AM7/22/12
to
direct port I/O.
--
Pete
Shmuel Metz
Jul 22, 2012, 7:52:47 AM7/22/12
to
In <juath5$3mt$1...@speranza.aioe.org>, on 07/20/2012
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
at 06:23 AM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>For S/360, operands had to be aligned.
On the early models; not on the 85 and 195.
>For S/360, operands had to be aligned.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
Shmuel Metz
Jul 22, 2012, 8:00:04 AM7/22/12
to
In <500978e5$0$11538$607e...@cv.net>, on 07/20/2012
getting any work out of it in less than 48 KiB.
at 11:27 AM, John W Kennedy <jwk...@attglobal.net> said:
>And TOS/360 and DOS/360 was designed to run in 16K, and BOS/360
>was designed to run in 8. Even OS/360 could run in 32K
You could IPL OS/360 PCP in 32 KiB, but I never heard of anybody
>And TOS/360 and DOS/360 was designed to run in 16K, and BOS/360
>was designed to run in 8. Even OS/360 could run in 32K
getting any work out of it in less than 48 KiB.
Shmuel Metz
Jul 22, 2012, 8:02:04 AM7/22/12
to
In <jubbt6$8g5$1...@speranza.aioe.org>, on 07/20/2012
to what the shipped code required.
at 10:28 AM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>There is a system behind the letters,
Yes, although for software they referred to design targets rather than
>There is a system behind the letters,
to what the shipped code required.
Shmuel Metz
Jul 22, 2012, 8:06:14 AM7/22/12
to
In <50098dcf$0$11541$607e...@cv.net>, on 07/20/2012
and presumably other IBM S/360 operating systems.
at 12:56 PM, John W Kennedy <jwk...@attglobal.net> said:
>It had its own special operating system (44PS)
However, a 44 with the commercial instruction feature could run OS/360
>It had its own special operating system (44PS)
and presumably other IBM S/360 operating systems.
Shmuel Metz
Jul 22, 2012, 8:17:59 AM7/22/12
to
In <jucan9$oa6$1...@speranza.aioe.org>, on 07/20/2012
machine.
>Yes. As previously mentioned, much of S/360 was an experiment.
More the fruits of earlier experiments, e.g., Stretch.
>And, I had almost forgotten, the 85 and 195 experiment
>in unaligned access.
To say nothing of the block mux.
at 07:14 PM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>The microcoded models all used different control store
>technology to try out different ones.
Not all, unless you consider, e.g., 2067 and 2065, to be the same
>The microcoded models all used different control store
>technology to try out different ones.
machine.
>Yes. As previously mentioned, much of S/360 was an experiment.
>And, I had almost forgotten, the 85 and 195 experiment
>in unaligned access.
Shmuel Metz
Jul 22, 2012, 8:53:13 AM7/22/12
to
In <500af8f6$0$6053$607e...@cv.net>, on 07/21/2012
Was the 91 a different machine, or only a renamed 92?
Was the 91 a different machine, or only a renamed 92?
John Levine
Jul 22, 2012, 1:39:38 PM7/22/12
to
>>Only the 92 was abandoned in that sense.
>
>Was the 91 a different machine, or only a renamed 92?
According to Pugh et al., there was a great deal of flux at the high
>
>Was the 91 a different machine, or only a renamed 92?
end both due to what they could actually build, and trying to meet
competition with the CDC 6600. The 91 was originally a less
aggressive version of the 92, but when some of the technology for the
91 turned out to be faster than they though, notably the core memory
from the 75 which turned out to be 750ns rather than 1us, they folded
the remnants of the 92 program into the 91.
Given how much thouble they had getting the 91 to work, and how much
more it cost to build than they'd planned, that was not a bad
decision.
R's,
John
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
John Levine
Jul 22, 2012, 1:40:12 PM7/22/12
to
>However, a 44 with the commercial instruction feature could run OS/360
>and presumably other IBM S/360 operating systems.
When did that come out? It's not in any of the /44 manuals I have.
>and presumably other IBM S/360 operating systems.
glen herrmannsfeldt
Jul 22, 2012, 7:24:03 PM7/22/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
> In <500af8f6$0$6053$607e...@cv.net>, on 07/21/2012
> at 02:46 PM, John W Kennedy <jwk...@attglobal.net> said:
>>Only the 92 was abandoned in that sense.
> Was the 91 a different machine, or only a renamed 92?
There might be a legal reason for the change, no technical
> In <500af8f6$0$6053$607e...@cv.net>, on 07/21/2012
> at 02:46 PM, John W Kennedy <jwk...@attglobal.net> said:
>>Only the 92 was abandoned in that sense.
> Was the 91 a different machine, or only a renamed 92?
reason that I know of.
As well as I know it, the result didn't run as fast as was
hoped, so they renumbered it.
Seems to me, that might get around legal problems with people
having bought a 92.
-- glen
glen herrmannsfeldt
Jul 22, 2012, 7:28:02 PM7/22/12
to
John Levine <jo...@iecc.com> wrote:
(snip)
the 60ns processor cycle and one instruction per cycle goal.
I could get out the book and look it up, but there was also the 95,
which I believe is pretty much the same, but with (faster) magnetic
thin film memory.
-- glen
(snip)
> According to Pugh et al., there was a great deal of flux at the high
> end both due to what they could actually build, and trying to meet
> competition with the CDC 6600. The 91 was originally a less
> aggressive version of the 92, but when some of the technology for the
> 91 turned out to be faster than they though, notably the core memory
> from the 75 which turned out to be 750ns rather than 1us, they folded
> the remnants of the 92 program into the 91.
And 16 way interleaved to have a chance to keep up with
> end both due to what they could actually build, and trying to meet
> competition with the CDC 6600. The 91 was originally a less
> aggressive version of the 92, but when some of the technology for the
> 91 turned out to be faster than they though, notably the core memory
> from the 75 which turned out to be 750ns rather than 1us, they folded
> the remnants of the 92 program into the 91.
the 60ns processor cycle and one instruction per cycle goal.
I could get out the book and look it up, but there was also the 95,
which I believe is pretty much the same, but with (faster) magnetic
thin film memory.
-- glen
glen herrmannsfeldt
Jul 22, 2012, 7:33:26 PM7/22/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
> In <jucan9$oa6$1...@speranza.aioe.org>, on 07/20/2012
> at 07:14 PM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>>The microcoded models all used different control store
>>technology to try out different ones.
> Not all, unless you consider, e.g., 2067 and 2065, to be
> the same machine.
I suppose I do. Some posts here have called the 67 with DAT
> at 07:14 PM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>>The microcoded models all used different control store
>>technology to try out different ones.
> Not all, unless you consider, e.g., 2067 and 2065, to be
> the same machine.
off (panel switch) 65 mode.
>>Yes. As previously mentioned, much of S/360 was an experiment.
> More the fruits of earlier experiments, e.g., Stretch.
But the whole idea of one architecture for both commercial
and scientific users was pretty much untried. I am not sure
now how well the thoughts that IBM had before and during
development are documented.
>>And, I had almost forgotten, the 85 and 195 experiment
>>in unaligned access.
> To say nothing of the block mux.
robin....@gmail.com
Jul 22, 2012, 7:52:47 PM7/22/12
to
On Monday, 23 July 2012 03:40:12 UTC+10, John Levine wrote:
> >However, a 44 with the commercial instruction feature could run OS/360
> >and presumably other IBM S/360 operating systems.
>
> When did that come out? It's not in any of the /44 manuals I have.
I believe that the model 44 was running in 1966.
> >However, a 44 with the commercial instruction feature could run OS/360
> >and presumably other IBM S/360 operating systems.
>
> When did that come out? It's not in any of the /44 manuals I have.
John Levine
Jul 22, 2012, 10:13:36 PM7/22/12
to
>> When did that come out? It's not in any of the /44 manuals I have.
>
>I believe that the model 44 was running in 1966.
Not with commercial instructions. I have a bunch of manuals,
>
>I believe that the model 44 was running in 1966.
principles of operation, building a system, Fortran programmmer's
guide, stuff like that. No hint of any instructions beyond the
originally documented scientific subset.
John W Kennedy
Jul 22, 2012, 10:52:50 PM7/22/12
to
>> I
>> forget what the requirements were for BPS RPG and FORTRAN.
>>
>> TOS/360 and DOS/360 Assembler D, TOS/360 and DOS/360 Fortran D, TOS/360
>> and DOS/360 RPG D, TOS/360 and DOS/360 PL/I D, and TOS/360 COBOL D ran
>> in 16K.
>
> DOS PL/I was a subset. PL/I-F couldn't run.
> DOS FORTRAN and COBOL were probably subset versions.
> Is that the case?
> Fortran E and G required larger memories than 8K and 16K.
>
>> DOS/360 COBOL D was originally targetted for 16K, but ended up
>> needing 32.
>
> Precisely my point.
>
>> > Still, 8K was a far cry from 1K and 2K memories of earlier machines.
>> >
>> > It was actually difficult to write any significant S/360 code
>> > that would run in what remained in a 8K or 16K system
>> > after the OS was loaded.
>>
>>> An 8K system would have been principally for stand-alone systems.
>>
>>> Overlay techniques would have been needed for such memories.
>>
>> Overlay techniques were also used in OS/360. Indeed, one feature of
>> OS/360 overlay only worked in full-blown MVT.
John W Kennedy
Having switched to a Mac in disgust at Microsoft's combination of
incompetence and criminality.
John W Kennedy
Jul 22, 2012, 10:55:33 PM7/22/12
to
> Now that you mention it, XPL object code ran unaltered on any S/360
> having sufficient memory; even ran on the RCA Spectra compatible.
>
>> just as often
>> happened in MS-DOS days, when so many of the same lessons had to be
>> learned over again.
>
> Every one of the DOS programs that I have still run on newer and
> faster PCs, even on Windows XP.
> For that matter, they even ran/run under both MS DOS and DR DOS.
> The only DOS program that I tried under DOS mode within OS/2 also ran.
--
John W Kennedy
"I want everybody to be smart. As smart as they can be. A world of
ignorant people is too dangerous to live in."
-- Garson Kanin. "Born Yesterday"
John W Kennedy
Jul 22, 2012, 10:57:01 PM7/22/12
to
On 2012-07-22 12:06:14 +0000, Shmuel (Seymour J.) Metz said:
> In <50098dcf$0$11541$607e...@cv.net>, on 07/20/2012
> at 12:56 PM, John W Kennedy <jwk...@attglobal.net> said:
>
>> It had its own special operating system (44PS)
>
> However, a 44 with the commercial instruction feature could run OS/360
> and presumably other IBM S/360 operating systems.
Yes, but with some nasty speed problems and a serious timer drift, as I
> In <50098dcf$0$11541$607e...@cv.net>, on 07/20/2012
> at 12:56 PM, John W Kennedy <jwk...@attglobal.net> said:
>
>> It had its own special operating system (44PS)
>
> However, a 44 with the commercial instruction feature could run OS/360
> and presumably other IBM S/360 operating systems.
went on to say.
--
John W Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://www.SKenSoftware.com/Double%20Falshood
John W Kennedy
Jul 22, 2012, 11:02:36 PM7/22/12
to
On 2012-07-23 02:13:36 +0000, John Levine said:
>>>
>>> When did that come out? It's not in any of the /44 manuals I have.
>>
>> I believe that the model 44 was running in 1966.
>
> Not with commercial instructions. I have a bunch of manuals,
> principles of operation, building a system, Fortran programmmer's
> guide, stuff like that. No hint of any instructions beyond the
> originally documented scientific subset.
Most of those wouldn't have mentioned it, since they assumed 44PS (or
>>>
>>> When did that come out? It's not in any of the /44 manuals I have.
>>
>> I believe that the model 44 was running in 1966.
>
> Not with commercial instructions. I have a bunch of manuals,
> principles of operation, building a system, Fortran programmmer's
> guide, stuff like that. No hint of any instructions beyond the
> originally documented scientific subset.
Model 44 BPS) to begin with. And I don't think Functional
Characteristics mentioned it either, as it was fairly complicated, and
of no interest to ordinary 44 users. But it was in the System/360
System Summary, in the sales manual, and had its own documentation.
Note that this was /not/ regarded as a normal use of the machine -- it
was intended only for use as a transition tool.
--
John W Kennedy
"The first effect of not believing in God is to believe in anything...."
-- Emile Cammaerts, "The Laughing Prophet"
John W Kennedy
Jul 22, 2012, 11:08:27 PM7/22/12
to
On 2012-07-22 12:53:13 +0000, Shmuel (Seymour J.) Metz said:
> In <500af8f6$0$6053$607e...@cv.net>, on 07/21/2012
> at 02:46 PM, John W Kennedy <jwk...@attglobal.net> said:
>
>> Only the 92 was abandoned in that sense.
>
> Was the 91 a different machine, or only a renamed 92?
I imagine it was a degraded 92, but, since the 92 never shipped, it's
> In <500af8f6$0$6053$607e...@cv.net>, on 07/21/2012
> at 02:46 PM, John W Kennedy <jwk...@attglobal.net> said:
>
>> Only the 92 was abandoned in that sense.
>
> Was the 91 a different machine, or only a renamed 92?
hard to be certain. The 92 was announced sometime after the April '64
original 360 announcement, then was withdrawn in favor of an even
vaguer "90 series", which was finally realized in the 91, then the 95,
and the 195. (The 95 existed only as two supercharged 91s custom-made
for NASA.)
John W Kennedy
Jul 22, 2012, 11:09:23 PM7/22/12
to
--
John W Kennedy
"Sweet, was Christ crucified to create this chat?"
-- Charles Williams. "Judgement at Chelmsford"
robin....@gmail.com
Jul 23, 2012, 2:13:31 AM7/23/12
to
On Saturday, 21 July 2012 02:56:47 UTC+10, John W Kennedy wrote:
Thanks. Interesting. I knew that the /44 was hard wired.
> The 40 was a microcoded 16-bit machine.
>
> The 44 was an unmicrocoded 32-bit machine that omitted all SS
> instructions, plus BXLE, BXH, LM, STM, and EX. The 44 also offered an
> optional internal disk drive (the same that was used by the 1130) for
> users who didn't trust disks, but needed one for the operating system,
> compiler scratch files, and resident programs. It had its own special
> operating system (44PS) that offered only a ported version of FORTRAN G
> and an assembler without macros (though it /did/ have full
> conditional-assembly features in open code), and which was functionally
> much like DOS/360, except that, like OS/360 and unlike DOS/360, it
> could allocate disk files without the user having to set the exact
> extents.
>
> One funky feature was that the precision of 64-bit floating point could
> be reduced by a dial on the front panel, with a corresponding increase
> in speed. Since 44PS didn't offer multiprogramming, it didn't matter
> that the dial affected the whole machine.
>
> Custom hardware was available to add priority interrupts and a 32-bit
> version of the Direct Control feature, and there were operating-system
> extentions to match.
>
> There was an optional compatibility feature that added BXLE, BXH, LM,
> STM, and EX to the hardware, plus an invisible shadow core unit into
> which you could load special software to emulate the SS instructions.
> With that, you could run normal 360 software, but with some severe
> performance hits and a tendency for the clock to drift. (Even with the
> normal software, there was a slight clock-drift problem, because the
> MVC instruction wasn't available. To reduce, but not eliminate the
> problem, the 44 offered the improved interval timer option that ticked
> 76,800 times a second instead of 300, which was not available in other
> 360s in its price class.)
>
> If the restrictions didn't bother you, the 44 gave you the performance
> of a 65 at the price of a 40.
Not sure about that claim.
According to IBM, single-precision float add/subtract was 3.81uS;
double precision was 6.32uS.
Integer add/subtract was 1.75 uS.
I don't have timing figures for model 65, but do have for
ICL System 4/70 (=RCA Spectra) (4/70 apparently slower than 360/65):
Float add: AER single 2.4uS, ADR double 2.9uS
Integer add: AR 1.1uS
> But the 40 and 44 had nothing in common but the name and the price point.
Thanks. Interesting. I knew that the /44 was hard wired.
> The 40 was a microcoded 16-bit machine.
>
> The 44 was an unmicrocoded 32-bit machine that omitted all SS
> instructions, plus BXLE, BXH, LM, STM, and EX. The 44 also offered an
> optional internal disk drive (the same that was used by the 1130) for
> users who didn't trust disks, but needed one for the operating system,
> compiler scratch files, and resident programs. It had its own special
> operating system (44PS) that offered only a ported version of FORTRAN G
> and an assembler without macros (though it /did/ have full
> conditional-assembly features in open code), and which was functionally
> much like DOS/360, except that, like OS/360 and unlike DOS/360, it
> could allocate disk files without the user having to set the exact
> extents.
>
> One funky feature was that the precision of 64-bit floating point could
> be reduced by a dial on the front panel, with a corresponding increase
> in speed. Since 44PS didn't offer multiprogramming, it didn't matter
> that the dial affected the whole machine.
>
> Custom hardware was available to add priority interrupts and a 32-bit
> version of the Direct Control feature, and there were operating-system
> extentions to match.
>
> There was an optional compatibility feature that added BXLE, BXH, LM,
> STM, and EX to the hardware, plus an invisible shadow core unit into
> which you could load special software to emulate the SS instructions.
> With that, you could run normal 360 software, but with some severe
> performance hits and a tendency for the clock to drift. (Even with the
> normal software, there was a slight clock-drift problem, because the
> MVC instruction wasn't available. To reduce, but not eliminate the
> problem, the 44 offered the improved interval timer option that ticked
> 76,800 times a second instead of 300, which was not available in other
> 360s in its price class.)
>
> If the restrictions didn't bother you, the 44 gave you the performance
> of a 65 at the price of a 40.
Not sure about that claim.
According to IBM, single-precision float add/subtract was 3.81uS;
double precision was 6.32uS.
Integer add/subtract was 1.75 uS.
I don't have timing figures for model 65, but do have for
ICL System 4/70 (=RCA Spectra) (4/70 apparently slower than 360/65):
Float add: AER single 2.4uS, ADR double 2.9uS
Integer add: AR 1.1uS
> But the 40 and 44 had nothing in common but the name and the price point.
robin....@gmail.com
Jul 23, 2012, 2:24:55 AM7/23/12
to
On Monday, 23 July 2012 12:52:50 UTC+10, John W Kennedy wrote:
> On 2012-07-22 00:53:59 +0000, rrrrrr...@gmail.com said:
>
> > On Sunday, 22 July 2012 04:53:34 UTC+10, John W Kennedy wrote:
> >> &gt; On Saturday, 21 July 2012 01:27:33 UTC+10, John W Kennedy wrote:
> >> herrmannsfeldt wrote:
> >> &gt;&gt; &amp;gt;&amp;gt; John Levine
> >> &amp;amp;lt;jjjj...@iecc.com&amp;amp;gt; wrote:
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt; Model 40/44 and 50 timings
> >> were somewhat better.
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; The model 44 is hard to compare since
> >> it didn&amp;#39;t have
> >> &gt;&gt; MVC, a loop like
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; L, ST, LA, BCT is about 8us per word
> >> or 200us to move 100 bytes
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; assuming they were word aligned,
> >> probably twice that if
> >> &gt;&gt; they weren&amp;#39;t.
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; For the /65, an unaligned 100 byte
> >> MVC was about 40us,
> >> &gt;&gt; plus 3us for an
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; EX.
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt; For S/360, operands had to be aligned. It
> >> would take lots of shifts
> >> &gt;&gt; &amp;gt;&amp;gt; otherwise, or use an IC, STC loop.
> >> &gt;&gt; &amp;gt;
> >> &gt;&gt; &amp;gt; Not sure about that.
> >> &gt;&gt; &amp;gt; IIRC Watfor allowed unaligned variables, and shifted them
> >> &gt;&gt; &amp;gt; accordingly.
> >> &gt;&gt; &amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt; S/370 allowed for slow access to unaligned operands.
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; But remember that the point of the
> >> 360 series was that
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; programs worked the same way on all
> >> the models, so the
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; code had to be designed so it would
> >> work adequately even
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; at the low end.
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt; Most of the &amp;quot;work the same
> >> way&amp;quot; conveniently exclude timing,
> >> &gt;&gt; &amp;gt;&amp;gt; and also memory size.
> >> &gt;&gt; &amp;gt;
> >> &gt;&gt; &amp;gt; S/360 programs were upwards compatible.
> >> &gt;&gt; &amp;gt; Provided that the larger/faster target machine had the same
> >> &gt;&gt; &amp;gt; instruction set and at least the same amount of memory
> >> &gt;&gt; &amp;gt; (usually the case), then the program would run.
> >> &gt;&gt; IBM from the beginning, but mistakes were still made.)
> >> &gt;&gt;&gt;&gt; to run in small memories, though not necessarily fast.
> >> &gt;&gt;&gt;&gt; PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
> >> &gt;&gt;&gt;&gt; At the end of each compilation, it tells you the minimum
> >> &gt;&gt;&gt;&gt; amount of memory to keep the symbol table in core.
> >>>>>> (It will happily write it to disk, if needed.)
> >>
> >>>>> In terms of program size, IBM 360 programs and compilers weren't
> >>>>> designed to run in small memories. Fortran H required some 150K.
> >>
> >>>> And TOS/360 and DOS/360 was designed to run in 16K, and BOS/360 was
> >>>> designed to run in 8. Even OS/360 could run in 32K (and some /very/
> >>>> early statements were made about a 16K tape-resident version of OS/360).
> >>
> RPG is a compiler.
> >> I
> >> forget what the requirements were for BPS RPG and FORTRAN.
>
> >> TOS/360 and DOS/360 Assembler D, TOS/360 and DOS/360 Fortran D, TOS/360
> >> and DOS/360 RPG D, TOS/360 and DOS/360 PL/I D, and TOS/360 COBOL D ran
> >> in 16K.
>
> > DOS PL/I was a subset. PL/I-F couldn't run.
>
> You said nothing about subsets.
Neither did you. I merely pointed it out.
> > DOS FORTRAN and COBOL were probably subset versions.
> > Is that the case?
> > Fortran E and G required larger memories than 8K and 16K.
>
> >> DOS/360 COBOL D was originally targetted for 16K, but ended up
> >> needing 32.
>
> > Precisely my point.
>
> On 2012-07-22 00:53:59 +0000, rrrrrr...@gmail.com said:
>
> > On Sunday, 22 July 2012 04:53:34 UTC+10, John W Kennedy wrote:
> >> &gt; On Saturday, 21 July 2012 01:27:33 UTC+10, John W Kennedy wrote:
> >> &gt;&gt; On 2012-07-20 09:07:18 +0000, rrrr...@gmail.com said:
> >> &gt;&gt;
> >> &gt;&gt; &amp;gt; On Friday, 20 July 2012 16:23:34 UTC+10, glen
> >> &gt;&gt;
> >> herrmannsfeldt wrote:
> >> &gt;&gt; &amp;gt;&amp;gt; John Levine
> >> &amp;amp;lt;jjjj...@iecc.com&amp;amp;gt; wrote:
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt; Model 40/44 and 50 timings
> >> were somewhat better.
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; The model 44 is hard to compare since
> >> it didn&amp;#39;t have
> >> &gt;&gt; MVC, a loop like
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; L, ST, LA, BCT is about 8us per word
> >> or 200us to move 100 bytes
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; assuming they were word aligned,
> >> probably twice that if
> >> &gt;&gt; they weren&amp;#39;t.
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; For the /65, an unaligned 100 byte
> >> MVC was about 40us,
> >> &gt;&gt; plus 3us for an
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; EX.
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt; For S/360, operands had to be aligned. It
> >> would take lots of shifts
> >> &gt;&gt; &amp;gt;&amp;gt; otherwise, or use an IC, STC loop.
> >> &gt;&gt; &amp;gt;
> >> &gt;&gt; &amp;gt; Not sure about that.
> >> &gt;&gt; &amp;gt; IIRC Watfor allowed unaligned variables, and shifted them
> >> &gt;&gt; &amp;gt; accordingly.
> >> &gt;&gt; &amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt; S/370 allowed for slow access to unaligned operands.
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; But remember that the point of the
> >> 360 series was that
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; programs worked the same way on all
> >> the models, so the
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; code had to be designed so it would
> >> work adequately even
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; at the low end.
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt; Most of the &amp;quot;work the same
> >> way&amp;quot; conveniently exclude timing,
> >> &gt;&gt; &amp;gt;&amp;gt; and also memory size.
> >> &gt;&gt; &amp;gt;
> >> &gt;&gt; &amp;gt; S/360 programs were upwards compatible.
> >> &gt;&gt; &amp;gt; Provided that the larger/faster target machine had the same
> >> &gt;&gt; &amp;gt; instruction set and at least the same amount of memory
> >> &gt;&gt; &amp;gt; (usually the case), then the program would run.
> >> &gt;&gt;
> >> &gt;&gt; No, sometimes speed was critical. (Strong recommendations were made by
> >> &gt;&gt; IBM from the beginning, but mistakes were still made.)
> >> &gt;&gt;
> >> &gt;&gt;&gt;&gt; Many utilities, and also the PL/I (F) compiler, were designed
> >> &gt;&gt;&gt;&gt; to run in small memories, though not necessarily fast.
> >> &gt;&gt;&gt;&gt; PL/I (F) would run in 44K, leaving 20K for PCP on a 360/40.
> >> &gt;&gt;&gt;&gt; At the end of each compilation, it tells you the minimum
> >> &gt;&gt;&gt;&gt; amount of memory to keep the symbol table in core.
> >>>>>> (It will happily write it to disk, if needed.)
> >>
> >>>>> In terms of program size, IBM 360 programs and compilers weren't
> >>>>> designed to run in small memories. Fortran H required some 150K.
> >>
> >>>> And TOS/360 and DOS/360 was designed to run in 16K, and BOS/360 was
> >>>> designed to run in 8. Even OS/360 could run in 32K (and some /very/
> >>>> early statements were made about a 16K tape-resident version of OS/360).
> >>
> >>> And how many of the compilers ran in 8K? 16K?
>
> >> BOS/360 Assembler and RPG ran in 8K, as did BPS Basic Assembler.
>
> > Those are not compilers.
>
> Assembler occupies the same use space as a compiler.
That doesn't make it a compiler.
>
> >> BOS/360 Assembler and RPG ran in 8K, as did BPS Basic Assembler.
>
> > Those are not compilers.
>
> Assembler occupies the same use space as a compiler.
> RPG is a compiler.
> >> I
> >> forget what the requirements were for BPS RPG and FORTRAN.
>
> >> TOS/360 and DOS/360 Assembler D, TOS/360 and DOS/360 Fortran D, TOS/360
> >> and DOS/360 RPG D, TOS/360 and DOS/360 PL/I D, and TOS/360 COBOL D ran
> >> in 16K.
>
> > DOS PL/I was a subset. PL/I-F couldn't run.
>
> You said nothing about subsets.
> > DOS FORTRAN and COBOL were probably subset versions.
> > Is that the case?
> > Fortran E and G required larger memories than 8K and 16K.
>
> >> DOS/360 COBOL D was originally targetted for 16K, but ended up
> >> needing 32.
>
> > Precisely my point.
>
> >> > Still, 8K was a far cry from 1K and 2K memories of earlier machines.
>
>
> >>> It was actually difficult to write any significant S/360 code
> >> that would run in what remained in a 8K or 16K system
Peter Flass
Jul 23, 2012, 5:35:33 AM7/23/12
to
On 7/23/2012 2:24 AM, robin....@gmail.com wrote:
[I give up on the attributions, I'm hopelessly lost as to who said what]
>>
>>> DOS PL/I was a subset. PL/I-F couldn't run.
>>
>> You said nothing about subsets.
>
> Neither did you. I merely pointed it out.
>
>>> DOS FORTRAN and COBOL were probably subset versions.
>>> Is that the case?
>>> Fortran E and G required larger memories than 8K and 16K.
>>
>>>> DOS/360 COBOL D was originally targetted for 16K, but ended up
>>>> needing 32.
>>
PL/I-D was a very restricted subset of PL/I, though in retrospect it
was probably not too much below to ANSI subset-G. I think the compiler
would run on a 32K machine, so probably a 24K or 26K partition, but it
was horribly slow. DOS/VS finally gave DOS users a real PL/I compiler -
the Optimizing Compiler.
There was even PL/I for the 360/20, I have a manual somewhere. I'd love
to have seen that run.
--
Pete
[I give up on the attributions, I'm hopelessly lost as to who said what]
>>
>>> DOS PL/I was a subset. PL/I-F couldn't run.
>>
>> You said nothing about subsets.
>
> Neither did you. I merely pointed it out.
>
>>> DOS FORTRAN and COBOL were probably subset versions.
>>> Is that the case?
>>> Fortran E and G required larger memories than 8K and 16K.
>>
>>>> DOS/360 COBOL D was originally targetted for 16K, but ended up
>>>> needing 32.
>>
was probably not too much below to ANSI subset-G. I think the compiler
would run on a 32K machine, so probably a 24K or 26K partition, but it
was horribly slow. DOS/VS finally gave DOS users a real PL/I compiler -
the Optimizing Compiler.
There was even PL/I for the 360/20, I have a manual somewhere. I'd love
to have seen that run.
--
Pete
Shmuel Metz
Jul 22, 2012, 10:09:20 PM7/22/12
to
In <juhdts$2t7n$3...@leila.iecc.com>, on 07/22/2012
I'm not sure.
>It's not in any of the /44 manuals I have.
I thought that it was in the 44 functional specifications, but I can't
find it there. The description in Message-ID:
<50098dcf$0$11541$607e...@cv.net> is reasonably accurate.
I'm not sure.
>It's not in any of the /44 manuals I have.
find it there. The description in Message-ID:
<50098dcf$0$11541$607e...@cv.net> is reasonably accurate.
Shmuel Metz
Jul 22, 2012, 10:01:29 PM7/22/12
to
In <jui2k5$682$1...@speranza.aioe.org>, on 07/22/2012
processors that I listed were decimal machines with floating point.
at 11:33 PM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>But the whole idea of one architecture for both commercial and
>scientific users was pretty much untried.
Burroughs B5000; IBM 650, 7070, 7072, 7074; RCA 601. The IBM
>But the whole idea of one architecture for both commercial and
>scientific users was pretty much untried.
processors that I listed were decimal machines with floating point.
robin....@gmail.com
Jul 23, 2012, 12:07:40 PM7/23/12
to
On Monday, 23 July 2012 09:33:26 UTC+10, glen herrmannsfeldt wrote:
> But the whole idea of one architecture for both commercial
> and scientific users was pretty much untried.
By 1955 in the UK, the English Electric Company
> But the whole idea of one architecture for both commercial
> and scientific users was pretty much untried.
produced a machine capable of being used for scientific
and commercial uses (the DEUCE),
and by 1960 had added hardware specifically aimed at
improving its commercial prospects. The equipment included
a combined 80-column card reader-punch, with automatic
conversion of alphanumeric data on cards to and from BCD,
and the ability to read a card and to punch an (updated) card
one cycle later, as required for unit-record processing.
As well, EE enhanced the machine with mag tape decks,
suitable for large volume data processing.
robin....@gmail.com
Jul 23, 2012, 12:17:42 PM7/23/12
to
On Monday, 23 July 2012 12:01:29 UTC+10, Seymour J. Shmuel Metz wrote:
> In <jjjjj...@speranza.aioe.org>, on 07/22/2012
I think that the B5000 also was 1963.
There were probably many more that preceded the S/360.
> In <jjjjj...@speranza.aioe.org>, on 07/22/2012
> at 11:33 PM, glen herrmannsfeldt <gggg...@ugcs.caltech.edu> said:
>
> >But the whole idea of one architecture for both commercial and
> >scientific users was pretty much untried.
>
> Burroughs B5000; IBM 650, 7070, 7072, 7074; RCA 601. The IBM
> processors that I listed were decimal machines with floating point.
The English Electric KDF9 (1963) can be added to the list.
>
> >But the whole idea of one architecture for both commercial and
> >scientific users was pretty much untried.
>
> Burroughs B5000; IBM 650, 7070, 7072, 7074; RCA 601. The IBM
> processors that I listed were decimal machines with floating point.
I think that the B5000 also was 1963.
There were probably many more that preceded the S/360.
John Levine
Jul 23, 2012, 12:39:26 PM7/23/12
to
>> If the restrictions didn't bother you, the 44 gave you the performance
>> of a 65 at the price of a 40.
>
>Not sure about that claim.
>According to IBM, single-precision float add/subtract was 3.81uS;
>double precision was 6.32uS.
>
>Integer add/subtract was 1.75 uS.
>
>I don't have timing figures for model 65
I have the /67 manual which I think was the same speed as the /65.
>> of a 65 at the price of a 40.
>
>Not sure about that claim.
>According to IBM, single-precision float add/subtract was 3.81uS;
>double precision was 6.32uS.
>
>Integer add/subtract was 1.75 uS.
>
>I don't have timing figures for model 65
44 67
AER 3,81 1.68
AD 7.53 2.45
MER 14 4.05
DDR 124 13.35
Floating multiply and divide on the /44 got a lot faster if you turned
the knob to decrease the number of digits, but still slower than the
/67.
Peter Flass
Jul 23, 2012, 7:44:40 PM7/23/12
to
On 7/22/2012 10:09 PM, Shmuel (Seymour J.) Metz wrote:
> In <juhdts$2t7n$3...@leila.iecc.com>, on 07/22/2012
> at 05:40 PM, John Levine <jo...@iecc.com> said:
>
>> When did that come out?
>
> I'm not sure.
>
>> It's not in any of the /44 manuals I have.
>
> I thought that it was in the 44 functional specifications, but I can't
> find it there. The description in Message-ID:
> <50098dcf$0$11541$607e...@cv.net> is reasonably accurate.
>
Perhaps it was an RPQ.
> In <juhdts$2t7n$3...@leila.iecc.com>, on 07/22/2012
> at 05:40 PM, John Levine <jo...@iecc.com> said:
>
>> When did that come out?
>
> I'm not sure.
>
>> It's not in any of the /44 manuals I have.
>
> I thought that it was in the 44 functional specifications, but I can't
> find it there. The description in Message-ID:
> <50098dcf$0$11541$607e...@cv.net> is reasonably accurate.
>
--
Pete
Shmuel Metz
Jul 23, 2012, 9:22:14 AM7/23/12
to
In <500cc02b$0$11511$607e...@cv.net>, on 07/22/2012
at 11:08 PM, John W Kennedy <jwk...@attglobal.net> said:
>The 92 was announced sometime after the April '64
>original 360 announcement, then was withdrawn in favor of an even
>vaguer "90 series", which was finally realized in the 91, then the
>95, and the 195.
I would consider the 195 to be a distinct machine.
>The 92 was announced sometime after the April '64
>original 360 announcement, then was withdrawn in favor of an even
>vaguer "90 series", which was finally realized in the 91, then the
>95, and the 195.
Shmuel Metz
Jul 23, 2012, 9:25:29 AM7/23/12
to
In <500cbd7d$0$11531$607e...@cv.net>, on 07/22/2012
performance issue; there was also the restricted core size.
Nonetheless, I did know of a shop running PCP on a 44.
at 10:57 PM, John W Kennedy <jwk...@attglobal.net> said:
>Yes, but with some nasty speed problems and a serious timer drift,
>as I went on to say.
For OS/360 the speed of the simulated instructions was not the only
>Yes, but with some nasty speed problems and a serious timer drift,
>as I went on to say.
performance issue; there was also the restricted core size.
Nonetheless, I did know of a shop running PCP on a 44.
robin....@gmail.com
Jul 23, 2012, 9:49:54 PM7/23/12
to robin....@gmail.com
On Tuesday, 24 July 2012 02:39:26 UTC+10, John Levine wrote:
> > If the restrictions didn't bother you, the 44 gave you the performance
> >> of a 65 at the price of a 40.
>
> >Not sure about that claim.
> >According to IBM, single-precision float add/subtract was 3.81uS;
> >double precision was 6.32uS.
>
> >Integer add/subtract was 1.75 uS.
>
> >I don't have timing figures for model 65
>
> I have the /67 manual which I think was the same speed as the /65.
John, I think that you are right. The difference was the DAT box.
> > If the restrictions didn't bother you, the 44 gave you the performance
> >> of a 65 at the price of a 40.
>
> >Not sure about that claim.
> >According to IBM, single-precision float add/subtract was 3.81uS;
> >double precision was 6.32uS.
>
> >Integer add/subtract was 1.75 uS.
>
> >I don't have timing figures for model 65
>
> I have the /67 manual which I think was the same speed as the /65.
> 44 67 S4/70
> AER 3,81 1.68 2.4
> AD 7.53 2.45 4.0
> MER 14 4.05 4.9
10.1
DER 8.3
> DDR 124 13.35 17.6
HER 1.1
Shmuel Metz
Jul 23, 2012, 10:26:23 PM7/23/12
to
In <500af8f6$0$6053$607e...@cv.net>, on 07/21/2012
at 02:46 PM, John W Kennedy <jwk...@attglobal.net> said:
>That does not mean that the 360/64,66,67 was not an experiment.
>For one thing, I do not see that the Atlas had anything equivalent
>to their Associative Registers (known in the 370 in greatly
>expanded form as the Translation Lookaside Buffer).
It was page tables that the Atlas didn't have. It did have an
associative memory, with one word for every page frame (512 48-bit
words).
John W Kennedy
Jul 31, 2012, 12:07:23 AM7/31/12
to
functions, and the 44 regularly came within a few percentage points of
the 65.
--
John W Kennedy
"When a man contemplates forcing his own convictions down another man's
throat, he is contemplating both an unchristian act and an act of
treason to the United States."
-- Joy Davidman, "Smoke on the Mountain"
John W Kennedy
Jul 31, 2012, 12:09:30 AM7/31/12
to
On 2012-07-23 09:35:33 +0000, Peter Flass said:
> On 7/23/2012 2:24 AM, robin....@gmail.com wrote:
>
> [I give up on the attributions, I'm hopelessly lost as to who said what]
>
>>>
>>>> DOS PL/I was a subset. PL/I-F couldn't run.
>>>
>>> You said nothing about subsets.
>>
>> Neither did you. I merely pointed it out.
>>
>>>> DOS FORTRAN and COBOL were probably subset versions.
>>>> Is that the case?
>>>> Fortran E and G required larger memories than 8K and 16K.
>>>
>>>>> DOS/360 COBOL D was originally targetted for 16K, but ended up
>>>>> needing 32.
>>>
>
> PL/I-D was a very restricted subset of PL/I, though in retrospect it
> was probably not too much below to ANSI subset-G. I think the compiler
> would run on a 32K machine, so probably a 24K or 26K partition, but it
> was horribly slow.
It would run in a 16K machine.
> On 7/23/2012 2:24 AM, robin....@gmail.com wrote:
>
> [I give up on the attributions, I'm hopelessly lost as to who said what]
>
>>>
>>>> DOS PL/I was a subset. PL/I-F couldn't run.
>>>
>>> You said nothing about subsets.
>>
>> Neither did you. I merely pointed it out.
>>
>>>> DOS FORTRAN and COBOL were probably subset versions.
>>>> Is that the case?
>>>> Fortran E and G required larger memories than 8K and 16K.
>>>
>>>>> DOS/360 COBOL D was originally targetted for 16K, but ended up
>>>>> needing 32.
>>>
>
> PL/I-D was a very restricted subset of PL/I, though in retrospect it
> was probably not too much below to ANSI subset-G. I think the compiler
> would run on a 32K machine, so probably a 24K or 26K partition, but it
> was horribly slow.
> DOS/VS finally gave DOS users a real PL/I compiler - the Optimizing Compiler.
>
> There was even PL/I for the 360/20, I have a manual somewhere. I'd
> love to have seen that run.
--
John W Kennedy
"Never try to take over the international economy based on a radical
feminist agenda if you're not sure your leader isn't a transvestite."
-- David Misch: "She-Spies", "While You Were Out"
John W Kennedy
Jul 31, 2012, 12:10:22 AM7/31/12
to
--
John W Kennedy
A proud member of the reality-based community.
John W Kennedy
Jul 31, 2012, 12:12:24 AM7/31/12
to
On 2012-07-23 13:22:14 +0000, Shmuel (Seymour J.) Metz said:
> In <500cc02b$0$11511$607e...@cv.net>, on 07/22/2012
> at 11:08 PM, John W Kennedy <jwk...@attglobal.net> said:
>
>> The 92 was announced sometime after the April '64
>> original 360 announcement, then was withdrawn in favor of an even
>> vaguer "90 series", which was finally realized in the 91, then the
>> 95, and the 195.
>
> I would consider the 195 to be a distinct machine.
It had a good many engineering artifacts identical to the 91, and to
> In <500cc02b$0$11511$607e...@cv.net>, on 07/22/2012
> at 11:08 PM, John W Kennedy <jwk...@attglobal.net> said:
>
>> The 92 was announced sometime after the April '64
>> original 360 announcement, then was withdrawn in favor of an even
>> vaguer "90 series", which was finally realized in the 91, then the
>> 95, and the 195.
>
> I would consider the 195 to be a distinct machine.
the 85, as well. It seems to have drawn from both of them.
--
John W Kennedy
"There are those who argue that everything breaks even in this old dump
of a world of ours. I suppose these ginks who argue that way hold that
because the rich man gets ice in the summer and the poor man gets it in
the winter things are breaking even for both. Maybe so, but I'll swear
I can't see it that way."
-- The last words of Bat Masterson
glen herrmannsfeldt
Jul 31, 2012, 3:07:19 AM7/31/12
to
John W Kennedy <jwk...@attglobal.net> wrote:
(snip)
>> I would consider the 195 to be a distinct machine.
> It had a good many engineering artifacts identical to the 91,
> and to the 85, as well. It seems to have drawn from both of them.
At least the cache from the 85 and the pipelined floating
point, more or less, from the 91.
Stories were that with the cache, and a usual instruction mix
(for scientific work) the 85 and 91 were close to the same speed.
Also, when you ordered a 91, they gave you an 85 while it
was being built. (Good chance to benchmark the two.)
-- glen
(snip)
>> I would consider the 195 to be a distinct machine.
> It had a good many engineering artifacts identical to the 91,
> and to the 85, as well. It seems to have drawn from both of them.
point, more or less, from the 91.
Stories were that with the cache, and a usual instruction mix
(for scientific work) the 85 and 91 were close to the same speed.
Also, when you ordered a 91, they gave you an 85 while it
was being built. (Good chance to benchmark the two.)
-- glen
sorrel...@gmail.com
Mar 19, 2013, 10:29:24 AM3/19/13
to
On Friday, July 20, 2012 8:01:25 PM UTC-6, robin....@gmail.com wrote:
>And how many of the compilers ran in 8K? 16K?
>
>And how many of the compilers ran in 8K? 16K?
>
>Still, 8K was a far cry from 1K and 2K memories of earlier machines.
>
>It was actually difficult to write any significant S/360 code
>that would run in what remained in a 8K or 16K system
>after the OS was loaded.
>
>An 8K system would have been principally for stand-alone systems.
>
>Overlay techniques would have been needed for such memories.
At the Standard Bank we ran our entire Branch Accounting Suite on a 360/25 with 16K. The code was written in Cobol with transient ($$) routines written in Assembler. I did not ever consider that there was any other way to write other than overlays.
>
>It was actually difficult to write any significant S/360 code
>that would run in what remained in a 8K or 16K system
>after the OS was loaded.
>
>An 8K system would have been principally for stand-alone systems.
>
>Overlay techniques would have been needed for such memories.
And the 360/20 taught me that consoles were for sissies.
0 new messages