Computer Old Farts Forum
 help / color / mirror / Atom feed
* [COFF] Re: machine code translation,as mental architecture models
@ 2024-07-13 22:00 Douglas McIlroy
  2024-07-13 23:46 ` John Levine
  0 siblings, 1 reply; 36+ messages in thread
From: Douglas McIlroy @ 2024-07-13 22:00 UTC (permalink / raw)
  To: COFF

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

> 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 am, too. It seems that expansion is not recursive. And that it can only
allocate storage word by word, not in larger blocks.

Doug

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

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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-13 22:00 [COFF] Re: machine code translation,as mental architecture models Douglas McIlroy
@ 2024-07-13 23:46 ` John Levine
  2024-07-14  0:54   ` Dan Cross
  2024-07-14  0:56   ` Aron Insinga
  0 siblings, 2 replies; 36+ messages in thread
From: John Levine @ 2024-07-13 23:46 UTC (permalink / raw)
  To: coff; +Cc: douglas.mcilroy

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

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

* [COFF] Re: machine code translation,as mental architecture models
  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
  1 sibling, 1 reply; 36+ messages in thread
From: Dan Cross @ 2024-07-14  0:54 UTC (permalink / raw)
  To: John Levine; +Cc: coff, douglas.mcilroy

A general housekeeping plea.  When quoting someone's text, could we
please use correct attributions?

On Sat, Jul 13, 2024 at 7:46 PM John Levine <johnl@taugh.com> wrote:
> It appears that Douglas McIlroy <douglas.mcilroy@dartmouth.edu> said:

It may appear so based on the quoted text, but in fact Doug did _not_
write the words reproduced here, but rather, was quoting someone else
who did.  In this case, Aron Insinga wrote the text below.
Unfortunately, that this is Aron's contribution to the discussion is
not mentioned anywhere in the quoted portion.

Of course mistakes happen, but it's been happening with increasing
frequency lately, and it's not particularly fair to either the person
who made the original contribution or the person to whom the quotes
are misattributed.

Thanks!

        - Dan C.

> >-=-=-=-=-=-
> >
> >> 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

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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-13 23:46 ` John Levine
  2024-07-14  0:54   ` Dan Cross
@ 2024-07-14  0:56   ` Aron Insinga
  2024-07-14 18:02     ` [COFF] Re: ancient macros, " John Levine
  1 sibling, 1 reply; 36+ messages in thread
From: Aron Insinga @ 2024-07-14  0:56 UTC (permalink / raw)
  To: coff

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


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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-14  0:54   ` Dan Cross
@ 2024-07-14  1:04     ` Aron Insinga
  0 siblings, 0 replies; 36+ messages in thread
From: Aron Insinga @ 2024-07-14  1:04 UTC (permalink / raw)
  To: coff

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

I think this is correctly patched:


On 7/13/24 19:46, John Levine wrote:
>> Aron Insinga<aki@insinga.com>  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

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

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

* [COFF] Re: ancient macros, machine code translation,as mental architecture models
  2024-07-14  0:56   ` Aron Insinga
@ 2024-07-14 18:02     ` John Levine
  2024-07-15  1:44       ` Aron Insinga
  0 siblings, 1 reply; 36+ messages in thread
From: John Levine @ 2024-07-14 18:02 UTC (permalink / raw)
  To: coff

According to Aron Insinga <aki@insinga.com>:
>On 7/13/24 19:46, John Levine wrote:
>> I looked at the manual and I think he's misreading it. The "words" in
>> question are the tokens in the macro definition. ...

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

If you really want to know what it did, here's the internals manual.
The description of the macro facility starts on page 19 and it is
quite clear that they're storing a tokenized version of the macros, so
they're not copying characters, but they're not just copying assembled
instructions either.

https://bitsavers.org/pdf/dec/pdp1/F36P_PDP1_Macro_Internals.pdf

  The macro instruction facility in MACRO is both the strongest and weakest part of the program.
  It is the strongest in the sense that it is thot part of the program which contributes most toward
  ease of programming, especially in setting up tables of specialized format. 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.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


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

* [COFF] Re: ancient macros, machine code translation,as mental architecture models
  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
  0 siblings, 1 reply; 36+ messages in thread
From: Aron Insinga @ 2024-07-15  1:44 UTC (permalink / raw)
  To: coff

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

On 7/14/24 14:02, John Levine wrote:
> According to Aron Insinga<aki@insinga.com>:
>> On 7/13/24 19:46, John Levine wrote:
>>> I looked at the manual and I think he's misreading it. The "words" in
>>> question are the tokens in the macro definition. ...
>> 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.
> If you really want to know what it did, here's the internals manual.
> The description of the macro facility starts on page 19 and it is
> quite clear that they're storing a tokenized version of the macros, so
> they're not copying characters, but they're not just copying assembled
> instructions either.
>
> https://bitsavers.org/pdf/dec/pdp1/F36P_PDP1_Macro_Internals.pdf

Thank you!!  I found the PDP-1 and TX-0 MACRO sources and was sadly 
unsurprised by the lack of comments, so they are difficult reading.

    http://www.bitsavers.org/bits/DEC/pdp1/papertapeImages/20040106/macro_6-63/_text/part2.txt

They are not storing tokens.  In fact, the list of 'codes' for items 
stored as the macro body on p 20 is:
     a storage word,
     a dummy symbol specification.
     a constant,
     a dummy symbol parameter assignment, or
     an end marker.
So it is not storing tokens for instructions, just storage words 
(instructions or data) as mentioned in the user manual.

In the discussion in the internals manual, after the paragraph 
mentioning the year this was designed (a nice touch), they say that they 
are storing the macro body as 'partially assembled' 'words' into which 
the dummy symbols are 'inserted'.  (And in a single-address architecture 
with a small memory address, addition is enough to do that insertion.)  
They explain why they did this instead of storing characters:

They do not look at the opcode as I suggested was possible, they have a 
more general solution that works for a word containing either code or data.

I think that this may be (at least as far as any of us know) a unique 
case from the early days of computing where, on the TX-0 and a port to 
the PDP-1, a macro body *is* stored as a list of 'machine words' instead 
of source text.  The macro  body is not manipulated as a 'higher-level 
construct', it is just used for quite limited macro expansion.

This has NO bearing on what DEC/HP/VSI did more than two decades later 
for the Alpha, Itanic, and x86_64 (where macros are expanded by the 
conventional insertion of characters from the macro body into the source 
text stream).

- Aron

[-- Attachment #2.1: Type: text/html, Size: 4118 bytes --]

[-- Attachment #2.2: 1RaBLgOaK9W7nogv.png --]
[-- Type: image/png, Size: 101224 bytes --]

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

* [COFF] Re: ancient macros, machine code translation,as mental architecture models
  2024-07-15  1:44       ` Aron Insinga
@ 2024-07-15 14:09         ` Paul Winalski
  0 siblings, 0 replies; 36+ messages in thread
From: Paul Winalski @ 2024-07-15 14:09 UTC (permalink / raw)
  To: Aron Insinga; +Cc: coff

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

On Sun, Jul 14, 2024 at 9:44 PM Aron Insinga <aki@insinga.com> wrote:

> I think that this may be (at least as far as any of us know) a unique case
> from the early days of computing where, on the TX-0 and a port to the
> PDP-1, a macro body *is* stored as a list of 'machine words' instead of
> source text.  The macro  body is not manipulated as a 'higher-level
> construct', it is just used for quite limited macro expansion.
>

Thanks for clearing this up.  I think you're right that this is a unique
case.  All assemblers I've ever dealt with expanded macros into text that
was then fed to the assember's parser just as if it were ordinary source
program text.  On a machine with limited memory it makes sense not to have
to re-parse the expanded source after macro expansion, but instead to do
the translation on the fly.  It saves a second pass over the expanded macro
call.

-Paul W.

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

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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-14 15:55     ` Paul Winalski
@ 2024-07-14 17:29       ` G. Branden Robinson
  0 siblings, 0 replies; 36+ messages in thread
From: G. Branden Robinson @ 2024-07-14 17:29 UTC (permalink / raw)
  To: coff

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

* [COFF] Re: machine code translation, as mental architecture models
  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
  2 siblings, 0 replies; 36+ messages in thread
From: Paul Winalski @ 2024-07-14 16:16 UTC (permalink / raw)
  To: Dan Cross; +Cc: John Levine, coff

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

On Sat, Jul 13, 2024 at 4:00 PM Dan Cross <crossd@gmail.com> wrote:

>
> This is conflating two different things over the life of the MACRO-32
> language.  It certainly started out as a macro assembler, but with the
> introduction of the Alpha, DEC turned it into a true compiler (where
> the source language happens to be VAX assembly language) that
> generated native code for whatever machine it was compiled for: VAX or
> Alpha; using the GEM backends.
>
> The confusion arises because the name VAX MACRO was used for two
completely independent and very different software tools.

The first VAX MACRO was the conventional assembler for VAX/VMS, developed
in the mid-1970s.  It had conventional macroinstruction capabilities, hence
the name.

An inconveniently large amount of the VAX/VMS operating system code was
written in VAX assembly language.  Dave Cutler didn't believe in using
higher level languages for system code, and he despised BLISS (DEC's
standard HLL language for software product development) in particular.  To
migrate VMS to Alpha it was decided that the quickest and least error-prone
path was to write a compiler front end that takes VAX MACRO syntax and
generates expanded intermediate language (EIL) for the GEM compiler back
end.  GEM then generates the Alpha code and writes it into an object file.
This work was done circa 1990.  The name "VAX MACRO" was used for this
compiler as well as for the previous assembler.


> When Compaq started the port to Itanium, they employed the same
> technique; this was maintained by HP.
>
> No further work needed to be done in the VAX MACRO compiler front end to
support Itanium.  All that needed to be done was to add Itanium code
generation capability to the GEM back end.  After that all GEM-based
compilers acquired Itanium code generation capability.  That is the big
advantage of having a common back end for all compilers.  Over its lifetime
GEM could generate object files for the MIPS, Alpha, and IA-32 machine
architectures and for the VMS, Ultrix, OSF-1, and Windows operating
systems.

VSI has shifted to using LLVM as their compiler backend for the x86_64
> port, with ELF as the executable file format (and presumably for
> object files as well).  As I understand the current state of affairs,
> there is a GEM to LLVM layer that interfaces between the still-GEM
> output of compiler frontends and the LLVM backend, that performs
> native code generation.  Macro, in particular, bypasses most of the
> LLVM optimization layer.
>
> VAX MACRO also bypassed most of GEM's optimization layer as well.  And
yes, most (if not all) of the legacy OpenVMS compilers use a GEM-to-LLVM IL
translator.  VSI has more than enough on their plate without taking on a
wholesale rewrite of the IL generators in the compiler front ends.

-Paul W.

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

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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-13 21:05   ` Aron Insinga
@ 2024-07-14 15:55     ` Paul Winalski
  2024-07-14 17:29       ` G. Branden Robinson
  0 siblings, 1 reply; 36+ messages in thread
From: Paul Winalski @ 2024-07-14 15:55 UTC (permalink / raw)
  To: Aron Insinga; +Cc: coff


[-- Attachment #1.1: Type: text/plain, Size: 2248 bytes --]

On Sat, Jul 13, 2024 at 5:20 PM Aron Insinga <aki@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.

[-- Attachment #1.2: Type: text/html, Size: 3333 bytes --]

[-- Attachment #2: kLOsHOzErbke14PV.png --]
[-- Type: image/png, Size: 29927 bytes --]

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

* [COFF] Re: machine code translation, as mental architecture models
  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
  2 siblings, 0 replies; 36+ messages in thread
From: Aron Insinga @ 2024-07-14  1:46 UTC (permalink / raw)
  To: coff

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

On 7/13/24 15:42, Dan Cross wrote:

> The output of fully expanded MACRO-32 is basically VAX assembly language, which is then
> compiled in a manner similar to how one would compile preprocessed C.
>
>          - Dan C.

Although, a minor point, the macro definition & expansion, conditional 
assembly, etc. are all done on the fly as the assembly language source 
file is read.  There's no separate macro processing pass like on Unix 
when, if the first character of the .c file was '#', cpp read the .c 
file and generated a .i file to pass to the compiler proper (which let 
cpp be used on Pascal, assembler, and who knows what else).

- Aron

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

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

* [COFF] Re: machine code translation, as mental architecture models
  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
  2 siblings, 0 replies; 36+ messages in thread
From: Aron Insinga @ 2024-07-14  1:09 UTC (permalink / raw)
  To: Computer Old Farts Followers

Back to topic of machine code translation, I stumbled over this paper 
describing DEC's migration from VAX (VMS) or MIPS (Ultrix) to Alpha (VMS 
or OSF/1, respectively) for user-mode applications.  The paper states 
that this included hand-coded assembly language applications.

https://web.stanford.edu/class/cs343/resources/binary-translation.pdf


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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-13 17:36 ` Paul Winalski
@ 2024-07-13 21:05   ` Aron Insinga
  2024-07-14 15:55     ` Paul Winalski
  0 siblings, 1 reply; 36+ messages in thread
From: Aron Insinga @ 2024-07-13 21:05 UTC (permalink / raw)
  To: coff

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

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

[-- Attachment #2.1: Type: text/html, Size: 2957 bytes --]

[-- Attachment #2.2: kLOsHOzErbke14PV.png --]
[-- Type: image/png, Size: 29927 bytes --]

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

* [COFF] Re: machine code translation, as mental architecture models
  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
                                   ` (2 more replies)
  1 sibling, 3 replies; 36+ messages in thread
From: Dan Cross @ 2024-07-13 19:42 UTC (permalink / raw)
  To: John Levine; +Cc: coff

On Sat, Jul 13, 2024 at 2:50 PM John Levine <johnl@taugh.com> wrote:
> According to Ralph Corderoy <ralph@inputplus.co.uk>:
> >> Oh, no wonder the translator worked so well.
> >
> >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.
>
> It was a macro assembler. The macros generated assembler statements
> that got assembled the normal way. I agree with the person that every
> macro assembler I've ever seen did that. A semi-exception is the IBM
> assembler that also had a PUNCH statement that put records into the
> object file but I think that was only used to pass commands to the
> linker.

This is conflating two different things over the life of the MACRO-32
language.  It certainly started out as a macro assembler, but with the
introduction of the Alpha, DEC turned it into a true compiler (where
the source language happens to be VAX assembly language) that
generated native code for whatever machine it was compiled for: VAX or
Alpha; using the GEM backends.

When Compaq started the port to Itanium, they employed the same
technique; this was maintained by HP.

VSI has shifted to using LLVM as their compiler backend for the x86_64
port, with ELF as the executable file format (and presumably for
object files as well).  As I understand the current state of affairs,
there is a GEM to LLVM layer that interfaces between the still-GEM
output of compiler frontends and the LLVM backend, that performs
native code generation.  Macro, in particular, bypasses most of the
LLVM optimization layer.

> The more relevant question is how they used the macros. If the macros
> were used consistently for semantically higher level things, the
> translator can use the semantics of the macros when translating.

As has been mentioned, they don't do this.  The output of fully
expanded MACRO-32 is basically VAX assembly language, which is then
compiled in a manner similar to how one would compile preprocessed C.

        - Dan C.

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

* [COFF] Re: machine code translation, as mental architecture models
  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
  1 sibling, 0 replies; 36+ messages in thread
From: Paul Winalski @ 2024-07-13 19:27 UTC (permalink / raw)
  To: John Levine; +Cc: coff

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

On Sat, Jul 13, 2024 at 2:50 PM John Levine <johnl@taugh.com> wrote:

> The more relevant question is how they used the macros. If the macros
> were used consistently for semantically higher level things, the
> translator can use the semantics of the macros when translating.
>
> There is an assembly macro for each of the user-mode VMS system services
These are wrappers around the RTL subroutines.  So, for example, the $QIO
(queue I/O) macro is a wrapper around a call to the SYS$QIO runtime library
routine.  There is a similar set of macros for the RMS (record management
services--the VMS file I/O system) data structures and routines.

The VAX MACRO compiler could perhaps use the semantics of the macros when
translating, but it doesn't.  It has to support semantics-free macro
expansion since users can write their own macros, so there is little point
in building semantic knowledge into the translator.

-Paul W.

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

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

* [COFF] Re: machine code translation, as mental architecture models
       [not found]           ` <20240710203422.284BA18C077@mercury.lcs. <20240713095708.203D5220C9@orac.inputplus.co.uk>
@ 2024-07-13 18:50             ` John Levine
  2024-07-13 19:27               ` Paul Winalski
  2024-07-13 19:42               ` Dan Cross
  0 siblings, 2 replies; 36+ messages in thread
From: John Levine @ 2024-07-13 18:50 UTC (permalink / raw)
  To: coff

According to Ralph Corderoy <ralph@inputplus.co.uk>:
>> Oh, no wonder the translator worked so well.
>
>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.

It was a macro assembler. The macros generated assembler statements
that got assembled the normal way. I agree with the person that every
macro assembler I've ever seen did that. A semi-exception is the IBM
assembler that also had a PUNCH statement that put records into the
object file but I think that was only used to pass commands to the
linker.

The more relevant question is how they used the macros. If the macros
were used consistently for semantically higher level things, the
translator can use the semantics of the macros when translating.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-13 11:09 [COFF] " Douglas McIlroy
@ 2024-07-13 17:36 ` Paul Winalski
  2024-07-13 21:05   ` Aron Insinga
  0 siblings, 1 reply; 36+ messages in thread
From: Paul Winalski @ 2024-07-13 17:36 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: COFF

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

On Sat, Jul 13, 2024 at 9:35 AM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

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

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

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

* [COFF] Re: machine code translation, as mental architecture models
  2024-07-13 14:25                   ` Dan Cross
@ 2024-07-13 17:27                     ` Aron Insinga
  0 siblings, 0 replies; 36+ messages in thread
From: Aron Insinga @ 2024-07-13 17:27 UTC (permalink / raw)
  To: COFF

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

On 7/13/24 10:25, Dan Cross wrote:
> On Sat, Jul 13, 2024 at 5:57 AM Ralph Corderoy<ralph@inputplus.co.uk>  wrote:
>> John and Paul wrote:
>> 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 DEC assemblers [sic] for the PDP-11 and VAX-11 did macro expansion 
as text substitution.

AA-V027A-TC PDP-11 MACRO-11 Language Reference Manual
Section 7.1 (PDF file p 115, original document p 7-1) says
"Macro expansion is the insertion of the macro source lines into the 
main program."
Note: This manual also discusses concatenation with macro arguments and 
(on p 120 or p 7-6) macros that define other macros.

AA-D032B-TE VAX-11 MACRO Language Reference Manual
The beginning of chapter 6 (p 119 or p 6-1) says the same thing.

At least in those assemblers, macros were not inline procedures.

Google can find manuals for other assemblers.  For even earlier history, see
https://github.com/PDP-10/its/issues/2032
http://www.bitsavers.org/pdf/mit/rle_pdp1/memos/PDP-1_MIDAS.pdf

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

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

* [COFF] Re: machine code translation, as mental architecture models
  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
  0 siblings, 1 reply; 36+ messages in thread
From: Dan Cross @ 2024-07-13 14:25 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: COFF

On Sat, Jul 13, 2024 at 5:57 AM Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> John and Paul wrote:
> > > > > The VAX MACRO compiler takes in VAX assembly source code, not
> > > > > binary VAX instructions.
> > > >
> > > > Does anyone know how extensively they used the macro facilities?
> > > > You can write much higher level stuff as macros than as single
> > > > instructions, which makes it a lot easier to do efficient
> > > > translation.
> > >
> > > Macros were used very extensively in VAX MACRO, both for user
> > > programming and in the operating system.  All of the low-level
> > > system calls for user programs were implemented and documented as
> > > macros.  The OS assembly code made heavy use of macros as well.
> >
> > Oh, no wonder the translator worked so well.
>
> 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 non-VAX compilers for Macro-32 do expansion.  That is, they don't
just recognize macros and treat them as intrinsics or primitives that
are specially optimized. Macro is not C, where you can treat "library"
functions defined in the standard specially.  John Reagan, of VSI, has
posted about XMACRO (the Macro compiler for x86) in various places.
For instance, here:
https://comp.os.vms.narkive.com/F05qmMaD/x86-cross-tools-kit#post4

This post, and others, suggests to me that XMACRO is definitely doing
macro expansion before compilation proper.

        - Dan C.

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

* [COFF] Re: machine code translation,as mental architecture models
@ 2024-07-13 11:09 Douglas McIlroy
  2024-07-13 17:36 ` Paul Winalski
  0 siblings, 1 reply; 36+ messages in thread
From: Douglas McIlroy @ 2024-07-13 11:09 UTC (permalink / raw)
  To: COFF

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

> 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

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

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

* [COFF] Re: machine code translation, as mental architecture models
  2024-07-12 17:02               ` John R Levine
  2024-07-12 20:52                 ` Dave Horsfall
       [not found]                 ` <CABH=_VS8z6ayJSQab0u5Cxw--hM8px8-eFGjeFCKTXxe <alpine.BSF.2.21.9999.2407131018370.6233@aneurin.horsfall.org>
@ 2024-07-13  9:57                 ` Ralph Corderoy
  2024-07-13 14:25                   ` Dan Cross
  2 siblings, 1 reply; 36+ messages in thread
From: Ralph Corderoy @ 2024-07-13  9:57 UTC (permalink / raw)
  To: COFF

Hi,

John and Paul wrote:
> > > > The VAX MACRO compiler takes in VAX assembly source code, not
> > > > binary VAX instructions.
> > >
> > > Does anyone know how extensively they used the macro facilities?
> > > You can write much higher level stuff as macros than as single
> > > instructions, which makes it a lot easier to do efficient
> > > translation.
> >
> > Macros were used very extensively in VAX MACRO, both for user
> > programming and in the operating system.  All of the low-level
> > system calls for user programs were implemented and documented as
> > macros.  The OS assembly code made heavy use of macros as well.
>
> Oh, no wonder the translator worked so well.

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.

-- 
Cheers, Ralph.

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

* [COFF] Re: machine code translation, as mental architecture models
  2024-07-12 20:35                   ` John Levine
@ 2024-07-13  9:26                     ` Ralph Corderoy
  0 siblings, 0 replies; 36+ messages in thread
From: Ralph Corderoy @ 2024-07-13  9:26 UTC (permalink / raw)
  To: coff

Hi,

John Levine wrote:
> Take a look at PL/I.  Its preprocessor lets you use a large subset of
> PL/I including if, goto, and do loops and most of the string and
> arithmetic operators to write functions that run at compile time and
> put their results into the source file.

Another approach is for the language to offer evaluation at compile
time.

- FORTH had COMPILE and IMMEDIATE to switch modes; there's POSTPONE as
  well now.

- Zig has comptime.
  https://ziglang.org/documentation/master/#comptime
  https://ziglang.org/documentation/master/#Case-Study-print-in-Zig

-- 
Cheers, Ralph.

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

* [COFF] Re: machine code translation,as mental architecture models
       [not found]                 ` <CABH=_VS8z6ayJSQab0u5Cxw--hM8px8-eFGjeFCKTXxe <alpine.BSF.2.21.9999.2407131018370.6233@aneurin.horsfall.org>
@ 2024-07-13  2:25                   ` John Levine
  0 siblings, 0 replies; 36+ messages in thread
From: John Levine @ 2024-07-13  2:25 UTC (permalink / raw)
  To: coff

According to Dave Horsfall <dave@horsfall.org>:
>I am reminded of the time when overlapped seeks on the RK-11 were 
>implemented in Unix, per the Peripherals Handbook.
>
>They didn't work.

Yup, I recall looking at the disk drivers which had a comment saying
that overlapped seeks on RK disks didn't work.

At Yale our PDP-11 had a pair of 2314-style RP drives. Its controller
did work and I stayed up all night one weekend debugging a driver that
queued and sorted requests for the two drives separately and did
separate seeks. It made a lot of difference, something like 30% more
transfers/minute.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


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

* [COFF] Re: machine code translation,as mental architecture models
  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
  2 siblings, 0 replies; 36+ messages in thread
From: Paul Winalski @ 2024-07-13  1:19 UTC (permalink / raw)
  To: John Levine; +Cc: coff

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

On Fri, Jul 12, 2024 at 6:10 PM John Levine <johnl@taugh.com> wrote:

>
> PS: For you young folks, Comet was DEC's internal project name for the
> /750.
>

The first generation of VAXen were the 11-780 (codenamed Star), the 11/750
(Comet) and the 11/730 (Nebula).

The 11/780's successor was to be implemented in ECL and was codenamed
Venus.  Along with Venus were a two-board VAX implementation (Gemini) and a
one-board VAX (Scorpio).  Gemini was cancelled.  Venus had lots of schedule
slippage but was eventually released, but under the new 4-digit VAX
branding system (it was originally slated to be called the 11-790).
Scorpio became the VAX 8000.

-Paul W

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

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

* [COFF] Re: machine code translation,as mental architecture models
  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
  2 siblings, 0 replies; 36+ messages in thread
From: Dave Horsfall @ 2024-07-13  0:27 UTC (permalink / raw)
  To: Computer Old Farts Followers

On Sat, 12 Jul 2024, John Levine wrote:

> The details are a litle dim after 45 years, but there was a MOVTUC 
> instruction in the inner loop of printf that scanned for the null at the 
> end of the string.  The /750 had a microcode bug that didn't matter for 
> the way DEC's software used it but broke the libc and I think also the 
> kernel version.  MOVTUC sets six registers and we probably used one they 
> didn't.

I am reminded of the time when overlapped seeks on the RK-11 were 
implemented in Unix, per the Peripherals Handbook.

They didn't work.

DEC responded with "Well, you were running Unix!"...

We then ran "DECEX" (their own diagnostic tool), which indeed failed
on overlapped seekson the RK-11.

It turned out that DEC never used overlapped seeks in their own stuff...

-- Dave

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

* [COFF] Re: machine code translation,as mental architecture models
  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
  2 siblings, 0 replies; 36+ messages in thread
From: Aron Insinga @ 2024-07-13  0:25 UTC (permalink / raw)
  To: coff

I think my work was in the summer of 1979 or possibly 1980, before the 
FRS in Oct. 1980.  People were happy because mass production of the 
ucode ROMs hadn't started yet.  I was using one of the 2~4 11/750 
prototypes which were on concrete blocks in a lab, and the 11/730 
breadboard was standing up on a table (no box) with its boards fanned 
out.  And it was during the gasoline shortage.  Maybe I'll find 
something about it later.

- Aron


On 7/12/24 18:03, John Levine wrote:
> It appears that Dave Horsfall <dave@horsfall.org> said:
>> On Sat, 12 Jul 2024, John R Levine wrote:
>>
>>> Our Vaxes ran Unix so it was all C other than a few things like tracking
>>> down a bug in the 11/750's microcode that broke an instruction in the
>>> inner loop of printf().  [...]
>> Do tell...
> The details are a litle dim after 45 years, but there was a MOVTUC
> instruction in the inner loop of printf that scanned for the null at
> the end of the string.  The /750 had a microcode bug that didn't
> matter for the way DEC's software used it but broke the libc and
> I think also the kernel version.  MOVTUC sets six registers and
> we probably used one they didn't.
>
> Bill replaced it with a few simpler instructions and the comment
>
> 	; Comet sucks
>
> R's,
> John
>
> PS: For you young folks, Comet was DEC's internal project name for the /750.


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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-12 20:52                 ` Dave Horsfall
@ 2024-07-12 22:03                   ` John Levine
  2024-07-13  0:25                     ` Aron Insinga
                                       ` (2 more replies)
  0 siblings, 3 replies; 36+ messages in thread
From: John Levine @ 2024-07-12 22:03 UTC (permalink / raw)
  To: coff

It appears that Dave Horsfall <dave@horsfall.org> said:
>On Sat, 12 Jul 2024, John R Levine wrote:
>
>> Our Vaxes ran Unix so it was all C other than a few things like tracking 
>> down a bug in the 11/750's microcode that broke an instruction in the 
>> inner loop of printf().  [...]
>
>Do tell...

The details are a litle dim after 45 years, but there was a MOVTUC
instruction in the inner loop of printf that scanned for the null at
the end of the string.  The /750 had a microcode bug that didn't
matter for the way DEC's software used it but broke the libc and
I think also the kernel version.  MOVTUC sets six registers and
we probably used one they didn't.

Bill replaced it with a few simpler instructions and the comment

	; Comet sucks

R's,
John

PS: For you young folks, Comet was DEC's internal project name for the /750.

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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-12 18:54               ` [COFF] Re: machine code translation,as " Aron Insinga
@ 2024-07-12 21:49                 ` Dave Horsfall
  0 siblings, 0 replies; 36+ messages in thread
From: Dave Horsfall @ 2024-07-12 21:49 UTC (permalink / raw)
  To: Computer Old Farts Followers

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

On Fri, 12 Jul 2024, Aron Insinga wrote:

> Re: Paul's comment about the portable I/O library in BLISS: When I first 
> encountered C, I used the Unix system calls to do I/O.  The "standard 
> I/O" library was a very important addition to C's usability.  [...]

As was the "Portable I/O Library" preceding it.

-- Dave

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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-12 17:02               ` John R Levine
@ 2024-07-12 20:52                 ` Dave Horsfall
  2024-07-12 22:03                   ` John Levine
       [not found]                 ` <CABH=_VS8z6ayJSQab0u5Cxw--hM8px8-eFGjeFCKTXxe <alpine.BSF.2.21.9999.2407131018370.6233@aneurin.horsfall.org>
  2024-07-13  9:57                 ` [COFF] Re: machine code translation, as " Ralph Corderoy
  2 siblings, 1 reply; 36+ messages in thread
From: Dave Horsfall @ 2024-07-12 20:52 UTC (permalink / raw)
  To: Computer Old Farts Followers

On Sat, 12 Jul 2024, John R Levine wrote:

> Our Vaxes ran Unix so it was all C other than a few things like tracking 
> down a bug in the 11/750's microcode that broke an instruction in the 
> inner loop of printf().  [...]

Do tell...

-- Dave

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

* [COFF] Re: machine code translation,as mental architecture models
  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
  0 siblings, 1 reply; 36+ messages in thread
From: John Levine @ 2024-07-12 20:35 UTC (permalink / raw)
  To: coff; +Cc: paul.winalski

It appears that Paul Winalski <paul.winalski@gmail.com> said:
>> DEC BLISS has the most powerful macro facility that I've ever seen in any
>programming language. ...

Take a look at PL/I. Its preprocessor lets you use a large subset of
PL/I including if, goto, and do loops and most of the string and
arithmetic operators to write functions that run at compile time and
put their results into the source file.

And don't forget the IBM macro assembler. In macros along with all of
the usual loops and local and global variables and subscripted
parameters and conditional expressions and string processing, it had
the AREAD op which read the next line from the source file and put it
in a macro-time variable, thereby letting the macro define its own
syntax from scratch if you wanted. There was also PUNCH to write a
line directly to the object file.


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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-12 16:51             ` [COFF] " Paul Winalski
  2024-07-12 17:02               ` John R Levine
  2024-07-12 17:03               ` [COFF] Re: machine code translation,as " Stuff Received
@ 2024-07-12 18:54               ` Aron Insinga
  2024-07-12 21:49                 ` Dave Horsfall
  2 siblings, 1 reply; 36+ messages in thread
From: Aron Insinga @ 2024-07-12 18:54 UTC (permalink / raw)
  To: coff

Outside of product development, the internal DECSIM multi-level logic 
simulator and its CLI and compilers were also written in BLISS.  Most of 
these started out in BLISS-36 but they were all brought together with a 
fault simulation kernel on the VAX to take advantage of the larger 
address space.

Some other internal VLSI CAD tools were also written in BLISS, although 
a few were written in more common languages.  The first (AFAIK) 
retargetable microcode assembler at DEC, MICRO, was written in MACRO-10; 
sources are on the net.  The next generation MICRO2 was written in BLISS 
and AFAIK the binary is available but the sources have sadly been lost.  
<Insert obvious plea here.>

Re: Paul's comment about the portable I/O library in BLISS: When I first 
encountered C, I used the Unix system calls to do I/O.  The "standard 
I/O" library was a very important addition to C's usability.  Similarly, 
when I first encountered BLISS-10, I had to type in a package from the 
DECUS documentation to call TOPS-10 to do I/O.  Getting the "XPORT" I/O 
(etc.) library for Common BLISS was invaluable for the CAD tools.

People have repeatedly omitted I/O from the initial design of a language 
and relegated it to a library, but even if the language is intended to 
be used for a kernel, people learning the language ("Hello, world!") or 
using the language above the kernel for utilities will need to do I/O, 
so this library should be included in the language design from the very 
beginning.  I think this lesson has been learned by now.  Its fallout is 
recognized in Stroustrup's quote of a Bell Labs axiom, "Library design 
is language design, and vice versa."

- Aron


On 7/12/24 12:51, Paul Winalski wrote:
> Outside the VAX/VMS development group, BLISS was DEC's standard 
> implementation language.  In the development organizations I worked in 
> (software development tools and compilers), we did almost zero 
> programming in assembly code.


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

* [COFF] Re: machine code translation,as mental architecture models
  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
  0 siblings, 1 reply; 36+ messages in thread
From: Paul Winalski @ 2024-07-12 18:01 UTC (permalink / raw)
  Cc: coff

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

On Fri, Jul 12, 2024 at 1:03 PM Stuff Received <stuff@riddermarkfarm.ca>
wrote:

>
> I recall one place that used macros that were hundreds of lines long.
> They were a nightmare to maintain as they were so rigid -- not the right
> way write macros.
>
> DEC BLISS has the most powerful macro facility that I've ever seen in any
programming language.  Ward Clark of DEC's Development Methods and Software
Tools Group wrote a set of macros called "Portable BLISS"  that provided a
uniform means to access basic operating system services such as sequential
file I/O and heap memory management.  There were Portable BLISS
implementations for much of the vast zoo of DEC operating systems (RSX-11,
RSTS, RT-11, TOPS-10, TOPS-20, VMS).  Some of the Portable BLISS macros
were over a thousand lines long.  They were all obscure and hard to
maintain.

Unix users will be familiar with the Obfuscated C Contest.  Within DEC
Engineering there was an Obfuscated BLISS Contest one year.  The winner was
Stan Rabinowitz, who used macros to produce a text that looked nothing like
BLISS syntax.  Stan said it would compile cleanly except for one semantic
error and challenged us to figure out what that was.  It turned out to be
an illegal uplevel reference.

-Paul W.

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

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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-12 16:51             ` [COFF] " Paul Winalski
  2024-07-12 17:02               ` John R Levine
@ 2024-07-12 17:03               ` Stuff Received
  2024-07-12 18:01                 ` Paul Winalski
  2024-07-12 18:54               ` [COFF] Re: machine code translation,as " Aron Insinga
  2 siblings, 1 reply; 36+ messages in thread
From: Stuff Received @ 2024-07-12 17:03 UTC (permalink / raw)
  To: coff

On 2024-07-12 12:51, Paul Winalski wrote (in part):
> 
> Macros were used very extensively in VAX MACRO, both for user 
> programming and in the operating system.  All of the low-level system 
> calls for user programs were implemented and documented as macros.  The 
> OS assembly code made heavy use of macros as well.

I recall one place that used macros that were hundreds of lines long. 
They were a nightmare to maintain as they were so rigid -- not the right 
way write macros.

S.


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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-12 16:51             ` [COFF] " Paul Winalski
@ 2024-07-12 17:02               ` John R Levine
  2024-07-12 20:52                 ` Dave Horsfall
                                   ` (2 more replies)
  2024-07-12 17:03               ` [COFF] Re: machine code translation,as " Stuff Received
  2024-07-12 18:54               ` [COFF] Re: machine code translation,as " Aron Insinga
  2 siblings, 3 replies; 36+ messages in thread
From: John R Levine @ 2024-07-12 17:02 UTC (permalink / raw)
  To: Paul Winalski; +Cc: COFF

On Fri, 12 Jul 2024, Paul Winalski wrote:
>> Macros were used very extensively in VAX MACRO, both for user programming
> and in the operating system.  All of the low-level system calls for user
> programs were implemented and documented as macros.  The OS assembly code
> made heavy use of macros as well.

Oh, no wonder the translator worked so well.

> Outside the VAX/VMS development group, BLISS was DEC's standard
> implementation language.  In the development organizations I worked in
> (software development tools and compilers), we did almost zero programming
> in assembly code. ...

When I was at Yale we did a fair amount of programming in BLISS-36 which 
was a pretty nice language once you wrapped your brain around some of its 
quirks like needing a dot for every memory reference.

Our Vaxes ran Unix so it was all C other than a few things like tracking 
down a bug in the 11/750's microcode that broke an instruction in the 
inner loop of printf().  I had managed to get a cross-compiling 
environment working an a PDP-11 but Bill Joy found the bug at the same 
time so we used his patched version.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

* [COFF] Re: machine code translation,as mental architecture models
  2024-07-12 16:23           ` John R Levine
@ 2024-07-12 16:51             ` Paul Winalski
  2024-07-12 17:02               ` John R Levine
                                 ` (2 more replies)
  0 siblings, 3 replies; 36+ messages in thread
From: Paul Winalski @ 2024-07-12 16:51 UTC (permalink / raw)
  To: John R Levine; +Cc: COFF

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

On Fri, Jul 12, 2024 at 12:23 PM John R Levine <johnl@taugh.com> wrote:

> On Thu, 11 Jul 2024, Paul Winalski wrote:
> > Yes, that was precisely my point, and thank you for stating it more
> clearly
> > and concisely than I did.  The VAX MACRO compiler takes in VAX assembly
> > source code, not binary VAX instructions.
>
> Does anyone know how extensively they used the macro facilities?  You can
> write much higher level stuff as macros than as single instructions, which
> makes it a lot easier to do efficient translation.  For example, on OS/360
> you'd write a GET macro to retrieve the next record (or a pointer to it)
> from a file, which was a lot easier to figure out than the control blocks
> and subroutine calls the macros expanded into.
>
> Macros were used very extensively in VAX MACRO, both for user programming
and in the operating system.  All of the low-level system calls for user
programs were implemented and documented as macros.  The OS assembly code
made heavy use of macros as well.

Outside the VAX/VMS development group, BLISS was DEC's standard
implementation language.  In the development organizations I worked in
(software development tools and compilers), we did almost zero programming
in assembly code.  The only assembly-level programming I ever did was the
innermost loop of my VAX/VMS Mandelbrot set  program and a device driver to
implement Unix-style pipes on VMS.  I did the latter in assembly code only
because there was no documented HLL interface for writing VAX/VMS device
drivers.

As Clem Cole observed, Dave Cutler hated BLISS with a passion.  All of his
work on the VAX/VMS operating system was in assembly code.  Because of this
there is still a large amount of OpenVMS still written in VAX MACRO.  But
the RMS (Record Management Services, the VMS file system user interface)
group wrote all of their code in BLISS.

After leaving the VMS group Dave went on to design and implement a common
compiler back end for VAX, the VAX Code Generator (VCG), which was the
optimizer and back end for VAX PL/I, VAX C, and VAX Ada.  The earlier
generations of VAX/VMS compilers (VAX Fortran, VAX Pascal, VAX COBOL) each
had their own back ends.  Cutler later did get HLL religion.  His real-time
operating system for the VAX, VAXeln, was written almost entirely in Pascal.

-Paul W.

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

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

end of thread, other threads:[~2024-07-15 14:09 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-07-13 22:00 [COFF] Re: machine code translation,as mental architecture models 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
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
  -- strict thread matches above, loose matches on Subject: below --
2024-07-13 11:09 [COFF] " 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
     [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

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