🚀 go-pugleaf

On 2018-01-27, Bob Eager <news...@eager.cx> wrote:

> On Sat, 27 Jan 2018 20:18:37 +0000, Charlie Gibbs wrote:
>
>> On 2018-01-27, Quadibloc <jsa...@ecn.ab.ca> wrote:
>> 
>>> I would say that it must have been a good idea, because what the later
>>> x86 did with segment + offset was very nearly the same thing.
>> 
>> The 360's "4k barrier" wasn't nearly as onerous as the x86's 64K
>> barrier; at least the 360's registers could hold a full address.
>
> FSVO full - 24 bits? (until XA)

Yup.  But at least the registers were 32 bits wide, leaving room
for expansion.  On the x86, on the other hand, it was a pain trying
to navigate a 20-bit address space with 16-bit registers.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

In article <b204534e-f56c-4b29...@googlegroups.com>,
>Memory addressing was a big issue in the original concept of 
>System/360.  Small machines had simple addresses which saved
>memory, big machines had more complex addresses.  Providing space
>for a large address was wasteful in a small machine, most
>S/360 users were getting small ones.  As a compromise, IBM came
>up with the base+displacement method.

All 360s other than the /20 used the same addressing, full 24 bit
addresses, instructions used base register plus 12 bit displacement
sometimes plus index register.  Base register 0 meant direct
addressing with the 12 bit displacement, but as far as I know that was
used only in little bits of startup and trap handler code, not in
applications.

>From my recollection of the discussion of the 360 design in the 1964
IBM System Journal, they correctly observed that this would make code
smaller than direct or indirect addressing.  But they also claimed it
would make programs position independent, which was rather
overoptimistic.  It's true, the code itself is position independent if
you follow some common conventions, but real programs all have
pointers stored in memory, which have to be relocated if the program
moves.

TSS/360 had real reentrant position independent code that could be
mapped to different places in different address spaces, but it made
the programming a lot more complex -- every program had to be divided
into position independent shared CSECTs and relocatable unshared
PSECTs, and the calling sequence got much more complex because the
caller had to pass a pointer to the called routine's PSECT at each
call.

The 360/20 was different.  There were 8 16-bit registers numbered
8-16.  For addressing, if the high bit of the base register number
was 0, the other 3 bits along with the displacement were taken as
an absolute address.  You could think of it as pseudo registers 0
through 7 containing fixed addresses 0, 4K, 8K, ... 28K.  Since
the /20 only had half a set of registers, saving the register that
would have been the base register mattered.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <jo...@taugh.com> writes:

> In article <b204534e-f56c-4b29...@googlegroups.com>,
>>Memory addressing was a big issue in the original concept of 
>>System/360.  Small machines had simple addresses which saved
>>memory, big machines had more complex addresses.  Providing space
>>for a large address was wasteful in a small machine, most
>>S/360 users were getting small ones.  As a compromise, IBM came
>>up with the base+displacement method.
>
> All 360s other than the /20 used the same addressing, full 24 bit
> addresses, instructions used base register plus 12 bit displacement
> sometimes plus index register.  Base register 0 meant direct
> addressing with the 12 bit displacement, but as far as I know that was
> used only in little bits of startup and trap handler code, not in
> applications.

MVS applications often get system information
by using an address at a fixed low storage location (CVT at 16).

-- 
Dan Espen

And the register to register version of the jump to subroutine instruction 
allows a program to find its own address, needed to start loading its 
base registers.

On 2018-01-28, Dan Espen <dan1...@gmail.com> wrote:

> John Levine <jo...@taugh.com> writes:
>
>> In article <b204534e-f56c-4b29...@googlegroups.com>,
>>
>>> Memory addressing was a big issue in the original concept of 
>>> System/360.  Small machines had simple addresses which saved
>>> memory, big machines had more complex addresses.  Providing space
>>> for a large address was wasteful in a small machine, most
>>> S/360 users were getting small ones.  As a compromise, IBM came
>>> up with the base+displacement method.
>>
>> All 360s other than the /20 used the same addressing, full 24 bit
>> addresses, instructions used base register plus 12 bit displacement
>> sometimes plus index register.  Base register 0 meant direct
>> addressing with the 12 bit displacement, but as far as I know that was
>> used only in little bits of startup and trap handler code, not in
>> applications.
>
> MVS applications often get system information
> by using an address at a fixed low storage location (CVT at 16).

It also lets you use Load Address to load a constant from 0 to
4095 inclusive into a register (although if you're setting the
register to zero it's faster to subtract it from itself).

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

Dan Espen <dan1...@gmail.com> writes:
> MVS applications often get system information by using an address at a
> fixed low storage location (CVT at 16).

os/360 had convention of CVT at 16 ... moved first to 370 VS2/SVS
... single virtual storage ... effectively MVT layed out in a single
16mbyte virtual address space ... not all that different from running
MVT in CP67 16mbyte memory virtual machine ... except a little bit of
code for building the segment/page table and handling page fault.  Old
post about justifying all 370 to virtual memory ... because MVT
application storage management was so bad ... program regions had to be
four times larger than storage actually used ... typical 370/165 1mbyte
MVT only could have four regions. Move to SVS would allow increasing
number of concurrent regions with little or no paging.
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory

The biggest VS2/SVS effort was to do channel program translation
... which they started out by borrowing the CCWTRAN routine from
CP67. MVT application standard was usually application library would
build channel programs with real addresses and execute EXCP SVC 0 to
perform the SIO for the channel program. Moving to SVS ... the
application channel programs were all virtual ... so EXCP had to build
copy channel program with real addresses ... effectively the same as
what CP67 had to do for virtual machines.

Move from VS2/SVS to VS2/MVS (each application having its own 16mbyte
virtual addres space) was problem. OS/360 application API convention is
heavily pointer passing. That means calls need to have access to API
parameters accessed by the API pointer. To start with that had an 8mbyte
image of the MVS kernel in (half) of every application 16mbyte virtual
address space (leaving only 8mbytes for the application). Then all the
"subsystems" were also put into their separate address space (just like
applications) ... however application API call to subsystem no longer
could access the parameter information. So to fix that, they defined a
API "common segment" that appears in every address space (leaving only
7mbytes for applications). Applications would allocated storage in the
common segment area (CSA) for parameters being based to subsystem in
different address space. The need for common segment space is somewhat
proportional to size of system, number of concurrent applications and
number of subsystems ... and quickly exceeded 1mbyte ... and is renamed
common system area (still CSA). By 3033 timeframe it was threatening to
exceed 6mbytes ... becoming 8mbytes ... leaving zero mbytes for
application programs (in each 16mbyte application vritual address
space).

Somewhat as kludge, somebody (who later left for HP and was involved in
snake & itanium) retrofitted some of XA "access registers" to 3033 as
dual address space mode ... semi-privileged subsystems could directly
access application address space (for parameters) ... w/o needing CSA.

XA allowed for 31bit virtual address space ... but theoritically could
have addressing for eight different virtual address spaces. To go along
with "access registers" they created "program call" (and return)
instructions ... which access kernel table that had rules for changing
(semi-privileged subsystem) virtual address spaces (avoiding have to
pass through kernel doing address space changes).

Besides use by semi-privileged subsystems for accessing application
parameter values ... they created "dataspaces" ... application in one
virtual address space ... and purely data in other address spaces.
misc.

past posts mentioning "access registers":
http://www.garlic.com/~lynn/98.html#36 What is MVS/ESA?
http://www.garlic.com/~lynn/2000d.html#28 RS/6000 vs. System/390 architecture?
http://www.garlic.com/~lynn/2001d.html#28 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001d.html#30 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001h.html#73 Most complex instructions
http://www.garlic.com/~lynn/2001k.html#16 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002g.html#5 Black magic in POWER5
http://www.garlic.com/~lynn/2002g.html#17 Black magic in POWER5
http://www.garlic.com/~lynn/2002l.html#57 Handling variable page sizes?
http://www.garlic.com/~lynn/2002n.html#74 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#43 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003d.html#53 Reviving Multics
http://www.garlic.com/~lynn/2003e.html#12 Resolved: There Are No Programs With >32 Bits of Text
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#53 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#53 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005c.html#63 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005f.html#7 new Enterprise Architecture online user group
http://www.garlic.com/~lynn/2005f.html#41 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#57 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005p.html#18 address space
http://www.garlic.com/~lynn/2005q.html#41 Instruction Set Enhancement Idea
http://www.garlic.com/~lynn/2005q.html#48 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006r.html#32 MIPS architecture question - Supervisor mode & who is using it?
http://www.garlic.com/~lynn/2006t.html#23 threads versus task
http://www.garlic.com/~lynn/2006y.html#39 Multiple mappings
http://www.garlic.com/~lynn/2007g.html#39 Wylbur and Paging
http://www.garlic.com/~lynn/2007k.html#27 user level TCP implementation
http://www.garlic.com/~lynn/2007l.html#71 IBM 360 Model 20 Questions
http://www.garlic.com/~lynn/2007q.html#68 Direction of Stack Growth
http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar'
http://www.garlic.com/~lynn/2007t.html#16 segmentation or lack thereof
http://www.garlic.com/~lynn/2007t.html#75 T3 Sues IBM To Break its Mainframe Monopoly
http://www.garlic.com/~lynn/2008c.html#35 New Opcodes
http://www.garlic.com/~lynn/2008d.html#69 Regarding the virtual machines
http://www.garlic.com/~lynn/2008e.html#14 Kernels
http://www.garlic.com/~lynn/2008e.html#33 IBM Preview of z/OS V1.10
http://www.garlic.com/~lynn/2008g.html#60 Different Implementations of VLIW
http://www.garlic.com/~lynn/2008o.html#53 Old XDS Sigma stuff
http://www.garlic.com/~lynn/2008o.html#73 Addressing Scheme with 64 vs 63 bits
http://www.garlic.com/~lynn/2008p.html#40 Opsystems
http://www.garlic.com/~lynn/2010g.html#83 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010h.html#2 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010h.html#3 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010h.html#8 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2011f.html#17 New job for mainframes: Cloud platform
http://www.garlic.com/~lynn/2011f.html#20 New job for mainframes: Cloud platform
http://www.garlic.com/~lynn/2011h.html#11 History of byte addressing
http://www.garlic.com/~lynn/2011l.html#45 segments and sharing, was 68000 assembly language programming
http://www.garlic.com/~lynn/2012b.html#66 M68k add to memory is not a mistake any more
http://www.garlic.com/~lynn/2012j.html#80 Slackware
http://www.garlic.com/~lynn/2012n.html#21 8-bit bytes and byte-addressed machines
http://www.garlic.com/~lynn/2013m.html#71 'Free Unix!': The world-changing proclamation made 30 years agotoday
http://www.garlic.com/~lynn/2014e.html#40 The mainframe turns 50, or, why the IBM System/360 launch was the dawn of enterprise IT
http://www.garlic.com/~lynn/2014f.html#22 Complete 360 and 370 systems found
http://www.garlic.com/~lynn/2014k.html#36 1950: Northrop's Digital Differential Analyzer
http://www.garlic.com/~lynn/2014k.html#82 Do we really need 64-bit DP or is 48-bit enough?
http://www.garlic.com/~lynn/2015b.html#60 ou sont les VAXen d'antan, was Variable-Length Instructions that aren't
http://www.garlic.com/~lynn/2015h.html#116 Is there a source for detailed, instruction-level performance info?
http://www.garlic.com/~lynn/2016b.html#35 Qbasic
http://www.garlic.com/~lynn/2016b.html#57 Introducing the New z13s: Tim's Hardware Highlights
http://www.garlic.com/~lynn/2016b.html#104 You count as an old-timer if (was Re: Origin of the phrase "XYZZY")
http://www.garlic.com/~lynn/2016e.html#3 S/360 stacks, was self-modifying code, Is it a lost cause?
http://www.garlic.com/~lynn/2017d.html#61 Paging subsystems in the era of bigass memory
http://www.garlic.com/~lynn/2017e.html#40 Mainframe Family tree and chronology 2
http://www.garlic.com/~lynn/2017e.html#94 Migration off Mainframe to other platform
http://www.garlic.com/~lynn/2017i.html#48 64 bit addressing into the future
http://www.garlic.com/~lynn/2017i.html#57 64 bit addressing into the future

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

In article <874ln6w...@garlic.com>,
Anne & Lynn Wheeler  <ly...@garlic.com> wrote:
>os/360 had convention of CVT at 16 ... moved first to 370 VS2/SVS
>... single virtual storage ... effectively MVT laid out in a single
>16mbyte virtual address space ... 

I read somewhere that someone put handshake code in OS/MFT so that if
it were running under VM\/370, when it page faulted CP would send a
virtual interrupts to MFT so it could switch tasks rather than
waiting.  This got the effect of VS1 but with a competent virtual
memory system, and the option to run other stuff under VM.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 1/27/2018 7:22 PM, Charlie Gibbs wrote:
> On 2018-01-28, Dan Espen <dan1...@gmail.com> wrote:
> 
>> John Levine <jo...@taugh.com> writes:
>>
>>> In article <b204534e-f56c-4b29...@googlegroups.com>,
>>>
>>>> Memory addressing was a big issue in the original concept of
>>>> System/360.  Small machines had simple addresses which saved
>>>> memory, big machines had more complex addresses.  Providing space
>>>> for a large address was wasteful in a small machine, most
>>>> S/360 users were getting small ones.  As a compromise, IBM came
>>>> up with the base+displacement method.
>>>
>>> All 360s other than the /20 used the same addressing, full 24 bit
>>> addresses, instructions used base register plus 12 bit displacement
>>> sometimes plus index register.  Base register 0 meant direct
>>> addressing with the 12 bit displacement, but as far as I know that was
>>> used only in little bits of startup and trap handler code, not in
>>> applications.
>>
>> MVS applications often get system information
>> by using an address at a fixed low storage location (CVT at 16).
> 
> It also lets you use Load Address to load a constant from 0 to
> 4095 inclusive into a register (although if you're setting the
> register to zero it's faster to subtract it from itself).
> 

How does that compare with the time for exclusive-oring the resister 
with itself???  On the Intel 8080, that was the fastest way to zero the 
accumulator...

-- 
numerist at aquaporin4 dot com

On 1/27/2018 7:13 PM, Quadibloc wrote:
> And the register to register version of the jump to subroutine instruction
> allows a program to find its own address, needed to start loading its
> base registers.
> 

Is this the "branch and link register" instruction (BALR)???

-- 
numerist at aquaporin4 dot com

John Levine <jo...@taugh.com> writes:
> I read somewhere that someone put handshake code in OS/MFT so that if
> it were running under VM\/370, when it page faulted CP would send a
> virtual interrupts to MFT so it could switch tasks rather than
> waiting.  This got the effect of VS1 but with a competent virtual
> memory system, and the option to run other stuff under VM.

re:
http://www.garlic.com/~lynn/2018.html#91 Honeywell 200
http://www.garlic.com/~lynn/2018.html#92 S/360 addressing, not Honeywell 200

from Melinda's VM History:

Dewayne Hendricks(109) reported at SHARE XLII, in March, 1974, that he
had successfully implemented MVT-CP handshaking for page faulting, so
that when MVT running under VM took a page fault, CP would allow MVT to
dispatch another task while CP brought in the page.  At the following
SHARE, Dewayne did a presentation on further modifications, including
support for SIOF and a memory-mapped job queue.  With these changes, his
system would allow multi-tasking guests actually to multi-task when
running in a virtual machine.  Significantly, his modifications were
available on the Waterloo Tape.

Dewayne became the chairman of the Operating Systems Committee of the
SHARE VM Project.  Under his guidance, the Committee prepared several
detailed requirements for improvements to allow guest systems to perform
better.  At SHARE XLV, in 1975, the Committee presented IBM with a White
Paper entitled Operating Systems Under VM/370,(110) which discussed the
performance problems of guests under VM and the solutions that customers
had found for these problems.  Many of the solutions that Dewayne and
others had found, such as PAGEX, made their way into VM fairly quickly,
apparently as the result of customers' persistence in documenting them.
By SHARE 49, Dewayne was able to state that, "It is now generally
understood that either MFT or MVT can run under VM/370 with relative
batch throughput greater than 1."(111) That is to say, they had both
been made to run significantly faster under VM than on the bare
hardware.  Dewayne and others did similar work to improve the
performance of DOS under VM.  Other customers, notably Woody Garnett and
John Alvord, soon achieved excellent results with VS1 under VM.

... snip ...

Endicott added VM/370 PAGEX & VS/1 Handshanking along with ECPS ...
http://www.garlic.com/~lynn/94.html#21 370 ECPS microcode assist

Endicott even tried to get corporate to agree to having VM/370 preinstalled on
every 138/148 shipped (sort of like LPAR does today) ... but this was in
period when POK was convincing corporate to kill VM/370 product and
transfer all people to POK to support MVS/XA development (or otherwise
MVS/XA wouldn't ship on time 7-8 yrs later). Eventually Endicott
managed to rescue the VM/370 product mission ... but had to recreate
a VM/370 development group from scratch.

Note VS1 under VM/370 could run faster than on stand alone machine.
Part of VS1 running faster under VM/370 was VS1 still used 370 2kbyte
pages (option used to better squeeze into small real storage machines)
... as hardware scaleup there was much larger real storage and the
trade-off of 2k versus 4k pages was overhead of 2k paging was greater
than any benefit for squeezing into small real storage. The other was my
page replacement algorithm in VM/370 was much more efficient than the
page replacement algorithm in VS/1. page replacement posts
http://www.garlic.com/~lynn/subtopic.html#wsclock

Part of MVT running faster under (originally CP/67 and then) VM/370 was
the same justification for all 370s moving to virtual memory ...
i.e. MVT very poor application storage management ... requiring regions
to be four times larger than actually used (extreme storage
fragmentation and needing lots of contiguous addressing) ... virtual
memory allowed to have much larger address space (than real storage),
being able to have four times the regions (concurrent applications and
larger multiprogramming level allowing more activity overlapped waiting
for I/O) ...  also referenced in upthread, previous post
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory

for other drift ... at SJR ... after they upgraded the 370/195 to
370/168 for MVS and 370/158 VM/370 ... all (physically) sharing common
DASD pool ... but there was rule that certain 3830/3330
controller/strings were dedicated to MVS and others dedicated to VM370
... and MVS 3330s were not allowed to be mounted on VM370 strings.  One
day MVS operations violated the rule and almost immediately datacenter
was getting irate VM370/CMS user calls about enormously degraded CMS
interactive response. The issue was MVS extensive use of multitrack
search to the (mis-)mounted 3330 was interferring with VM370 I/O.
MVS operations said they wouldn't move the mis-mounted 3330 until
2nd shift.

Woody's VS1 3330 was mounted on MVS string, running under (heavily
loaded) VM370 (158) and some applications started ... even under heavily
loaded VM370 158 ... the VS1 multi-track searches were able to bring MVS
168 to its knees ... significantly slowing down the MVS activity
intererring with VM370 throughput and alleviating the degraded CMS
iteractive response. MVS operations then immediately agreed to move the
offending MVS 3330 off VM370 string. recent ref/post (in ibm-main
mailing list)
http://www.garlic.com/~lynn/2018.html#46 VSE timeline [was: RE: VSAM usage for ancient disk models]

CKD, FBA, multi-track search, etc posts
http://www.garlic.com/~lynn/submain.html#dasd

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

On 28/01/2018 18:29, Charles Richmond wrote:
> On 1/27/2018 7:22 PM, Charlie Gibbs wrote:
>> On 2018-01-28, Dan Espen <dan1...@gmail.com> wrote:
>>
>>> John Levine <jo...@taugh.com> writes:
>>>
>>>> In article <b204534e-f56c-4b29...@googlegroups.com>,
>>>>
>>>>> Memory addressing was a big issue in the original concept of
>>>>> System/360.  Small machines had simple addresses which saved
>>>>> memory, big machines had more complex addresses.  Providing space
>>>>> for a large address was wasteful in a small machine, most
>>>>> S/360 users were getting small ones.  As a compromise, IBM came
>>>>> up with the base+displacement method.
>>>>
>>>> All 360s other than the /20 used the same addressing, full 24 bit
>>>> addresses, instructions used base register plus 12 bit displacement
>>>> sometimes plus index register.  Base register 0 meant direct
>>>> addressing with the 12 bit displacement, but as far as I know that was
>>>> used only in little bits of startup and trap handler code, not in
>>>> applications.
>>>
>>> MVS applications often get system information
>>> by using an address at a fixed low storage location (CVT at 16).
>>
>> It also lets you use Load Address to load a constant from 0 to
>> 4095 inclusive into a register (although if you're setting the
>> register to zero it's faster to subtract it from itself).
>>
> 
> How does that compare with the time for exclusive-oring the resister 
> with itself???  On the Intel 8080, that was the fastest way to zero the 
> accumulator...
> 
Both exclusive or and subtraction probably take the same amount of time.

In article <p4l4so$17i$2...@dont-email.me>,
Charles Richmond  <nume...@aquaporin4.com> wrote:
>On 1/27/2018 7:13 PM, Quadibloc wrote:
>> And the register to register version of the jump to subroutine instruction
>> allows a program to find its own address, needed to start loading its
>> base registers.
>
>Is this the "branch and link register" instruction (BALR)???

Yes, except on machines with shorter (360/20) and longer (360/67, and most recent
machines) addresses where you use BASR instead.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

In article <11a679ce-bee2-4d48...@googlegroups.com>,
Quadibloc  <jsa...@ecn.ab.ca> wrote:
>And the register to register version of the jump to subroutine instruction 
>allows a program to find its own address, needed to start loading its 
>base registers.

The standard calling sequence put the address of the routine in r15 so
in most cases it was as easy to use that.


-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

In article <p4l4pn$17i$1...@dont-email.me>,
Charles Richmond  <nume...@aquaporin4.com> wrote:
>> It also lets you use Load Address to load a constant from 0 to
>> 4095 inclusive into a register (although if you're setting the
>> register to zero it's faster to subtract it from itself).
>
>How does that compare with the time for exclusive-oring the resister 
>with itself???  On the Intel 8080, that was the fastest way to zero the 
>accumulator...

It varied by model.  SR wasn't always faster than LA.

	LA R,0	SR R,R	XR R,R

360/30	17	22	23
360/67	0.9	0.65	1.25
360/85	0.16	0.08	0.08

(times in microseconds, /30 may be less since there's no base register
addition)


-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <jo...@taugh.com> writes:
> The standard calling sequence put the address of the routine in r15 so
> in most cases it was as easy to use that.

re:
http://www.garlic.com/~lynn/2018.html#91 Honeywell 200
http://www.garlic.com/~lynn/2018.html#92 S/360 addressing, not Honeywell 200
http://www.garlic.com/~lynn/2018.html#93 S/360 addressing, not Honeywell 200

I did Q&D HTML of the internal gcard ios3270 ... this shows
call/save/return os/360 convention.
http://www.garlic.com/~lynn/gcard.html#50

addressing convention can be to use either the entry R15 register value
... or do BALR Rx,0. BALR routine calling branches to the address in the
2nd register while saving the "return" address in the 1st register. If
the 2nd register is zero ... it doesn't actually do a branch ... just
saves the current address in the 1st register.

One of the things is that lots of application library routines that were
called using the BALR conventions ... could be moved into a different
address space and use "access register" and (hardware) program
call/return instructions to do all the address space swizzling.

address types
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/3.2.1?SHELF=&DT=20040504121320&CASE=

3.2.1.1 Absolute Address
3.2.1.2 Real Address
3.2.1.3 Virtual Address
3.2.1.4 Primary Virtual Address
3.2.1.5 Secondary Virtual Address
3.2.1.6 AR-Specified Virtual Address
3.2.1.7 Home Virtual Address
3.2.1.8 Logical Address
3.2.1.9 Instruction Address
3.2.1.10 Effective Address 

program call (sort of supervisor call, but also swizzles the address
space pointers in hardware
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/10.34?DT=20040504121320
and program return
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/10.35?DT=20040504121320

program call/return sort of push/pop call stack.

they then did TRANSFER ... w/o pushing to the call stack
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/10.36?DT=20040504121320
and
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/10.37?DT=20040504121320

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

John Levine <jo...@taugh.com> wrote:
> In article <874ln6w...@garlic.com>,
> Anne & Lynn Wheeler  <ly...@garlic.com> wrote:
>> os/360 had convention of CVT at 16 ... moved first to 370 VS2/SVS
>> ... single virtual storage ... effectively MVT laid out in a single
>> 16mbyte virtual address space ... 
> 
> I read somewhere that someone put handshake code in OS/MFT so that if
> it were running under VM\/370, when it page faulted CP would send a
> virtual interrupts to MFT so it could switch tasks rather than
> waiting.  This got the effect of VS1 but with a competent virtual
> memory system, and the option to run other stuff under VM.
> 

VS1 and DOS, but not VS2/MVS.

-- 
Pete

Peter Flass <peter...@yahoo.com> writes:
> VS1 and DOS, but not VS2/MVS.

re:
http://www.garlic.com/~lynn/2018.html#91 Honeywell 200
http://www.garlic.com/~lynn/2018.html#92 S/360 addressing, not Honeywell 200
http://www.garlic.com/~lynn/2018.html#93 S/360 addressing, not Honeywell 200
http://www.garlic.com/~lynn/2018.html#96 S/360 addressing, not Honeywell 200

POK (favorite son operating system VS2) was the organization that had
convinced corporate to kill vm370 and move the vm370 development group
to POK to support MVS/XA development (justification was otherwise they
wouldn't be able to meet MVS/XA delivery schedule much later in the
80s).

Endicott eventually managed to acquire the VM370 development mission,
but had to recreate a development group fram scratch.

POK eventually managed to provide XA/370 SIE instruction which would
handle a lot more privileged instructions directly in hardware
... reducing the VM370 virtual machine software simulation overhead.
Then POK was somewhat forced to eventually come out with PR/SM virtual
machine subset directly in the hardware for the 3090 (to compete with
Amdahl's hypervisor)
https://en.wikipedia.org/wiki/PR/SM
 ... and then eventually LPAR
https://en.wikipedia.org/wiki/Logical_partition

Amdahl Corporation's Multiple Domain Facility (MDF) was introduced in
1982.[4] IBM began marketing its functionally similar PR/SM in 1988,
implemented on its ESA/390 architecture released that year. MDF-based
LPAR technology continued to be developed separately by Amdahl, and
Hitachi Data Systems in part for their implementations of the new
architecture, which featured the introduction of access registers that
allowed use of multiple data spaces addressable by a single address
space. IBM subsequently continued its LPAR development with its 64-bit
System z and System i architectures. LPAR and PR/SM reconfigurations can
be made without rebooting the computer, i.e., while some LPARs remain
active. Reconfigurations can include changing channel path definitions
and device definitions.

... snip ...


z Systems Processor Resource/Systems Manager Planning Guide
http://www-01.ibm.com/support/docview.wss?uid=isg22dec9fb95bdff17385257dc4007a164f

seems little or no new web-based versions ... everything seems to
becoming PDF download.

some old email mentioning XA, SIE &/or 3090... original SIE on (POK)
3081/XA ... was assumed to only be testing ... so SIE microcode had
to be constantly swapped in for execution (adversely affecting
throughput). (POK) 3090 finally started to assume that virtual machine
operation might actually be part of production environment
http://www.garlic.com/~lynn/2011b.html#email810210
http://www.garlic.com/~lynn/2006j.html#email810630
http://www.garlic.com/~lynn/2007d.html#email820916
http://www.garlic.com/~lynn/2011b.html#email820917
http://www.garlic.com/~lynn/2003j.html#email831118

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

Charles Richmond <nume...@aquaporin4.com> writes:
>On 1/27/2018 7:22 PM, Charlie Gibbs wrote:
>> On 2018-01-28, Dan Espen <dan1...@gmail.com> wrote:
>> 
>>> John Levine <jo...@taugh.com> writes:
>>>
>>>> In article <b204534e-f56c-4b29...@googlegroups.com>,
>>>>
>>>>> Memory addressing was a big issue in the original concept of
>>>>> System/360.  Small machines had simple addresses which saved
>>>>> memory, big machines had more complex addresses.  Providing space
>>>>> for a large address was wasteful in a small machine, most
>>>>> S/360 users were getting small ones.  As a compromise, IBM came
>>>>> up with the base+displacement method.
>>>>
>>>> All 360s other than the /20 used the same addressing, full 24 bit
>>>> addresses, instructions used base register plus 12 bit displacement
>>>> sometimes plus index register.  Base register 0 meant direct
>>>> addressing with the 12 bit displacement, but as far as I know that was
>>>> used only in little bits of startup and trap handler code, not in
>>>> applications.
>>>
>>> MVS applications often get system information
>>> by using an address at a fixed low storage location (CVT at 16).
>> 
>> It also lets you use Load Address to load a constant from 0 to
>> 4095 inclusive into a register (although if you're setting the
>> register to zero it's faster to subtract it from itself).
>> 
>
>How does that compare with the time for exclusive-oring the resister 
>with itself???  On the Intel 8080, that was the fastest way to zero the 
>accumulator...

That doesn't necessarily mean that the 8080 (and successors through Haswell)
actually do the xor.   Simply recognizing that the two registers are identical
would be sufficient to drive the result to zero.

On Saturday, January 27, 2018 at 6:02:52 PM UTC-5, John Levine wrote:

[snip]

> From my recollection of the discussion of the 360 design in the 1964
> IBM System Journal, they correctly observed that this would make code
> smaller than direct or indirect addressing.  But they also claimed it
> would make programs position independent, which was rather
> overoptimistic.  It's true, the code itself is position independent if
> you follow some common conventions, but real programs all have
> pointers stored in memory, which have to be relocated if the program
> moves.

IIRC my S/360-DOS days, our application programs were called
"relocatable".  That meant, at execution time, they could be loaded
anyway in the machine (but then, stayed static at that location for
the duration of the job).   

When we got dumps, we had to had the physical load address to
the error location to get the actual location in the dump.

Later on, the product Abend-Aid did all that automatically, plus
provide additional information quickly speeding dump resolution.

On Saturday, January 27, 2018 at 7:37:00 PM UTC-5, Dan Espen wrote:

> MVS applications often get system information
> by using an address at a fixed low storage location (CVT at 16).

I thought SYNCSORT's run control log was neat since it provided
a variety of system information, such as Job and Step name.
I felt this would be useful to include in run control totals for
application programs.  A colleague wrote an assembler routine to
access that information (easy to do.)

COBOL did provide the compilation date/time and execution date/time
and this were very useful to display on the run control log.  They
helped ensure the correct version of the program was being run,
and the correct run was being reviewed.

In article <2e84c3ac-e42b-402f...@googlegroups.com>,
 <hanc...@bbs.cpcn.com> wrote:
>> overoptimistic.  It's true, the code itself is position independent if
>> you follow some common conventions, but real programs all have
>> pointers stored in memory, which have to be relocated if the program
>> moves.
>
>IIRC my S/360-DOS days, our application programs were called
>"relocatable".  That meant, at execution time, they could be loaded
>anyway in the machine (but then, stayed static at that location for
>the duration of the job).   

Yup, there were (still as as far as I know on z/VSE) RLD records in
load modules that told the program fetcher what to relocate as it was
loading the program.  OS used (uses) the same object formats.  Read
all about it in my book.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 2018-01-29, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:

> On Saturday, January 27, 2018 at 7:37:00 PM UTC-5, Dan Espen wrote:
>
>> MVS applications often get system information
>> by using an address at a fixed low storage location (CVT at 16).
>
> I thought SYNCSORT's run control log was neat since it provided
> a variety of system information, such as Job and Step name.
> I felt this would be useful to include in run control totals for
> application programs.  A colleague wrote an assembler routine to
> access that information (easy to do.)

I wrote a little assembly-language subroutine that would change our
equivalent of a DDNAME in a COBOL program, so the payroll program
could print different cheque forms for several dozen clients in a
single run without having to define a different printer file for
each one.  (We still needed a line of JCL for each form, but that
wasn't nearly as much of a hassle.)

> COBOL did provide the compilation date/time and execution date/time
> and this were very useful to display on the run control log.  They
> helped ensure the correct version of the program was being run,
> and the correct run was being reviewed.

I've been a date stamp fanatic for a long time.  Part of the reason
is that I got tired of tracking down bugs I had already fixed, when
the customer failed to update the program.

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

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

> On 2018-01-29, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:
>
>> On Saturday, January 27, 2018 at 7:37:00 PM UTC-5, Dan Espen wrote:
>>
>>> MVS applications often get system information
>>> by using an address at a fixed low storage location (CVT at 16).
>>
>> I thought SYNCSORT's run control log was neat since it provided
>> a variety of system information, such as Job and Step name.
>> I felt this would be useful to include in run control totals for
>> application programs.  A colleague wrote an assembler routine to
>> access that information (easy to do.)
>
> I wrote a little assembly-language subroutine that would change our
> equivalent of a DDNAME in a COBOL program, so the payroll program
> could print different cheque forms for several dozen clients in a
> single run without having to define a different printer file for
> each one.  (We still needed a line of JCL for each form, but that
> wasn't nearly as much of a hassle.)

I had a similar requirement for a COBOL program on a S/34.
Instead of calling an Assembler program I simply searched memory
downward by byte until I found a match on the DDNAME then changed it.

(My first guess (downward) was just a half educated lucky guess.)


-- 
Dan Espen

Dan Espen <dan1...@gmail.com> wrote:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> 
>> On 2018-01-29, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:
>> 
>>> On Saturday, January 27, 2018 at 7:37:00 PM UTC-5, Dan Espen wrote:
>>> 
>>>> MVS applications often get system information
>>>> by using an address at a fixed low storage location (CVT at 16).
>>> 
>>> I thought SYNCSORT's run control log was neat since it provided
>>> a variety of system information, such as Job and Step name.
>>> I felt this would be useful to include in run control totals for
>>> application programs.  A colleague wrote an assembler routine to
>>> access that information (easy to do.)
>> 
>> I wrote a little assembly-language subroutine that would change our
>> equivalent of a DDNAME in a COBOL program, so the payroll program
>> could print different cheque forms for several dozen clients in a
>> single run without having to define a different printer file for
>> each one.  (We still needed a line of JCL for each form, but that
>> wasn't nearly as much of a hassle.)

The old JFCB twizzle. I also used this to change the PDS member name so I
could read a number of members as sequential files. I had a program that
read the directory and then dumped all the members.

> 
> I had a similar requirement for a COBOL program on a S/34.
> Instead of calling an Assembler program I simply searched memory
> downward by byte until I found a match on the DDNAME then changed it.
> 
> (My first guess (downward) was just a half educated lucky guess.)
> 
> 


-- 
Pete

hanc...@bbs.cpcn.com wrote:


> 
> IIRC my S/360-DOS days, our application programs were called
> "relocatable".  That meant, at execution time, they could be loaded
> anyway in the machine (but then, stayed static at that location for
> the duration of the job).
> 
Yes, that was one of the features of the 360 instruction set.  The base 
register was set by the initiator/terminator just before passing control to 
the program.  Object decks were relocatable before they started, but then 
various instructions stored physical addresses, so the program was no longer 
able to be relocated.

Jon

On 29/01/2018 15:14, Scott Lurndal wrote:
> Charles Richmond <nume...@aquaporin4.com> writes:
{snip}

>> How does that compare with the time for exclusive-oring the resister
>> with itself???  On the Intel 8080, that was the fastest way to zero the
>> accumulator...
> 
> That doesn't necessarily mean that the 8080 (and successors through Haswell)
> actually do the xor.   Simply recognizing that the two registers are identical
> would be sufficient to drive the result to zero.
> 

The 8080 was so simple that it would have performed the xor. That sort 
of optimisations would have need chips with many more gates. An xor only 
takes a single clock cycle anyway.

On Mon, 29 Jan 2018 13:08:07 -0800 (PST), hanc...@bbs.cpcn.com wrote:

>On Saturday, January 27, 2018 at 6:02:52 PM UTC-5, John Levine wrote:
>
>[snip]
>
>> From my recollection of the discussion of the 360 design in the 1964
>> IBM System Journal, they correctly observed that this would make code
>> smaller than direct or indirect addressing.  But they also claimed it
>> would make programs position independent, which was rather
>> overoptimistic.  It's true, the code itself is position independent if
>> you follow some common conventions, but real programs all have
>> pointers stored in memory, which have to be relocated if the program
>> moves.
>
>IIRC my S/360-DOS days, our application programs were called
>"relocatable".  That meant, at execution time, they could be loaded
>anyway in the machine (but then, stayed static at that location for
>the duration of the job).   
>
>When we got dumps, we had to had the physical load address to
>the error location to get the actual location in the dump.
>
>Later on, the product Abend-Aid did all that automatically, plus
>provide additional information quickly speeding dump resolution.

Just a note, but Abend-Aid is third party.  And now you can use it
from the Eclipse IDE running on a PC.
>

hanc...@bbs.cpcn.com writes:
> Later on, the product Abend-Aid did all that automatically, plus
> provide additional information quickly speeding dump resolution.

I had wanted to show that REXX (before customer release, originally
just REX, early 80s) wasn't just another pretty scripting language ...
I decided on demo'ing that I could redo IPCS (very large assembler
application) in less than 3months elapsed time working half time with
ten times the function and running ten times faster (some slight of
hand for REXX to run faster than assembler).

I finished early so started doing library of automated scripts that
searched/analyzed for lots of different kind of failure signatures. I
had expected that it would be released to customers ... but for some
reason it wasn't, even tho it became standard for internal datacenters
and customer support PSRs. Some old email from the 3092 (3090 service
processor) group wanting to include it
http://www.garlic.com/~lynn/2010e.html#email861031
http://www.garlic.com/~lynn/2010e.html#email861223

Eventually I got approval for making presentations at SHARE and other
customer user group meetings on how I implemented it .. and within a few
months similar implementations started to appear.

As an aside the implementation included functions like formating
storage segments using maclib DSECTs and decompiling instruction
sequences ... and this was in the "OCO-wars" (object code only)
... transition to no longer shipping source code. past posts
http://www.garlic.com/~lynn/submain.html#dumprx

other trivia: this is old "greencard" done in IOS3270 with q&d
conversion to html (the 3092 service processor screens were done
in IOS3270)
http://www.garlic.com/~lynn/gcard.html