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.
On Mon, 28 Jun 2021 at 14:49, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
I want to use printf from an assembly language
program, in V6. ...
substitutional arguments for printf are pushed
onto the stack in
order, then the address of the string, and then
printf is called.
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
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
if you want to see it), set up and tear down the frame on entry/exit to
routine. The SP (R6) points to a blank location on the top (i.e. lower
PDP-11 stacks grow down) of the stack.
To call a subroutine, the arguments are pushed, the routine is called
pushes the return PC), and on return (which pops the return PC), the
are discarded by the caller.
(I wrote a note, BITD, explaining how all this worked; I'll upload it to
CHWiki when I get a chance.)
I assume that the printf routine pops the address
of the string off
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
automatic variables), and popping the return PC on exit. The exception to
is the stuff around calling _enother_ routine (sketched above).
Another exception is alloca() (source here:
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
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
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
I force a termination and core dump elegantly, so
I can examine some
which can do interactive debugging.