>> 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
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.
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
On 7/22/2012 10:09 PM, Shmuel (Seymour J.) Metz wrote:
> In <juhdts$2t7...@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$607ed...@cv.net> is reasonably accurate.
In <500cc02b$0$11511$607ed...@cv.net>, on 07/22/2012
at 11:08 PM, John W Kennedy <jwke...@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.
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 spamt...@library.lspace.org
In <500cbd7d$0$11531$607ed...@cv.net>, on 07/22/2012
at 10:57 PM, John W Kennedy <jwke...@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
performance issue; there was also the restricted core size.
Nonetheless, I did know of a shop running PCP on a 44.
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 spamt...@library.lspace.org
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.
> 44 67 S4/70
> AER 3,81 1.68 2.4
> AD 7.53 2.45 4.0
> MER 14 4.05 4.9
In <500af8f6$0$6053$607ed...@cv.net>, on 07/21/2012
at 02:46 PM, John W Kennedy <jwke...@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).
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 spamt...@library.lspace.org
> 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.
There was a manual that gave timing estimates for the FORTRAN library 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"
> On 7/23/2012 2:24 AM, robin.vow...@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.
> 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.
It was superior to PL/I D in one respect; it allowed arrays of structures.
-- 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"
> On 7/22/2012 10:09 PM, Shmuel (Seymour J.) Metz wrote:
>> In <juhdts$2t7...@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$607ed...@cv.net> is reasonably accurate.
> Perhaps it was an RPQ.
No, it was optional, but a standard option.
-- John W Kennedy
A proud member of the reality-based community.
On 2012-07-23 13:22:14 +0000, Shmuel (Seymour J.) Metz said:
> In <500cc02b$0$11511$607ed...@cv.net>, on 07/22/2012
> at 11:08 PM, John W Kennedy <jwke...@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 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
>> 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.)
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?
>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.
And the 360/20 taught me that consoles were for sissies.
