From: Aron Insinga <aki@insinga.com>
To: coff@tuhs.org
Subject: [COFF] Re: machine code translation,as mental architecture models
Date: Sat, 13 Jul 2024 20:56:41 -0400 [thread overview]
Message-ID: <6a0f5b10-a2df-4117-b0ea-71802b6a7c26@insinga.com> (raw)
In-Reply-To: <20240713234644.AAD0B8F88DE4@ary.qy>
On 7/13/24 19:46, John Levine wrote:
> It appears that Douglas McIlroy <douglas.mcilroy@dartmouth.edu> said:
>> -=-=-=-=-=-
>>
>>> the DEC PDP-1 MACRO assembler manual says that a macro call
>>> is expanded by copying the *sequence of 'storage words' and
>>> advancing the current location (.) for each word copied*
>>> I am quite surprised.
> I looked at the manual and I think he's misreading it. The "words" in
> question are the tokens in the macro definition.
>
> The example macros look pretty straightforward, instructions and
> pseudo-ops that are expanded replacing dummy arguments by actual ones.
> There's no conditional assembly so each macro is just a parameterized
> chunk of code.
>
> https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf
>
> R's,
> John
Possibly, but they use 'syllables' for tokens (symbols or integers), and
they say here that they advance the location counter after each word
copied. If they were copying characters into the input stream, they
would not be incrementing the location counter ('.') after each word
transferred.
And as you say, it is simple parameter substitution, so tracking which
macro argument goes into which instruction's address field is easy. The
instruction format is simple. So for each line in the macro definition
body, if the opcode is a memory reference instruction, put the argument
number in the binary instruction address field before storing the
instruction word in a list/block. When expanding the macro, if the
opcode is a memory reference instruction, get the argument number from
the address field and replace it with the symbol table value of the
symbol passed in as the actual argument, and store the word in the
output stream (and incrememnt '.').
I haven't yet gotten the 18-bit-but-incompatible PDP-4 documentation for
comparison. [IIRC the PDP-4 assembler was the one with a single pass
assembler that punched the symbol table at the end of the tape, and the
clever loader that read the tape upside down and backwards to first
rebuild the symbol table and then fix up the instructions and load them
into memory.]
- Aron
next prev parent reply other threads:[~2024-07-14 0:57 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-13 22:00 Douglas McIlroy
2024-07-13 23:46 ` John Levine
2024-07-14 0:54 ` Dan Cross
2024-07-14 1:04 ` Aron Insinga
2024-07-14 0:56 ` Aron Insinga [this message]
2024-07-14 18:02 ` [COFF] Re: ancient macros, " John Levine
2024-07-15 1:44 ` Aron Insinga
2024-07-15 14:09 ` Paul Winalski
[not found] <20240710203422.284BA18C077@mercury.lcs.mit.edu>
[not found] ` <20240710212641.E24548F5C32C@ary.qy>
2024-07-11 1:29 ` [COFF] Re: [TUHS] " Dan Cross
[not found] ` <18977302-8934-ec96-9154-b3c53824e506@taugh.com>
2024-07-11 2:05 ` Dan Cross
2024-07-11 16:50 ` Paul Winalski
2024-07-12 16:23 ` John R Levine
2024-07-12 16:51 ` [COFF] " Paul Winalski
2024-07-12 17:02 ` John R Levine
2024-07-12 20:52 ` Dave Horsfall
2024-07-12 22:03 ` John Levine
2024-07-13 0:25 ` Aron Insinga
2024-07-13 0:27 ` Dave Horsfall
2024-07-13 1:19 ` Paul Winalski
[not found] ` <CABH=_VS8z6ayJSQab0u5Cxw--hM8px8-eFGjeFCKTXxe <alpine.BSF.2.21.9999.2407131018370.6233@aneurin.horsfall.org>
2024-07-13 2:25 ` John Levine
2024-07-13 9:57 ` [COFF] Re: machine code translation, as " Ralph Corderoy
2024-07-13 14:25 ` Dan Cross
2024-07-13 17:27 ` Aron Insinga
2024-07-12 17:03 ` [COFF] Re: machine code translation,as " Stuff Received
2024-07-12 18:01 ` Paul Winalski
2024-07-12 20:35 ` John Levine
2024-07-13 9:26 ` [COFF] Re: machine code translation, as " Ralph Corderoy
2024-07-12 18:54 ` [COFF] Re: machine code translation,as " Aron Insinga
2024-07-12 21:49 ` Dave Horsfall
[not found] ` <20240710203422.284BA18C077@mercury.lcs. <20240713095708.203D5220C9@orac.inputplus.co.uk>
2024-07-13 18:50 ` [COFF] Re: machine code translation, as " John Levine
2024-07-13 19:27 ` Paul Winalski
2024-07-13 19:42 ` Dan Cross
2024-07-14 1:09 ` Aron Insinga
2024-07-14 1:46 ` Aron Insinga
2024-07-14 16:16 ` Paul Winalski
-- strict thread matches above, loose matches on Subject: below --
2024-07-13 11:09 [COFF] Re: machine code translation,as " Douglas McIlroy
2024-07-13 17:36 ` Paul Winalski
2024-07-13 21:05 ` Aron Insinga
2024-07-14 15:55 ` Paul Winalski
2024-07-14 17:29 ` G. Branden Robinson
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=6a0f5b10-a2df-4117-b0ea-71802b6a7c26@insinga.com \
--to=aki@insinga.com \
--cc=coff@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).