Assembler vs. COBOL--processing time, space needed

[hanc...@bbs.cpcn.com]

In the earlier days of System/360 many sites used Assembler
programming, not COBOL, because their machines were slow and had
limited memory.

Just out of curiousity, I was wondering how much space and time was
saved by writing a typical business application program in Assembler
rather than COBOL in System/360.

Imagine an application where a sorted sequential tape file is input,
along with a sorted card deck of update records to that file. A new
revised tape file is output. Also, a log report of updated records
and rejected cards is printed.

Generally speaking, would anyone care to discuss the techniques in
Assembler that would save significant memory and processing time in an
application like the above?

[Charlie Gibbs]

In article
<3cb72b11-0447-4a11...@ez26g2000vbb.googlegroups.com>,

I think a lot of it was simply that compilers of the day didn't
generate code that was nearly as efficient as modern ones do.
Optimizers were quite rudimentary - if they existed at all.
It wasn't hard for a good assembly-language programmer to write
more efficient code than a compiler would generate - which meant
that the company could get by with a much cheaper machine.

Mind you, the whole argument becomes moot if the computer is
too small to even run the COBOL compiler in the first place.
(BTDTGTTS)

--
/~\ 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!

[hanc...@bbs.cpcn.com]

On Nov 8, 11:58 am, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

> I think a lot of it was simply that compilers of the day didn't
> generate code that was nearly as efficient as modern ones do.
> Optimizers were quite rudimentary - if they existed at all.
> It wasn't hard for a good assembly-language programmer to write
> more efficient code than a compiler would generate - which meant
> that the company could get by with a much cheaper machine.

As an experiment, I compiled and executed a COBOL program two ways,
one with optimization on, the other with opt off. The wall clock
execution time was noticeably longer without optimization (IIRC, about
20-30% longer).

If the early S/360 compilers did not have decent optimization, I could
well understand the advantage of using Assembler (presuming the
programmer knew what he/she was doing.)

> Mind you, the whole argument becomes moot if the computer is
> too small to even run the COBOL compiler in the first place.
> (BTDTGTTS)

I think the D level was intended for machines of 16k, but I think many
model 30's and 40s were delivered with more memory than that.

[Charlie Gibbs]

In article
<4468dd99-03d5-41e2...@l18g2000vbv.googlegroups.com>,

Yes, but if IBM's marketroids were as good as Univac's at lowballing
memory requirements, that 16K might be a bad joke.

[Walter Bushell]

In article <1626.730T2...@kltpzyxm.invalid>,

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

> In article
> <3cb72b11-0447-4a11...@ez26g2000vbb.googlegroups.com>,
> hanc...@bbs.cpcn.com (hancock4) writes:
>
> > In the earlier days of System/360 many sites used Assembler
> > programming, not COBOL, because their machines were slow and had
> > limited memory.
> >
> > Just out of curiousity, I was wondering how much space and time was
> > saved by writing a typical business application program in Assembler
> > rather than COBOL in System/360.
> >
> > Imagine an application where a sorted sequential tape file is input,
> > along with a sorted card deck of update records to that file. A new
> > revised tape file is output. Also, a log report of updated records
> > and rejected cards is printed.
> >
> > Generally speaking, would anyone care to discuss the techniques in
> > Assembler that would save significant memory and processing time in
> > an application like the above?
>
> I think a lot of it was simply that compilers of the day didn't
> generate code that was nearly as efficient as modern ones do.
> Optimizers were quite rudimentary - if they existed at all.
> It wasn't hard for a good assembly-language programmer to write
> more efficient code than a compiler would generate - which meant
> that the company could get by with a much cheaper machine.

Not to mention writing optimum code was much easier on early confusers.
Optimizing for speculative execution, minimum cache hits and other
techniques is more difficult.

>
> Mind you, the whole argument becomes moot if the computer is
> too small to even run the COBOL compiler in the first place.
> (BTDTGTTS)

--

This space unintentionally left blank.

[Shmuel Metz]

In <proto-226886....@news.panix.com>, on 11/08/2012

at 07:15 PM, Walter Bushell <pr...@panix.com> said:

>Not to mention writing optimum code was much easier on early
>confusers. Optimizing for speculative execution, minimum cache hits
>and other techniques is more difficult.

That was not a factor for the COBOL compilers. None of the DOS
customers was running a 360/91 or 360/95, the only S/360 models to use
such tecjniques. Further, the optimization issues in OS/360 COBOL (F)
and, later, (U), were fare cruder than pipelining issues.

--
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

[Peter Flass]

On 11/8/2012 4:51 PM, Charlie Gibbs wrote:
> In article
> <4468dd99-03d5-41e2...@l18g2000vbv.googlegroups.com>,
> hanc...@bbs.cpcn.com (hancock4) writes:
>
>> On Nov 8, 11:58 am, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>>
>>> Mind you, the whole argument becomes moot if the computer is
>>> too small to even run the COBOL compiler in the first place.
>>> (BTDTGTTS)
>>
>> I think the D level was intended for machines of 16k, but I think
>> many model 30's and 40s were delivered with more memory than that.
>
> Yes, but if IBM's marketroids were as good as Univac's at lowballing
> memory requirements, that 16K might be a bad joke.
>

I would agree. Most small machines I saw were 32K, it was pretty much
standard.

--
Pete

[hanc...@bbs.cpcn.com]

On Nov 9, 7:26 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> I would agree.  Most small machines I saw were 32K, it was pretty much
> standard.

So, the typical S/360 model 30 was 32k?

[Dan Espen]

The first one I used was 64K but we reserved F1 for an online BTAM 2260
application, I think we needed 14K for that. Leaving barely enough to run
the COBOL compiler.

I'd _guess_ that "typical" was 64K.

--
Dan Espen

[Charles Richmond]

"Dan Espen" <des...@verizon.net> wrote in message
news:icobj6e...@home.home...

Just like a Commodore 64 would have twenty years later!

--

numerist at aquaporin4 dot ocm

[hanc...@bbs.cpcn.com]

On Nov 9, 7:03 am, Shmuel (Seymour J.) Metz

<spamt...@library.lspace.org.invalid> wrote:

> That was not a factor for the COBOL compilers. None of the DOS
> customers was running a 360/91 or 360/95, the only S/360 models to use
> such tecjniques. Further, the optimization issues in OS/360 COBOL (F)
> and, later, (U), were fare cruder than pipelining issues.

Could you elaborate on some details of optimized/unoptimized code of
the System/360 era? That is, what would the COBOL compiler generate
that was wasteful that an Assembler programmer would not code?

[Dan Espen]

Wow, brush off the cobwebs!

I remember a site using some 3rd party optimizer.
I was really impressed that "PERFORM" generated one instruction,
"BAL" for the PERFORM.

I can't remember what the IBM compiler generated but it was more
than one instruction.

S/360 presents a big problem with the limited range of a base
register (4K) and a limited number of base registers (16).
The optimizer has to figure out what areas of memory are referenced a
lot and deserve a dedicated register and which areas are only referenced
in exception cases and use temporary base registers for those areas.

An Assembler programmer knows that stuff because he understands the data
flow of the program. The COBOL compiler can't get it right at compile time,
even to today.

--
Dan Espen

[Walter Banks]

Every once in a while I get a wake up call about
where we were and where we are now. I was at a
processor release yesterday for a 32bit processor
that runs at about 80Mhz has a floating point
co processor. On board memory is 128K. It has
a second processor on the card that DMA's into the first
that can be used for live debugging or used as a
co I/O processor. Needs <20 ma
(powered through a USB port)

Compare that to the 360/75 at the U of Waterloo
when I first started to work there in 1970.

Price for the development board $11.00

w..

[Anne & Lynn Wheeler]

Dan Espen <des...@verizon.net> writes:
> Wow, brush off the cobwebs!
>
> I remember a site using some 3rd party optimizer.
> I was really impressed that "PERFORM" generated one instruction,
> "BAL" for the PERFORM.
>
> I can't remember what the IBM compiler generated but it was more
> than one instruction.
>
> S/360 presents a big problem with the limited range of a base
> register (4K) and a limited number of base registers (16).
> The optimizer has to figure out what areas of memory are referenced a
> lot and deserve a dedicated register and which areas are only referenced
> in exception cases and use temporary base registers for those areas.
>
> An Assembler programmer knows that stuff because he understands the data
> flow of the program. The COBOL compiler can't get it right at compile time,
> even to today.

but it help some with the intro of virtual memory and 4k pages.

science center had done virtual machine cp40 in the mid-60s on 360/40
with hardware modifications supporting virtual memory ... which morphed
into cp/67 when standard 360/67 with virtual memory became available.

in the 70s, science center did a whole lof of performance work,
instrumenting cp67 & vm370 gathering data for decades on internal
systems growing into hundreds; numerous simulation and modeling
efforts ... eventually growing into capacity planning. one of the
analytical models done in APL was made available on the internal
world-wide sales&marketing support system ... local branch people
could enter description of customer's workload and configuration and
ask what-if questions about changes to workload &/or configuration.

One of the other tools was trace ... that tracked instruction and
storage references and then did semi-automated program reorganization to
optimize virtual memory operation (Bayesian cluster analysis). it was
eventually made available spring 1976 as product called vs/repack.

it was used internally by lots of the 360 products (compilers, dbms,
etc) as part of the transition from real-storage to virtual memory
(i.e. dos, mft, mvt transitions to 370 virtual memory).

the register 4k addressing tended to help consolidate/compact storage
use ... providing for slightly better virtual memory operation

--
virtualization experience starting Jan1968, online at home since Mar1970

[Dan Espen]

Anne & Lynn Wheeler <ly...@garlic.com> writes:

> Dan Espen <des...@verizon.net> writes:
>> Wow, brush off the cobwebs!
>>
>> I remember a site using some 3rd party optimizer.
>> I was really impressed that "PERFORM" generated one instruction,
>> "BAL" for the PERFORM.
>>
>> I can't remember what the IBM compiler generated but it was more
>> than one instruction.
>>
>> S/360 presents a big problem with the limited range of a base
>> register (4K) and a limited number of base registers (16).
>> The optimizer has to figure out what areas of memory are referenced a
>> lot and deserve a dedicated register and which areas are only referenced
>> in exception cases and use temporary base registers for those areas.
>>
>> An Assembler programmer knows that stuff because he understands the data
>> flow of the program. The COBOL compiler can't get it right at compile time,
>> even to today.
>
> but it help some with the intro of virtual memory and 4k pages.

I don't see how.
If you're reading and writing an 8K record, you still have 4 base
registers tied up.

> science center had done virtual machine cp40 in the mid-60s on 360/40
> with hardware modifications supporting virtual memory ... which morphed
> into cp/67 when standard 360/67 with virtual memory became available.
>
> in the 70s, science center did a whole lof of performance work,
> instrumenting cp67 & vm370 gathering data for decades on internal
> systems growing into hundreds; numerous simulation and modeling
> efforts ... eventually growing into capacity planning. one of the
> analytical models done in APL was made available on the internal
> world-wide sales&marketing support system ... local branch people
> could enter description of customer's workload and configuration and
> ask what-if questions about changes to workload &/or configuration.
>
> One of the other tools was trace ... that tracked instruction and
> storage references and then did semi-automated program reorganization to
> optimize virtual memory operation (Bayesian cluster analysis). it was
> eventually made available spring 1976 as product called vs/repack.

Never heard of vs/repack, but I was thinking of the various execution
profilers when I wrote the above. A profiler _could in theory_ do better
optimization than a coder that knows the data.

> it was used internally by lots of the 360 products (compilers, dbms,
> etc) as part of the transition from real-storage to virtual memory
> (i.e. dos, mft, mvt transitions to 370 virtual memory).
>
> the register 4k addressing tended to help consolidate/compact storage

> use ... providing for slightly better virtual memory operation.

But greatly complicates things like processing 12K records.

--
Dan Espen

[Christian Brunschen]

In article <509D65DB...@bytecraft.com>,

Walter Banks <wal...@bytecraft.com> wrote:
>
>Every once in a while I get a wake up call about
>where we were and where we are now. I was at a
>processor release yesterday for a 32bit processor
>that runs at about 80Mhz has a floating point
>co processor. On board memory is 128K. It has
>a second processor on the card that DMA's into the first
>that can be used for live debugging or used as a
>co I/O processor. Needs <20 ma
>(powered through a USB port)
>
>Compare that to the 360/75 at the U of Waterloo
>when I first started to work there in 1970.
>
>Price for the development board $11.00

Do you happen to have a link to some more information about this?

Best wishes,

>w..

// Christian

[Shmuel Metz]

In <ick3tue...@home.home>, on 11/09/2012

at 01:35 PM, Dan Espen <des...@verizon.net> said:

>S/360 presents a big problem with the limited range of a base
>register (4K) and a limited number of base registers (16).

There were 16 general registers, but only 15 of them could be used as
base or index registers.

[Anne & Lynn Wheeler]

Anne & Lynn Wheeler <ly...@garlic.com> writes:

> One of the other tools was trace ... that tracked instruction and
> storage references and then did semi-automated program reorganization to
> optimize virtual memory operation (Bayesian cluster analysis). it was
> eventually made available spring 1976 as product called vs/repack.

re:
http://www.garlic.com/~lynn/2012o.html#19 Assembler vs. COBOL--processing time, space needed

early version help with move of apl\360 to cms\apl

apl\360 had its own monitor and did its own workspace (real memory)
swapping (typically configuration 16kbytes or 32kbytes max. workspace
size)

move to cms\apl in (virtual memory) cp67/cms (virtual machine) allowed
wokspaces to be (demand paged) virtual address space size. This (and
interface for accessing cms system services ... like file read/write)
allowed real-world sized applications. business planning people in
(armonk) corporate hdqtrs loaded the most valuable corporate information
(detailed customer information) on the cambridge science center ... and
did business modeling in cms\apl (this also required quite a bit of
security because non-employees from varous boston area univ
... including students were using cambridge system). misc. past posts
mentioning science center on 4th flr 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech

the problem came up for working in demand paged, virtual memory
environment was apl\360 storage allocation ... allocated a new
storage location on every assignment ... this continued until
workspace storage was exhausted and then did garbage collection ...
compacted in-use storage to single contiguous area ... and then
it starts all over again.

the (vs/repack precursor) tool included doing printout of storage use
traces ... would print on reverse white-side of green-bar paper ...
time along horizontal ... storage location vertical ... storage (both
instruction and data refs) was scaled to about 7ft length of print-out
... and time-line scaled about 30ft ... over several lengths of
print-out taped together on internal hall in the science center.

apl\360 program would quickly alter every location in the available
workspace memory ... looking like the sloped side of saw tooth and then
garbage collect ... a solid vertical line (in print-out). with 16byte
workspace where the whole thing was always swapped ... made no
difference.

however, several mybyte virtual memory ... in quickly alters every page
and then garbage collects ... the use of storage is based on the number
of assignment operations ... independent the actaul aggregate storage in
use at any one moment. in any case, had to redo the apl\360 storage
management for virtual memory environment.

recent announcement that apl\360 source code available:
http://www.computerhistory.org/atchm/the-apl-programming-language-source-code/

The previously mentioned world-wide sales&marketing online HONE system
started out with several virtual machine cp67 datacenters to give branch
office technical people opportunity to practice operating system skills
(in virtual machines) ... but it came to be dominated by sales/marketing
(non-technical) support applications (mostly written in apl ... starting
out with cms\apl). misc. past posts mentioning hone &/or apl
http://www.garlic.com/~lynn/subtopic.html#hone

misc. past posts mentioning cms\apl
http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
http://www.garlic.com/~lynn/97.html#4 Mythical beasts (was IBM... mainframe)
http://www.garlic.com/~lynn/99.html#38 1968 release of APL\360 wanted
http://www.garlic.com/~lynn/2000.html#69 APL on PalmOS ???
http://www.garlic.com/~lynn/2000c.html#49 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000g.html#27 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001i.html#43 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#44 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001l.html#6 mainframe question
http://www.garlic.com/~lynn/2001n.html#0 TSS/360
http://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#30 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe?
http://www.garlic.com/~lynn/2002f.html#30 Computers in Science Fiction
http://www.garlic.com/~lynn/2002h.html#60 Java, C++ (was Re: Is HTML dead?)
http://www.garlic.com/~lynn/2002h.html#67 history of CMS
http://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#2 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#5 HONE, xxx#, misc
http://www.garlic.com/~lynn/2002j.html#37 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002p.html#37 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2002q.html#47 myths about Multics
http://www.garlic.com/~lynn/2003c.html#16 Early attempts at console humor?
http://www.garlic.com/~lynn/2003c.html#18 Early attempts at console humor?
http://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
http://www.garlic.com/~lynn/2003g.html#5 Any DEC 340 Display System Doco ?
http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003j.html#32 Language semantics wrt exploits
http://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2003p.html#14 64 bits vs non-coherent MPP was: Re: Itanium strikes again
http://www.garlic.com/~lynn/2004.html#14 Holee shit! 30 years ago!
http://www.garlic.com/~lynn/2004b.html#58 Oldest running code
http://www.garlic.com/~lynn/2004c.html#7 IBM operating systems
http://www.garlic.com/~lynn/2004c.html#21 PSW Sampling
http://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#55 If there had been no MS-DOS
http://www.garlic.com/~lynn/2004j.html#25 Wars against bad things
http://www.garlic.com/~lynn/2004j.html#28 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004j.html#53 history books on the development of capacity planning (SMF and RMF)
http://www.garlic.com/~lynn/2004m.html#54 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#0 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#6 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#37 passing of iverson
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#10 Multi-processor timing issue
http://www.garlic.com/~lynn/2004q.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#41 something like a CTC on a PC
http://www.garlic.com/~lynn/2005.html#44 John Titor was right? IBM 5100
http://www.garlic.com/~lynn/2005f.html#63 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005g.html#27 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005g.html#30 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005h.html#1 Single System Image questions
http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#25 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005j.html#62 More on garbage collection
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#50 APL, J or K?
http://www.garlic.com/~lynn/2005o.html#5 Code density and performance?
http://www.garlic.com/~lynn/2005o.html#34 Not enough parallelism in programming
http://www.garlic.com/~lynn/2005o.html#38 SHARE reflections
http://www.garlic.com/~lynn/2005o.html#46 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005p.html#20 address space
http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1
http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006c.html#44 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006h.html#14 Security
http://www.garlic.com/~lynn/2006j.html#24 virtual memory
http://www.garlic.com/~lynn/2006j.html#39 virtual memory
http://www.garlic.com/~lynn/2006k.html#30 PDP-1
http://www.garlic.com/~lynn/2006m.html#53 DCSS
http://www.garlic.com/~lynn/2006n.html#2 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006o.html#13 The SEL 840 computer
http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents
http://www.garlic.com/~lynn/2006o.html#30 The Question of Braces in APL-ASCII
http://www.garlic.com/~lynn/2006o.html#52 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2006o.html#53 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2006s.html#12 Languages that should have made it but didn't
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006x.html#19 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2007b.html#32 IBMLink 2000 Finding ESO levels
http://www.garlic.com/~lynn/2007d.html#64 Is computer history taugh now?
http://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
http://www.garlic.com/~lynn/2007g.html#48 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#62 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
http://www.garlic.com/~lynn/2007i.html#77 Sizing CPU
http://www.garlic.com/~lynn/2007j.html#13 Interrupts
http://www.garlic.com/~lynn/2007j.html#17 Newbie question on table design
http://www.garlic.com/~lynn/2007j.html#19 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#65 Help settle a job title/role debate
http://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#73 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007l.html#59 Scholars needed to build a computer history bibliography
http://www.garlic.com/~lynn/2007m.html#15 Patents, Copyrights, Profits, Flex and Hercules
http://www.garlic.com/~lynn/2007m.html#55 Capacity and Relational Database
http://www.garlic.com/~lynn/2007m.html#57 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#53 Virtual Storage implementation
http://www.garlic.com/~lynn/2007q.html#23 GETMAIN/FREEMAIN and virtual storage backing up
http://www.garlic.com/~lynn/2007r.html#5 The history of Structure capabilities
http://www.garlic.com/~lynn/2007r.html#68 High order bit in 31/24 bit address
http://www.garlic.com/~lynn/2007s.html#33 Age of IBM VM
http://www.garlic.com/~lynn/2007s.html#41 Age of IBM VM
http://www.garlic.com/~lynn/2007t.html#71 T3 Sues IBM To Break its Mainframe Monopoly
http://www.garlic.com/~lynn/2007v.html#0 IBM mainframe history, was Floating-point myths
http://www.garlic.com/~lynn/2007v.html#48 IBM mainframe history, was Floating-point myths
http://www.garlic.com/~lynn/2007v.html#57 folklore indeed
http://www.garlic.com/~lynn/2008b.html#27 Re-hosting IMB-MAIN
http://www.garlic.com/~lynn/2008c.html#24 Job ad for z/OS systems programmer trainee
http://www.garlic.com/~lynn/2008d.html#32 Interesting Mainframe Article: 5 Myths Exposed
http://www.garlic.com/~lynn/2008d.html#35 Interesting Mainframe Article: 5 Myths Exposed
http://www.garlic.com/~lynn/2008f.html#36 Object-relational impedence
http://www.garlic.com/~lynn/2008h.html#7 Xephon, are they still in business?
http://www.garlic.com/~lynn/2008h.html#74 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008j.html#89 CLIs and GUIs
http://www.garlic.com/~lynn/2008m.html#36 IBM THINK original equipment sign
http://www.garlic.com/~lynn/2008m.html#42 APL
http://www.garlic.com/~lynn/2008m.html#61 CHROME and WEB apps on Mainframe?
http://www.garlic.com/~lynn/2008n.html#57 VMware renders multitasking OSes redundant
http://www.garlic.com/~lynn/2008o.html#66 Open Source, Unbundling, and Future System
http://www.garlic.com/~lynn/2008p.html#41 Automation is still not accepted to streamline the business processes... why organizations are not accepting newer technologies?
http://www.garlic.com/~lynn/2008p.html#42 Password Rules
http://www.garlic.com/~lynn/2008p.html#73 History of preprocessing (Burroughs ALGOL)
http://www.garlic.com/~lynn/2008q.html#48 TOPS-10
http://www.garlic.com/~lynn/2008q.html#59 APL
http://www.garlic.com/~lynn/2008r.html#18 Comprehensive security?
http://www.garlic.com/~lynn/2008r.html#40 Paris
http://www.garlic.com/~lynn/2008s.html#17 IBM PC competitors
http://www.garlic.com/~lynn/2009.html#0 Is SUN going to become x86'ed ??
http://www.garlic.com/~lynn/2009.html#6 mvs preemption dispatcher
http://www.garlic.com/~lynn/2009f.html#0 How did the monitor work under TOPS?
http://www.garlic.com/~lynn/2009f.html#18 System/360 Announcement (7Apr64)
http://www.garlic.com/~lynn/2009i.html#26 Why are z/OS people reluctant to use z/OS UNIX?
http://www.garlic.com/~lynn/2009i.html#36 SEs & History Lessons
http://www.garlic.com/~lynn/2009j.html#67 DCSS
http://www.garlic.com/~lynn/2009j.html#77 More named/shared systems
http://www.garlic.com/~lynn/2009l.html#1 Poll results: your favorite IBM tool was IBM-issued laptops
http://www.garlic.com/~lynn/2009l.html#43 SNA: conflicting opinions
http://www.garlic.com/~lynn/2009o.html#37 Young Developers Get Old Mainframers' Jobs
http://www.garlic.com/~lynn/2009p.html#33 Survey Revives Depate Over Mainframe's Future
http://www.garlic.com/~lynn/2009q.html#18 email
http://www.garlic.com/~lynn/2009r.html#17 How to reduce the overall monthly cost on a System z environment?
http://www.garlic.com/~lynn/2009r.html#68 360 programs on a z/10
http://www.garlic.com/~lynn/2010b.html#51 Source code for s/360
http://www.garlic.com/~lynn/2010c.html#28 Processes' memory
http://www.garlic.com/~lynn/2010c.html#35 Processes' memory
http://www.garlic.com/~lynn/2010c.html#54 Processes' memory
http://www.garlic.com/~lynn/2010c.html#55 Processes' memory
http://www.garlic.com/~lynn/2010c.html#89 Notes on two presentations by Gordon Bell ca. 1998
http://www.garlic.com/~lynn/2010d.html#27 HONE & VMSHARE
http://www.garlic.com/~lynn/2010d.html#59 LPARs: More or Less?
http://www.garlic.com/~lynn/2010d.html#62 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#14 Senior Java Developer vs. MVS Systems Programmer (warning: Conley rant)
http://www.garlic.com/~lynn/2010e.html#21 paged-access method
http://www.garlic.com/~lynn/2010e.html#22 search engine history, was Happy DEC-10 Day
http://www.garlic.com/~lynn/2010e.html#24 Unbundling & HONE
http://www.garlic.com/~lynn/2010g.html#20 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#64 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010h.html#17 LINUX on the MAINFRAME
http://www.garlic.com/~lynn/2010i.html#11 IBM 5100 First Portable Computer commercial 1977
http://www.garlic.com/~lynn/2010i.html#13 IBM 5100 First Portable Computer commercial 1977
http://www.garlic.com/~lynn/2010i.html#66 Global CIO: Global Banks Form Consortium To Counter HP, IBM, & Oracle
http://www.garlic.com/~lynn/2010j.html#17 Personal use z/OS machines was Re: Multiprise 3k for personal Use?
http://www.garlic.com/~lynn/2010j.html#48 Knuth Got It Wrong
http://www.garlic.com/~lynn/2010j.html#80 Idiotic programming style edicts
http://www.garlic.com/~lynn/2010l.html#15 Age
http://www.garlic.com/~lynn/2010n.html#10 Mainframe Slang terms
http://www.garlic.com/~lynn/2010n.html#17 What non-IBM software products have been most significant to the mainframe's success
http://www.garlic.com/~lynn/2010q.html#35 VMSHARE Archives
http://www.garlic.com/~lynn/2010q.html#51 Is email dead? What do you think?
http://www.garlic.com/~lynn/2011.html#28 Personal histories and IBM computing
http://www.garlic.com/~lynn/2011.html#82 Utility of find single set bit instruction?
http://www.garlic.com/~lynn/2011b.html#69 Boeing Plant 2 ... End of an Era
http://www.garlic.com/~lynn/2011d.html#59 The first personal computer (PC)
http://www.garlic.com/~lynn/2011e.html#8 Multiple Virtual Memory
http://www.garlic.com/~lynn/2011e.html#58 Collection of APL documents
http://www.garlic.com/~lynn/2011f.html#3 History of APL -- Software Preservation Group
http://www.garlic.com/~lynn/2011f.html#51 US HONE Datacenter consolidation
http://www.garlic.com/~lynn/2011h.html#61 Do you remember back to June 23, 1969 when IBM unbundled
http://www.garlic.com/~lynn/2011i.html#39 Wondering if I am really eligible for this group. I learned my first programming language in 1975
http://www.garlic.com/~lynn/2011i.html#55 Architecture / Instruction Set / Language co-design
http://www.garlic.com/~lynn/2011j.html#48 Opcode X'A0'
http://www.garlic.com/~lynn/2011m.html#27 "Best" versus "worst" programming language you've used?
http://www.garlic.com/~lynn/2011m.html#37 What is IBM culture?
http://www.garlic.com/~lynn/2011m.html#61 JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)
http://www.garlic.com/~lynn/2011m.html#62 JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel)
http://www.garlic.com/~lynn/2011m.html#69 "Best" versus "worst" programming language you've used?
http://www.garlic.com/~lynn/2011n.html#53 Virginia M. Rometty elected IBM president
http://www.garlic.com/~lynn/2011o.html#44 Data Areas?
http://www.garlic.com/~lynn/2012.html#7 Can any one tell about what is APL language
http://www.garlic.com/~lynn/2012.html#10 Can any one tell about what is APL language
http://www.garlic.com/~lynn/2012.html#14 HONE
http://www.garlic.com/~lynn/2012.html#50 Can any one tell about what is APL language
http://www.garlic.com/~lynn/2012b.html#6 Cloud apps placed well in the economic cycle
http://www.garlic.com/~lynn/2012b.html#43 Where are all the old tech workers?
http://www.garlic.com/~lynn/2012d.html#38 Invention of Email
http://www.garlic.com/~lynn/2012e.html#39 A bit of IBM System 360 nostalgia
http://www.garlic.com/~lynn/2012e.html#100 Indirect Bit
http://www.garlic.com/~lynn/2012f.html#40 STSC Story
http://www.garlic.com/~lynn/2012i.html#93 Operating System, what is it?
http://www.garlic.com/~lynn/2012j.html#82 printer history Languages influenced by PL/1
http://www.garlic.com/~lynn/2012k.html#8 International Business Marionette
http://www.garlic.com/~lynn/2012l.html#79 zEC12, and previous generations, "why?" type question - GPU computing

[Ben Pfaff]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <ick3tue...@home.home>, on 11/09/2012
> at 01:35 PM, Dan Espen <des...@verizon.net> said:
>
>>S/360 presents a big problem with the limited range of a base
>>register (4K) and a limited number of base registers (16).
>
> There were 16 general registers, but only 15 of them could be used as
> base or index registers.

Why could a base register address only 4KB?

[Charlie Gibbs]

In article <icehk2e...@home.home>, des...@verizon.net (Dan Espen)
writes:

> Anne & Lynn Wheeler <ly...@garlic.com> writes:
>
>> Dan Espen <des...@verizon.net> writes:
>>
>>> S/360 presents a big problem with the limited range of a base
>>> register (4K) and a limited number of base registers (16).
>>> The optimizer has to figure out what areas of memory are referenced
>>> a lot and deserve a dedicated register and which areas are only
>>> referenced in exception cases and use temporary base registers for
>>> those areas.
>>>
>>> An Assembler programmer knows that stuff because he understands the
>>> data flow of the program. The COBOL compiler can't get it right at
>>> compile time, even to today.
>>
>> but it help some with the intro of virtual memory and 4k pages.
>
> I don't see how.
> If you're reading and writing an 8K record, you still have 4 base
> registers tied up.

You could step a register through that record if you really had to.
But I can't think of a case where anyone used 8K records (at least
in the sense of a group of related fields). On a 2314 you couldn't
even have 8K blocks, since a track could hold a maximum of 7294 bytes.

[John Levine]

>> There were 16 general registers, but only 15 of them could be used as
>> base or index registers.
>
>Why could a base register address only 4KB?

Because the displacement field in a 360 instruction is 12 bits. The
explicit assumption is that all application code does base register
relative addressing. Anyone interested in the design of the 360
should read the articles on it in the IBM Systems Journal in 1964.
From those articles, I get the idea that they thought that since all
addressing will be relative to base registers, programs would be
position independent, thereby avoiding expensive address translation
hardware. Only later did they remember that real programs store a lot
of pointers in memory, and those aren't going to relocate themselves.
Oops.

It was my impression that human programmers were a lot better at
allocating base registers than 1960s era compilers, and assembler
programs tended to have a lot fewer loads and other instructions to
set up registers for addressing than compiler generated programs did.
Well, except for Fortran H, but it was in a class by itself.


--
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

[Peter Flass]

Now you made me look, but I didn't get a good answer. I can only speak
from experience at several shops, but as I said, all the ones I saw were
32K. In fact, they were all cookie-cutter machines: two or three 2311s,
two or three 2415s, 1403 (not N1), 2540 reader/punch. Nominally, I
guess, DOS would run on a 16K machine but the minimum supervisor (IIRC)
was 4K so you'd only have 12K left for the application, and core was
always tight on a 32K machine. Maybe RPG would use less memory than
COBOL, but also everyone I saw used COBOL.

--
Pete

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <ick3tue...@home.home>, on 11/09/2012
> at 01:35 PM, Dan Espen <des...@verizon.net> said:
>
>>S/360 presents a big problem with the limited range of a base
>>register (4K) and a limited number of base registers (16).
>
> There were 16 general registers, but only 15 of them could be used as
> base or index registers.

Right, and another 4 (13,14,15,1) aren't good candidates either since
they're involved with standard linkage, some instructions (R1) and save
areas.

Any Assembler programmer knows base registers have a way of disappearing
fast.

I've been relying on the new relative instructions so I don't need base
registers for code, but even then, a couple for the stack, a couple for
constants, and 2 pairs for MVCL and you've got little left for locate
mode I/O areas, getmained areas, or table searching.

So, a good technique is save and restore registers when you JAS into a
subroutine. Then you can have a DO WHILE type construct using R3 and
JAS to a subroutine that uses R3 for something else. As long as the
subroutine saves and restores R3, no problem for the caller.

But saving and restoring 14,12 (15 registers or 15*4 bytes) strikes me as too much
overhead on a JAS, so for small subroutines, I like to write SAVE/RETURN
type macros, that have a parm ONLY=(Ra,Rb) where registers a through b are
the only registers saved. If the small routine does a table look up, it
might only need 1 or 2 registers so it can save some cycles (or cache usage).

Here's an example from some recent code:

MY#ENT ...,ONLY=(R0,R2)
MY#ENT ...,ONLY=(R0,R6)
MY#ENT ...,ONLY=(R1,R2)
MY#ENT ...,ONLY=(R1,R3)
MY#ENT ...,ONLY=(R1,R1)
MY#ENT ...,ONLY=(R1,R1)
MY#ENT ...,ONLY=(R1,R3)
MY#ENT ...,ONLY=(R1,R4)
MY#ENT ...,ONLY=(R1,R3)
MY#ENT ...,ONLY=(R1,R1)
MY#ENT ...,ONLY=(R1,R4)
MY#ENT ...,ONLY=(R1,R2)

So quite a few of the routines only needed to save/restore 1 register.

To make this work, you need to call the routine like this:

JAS R1,RTN
^^

Because the return register MUST be saved. If you use the standard R14,
you end up with multiple saves or you need to save 3 additional
registers.

So, now we come full circle. Using the above technique, R1 is no good
for passing a PARM. So which register is good? I like R0.

--
Dan Espen

[hanc...@bbs.cpcn.com]

On Nov 9, 6:53 pm, John Levine <jo...@iecc.com> wrote:

> >Why could a base register address only 4KB?
>
> Because the displacement field in a 360 instruction is 12 bits.  The
> explicit assumption is that all application code does base register
> relative addressing.

The scheme was a compromise so that all machines of the S/360 product
line could address the possible full size of memory (originally 16
meg), but without wasting space on long addresses not needed nor
wanted in the low-end machines. In this way a customer who outgrew
their machine could port their programs to a larger model without
changing the programs. Before S/360 that could be difficult to do.

> Anyone interested in the design of the 360
> should read the articles on it in the IBM Systems Journal in 1964.

They might be hard to find. The book on the history of System/360
(see separate thread) is much more widely available, and that explains
the development in detail.

[hanc...@bbs.cpcn.com]

On Nov 9, 7:10 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> > So, the typical S/360 model 30 was 32k?
>
> Now you made me look, but I didn't get a good answer. I can only speak
> from experience at several shops, but as I said, all the ones I saw were
> 32K.  In fact, they were all cookie-cutter machines: two or three 2311s,
> two or three 2415s, 1403 (not N1), 2540 reader/punch.  Nominally, I
> guess, DOS would run on a 16K machine but the minimum supervisor (IIRC)
> was 4K so you'd only have 12K left for the application, and core was
> always tight on a 32K machine.  Maybe RPG would use less memory than
> COBOL, but also everyone I saw used COBOL.

I think RPG used less memory than COBOL, it was developed for the
1401.

I wonder how many 16k S/360's there were out there, especially in the
early years. Perhaps those users didn't use DOS, but BOS or BPS.
Indeed, I wonder if they were a wise purchase--I suspect upgrading
their 1401 to 16,000 characters and retaining their Autocoder
investment was a better way to go. Also, IBM continued marketing
their 1401 as a cheap entry level machine into the late 1960s. After
all, IBM had them being returned from other customers and still had
some life left in them. (My former frugal employer got one c. 1968).

[Walter Banks]

Christian,

There were actually two different very similar development
boards. One for freescale and the second for ST . They
were both based on the ARM Cortex parts

The freescale board was based on Cortex M0+ was on an
arduino form factor board using a 128 K part ($12.95)
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-KL25Z&tid=FSHBNR_20121107

The second was ST using a Cortex M4 based part with
floating point 256Kflash and 48K RAM on a similar
sized board ($10.90)
http://www.st.com/internet/evalboard/product/254044.jsp

Walter..

[Christian Brunschen]

In article <509E5287...@bytecraft.com>,

Many thanks!

>Walter..

// Christian

[Walter Bushell]

In article <509D65DB...@bytecraft.com>,

How about compared to the IBM 650?

[John Levine]

>> Anyone interested in the design of the 360
>> should read the articles on it in the IBM Systems Journal in 1964.
>
>They might be hard to find.

Not for anyone who's willing to do a Google search. Sheesh.

[hanc...@bbs.cpcn.com]

On Nov 10, 1:05 pm, Walter Bushell <pr...@panix.com> wrote:

> > Compare that to the 360/75 at the U of Waterloo
> > when I first started to work there in 1970.
>
> > Price for the development board $11.00

> How about compared to the IBM 650?

The book "IBM's Early Computers" has charts showing the relative cost
per bit of various machines. Williams Tube memory was very
expensive. The 650 used a drum (a little core later on). Technology
improvements helped reduce the cost/bit in core memory.

For its day, the 650 was a popular cost effective machine. IIRC, they
continued building them until 1962 which is a good lifespan.

[Shmuel Metz]

In <87625el...@blp.benpfaff.org>, on 11/09/2012

at 03:41 PM, Ben Pfaff <b...@cs.stanford.edu> said:

>Why could a base register address only 4KB?

More precisely, why could a S/360 base register only address 4 KiB
unless you also used an index register? Because the displacement field
for the RS, RX, SI and SS instructions was[1] only 12 bits.

[1] Current processors have some long displacement instructions,
e.g., AG, AGF.

[Shmuel Metz]

In <ica9uqe...@home.home>, on 11/09/2012

at 07:55 PM, Dan Espen <des...@verizon.net> said:

>Right, and another 4 (13,14,15,1) aren't good candidates either since
>they're involved with standard linkage, some instructions (R1) and
>save areas.

Unless you're hot to TRT, in which case R2 is not a good candidate
either.

[Peter Flass]

On 11/11/2012 8:09 AM, Shmuel (Seymour J.) Metz wrote:
> In <ica9uqe...@home.home>, on 11/09/2012
> at 07:55 PM, Dan Espen <des...@verizon.net> said:
>
>> Right, and another 4 (13,14,15,1) aren't good candidates either since
>> they're involved with standard linkage, some instructions (R1) and
>> save areas.
>
> Unless you're hot to TRT, in which case R2 is not a good candidate
> either.
>

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.

--
Pete

[Ben Pfaff]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <87625el...@blp.benpfaff.org>, on 11/09/2012
> at 03:41 PM, Ben Pfaff <b...@cs.stanford.edu> said:
>
>>Why could a base register address only 4KB?
>
> More precisely, why could a S/360 base register only address 4 KiB
> unless you also used an index register? Because the displacement field
> for the RS, RX, SI and SS instructions was[1] only 12 bits.

I missed the "unless you also used an index register" part
before. (Perhaps it was implied.) It makes sense with that
clarification.

[Shmuel Metz]

In <k7oa6d$ped$3...@dont-email.me>, on 11/11/2012

at 08:53 AM, Peter Flass <Peter...@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.

[Tim McCaffrey]

In article <509E5287...@bytecraft.com>, wal...@bytecraft.com says...

I wonder if you can use the 256K flash to implement a 360 emulator that would
be fast enough to out run the 360/75? :O

- Tim

[Peter Flass]

On 11/11/2012 2:59 PM, Shmuel (Seymour J.) Metz wrote:
> In <k7oa6d$ped$3...@dont-email.me>, on 11/11/2012
> at 08:53 AM, Peter Flass <Peter...@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.
>

My point, badly made perhaps, was that the programmer should modularize
so as not to need many registers. I have seen 360 assembler programs
written a one monolithic CSECT, so between needing three or four (or
more) base registers plus spaghetti code that doesn't localize the use
of other registers, yes, it's not hard to run out. OTOH, I rarely need
more than one base register for code at a time and try to keep other
register usage localized.

--
Pete

[Dan Espen]

In modern assembler you don't need any registers for code.
The relative instructions like J (Jump) make them unnecessary.

The last program I wrote ended up needing 2 registers for the stack and
2 registers for constants.

When I went to test the Assembler program as an LE Assembler program
it took a while to re-organize to free up R12 (which LE wants).

I usually write using one CSECT but subroutines (routines entered by
JAS) save the callers registers allowing some register re-use.


--
Dan Espen

[Shmuel Metz]

In <k7s00m$hh0$1...@dont-email.me>, on 11/12/2012

at 06:24 PM, Peter Flass <Peter...@Yahoo.com> said:

>My point, badly made perhaps, was that the programmer should
>modularize so as not to need many registers.

He should modularize regardless, but you have to carve the bird at the
joints. If you are dealing with complicated calculations, that can eat
up a lot of registers for intermediate results. If you are accessing
multiple data structures in a routine, that will chew up registers
regardless of how small the routine is.

>I have seen 360 assembler programs written a one monolithic CSECT,

I've seen worse; IEFZGST1 and IEFZGST2 were unspeakable.

>OTOH, I rarely need more than one base register for code at a time

The problem isn't base registers for code; it's base registers for
data.

[Shmuel Metz]

In <k7rprf$55l$1...@USTR-NEWS.TR.UNISYS.COM>, on 11/12/2012

at 09:31 PM, timca...@aol.com (Tim McCaffrey) said:

>I wonder if you can use the 256K flash to implement a 360
>emulator that would be fast enough to out run the 360/75?

256 KiB is rather small for a 360/75. As for speed, you would need to
access a double word[1] in a microsecond. Given the memory sizes of
current processors, and given that the S/360 architecture[2] did not
allow addressing more than 16 KiB, I can't imagine why you wouldn't
just use RAM.

[1] 64 bits plus parity.

[2] 360/67 doesn't count.

[Shmuel Metz]

In <icfw4ec...@home.home>, on 11/12/2012

at 07:48 PM, Dan Espen <des...@verizon.net> said:

>In modern assembler you don't need any registers for code.

ITYM in modern IBM z Serious boxen; other architectures are different.

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <k7s00m$hh0$1...@dont-email.me>, on 11/12/2012
> at 06:24 PM, Peter Flass <Peter...@Yahoo.com> said:
>
>>My point, badly made perhaps, was that the programmer should
>>modularize so as not to need many registers.
>
> He should modularize regardless, but you have to carve the bird at the
> joints. If you are dealing with complicated calculations, that can eat
> up a lot of registers for intermediate results. If you are accessing
> multiple data structures in a routine, that will chew up registers
> regardless of how small the routine is.
>
>>I have seen 360 assembler programs written a one monolithic CSECT,
>
> I've seen worse; IEFZGST1 and IEFZGST2 were unspeakable.

Allocation?

Somehow I'm not surprised.

Is the source online somewhere?

--
Dan Espen

[Tim McCaffrey]

In article <50a18f2b$11$fuzhry+tra$mr2...@news.patriot.net>,
spam...@library.lspace.org.invalid says...

>
>In <k7rprf$55l$1...@USTR-NEWS.TR.UNISYS.COM>, on 11/12/2012
> at 09:31 PM, timca...@aol.com (Tim McCaffrey) said:
>
>>I wonder if you can use the 256K flash to implement a 360
>>emulator that would be fast enough to out run the 360/75?
>
>256 KiB is rather small for a 360/75. As for speed, you would need to
>access a double word[1] in a microsecond. Given the memory sizes of
>current processors, and given that the S/360 architecture[2] did not
>allow addressing more than 16 KiB, I can't imagine why you wouldn't
>just use RAM.
>
>[1] 64 bits plus parity.
>
>[2] 360/67 doesn't count.
>

If I was doing it, I would propose that the 256K flash be used for the
emulator's code, and the 48K RAM be used for the emulated machines memory
(minus emulator storage, of course). Of course, 48K is a little tight, but
everybody keeps talking about running in 32K...

- Tim

[Gerard Schildberger]

On Monday, November 12, 2012 3:35:23 PM UTC-6, Tim McCaffrey wrote:
----- snipped -----

> I wonder if you can use the 256K flash to implement a 360 emulator that would
> be fast enough to out run the 360/75? :O
> - Tim

If Hercules can emulate 60 MIPS on a modest PC (on faster
engines, it can do over 300 MIPS on PCs available 3 years
ago), I see no reason why not.

An IBM 2075 (aka, 360/75) was about 0.89 MIPS.
_________________________________________ Gerard Schildberger

[Shmuel Metz]

In <ic7gppd...@home.home>, on 11/13/2012
at 09:02 AM, Dan Espen <des...@verizon.net> said:

>Allocation?

Yes.

>Somehow I'm not surprised.

>Is the source online somewhere?

I believe that the Hercules project has complete OS/360 source code.
I'm not responsible for your eyes if you look at those two modules.

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <ic7gppd...@home.home>, on 11/13/2012
> at 09:02 AM, Dan Espen <des...@verizon.net> said:
>
>>Allocation?
>
> Yes.
>
>>Somehow I'm not surprised.
>
>>Is the source online somewhere?
>
> I believe that the Hercules project has complete OS/360 source code.
> I'm not responsible for your eyes if you look at those two modules.

I took a look, no modules named like that.
I wouldn't expect Hercules to be using any IBM source code.
it's emulating the hardware, not MVS?

Last time I saw MVS source code I was using a microfiche reader.

--
Dan Espen

[Walter Banks]

Gerard Schildberger wrote:

> On Monday, November 12, 2012 3:35:23 PM UTC-6, Tim McCaffrey wrote:
> ----- snipped -----
> > I wonder if you can use the 256K flash to implement a 360 emulator that would
> > be fast enough to out run the 360/75? :O
> > - Tim
>
> If Hercules can emulate 60 MIPS on a modest PC (on faster
> engines, it can do over 300 MIPS on PCs available 3 years
> ago), I see no reason why not.
>
> An IBM 2075 (aka, 360/75) was about 0.89 MIPS.
> ___

I don't think it would have any problem emulating the
360/75 at full speed.

Does anyone have a link to a 360 emulator source or
email it to me privately and I will compile it and test it
on the board.

w,,

[Rich Alderson]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> 256 KiB is rather small for a 360/75. As for speed, you would need to
> access a double word[1] in a microsecond. Given the memory sizes of
> current processors, and given that the S/360 architecture[2] did not
> allow addressing more than 16 KiB, I can't imagine why you wouldn't
> just use RAM.

Leaving aside the stupidity of "MiB" and "KiB", the System/360 has a 24 bit
address space, for 16MB, not 16KB.

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

[Rich Alderson]

Walter Banks <wal...@bytecraft.com> writes:

> Does anyone have a link to a 360 emulator source or
> email it to me privately and I will compile it and test it
> on the board.

Hey, Walter, just go to Hercules.org and download it!

[hanc...@bbs.cpcn.com]

On Nov 13, 4:03 pm, Gerard Schildberger <gerar...@rrt.net> wrote:

> If Hercules can emulate 60 MIPS on a modest PC (on faster
> engines, it can do over 300 MIPS on PCs available 3 years
> ago), I see no reason why not.
>
> An IBM 2075 (aka, 360/75) was about 0.89 MIPS.

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?

Some years ago, wasn't comparative computer performance changed to
throughput or wall clock time for a given problem as opposed to MIPS,
to recognize I/O and other issues? Wasn't the S/370-158 used as a
baseline for that?

Thanks.

[Anne & Lynn Wheeler]

hanc...@bbs.cpcn.com writes:
> 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?
>
> Some years ago, wasn't comparative computer performance changed to
> throughput or wall clock time for a given problem as opposed to MIPS,
> to recognize I/O and other issues? Wasn't the S/370-158 used as a
> baseline for that?

s/370-158 & vax ... dhrystone 1mip
http://en.wikipedia.org/wiki/Instructions_per_second

e5-2690 @2.9GHZ 527.55BIPS (ratio of dhrystone iterations to 158/vax)

recent post discussing e5-2600 blade & current mainframes
http://www.garlic.com/~lynn/2012o.html#6 Mainframes are still the best platform for high volume transaction processing.

2005 Z9 17.8BIPS, 54processors 330MIPS/processor
2008 Z10 30BIPS, 64processors 460MIPS/processor
2010 Z196 50BIPS, 80processors 624MIPS/processor
2012 ZEC12 75BIPS, 101processors 743MIPS/processor

referenced post also discusses mainframe I/O thruput using "FICON"
channels.

FICON is an ibm mainframe channel emulation layer on top of
fibre-channel standard ... that drastically reduces the thruput compared
to the underlying fibre-channel capacity.

peak (mainframe) z196 at 2M IOPS with 104 FICON channels, 14 storage
subsystems and 14 "system assist processors"
ftp://public.dhe.ibm.com/common/ssi/ecm/en/zsw03169usen/ZSW03169USEN.PDF

references that 14 system assist processors peak is 2.2M SSCH/sec, all
running at 100% processor busy ... but recommends keeping SAPs at 70% or
less (1.5M SSCH/sec).

note that in addition to the enormous inefficiency introduced by
mainframe FICON layer (on top of underlying fibre-channel standard),
much of mainframe business processing also utilize "CKD" disks ...
something that hasn't been manufactured for decades ... current "CKD"
disks are another emulation layer built on top of industry standard
fixed-block disks (futher reducing throughput compared to directly using
underlying native capacity).

reference to (single) fibre-channel for e5-2600 capable of over million
IOPS (compared to z196 using 104 FICON channels to get 2M IOPS)
http://www.emulex.com/artifacts/0c1f55d0-aec6-4c37-bc42-7765d5d7a70e/elx_wp_all_hba_romley.pdf

fibre-channel from 1988 was designed to download complete i/o request
... significantly reducing protocol chatter and latency. IBM added FICON
layer that serialize ibm mainframe channel program emulation over the
underlying fibre-channel ... significantly increasing chatter and
latency (and decreasing throughput). This discusses some recent
enhancements for FICON ... somewhat recreating some of the underlying
original 1988 fibre channel characteristics
http://www-03.ibm.com/systems/z/hardware/connectivity/ficon_performance.html

while (max) ZEC12 documentation lists it as 50percent more processor
than (max) Z196 (75BIPS compared to 50BIPS), the documentation states
(max) ZEC12 DBMS throughput is only 30% more than (max) Z196 (seemingly
more of a I/O issue than processor issue).

recent posts mentioning e5-2600 and/or FICON:
http://www.garlic.com/~lynn/2012.html#90 Has anyone successfully migrated off mainframes?
http://www.garlic.com/~lynn/2012d.html#28 NASA unplugs their last mainframe
http://www.garlic.com/~lynn/2012d.html#43 Layer 8: NASA unplugs last mainframe
http://www.garlic.com/~lynn/2012d.html#50 Layer 8: NASA unplugs last mainframe
http://www.garlic.com/~lynn/2012d.html#64 Layer 8: NASA unplugs last mainframe
http://www.garlic.com/~lynn/2012e.html#3 NASA unplugs their last mainframe
http://www.garlic.com/~lynn/2012e.html#4 Memory versus processor speed
http://www.garlic.com/~lynn/2012e.html#27 NASA unplugs their last mainframe
http://www.garlic.com/~lynn/2012e.html#94 Can Mainframes Be Part Of Cloud Computing?
http://www.garlic.com/~lynn/2012e.html#99 Can Mainframes Be Part Of Cloud Computing?
http://www.garlic.com/~lynn/2012e.html#105 Burroughs B5000, B5500, B6500 videos
http://www.garlic.com/~lynn/2012f.html#0 Burroughs B5000, B5500, B6500 videos
http://www.garlic.com/~lynn/2012f.html#4 Can Mainframes Be Part Of Cloud Computing?
http://www.garlic.com/~lynn/2012f.html#7 Burroughs B5000, B5500, B6500 videos
http://www.garlic.com/~lynn/2012f.html#94 Time to competency for new software language?
http://www.garlic.com/~lynn/2012g.html#36 Should IBM allow the use of Hercules as z system emulator?
http://www.garlic.com/~lynn/2012g.html#38 Should IBM allow the use of Hercules as z system emulator?
http://www.garlic.com/~lynn/2012h.html#4 Think You Know The Mainframe?
http://www.garlic.com/~lynn/2012h.html#20 Mainframes Warming Up to the Cloud
http://www.garlic.com/~lynn/2012h.html#35 Monopoly/ Cartons of Punch Cards
http://www.garlic.com/~lynn/2012h.html#52 How will mainframers retiring be different from Y2K?
http://www.garlic.com/~lynn/2012h.html#62 What are your experiences with Amdahl Computers and Plug-Compatibles?
http://www.garlic.com/~lynn/2012i.html#11 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012i.html#16 Think You Know The Mainframe?
http://www.garlic.com/~lynn/2012i.html#47 IBM, Lawrence Livermore aim to meld supercomputing, industries
http://www.garlic.com/~lynn/2012i.html#54 IBM, Lawrence Livermore aim to meld supercomputing, industries
http://www.garlic.com/~lynn/2012i.html#84 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012i.html#88 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012i.html#95 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#1 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#13 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#34 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#46 Word Length
http://www.garlic.com/~lynn/2012j.html#66 Monopoly/ Cartons of Punch Cards
http://www.garlic.com/~lynn/2012j.html#95 printer history Languages influenced by PL/1
http://www.garlic.com/~lynn/2012j.html#96 The older Hardware school
http://www.garlic.com/~lynn/2012k.html#41 Cloud Computing
http://www.garlic.com/~lynn/2012k.html#69 ESCON
http://www.garlic.com/~lynn/2012k.html#80 360/20, was 1132 printer history
http://www.garlic.com/~lynn/2012l.html#20 X86 server
http://www.garlic.com/~lynn/2012l.html#27 PDP-10 system calls, was 1132 printer history
http://www.garlic.com/~lynn/2012l.html#28 X86 server
http://www.garlic.com/~lynn/2012l.html#30 X86 server
http://www.garlic.com/~lynn/2012l.html#34 X86 server
http://www.garlic.com/~lynn/2012l.html#39 The IBM zEnterprise EC12 announcment
http://www.garlic.com/~lynn/2012l.html#42 I.B.M. Mainframe Evolves to Serve the Digital World
http://www.garlic.com/~lynn/2012l.html#51 Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012l.html#56 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012l.html#81 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012l.html#87 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012l.html#88 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012l.html#90 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012l.html#100 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012m.html#2 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012m.html#3 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012m.html#4 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012m.html#5 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012m.html#13 Intel Confirms Decline of Server Giants HP, Dell, and IBM
http://www.garlic.com/~lynn/2012m.html#28 I.B.M. Mainframe Evolves to Serve the Digital World
http://www.garlic.com/~lynn/2012m.html#31 Still think the mainframe is going away soon: Think again. IBM mainframe computer sales are 4% of IBM's revenue; with software, services, and storage it's 25%
http://www.garlic.com/~lynn/2012m.html#43 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
http://www.garlic.com/~lynn/2012m.html#67 How do you feel about the fact that today India has more IBM employees than any of the other countries in the world including the USA.?
http://www.garlic.com/~lynn/2012n.html#9 How do you feel about the fact that today India has more IBM employees than any of the other countries in the world including the USA.?
http://www.garlic.com/~lynn/2012n.html#13 System/360--50 years--the future?
http://www.garlic.com/~lynn/2012n.html#14 System/360--50 years--the future?
http://www.garlic.com/~lynn/2012n.html#19 How to get a tape's DSCB
http://www.garlic.com/~lynn/2012n.html#44 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe?
http://www.garlic.com/~lynn/2012n.html#46 history of Programming language and CPU in relation to each
http://www.garlic.com/~lynn/2012n.html#48 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe?
http://www.garlic.com/~lynn/2012n.html#50 history of Programming language and CPU in relation to each
http://www.garlic.com/~lynn/2012n.html#51 history of Programming language and CPU in relation to each
http://www.garlic.com/~lynn/2012n.html#56 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe?
http://www.garlic.com/~lynn/2012n.html#69 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe?
http://www.garlic.com/~lynn/2012n.html#70 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe?
http://www.garlic.com/~lynn/2012n.html#72 Mainframes are still the best platform for high volume transaction processing
http://www.garlic.com/~lynn/2012o.html#11 Mainframes are still the best platform for high volume transaction processing

--
virtualization experience starting Jan1968, online at home since Mar1970

[Shmuel Metz]

In <ic4nktb...@home.home>, on 11/13/2012
at 05:24 PM, Dan Espen <des...@verizon.net> said:

>I took a look,

At what?

>I wouldn't expect Hercules to be using any IBM source code.

Nor did I say that they were. The Hercules project has archived more
than just the code for Hercules. However, it appears to be a different
group that is offering the OS/360 source tapes on CD-ROM,
<http://www.cbttape.org/cdrom.htm>.

[Walter Bushell]

In article <50A2E31C...@bytecraft.com>,

But the I/O channels? Wasn't the 360 line mostly about I/O?

[Gerard Schildberger]

On Tuesday, November 13, 2012 10:23:57 PM UTC-6, Walter Bushell wrote:
>> Gerard Schildberger wrote:
>>> On Monday, November 12, 2012 3:35:23 PM UTC-6, Tim McCaffrey wrote:
>>> ----- snipped -----
>>>> I wonder if you can use the 256K flash to implement a 360 emulator that
>>>> would be fast enough to out run the 360/75? :O
>>>> - Tim

>>> If Hercules can emulate 60 MIPS on a modest PC (on faster
>>> engines, it can do over 300 MIPS on PCs available 3 years
>>> ago), I see no reason why not.

>>> An IBM 2075 (aka, 360/75) was about 0.89 MIPS. ___ Gerard S.

>> I don't think it would have any problem emulating the
>> 360/75 at full speed.

>> Does anyone have a link to a 360 emulator source or
>> email it to me privately and I will compile it and test it
>> on the board.
>> w,,

> But the I/O channels? Wasn't the 360 line mostly about I/O?

Yes, especially if the channels were outboard instead of
inboard. Inboard channels stole "CPU" cycles for execution
and memory access(es). _________________ Gerard Schildberger

[Shmuel Metz]

In <50A2E31C...@bytecraft.com>, on 11/13/2012

at 07:17 PM, Walter Banks <wal...@bytecraft.com> said:

>Does anyone have a link to a 360 emulator source

Well, since the OP mentioned Hercules, why not go to their web site at
<http://www.hercules-390.org/>?

[Shmuel Metz]

In <proto-D8DF3B....@news.panix.com>, on 11/13/2012

at 11:23 PM, Walter Bushell <pr...@panix.com> said:

>But the I/O channels? Wasn't the 360 line mostly about I/O?

The S/360 was about a common architecture; that includes CPU, I/O abd
recovery from errors. The channel architecture is a small piece of
that.

A normal Hercules user will be simulating S/360 I/O gear on PC devices
and will not need to attach to real S/360 I/O control units and
devices. I believe that Hercules does support channel cards, but if so
not many would use that feature.

[Peter Flass]

On 11/13/2012 9:10 PM, hanc...@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).

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.


--
Pete

[Ahem A Rivet's Shot]

On Tue, 13 Nov 2012 18:10:29 -0800 (PST)
hanc...@bbs.cpcn.com wrote:

> On Nov 13, 4:03 pm, Gerard Schildberger <gerar...@rrt.net> wrote:
>
> > If Hercules can emulate 60 MIPS on a modest PC (on faster
> > engines, it can do over 300 MIPS on PCs available 3 years
> > ago), I see no reason why not.
> >
> > An IBM 2075 (aka, 360/75) was about 0.89 MIPS.
>
> Ok, a PC's CPU is faster today, but what about I/O and the channels,

Modern PCs have impressive I/O, SATA channels run at up to 300MB/s,
multiple gigait NICs are possible and I've seen two PCs copying data from
disc (array) on one box to disc (array) on the other saturating the gigabit
ethernet between them, the discs were less than 50% busy and the CPUs were
practically idle. If the network hadn't been saturated the discs would have
been the next limiting factor.

> and multiprogramming? The S/360 hardware was designed to handle all
> of that efficiently, how efficiently would a PC handle it all?

A modern PC CPU is at least as good at multi-tasking as any 360.
I'd say very efficiently (modulo presence of crap software).

> 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?

That might be quite difficult - but a modern PC running a web
service does a *lot* more work.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Walter Banks]

Rich Alderson wrote:

> Walter Banks <wal...@bytecraft.com> writes:
>
> > Does anyone have a link to a 360 emulator source or
> > email it to me privately and I will compile it and test it
> > on the board.
>
> Hey, Walter, just go to Hercules.org and download it!
>

Thanks found it . The actual link is

http://www.hercules-390.org/

w..

[Walter Banks]

"Shmuel (Seymour J.) Metz" wrote:

> In <50A2E31C...@bytecraft.com>, on 11/13/2012
> at 07:17 PM, Walter Banks <wal...@bytecraft.com> said:
>
> >Does anyone have a link to a 360 emulator source
>
> Well, since the OP mentioned Hercules, why not go to their web site at
> <http://www.hercules-390.org/>?

Thanks I really should read all the responses first. I read this
just after I found the link

w..

[Walter Banks]

Walter Bushell wrote:

> In article <50A2E31C...@bytecraft.com>,
> Walter Banks <wal...@bytecraft.com> wrote:
>
> > Gerard Schildberger wrote:
> >
> > > On Monday, November 12, 2012 3:35:23 PM UTC-6, Tim McCaffrey wrote:
> > > ----- snipped -----
> > > > I wonder if you can use the 256K flash to implement a 360 emulator that
> > > > would
> > > > be fast enough to out run the 360/75? :O
> > > > - Tim
> > >
> > > If Hercules can emulate 60 MIPS on a modest PC (on faster
> > > engines, it can do over 300 MIPS on PCs available 3 years
> > > ago), I see no reason why not.
> > >
> > > An IBM 2075 (aka, 360/75) was about 0.89 MIPS.
> > > ___
> >
> > I don't think it would have any problem emulating the
> > 360/75 at full speed.
> >
> > Does anyone have a link to a 360 emulator source or
> > email it to me privately and I will compile it and test it
> > on the board.
> >

> > w..

>
> But the I/O channels? Wasn't the 360 line mostly about I/O?

That may be doable with either of these boards. They both
have a second processor on board for debugging that one
way or another accesses main processor memory. It may
actually be possible to emulate channel memory access.
The second processor has a bootstrap mode that makes it
programmable.

w..

[Anne & Lynn Wheeler]

Gerard Schildberger <gera...@rrt.net> writes:
> Yes, especially if the channels were outboard instead of
> inboard. Inboard channels stole "CPU" cycles for execution
> and memory access(es). _________________ Gerard Schildberger

re:
http://www.garlic.com/~lynn/2012o.html#19 Assembler vs. COBOL--processing time, space needed
http://www.garlic.com/~lynn/2012o.html#20 Assembler vs. COBOL--processing time, space needed
http://www.garlic.com/~lynn/2012o.html#21 Assembler vs. COBOL--processing time, space needed

low-end &mid-range 360 processors had integrated channels ... i.e. same
engine that executed the 360 instruction set microcode also executed the
channel microcode. 360/65(67) and above had external channels.

note that even external channels doing lots of i/o, could cause lots of
memory bus interference for the processor.

undergraduate I had done the cp67 changes to support tty/ascii terminals
... and tried to make the ibm 2702 terminal controller do something that
it couldn't quite do. this somewhat prompted the univ to start a clone
controller effort ... reverse engineer channel interface and build
channel interface controller board for interdata/3 programmed to emulate
2702 (and also do what I tried with the 2702). late four of us were
written up as responsible for (some part of) the clone controller business
... some past posts
http://www.garlic.com/~lynn/subtopic.html#360pcm

an early bug was the controller "held" the channel ... which "held" the
memory bus ... which resulted in the processor "red-light". The issue
was that the 360/67 high-frequency timer "tic'ed" approx. every 13mics
and needed to update the location 80 timer field. If the timer tic'ed
while a previous timer memory update was still pending, the processor
would stop with hardware error. the clone controller had to frequently
"free" the channel (which in turned "freed" the memory bus) ... to
allow for timer-tic update.

later at the science center ... the 360/67 was "upgraded" from a
"simplex" to dual-processor 360/67. the multiprocessor 360/67 was unique
in 360s that added a "channel controller" and multi-ported memory that
provided channel interface with independent interface. the multi-ported
memory interface slowed the processor memory bus cycle by 10-15% ... a
single-processor "half-duplex" 360/67 (single processor with channel
controller) would run that much slower for compute intensive workload.
However a simplex 360/67 running 100% cpu concurrent with heavy i/o
workload would have lower thruput than same workload on a half-duplex
(single processor with channel controller) 360/67. misc. past posts
mentioning multiprocessor (&/or compare&swap instruction)
http://www.garlic.com/~lynn/subtopic.html#smp

note that clone controller business was major motivation for the
"failed" future system effort ... some past posts
http://www.garlic.com/~lynn/submain.html#futuresys

during "future system" period lots of 370 activity was killed off (and
the lack of 370 products during this period is credited with giving
clone processors a market foothold) ... but when FS was killed ... there
was mad rush to get stuff back into the 370 product pipelines. this
included the q&d 303x in parallel with 3081 using some warmed over FS
technology.

370/158 had integrated channels, for 303x ... there was an external
"channel director" by taking the 370/158 engine and eliminating the 370
instruction microcode. A 3031 was a 370/158 engine with just the 370
instruction microcode and a 2nd 370/158 engine with just the integrated
microcode engine. A 3032 was a 370/168 reconfigured to use the 303x
channel director. A 3033 was 370/168 logic remapped to 20% faster chips
... but with something like 10 times the circuits/chip. During 3033
development, some logic rework was done to take advantage of the extra
circuits eventually resulting in 3033 being 50% faster than 370/158.

The 360/370 channel architecture was half-duplex, end-to-end handshaking
(between channel and end-device) and designed to be "shared" with lots
of concurrent device activity. The end-to-end handshaking could result
in enormous "channel busy" and latency ... especially with slow
controllers.

I've repeated before that common configuration for "large systems" (16
channels) tended to be both disk controllers and 3270 terminal
controllers spread across the same channels. In special project for STL
moving 300 people from the IMS group to off-site location, I did support
for HYPERchannel operating as channel extender. HYPERChannel remote
device adapters were at the remote location with local
"channel-attached" 3270 controllers moved to the remote location ... and
HYPERChannel adapter used on the real channels. The HYPERChannel
adapters had much faster processor than the 3270 controllers ... so
identical operations resulted in much lower channel busy (especially
hand-shaking controller operations) ... and the move resulted in 10-15%
increase in workload throughput (lower channel busy interferance with
disk operations).

A similar but different was the development of the 3880 disk controller
(replacing 3830) for 3mbyte 3380 disks. While the transfer rate when up
by factor of ten times, the 3880 processor engine was much slower than
the 3830 it replaced (significantly channel busy for control
hand-shaking operations). The 3090 processor had originally configured
max. number of configuration channels based on assumption that 3880
would have same channel busy control operations a 3830. When they found
out how bad the 3880 controller actually was, they had to significantly
increase the number of channels (in order to achieve target system
throughput). This increased the number of TCMs needed to manufactor a
3090 ... a big hit to the 3090 manufacturing cost ... there was joke
that 3090 group was going to bill the 3880 group for the increase in
3090 manufacturing cost. This in large part accounted for subsequent
myths about the massive number of mainframe channels increasing i/o
throughput (when it was actually to compensate for the implementation
short-comings of half-duplex, end-to-end operation).

Fibre-channel effort originated circa 1988 at LLNL looking at
standardizing was serial technology that they were using in house (this
was about the same time that LANL started work on HiPPI for 100mbyte/sec
standards version of half-duplex cray channel). A big push in
fibre-channel was pairs of serial transfer, one dedicated for concurrent
transfer in each direction. Part of the effort was fully concurrent
asynchronous operation to compensate for the increasing role that
end-to-end latency played as transfer rates increased. Part of this was
complete transfer of request to remote end as asynchronous operation
with results coming back ... minimizing the number of end-to-end
operations for doing I/O (and the associated latency turn-around).
reference to early jan1992 meeting doing cluster-scaleup for commercial
using fibre-channel standard
http://www.garlic.com/~lynn/95.html#13
misc. past ha/cmp postings
http://www.garlic.com/~lynn/subtopic.html#hacmp

above references also wanting to reform (serial) 9333/harrier to
interoperate with fibre-channel ... instead it was done as its own
unique coming out as SSA. It was part of working with LLNL on
fibre-channel ... as well as working with LLNL on cluster-scaleup for
numeric intensive & scientific workload ... some old email on
cluster-scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

possibly only hrs after the last email above (end of jan1992), the
cluster-scaleup work was transferred and we were told we couldn't work
on anything with more than four processors. A couple weeks later
(17Feb1992), it was announced as IBM supercomputer for numeric intensive
and scientific *ONLY*. old press reference:
http://www.garlic.com/~lynn/2001n.html#6000clusters1
later that spring (11May1992), press about clusters had caught the
company "by surprise" ... even though I had been working on it for
some time with various customers.
http://www.garlic.com/~lynn/2001n.html#6000clusters2

The later IBM mainframe FICON effort effectively layered the standard
half-duplex characteristic on-top of fibre-channel standard ... carrying
with it all the throughput limitations of the high number of end-to-end
operations and associated latencies (drastically cutting the throughput
of the FICON layer compared to that of the underlying fibre-channel).

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <ic4nktb...@home.home>, on 11/13/2012
> at 05:24 PM, Dan Espen <des...@verizon.net> said:
>
>>I took a look,
>
> At what?

Hercules source code.

>>I wouldn't expect Hercules to be using any IBM source code.
>
> Nor did I say that they were. The Hercules project has archived more
> than just the code for Hercules. However, it appears to be a different
> group that is offering the OS/360 source tapes on CD-ROM,
> <http://www.cbttape.org/cdrom.htm>.

I really don't want a CD. I can download a CD work of data pretty quickly.

I tried to follow the links to MVS3.8 downloads but they are all broken.

Oh well, only so much work I'm willing to do to see crappy code, even if
it's prize winning crappy code.

--
Dan Espen

[Scott Lurndal]

hanc...@bbs.cpcn.com writes:

>On Nov 13, 4:03=A0pm, Gerard Schildberger <gerar...@rrt.net> wrote:
>
>> If Hercules can emulate 60 MIPS on a modest PC (on faster
>> engines, it can do over 300 MIPS on PCs available 3 years
>> ago), I see no reason why not.
>>
>> An IBM 2075 (aka, 360/75) was about 0.89 MIPS.
>
>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?

Given that all server-grade PC I/O hardware offloads most of the
processing, current PC hardware will outperform a S/360 by
a significant margin. An intel sandybridge, for example,
provides up to 40 lanes of generation 3 PCI-Express. A four-lane gen3
peripheral device can transfer north of 2 gigabytes/second,
and the processor could support 10 of these (or fewer wider
devices - e.g. two x16 (used for graphics typically) and a
pair of x4) for a total throughput _per processor socket_
of north of 20 gigabytes/second.

There are now SSD devices (particularly NVM-Express cards)
that provide read and writes speeds north of 600Mbytes/second,
and even consumer grade SSD devices do north of 200Mbytes/second;
I think a modern server grade PC easily provides significantly more
I/O capacity than any 360 or 370-class machine, particularly at the
low-end.

I suspect that even a consumer grade PC with a few 7200RPM SATA drives
will handily support any I/O workload generated by a 360-class machine.

s

[Scott Lurndal]

Dan Espen <des...@verizon.net> writes:
>Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>
>> In <ic4nktb...@home.home>, on 11/13/2012
>> at 05:24 PM, Dan Espen <des...@verizon.net> said:
>>
>>>I took a look,
>>
>> At what?
>
>Hercules source code.
>
>>>I wouldn't expect Hercules to be using any IBM source code.
>>
>> Nor did I say that they were. The Hercules project has archived more
>> than just the code for Hercules. However, it appears to be a different
>> group that is offering the OS/360 source tapes on CD-ROM,
>> <http://www.cbttape.org/cdrom.htm>.
>
>I really don't want a CD. I can download a CD work of data pretty quickly.
>
>I tried to follow the links to MVS3.8 downloads but they are all broken.

try http://www.bsp-gmbh.com/turnkey/index.html

The CD is: http://www.ibiblio.org/jmaynard/turnkey-mvs-3.zip

scott

[Charlie Gibbs]

In article <k7tq2f$m0v$1...@USTR-NEWS.TR.UNISYS.COM>, timca...@aol.com

(Tim McCaffrey) writes:

> If I was doing it, I would propose that the 256K flash be used
> for the emulator's code, and the 48K RAM be used for the emulated
> machines memory (minus emulator storage, of course). Of course,
> 48K is a little tight, but everybody keeps talking about running
> in 32K...

"Everybody talks about the weather, but nobody does anything
about it."

Mark Twain was definitely not a marketroid.

--
/~\ 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!

[Charles Richmond]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote in message
news:740.736T7...@kltpzyxm.invalid...

> In article <k7tq2f$m0v$1...@USTR-NEWS.TR.UNISYS.COM>, timca...@aol.com
> (Tim McCaffrey) writes:
>
>> If I was doing it, I would propose that the 256K flash be used
>> for the emulator's code, and the 48K RAM be used for the emulated
>> machines memory (minus emulator storage, of course). Of course,
>> 48K is a little tight, but everybody keeps talking about running
>> in 32K...
>
> "Everybody talks about the weather, but nobody does anything
> about it."
>
> Mark Twain was definitely not a marketroid.
>

"Climate is what you expect. Weather is what you get." -- Mark Twain

--

numerist at aquaporin4 dot com

[Dan Espen]

Thanks Scott, downloading now.


--
Dan Espen

[Shmuel Metz]

In <k804pq$gn0$1...@dont-email.me>, on 11/14/2012

at 08:09 AM, Peter Flass <Peter...@Yahoo.com> said:

>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.

Well, if I were running Hercules and wanted to support remote users,
I'd go for a TN3270 server rather than a coax adapter or a synchronous
serial adapter.

[Shmuel Metz]

In <3%Oos.88181$Kv.2...@fed10.iad>, on 11/14/2012

at 03:43 PM, sc...@slp53.sl.home (Scott Lurndal) said:

>I suspect that even a consumer grade PC with a few 7200RPM SATA
>drives will handily support any I/O workload generated by a 360-class
>machine.

The fastest I/O channel on a S/360 was 3.0 MB/s, and that only on the
360/85 and 360/195. The number of I/O channels was severely limited.
The I/O bandwidth was nowhere near what you can get on z Series.

[Bill Marcum]

On 11/13/2012 11:23 PM, Walter Bushell wrote:
>
>
> But the I/O channels? Wasn't the 360 line mostly about I/O?
>

Of course a 360 could have dozens of disk and tape drives and still have
less storage than a flash drive can hold today.

[Peter Flass]

On 11/14/2012 8:38 AM, Ahem A Rivet's Shot wrote:
>
> A modern PC CPU is at least as good at multi-tasking as any 360.
> I'd say very efficiently (modulo presence of crap software).
>

Well, I guess that lets windoze out.

--
Pete

[Peter Flass]

On 11/14/2012 6:41 PM, Shmuel (Seymour J.) Metz wrote:
> In <k804pq$gn0$1...@dont-email.me>, on 11/14/2012
> at 08:09 AM, Peter Flass <Peter...@Yahoo.com> said:
>
>> 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.
>
> Well, if I were running Hercules and wanted to support remote users,
> I'd go for a TN3270 server rather than a coax adapter or a synchronous
> serial adapter.
>

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.

--
Pete

[Charles Richmond]

"Bill Marcum" <bi...@nowhere.invalid> wrote in message
news:k82b2t$lob$1...@speranza.aioe.org...

"It is the business of the future to make the past look ridiculous." -- me
:-)

[Anne & Lynn Wheeler]

Peter Flass <Peter...@Yahoo.com> writes:
> 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.

re:
http://www.garlic.com/~lynn/2012o.html#19 Assembler vs. COBOL--processing time, space needed
http://www.garlic.com/~lynn/2012o.html#20 Assembler vs. COBOL--processing time, space needed
http://www.garlic.com/~lynn/2012o.html#21 Assembler vs. COBOL--processing time, space needed

http://www.garlic.com/~lynn/2012o.html#22 Assembler vs. COBOL--processing time, space needed

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.

channels would mostly be integrated (aka processor engine executing both
the 360 instruction microcode and the integrated channel microcode)
... didn't get separate channels until 360/65.

then you have 2311 & 2314 disk controllers ... 2702 terminal
controllers, etc.

here is old comparison of 360/67 running cp67 with similar cms workload
to vm370 running on 3081.
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door

I had been making such statements about relative system throughput
decline of disk technology since the later half of the 70s. The disk
division executives took exception with the above and assigned the
division performance group to refute the comparison ... after a couple
weeks they came back and essentially said I had slightly understated the
situation. old posts with reference to the analysis
http://www.garlic.com/~lynn/2001l.html#46 MVS History (all parts)
http://www.garlic.com/~lynn/2006f.html#3 using 3390 mod-9s

part of the discussion ... that continues today ... is that the
processor rate has gotten substantially faster than other components
... today's delay for a cache miss (access to memory), when delay is
measured in number of processor cycles ... is compareable to to 360 disk
access delay (when disk access is measured in number of 360 processor
cycles). this trend has resulted in various approaches allowing current
processors to switch to other work while waiting for cache-miss ...
compareable to multitasking approach for 360s. Today is hyperthreading
(additional instruction streams simulating multiple processors) and
out-of-order execution.

Also most processor caches are now (substantially) larger than total 360
real storage (and main memory now larger than 360 disk storage)

I've recently noted that for few generations of i86 are really risc
cores with hardware layer translating i86 instructions into risc
micro-ops ... helping to moderate the throughput advantage that risc has
had over i86 ... things like risc has had out-of-order executation for
decades.

big part of z196 processor throughput increase over z10 is supposedly
the introduction of out-of-order execution ... with further out-of-order
refinements done for zec12

* 2005 Z9 17.8BIPS 54processor 330MIPS/processor
* 2008 Z10 30BIPS 64processor 460MIPS/processor
* 2010 Z196 50BIPS 80processor 625MIPS/processor
* 2012 zec12 75BIPS 101processor 743MIPS/processor

as aside ... the above referenced post from 1993 (regarding 67/3081
comparison from the early 80s) was in the period that mainframe channel
engineers were appearing at fibre-channel meetings and pushing their
higher layer that would eventually become FICON (FICON layer resulting
in drastically reduced throughput compared to the underlying

[Shmuel Metz]

In <k82r8f$a11$2...@dont-email.me>, on 11/15/2012

at 08:44 AM, Peter Flass <Peter...@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?

[Stan Dandy Liver]

On Wed, 14 Nov 2012 13:09:22 -0000, Peter Flass <Peter...@yahoo.com>
wrote:

> On 11/13/2012 9:10 PM, hanc...@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.
>
>


--

[dash dash space newline 4line sig]

Money/Life question

[Peter Flass]

TXSeries? Previous OS/2 software had the ability to connect with
Database Manager using SQL. I'd presume the windoze flavors have
similar capability.


--
Pete

[hanc...@bbs.cpcn.com]

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.

[Anne & Lynn Wheeler]

hanc...@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.

re:
http://www.garlic.com/~lynn/2012o.html#24 Assembler vs. COBOL--processing time, space needed

mip rates from:
http://osdir.com/ml/emulators.hercules390.general/2002-10/msg00578.html

2065 360/65 .70
2067 rpq 360/67 .98
2075 360/75 .89
3158-3 370/158 1.00
4341-1 370/4341 .88

dhrystone has vax & 158-3 at 1mips
http://en.wikipedia.org/wiki/Million_instructions_per_second

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.

2400ft 800bpi ... 20mbytes.
http://www.dataconversionresource.com/9-track_magnetic_reel_tape_1600%20BPI_6250%20BPI.htm

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.

[Shmuel Metz]

In <m3zk2dg...@garlic.com>, on 11/19/2012

at 10:27 PM, Anne & Lynn Wheeler <ly...@garlic.com> said:

>2065 360/65 .70
>2067 rpq 360/67 .98
>2075 360/75 .89

What RPQ causes a 360/67 to be faster than a 360/65, much less faster
than a 360/75?

>3158-3 370/158 1.00
>4341-1 370/4341 .88

Weighted toward decimal or toward floating point?

[Walter Bushell]

In article <50a003aa$25$fuzhry+tra$mr2...@news.patriot.net>,

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid>

wrote:

> In <k7oa6d$ped$3...@dont-email.me>, on 11/11/2012
> at 08:53 AM, Peter Flass <Peter...@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.

--
This space unintentionally left blank.

[Shmuel Metz]

In <proto-123D0B....@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.

[1] Including successors to the ones I list.

[Scott Lurndal]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>In <proto-123D0B....@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).

scott

[Shmuel Metz]

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.

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> 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.

--
Dan Espen

[Peter Flass]

Aren't "true bytes" something out of a "Twilight" movie?

--
Pete

[Walter Bushell]

In article <icpq1gw...@home.home>, 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.

>
> True-bytes just sounds weird and doesn't pass the Google test.

--

[Dan Espen]

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.

--
Dan Espen

[jmfbahciv]

Shmuel (Seymour J.) Metz wrote:

> 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.
>

/BAH

[hanc...@bbs.cpcn.com]

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.

[Dan Espen]

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.

--
Dan Espen

[Charlie Gibbs]

In article <kch4lc$cm0$1...@dont-email.me>, Peter...@Yahoo.com

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!

[Shmuel Metz]

In <proto-EC386F....@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.

[Shmuel Metz]

In <kch4lc$cm0$1...@dont-email.me>, on 01/08/2013

at 07:56 AM, Peter Flass <Peter...@Yahoo.com> said:

>Aren't "true bytes" something out of a "Twilight" movie?

I wouldn't know; I had the word addressability in my statement and
have no idea what a redacted version would mean.

[Shmuel Metz]

In <icpq1gw...@home.home>, on 01/07/2013

at 09:57 PM, Dan Espen <des...@verizon.net> said:

>"True-byte"?

>I think you just made that up.

Not I, half a century ago, and make that true byte *addressability*.

>Google says:

I'm more concerned with what Werner Buchholz et al wrote.

>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.

That's because your background is too narrow.

>True-bytes just sounds weird and doesn't pass the Google test.

Google test? I don't need no stinking google test; I go to original
sources.

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <icpq1gw...@home.home>, on 01/07/2013
> at 09:57 PM, Dan Espen <des...@verizon.net> said:
>
>>"True-byte"?
>
>>I think you just made that up.
>
> Not I, half a century ago, and make that true byte *addressability*.
>
>>Google says:
>
> I'm more concerned with what Werner Buchholz et al wrote.

Hmm, 1956, I'm 11 years old.

>>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.
>
> That's because your background is too narrow.

Ah, but by asking, I learn.

>>True-bytes just sounds weird and doesn't pass the Google test.
>
> Google test? I don't need no stinking google test; I go to original
> sources.

Interestingly, this thread hasn't moved true-byte into the realm of
Google hits yet. Usually Google picks up stuff pretty quick.

--
Dan Espen