Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Anne & Lynn Wheeler <lynn@garlic.com>
Newsgroups: alt.folklore.computers,comp.sys.raspberry-pi
Subject: Re: S/360 stacks, was self-modifying code, Is it a lost cause?
Date: Tue, 05 Jul 2016 15:38:23 -0700
Organization: Wheeler&Wheeler
Lines: 62
Message-ID: <87vb0jsobk.fsf@garlic.com>
References: <njmu8u$3i6$1@dont-email.me> <nlf0ho$npt$1@dont-email.me> <nlf722$1gom$1@miucha.iecc.com> <nlfpb7$58u$1@news.albasani.net> <nlh839$2ruj$4@miucha.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="6a701f7a2f120c3c3ec794af16136f6c"; logging-data="26023"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18YcnTmSX8qic9Ulk3COQe2Lkqbosr1WkQ="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.94 (gnu/linux)
Cancel-Lock: sha1:Q4YsV3317/0jM5fUGhiF4N1R6HU= sha1:I+5a6uGuNnBpR+wrPyUlNj76zeY=
Xref: csiph.com alt.folklore.computers:166720 comp.sys.raspberry-pi:12562

John Levine <johnl@iecc.com> writes:
> It has a linkage stack, used by some specialized call and return
> instructions.  The linkage stack is complex enough that I never
> figured out all the details, but it was largely to enable programs to
> span multiple 31-bit address spaces back on the 32 bit systems.
>
> Z has it because it has nearly everything its predecessors did, but
> with the address space limits gone, the motivation for the linkage
> stack is now just backward compatibility.

migration from real memory os/360 to MVS involved giving each
task/applications outside the kernel its own 16mbyte virtual address
space. However, os/360 is extremely pointer passing intensive paradigm
so they included an 8mbyte kernel image in every 16mbyte virtual address
space (so kernel calls could easily continue with pointer passing
... and kernel code simply address parameters&returns like it always
had).

Problem was that a lot of subsystems (outside the kernel) also got their
own 16mbyte virtual address spaces ... and also required pointer passing
API. This required creating a "COMMON SEGMENT", 1mbyte area mapped into
every 16mbyte application virtual address space ... where global space
was allocated for parameter & return passing between applications and
subsystems (running in their own address space). However, the amount of
common space was somewhat proportional to system size, number of
concurrent applications and concurrent subsystems. In late 370 days
... before 31bit and 370-xa, on large systems, the common areas were
threatening to grow to 8mbytes ... leaving nothing for applications
(8mbyte kernel image plust 8mbyte common area out of 16mbyte virtual
address space left nothing for applications).

For 370/xa both "access registers" and program call/return were defined
for subsystems. Early simple implementation, application made a kernel
call to transfer to subsystem. Kernel would load application address
space pointer into secondary address space (access) register, load the
subsystem virtual address space into primary virtual/home address space
register and invoke the subsystem (passing the calling routines
registers). Subsystems could use special instructions to retrieve/store
data in the calling application virtual address space. Program
call/return would reference a hardware defined table that had pointer
for every valid subsystem and its virtual address space pointer. An
application could call a subsystem, where the program call did the
address space pointer changes all in hardware (w/o requiring a kernel
call). Similarly a subsystem could make a program return ... which
reverse the virtual address space pointer changes .... back to the
calling application virtual address space.

Applications could now efficiently call a routine that exists in
different address space ... which had authorization to fetch/store the
calling application virtual address space (w/o requiring pathlength
through the kernel).

There has since been some use of access registers for use to define
"dataspaces" ... effectively a virtual address space that was all data
... with application using "access registers" to access the data in
different virtual address space. However, the original purpose of access
registers was for a subsystem in its own address space to access passed
parameters in the calling application address space (and store return
values).

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