In <k82r8f$a1...@dont-email.me>, on 11/15/2012
at 08:44 AM, Peter Flass <Peter_Fl...@Yahoo.com> said:
>Yes, but the discussion was about comparing emulated 360s to real
>ones (I believe), so you'd want to try to keep the outboard parts
>the same as much as possible.
What's special about the outboard components? If you're simulating
part of it with better technology, why not simulate all of it with
better technology?
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 Wed, 14 Nov 2012 13:09:22 -0000, Peter Flass <Peter_Fl...@yahoo.com>
wrote:
> On 11/13/2012 9:10 PM, hanco...@bbs.cpcn.com wrote:
>> Ok, a PC's CPU is faster today, but what about I/O and the channels,
>> and multiprogramming? The S/360 hardware was designed to handle all
>> of that efficiently, how efficiently would a PC handle it all?
>> Suppose we hung an early CICS and a few terminals off of the PC
>> emulating a S/360--how would they be accomodated in terms of
>> processing time?
> Now that would be an interesting experiment. I don't know if Hercules
> has the ability to drive a synch. card, these days it all seems to be
> oriented toward IP, and also CICS isn't available (again AFAIK).
There is/was a a CICS for the PC; I've no idea if it was merely a screen
lookalike, or had a database backend.
> Set up a PC with a synchronous card attached to a 3270 control unit with
> a few displays and printers hung off it. You'd have to test with TSO or
> VM to see how it performs.
> On Wed, 14 Nov 2012 13:09:22 -0000, Peter Flass <Peter_Fl...@yahoo.com>
> wrote:
>> On 11/13/2012 9:10 PM, hanco...@bbs.cpcn.com wrote:
>>> Ok, a PC's CPU is faster today, but what about I/O and the channels,
>>> and multiprogramming? The S/360 hardware was designed to handle all
>>> of that efficiently, how efficiently would a PC handle it all?
>>> Suppose we hung an early CICS and a few terminals off of the PC
>>> emulating a S/360--how would they be accomodated in terms of
>>> processing time?
>> Now that would be an interesting experiment. I don't know if Hercules
>> has the ability to drive a synch. card, these days it all seems to be
>> oriented toward IP, and also CICS isn't available (again AFAIK).
> There is/was a a CICS for the PC; I've no idea if it was merely a screen
> lookalike, or had a database backend.
>> Set up a PC with a synchronous card attached to a 3270 control unit
>> with a few displays and printers hung off it. You'd have to test with
>> TSO or VM to see how it performs.
TXSeries? Previous OS/2 software had the ability to connect with Database Manager using SQL. I'd presume the windoze flavors have similar capability.
On Nov 15, 11:04 am, Anne & Lynn Wheeler <l...@garlic.com> wrote:
> problem is the outboard parts haven't been built for decades ... 360s
> would be 2311 & 2314 disks and terminals would be tty33, tty35, 2741,
> 1052 ... maybe a couple 2260 displays.
What about a comparison of the S/360-75 to a PC in terms of workload,
using the appropriate peripherals?
My recollection from college days was that a 360-65 handled a
substantial amount of batch processing from many users through RJE
sites. I don't know how much on-line processing was done back then or
how many terminals could be hung on the machine (FWIW, we hung four
terminals off of S/360-40 with a mini-CICS).
The -75 used quite a bit of off-line storage in terms of moutable
tapes and disks. For the equivalent, I would suggest the PC would use
varied flashdrives on all its serial ports, mounting and demounting as
jobs came and left. Perhaps some i/O through floppy drives, too.
For on-line service, I would expect the same PC to support
straightforward web pages to about ten simultaneous users. Given the
limitation of "green-on-glass" applications years ago, that shouldn't
be much of a problem, including updating disk files.
For RJE, I would have say ten workstations (perhaps a "thin client")
with a flashdrive input (equating the card reader) and a printer.
I would expect the central PC to be able to manage all of the above
activity from its console, in an analgous fashion the way HASP and
other systems software managed all the above in a large S/360 shop.
hanco...@bbs.cpcn.com writes:
> What about a comparison of the S/360-75 to a PC in terms of workload,
> using the appropriate peripherals?
> My recollection from college days was that a 360-65 handled a
> substantial amount of batch processing from many users through RJE
> sites. I don't know how much on-line processing was done back then or
> how many terminals could be hung on the machine (FWIW, we hung four
> terminals off of S/360-40 with a mini-CICS).
> The -75 used quite a bit of off-line storage in terms of moutable
> tapes and disks. For the equivalent, I would suggest the PC would use
> varied flashdrives on all its serial ports, mounting and demounting as
> jobs came and left. Perhaps some i/O through floppy drives, too.
> For on-line service, I would expect the same PC to support
> straightforward web pages to about ten simultaneous users. Given the
> limitation of "green-on-glass" applications years ago, that shouldn't
> be much of a problem, including updating disk files.
> For RJE, I would have say ten workstations (perhaps a "thin client")
> with a flashdrive input (equating the card reader) and a printer.
> I would expect the central PC to be able to manage all of the above
> activity from its console, in an analgous fashion the way HASP and
> other systems software managed all the above in a large S/360 shop.
the 2067 should be same as 2065 except when running in virtual memory
mode ... where memory cycle increases from 750ns to 900ns doing the
virtual address translation (20% increase in memory cycle time, which
should be corresponding decrease in mip rate). 360/65 has been
considered closer to .5mip rate in real world, because of heavy
interference between i/o activity on memory bus ... and 360/67 then
should be 20% slow-down from that (i.e. closer to .4mip).
360/75 considered much faster than 360/65 ... more like 1mip
1979 on early engineering model of first 4341 ... i ran llnl rain
benchmark (they were looking at large numbers of 4341 for compute
farm). 4341 ran the benchmark 21% faster than 370/158 ... assuming 158
is 1mip processor ... that puts original 4341 more like 1.2mips
(rather than .88 mips). Rather than 360/75 and 4341 being approx.
same mip rate, 360/75 should be more like same mip rate as 370/158
(with 4341 21% faster). old post with rain benchmark
http://www.garlic.com/~lynn/2000d.html#0
the original post includes this reference comparing cp67-360/67 to
vm370-3081
http://www.garlic.com/~lynn/93.html#31</a> Big I/O or Kicking the Mainframe out the Door
I claim that I did i/o operations with much less than half the
pathlength of mvt. so I would claim that mvt on 360/75 would have
approx. same i/o rate (or less) than i would get out of cp67 on 360/67
(i also did much better job in cp67 maintaining multiprogramming level
keeping processor at 100% utilization ... even with lower overhead)
45 2314 drivers @29mbyte is 1.3gbyte ... less than current real storage
sizes (actual 2314 would have somewhat less capacity per pack because
of formating overhead)
say customer has 200 2314 packs ... that is is 6gbytes ... still less
than can get in modern real storage.
a library with 1000 tapes would be 20gbytes; it is possible to get
server system with 32gbytes (and more) of real storage ... more than
typical library of disk packs and tape reels.
four 360 selector channels at 1mbyte each ... but sustain would be more
like maybe 50 4k disk records/sec and 50 4k tape records/sec (or
equivalent) ... say max. sustained 400kbytes/sec transfer. current
system would easily handle all storage in real memory ... doesn't even
need to do i/o to access the data.
say 100 terminals working non-stop at 10chars/sec is peak 1kbytes/sec.
(i had 80 concurrent active users on 360/67 ... so total could easy be
over 100).
4800baud for rje ... is 480char/sec ... even ten running non-stop is
5kbytes/sec.
pc with gbit ethernet for communication gives 100mbyte/sec ... could
trivially handle all the communication workload (say by 20,000 times)
two chip e5-2600 is clocked at over 500BIPs ... over 500,000 times
faster than 360/75. all data from disk and tape being able to fit in
real storage ... means that data from tape&disk in real storage would be
available at gbyte speeds ... can get ddr3 for e5-2600 at over
10gbyte/sec ... easily tens of thousand times faster.
-- virtualization experience starting Jan1968, online at home since Mar1970
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 article <50a003aa$25$fuzhry+tra$mr2...@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamt...@library.lspace.org.invalid>
wrote:
> In <k7oa6d$pe...@dont-email.me>, on 11/11/2012
> at 08:53 AM, Peter Flass <Peter_Fl...@Yahoo.com> said:
> >Of course that still leaves ten possible base registers, so you > >could directly address 40K. You'd have to have pretty lousy > >programming technique to need more than a few base registers in a > >single module.
> That would be relevant in an architecture with dedicated base
> register. In the S360, the same 16 registers serve as accumulators,
> base registers and index registers, and it is not hard to run out.
Arruuugh! The instruction length was too small. But the idea was that IBM wanted a homogeneous set of machines to sell to 1401 users up. (Didn't quite make it the 20 was not quite a member of the family.)
DEC managed quite a nice series of 36 bit machines with 18 bit addresses which addressed 256K of 36 bit words.
In <proto-123D0B.10594107012...@news.panix.com>, on 01/07/2013
at 10:59 AM, Walter Bushell <pr...@panix.com> said:
>DEC managed quite a nice series of 36 bit machines with 18 bit >addresses which addressed 256K of 36 bit words.
One of the few lines that had true byte addressability, albeit only on
two instructions. The others[1] that I know of are the Burroughs
B1700, CDC 3600 and IBM 7030.
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 <proto-123D0B.10594107012...@news.panix.com>, on 01/07/2013
> at 10:59 AM, Walter Bushell <pr...@panix.com> said:
>>DEC managed quite a nice series of 36 bit machines with 18 bit >>addresses which addressed 256K of 36 bit words.
>One of the few lines that had true byte addressability, albeit only on
>two instructions. The others[1] that I know of are the Burroughs
>B1700, CDC 3600 and IBM 7030.
Define true-byte addressability. The B2500 had it (by virtual of being
digit addressable :-). The B2500 was unrelated to the B1700 (aside from
a couple of shared peripherals).
In <A5IGs.161$oR5....@fed05.iad>, on 01/07/2013
at 10:36 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>Define true-byte addressability.
The ability to address an arbitrary byte up to an architected size
limit. I cheated slightly on the PDP-6 and -10 in that they didn't
provide for bytes that crossed word boundaries.
>The B2500 had it (by virtual of being digit addressable :-).
No; you need addressability to the bit, which the B2500 did not have.
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 <A5IGs.161$oR5....@fed05.iad>, on 01/07/2013
> at 10:36 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>>Define true-byte addressability.
> The ability to address an arbitrary byte up to an architected size
> limit. I cheated slightly on the PDP-6 and -10 in that they didn't
> provide for bytes that crossed word boundaries.
"True-byte"?
I think you just made that up.
:)
Google says:
byte
A group of binary digits or bits (usually eight) operated on as a unit.
and Webster:
a unit of computer information or data-storage capacity that consists
of a group of eight bits and that is used especially to represent an
alphanumeric character
Seems to me, if you can address any bit, that's more like bit-addressable.
If you can address bytes, that's 8 bit chunks.
True-bytes just sounds weird and doesn't pass the Google test.
>> In <A5IGs.161$oR5....@fed05.iad>, on 01/07/2013
>> at 10:36 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>>> Define true-byte addressability.
>> The ability to address an arbitrary byte up to an architected size
>> limit. I cheated slightly on the PDP-6 and -10 in that they didn't
>> provide for bytes that crossed word boundaries.
> "True-byte"?
> I think you just made that up.
> :)
> Google says:
> byte
> A group of binary digits or bits (usually eight) operated on as a unit.
> and Webster:
> a unit of computer information or data-storage capacity that consists
> of a group of eight bits and that is used especially to represent an
> alphanumeric character
> Seems to me, if you can address any bit, that's more like bit-addressable.
> If you can address bytes, that's 8 bit chunks.
> True-bytes just sounds weird and doesn't pass the Google test.
Aren't "true bytes" something out of a "Twilight" movie?
> > In <A5IGs.161$oR5....@fed05.iad>, on 01/07/2013
> > at 10:36 PM, sc...@slp53.sl.home (Scott Lurndal) said:
> >>Define true-byte addressability.
> > The ability to address an arbitrary byte up to an architected size
> > limit. I cheated slightly on the PDP-6 and -10 in that they didn't
> > provide for bytes that crossed word boundaries.
> "True-byte"?
> I think you just made that up.
> :)
> Google says:
> byte
> A group of binary digits or bits (usually eight) operated on as a unit.
> and Webster:
> a unit of computer information or data-storage capacity that consists
> of a group of eight bits and that is used especially to represent an
> alphanumeric character
> Seems to me, if you can address any bit, that's more like bit-addressable.
> If you can address bytes, that's 8 bit chunks.
No reason that bytes should always be 8 bit chunks, except the industry has standardized. For a long time it was 6 bits, and some confusers addressed 4 bit bytes -- IBM's 1620, but they weren't called bytes. Maybe, someday bytes will be 16 bits or more.
> True-bytes just sounds weird and doesn't pass the Google test.
>> > In <A5IGs.161$oR5....@fed05.iad>, on 01/07/2013
>> > at 10:36 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>> >>Define true-byte addressability.
>> > The ability to address an arbitrary byte up to an architected size
>> > limit. I cheated slightly on the PDP-6 and -10 in that they didn't
>> > provide for bytes that crossed word boundaries.
>> "True-byte"?
>> I think you just made that up.
>> :)
>> Google says:
>> byte
>> A group of binary digits or bits (usually eight) operated on as a unit.
>> and Webster:
>> a unit of computer information or data-storage capacity that consists
>> of a group of eight bits and that is used especially to represent an
>> alphanumeric character
>> Seems to me, if you can address any bit, that's more like bit-addressable.
>> If you can address bytes, that's 8 bit chunks.
> No reason that bytes should always be 8 bit chunks, except the > industry has standardized. For a long time it was 6 bits, and some > confusers addressed 4 bit bytes -- IBM's 1620, but they weren't called > bytes. Maybe, someday bytes will be 16 bits or more.
Yep. On the 14xx they were 6 bits[1] but they were called characters.
I first heard the term bytes with the introduction of S/360.
> In <A5IGs.161$oR5....@fed05.iad>, on 01/07/2013
> at 10:36 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>>Define true-byte addressability.
> The ability to address an arbitrary byte up to an architected size
> limit. I cheated slightly on the PDP-6 and -10 in that they didn't
> provide for bytes that crossed word boundaries.
Not with one instruction. However, you could use two load/dep instruction
pairs if there really was a byte which crossed a word boundardy. I can't
think of any which would naturally happen (other than bits moved from
another architecture).
>>The B2500 had it (by virtual of being digit addressable :-).
> No; you need addressability to the bit, which the B2500 did not have.
On Jan 8, 9:11 am, Dan Espen <des...@verizon.net> wrote:
> > No reason that bytes should always be 8 bit chunks, except the
> > industry has standardized. For a long time it was 6 bits, and some
> > confusers addressed 4 bit bytes -- IBM's 1620, but they weren't called
> > bytes. Maybe, someday bytes will be 16 bits or more.
> Yep. On the 14xx they were 6 bits[1] but they were called characters.
> I first heard the term bytes with the introduction of S/360.
> [1] Not counting word mark and parity.
I believe the term byte was first used for Stretch, which had 8 bit
characters.
Parity normally isn't counted since it is not accessible by
programmers, only hardware.
I'm not sure if 14xx wordmarks were _directly_ accessible or had to be
referenced as part of a different instruction, eg, moving a character
string along with its wordmarks as opposed to moving a character
string without its wordmarks.
I never quite grasped the overall concept of wordmarks, other than
they served as a convenient delimiter to variable length fields.
Presumably, it was more efficient to use them rather than have
instructions include a field length, so instructions were simpler.
hanco...@bbs.cpcn.com writes:
> On Jan 8, 9:11 am, Dan Espen <des...@verizon.net> wrote:
>> > No reason that bytes should always be 8 bit chunks, except the
>> > industry has standardized. For a long time it was 6 bits, and some
>> > confusers addressed 4 bit bytes -- IBM's 1620, but they weren't called
>> > bytes. Maybe, someday bytes will be 16 bits or more.
>> Yep. On the 14xx they were 6 bits[1] but they were called characters.
>> I first heard the term bytes with the introduction of S/360.
>> [1] Not counting word mark and parity.
> I believe the term byte was first used for Stretch, which had 8 bit
> characters.
> Parity normally isn't counted since it is not accessible by
> programmers, only hardware.
> I'm not sure if 14xx wordmarks were _directly_ accessible or had to be
> referenced as part of a different instruction, eg, moving a character
> string along with its wordmarks as opposed to moving a character
> string without its wordmarks.
> I never quite grasped the overall concept of wordmarks, other than
> they served as a convenient delimiter to variable length fields.
> Presumably, it was more efficient to use them rather than have
> instructions include a field length, so instructions were simpler.
Word marks delimited instructions and fields.
There was a word mark under the OP code and in most cases a word mark
at the end of an instruction[1].
A word mark is indicated with an underscore:
_Bxxx_ plain branch instruction
_BxxxC_ branch on condition
_BxxxyyyZ_ branch to xxx if yyy contains character Z
With fields you could easily clear a group of unequal sized
accumulators:
A1 _aa
B1 _bbbb
C1 _cccccc
_S ccc ccc where ccc=address of C1 subract C1 from C1 (zero accumulator)
_S clear B1 (next field) _S clear A1 (next field)
_ next instruction (ends 1 character subtract)
Most opcodes worked until the word mark was found in the target.
L (Load) copied the word mark from the source field to the target field
clearing target word marks.
1. SW (Set Word Mark) didn't require a trailing word mark.
Anyone familiar with load decks knows why.
>>> In <A5IGs.161$oR5....@fed05.iad>, on 01/07/2013
>>> at 10:36 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>>>> Define true-byte addressability.
>>> The ability to address an arbitrary byte up to an architected size
>>> limit. I cheated slightly on the PDP-6 and -10 in that they didn't
>>> provide for bytes that crossed word boundaries.
>> "True-byte"?
>> I think you just made that up.
>> :)
>> Google says:
>> byte
>> A group of binary digits or bits (usually eight) operated on
>> as a unit.
>> and Webster:
>> a unit of computer information or data-storage capacity that
>> consists of a group of eight bits and that is used especially
>> to represent an alphanumeric character
>> Seems to me, if you can address any bit, that's more like
>> bit-addressable. If you can address bytes, that's 8 bit chunks.
>> True-bytes just sounds weird and doesn't pass the Google test.
> Aren't "true bytes" something out of a "Twilight" movie?
I thought it was that movie with Ahnold and Jamie Lee Curtis.
-- /~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
In <proto-EC386F.08385808012...@news.panix.com>, on 01/08/2013
at 08:38 AM, Walter Bushell <pr...@panix.com> said:
>No reason that bytes should always be 8 bit chunks,
Back in CDC land they often assumed a byte size of 12, and I believe
that some of the GE types assumed a byte size of 9. On the machine for
which the word byte was coined, you could specify any byte size from 1
to 64; the PDP-6 and -10 had a 36-bit limit.
BTW, that's the reason that communications standards use the term
octet; there's no ambiguity about the size.
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
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
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
