From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3765 invoked from network); 28 Jun 2021 11:28:18 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 28 Jun 2021 11:28:18 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 7D43F9CA68; Mon, 28 Jun 2021 21:28:16 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id CDA9D9CA5F; Mon, 28 Jun 2021 21:27:28 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 2F9D99CA5F; Mon, 28 Jun 2021 21:27:24 +1000 (AEST) Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by minnie.tuhs.org (Postfix) with ESMTPS id 0BE889CA3B for ; Mon, 28 Jun 2021 21:27:23 +1000 (AEST) Received: by mail-pj1-f51.google.com with SMTP id kt19so1975824pjb.2 for ; Mon, 28 Jun 2021 04:27:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kj585TsziEBq56CUzrqFTy8WN0RrLis2aLQhRcKwxio=; b=nx4N5B7teGJOlF0mJdCzB8R98YQqa3jZFwqE/RfKEZ1KXRcZ5FV30TQgkxEBzxjz3+ GBIv/eC/7kg4RttGPuuARguUcH+z61K/z4K2e6lEecJISwGpbW3P8d/Lc2ZFBT46macz L51O59jSJ9OYUjnAW0GxWxDwL8XwrJpVV4XpBe0Eain7uaWr9M+suPAhnA2An4doSzv3 r5qELq6pJgTbJeDj8xhcSy2SPAjQDjhCyZMVVHegVUKHIfH07mPxZR4hQmPReUxKQAeT Do9zD9iXZGbIBfO3S5RWRYtPESI9l1PRaQ8C+f0zRJeFuEJ4MGNhfQXZMUFjt18XxOMz DuNQ== X-Gm-Message-State: AOAM530Nz+TO9JOjAHr3xvcK7k+LgcMeGqrrqL4suWYZSifMHSUspSZ3 tynoiLwETHpUCZV6G1fYTSz97XPxOaFaZtpsGorC4bEfB1o= X-Google-Smtp-Source: ABdhPJycBswVc6fVysroa8hEDt/aYaXiBKvtF8b9mDRXnVd/60++uPkrjzqLObStXl/Ewo06qLHpoWWQDMaklZZtHQM= X-Received: by 2002:a17:902:b588:b029:11d:b246:c59a with SMTP id a8-20020a170902b588b029011db246c59amr22300450pls.58.1624879642121; Mon, 28 Jun 2021 04:27:22 -0700 (PDT) MIME-Version: 1.0 References: <20210628044852.2B53B18C08F@mercury.lcs.mit.edu> In-Reply-To: <20210628044852.2B53B18C08F@mercury.lcs.mit.edu> From: Paul Riley Date: Mon, 28 Jun 2021 21:27:08 +1000 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary="000000000000df1b5405c5d1c5d3" Subject: Re: [TUHS] Using printf from Assembly Language in V6, and db. X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000df1b5405c5d1c5d3 Content-Type: text/plain; charset="UTF-8" Noel, Thanks for that. As a non-C consumer of printf, should I point R5 at some space for a stack and call printf in the same manner as the C example I cited? If it's all too hard I'll stick to writing to stdout with my own routines. Paul *Paul Riley* Email: paul@rileyriot.com On Mon, 28 Jun 2021 at 14:49, Noel Chiappa wrote: > > From: Paul Riley > > > I want to use printf from an assembly language program, in V6. ... > the > > substitutional arguments for printf are pushed onto the stack in > reverse > > order, then the address of the string, and then printf is called. > After > > this, 6 is added to the stack pointer. > > This is all down to the standard C environment / calling sequence on the > PDP-11 (at least, in V6 C; other compilers may do it differently). Calls to > printf() are in no way special. > > Very briefly, there's a 'frame pointer' (R5) which points to the current > stack > frame; all arguments and automatics are relative to that. A pair of special > routines, csv and cret (I couldn't find the source on TUHS, but it happens > to > be here: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/lib/csv.s > > if you want to see it), set up and tear down the frame on entry/exit to > that > routine. The SP (R6) points to a blank location on the top (i.e. lower > address; > PDP-11 stacks grow down) of the stack. > > To call a subroutine, the arguments are pushed, the routine is called > (which > pushes the return PC), and on return (which pops the return PC), the > arguments > are discarded by the caller. > > (I wrote a note, BITD, explaining how all this worked; I'll upload it to > the > CHWiki when I get a chance.) > > > > I assume that the printf routine pops the address of the string off > the > > stack, but leaves the other values on the stack > > No, all C routines (including printf()) leave the stack more or less alone, > except for CSV/CRET hackery, allocating space for automatic variables on > routine entry (that would be at L1; try looking at the .s for a routine > with > automatic variables), and popping the return PC on exit. The exception to > this > is the stuff around calling _enother_ routine (sketched above). > > Another exception is alloca() (source here: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/lib/alloca.s > > again, couldn't find it in TUHS), which allocated a block of memory on > the stack (automatically discarded when the routine which called alloca() > returns). Note that since all automatic variables and incoming arguments > are relative to the FP, alloca is _really_ simple; justs adjusts the > SP, and it's done. > > > What troubles me is that the stack pointer is not decremented before > the > > first mov, in the example below. Is this some C convention? I would > > assume that the first push in my example would overwrite the top of > the > > stack. > > That's right; that's because in the C runtime environment, the top location > on the stack is a trash word (set up by csv). > > > I understand db only works on files like a.out or core dumps. If I > > wanted to break the assembly language program to examine values, how > can > > I force a termination and core dump elegantly, so I can examine some > > register values? > > Use 'cdb': > > https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/man/man1/cdb.1 > > which can do interactive debugging. > > Noel > --000000000000df1b5405c5d1c5d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Noel,

Thanks for that.

As a non-C consumer of printf, should I point R5 at some space for= a stack and call printf in the same manner as the C example I cited? If it= 's all too hard I'll stick=C2=A0to writing to stdout with my own ro= utines.

Paul

<= div dir=3D"ltr">
Paul Riley



<= /div>


On Mon, 28 Jun 2021 at 14:49, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:<= br>
=C2=A0 =C2=A0 &g= t; From: Paul Riley

=C2=A0 =C2=A0 > I want to use printf from an assembly language program, = in V6. ...=C2=A0 the
=C2=A0 =C2=A0 > substitutional arguments for printf are pushed onto the = stack in reverse
=C2=A0 =C2=A0 > order, then the address of the string, and then printf i= s called. After
=C2=A0 =C2=A0 > this, 6 is added to the stack pointer.

This is all down to the standard C environment / calling sequence on the PDP-11 (at least, in V6 C; other compilers may do it differently). Calls to=
printf() are in no way special.

Very briefly, there's a 'frame pointer' (R5) which points to th= e current stack
frame; all arguments and automatics are relative to that. A pair of special=
routines, csv and cret (I couldn't find the source on TUHS, but it happ= ens to
be here:

=C2=A0 http://ana-3.lcs.mit.edu/~jnc/tech/unix/lib/= csv.s

if you want to see it), set up and tear down the frame on entry/exit to tha= t
routine. The SP (R6) points to a blank location on the top (i.e. lower addr= ess;
PDP-11 stacks grow down) of the stack.

To call a subroutine, the arguments are pushed, the routine is called (whic= h
pushes the return PC), and on return (which pops the return PC), the argume= nts
are discarded by the caller.

(I wrote a note, BITD, explaining how all this worked; I'll upload it t= o the
CHWiki when I get a chance.)


=C2=A0 =C2=A0 > I assume that the printf routine pops the address of the= string off the
=C2=A0 =C2=A0 > stack, but leaves the other values on the stack

No, all C routines (including printf()) leave the stack more or less alone,=
except for CSV/CRET hackery, allocating space for automatic variables on routine entry (that would be at L1; try looking at the .s for a routine wit= h
automatic variables), and popping the return PC on exit. The exception to t= his
is the stuff around calling _enother_ routine (sketched above).

Another exception is alloca() (source here:

=C2=A0 http://ana-3.lcs.mit.edu/~jnc/tech/unix/l= ib/alloca.s

again, couldn't find it in TUHS), which allocated a block of memory on<= br> the stack (automatically discarded when the routine which called alloca() returns). Note that since all automatic variables and incoming arguments are relative to the FP, alloca is _really_ simple; justs adjusts the
SP, and it's done.

=C2=A0 =C2=A0 > What troubles me is that the stack pointer is not decrem= ented before the
=C2=A0 =C2=A0 > first mov, in the example below. Is this some C conventi= on? I would
=C2=A0 =C2=A0 > assume that the first push in my example would overwrite= the top of the
=C2=A0 =C2=A0 > stack.

That's right; that's because in the C runtime environment, the top = location
on the stack is a trash word (set up by csv).

=C2=A0 =C2=A0 > I understand db only works on files like a.out or core d= umps. If I
=C2=A0 =C2=A0 > wanted to break the assembly language program to examine= values, how can
=C2=A0 =C2=A0 > I force a termination and core dump elegantly, so I can = examine some
=C2=A0 =C2=A0 > register values?

Use 'cdb':

=C2=A0 https://minnie.tuhs.org= //cgi-bin/utree.pl?file=3DV6/usr/man/man1/cdb.1

which can do interactive debugging.

=C2=A0 =C2=A0 =C2=A0 Noel
--000000000000df1b5405c5d1c5d3--