7

The ASM86.CMD assembler Digital Research shipped with CP/M-86 provided only code-macros, a limited type of macros for creating new instructions through a small set of specific directives. Why didn't the assembler support also traditional macros that contain Assembly language instructions?

I wonder because the CP/M-80 MAC.COM macro-assembler did support traditional macros, and the CP/M Plus Programmer's Utilities Guide extensively covered advanced uses of these macros such as special purpose languages and program control structures. The manual CP/M MAC Assembler: Language Manual and Applications Guide published in 1977 for CP/M-80 up to version 2, well before the work on CP/M-86 began, in chapter 9 Applications of Marcos already covered the same advanced uses of macros of the CP/M Plus Programmer's Utilities Guide.

So why did Digital Research leave out such a powerful feature from the later port of CP/M to the more capable 8086?

Improve this question
8
  • 5
    I don't know the answer, but two possibilities come to mind. The first is obvious -- they lacked the time and/or money to implement the feature, and then the issue never became important enough to add later to an increasingly obscure product. The second possibility is more esoteric, the possibility of "religion". The project designer might have viewed traditional assembly macros as something similar to hidden spaghetti code, with its usage too apt to obscure code intent, making "unclean" coding too likely.
    – RichF
    Commented Oct 17, 2022 at 14:50
  • 2
    Interesting question. Never thought about (but liked the CODEMACRO part for V20 programming). Maybe one has to look as well at Intel's rather ASM86, which as well included CODEMACROs plus a quite strange macro syntax, more similar to C-macros than traditional ones. One speculation might be that DR was way more focused on their HLL, seeing ASM only as a tool to bootstrap CP/M onto a new system - where CODEMACRO would be extreme handy if that was one with a new, extended x86ish CPU.
    – Raffzahn
    Commented Oct 17, 2022 at 15:21
  • Was The MAC assembler part of a separate product? This might be two differently priced products.
    – Thorbjørn Ravn Andersen
    Commented Oct 18, 2022 at 8:20
  • 1
    I didn't recall having used MAC.COM, so had a look. Based on rvbelzen.tripod.com/cpm/asuthelp.htm#mac it appears that MAC.COM was for CP/M 3 which was released in 1983 and CP/M-86 was released around 1982. Could be that the assembler was improved for the "get the marked back" CP/M-3 version?
    – Thorbjørn Ravn Andersen
    Commented Oct 18, 2022 at 9:31
  • @ThorbjørnRavnAndersen That's a good point.
    – Paolo Amoroso
    Commented Oct 18, 2022 at 19:36

1 Answer 1

Reset to default
1

Some macro assemblers have a macro construct which performs text substitution within a line, some have features that allow a line to be replaced with a sequence of lines, and some have both. The two kinds of construct are often processed using different mechanisms, and thus supporting both would require about twice as much effort as supporting either individually.

Short macros are handled by keeping a list of macro names and text substitutions, and applying the substitutions within a buffer that will often have some fixed size limit. Encountering such a macro will not affect the sequence in which the assembler reads source code.

Long macros are handled by keeping a list of macro names, file names, and the offsets of the macros within the files. Upon encountering such a macro, an assembler would need to make note of its position within the current file, switch to the reading the file containing the macro (if not already doing so), seek to the offset of the macro within the file, and then go back to processing code normally until the end-of-macro marker is found. Once that happens, the assembler must switch back to reading the earlier source file, seek back to the saved file position, and then resume processing.

Note that when using this latter approach, the amount of memory required to handle a macro would be independent of the size thereof, but processing such macros would be much slower than processing simple text substitution macros that can be kept in memory.

Improve this answer
2
  • 2
    So… how does this answer the question?
    – RonJohn
    Commented Oct 18, 2022 at 2:28
  • 1
    The more advanced macros would have required additional effort and complexity to implement, and whoever was responsible for writing the assembler probably figured it wasn't worth the effort.
    – supercat
    Commented Oct 18, 2022 at 5:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .