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`
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
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
=============================
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.
*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 `<NTH <TOP channel> fix>`, for some appropriate
----------------------
`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
--------------------------
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
=======================
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
<RSUBR [code name decl ref ref ...]>
`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`:
<SET FIXIT <CHTYPE ,name VECTOR>>$
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 ...)
...)
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
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)
------------------------
<RESUME 2 ,SUMUP>$
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:
<DEFINE SUM3 (A)
<REPEAT ((S .A))
### 20.7.2. MAIN
-When you initially start up MDL, the `PROCESS` in which you are
+When you initially start up Muddle, the `PROCESS` in which you are
running is slightly "special" in these two ways:
1. Any attempt to cause it become `DEAD` will be met with an error.
Chapter 21. Interrupts
======================
-The MDL interrupt handling facilities provide the ability to say the
-following: whenever "this event" occurs, stop whatever is being done
-at the time and perform "this action"; when "this action" is finished,
-continue with whatever was originally being done. "This event" can be
-things like the typing of a character at a terminal, a time interval
-ending, a `PROCESS` becoming blocked, or a program-defined and
--generated "event". "This action" is the application of a specified
-`APPLICABLE` object to arguments provided by the MDL interrupt system.
-The sets of events and actions can be changed in extremely flexible
-ways, which accounts for both the variety of `SUBR`s and arguments,
-and the rich interweaving of the topics in this chapter. Interrupt
-handling is a kind of parallel processing: a program can be divided
-into a "main-level" part and one or more interrupt handlers that
-execute only when conditions are ripe.
+The Muddle interrupt handling facilities provide the ability to say
+the following: whenever "this event" occurs, stop whatever is being
+done at the time and perform "this action"; when "this action" is
+finished, continue with whatever was originally being done. "This
+event" can be things like the typing of a character at a terminal, a
+time interval ending, a `PROCESS` becoming blocked, or a
+program-defined and -generated "event". "This action" is the
+application of a specified `APPLICABLE` object to arguments provided
+by the Muddle interrupt system. The sets of events and actions can be
+changed in extremely flexible ways, which accounts for both the
+variety of `SUBR`s and arguments, and the rich interweaving of the
+topics in this chapter. Interrupt handling is a kind of parallel
+processing: a program can be divided into a "main-level" part and one
+or more interrupt handlers that execute only when conditions are ripe.
21.1. Definitions of Terms
--------------------------
-An **interrupt** is not an object in MDL, but rather a class of
+An **interrupt** is not an object in Muddle, but rather a class of
events, for example, "ticks" of a clock, garbage collections, the
typing of a character at a terminal, etc.
An interrupt is said to **occur** when one of the events in its class
takes place.
-An **external** interrupt is one whose occurrences are signaled to MDL
-by the operating system, for example, "ticks" of a clock. An
-**internal** interrupt is one whose occurrences are detected by MDL
-itself, for example, garbage collections. MDL can arrange for the
+An **external** interrupt is one whose occurrences are signaled to
+Muddle by the operating system, for example, "ticks" of a clock. An
+**internal** interrupt is one whose occurrences are detected by Muddle
+itself, for example, garbage collections. Muddle can arrange for the
operating system to not signal occurrences of an external interrupt to
-it; then, as far as MDL is concerned, that interrupt does not occur.
+it; then, as far as Muddle is concerned, that interrupt does not
+occur.
Each interrupt has a **name** which is either a `STRING` (for example,
`"GC"`, `"CHAR"`, `"WRITE"`) or an `ATOM` with that `PNAME` in a
high-priority interrupt has been handled.
In each `IHEADER` is a (possibly empty) list of `HANDLER`s. (This list
-is not a MDL `LIST`.) Each `HANDLER` corresponds to an action to
+is not a Muddle `LIST`.) Each `HANDLER` corresponds to an action to
perform. There are `SUBR`s for creating a `HANDLER`, adding it to an
`IHEADER`'s list, and later removing it.
- The argument must be a `LOCATIVE` if and only if *name* is
`"READ"` (or `READ!-INTERRUPTS`) or `"WRITE"` (or
`WRITE!-INTERRUPTS`). In this case it specifies an object to be
- "monitored" for usage by (interpreted) MDL programs (section
+ "monitored" for usage by (interpreted) Muddle programs (section
21.8.9).
-If the interrupt is external, MDL arranges for the operating system to
-signal its occurrences.
+If the interrupt is external, Muddle arranges for the operating system
+to signal its occurrences.
21.3. HANDLER (the SUBR)
------------------------
removes the association between *iheader* and the name of its
interrupt, and then disables *iheader* and returns it. (An error
-occurs if there is no association.) If the interrupt is external, MDL
-arranges for the operating system not to signal its occurrences.
+occurs if there is no association.) If the interrupt is external,
+Muddle arranges for the operating system not to signal its
+occurrences.
<OFF name which>
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 `<OFF "CHAR" ,INCHAN>`, MDL
-will become deaf.
+*names*, as for `EVENT`. Caution: if you `<OFF "CHAR" ,INCHAN>`,
+Muddle will become deaf.
<OFF handler>
#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:
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
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.
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
Initially, only <kbd>\^G</kbd>, <kbd>\^S</kbd>, and <kbd>\^O</kbd>
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 <kbd>`^G`</kbd> and
<kbd>`^S`</kbd> are processed. In addition, every time a new `CHANNEL`
`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 <kbd>`^Y`</kbd> is typed on `.INCHAN`:
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.
<ON "BLOCKED" #FUNCTION ((IGNORE) <PRINC !\*>) 5>
### 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
### 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
### 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.
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 `<RUNTIMER N:fix-or-float>`, 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 `<RUNTIMER N:fix-or-float>`, 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 `<REALTIMER N:fix-or-float>`, which returns its
### 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
-----------------------------
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 `<INTERRUPTS>` and an associated `IHEADER` anyway, making
+standard predefined interrupts of Muddle, they will gleefully create
+an `ATOM` in `<INTERRUPTS>` 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`
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
==============================
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,
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
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
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.
### 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
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
-----------------------
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.
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
---------------------------------
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
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,
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
-------
<BLOAT-STAT length-27:uvector>
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
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
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
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
<UNAME>
-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.
<XUNAME>
-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 `<UNAME>` 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 `<UNAME>` in the Tenex and Tops-20 versions.
<JNAME>
-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
`<ASCII *40*>` and `<ASCII *137*>` inclusive.
<XJNAME>
-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 `<JNAME>` 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 `<JNAME>` in the Tenex and Tops-20 versions.
23.3. Exits
-----------
<LOGOUT>
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 ()`.
<QUIT>
-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.
<VALRET string-or-fix>
("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
---------------------------------
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 `<UNAME>` and `<JNAME>`. A
### 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 `<UNAME>` and `<JNAME>`.
There is a built-in `HANDLER` for the `"IPC"` interrupt, with a
arguments are provided, listening is on `<UNAME>` `<JNAME>`. When a
message arrives, `"IPC"` occurs.
-MDL is initially listening as `<UNAME>` `<JNAME>` with the built-in
+Muddle is initially listening as `<UNAME>` `<JNAME>` with the built-in
`HANDLER` set up on the `"IPC"` interrupt with a priority of `1`.
### 23.4.5. DEMSIG
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.
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
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
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
projects / mudman.git / commitdiff