From: Jason Self Date: Fri, 7 Jul 2017 13:40:34 +0000 (-0700) Subject: Changing some MDL references back to Muddle X-Git-Url: https://jxself.org/git/?p=mudman.git;a=commitdiff_plain;h=df1aee4d4e5402dfc0f0ad1966db73b33b2723d3 Changing some MDL references back to Muddle --- diff --git a/md/language.md b/md/language.md index ce40369..ec7fb04 100644 --- a/md/language.md +++ b/md/language.md @@ -583,9 +583,9 @@ brackets to be closed. In other cases, they will produce errors during met. Instead, the right-hand column will be used to state just what `READ` thought the input in the left-hand column really was. - ---------------------------------------------------------------------------------- + -------------------------------------------------------------------------------- Input Explanation - --------------------------- ------------------------------------------------------ + --------------------------- ---------------------------------------------------- `ABC$` an `ATOM` of `PNAME` `ABC` `abc$` an `ATOM` of `PNAME` `abc` @@ -608,9 +608,9 @@ met. Instead, the right-hand column will be used to state just what something else (The something else will contain an `ATOM` of `PNAME` beginning `cd.`) - `12345A34$` an `ATOM` of `PNAME` `12345A35` (If the A had been an - E, the object would have been a `FLOAT`.) - ---------------------------------------------------------------------------------- + `12345A34$` an `ATOM` of `PNAME` `12345A35` (If the A had been + an E, the object would have been a `FLOAT`.) + -------------------------------------------------------------------------------- #### 2.6.3.3.  (Backslash) in ATOMs @@ -639,19 +639,19 @@ non-standard, this time not because anything is unfinished or in error, but because commenting is needed: `PRINT` doesn't do it full justice. - ------------------------------------------------------------------------------ + --------------------------------------------------------------------------- Input Explanation - ------------------------ ----------------------------------------------------- + ------------------------ -------------------------------------------------- `a\ one\ and\ a\ two$` one `ATOM`, whose `PNAME` has four spaces in it - `1234\56789$` an `ATOM` of `PNAME` `123456789`, which `PRINT`s as - `\1233456789` + `1234\56789$` an `ATOM` of `PNAME` `123456789`, which `PRINT`s + as `\1233456789` `123\ $` an `ATOM` of `PNAME` `123space`, which `PRINT`s as `\123\`, with a space on the end `\\$` an `ATOM` whose `PNAME` is a single backslash - ------------------------------------------------------------------------------ + --------------------------------------------------------------------------- Chapter 3. Built-in Functions ============================= @@ -4131,30 +4131,30 @@ used on the `CHANNEL`, and whether or not the *device* is a terminal. The following table tells which `SUBR`s can be used with which modes, where `OK` indicates an allowed use: - ------------------------------------------------------------------------------------------------------------------------------------------------- - "READ" "PRINT" "READB" "PRINTB", "PRINTO" mode / SUBRs - -------------------- --------------------- --------------------- -------------------------------------------- ----------------------------------- - OK OK `READ` `READCHR` `NEXTCHR` - `READSTRING` `FILECOPY` - `FILE-LENGTH LOAD` + ------------------------------------------------------------------------------------------------------------------------------------------- + "READ" "PRINT" "READB" "PRINTB", "PRINTO" mode / SUBRs + -------------------- -------------------- -------------------- ------------------------------------------ --------------------------------- + OK OK `READ` `READCHR` `NEXTCHR` + `READSTRING` `FILECOPY` + `FILE-LENGTH LOAD` - OK OK\* `PRINT` `PRIN1` `PRINC` `IMAGE` - `CRLF` `TERPRI` `FILECOPY` - `PRINTSTRING` `BUFOUT` `NETS` - `RENAME` + OK OK\* `PRINT` `PRIN1` `PRINC` `IMAGE` + `CRLF` `TERPRI` `FILECOPY` + `PRINTSTRING` `BUFOUT` `NETS` + `RENAME` - OK `READB` `GC-READ` + OK `READB` `GC-READ` - OK `PRINTB` `GC-DUMP` + OK `PRINTB` `GC-DUMP` - OK OK OK `ACCESS` + OK OK OK `ACCESS` - OK OK OK OK `RESET` + OK OK OK OK `RESET` - OK OK `ECHOPAIR` + OK OK `ECHOPAIR` - OK `TTYECHO` `TYI` - ------------------------------------------------------------------------------------------------------------------------------------------------- + OK `TTYECHO` `TYI` + ------------------------------------------------------------------------------------------------------------------------------------------- `*` PRINTing (or `PRIN1`ing) an `RSUBR` (chapter 19) on a `"PRINTB"` or `"PRINTO"` `CHANNEL` has special effects. @@ -4277,52 +4277,52 @@ each element, and an interpretation. The format used is the following: *element-number: type interpretation* - ---------------------------------------------------------------------------------------------------- - element-number type interpretation - -------------------------- ------------------ ------------------------------------------------------ - -1 `LIST` transcript channel(s) (see below) + ------------------------------------------------------------------------------------------------ + element-number type interpretation + ------------------------- ------------------ --------------------------------------------------- + -1 `LIST` transcript channel(s) (see below) - \* 0 varies device-dependent information + \* 0 varies device-dependent information - \* 1 `FIX` channel number (ITS) or JFN (Tenex and Tops-20), `0` - for internal or closed + \* 1 `FIX` channel number (ITS) or JFN (Tenex and Tops-20), + `0` for internal or closed - \* 2 `STRING` mode + \* 2 `STRING` mode - \* 3 `STRING` first file name argument + \* 3 `STRING` first file name argument - \* 4 `STRING` second file name argument + \* 4 `STRING` second file name argument - \* 5 `STRING` device name argument + \* 5 `STRING` device name argument - \* 6 `STRING` directory name argument + \* 6 `STRING` directory name argument - \* 7 `STRING` real first file name + \* 7 `STRING` real first file name - \* 8 `STRING` real second file name + \* 8 `STRING` real second file name - \* 9 `STRING` real device name + \* 9 `STRING` real device name - \* 10 `STRING` real directory name + \* 10 `STRING` real directory name - \* 11 `FIX` various status bits + \* 11 `FIX` various status bits - \* 12 `FIX` PDP-10 instruction used to do one I/O operation + \* 12 `FIX` PDP-10 instruction used to do one I/O operation - 13 `FIX` number of characters per line of output + 13 `FIX` number of characters per line of output - 14 `FIX` current character position on a line + 14 `FIX` current character position on a line - 15 `FIX` number of lines per page + 15 `FIX` number of lines per page - 16 `FIX` current line number on a page + 16 `FIX` current line number on a page - 17 `FIX` access pointer for file-oriented devices + 17 `FIX` access pointer for file-oriented devices - 18 `FIX` radix for `FIX` conversion + 18 `FIX` radix for `FIX` conversion - 19 `FIX` sink for an internal `CHANNEL` - ---------------------------------------------------------------------------------------------------- + 19 `FIX` sink for an internal `CHANNEL` + ------------------------------------------------------------------------------------------------ N.B.: The elements of a `CHANNEL` below number 1 are usually invisible but are obtainable via ` fix>`, for some appropriate @@ -7022,13 +7022,13 @@ Chapter 19. Compiled Programs ---------------------- `RSUBR`s ("relocatable subroutines") are machine-language programs -written to run in the MDL environment. They are usually produced by -the MDL assembler (often from output produced by the compiler) +written to run in the Muddle environment. They are usually produced by +the Muddle assembler (often from output produced by the compiler) although this is not necessary. All `RSUBR`s have two components: the "reference vector" and the "code vector". In some cases the code vector is in pure storage. There is also a set of "fixups" associated with every `RSUBR`, although it may not be available in the running -MDL. +Muddle. 19.2. The Reference Vector -------------------------- @@ -7115,8 +7115,8 @@ an offset into the block of code where this `RSUBR` starts. The where *name* names the entry in the user's pure-`RSUBR` table, and *offset* is the offset. (Obviously, `PCODE` is also the name of a `SUBR`, which generates a pure code vector.) Pure `RSUBR`s may also -move around, but only by being included in MDL's page map at different -places. Once again `M` can be used exactly as before to do +move around, but only by being included in Muddle's page map at +different places. Once again `M` can be used exactly as before to do location-independent address referencing. Individual pure code vectors can be "unmapped" (marked as being not in primary storage but in their original pure-code disk files) if the space in storage allocated for @@ -7130,7 +7130,7 @@ produces objects of `TYPE` `LOCR` instead of `LOCD`. ======================= In order to handle user `NEWTYPE`s reasonably, the internal `TYPE` -codes for them have to be able to be different from one MDL run to +codes for them have to be able to be different from one Muddle run to another. Therefore, references to the `TYPE` codes must be in the reference vector rather than the code vector. To help handle this problem, two `TYPE`s exist, `TYPE-C` ("type code") and `TYPE-W` ("type @@ -7163,9 +7163,9 @@ same `TYPEPRIM`, but they all have different `PRIMTYPE-C`s. `CHTYPE`s its argument to an `RSUBR`, after checking it for legality. -`RSUBR` is rarely called other than in the MDL Assembler (Lebling, +`RSUBR` is rarely called other than in the Muddle Assembler (Lebling, 1979). It can be used if changes must be made to an `RSUBR` that are -prohibited by MDL's built-in safety mechanisms. For example, if the +prohibited by Muddle's built-in safety mechanisms. For example, if the `GVAL` of *name* is an `RSUBR`: >$ @@ -7224,34 +7224,34 @@ delete them.) The pure code itself resides (in the ITS and Tops-20 versions) in a special large file that contains all currently-used pure code, or (in the Tenex version) in a file in a special disk directory with first name the same as the *name* argument to `PCODE` -for the `RSUBR`. The pure-code file is page-mapped directly into MDL -storage in read-only mode. It can be unmapped when the pure storage -must be reclaimed, and it can be mapped at a different storage address -when pure storage must be compacted. There is also a "fixup" file (see -below) or portion of a file associated with the `FBIN` to round out -the triad. - -An initial MDL can have pure `RSUBR`s in it that were "loaded" during -the initialization procedure. The files are not page-mapped in until -they are actually needed. The "loading" has other side effects, such -as the creation of `OBLIST`s (chapter 15). Exactly what is pre-loaded -is outside the scope of this document. +for the `RSUBR`. The pure-code file is page-mapped directly into +Muddle storage in read-only mode. It can be unmapped when the pure +storage must be reclaimed, and it can be mapped at a different storage +address when pure storage must be compacted. There is also a "fixup" +file (see below) or portion of a file associated with the `FBIN` to +round out the triad. + +An initial Muddle can have pure `RSUBR`s in it that were "loaded" +during the initialization procedure. The files are not page-mapped in +until they are actually needed. The "loading" has other side effects, +such as the creation of `OBLIST`s (chapter 15). Exactly what is +pre-loaded is outside the scope of this document. 19.9. Fixups ------------ The purpose of "fixups" is to correct references in the `RSUBR` to -parts of the interpreter that change from one release of MDL to the +parts of the interpreter that change from one release of Muddle to the next. The reason the fixups contain a release number is so that they can be completely ignored when an `RSUBR` is loaded into the same -release of MDL as that from which it was last written out. +release of Muddle as that from which it was last written out. There are three forms of fixups, corresponding to the three kinds of `RSUBR` files. ASCII `RSUBR`s, found in `BINARY` files, have ASCII fixups. The fixups are contained in a `LIST` that has the following format: - (MDL-release:fix + (Muddle-release:fix name:atom value:fix (use:fix use:fix ...) name:atom value:fix (use:fix use:fix ...) ...) @@ -7270,8 +7270,8 @@ the assembler and compiler make the same association when they first create an `RSUBR`, so that it can be written out with its fixups. In the case of pure `RSUBR`s (`FBIN` files), things are a little -different. If a pure-code file exists for this release of MDL, it is -used immediately, and the fixups are completely ignored. If a +different. If a pure-code file exists for this release of Muddle, it +is used immediately, and the fixups are completely ignored. If a pure-code file for this release doesn't exist, the fixup file is used to create a new copy of the file from an old one, and also a new version of the fixup file is created to go with the new pure-code @@ -7280,22 +7280,22 @@ file. This all goes on automatically behind the user's back. Chapter 20. Coroutines ====================== -This chapter purports to explain the coroutine primitives of MDL. It -does make some attempt to explain coroutines as such, but only as +This chapter purports to explain the coroutine primitives of Muddle. +It does make some attempt to explain coroutines as such, but only as required to specify the primitives. If you are unfamiliar with the basic concepts, confusion will probably reign. -A coroutine in MDL is implemented by an object of `TYPE` `PROCESS`. In -this manual, this use of the word "process" is distinguished by a +A coroutine in Muddle is implemented by an object of `TYPE` `PROCESS`. +In this manual, this use of the word "process" is distinguished by a capitalization from its normal use of denoting an operating-system process (which various systems call a process, job, fork, task, etc.). -MDL's built-in coroutine primitives do not include a "time-sharing +Muddle's built-in coroutine primitives do not include a "time-sharing system". Only one `PROCESS` is ever running at a time, and control is passed back and forth between `PROCESS`es on a coroutine-like basis. The primitives are sufficient, however, to allow the writing of a -"time-sharing system" **in MDL**, with the additional use of the MDL -interrupt primitives. This has, in fact, been done. +"time-sharing system" **in Muddle**, with the additional use of the +Muddle interrupt primitives. This has, in fact, been done. 20.1. PROCESS (the TYPE) ------------------------ @@ -7476,8 +7476,8 @@ off. $ 8 -Just as a note, by taking advantage of MDL's order of evaluation, SUM3 -could be have been written as: +Just as a note, by taking advantage of Muddle's order of evaluation, +SUM3 could be have been written as: finds the `IHEADER` associated with *name* and proceeds as above, returning the `IHEADER`. *which* must be given only for certain -*names*, as for `EVENT`. Caution: if you ``, MDL -will become deaf. +*names*, as for `EVENT`. Caution: if you ``, +Muddle will become deaf. @@ -7803,7 +7805,7 @@ that way, since they are self-referencing. Instead they `PRINT` as #type most-interesting-component The contents of `IHEADER`s and `HANDLER`s can be changed by `PUT`, and -the new values will then determine the behavior of MDL. +the new values will then determine the behavior of Muddle. Before describing the elements of these `TYPE`s in detail, here are a picture and a Pattern, both purporting to show how they look: @@ -7927,7 +7929,7 @@ the interrupt occurrence is **queued** -- that is, the fact that it occurred is saved away for processing when the interrupt level becomes low enough. -When the processing of an interrupt's actions is completed, MDL +When the processing of an interrupt's actions is completed, Muddle usually (1) "acts as if" the previously-existing interrupt level is restored, and processing continues on what was left off (perhaps for no time duration); and (2) "acts as if" any queued interrupt @@ -7977,7 +7979,7 @@ is restored. 21.8. Specific Interrupts ------------------------- -Descriptions of the characteristics of particular "built-in" MDL +Descriptions of the characteristics of particular "built-in" Muddle interrupts follow. Each is named by its `STRING` name. Expect this list to be incomplete yesterday. @@ -7985,10 +7987,10 @@ list to be incomplete yesterday. serves duty in several ways. These different ways will be described in several different sections. All ways are concerned with characters or machine words that arrive or depart at unpredictable times, because -MDL is communicating with a person or another processor. Each `"CHAR"` -`IHEADER` has a `CHANNEL` for the element that names the interrupt, -and the mode of the `CHANNEL` tells what kinds of `"CHAR"` interrupts -occur to be handled through that `IHEADER`. +Muddle is communicating with a person or another processor. Each +`"CHAR"` `IHEADER` has a `CHANNEL` for the element that names the +interrupt, and the mode of the `CHANNEL` tells what kinds of `"CHAR"` +interrupts occur to be handled through that `IHEADER`. 1. If the `CHANNEL` is for `INPUT`, "CHAR" occurs every time an "interesting" character (see below) is received from the @@ -8024,7 +8026,7 @@ returns a `STRING` containing the characters that currently interrupt. Initially, only \^G, \^S, and \^O interrupt. -An initial MDL already has `"CHAR"` enabled on `,INCHAN` with a +An initial Muddle already has `"CHAR"` enabled on `,INCHAN` with a priority 8 (eight), the `SUBR` `QUITTER` for a handler to run in `#PROCESS 0` (the running `PROCESS`); this is how `^G` and `^S` are processed. In addition, every time a new `CHANNEL` @@ -8032,8 +8034,8 @@ is `OPEN`ed in `"READ"` mode to a terminal, a similar `IHEADER` and `HANDLER` are associated with that new `CHANNEL` automatically. These automatically-generated `IHEADER`s and `HANDLER`s use the standard machinery, and they can be `DISABLE`d or `OFF`ed at will. **However**, -the `IHEADER` for `,INCHAN` should not be `OFF`ed: MDL knows that `$` -is typed only by an interrupt! +the `IHEADER` for `,INCHAN` should not be `OFF`ed: Muddle knows that +`$` is typed only by an interrupt! Example: the following causes the given message to be printed out whenever a `^Y` is typed on `.INCHAN`: @@ -8155,7 +8157,7 @@ is, an occurrence indicates that somewhere, somebody did a `READ`, which started waiting (which will also be the `PROCESS` in which the handler runs, if no specific one is in the `HANDLER`). -Example: the following will cause MDL to acquire a `*` prompting +Example: the following will cause Muddle to acquire a `*` prompting character. ) 5> @@ -8170,7 +8172,7 @@ call (which see) is satisfied. A handler takes one argument: the ### 21.8.9. "READ" and "WRITE" `"READ"` and `"WRITE"` are associated with read or write references to -MDL objects. These interrupts are often called "monitors", and +Muddle objects. These interrupts are often called "monitors", and enabling the interrupt is often called "monitoring" the associated object. A "read reference" to an `ATOM`'s local value includes applying `BOUND?` or `ASSIGNED?` to the `ATOM`; similarly for a global @@ -8220,7 +8222,7 @@ a reprieve). ### 21.8.11. "ERROR" -In an effort to simplify error handling by programs, MDL has a +In an effort to simplify error handling by programs, Muddle has a facility allowing errors to be handled like interrupts. `SETG`ing `ERROR` to a user function is a distasteful method, not safe if any bugs are around. An `"ERROR"` interrupt wants a handler that takes any @@ -8242,7 +8244,7 @@ the `"ERROR"` interrupt, real `ERROR` will be called, because ### 21.8.13. "INFERIOR" -`"INFERIOR"` occurs when an inferior ITS process interrupts the MDL +`"INFERIOR"` occurs when an inferior ITS process interrupts the Muddle process. It is not available in the Tenex and Tops-20 versions. A handler takes one argument: A `FIX` between `0` and `7` inclusive, telling which inferior process is interrupting. @@ -8251,12 +8253,12 @@ telling which inferior process is interrupting. These are not available in the Tenex and Tops-20 versions. -`"RUNT"`, if enabled, occurs **once**, *N* seconds of MDL running time -(CPU time) after calling ``, which returns -its argument. A handler takes no arguments. If `RUNTIMER` is called -with no argument, it returns a `FIX`, the number of run-time seconds -left until the interrupt occurs, or `#FALSE ()` if the interrupt is -not going to occur. +`"RUNT"`, if enabled, occurs **once**, *N* seconds of Muddle running +time (CPU time) after calling ``, which +returns its argument. A handler takes no arguments. If `RUNTIMER` is +called with no argument, it returns a `FIX`, the number of run-time +seconds left until the interrupt occurs, or `#FALSE ()` if the +interrupt is not going to occur. `"REALT"`, if enabled, occurs **every** *N* seconds of real-world time after calling ``, which returns its @@ -8268,21 +8270,21 @@ argument, or `#FALSE ()` if `REALTIMER` has not been called. ### 21.8.15. "Dangerous" Interrupts -`"MPV"` ("memory protection violation") occurs if MDL tries to refer -to a storage address not in its address space. `"PURE"` occurs if MDL -tries to alter read-only storage. `"ILOPR"` occurs if MDL executes and -illegal instruction ("operator"). `"PARITY"` occurs if the CPU detects -a parity error in MDL's address space. All of these require a handler -that takes one argument: the address (`TYPE` `WORD`) following the -instruction that was being executed at the time. +`"MPV"` ("memory protection violation") occurs if Muddle tries to +refer to a storage address not in its address space. `"PURE"` occurs +if Muddle tries to alter read-only storage. `"ILOPR"` occurs if Muddle +executes and illegal instruction ("operator"). `"PARITY"` occurs if +the CPU detects a parity error in Muddle's address space. All of these +require a handler that takes one argument: the address (`TYPE` `WORD`) +following the instruction that was being executed at the time. -`"IOC"` occurs if MDL tries to deal illegally with an I/O channel. A -handler must take two arguments: a three-element `FALSE` like one that -`OPEN` might return, and the `CHANNEL` that got the error. +`"IOC"` occurs if Muddle tries to deal illegally with an I/O channel. +A handler must take two arguments: a three-element `FALSE` like one +that `OPEN` might return, and the `CHANNEL` that got the error. Ideally these interrupts should never occur. In fact, in the Tenex and Tops-20 versions, these interrupts always go to the superior operating -system process instead of to MDL. In the ITS version, if and when a +system process instead of to Muddle. In the ITS version, if and when a "dangerous" interrupt does occur: - If no `IHEADER` is associated with the interrupt, then the @@ -8298,8 +8300,8 @@ system process instead of to MDL. In the ITS version, if and when a ----------------------------- If the interrupt name given to `EVENT` or `ON` is **not** one of the -standard predefined interrupts of MDL, they will gleefully create an -`ATOM` in `` and an associated `IHEADER` anyway, making +standard predefined interrupts of Muddle, they will gleefully create +an `ATOM` in `` and an associated `IHEADER` anyway, making the assumption that you are setting up a "program-defined" interrupt. Program-defined interrupts are made to occur by applying the `SUBR` @@ -8316,7 +8318,7 @@ and queueing rules hold, so that even if `INTERRUPT` returns `T`, it is possible that nothing "really happened" (yet). `INTERRUPT` can also be used to cause "artificial" occurrences of -standard predefined MDL interrupts. +standard predefined Muddle interrupts. Making a program-defined interrupt occur is similar to calling a handler directly, but there are differences. The value returned by a @@ -8368,13 +8370,13 @@ Chapter 22. Storage Management ============================== The reason this chapter comes so late in this document is that, except -for special cases, MDL programs have their storage needs handled +for special cases, Muddle programs have their storage needs handled automatically. There is usually no need even to consider storage management, except as it affects efficiency (chapter 24). This chapter gives some explanation of why this is so, and covers those special means by which a program can assume control of storage management. -The MDL address space is divided into five parts, which are usually +The Muddle address space is divided into five parts, which are usually called 1. movable garbage-collected space, @@ -8384,8 +8386,8 @@ called 5. internal storage. Internal storage occupies both the highest and lowest addresses in the -address space, and its size never changes as MDL executes. The other -spaces can vary in size according to the needs of the executing +address space, and its size never changes as Muddle executes. The +other spaces can vary in size according to the needs of the executing program. Generally the interpreter allocates a contiguous set of addresses for each space, and each space gradually fills up as new objects are created and as disk files are mapped in. The action taken @@ -8394,10 +8396,10 @@ when space becomes full varies, as discussed below. 22.1. Movable Garbage-collected Storage --------------------------------------- -Most storage used explicitly by MDL programs is obtained from a pool -of free storage managed by a "garbage collector". Storage is obtained -from this pool by the `SUBR`s which construct objects. When a `SUBR` -finds that the pool of available storage is exhausted, it +Most storage used explicitly by Muddle programs is obtained from a +pool of free storage managed by a "garbage collector". Storage is +obtained from this pool by the `SUBR`s which construct objects. When a +`SUBR` finds that the pool of available storage is exhausted, it automatically calls the garbage collector. The garbage collector has two algorithms available to it: the @@ -8420,8 +8422,8 @@ object-construction `SUBR`s can find them and re-use their storage. If the request for more storage still cannot be satisfied from reclaimed storage, the garbage collector will attempt to obtain more -total storage from the operating system under which MDL runs. (Also, -if there is a gross superfluity of storage space, the garbage +total storage from the operating system under which Muddle runs. +(Also, if there is a gross superfluity of storage space, the garbage collector will politely return some storage to the operating system.) Only when the total system resources are exhausted will you finally lose. @@ -8433,9 +8435,9 @@ used in `PROCESS`es for functional application. ### 22.1.1. Stacks and Other Internal Vectors -Control stacks are used in MDL to control the changes in environment -caused by calling and binding. Each active `PROCESS` has its own -control stack. On this stack are stored `LVAL`s for `ATOM`s; +Control stacks are used in Muddle to control the changes in +environment caused by calling and binding. Each active `PROCESS` has +its own control stack. On this stack are stored `LVAL`s for `ATOM`s; `PRIMTYPE` `TUPLE`s, which are otherwise like `VECTOR`s; `PRIMTYPE` `FRAME`s, which are generated by calling Subroutines; and `ACTIVATION`s, which are generated by calling `FUNCTION`s with named @@ -8460,14 +8462,14 @@ section can overflow, of course. The top-level-`LVAL` section is below the other one, so that a top-level `LVAL` will be found only if the `ATOM` is not currently bound elsewhere, namely in the other section. -MDL also has an internal stack, used for calling and temporary storage -within the interpreter and compiled programs. It too is stored like a -`VECTOR` and can overflow. There are other internal vectors that can -overflow: the "global vector" holds pairs ("slots") of `ATOM`s and -corresponding `GVAL`s ("globally bound" or `GBOUND?` means that the -`ATOM` in question is in this vector, whether or not it currently has -a global value), and the "`TYPE` vector" holds `TYPE` names -(predefined and `NEWTYPE`s) and how they are to be treated. +Muddle also has an internal stack, used for calling and temporary +storage within the interpreter and compiled programs. It too is stored +like a `VECTOR` and can overflow. There are other internal vectors +that can overflow: the "global vector" holds pairs ("slots") of +`ATOM`s and corresponding `GVAL`s ("globally bound" or `GBOUND?` means +that the `ATOM` in question is in this vector, whether or not it +currently has a global value), and the "`TYPE` vector" holds `TYPE` +names (predefined and `NEWTYPE`s) and how they are to be treated. 22.2. Immovable Storage ----------------------- @@ -8486,21 +8488,21 @@ garbage-collected space. `FREEZE` returns the copy `CHTYPE`d to its An object of `PRIMTYPE` `STORAGE` is really a frozen `UVECTOR` whose `UTYPE` is of `PRIMTYPE` `WORD`, but it is always pointed to by -something internal to MDL and thus is never garbage-collectible. The -use of `FREEZE` is always preferable, except when for historical +something internal to Muddle and thus is never garbage-collectible. +The use of `FREEZE` is always preferable, except when for historical reasons a `STORAGE` is necessary. 22.3. Other Storage ------------------- User pure/page space serves two purposes. First, when a user program -`PURIFY`s (see below) MDL objects, they are copied into this space. +`PURIFY`s (see below) Muddle objects, they are copied into this space. Second, so-called hand-crafted `RSUBR`s (assembled but not compiled) can call on the interpreter to map pages of disk files into this space for arbitrary purposes. Pure-`RSUBR` mapping space is used by the interpreter to dynamically -map pages of pure compiled programs into and out of the MDL address +map pages of pure compiled programs into and out of the Muddle address space. Pure code can refer to impure storage through the "transfer vector", another internal vector. This space is the most vulnerable to being compressed in size by the long-term growth of other spaces. @@ -8509,7 +8511,7 @@ Internal storage has both pure and impure parts. The interpreter program itself is pure and sharable, while impure storage is used for internal pointers, counters, and flags, for example, pointers to the boundaries of other spaces. In the pure part of this space are most of -the `ATOM`s in an initial MDL, along with their `OBLIST` buckets +the `ATOM`s in an initial Muddle, along with their `OBLIST` buckets (`LIST`s) and `GVAL` slots (a pure extension of the global vector), where possible. A `SET` or `SETG` of a pure `ATOM` automatically impurifies the `ATOM` and as much of its `OBLIST` bucket as needs to @@ -8519,7 +8521,7 @@ be impure. --------------------------------- When either of the garbage-collected spaces (movable or immovable) -becomes full, MDL goes through the following procedure: +becomes full, Muddle goes through the following procedure: 1. A `"DIVERT-AGC"` interrupt occurs if the garbage collection can be deferred temporarily by shifting boundaries between storage spaces @@ -8528,7 +8530,7 @@ becomes full, MDL goes through the following procedure: 2. The garbage collector begins execution. The "copying" algorithm creates an inferior operating-system process (named `AGC` in the ITS version) whose address space is used to hold the new copies of - non-garbage objects. MDL accesses the inferior's address space + non-garbage objects. Muddle accesses the inferior's address space through two pages ("frontier" and "window") in its internal space that are shared with the inferior. If the garbage collection occurred because movable garbage-collected space was exhausted, @@ -8552,8 +8554,8 @@ becomes full, MDL goes through the following procedure: 5. Finally, the "mark-sweep" algorithm sweeps through the storage space, adding unmarked objects to the internal free lists for later re-use. The "copying" algorithm maps the inferior process's - address space into MDL's own, replacing old garbagey with the new - compact storage, and the inferior process is destroyed. + address space into Muddle's own, replacing old garbagey with the + new compact storage, and the inferior process is destroyed. 22.5 GC ------- @@ -8650,7 +8652,7 @@ to particular program requirements. fills the *uvector* with information about the state of storage of -MDL. The argument should be a `UVECTOR` of length 27 and `UTYPE` +Muddle. The argument should be a `UVECTOR` of length 27 and `UTYPE` `FIX`. If `BLOAT-STAT` does not get an argument, it will provide its own `UVECTOR`. The information returned is as follows: the first 8 elements indicate the number of garbage collections that are @@ -8670,7 +8672,7 @@ about certain areas of storage. In detail: 9. number of words of movable storage 10. number of words of movable storage used since last `BLOAT-STAT` 11. maximum number of words of movable storage ever existing -12. number of words of movable storage used since MDL began running +12. number of words of movable storage used since Muddle began running 13. maximum size of control stack 14. number of words on control stack in use 15. maximum size of control stack(s) ever reached @@ -8716,7 +8718,7 @@ of `GIN` and `GOUT`. Two `SUBR`s, described next, use only part of the garbage-collector algorithm, in order to find all pointers to an object. `GC-DUMP` and `GC-READ`, as their names imply, also use part in order to translate -between MDL objects and binary representation thereof. +between Muddle objects and binary representation thereof. ### 22.9.1. SUBSTITUTE @@ -8745,20 +8747,20 @@ can live on the control stack or be of `PRIMTYPE` `PROCESS` or `LOCD` or `ASOC`. Sharing between operating-system processes actually occurs after a `SAVE`, if and when the `SAVE` file is `RESTORE`d. -Chapter 23. MDL as a System Process -=================================== +Chapter 23. Muddle as a System Process +====================================== -This chapter treats MDL considered as executing in an operating-system -process, and interactions between MDL and other operating-system -processes. See also section 21.8.13. +This chapter treats Muddle considered as executing in an +operating-system process, and interactions between Muddle and other +operating-system processes. See also section 21.8.13. 23.1. TIME ---------- `TIME` takes any number of arguments, which are evaluated but ignored, -and returns a `FLOAT` giving the number of seconds of CPU time the MDL -process has used so far. `TIME` is often used in machine-level -debugging to examine the values of its arguments, by having MDL's +and returns a `FLOAT` giving the number of seconds of CPU time the +Muddle process has used so far. `TIME` is often used in machine-level +debugging to examine the values of its arguments, by having Muddle's superior process (say, DDT) plant a breakpoint in the code for `TIME`. 23.2. Names @@ -8766,29 +8768,29 @@ superior process (say, DDT) plant a breakpoint in the code for `TIME`. -returns a `STRING` which is the "user name" of MDL's process. This is -the "uname" process-control variable in the ITS version and the +returns a `STRING` which is the "user name" of Muddle's process. This +is the "uname" process-control variable in the ITS version and the logged-in directory in the Tenex and Tops-20 versions. -returns a `STRING` which is the "intended user name" of MDL's process. -This is the "xuname" process-control variable in the ITS version and -identical to `` in the Tenex and Tops-20 versions. +returns a `STRING` which is the "intended user name" of Muddle's +process. This is the "xuname" process-control variable in the ITS +version and identical to `` in the Tenex and Tops-20 versions. -returns a `STRING` which is the "job name" of MDL's process. This is -the "jname" process-control variable in the ITS version and the +returns a `STRING` which is the "job name" of Muddle's process. This +is the "jname" process-control variable in the ITS version and the `SETNM` name in the Tenex and Tops-20 versions. The characters belong to the "sixbit" or "printing" subset of ASCII, namely those between `` and `` inclusive. -returns a `STRING` which is the "intended job name" of MDL's process. -This is the "xjname" process-control variable in the ITS version and -identical to `` in the Tenex and Tops-20 versions. +returns a `STRING` which is the "intended job name" of Muddle's +process. This is the "xjname" process-control variable in the ITS +version and identical to `` in the Tenex and Tops-20 versions. 23.3. Exits ----------- @@ -8796,27 +8798,27 @@ identical to `` in the Tenex and Tops-20 versions. attempts to log out the process in which it is executed. It will -succeed only if the MDL is the top-level process, that is, it is +succeed only if the Muddle is the top-level process, that is, it is running disowned or as a daemon. If it succeeds, it of course never returns. If it does not, it returns `#FALSE ()`. -causes MDL to stop running, in an orderly manner. In the ITS version, -it is equivalent to a `.LOGOUT 1` instruction. In the Tenex and -Tops-20 versions, it is equivalent to a control-C signal, and control -passes to the superior process. +causes Muddle to stop running, in an orderly manner. In the ITS +version, it is equivalent to a `.LOGOUT 1` instruction. In the Tenex +and Tops-20 versions, it is equivalent to a control-C signal, and +control passes to the superior process. ("value return") seldom returns. It passes control back up the process -tree to the superior of MDL, passing its argument as a message to that -superior. If it does return, the value is `#FALSE ()`. If the argument -is a `STRING`, it is passed to the superior as a command to be -executed, via `.VALUE` in the ITS version and `RSCAN` in the Tops-20 -version. If the argument is a `FIX`, it is passed to the superior as -the "effective address" of a `.BREAK 16`, instruction in the ITS -version and ignored in other versions. +tree to the superior of Muddle, passing its argument as a message to +that superior. If it does return, the value is `#FALSE ()`. If the +argument is a `STRING`, it is passed to the superior as a command to +be executed, via `.VALUE` in the ITS version and `RSCAN` in the +Tops-20 version. If the argument is a `FIX`, it is passed to the +superior as the "effective address" of a `.BREAK 16`, instruction in +the ITS version and ignored in other versions. 23.4. Inter-process Communication --------------------------------- @@ -8825,8 +8827,8 @@ All of the `SUBR`s in this section are available only in the ITS version. The IPC ("inter-process communication") device is treated as an I/O -device by ITS but not explicitly so by MDL: that is, it is never -`OPEN`ed. It allows MDL to communicate with other ITS processes by +device by ITS but not explicitly so by Muddle: that is, it is never +`OPEN`ed. It allows Muddle to communicate with other ITS processes by means of sending and receiving messages. A process identifies itself as sender or recipient of a message with an ordered pair of "sixbit" `STRING`s, which are often but not always `` and ``. A @@ -8850,9 +8852,9 @@ accepts the message. ### 23.4.2. The "IPC" Interrupt -When your MDL process receives an IPC message, `"IPC"` occurs (chapter -21). A handler is called with either four or six arguments gleaned -from the message. *body*, *type*, *othern1*, and *othern2* are +When your Muddle process receives an IPC message, `"IPC"` occurs +(chapter 21). A handler is called with either four or six arguments +gleaned from the message. *body*, *type*, *othern1*, and *othern2* are supplied only if they are not this process's `` and ``. There is a built-in `HANDLER` for the `"IPC"` interrupt, with a @@ -8874,7 +8876,7 @@ causes listening on the IPC device as *myname1* *myname2*. If no arguments are provided, listening is on `` ``. When a message arrives, `"IPC"` occurs. -MDL is initially listening as `` `` with the built-in +Muddle is initially listening as `` `` with the built-in `HANDLER` set up on the `"IPC"` interrupt with a priority of `1`. ### 23.4.5. DEMSIG @@ -8891,9 +8893,9 @@ Chapter 24. Efficiency and Tastefulness 24.1. Efficiency ---------------- -Actually, you make MDL programs efficient by thinking hard about what -they really make the interpreter **do**, and making them do less. Some -guidelines, in order of decreasing expense: +Actually, you make Muddle programs efficient by thinking hard about +what they really make the interpreter **do**, and making them do less. +Some guidelines, in order of decreasing expense: 1. Free storage is expensive. 2. Calling functions is expensive. @@ -8903,7 +8905,7 @@ Explanation: 1. Unnecessary use of free storage (creating needless `LIST`s, `VECTOR`s, `UVECTOR`s, etc.) will cause the garbage collector to - run more often. This is **expensive!** A fairly large MDL (for + run more often. This is **expensive!** A fairly large Muddle (for example, 60,000 36-bit words) can take ten seconds of PDP-10 CPU time for a garbage collection. Be especially wary of constructions like `(0)`. Every time that is evaluated, it creates a new @@ -9115,10 +9117,10 @@ be `MANIFEST` for the compiler's benefit. Thirdly, to establish the 24.6. Tables ------------ -There are several ways in MDL to store a table, that is, a collection -of (names and) values that will be searched. Unsurprisingly, choosing -the best way is often dictated by the size of the table and/or the -nature of the (names and) values. +There are several ways in Muddle to store a table, that is, a +collection of (names and) values that will be searched. +Unsurprisingly, choosing the best way is often dictated by the size of +the table and/or the nature of the (names and) values. For a small table, the names and values can be put in (separate) structures -- the choice of `LIST` or array being determined by @@ -9128,7 +9130,7 @@ larger, and if the elements are completely orderable, a (uniform) vector can be used, kept sorted, and searched with a binary search. For a large table, where reasonably efficient searches are required, a -hashing scheme is probably best. Two methods are available in MDL: +hashing scheme is probably best. Two methods are available in Muddle: associations and `OBLIST`s. In the first method, `PUTPROP` and `GETPROP` are used, which are very