Computer Old Farts Forum
 help / color / mirror / Atom feed
* [COFF] Re: ancient macros, machine code translation,as mental architecture models
@ 2024-07-15 12:37 Douglas McIlroy
  2024-07-15 14:26 ` Paul Winalski
  2024-07-15 19:39 ` John Levine
  0 siblings, 2 replies; 7+ messages in thread
From: Douglas McIlroy @ 2024-07-15 12:37 UTC (permalink / raw)
  To: COFF

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

In 1959, when Doug Eastwood and I,  at the suggestion  of George Mealy, set
out to add macro capability to SAP (Share assembly program), the word
"macro"--short for "macroinstruction"--was in the air, though none of us
had ever seen a macroprocessor. We were particularly aware that GE had a
macro-capable assembler. I still don't know where or when the term was
coined. Does anybody know?

We never considered anything but recursive expansion, where macro
definitions can contain macro calls; thus the TX-0 model comes as quite a
surprise. We kept a modest stack of the state of each active macro
expansion. We certainly did not foresee that within a few years some
applications would need a 70-level stack!

General stack-based programming was not common practice (and the term
"stack" did not yet exist). This caused disaster the first time we wrote a
macro that generated a macro definition, because a data-packing subroutine
with remembered state, which was used during both definition and expansion,
was not reentrant. To overcome the bug we had in effect to introduce
another small  stack to keep the two uses out of each other's way. Luckily
there were no more collisions between expansion and definition. Moreover,
this stack needed to hold only one suspended state because expansion could
trigger definition but not vice versa.

Interestingly, the problem in the previous paragraph is still with us 65
years later in many programming languages. To handle it gracefully, one
needs coroutines or higher-order functions.

Doug

[-- Attachment #2: Type: text/html, Size: 1729 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [COFF] Re: ancient macros, machine code translation,as mental architecture models
  2024-07-15 12:37 [COFF] Re: ancient macros, machine code translation,as mental architecture models Douglas McIlroy
@ 2024-07-15 14:26 ` Paul Winalski
  2024-07-15 14:38   ` Bakul Shah via COFF
  2024-07-15 19:39 ` John Levine
  1 sibling, 1 reply; 7+ messages in thread
From: Paul Winalski @ 2024-07-15 14:26 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: COFF

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Mon, Jul 15, 2024 at 8:46 AM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

>
> We never considered anything but recursive expansion, where macro
> definitions can contain macro calls; thus the TX-0 model comes as quite a
> surprise. We kept a modest stack of the state of each active macro
> expansion. We certainly did not foresee that within a few years some
> applications would need a 70-level stack!
>
> As I mentioned in a previous reply, BLISS has a very powerful and
extensive macro facility.  This led to an obscure and difficult to fix
parser bug.

The outermost organizational unit of a BLISS program is the module.  All
declarations, routines, identifiers, etc. have a syntactic scope limited to
the module in which they occur.  Modules are delimited by the keywords
MODULE and ELUOM (module spelt backwards).

The bug was triggered by a call to a macro that included an ELUDOM followed
by a new MODULE declaration.  When the parser saw the ELUDOM it threw away
all of the context for the current module, including the parser context for
the macro that was being processed.  The parser blew its brains out and the
compilation terminated with an internal compiler error.

-Paul W.

P. S. - I once remarked that in BLISS we don't solve problems, we ELUDOM.

[-- Attachment #2: Type: text/html, Size: 1727 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [COFF] Re: ancient macros, machine code translation,as mental architecture models
  2024-07-15 14:26 ` Paul Winalski
@ 2024-07-15 14:38   ` Bakul Shah via COFF
  0 siblings, 0 replies; 7+ messages in thread
From: Bakul Shah via COFF @ 2024-07-15 14:38 UTC (permalink / raw)
  To: Paul Winalski; +Cc: Douglas McIlroy, COFF

On Jul 15, 2024, at 7:26 AM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> Modules are delimited by the keywords MODULE and ELUOM (module spelt backwards)

I wonder who was the person who came up with the idea of reversing the beginning keyword to end the corresponding block in Algol68.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [COFF] Re: ancient macros, machine code translation,as mental architecture models
  2024-07-15 12:37 [COFF] Re: ancient macros, machine code translation,as mental architecture models Douglas McIlroy
  2024-07-15 14:26 ` Paul Winalski
@ 2024-07-15 19:39 ` John Levine
  2024-07-16 19:55   ` Aron Insinga
  1 sibling, 1 reply; 7+ messages in thread
From: John Levine @ 2024-07-15 19:39 UTC (permalink / raw)
  To: coff; +Cc: douglas.mcilroy

It appears that Douglas McIlroy <douglas.mcilroy@dartmouth.edu> said:
>In 1959, ...

>We never considered anything but recursive expansion, where macro
>definitions can contain macro calls; thus the TX-0 model comes as quite a
>surprise. We kept a modest stack of the state of each active macro
>expansion. We certainly did not foresee that within a few years some
>applications would need a 70-level stack!

As the PDP-1 Macro imeplementation manual said about the macro feature:

   It is the weakest
  in that it is quite inflexible and does not incorporate any of the more significant improvements
  in assembler technology that have occurred since the logic was first written in 1957.

The PDP-1 was not a very big machine, only 4K words and the only
standard I/O device was paper tape, so no overlays or multiple passes.
I can imagine that while they knew how to write a better macro
processor, they didn't want to use up the memory it would have needed.

Bitsavers has a bunch of memos about the TX-0.

Memo 39 describes TX-0 assembler as of 1962, which had real macros
that could insert arbitrary strings, as they show in an example on
pages 10-11.

https://bitsavers.org/pdf/mit/tx-0/memos/M-5001-39_MIDAS_Nov62.pdf

There are earlier memos about MACRO in 1959 and 1961 which suggest a weaker
macro facility but don't have details.

R's,
John

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [COFF] Re: ancient macros, machine code translation,as mental architecture models
  2024-07-15 19:39 ` John Levine
@ 2024-07-16 19:55   ` Aron Insinga
  2024-07-16 20:09     ` Aron Insinga
  0 siblings, 1 reply; 7+ messages in thread
From: Aron Insinga @ 2024-07-16 19:55 UTC (permalink / raw)
  To: coff

On 7/15/24 15:39, John Levine wrote:
> It appears that Douglas McIlroy <douglas.mcilroy@dartmouth.edu> said:
>> In 1959, ...
>> We never considered anything but recursive expansion, where macro
>> definitions can contain macro calls; thus the TX-0 model comes as quite a
>> surprise. We kept a modest stack of the state of each active macro
>> expansion. We certainly did not foresee that within a few years some
>> applications would need a 70-level stack!
> As the PDP-1 Macro imeplementation manual said about the macro feature:
>
>     It is the weakest
>    in that it is quite inflexible and does not incorporate any of the more significant improvements
>    in assembler technology that have occurred since the logic was first written in 1957.
>
> The PDP-1 was not a very big machine, only 4K words and the only
> standard I/O device was paper tape, so no overlays or multiple passes.
> I can imagine that while they knew how to write a better macro
> processor, they didn't want to use up the memory it would have needed.
>
> Bitsavers has a bunch of memos about the TX-0.
>
> Memo 39 describes TX-0 assembler as of 1962, which had real macros
> that could insert arbitrary strings, as they show in an example on
> pages 10-11.
>
> https://bitsavers.org/pdf/mit/tx-0/memos/M-5001-39_MIDAS_Nov62.pdf
>
> There are earlier memos about MACRO in 1959 and 1961 which suggest a weaker
> macro facility but don't have details.
>
> R's,
> John

At MIT they wrote two assemblers on the TX-0, and retargeted/ported both 
of them to the PDP-1.  (The machines were in adjacent rooms at the 
time.  Their architectures were very similar.)

* MACRO (macro expansion by limited partly-assembed memory words). DEC 
adopted MACRO, but its later MACRO assemblers do not seem to be at all 
based on that one.

* Midas (generalized macro expansion by inserting a character 
sequence).  MIT chose Midas for future work, and they rewrote it for the 
PDP-6, so that's what you find on ITS.

One of these retargets/ports was a challenge by Jack Dennis to a group 
of 4 or 5 students (the original hackers from the Tech Model Railroad 
Club) to do it over a weekend.

I agree, there is a lot of great stuff in these memos, from both MIT and 
from DEC, and in the oral histories done by the Computer History Museum 
and/or  the Smithsonian.

Bitsavers also has the hardware details, although they are in a very old 
notation, more abbreviated circuit schematics than logic diagrams..

- Aron




^ permalink raw reply	[flat|nested] 7+ messages in thread

* [COFF] Re: ancient macros, machine code translation,as mental architecture models
  2024-07-16 19:55   ` Aron Insinga
@ 2024-07-16 20:09     ` Aron Insinga
  2024-07-17 17:00       ` [COFF] Re: ancient macros Aron Insinga
  0 siblings, 1 reply; 7+ messages in thread
From: Aron Insinga @ 2024-07-16 20:09 UTC (permalink / raw)
  To: coff




On 7/16/24 15:55, Aron Insinga wrote:
> On 7/15/24 15:39, John Levine wrote:
>> It appears that Douglas McIlroy <douglas.mcilroy@dartmouth.edu> said:
>>> In 1959, ...
>>> We never considered anything but recursive expansion, where macro
>>> definitions can contain macro calls; thus the TX-0 model comes as 
>>> quite a
>>> surprise. We kept a modest stack of the state of each active macro
>>> expansion. We certainly did not foresee that within a few years some
>>> applications would need a 70-level stack!
>> As the PDP-1 Macro imeplementation manual said about the macro feature:
>>
>>     It is the weakest
>>    in that it is quite inflexible and does not incorporate any of the 
>> more significant improvements
>>    in assembler technology that have occurred since the logic was 
>> first written in 1957.
>>
>> The PDP-1 was not a very big machine, only 4K words and the only
>> standard I/O device was paper tape, so no overlays or multiple passes.
>> I can imagine that while they knew how to write a better macro
>> processor, they didn't want to use up the memory it would have needed.
>>
>> Bitsavers has a bunch of memos about the TX-0.
>>
>> Memo 39 describes TX-0 assembler as of 1962, which had real macros
>> that could insert arbitrary strings, as they show in an example on
>> pages 10-11.
>>
>> https://bitsavers.org/pdf/mit/tx-0/memos/M-5001-39_MIDAS_Nov62.pdf
>>
>> There are earlier memos about MACRO in 1959 and 1961 which suggest a 
>> weaker
>> macro facility but don't have details.
>>
>> R's,
>> John
>
> At MIT they wrote two assemblers on the TX-0, and retargeted/ported 
> both of them to the PDP-1.  (The machines were in adjacent rooms at 
> the time.  Their architectures were very similar.)
>
> * MACRO (macro expansion by limited partly-assembed memory words). DEC 
> adopted MACRO, but its later MACRO assemblers do not seem to be at all 
> based on that one.
>
> * Midas (generalized macro expansion by inserting a character 
> sequence).  MIT chose Midas for future work, and they rewrote it for 
> the PDP-6, so that's what you find on ITS.
>
> One of these retargets/ports was a challenge by Jack Dennis to a group 
> of 4 or 5 students (the original hackers from the Tech Model Railroad 
> Club) to do it over a weekend.
>
> I agree, there is a lot of great stuff in these memos, from both MIT 
> and from DEC, and in the oral histories done by the Computer History 
> Museum and/or  the Smithsonian.
>
> Bitsavers also has the hardware details, although they are in a very 
> old notation, more abbreviated circuit schematics than logic diagrams..

p.s. That was too sweeping of a statement.  For the machines built by 
MIT, I found block diagrams and some instruction flows and lots of 
memos, but not the clock distribution matrix details.  Since the WW 
clock distribution matrix (ROM) triggered Wilkes' invention of 
microprogramming, I'd love to compare WW's with their later machines'.  
And I haven't found more than a little on Wes Clark's later machines, 
L-1 and ARC-1.  I know some info is in the U. Wash. archives.  So many 
curiosities, so little time. :-)

Best,

- Aron

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [COFF] Re: ancient macros
  2024-07-16 20:09     ` Aron Insinga
@ 2024-07-17 17:00       ` Aron Insinga
  0 siblings, 0 replies; 7+ messages in thread
From: Aron Insinga @ 2024-07-17 17:00 UTC (permalink / raw)
  To: coff

This has nothing to do with compiling to code for other architectures!  
This is just for the record regarding the history of *assemblers*.

Here is a 1984 version of the DEC VAX-11 MACRO-32 *assembler* source 
listings:

http://www.bitsavers.org/pdf/dec/vax/microfiche/vms-source-listings/AH-BT13A-SE__VAX-VMS_V4.0_SRC_LST_MCRF/AH-BT13A-SE__VAX-VMS_V4.0_SRC_LST_MCRF/059__MACRO/

Unfortunately, they don't have the ASCII text attached, so you can't 
search.  Go up a level to find the linker, etc.

- Aron


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-07-17 17:00 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-07-15 12:37 [COFF] Re: ancient macros, machine code translation,as mental architecture models Douglas McIlroy
2024-07-15 14:26 ` Paul Winalski
2024-07-15 14:38   ` Bakul Shah via COFF
2024-07-15 19:39 ` John Levine
2024-07-16 19:55   ` Aron Insinga
2024-07-16 20:09     ` Aron Insinga
2024-07-17 17:00       ` [COFF] Re: ancient macros Aron Insinga

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).