13 Jul
2024
13 Jul
'24
11:09 a.m.
Well, doesn't it depend on whether VAX MACRO kept
the macros as
high-level entities when translating them, or if it processed macros in
the familiar way into instructions that sat at the same level as
hand-written ‘assembler’. I don't think this thread has made that clear
so far.
The Multics case that I cited was definitely in the latter category.
There was no "translator". Effectively there were just two different
macro packages applied to the same source file.
In more detail, there were very similar assemblers for the original
IBM machines and the new GE machines. Since they didn't have
"include" facilities, there were actually two source files that differed
only in their macro definitions. The act of translation was to supply
the latter set of definitions--a notably larger set than the former
(which may well have been empty).
Doug
13 Jul
13 Jul
5:36 p.m.
New subject: machine code translation,as mental architecture models
On Sat, Jul 13, 2024 at 9:35 AM Douglas McIlroy <
douglas.mcilroy(a)dartmouth.edu> wrote:
treats them.
It expands them into individual assembler statements (i.e.,
instructions, labels, data definitions, etc.). VAX MACRO then translates
those into compiler intermediate language (originally GEM EIL [expanded
intermediate language], nowadays probably LLVM IL).
Neither the VAX assembler nor the VAX MACRO compiler treats macros as
high-level entities. I know of no assembler that would do such a thing.
-Paul W.
Well,
doesn't it depend on whether VAX MACRO kept the macros as
high-level entities when translating them, or if it processed macros in
the familiar way into instructions that sat at the same level as
hand-written ‘assembler’. I don't think this thread has made that clear
so far.
The VAX MACRO compiler treats macros the same way that the assembler 
9:05 p.m.
New subject: machine code translation,as mental architecture models
On 7/13/24 13:36, Paul Winalski wrote:
Neither the VAX assembler nor the VAX MACRO compiler
treats macros as
high-level entities. I know of no assembler that would do such a thing.
-Paul W.
This morning I would have agreed with you but I think I found a
counter-example. At MIT, there were 2 assemblers written for the TX-0
and later ported and retargeted to the PDP-1: MACRO (which DEC adopted)
and then Midas (which MIT stayed with for the PDP-6 and PDP-10).
The MIDAS assembler manual says that it copies characters from the macro
body into the source program (as we would expect to happen today for a
macro, as opposed to an inline procedure):
http://www.bitsavers.org/pdf/mit/rle_pdp1/memos/PDP-1_MIDAS.pdf
p 10 in the document says:
When a macro instruction is called, MIDAS reads out the characters
which form the macro-instruction definition, substitutes the
characters of the arguments for the dummy arguments, and inserts the
resulting characters into the source program as if typed there
originally.
However, 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* (although it does replace
labels with memory addresses):
https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf
p 19 in the document says:
I am quite surprised.
[For those who may not know, the TX-0 was built at MIT Lincoln Lab in
1956 and, when it was no longer useful for their research, it was moved
onto the campus where the model railroad club found it and started
hacking. DEC was spun off from Lincoln Lab, with the result that the
PDP-1 was very similar to the TX-0, and an early PDP-1 was installed in
the room on campus next to the TX-0. But that was all before my time.]
- Aron
14 Jul
14 Jul
3:55 p.m.
New subject: machine code translation,as mental architecture models
On Sat, Jul 13, 2024 at 5:20 PM Aron Insinga <aki(a)insinga.com> wrote:
On 7/13/24 13:36, Paul Winalski wrote:
Neither the VAX assembler nor the VAX MACRO compiler treats macros as
high-level entities. I know of no assembler that would do such a thing.
-Paul W.
This morning I would have agreed with you but I think I found a
counter-example. At MIT, there were 2 assemblers written for the TX-0 and
later ported and retargeted to the PDP-1: MACRO (which DEC adopted) and
then Midas (which MIT stayed with for the PDP-6 and PDP-10).
The MIDAS assembler manual says that it copies characters from the macro
body into the source program (as we would expect to happen today for a
macro, as opposed to an inline procedure):
http://www.bitsavers.org/pdf/mit/rle_pdp1/memos/PDP-1_MIDAS.pdf
p 10 in the document says:
When a macro instruction is called, MIDAS reads out the characters which
form the macro-instruction definition, substitutes the characters of the
arguments for the dummy arguments, and inserts the resulting characters
into the source program as if typed there originally.
However, 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* (although it does replace labels
with memory addresses):
https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf
p 19 in the document says:
Those two quotes from the documentation are saying the same thing. The
MACRO quote
says the process is this:
1. Evaluate the expressions in the argument list of the macro.
2. Substitute these values for the dummy symbols in the macro.
3. Process the resulting text exactly the same way as non-macro input to
the assembler.
4. Place the resulting binary machine words into the object file.
Steps (1) and (2) match what the Midas text says. Steps (3) and (4) are
conventional processing of assembler input.
There is nothing unusual here. MACRO is decidedly NOT treating the macro
calls as higher-level entities. It is doing simple text substitution and
then treating it as it would any other input.
-Paul W.
5:29 p.m.
New subject: machine code translation,as mental architecture models
At 2024-07-14T11:55:19-0400, Paul Winalski wrote:
> However, 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* (although
> it does replace labels with memory addresses):
> https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf
> p 19 in the document says:
[snip]
Nothing destines a typeface for quaintness like naming it "Futura".
Regards,
Branden
206
days inactive
207
days old
4 comments
4 participants
participants (4)
-
Aron Insinga -
Douglas McIlroy -
G. Branden Robinson -
Paul Winalski