Computer Old Farts Forum
 help / color / mirror / Atom feed
From: clemc at ccc.com (Clem Cole)
Subject: [COFF] [TUHS] Unix quix
Date: Thu, 23 Jan 2020 09:08:24 -0500	[thread overview]
Message-ID: <CAC20D2OiPLpUQkezbG_JS-Jr20VCzM9ZgBsHAMBe-LYi4wMk6w@mail.gmail.com> (raw)
In-Reply-To: <20200123052702.GA83898@server.rulingia.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3888 bytes --]

FWIW: System 360 uses what was called the 'push down save area' as part of
the function calling convention.  Each routine declared and creates local
storage for the registers.   Being reentrant was certainly possible and
many languages such as the Algol and APL families were.   It's funny since
S/360 was the first architecture I knew deeply (*i.e.* got paid to
program), and working on support for York/APL at the time (and began
learning the Univac 1100 too), I just thought this was natural until I
began to learn about other processors ISA's like the PDP-11 family that had
an SP.

I remember, thinking -- this is so cool.

But as you said, originally early Fortran and Cobol didn't require same.
The typical calling conventions was something like this was pretty standard
for the S/360:

WORKAREA  DSECT ,                    Reentrant work area (stack like function)
          DS    18F                  Save area
FIELD1    DS    F                    Some variable
FIELD2    DS    F                    Another variable
WORKLEN   EQU   *-WORKAREA           Length of reentrant work area

SUBRTN1   RSECT ,                    HLASM will perform reentrant checking
          STM   R14,R12,12(R13)      Save registers at entry
          LR    R12,R15              Set code base register
          USING SUBRTN1,R12          Establish code addressability
          LGHI  R0,WORKLEN           Get length of reentrant work area
          STORAGE OBTAIN,            Obtain reentrant work area
          X
                LENGTH=(0)           ..Length is in R0
          ST    R1,8(,R13)           Forward chain in prev save area
          ST    R13,4(,R1)           Backward chain in next save area
          L     R14,20(,R13)         Get R1 at entry (parameters)
          LR    R13,R1               Set up new save area/reentrant workarea
          USING WORKAREA,R13         Establish work area addressability
          LM    R2,R3,0(R14)         Get addresses of parameters
          STM   R2,R3,FIELD1         Save parameter addresses for later
…
***    Subroutine Logic goes here
…
          LR    R1,R13               Address to be released
          L     R13,4(,R13)          Address of prior save area
          LGHI  R0,WORKLEN           Length of storage to release
          STORAGE RELEASE,           Release reentrant work area
          X
                ADDRESS=(1),         ..Address in R1
          X
                LENGTH=(0)           ..Length in R0
          LM    R14,R12,12(R13)      Restore registers
          OI    15(R13),X'01'        This bit on means this save area
is inactive
          BR    R14                  Return to caller



On Thu, Jan 23, 2020 at 12:47 AM Peter Jeremy <peter at rulingia.com> wrote:

> => coff since it's non-Unix
>
> On 2020-Jan-22 13:42:44 -0500, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
> >Pretty interesting machine, if you study its instruction set, BTW; with no
> >stack, subroutines are 'interesting'.
>
> "no stack" was fairly standard amongst early computers.  Note the the IBM
> S/360 doesn't have a stack..
>
> The usual approach to subroutines was to use some boilerplate as part of
> the
> "call" or function prologue that stashed a return address in a known
> location (storing it in the word before the function entry or patching the
> "return" branch were common aproaches).  Of course this made recursion
> "hard" (re-entrancy typically wasn't an issue) and Fortran and Cobol (at
> least of that vintage) normally don't support recursion for that reason.
>
> --
> Peter Jeremy
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200123/24bc73a9/attachment.html>


  reply	other threads:[~2020-01-23 14:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
2020-01-23  5:27 ` peter
2020-01-23 14:08   ` clemc [this message]
2020-01-23 14:31     ` clemc
2020-01-23 15:51       ` doug
2020-01-25  0:09         ` bakul
2020-01-24  1:18   ` krewat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC20D2OiPLpUQkezbG_JS-Jr20VCzM9ZgBsHAMBe-LYi4wMk6w@mail.gmail.com \
    --to=coff@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).