text:
Transistor–transistor logic

Transistor–transistor logic (TTL) is a logic family built from bipolar junction transistors. Its name signifies that transistors perform both the logic function (the first "transistor") and the amplifying function (the second "transistor"), as opposed to earlier resistor–transistor logic (RTL) and diode–transistor logic (DTL).

TTL integrated circuits (ICs) were widely used in applications such as computers, industrial controls, test equipment and instrumentation, consumer electronics, and synthesizers.

After their introduction in integrated circuit form in 1963 by Sylvania Electric Products, TTL integrated circuits were manufactured by several semiconductor companies. The 7400 series by Texas Instruments became particularly popular. TTL manufacturers offered a wide range of logic gates, flip-flops, counters, and other circuits. Variations of the original TTL circuit design offered higher speed or lower power dissipation to allow design optimization. TTL devices were originally made in ceramic and plastic dual in-line package(s) and in flat-pack form. Some TTL chips are now also made in surface-mount technology packages.

TTL became the foundation of computers and other digital electronics. Even after Very-Large-Scale Integration (VLSI) CMOS integrated circuit microprocessors made multiple-chip processors obsolete, TTL devices still found extensive use as glue logic interfacing between more densely integrated components.

History

TTL was invented in 1961 by James L. Buie of TRW, which declared it "particularly suited to the newly developing integrated circuit design technology." The original name for TTL was transistor-coupled transistor logic (TCTL). The first commercial integrated-circuit TTL devices were manufactured by Sylvania in 1963, called the Sylvania Universal High-Level Logic family (SUHL). The Sylvania parts were used in the controls of the Phoenix missile. TTL became popular with electronic systems designers after Texas Instruments introduced the 5400 series of ICs, with military temperature range, in 1964 and the later 7400 series,  specified over a narrower range and with inexpensive plastic packages, in 1966.

The Texas Instruments 7400 family became an industry standard. Compatible parts were made by Motorola, AMD, Fairchild, Intel, Intersil, Signetics, Mullard, Siemens, SGS-Thomson, Rifa, National Semiconductor, and many other companies, even in the Eastern Bloc (Soviet Union, GDR, Poland, Czechoslovakia, Hungary, Romania — for details see 7400 series). Not only did others make compatible TTL parts, but compatible parts were made using many other circuit technologies as well. At least one manufacturer, IBM, produced non-compatible TTL circuits for its own use; IBM used the technology in the IBM System/38, IBM 4300, and IBM 3081.

The term "TTL" is applied to many successive generations of bipolar logic, with gradual improvements in speed and power consumption over about two decades. The most recently introduced family 74Fxx is still sold today (as of 2019), and was widely used into the late 90s. 74AS/ALS Advanced Schottky was introduced in 1985. As of 2008, Texas Instruments continues to supply the more general-purpose chips in numerous obsolete technology families, albeit at increased prices. Typically, TTL chips integrate no more than a few hundred transistors each. Functions within a single package generally range from a few logic gates to a microprocessor bit-slice. TTL also became important because its low cost made digital techniques economically practical for tasks previously done by analog methods.

The Kenbak-1, ancestor of the first personal computers, used TTL for its CPU instead of a microprocessor chip, which was not available in 1971. The Datapoint 2200 from 1970 used TTL components for its CPU and was the basis for the 8008 and later the x86 instruction set. The 1973 Xerox Alto and 1981 Star workstations, which introduced the graphical user interface, used TTL circuits integrated at the level of arithmetic logic units (ALUs) and bitslices, respectively. Most computers used TTL-compatible "glue logic" between larger chips well into the 1990s. Until the advent of programmable logic, discrete bipolar logic was used to prototype and emulate microarchitectures under development.

Fundamental TTL gate

TTL inputs are the emitters of bipolar transistors. In the case of NAND inputs, the inputs are the emitters of multiple-emitter transistors, functionally equivalent to multiple transistors where the bases and collectors are tied together. The output is buffered by a common emitter amplifier.

Inputs both logical ones. When all the inputs are held at high voltage, the base–emitter junctions of the multiple-emitter transistor are reverse-biased. Unlike DTL, a small “collector” current (approximately 10 μA) is drawn by each of the inputs. This is because the transistor is in reverse-active mode. An approximately constant current flows from the positive rail, through the resistor and into the base of the multiple emitter transistor. This current passes through the base–emitter junction of the output transistor, allowing it to conduct and pulling the output voltage low (logical zero).

An input logical zero. Note that the base–collector junction of the multiple-emitter transistor and the base–emitter junction of the output transistor are in series between the bottom of the resistor and ground. If one input voltage becomes zero, the corresponding base–emitter junction of the multiple-emitter transistor is in parallel with these two junctions. A phenomenon called current steering means that when two voltage-stable elements with different threshold voltages are connected in parallel, the current flows through the path with the smaller threshold voltage. That is, current flows out of this input and into the zero (low) voltage source. As a result, no current flows through the base of the output transistor, causing it to stop conducting and the output voltage becomes high (logical one). During the transition the input transistor is briefly in its active region; so it draws a large current away from the base of the output transistor and thus quickly discharges its base. This is a critical advantage of TTL over DTL that speeds up the transition over a diode input structure.

The main disadvantage of TTL with a simple output stage is the relatively high output resistance at output logical "1" that is completely determined by the output collector resistor. It limits the number of inputs that can be connected (the fanout). Some advantage of the simple output stage is the high voltage level (up to VCC) of the output logical "1" when the output is not loaded.

Open collector wired logic
A common variation omits the collector resistor of the output transistor, making an open-collector output. This allows the designer to fabricate wired logic by connecting the open-collector outputs of several logic gates together and providing a single external pull-up resistor. If any of the logic gates becomes logic low (transistor conducting), the combined output will be low. Examples of this type of gate are the 7401 and 7403 series. Open-collector outputs of some gates have a higher maximum voltage, such as 15 V for the 7426, useful when driving non-TTL loads.

TTL with a "totem-pole" output stage

To solve the problem with the high output resistance of the simple output stage the second schematic adds to this a "totem-pole" ("push–pull") output. It consists of the two n-p-n transistors V3 and V4, the "lifting" diode V5 and the current-limiting resistor R3 (see the figure on the right). It is driven by applying the same current steering idea as above.

When V2 is "off", V4 is "off" as well and V3 operates in active region as a voltage follower producing high output voltage (logical "1").

When V2 is "on", it activates V4, driving low voltage (logical "0") to the output. Again there is a current-steering effect: the series combination of V2's C-E junction and V4's B-E junction is in parallel with the series of V3 B-E, V5's anode-cathode junction, and V4 C-E. The second series combination has the higher threshold voltage, so no current flows through it, i.e. V3 base current is deprived. Transistor V3 turns "off" and it does not impact on the output.

In the middle of the transition, the resistor R3 limits the current flowing directly through the series connected transistor V3, diode V5 and transistor V4 that are all conducting. It also limits the output current in the case of output logical "1" and short connection to the ground. The strength of the gate may be increased without proportionally affecting the power consumption by removing the pull-up and pull-down resistors from the output stage.

The main advantage of TTL with a "totem-pole" output stage is the low output resistance at output logical "1". It is determined by the upper output transistor V3 operating in active region as an emitter follower. The resistor R3 does not increase the output resistance since it is connected in the V3 collector and its influence is compensated by the negative feedback. A disadvantage of the "totem-pole" output stage is the decreased voltage level (no more than 3.5 V) of the output logical "1" (even if the output is unloaded). The reasons for this reduction are the voltage drops across the V3 base–emitter and V5 anode–cathode junctions.

Interfacing considerations
Like DTL, TTL is a current-sinking logic since a current must be drawn from inputs to bring them to a logic 0 voltage level. The driving stage must absorb up to 1.6 mA from a standard TTL input while not allowing the voltage to rise to more than 0.4 volts. The output stage of the most common TTL gates is specified to function correctly when driving up to 10 standard input stages (a fanout of 10). TTL inputs are sometimes simply left floating to provide a logical "1", though this usage is not recommended.

Standard TTL circuits operate with a 5-volt power supply. A TTL input signal is defined as "low" when between 0 V and 0.8 V with respect to the ground terminal, and "high" when between 2 V and VCC (5 V), and if a voltage signal ranging between 0.8 V and 2.0 V is sent into the input of a TTL gate, there is no certain response from the gate and therefore it is considered "uncertain" (precise logic levels vary slightly between sub-types and by temperature). TTL outputs are typically restricted to narrower limits of between 0.0 V and 0.4 V for a "low" and between 2.4 V and VCC for a "high", providing at least 0.4 V of noise immunity. Standardization of the TTL levels is so ubiquitous that complex circuit boards often contain TTL chips made by many different manufacturers selected for availability and cost, compatibility being assured. Two circuit board units off the same assembly line on different successive days or weeks might have a different mix of brands of chips in the same positions on the board; repair is possible with chips manufactured years later than original components. Within usefully broad limits, logic gates can be treated as ideal Boolean devices without concern for electrical limitations. The 0.4 V noise margins are adequate because of the low output impedance of the driver stage, that is, a large amount of noise power superimposed on the output is needed to drive an input into an undefined region.

In some cases (e.g., when the output of a TTL logic gate needs to be used for driving the input of a CMOS gate), the voltage level of the "totem-pole" output stage at output logical "1" can be increased closer to VCC by connecting an external resistor between the V4 collector and the positive rail. It pulls up the V5 cathode and cuts-off the diode. However, this technique actually converts the sophisticated "totem-pole" output into a simple output stage having significant output resistance when driving a high level (determined by the external resistor).

Packaging
Like most integrated circuits of the period 1963–1990, commercial TTL devices are usually packaged in dual in-line packages (DIPs), usually with 14 to 24 pins, for through-hole or socket mounting. Epoxy plastic (PDIP) packages were often used for commercial temperature range components, while ceramic packages (CDIP) were used for military temperature range parts.

Beam-lead chip dies without packages were made for assembly into larger arrays as hybrid integrated circuits. Parts for military and aerospace applications were packaged in flatpacks, a form of surface-mount package, with leads suitable for welding or soldering to printed circuit boards. Today, many TTL-compatible devices are available in surface-mount packages, which are available in a wider array of types than through-hole packages.

TTL is particularly well suited to bipolar integrated circuits because additional inputs to a gate merely required additional emitters on a shared base region of the input transistor. If individually packaged transistors were used, the cost of all the transistors would discourage one from using such an input structure. But in an integrated circuit, the additional emitters for extra gate inputs add only a small area.

At least one computer manufacturer, IBM, built its own flip chip integrated circuits with TTL; these chips were mounted on ceramic multi-chip modules.

Comparison with other logic families
TTL devices consume substantially more power than equivalent CMOS devices at rest, but power consumption does not increase with clock speed as rapidly as for CMOS devices. Compared to contemporary ECL circuits, TTL uses less power and has easier design rules but is substantially slower. Designers can combine ECL and TTL devices in the same system to achieve best overall performance and economy, but level-shifting devices are required between the two logic families. TTL is less sensitive to damage from electrostatic discharge than early CMOS devices.

Due to the output structure of TTL devices, the output impedance is asymmetrical between the high and low state, making them unsuitable for driving transmission lines. This drawback is usually overcome by buffering the outputs with special line-driver devices where signals need to be sent through cables. ECL, by virtue of its symmetric low-impedance output structure, does not have this drawback.

The TTL "totem-pole" output structure often has a momentary overlap when both the upper and lower transistors are conducting, resulting in a substantial pulse of current drawn from the power supply. These pulses can couple in unexpected ways between multiple integrated circuit packages, resulting in reduced noise margin and lower performance. TTL systems usually have a decoupling capacitor for every one or two IC packages, so that a current pulse from one TTL chip does not momentarily reduce the supply voltage to another.

Since the mid 1980s, several manufacturers supply CMOS logic equivalents with TTL-compatible input and output levels, usually bearing part numbers similar to the equivalent TTL component and with the same pinouts. For example, the 74HCT00 series provides many drop-in replacements for bipolar 7400 series parts, but uses CMOS technology.

Sub-types
Successive generations of technology produced compatible parts with improved power consumption or switching speed, or both. Although vendors uniformly marketed these various product lines as TTL with Schottky diodes, some of the underlying circuits, such as used in the LS family, could rather be considered DTL.

Variations of and successors to the basic TTL family, which has a typical gate propagation delay of 10ns and a power dissipation of 10 mW per gate, for a power–delay product (PDP) or switching energy of about 100 pJ, include:

 * Low-power TTL (L), which traded switching speed (33ns) for a reduction in power consumption (1 mW) (now essentially replaced by CMOS logic)
 * High-speed TTL (H), with faster switching than standard TTL (6ns) but significantly higher power dissipation (22 mW)
 * Schottky TTL (S), introduced in 1969, which used Schottky diode clamps at gate inputs to prevent charge storage and improve switching time. These gates operated more quickly (3ns) but had higher power dissipation (19 mW)
 * Low-power Schottky TTL (LS) – used the higher resistance values of low-power TTL and the Schottky diodes to provide a good combination of speed (9.5 ns) and reduced power consumption (2 mW), and PDP of about 20 pJ. Probably the most common type of TTL, these were used as glue logic in microcomputers, essentially replacing the former H, L, and S sub-families.
 * Fast (F) and Advanced-Schottky (AS) variants of LS from Fairchild and TI, respectively, circa 1985, with "Miller-killer" circuits to speed up the low-to-high transition. These families achieved PDPs of 10 pJ and 4 pJ, respectively, the lowest of all the TTL families.
 * Low-voltage TTL (LVTTL) for 3.3-volt power supplies and memory interfacing.

Most manufacturers offer commercial and extended temperature ranges: for example Texas Instruments 7400 series parts are rated from 0 to 70 °C, and 5400 series devices over the military-specification temperature range of −55 to +125 °C.

Special quality levels and high-reliability parts are available for military and aerospace applications.

Radiation-hardened devices (for example from the SNJ54 series) are offered for space applications.

Applications
Before the advent of VLSI devices, TTL integrated circuits were a standard method of construction for the processors of minicomputer and midrange mainframe computers, such as the DEC VAX and Data General Eclipse; however some computer families were based on proprietary components (e.g. Fairchild CTL) while supercomputers and high-end mainframes used Emitter-coupled logic. They were also used for equipment such as machine tool numerical controls, printers and video display terminals, and as microprocessors became more functional for "glue logic" applications, such as address decoders and bus drivers, which tie together the function blocks realized in VLSI elements. The Gigatron TTL is a more recent (2018) example of a processor built entirely with TTL integrated circuits.

Analog applications
While originally designed to handle logic-level digital signals, a TTL inverter can be biased as an analog amplifier. Connecting a resistor between the output and the input biases the TTL element as a negative feedback amplifier. Such amplifiers may be useful to convert analog signals to the digital domain but would not ordinarily be used where analog amplification is the primary purpose. TTL inverters can also be used in crystal oscillators where their analog amplification ability is significant.

A TTL gate may operate inadvertently as an analog amplifier if the input is connected to a slowly changing input signal that traverses the unspecified region from 0.8 V to 2 V. The output can be erratic when the input is in this range. A slowly changing input like this can also cause excess power dissipation in the output circuit. If such an analog input must be used, there are specialized TTL parts with Schmitt trigger inputs available that will reliably convert the analog input to a digital value, effectively operating as a one bit A to D converter.

Serial signaling
TTL serial refers to single-ended serial communication using raw transistor voltage levels: "low" for 0 and "high" for 1. UART over TTL serial is a common debug interface for embedded devices. Handheld devices such as graphing calculators and NMEA 0183-compliant GPS receivers and fishfinders also commonly use UART with TTL. TTL serial is only a de facto standard: there are no strict electrical guidelines. Driver–receiver modules interface between TTL and longer-range serial standards: one example is the MAX232, which converts from and to RS-232.

Differential TTL is TTL serial carried over a differential pair with complement levels, providing much enhanced noise tolerance. Both RS-422 and RS-485 signals can be produced using TTL levels.

CcTalk is based on TTL voltage levels.

title: Transistor–transistor logic


text:
TTL

TTL may refer to:

Photography

 * Through-the-lens metering, a camera feature
 * Zenit TTL, an SLR film camera named for its TTL metering capability

Technology

 * Time to live, a computer data lifespan-limiting mechanism
 * Transistor–transistor logic, a family of integrated-circuit digital logic
 * Differential TTL, a serial signaling standard based on TTL
 * Turtle (syntax), a computer data format used in semantic web technologies

Other uses

 * Taiwan Tobacco and Liquor, a state-owned manufacturer
 * "TTL (Time to Love)", a single by South Korean girl group T-ara and boy band Supernova

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: TTL


text:
Instruction set architecture

In computer science, an instruction set architecture (ISA) is an abstract model that generally defines how software controls the CPU in a computer or a family of computers. A device or program that executes instructions described by that ISA, such as a central processing unit (CPU), is called an implementation of that ISA.

In general, an ISA defines the supported instructions, data types, registers, the hardware support for managing main memory, fundamental features (such as the memory consistency, addressing modes, virtual memory), and the input/output model of implementations of the ISA.

An ISA specifies the behavior of machine code running on implementations of that ISA in a fashion that does not depend on the characteristics of that implementation, providing binary compatibility between implementations. This enables multiple implementations of an ISA that differ in characteristics such as performance, physical size, and monetary cost (among other things), but that are capable of running the same machine code, so that a lower-performance, lower-cost machine can be replaced with a higher-cost, higher-performance machine without having to replace software. It also enables the evolution of the microarchitectures of the implementations of that ISA, so that a newer, higher-performance implementation of an ISA can run software that runs on previous generations of implementations.

If an operating system maintains a standard and compatible application binary interface (ABI) for a particular ISA, machine code will run on future implementations of that ISA and operating system. However, if an ISA supports running multiple operating systems, it does not guarantee that machine code for one operating system will run on another operating system, unless the first operating system supports running machine code built for the other operating system.

An ISA can be extended by adding instructions or other capabilities, or adding support for larger addresses and data values; an implementation of the extended ISA will still be able to execute machine code for versions of the ISA without those extensions. Machine code using those extensions will only run on implementations that support those extensions.

The binary compatibility that they provide makes ISAs one of the most fundamental abstractions in computing.

Overview
An instruction set architecture is distinguished from a microarchitecture, which is the set of processor design techniques used, in a particular processor, to implement the instruction set. Processors with different microarchitectures can share a common instruction set. For example, the Intel Pentium and the AMD Athlon implement nearly identical versions of the x86 instruction set, but they have radically different internal designs.

The concept of an architecture, distinct from the design of a specific machine, was developed by Fred Brooks at IBM during the design phase of System/360. "Prior to NPL [System/360], the company's computer designers had been free to honor cost objectives not only by selecting technologies but also by fashioning functional and architectural refinements. The SPREAD compatibility objective, in contrast, postulated a single architecture for a series of five processors spanning a wide range of cost and performance. None of the five engineering design teams could count on being able to bring about adjustments in architectural specifications as a way of easing difficulties in achieving cost and performance objectives."

Some virtual machines that support bytecode as their ISA such as Smalltalk, the Java virtual machine, and Microsoft's Common Language Runtime, implement this by translating the bytecode for commonly used code paths into native machine code. In addition, these virtual machines execute less frequently used code paths by interpretation (see: Just-in-time compilation). Transmeta implemented the x86 instruction set atop VLIW processors in this fashion.

Classification of ISAs
An ISA may be classified in a number of different ways. A common classification is by architectural complexity. A complex instruction set computer (CISC) has many specialized instructions, some of which may only be rarely used in practical programs. A reduced instruction set computer (RISC) simplifies the processor by efficiently implementing only the instructions that are frequently used in programs, while the less common operations are implemented as subroutines, having their resulting additional processor execution time offset by infrequent use.

Other types include very long instruction word (VLIW) architectures, and the closely related and explicitly parallel instruction computing (EPIC) architectures. These architectures seek to exploit instruction-level parallelism with less hardware than RISC and CISC by making the compiler responsible for instruction issue and scheduling.

Architectures with even less complexity have been studied, such as the minimal instruction set computer (MISC) and one-instruction set computer (OISC). These are theoretically important types, but have not been commercialized.

Instructions
Machine language is built up from discrete statements or instructions. On the processing architecture, a given instruction may specify:
 * opcode (the instruction to be performed) e.g. add, copy, test
 * any explicit operands:
 * registers
 * literal/constant values
 * addressing modes used to access memory

More complex operations are built up by combining these simple instructions, which are executed sequentially, or as otherwise directed by control flow instructions.

Instruction types
Examples of operations common to many instruction sets include:

Data handling and memory operations

 * Set a register to a fixed constant value.
 * Copy data from a memory location or a register to a memory location or a register (a machine instruction is often called move; however, the term is misleading). They are used to store the contents of a register, the contents of another memory location or the result of a computation, or to retrieve stored data to perform a computation on it later. They are often called load and store operations.
 * Read and write data from hardware devices.

Arithmetic and logic operations

 * Add, subtract, multiply, or divide the values of two registers, placing the result in a register, possibly setting one or more condition codes in a status register.
 * increment, decrement in some ISAs, saving operand fetch in trivial cases.
 * Perform bitwise operations, e.g., taking the conjunction and disjunction of corresponding bits in a pair of registers, taking the negation of each bit in a register.
 * Compare two values in registers (for example, to see if one is less, or if they are equal).
 * Floating-point instructions for arithmetic on floating-point numbers.

Control flow operations

 * Branch to another location in the program and execute instructions there.
 * Conditionally branch to another location if a certain condition holds.
 * Indirectly branch to another location.
 * Call another block of code, while saving the location of the next instruction as a point to return to.

Coprocessor instructions

 * Load/store data to and from a coprocessor or exchanging with CPU registers.
 * Perform coprocessor operations.

Complex instructions
Processors may include "complex" instructions in their instruction set. A single "complex" instruction does something that may take many instructions on other computers. Such instructions are typified by instructions that take multiple steps, control multiple functional units, or otherwise appear on a larger scale than the bulk of simple instructions implemented by the given processor. Some examples of "complex" instructions include:

 * transferring multiple registers to or from memory (especially the stack) at once
 * moving large blocks of memory (e.g. string copy or DMA transfer)
 * complicated integer and floating-point arithmetic (e.g. square root, or transcendental functions such as logarithm, sine, cosine, etc.)
 * SIMD instructions, a single instruction performing an operation on many homogeneous values in parallel, possibly in dedicated SIMD registers
 * performing an atomic test-and-set instruction or other read-modify-write atomic instruction
 * instructions that perform ALU operations with an operand from memory rather than a register

Complex instructions are more common in CISC instruction sets than in RISC instruction sets, but RISC instruction sets may include them as well. RISC instruction sets generally do not include ALU operations with memory operands, or instructions to move large blocks of memory, but most RISC instruction sets include SIMD or vector instructions that perform the same arithmetic operation on multiple pieces of data at the same time. SIMD instructions have the ability of manipulating large vectors and matrices in minimal time. SIMD instructions allow easy parallelization of algorithms commonly involved in sound, image, and video processing. Various SIMD implementations have been brought to market under trade names such as MMX, 3DNow!, and AltiVec.

Instruction encoding

On traditional architectures, an instruction includes an opcode that specifies the operation to perform, such as add contents of memory to register—and zero or more operand specifiers, which may specify registers, memory locations, or literal data. The operand specifiers may have addressing modes determining their meaning or may be in fixed fields. In very long instruction word (VLIW) architectures, which include many microcode architectures, multiple simultaneous opcodes and operands are specified in a single instruction.

Some exotic instruction sets do not have an opcode field, such as transport triggered architectures (TTA), only operand(s).

Most stack machines have "0-operand" instruction sets in which arithmetic and logical operations lack any operand specifier fields; only instructions that push operands onto the evaluation stack or that pop operands from the stack into variables have operand specifiers. The instruction set carries out most ALU actions with postfix (reverse Polish notation) operations that work only on the expression stack, not on data registers or arbitrary main memory cells. This can be very convenient for compiling high-level languages, because most arithmetic expressions can be easily translated into postfix notation.

Conditional instructions often have a predicate field—a few bits that encode the specific condition to cause an operation to be performed rather than not performed. For example, a conditional branch instruction will transfer control if the condition is true, so that execution proceeds to a different part of the program, and not transfer control if the condition is false, so that execution continues sequentially. Some instruction sets also have conditional moves, so that the move will be executed, and the data stored in the target location, if the condition is true, and not executed, and the target location not modified, if the condition is false. Similarly, IBM z/Architecture has a conditional store instruction. A few instruction sets include a predicate field in every instruction; this is called branch predication.

Number of operands
Instruction sets may be categorized by the maximum number of operands explicitly specified in instructions.

(In the examples that follow, a, b, and c are (direct or calculated) addresses referring to memory cells, while reg1 and so on refer to machine registers.)

C = A+B

 * 0-operand (zero-address machines), so called stack machines: All arithmetic operations take place using the top one or two positions on the stack:,  ,  ,.
 * needs four instructions. For stack machines, the terms "0-operand" and "zero-address" apply to arithmetic instructions, but not to all instructions, as 1-operand push and pop instructions are used to access memory.
 * 1-operand (one-address machines), so called accumulator machines, include early computers and many small microcontrollers: most instructions specify a single right operand (that is, constant, a register, or a memory location), with the implicit accumulator as the left operand (and the destination if there is one):,  ,.
 * needs three instructions.
 * 2-operand — many CISC and RISC machines fall under this category:
 * CISC —  to C; then   to C.
 * needs two instructions. This effectively 'stores' the result without an explicit store instruction.
 * CISC — Often machines are limited to one memory operand per instruction: ;  ;  ; This requires a load/store pair for any memory movement regardless of whether the   result is an augmentation stored to a different place, as in , or the same memory location:.
 * needs three instructions.
 * RISC — Requiring explicit memory loads, the instructions would be: ;  ;  ;.
 * needs four instructions.
 * 3-operand, allowing better reuse of data:
 * CISC — It becomes either a single instruction:
 * needs one instruction.
 * CISC — Or, on machines limited to two memory operands per instruction, ;  ;
 * needs two instructions.
 * RISC — arithmetic instructions use registers only, so explicit 2-operand load/store instructions are needed: ;  ;  ;  ;
 * needs four instructions.
 * Unlike 2-operand or 1-operand, this leaves all three values a, b, and c in registers available for further reuse.
 * more operands—some CISC machines permit a variety of addressing modes that allow more than 3 operands (registers or memory accesses), such as the VAX "POLY" polynomial evaluation instruction.

Due to the large number of bits needed to encode the three registers of a 3-operand instruction, RISC architectures that have 16-bit instructions are invariably 2-operand designs, such as the Atmel AVR, TI MSP430, and some versions of ARM Thumb. RISC architectures that have 32-bit instructions are usually 3-operand designs, such as the ARM, AVR32, MIPS, Power ISA, and SPARC architectures.

Each instruction specifies some number of operands (registers, memory locations, or immediate values) explicitly. Some instructions give one or both operands implicitly, such as by being stored on top of the stack or in an implicit register. If some of the operands are given implicitly, fewer operands need be specified in the instruction. When a "destination operand" explicitly specifies the destination, an additional operand must be supplied. Consequently, the number of operands encoded in an instruction may differ from the mathematically necessary number of arguments for a logical or arithmetic operation (the arity). Operands are either encoded in the "opcode" representation of the instruction, or else are given as values or addresses following the opcode.

Register pressure
Register pressure measures the availability of free registers at any point in time during the program execution. Register pressure is high when a large number of the available registers are in use; thus, the higher the register pressure, the more often the register contents must be spilled into memory. Increasing the number of registers in an architecture decreases register pressure but increases the cost.

While embedded instruction sets such as Thumb suffer from extremely high register pressure because they have small register sets, general-purpose RISC ISAs like MIPS and Alpha enjoy low register pressure. CISC ISAs like x86-64 offer low register pressure despite having smaller register sets. This is due to the many addressing modes and optimizations (such as sub-register addressing, memory operands in ALU instructions, absolute addressing, PC-relative addressing, and register-to-register spills) that CISC ISAs offer.

Instruction length
The size or length of an instruction varies widely, from as little as four bits in some microcontrollers to many hundreds of bits in some VLIW systems. Processors used in personal computers, mainframes, and supercomputers have minimum instruction sizes between 8 and 64 bits. The longest possible instruction on x86 is 15 bytes (120 bits). Within an instruction set, different instructions may have different lengths. In some architectures, notably most reduced instruction set computers (RISC), instructions are a fixed length, typically corresponding with that architecture's word size. In other architectures, instructions have variable length, typically integral multiples of a byte or a halfword. Some, such as the ARM with Thumb-extension have mixed variable encoding, that is two fixed, usually 32-bit and 16-bit encodings, where instructions cannot be mixed freely but must be switched between on a branch (or exception boundary in ARMv8).

Fixed-length instructions are less complicated to handle than variable-length instructions for several reasons (not having to check whether an instruction straddles a cache line or virtual memory page boundary, for instance), and are therefore somewhat easier to optimize for speed.

Code density
In early 1960s computers, main memory was expensive and very limited, even on mainframes. Minimizing the size of a program to make sure it would fit in the limited memory was often central. Thus the size of the instructions needed to perform a particular task, the code density, was an important characteristic of any instruction set. It remained important on the initially-tiny memories of minicomputers and then microprocessors. Density remains important today, for smartphone applications, applications downloaded into browsers over slow Internet connections, and in ROMs for embedded applications. A more general advantage of increased density is improved effectiveness of caches and instruction prefetch.

Computers with high code density often have complex instructions for procedure entry, parameterized returns, loops, etc. (therefore retroactively named Complex Instruction Set Computers, CISC). However, more typical, or frequent, "CISC" instructions merely combine a basic ALU operation, such as "add", with the access of one or more operands in memory (using addressing modes such as direct, indirect, indexed, etc.). Certain architectures may allow two or three operands (including the result) directly in memory or may be able to perform functions such as automatic pointer increment, etc. Software-implemented instruction sets may have even more complex and powerful instructions.

Reduced instruction-set computers, RISC, were first widely implemented during a period of rapidly growing memory subsystems. They sacrifice code density to simplify implementation circuitry, and try to increase performance via higher clock frequencies and more registers. A single RISC instruction typically performs only a single operation, such as an "add" of registers or a "load" from a memory location into a register. A RISC instruction set normally has a fixed instruction length, whereas a typical CISC instruction set has instructions of widely varying length. However, as RISC computers normally require more and often longer instructions to implement a given task, they inherently make less optimal use of bus bandwidth and cache memories.

Certain embedded RISC ISAs like Thumb and AVR32 typically exhibit very high density owing to a technique called code compression. This technique packs two 16-bit instructions into one 32-bit word, which is then unpacked at the decode stage and executed as two instructions.

Minimal instruction set computers (MISC) are commonly a form of stack machine, where there are few separate instructions (8–32), so that multiple instructions can be fit into a single machine word. These types of cores often take little silicon to implement, so they can be easily realized in an FPGA or in a multi-core form. The code density of MISC is similar to the code density of RISC; the increased instruction density is offset by requiring more of the primitive instructions to do a task.

There has been research into executable compression as a mechanism for improving code density. The mathematics of Kolmogorov complexity describes the challenges and limits of this.

In practice, code density is also dependent on the compiler. Most optimizing compilers have options that control whether to optimize code generation for execution speed or for code density. For instance GCC has the option -Os to optimize for small machine code size, and -O3 to optimize for execution speed at the cost of larger machine code.

Representation
The instructions constituting a program are rarely specified using their internal, numeric form (machine code); they may be specified by programmers using an assembly language or, more commonly, may be generated from high-level programming languages by compilers.

Design
The design of instruction sets is a complex issue. There were two stages in history for the microprocessor. The first was the CISC (Complex Instruction Set Computer), which had many different instructions. In the 1970s, however, places like IBM did research and found that many instructions in the set could be eliminated. The result was the RISC (Reduced Instruction Set Computer), an architecture that uses a smaller set of instructions. A simpler instruction set may offer the potential for higher speeds, reduced processor size, and reduced power consumption. However, a more complex set may optimize common operations, improve memory and cache efficiency, or simplify programming.

Some instruction set designers reserve one or more opcodes for some kind of system call or software interrupt. For example, MOS Technology 6502 uses 00H, Zilog Z80 uses the eight codes C7,CF,D7,DF,E7,EF,F7,FFH while Motorola 68000 use codes in the range A000..AFFFH.

Fast virtual machines are much easier to implement if an instruction set meets the Popek and Goldberg virtualization requirements.

The NOP slide used in immunity-aware programming is much easier to implement if the "unprogrammed" state of the memory is interpreted as a NOP.

On systems with multiple processors, non-blocking synchronization algorithms are much easier to implement if the instruction set includes support for something such as "fetch-and-add", "load-link/store-conditional" (LL/SC), or "atomic compare-and-swap".

Instruction set implementation
A given instruction set can be implemented in a variety of ways. All ways of implementing a particular instruction set provide the same programming model, and all implementations of that instruction set are able to run the same executables. The various ways of implementing an instruction set give different tradeoffs between cost, performance, power consumption, size, etc.

When designing the microarchitecture of a processor, engineers use blocks of "hard-wired" electronic circuitry (often designed separately) such as adders, multiplexers, counters, registers, ALUs, etc. Some kind of register transfer language is then often used to describe the decoding and sequencing of each instruction of an ISA using this physical microarchitecture. There are two basic ways to build a control unit to implement this description (although many designs use middle ways or compromises):

 * 1) Some computer designs "hardwire" the complete instruction set decoding and sequencing (just like the rest of the microarchitecture).
 * 2) Other designs employ microcode routines or tables (or both) to do this, using ROMs or writable RAMs (writable control store), PLAs, or both.

Some microcoded CPU designs with a writable control store use it to allow the instruction set to be changed (for example, the Rekursiv processor and the Imsys Cjip).

CPUs designed for reconfigurable computing may use field-programmable gate arrays (FPGAs).

An ISA can also be emulated in software by an interpreter. Naturally, due to the interpretation overhead, this is slower than directly running programs on the emulated hardware, unless the hardware running the emulator is an order of magnitude faster. Today, it is common practice for vendors of new ISAs or microarchitectures to make software emulators available to software developers before the hardware implementation is ready.

Often the details of the implementation have a strong influence on the particular instructions selected for the instruction set. For example, many implementations of the instruction pipeline only allow a single memory load or memory store per instruction, leading to a load–store architecture (RISC). For another example, some early ways of implementing the instruction pipeline led to a delay slot.

The demands of high-speed digital signal processing have pushed in the opposite direction—forcing instructions to be implemented in a particular way. For example, to perform digital filters fast enough, the MAC instruction in a typical digital signal processor (DSP) must use a kind of Harvard architecture that can fetch an instruction and two data words simultaneously, and it requires a single-cycle multiply–accumulate multiplier.

title: Instruction set architecture


text:
Wikipedia talk:Disambiguation

on what statistics should look like for hatnotes, primary redirects, primary topics
Here's some more bits of info I've gathered after someone asked at Talk:Tupelo:

 * Talk:Slow
 * hatnote got up to 50% of traffic
 * after the move, the previously presumed primary topic barely registers though the common section does consistently get a measurably noticable chunk of traffic
 * Talk:Panis
 * a primary redirect was in place and no hatnote
 * after the move, the previous presumed primary topic got ~1.2%, ~1.4%, ~2.4%, ~1.9%
 * Talk:Zozo
 * hatnote got a small amount of traffic but almost all identifiable traffic anyway; RM received very little interest
 * after the move, the previous presumed primary topic got ~2.6%, ~1.9%, ~2.2%
 * Talk:Mar
 * hatnote got ~5.2% compared to incoming traffic
 * after the move, the previous presumed primary topic got ~6.5%, ~4.3%, ~4%, ~2.9% (the latter being a weird month)
 * Talk:Julius
 * a primary redirect was in place before, hatnote got ~3.5% of traffic, we noted the redirect ratio back then as 68/91 = ~75%
 * after the move, the previous redirect destination got ~11%, ~5%, ~3%, ~4%
 * Talk:Sola
 * hatnote got ~10% of traffic
 * after the move the previous presumed primary topic got ~7%, ~7%, and then with the fall of overall traffic it was below the anonymization threshold (< 10/273 = < 3.66% with every source-destination combination - which doesn't mean it wasn't actually something different though still a minority).
 * Talk:Tete
 * the hatnote got ~11% before the move
 * afterwards the previously presumed primary topic gets ~6%, ~7.2%, ~8.2%
 * Talk:Uma
 * there was a primary redirect in place and the hatnote got ~25.3% of its traffic before the move and dis. traffic was much larger still
 * afterwards the previously presumed primary topic gets ~8.2%, ~9%, ~11% interest
 * Talk:Ty
 * hatnote got a very small amount of traffic (max 220/13742 = ~1.6%), was only #5 in the top list
 * after the move, the previously presumed primary topic was sorted down in the list, got ~7% clicks the next month; sorted back up the following month it got ~8%, ~7.5%, ~5% clicks, though ~53% / ~55% / ~60% / ~47% of identifiable outgoing
 * Talk:Hum
 * used to be primary redirected to human humming, went back and forth a bit
 * previous primary redirect destination gets ~10%, ~8%, ~8%
 * Talk:Marr
 * hatnote got ~10% of traffic
 * after the move the previous presumed primary topic got ~11%, ~10.5%, ~11%, ~7.2%, ~9.6%
 * Talk:Rara
 * hatnote got some traffic before, all small
 * after the move the previous presumed primary topic got ~11.9%, ~11.3%
 * closely connected topic also shows up in outgoing destinations, but nothing else
 * Talk:Cam
 * hatnote got ~3.3% of traffic
 * after the move the previous presumed primary topic got ~11.5%, ~8.6%, ~12.3%
 * Talk:Luz
 * hatnote got ~9.7% of traffic, total disambiguation list traffic at times substantially higher as well
 * after the move the previous presumed primary topic got ~12%, ~7%, ~7.7% among several other topics
 * Talk:Top
 * hatnote got ~2%
 * after the move the previous presumed primary topic got ~12%, and half of identified outgoing
 * Talk:Kolya
 * hatnote got ~1.4%, total disambiguation list traffic substantially higher than that
 * after the move the previous presumed primary topic got ~13%, ~11%, ~8%, ~7.6%, ~7%
 * Talk:Shoot
 * hatnote got ~1% of traffic
 * after the move, the previously presumed primary topic got ~11%, ~10%, ~11%, ~12%, ~14.5% interest
 * Talk:Redd
 * hatnote got ~5% of traffic
 * after the move, the previously presumed primary topic got ~10.8%, 19.6%
 * Talk:Tupelo
 * hatnote got ~3% of traffic
 * after the move, the previously presumed primary topic got ~14%, ~28%
 * Talk:Boyle
 * hatnote got <4% of traffic
 * after the move, the previously presumed primary topic got ~15.6%, ~33%, though it's not clear if this is an actual improvement
 * Talk:Vic
 * hatnote got ~2%
 * after the move, the previously presumed primary topic got ~15.8%, ~15%
 * Talk:Golden shower
 * hatnote was on top of WikiProject Disambiguation/Popular pages
 * after the move, the previously presumed primary topic got ~0.7%, ~0.75%
 * another popular meaning got ~15%, ~17.3% though >90% identified outgoing
 * Talk:Bold
 * the previous stats indicated up to ~20% interest in the hatnote
 * after the move the interest in the previously presumed primary topic was ~16%, ~14.7%, ~18.4%, ~12.1%, ~14.3%
 * Talk:Julia
 * hatnote got ~20% of traffic
 * after the move, the previously presumed primary topic got ~14%, ~16%, ~17%
 * Talk:Slava
 * disambiguated after 18 years of being presumed primary topic, 15 years with a hatnote (March '22 1199/9356 = ~13%)
 * after the move, we continue seeing seasonal spikes for the previously presumed primary topic, and regardless of spikes it gets ~23%, ~15%, ~11% interest
 * Talk:Hamme
 * hatnote got relatively small traffic, was not measurable, most likely <10%
 * after the move, the previously presumed primary topic got ~16% interest
 * reverted, subsequent discussion resulted in no consensus
 * Talk:Baudouin
 * primary redirect, hatnote got < 0.5% interest compared to total incoming traffic at destination, nobody checked a comparison of redirect and disambiguation traffic
 * after the move, the previously presumed primary topic got ~16%, ~23%, ~17% interest
 * Talk:Warren
 * hatnote got ~7% of traffic
 * after the move, the previously presumed primary topic got ~18%, ~12%, ~14%, ~15% interest
 * Talk:Hamm
 * hatnote got ~2.5% of traffic
 * after the move, the previously presumed primary topic got ~18.4%, ~21%, ~22.9% interest
 * Talk:Mana
 * hatnotes combined got ~8% of traffic
 * after the move, the previously presumed primary topic got ~19%, ~17%, ~16% interest
 * Talk:Charlotte
 * the hatnote got ~0.7% before the move, yet there were hints that it could do better if reorganized because of ~20% measurements related to the primary redirect (which we sadly can't have in a lot of cases)
 * afterwards the previous presumed primary topic gets ~21%, ~23.5%, ~21.1%, ~22.9% interest
 * Talk:Lili
 * the hatnote got ~2% before the move
 * after the move, the previously presumed primary topic got ~23.2%, ~15.4%, ~26.4% interest
 * Talk:Gaga
 * the hatnote got ~1.5% before the move
 * after the move, the previously presumed primary topic got ~24.8%, ~29.9%, ~27.4% interest
 * Talk:Saba
 * hatnote was in the top 5 of identifiable outgoing clickstreams, the ratio wasn't recorded then but was around 635/23806 = ~2.6%
 * after the move, the previously presumed primary topic got ~28.5%, ~26%, ~24%, ~23.5%, though around half of outgoing
 * Talk:Frida
 * hatnote got ~2% of traffic
 * after the move, the previously presumed primary topic got ~27%, ~19%, ~27%, ~24.2%
 * Talk:Thomastown
 * hatnote got ~1%
 * after the move, the previously presumed primary topic got ~25%, ~28%
 * Talk:Forced march
 * was a soft redirect between 2011 and 2015, when it was made a primary redirect, and in 2023 it was disambiguated after a discussion
 * previous primary redirect destination gets ~29%, ~27%, ~44%, ~34.1%, another meaning that wasn't even mentioned in the RFD gets much more
 * Talk:Major
 * the previously discussed primary topic was moved after a lot of discussions, at the time of the RM the hatnote had max 431/17909 (~2.4%) interest
 * afterwards it shows up with ~30.6%, ~30.3%, ~25%, ~28%, ~21.3%, ~26.9%, ~37.1% of reader interest, though three quarters of outgoing
 * Talk:Ultra
 * the hatnote got ~2% before the move
 * afterwards the previously presumed primary topic gets ~29%, ~30.6%, ~26.5%, ~23%, ~26.9%, ~20.6%
 * Talk:Quantum leap
 * the hatnotes got ~21% before the move
 * afterwards the previously presumed primary topic gets ~32%, ~29.7%, ~32.5%
 * Talk:San Juan
 * before the discussion, the most popular link is alphabetically sorted in the middle of a big list and got ~22% clickstreams
 * after the discussion, it's on top of a MOS:DABCOMMON section, and gets ~29%, ~38%, ~26%
 * Talk:Sokol
 * hatnote got ~3-4%
 * afterwards the previously presumed primary topic got ~33%, ~21%, ~30%
 * Talk:Rasna
 * hatnote got ~1%
 * afterwards the previously presumed primary topic got ~20.9%, ~23.2%
 * move got reverted, went through a RM
 * afterwards the previously presumed primary topic got ~37%, ~38%
 * Talk:Severian
 * hatnote got ~1.7%
 * after the move, previously presumed primary topic got ~37%, ~33%, ~31%
 * Talk:Tiro
 * primary redirect was in place and we could measure ~18% of interest in the hatnote
 * after the move, previously presumed primary topic got ~36%, ~28%, ~36%
 * Talk:Lio
 * before the move, hatnote got ~1%
 * after the move, previously presumed primary topic got ~35.6%, ~37.9%, though >90% outgoing
 * Talk:Mons
 * hatnote got ~2%
 * after the move, previously presumed primary topic got ~38.5%, ~33.3%, ~32.3%, ~40.9%
 * Talk:Starwood
 * hatnote got ~2%
 * after the move, previously presumed primary topic got ~38.5%, ~35%, ~36.6%
 * Talk:Dave Hill
 * hatnote got ~0.5%
 * after the move, previously presumed primary topic got ~39%, ~46.1%, though almost all outgoing
 * Talk:Alnair
 * had a primary redirect
 * after disambiguation, previously presumed primary topic got ~46.5%, ~38%, ~41.5%
 * Talk:Angles
 * with primary topic in place, hatnote got less than 0.5% compared to incoming traffic and wasn't even in top 20 clickstreams
 * after the move, the previously presumed primary topic gets ~46.5%, ~43.6%, ~43.7%, ~42%
 * Talk:ATB
 * hatnote got ~1%
 * after the move, previously presumed primary topic got ~47%, ~45%, though almost all identifiable outgoing
 * Talk:Lord Cameron
 * proposed primary redirect quite recent, no consensus
 * proposed primary topic later got ~47%, ~54.8%, ~36.3%, ~54.2%, ~52.4% of incoming traffic
 * Talk:Give Me Liberty
 * hatnote did not get an observable level of interest
 * after the move, previously presumed primary topic got ~62%, ~39%, ~42.5%
 * Talk:Erasure
 * hatnote got < 0.3% interest, I myself doubted that there's a navigation issue there, but it wasn't completely clear
 * after the move, the previously presumed primary topic got ~48%, ~47%, ~44%, ~47.9% interest
 * Talk:AEG
 * hatnote got ~1% of traffic, I was skeptical because of that and long-term significance aspects
 * after the move the previous presumed primary topic got ~49%, ~47.5%, ~47.3% interest, though ~90% of identifiable outgoing
 * Talk:Motul
 * proposed primary topic gets ~51%, ~49%, ~52%, ~48%, ~51%
 * no consensus to move
 * Talk:Nabis
 * hatnote had ~1% interest
 * after the move the previous presumed primary topic got ~50%, ~58%, ~41.8%
 * Talk:King Charles
 * several RMs, kept disambiguated
 * proposed primary topic gets ~60%, ~55.9%, ~58.4% interest, though ~80% of identifiable outgoing, and hints of more
 * Talk:Sugar Man
 * was a primary redirect, the ratio between redirect views and disambiguation views was between ~23% and ~43% but then mostly going back
 * after the move the previous redirect destination got ~60%, ~61.5%, ~61%, ~68.2%
 * Talk:Heavy metal music/Archive 13
 * proposed primary topic got ~60% of traffic, though a fair bit of of it came from there, too
 * the discussion was overwhelmingly against the move regardless
 * Talk:Sean O'Malley (fighter)
 * proposed primary topic got ~71% or ~84% of traffic, one other topic identifiable as well
 * no consensus
 * Talk:Michael Fagan
 * proposed primary topic got between around 70 to around 85 percent of traffic for years and across spikes in usage
 * no other major topics by long-term significance, consensus to move by usage

I think I'll have to keep updating this summary here to build up a knowledge base. --Joy (talk) 15:19, 1 March 2024 (UTC)
 * --Joy (talk) 14:44, 6 April 2024 (UTC)
 * --Joy (talk) 18:05, 10 May 2024 (UTC)
 * --Joy (talk) 06:55, 5 June 2024 (UTC)
 * --Joy (talk) 16:37, 11 July 2024 (UTC)

This isn't to say that all of these moves were truly warranted or that there aren't a plethora of individual factors at play. But even with this spread of outcomes, there's something distinctly off with our current near-consensus interpretation of how stats should look like for primary topics by usage. This also means little for considerations of long-term significance. --Joy (talk) 15:30, 1 March 2024 (UTC)

 * Your numbers for % of "interest" are rather misleading, as they don't mention that in many cases, the largest percentage by far was "no traffic at all", i.e. no clickthrough, for whatever reason (visits not by humans? wanted target not available? info on disambig page sufficient?). E.g. for Hamme, you note "after the move, the previously presumed primary topic got ~16% interest", which was more than 4 times as much as the other topics "combined". Fram (talk) 14:51, 11 April 2024 (UTC)
 * Yes, I've mentioned this several times. I agree it is misleading to simply assume that every incoming view counts for something meaningful. Truth is that there is no way for us to know what if anything those 'dead-end' incoming page views signify. older ≠ wiser 15:34, 11 April 2024 (UTC)
 * @Bkonrad exactly, but it's not exactly that we don't know that they don't signify anything. There's multiple hints that they do:
 * First of all, there is a spread of cases here, ranging from where we see a lot of the incoming views translate into clicks, to where we see few of the incoming views translate into clicks. I didn't summarize all of that information on this talk page, you have to go click through the links to examine that. (I may find some time later to extract that dimension of data and extend the list above.)
 * That means that we're not just consistently seeing some ghost traffic always, rather, we've got to be observing actual reader behavior at least to an extent. So we can't just see e.g. 60% of traffic translate into clicks in a fresh case and then jump to the conclusion that most of the remaining 40% is ignorable.
 * Secondly, there are cases where we see almost all of the incoming views translate into clicks. The most recent such example I found is described at Talk:Forced march, where our identification rate went from 34/55 (~62%) in the first month observed, to 96/96, to 95/95, to 135/135 in the last three months, amazingly enough, even at such a small amount of traffic.
 * This negates even the idea that there's always got to be at least some of this ghost traffic, because apparently we have a falsifying scenario that seems quite consistent. So we can't just see e.g. 75% of traffic translate into clicks and then jump to the conclusion that any part of the remaining 25% is ignorable.
 * --Joy (talk) 12:33, 14 April 2024 (UTC)
 * It should be noted that we since observed forced march getting more outgoing clicks than incoming ones. That's another scenario we can't account for - the same readers clicking multiple items in a list. --Joy (talk) 08:48, 18 July 2024 (UTC)
 * On the individual points raised by @Fram earlier:
 * meta:Research:Wikipedia clickstream says it tries to exclude visits not by humans: We attempt to exclude spider traffic by classifying user agents with the ua-parser library and a few additional Wikipedia specific filters. It's certainly possible that it misses, but then the page views "User" category is likely missing, too, so I don't know that we should rely on that being a major effect.
 * Wanted target not available - how would this improve the odds for the claim that there would have to be a primary topic, when there'd be topics that detract from there being a primary topic yet they're not even available? That would seem to just raise the risk of astonishing more contingents of readers. "These people don't even know about meaning X, and they proclaimed meaning Y as the main one - pfft!"
 * Info on disambig page sufficient - this use case is indeed not studied at all, and I agree that it seems possible for at least some cases. Ultimately, why would we consider all navigations that do not result in another click bad? IOW surely this also detracts from the idea of there being a primary topic, if there is also the contingent of readers who we cannot convince to click on the link to read about the proposed primary topic (which is also usually the very first link in the list).
 * More than 4 times as the other topics combined - I've explained already at Talk:Hamme (disambiguation) how you are making weirdly incorrect statements. Even if we compare 28 identified clickstreams and the 10 identified clickstreams, the ratio between those two numbers is 2.8, it is simply not 4. Likewise, both 28 and 10 are so close to the anonymization threshold that it's not at all clear that this ratio has to be precise. In other words, this could have been 4 or it could have been 2 with just a few more src-dest pairs of views identified as opposed to anonymized out. And none of these ratios are impressive when we also see a lot more traffic interested in neither of these.
 * In any event, thanks for the interest. --Joy (talk) 12:33, 14 April 2024 (UTC)
 * Yes, I'm not saying the count of incoming views should be completely ignored, only that trying to read into what it signifies is highly speculative and we should be very cautious about what significance we attribute to such dead-end views. If there is a sudden change in the number of such incoming views, that likely merits some further consideration. Similarly, if there is a consistent, very large gap between incoming and outgoing views, that also may merit some consideration. But even in such cases, deciding what readers reaching such dead-end views were looking for when arriving at a particular disambiguation page is still highly speculative. It could play a factor in arguing that there is no primary topic where there is none at present (i.e., where there is a request to replace a disambiguation page with a primary topic). I'm not sure what significance we could read into such dead-end views of a disambiguation page where there is an existing primary topic. It could be readers are just curious about what else might have the same name, without intending to look at any of them in more detail. We just don't know why such readers behave that way. older ≠ wiser 13:46, 14 April 2024 (UTC)
 * Agreed, the change in pattern would be a significant indicator. But on that front, I point again to evidence above - we often observe a clearly consistent pattern, and then we do a switch for whatever reason, and then we the data switches to observing a clearly different consistent pattern. Well, it often takes a few months for things to settle, and in the interim period there's a swing or two, but still.
 * In cases where there is already a primary topic selected, it's very hard to read into the no-clickthrough traffic. Because the content is larger and varied, it could be any number of possibilities. Just like it could be readers who are navigated wrongly and just immediately click away, it could also be misnavigated readers who stayed and learned something and then clicked away, or it could be a bunch of completely content readers who were absolutely happy to read what was in front of them and had no need to immediately learn more about another related topic. We don't have the tools to discern these.
 * With simpler pages like the disambiguation lists, however, it's less hard to understand the general reader behavior because we don't present people with huge amounts of possibilities, we reduce that number and streamline their options, and make it more likely we can understand the measurements of our existing tools.
 * What I think we should learn from all this is that we should not be too cautious and instead we should not be afraid to experiment as much as we have been so far.
 * In all this data I've tracked, we've yet to observe a case where there was a fresh reader complaining about disambiguation lists being the wrong choice. As long as we apply MOS:DABCOMMON, and we do, we have no indication that we're confusing or troubling any appreciable amounts of readers even in contentious cases. --Joy (talk) 14:35, 14 April 2024 (UTC)
 * This seems a peculiar criterion. Quite aside from reactions to the lists you have been compiling, I can't recall the last time I came across a "fresh" reader ever complaining about an incorrectly placed disambiguation page where the complainant was not a myopic partisan seeking to promote their preferred topic.
 * Regarding I'm glad you are taking a deeper dive into the data, but I hope no one is being misled that the reems of data of uncertain quality based on poorly documented functions represents an agreed upon approach to making decisions. older ≠ wiser 16:02, 14 April 2024 (UTC)
 * We actually have some interesting data points about that, too, cf. Talk:Tito (disambiguation), where nobody really paid attention for over a decade as disambiguation was in place, and then a consensus of editors practically instantly chose to apply a primary topic redirect mainly for long-term significance. (On the plus side, that flip allowed us to measure something else afterwards, Wikipedia talk:Disambiguation/Archive 56 explains more.)
 * I'm pretty sure if we go through other cases we can also find similar timeframes, where some arbitrary navigation choice has been in place for years and decades, and then we arbitrarily decide to congregate, make fun new decisions and pat ourselves on our collective backs :)
 * IOW our decision-making process seems perfectly sound (mostly to me too, I'm not excluding myself here), but so much goes through the cracks that it's doubtful that much of it really matters as much as we think it does. --Joy (talk) 16:49, 14 April 2024 (UTC)

Wikipedia talk:Content assessment
In the discussion linked above, we have something of a weak consensus to stop strictly sequestering disambiguation from set indices in all cases. Does anyone see any reason not to draft changes to this guideline to incorporate some of these possibilities? --Joy (talk) 15:44, 6 March 2024 (UTC)

 * In the meantime the RFC thread was archived at Wikipedia talk:Content assessment/Archive 9.
 * As there's no objection, I think we need these kinds of changes:
 * Make it clear in the text of WP:PTM that the exception applied to toponymy can apply to anthroponymy as well, and we shouldn't shy away from listing some of the latter on disambiguation pages
 * Make it clear in the text of WP:NAMELIST that the strict separation of disambiguation and set index content should be weighed against the possibility that we introduce extra hurdles to readers just because some ambiguous topics also qualify for a set index
 * Possibly a section here about the practical interaction of disambiguation and set index articles, as opposed to just a See also link
 * --Joy (talk) 13:01, 28 April 2024 (UTC)

 * I've split out item #1 above into . --Joy (talk) 11:26, 4 June 2024 (UTC)

how many months it takes for disambiguation usage statistics to change
I'd like to point out an aspect of that is becoming increasingly clear - we don't need a lot of time to detect changes in readership navigation patterns. Usually whatever happened with one month after a change was quite indicative of the pattern of traffic going forward, there's never a serious fluctuation.

We should use this to our advantage - to be more willing to experiment for e.g. two months, because that will usually suffice to get measurements and decide if the change was good or not. --Joy (talk) 18:16, 10 May 2024 (UTC)

WP:DABCOMBINE not actually with organic consensus in the acronym space
I noticed this a month ago in Talk:PAG, last comment. Would be nice if someone could analyze the data more thoroughly. --Joy (talk) 07:52, 31 May 2024 (UTC)

including the most notable set index topics on human name disambiguation pages
This is effectively a continuation of Wikipedia talk:Disambiguation/Archive 55 which went stale and got archived out, but still applies.

More examples have since cropped up where we see from the available data that readers would benefit from us including the most popular given name and surname entries on the base disambiguation pages whenever a separate name list (set index) exists:

 * Talk:Boyle
 * Talk:Luka

I wanted to title this section "WP:NAMELIST considered harmful", but it's not really, just the overly strict implementation we employ right now. :)

If there are no objections, I would go ahead with making this change:

 * Lists of names
 * To prevent disambiguation pages from getting too long, long lists of given name or surname holders can be moved out of disambiguation pages into separate set indices. In cases where there are distinctly popular entries in such lists, such as those with substantially large usage or long-term significance compared to the rest of the list, links to such articles should be retained on the base disambiguation page. This kind of extra listing should in turn still be constrained by the base list size, so it should not typically exceed five to ten entries.
 * We reasonably expect to see Abraham Lincoln at Lincoln (disambiguation), but very few sources would refer to the waltz composer Harry J. Lincoln by an unqualified "Lincoln", nor is he a topic of outsized reader interest, so he is listed only at the Lincoln (surname) anthroponymy article. Conversely, it's reasonable to expect that a lot of readers might want to navigate to Andrew Lincoln because of consistently measurable outsized usage, so he should be listed at both.
 * footnote here: All-time page views for all entries listed at Lincoln (name) |Abraham_Lincoln|Andrew_Lincoln|Harry_J._Lincoln All time monthly page views comparing the aforementioned 'Lincoln' topics
 * This does not necessarily prejudice primary topic considerations. For example, many highly notable people are called Herb, but typing in Herb gets you an article on plants. However, as the usage statistics show the interest in Herb Alpert to be typically exceeding the reader interest in the plant topic, the hatnote at Herb or the list at Herb (disambiguation) may include a link to that biography, next to the links to Herb (surname) and Herb (given name), where articles on people named "Herb" are listed. Consensus among editors determines if an article should be listed on the disambiguation page.
 * footnote here: All-time page views for all entries listed at Herb (given name) |Herb_(given_name)|Herb_(disambiguation)|Herb_(surname)|Herb_Alpert All time monthly page views comparing the aforementioned 'Herb' topics

--Joy (talk) 11:25, 4 June 2024 (UTC)

 * This covers the most pressing topic of . The other issue, whether to encourage keeping anthroponymy lists merged, needs more discussion because it may detract from the goals of this - e.g. if we squash a short list like Herb (surname) back into Herb (disambiguation), and don't squash the given name list, that may give undue prominence to people with the surname. We already have a problem with the long tail of ambiguity cluttering disambiguation pages. I'd prefer to deal with the complexities of that separately. --Joy (talk) 11:29, 4 June 2024 (UTC)
 * I've applied this change, but something confused me with note formatting in https://en.wikipedia.org/w/index.php?title=Wikipedia:Disambiguation&oldid=1227556919#Lists_of_names - if someone could render assistance, I'd appreciate it.
 * I also swapped out Andrew Lincoln for Jon Hamm, because the difference in reader traffic is even more stark there. --Joy (talk) 13:30, 6 June 2024 (UTC)
 * I've reverted these changes. So much detail is couterproductive per WP:CREEP. It also changes the default to having WP:PTM names on dab pages from current general consensus that they are exceptions. Most PTM name lists belong in anthroponymy articles. Station1 (talk) 19:30, 6 June 2024 (UTC)
 * @Station1 you might have missed the reams of data I provided in discussions above and linked in the archive, explaining how readers looking for biographies are being so badly served by our navigation. I'd appreciate it if you could review it.
 * I think this idea of a general consensus that people's names are just partial title matches, as opposed to instances of actual ambiguity, are not based on an accurate observation of reader behavior, rather it appears more based on an opinion of a relatively small group of us editors. By moving links to biographies behind another click, and by not helping readers to the most common navigation choices, we've been artificially modifying reader navigation as opposed to enabling it.
 * In a few recently documented examples such as Tito, Charlotte and Luka, hints of their actual behavior still came through. --Joy (talk) 20:26, 6 June 2024 (UTC)
 * The trouble with Tito (disambiguation), for example, is that the 3 or 4 things actually called Tito are buried at the bottom of a huge list of people who aren't named solely Tito. Station1 (talk) 20:43, 6 June 2024 (UTC)
 * Yes, exactly this. That one or a very few might be looked as a mononym is not a good reason to abandon the current guidance. older ≠ wiser 20:54, 6 June 2024 (UTC)
 * I don't know what you mean, because the proposed wording doesn't talk of mononyms, rather it encourages thinking about outsized usage and long-term significance. A mononymous usage of a name by a relatively minor person should not be prioritized over a normal usage of a name by a relatively major person. (Or in turn by relatively minor toponyms, fictional characters and other items that habitually clutter our disambiguation lists.) IOW we should start thinking about ambiguity in navigation not just through what is technically ambiguous, but what is practically ambiguous for the average English reader, and how the compendium of knowledge about an ambiguous term is most effectively presented to them. --Joy (talk) 22:01, 6 June 2024 (UTC)
 * I'm sorry, but this is just continuing on the same "mononymity rules!" party line without evidence... I had a look in the clickstreams, and found in November '20 that the link to the acronym, "TITO", was clicked at least 20 times, in the same month when the 2019 film was clicked 10 times. The link to TITO has always been in the last section, See also, which is below the film section. No other entry from the film section crossed the anonymization threshold that month, but Jackson (15), Ortiz (11) and two of the footballers +did (11 and 12 resp.). The footballers are in the top mononymous section, while the other two are in the general sections. Maybe it's more likely that we forced the readers looking for the Jacksons and the Ortizes to have to comb through the general lists to find them, and the number of them who gave up and went back to Google might be higher than the number looking for the films? --Joy (talk) 21:47, 6 June 2024 (UTC)
 * Dab pages are not search engines, and were never meant to be search engines. They are necessary navigation aids where there are two or more topics that would or could have identical or nearly identical titles. That's because of the technical impossibility of two articles having the same title. They were always intended to be as short as possible, in order to be as easy to use as possible. WP has a search engine for people who can't remember or spell someone's last name, which is far superior to anything human editors could put on a page. We also have "intitle" and similar templates to stick on the bottom of dab pages when useful. An occasional IAR exception for a very popular easily misspelled topic is fine, but we shouldn't turn dab pages into inferior search engines. Station1 (talk) 22:24, 6 June 2024 (UTC)
 * Yes, and there are readers who think a person with the name Foo Bar has an identical name to a person with the name Foo Baz or Foo Quux, because that's how human names work.
 * But even so, regardless of this generic argument, I still don't see how the proposed wording doesn't match with what you described in your last sentence. Even if you think Abraham Lincoln isn't an identical enough match for Lincoln, you allow it to be listed already, because whatever, people use that like that. It turns the dab page into an inferior search engine, but you see the usefulness. Likewise, allowing Jon Hamm to be listed at Hamm would be useful, as the same thing happens. The Lincoln biography is read by 400 thousand people a month, while the comparable city articles are read by 20 and 15 thousand, respectively. The Hamm biography is read by 200 thousand people a month, while the comparable city article is read by 2 thousand. In the latter case it's a difference of 100 : 1, we're not talking subtle nuance here, and it's significantly larger than the 10 : 1 difference in the former.
 * Fundamentally, the encyclopedia describes, it does not prescribe. Making huge contingents of readers jump through hoops because we don't feel like they're using these words the right way - is the latter. --Joy (talk) 06:57, 7 June 2024 (UTC)
 * Lincoln is often referred to as Lincoln, and could conceivably be a PRIMARYREDIRECT like Einstein or Churchill, so belongs on the Lincoln dab page. To my knowledge Jon Hamm is not referred to as just Hamm. Even so, I wouldn't object to adding him to the dab page per WP:IAR, but it would be a bad idea to add the 18 other people at Hamm (surname). - Station1 (talk) 17:06, 7 June 2024 (UTC)
 * With these kinds of numbers, it seems probable that even the amount of accidental or cursory references to him as just Hamm are statistically relevant.
 * No argument about not listing the other 18 people there, absolutely, that's why the phrasing was very careful to weed that out. Did you notice the part that said In cases where there are distinctly popular entries in such lists, such as those with substantially large usage or long-term significance compared to the rest of the list. Is that not strict enough? --Joy (talk) 08:41, 8 June 2024 (UTC)

Since this discussion died down, the same kind of problems have cropped up in a few more places, for example at "Dina", described at Talk:Dina (disambiguation), and at Wikipedia talk:WikiProject Anthroponymy. --Joy (talk) 17:42, 26 June 2024 (UTC)

BTW Talk:Julius is another such case. We have it on the record that nobody calls him just Julius, yet when we started presenting readers with the choice to click him or to click mononymously named people, the readers consistently choose him. :) --Joy (talk) 08:53, 18 July 2024 (UTC)

MOS:DABNOENTRY is contradicted by WP:PTM
MOS:DABNOENTRY states: "On a page called Title, do not create entries merely because Title is part of the name ... This does not apply if the subject is commonly referred to simply by Title." On the other hand WP:PTM says: "Placenames are often divided between a specific and generic part, for example North Carolina (where "Carolina" is the specific, and "North" the generic part). Common generics are compass points, upper/lower, old/new, big/small, etc. It is entirely proper to include such placenames in disambiguation pages with the specific title (North Carolina is properly listed at Carolina (disambiguation))". DABNOENTRY would exclude North Carolina from Carolina (disambiguation) because the state is never called simply Carolina, just as New York is never referred to as York (York Yankees?). In my opinion, DABNOENTRY takes precedence (and makes the most sense), and the wording in PTM should be removed. Clarityfiend (talk) 14:48, 17 June 2024 (UTC)

 * "Nothing could be finer than to be in Carolina in the morning ..." Carolina in the Morning, Gus Kahn and Walter Donaldson.
 * References to "the Carolinas" or "the Dakotas" aren't unusual. Largoplazo (talk) 15:24, 17 June 2024 (UTC)
 * I have no objection to the Carolinas. As for the song, I venture to guess it's talking about the Carolinas, but it wouldn't scan properly as "be in the Carolinas". Also, DABNOENTRY states "commonly referred to". One song isn't going to cut it. Clarityfiend (talk) 10:13, 18 June 2024 (UTC)
 * How about 2? "Carolina in My Mind". The songwriter was specifically referring to his home in North Carolina.--User:Khajidha (talk) (contributions) 13:21, 6 July 2024 (UTC)
 * Or three? "Carolina". --User:Khajidha (talk) (contributions) 13:23, 6 July 2024 (UTC)
 * The key words in DABNOENTRY are "merely because". It's saying PTMs are not generally helpful to include. WP:PTM is pointing out a subclass of PTMs that often are helpful. There's no direct contradiction, but there could be better alignment – I'd say changing WP:PTM from "entirely proper" to "often proper" would bring it more in line with both DABNOENTRY and best practice, and that the two sections should link to each other with hatnotes. — swpb T • beyond • mutual 15:35, 17 June 2024 (UTC)
 * This started with Talk:Vic. I think the main criterion is pretty clear - if the average English reader is going to encounter ambiguous references to a topic in practice, they should be listed. --Joy (talk) 18:18, 17 June 2024 (UTC)
 * I often put partial matches like that in See also; I must have been in a particularly deletionist mood that day. That's the sort of thing I would do with the bizarre New York (disambiguation) entry in York (disambiguation). Who would look for the Big Apple under York? In fact:
 * Proposal: Reword what PTM currently says to "It is entirely often proper to include such placenames in the See also section of disambiguation pages with the specific title". Clarityfiend (talk) 10:13, 18 June 2024 (UTC)
 * I don't think this is just for see also, because I have encountered numerous examples of toponyms where this would not match real-world circumstances, and this sort of a thing could well be controversial. --Joy (talk) 14:05, 18 June 2024 (UTC)
 * I think in the case of "Vic", for most places like "Vic-sur-Aisne" it is common to use plain "Vic" when there is no ambiguity. For instance in the neighbouring town Cœuvres-et-Valsery the road leading to Vic-sur-Aisne is called "Route de Vic", Similarly, the "Route de Rabastens" leads to Rabastens-en-Bigorre. So yes, I think places like Vic-sur-Aisne should be listed on the disambiguation page "Vic". The "-sur-Aisne" is not really generic, more a specifier or disambiguator (because there are several places named "Vic"). Markussep Talk 08:09, 20 June 2024 (UTC)

traffic pattern changes between redirects, broad-concept articles and disambiguation pages
Here's a bit of a continuation of Wikipedia talk:Disambiguation/Archive 56:

The term national bank was recently replaced by disambiguation through a WP:MALPLACED redirect, but it used to be read by ~4k readers a month. Likewise happened for state bank, which used to be read by ~1k people a month.

|State_bank|National_bank_(disambiguation)|State_bank_(disambiguation) All-time page view statistics for these topics and the disambiguation pages

The change seems to have caused the reader traffic to practically instantly drop to 0.4k and 0.2k a month, respectively.

So it looks like the change caused us to effectively relinquish 80-90% of readers looking up a term like that, as their search engine stopped sending them our way (or at least I can't think of another scenario why this pattern change would happen). --Joy (talk) 18:05, 26 June 2024 (UTC)

Here's another one: Talk:Ottoman - once we squashed plural and singular, 80% of incoming traffic magically disappeared. --Joy (talk) 11:47, 27 June 2024 (UTC)

 * I happened to notice Talk:Pharos (disambiguation) today - a change from disambiguation page to primary redirect in 2016 also caused ~80% of previously recorded incoming traffic to disappear. --Joy (talk) 09:35, 16 July 2024 (UTC)

Semi-protected edit request on 5 July 2024
Edit purpose: The page section in the example no longer exists. The section and the redirect now use "American Football" instead of "Football".

Current text: In some cases, it may be more appropriate to redirect readers to a list rather than a disambiguation page. For example, Cleveland (NFL) should not be a disambiguation page, but should instead redirect to List of Cleveland sports teams.

Replacement text: In some cases, it may be more appropriate to redirect readers to a list rather than a disambiguation page. For example, Cleveland (NFL) should not be a disambiguation page, but should instead redirect to List of Cleveland sports teams. Solid kalium (talk) 18:09, 5 July 2024 (UTC)
 * I reverted "American" on a U.S. topic page, so it works again. Hyphenation Expert (talk) 18:42, 5 July 2024 (UTC)

Shield and sword
– a neo-Nazi music festival – red link – a disambig page

Can someone help me unscramble all this? Starting with the easy stuff: it seems pretty clear that D-page Sword and shield should contain an entry that links the festival article, right? Do we need to move the festival to Shield and Sword (festival) so we can create "Shield and sword" anew as a disambig page, so it can point to the festival, and also to Grand jury page, and maybe also the theory about Marshal Pètain? Thanks for any advice. Mathglot (talk) 08:51, 6 July 2024 (UTC)
 * "shield and sword" is a metaphor for the function of grand juries; see Grand jury for usage (no redirect there by that name)
 * A search-bar query for "shield and sword" (lowercased, without quotes) takes you to Shield and Sword, a neo-Nazi music festival, via the redirect Shield And Sword
 * "sword and shield theory" is an analysis of Marshal Pètain's leadership of Vichy France in WW2, and redirects to Vichy syndrome
 * A query for "sword and shield" (lowercased, without quotes) goes to disambig page Sword and shield (which doesn't link the festival, which has Shield first)
 * There is no disambig page Shield and sword (that slot is already taken by the festival article).
 * I would move the festival and redirect Shield and Sword (and Shield and sword) to Sword and shield as an alternative form. BD2412  T 21:05, 6 July 2024 (UTC)
 * Makes good sense to me. I'll wait some days to see if there are more thoughts about this before acting. Oh, and what would you do about the Grand jury sense of "shield and sword"; add it to the D-page? Mathglot (talk) 02:15, 7 July 2024 (UTC)

Primary Topic
There is a move proposal at Talk:Rallying suggesting the article should be disambiguated. Another user has supported, mentioning the policy of WP:PRIMARYTOPIC. However, no other Rallying topic articles can be found - making the move unnecessary under that very policy. Is that correct, does primary topic only mean a primary Wikipedia article and not common usage of a word within multiple contexts? I'd be grateful if anybody could clarify that within the discussion, or here for me. Thanks. Rally Wonk (talk) 16:38, 10 July 2024 (UTC)

What does "under certain circumstances" mean in WP:DABSISTER
Wouldn't it be useful to either define what the words "under cetain circumstances" at WP:DABSISTER mean? or (even better) provide examples when a link to a foreign language Wikipedia would be useful and when it wouldn't be useful? I would give it a stab, but I have no idea what those words mean. The Mountain of Eden (talk) 20:53, 16 July 2024 (UTC)

title: Wikipedia talk:Disambiguation


text:
Maclisp

Maclisp (or MACLISP, sometimes styled MacLisp or MacLISP) is a programming language, a dialect of the language Lisp. It originated at the Massachusetts Institute of Technology's (MIT) Project MAC (from which it derived its prefix) in the late 1960s and was based on Lisp 1.5. Richard Greenblatt was the main developer of the original codebase for the PDP-6; Jon L. White was responsible for its later maintenance and development. The name Maclisp began being used in the early 1970s to distinguish it from other forks of PDP-6 Lisp, notably BBN Lisp.

History
Maclisp is a descendant of Lisp 1.5. Maclisp departs from Lisp 1.5 by using a value cell to access and store the dynamic values of variables; Lisp 1.5 used a linear search of an association list to determine a variable's value. The Maclisp variable evaluation is faster but has different variable semantics. Maclisp also employed reader macros to make more readable input and output, termed input/output (I/O). Instead of entering, one could enter   to get the same s-expression. Although both implementations put functions on the property list, Maclisp uses different syntax to define functions. Maclisp also has a load-on-demand feature.

Maclisp began on Digital Equipment Corporation PDP-6 and PDP-10 computers running the Incompatible Timesharing System (ITS); later it was ported to all other PDP-10 operating systems, for example, Timesharing / Total Operating System, TOPS-10 and TOPS-20. The original implementation was in assembly language, but a later implementation on Multics used PL/I. Maclisp developed considerably in its lifetime. Major features were added which in other language systems would typically correspond to major release numbers.

Maclisp was used to implement the Macsyma computer algebra system (CAS) or symbolic algebra program. Macsyma's development also drove several features in Maclisp. The SHRDLU blocks-world program was written in Maclisp, and so the language was in widespread use in the artificial intelligence (AI) research community through the early 1980s. It was also used to implement other programming languages, such as Planner and Scheme. Multics Maclisp was used to implement the first Lisp-based Emacs.

Maclisp was an influential Lisp implementation, but is no longer maintained actively. It now runs on PDP-10 emulators and can be used for experimenting with early AI programs.

Characteristics
Maclisp began with a small, fixed number of data types: cons cell, atom (later termed symbol), integer, and floating-point number. Later additions included: arrays, which were never first-class data types; arbitrary-precision integers (bignums); strings; and tuples. All objects (except inums) were implemented as pointers, and their data type was determined by the block of memory into which it pointed, with a special case for small numbers (inums).

Programs could be interpreted or compiled. Compiled behavior was the same as interpreted except that local variables were lexical by default in compiled code, unless declared SPECIAL, and no error checking was done for inline operations such as CAR and CDR. The Ncomplr compiler (mid-1970s) introduced fast numeric support to Lisp languages, generating machine code (instructions) for arithmetic rather than calling interpretive routines which dispatched on data type. This made Lisp arithmetic comparable in speed to Fortran for scalar operations (though Fortran array and loop implementation remained much faster).

The original version was limited by the 18-bit word memory address of the PDP-10, and considerable effort was expended in keeping the implementation lean and simple. Multics Maclisp had a far larger address space, but was costly to use. When the memory and processing power of the PDP-10 were exceeded, the Lisp Machine was invented: Lisp Machine Lisp is the direct descendant of Maclisp. Several other Lisp dialects were also in use, and the need to unify the community resulted in the modern Common Lisp language.

Name
Maclisp was named for Project MAC, and is unrelated to Apple's Macintosh (Mac) computer, which it predates by decades or to John McCarthy. The various Lisp systems for the Macintosh have no particular similarity to Maclisp.

title: Maclisp


text:
Lisp Machine Lisp

Lisp Machine Lisp is a programming language, a dialect of the language Lisp. A direct descendant of Maclisp, it was initially developed in the mid to late 1970s as the system programming language for the Massachusetts Institute of Technology (MIT) Lisp machines. Lisp Machine Lisp was also the Lisp dialect with the most influence on the design of Common Lisp.

Lisp Machine Lisp branched into three dialects. Symbolics named their variant ZetaLisp. Lisp Machines, Inc. and later Texas Instruments (with the TI Explorer) would share a common code base, but their dialect of Lisp Machine Lisp would differ from the version maintained at the MIT AI Lab by Richard Stallman and others.

Manual
The Lisp Machine Manual describes the Lisp Machine Lisp language in detail. The manual was popularly termed the Chine Nual, because the full title was printed across the front and back covers such that only those letters appeared on the front. This name is sometimes further abbreviated by blending the two words into Chinual.

Traits
Lisp Machine Lisp features include:
 * Support for object-oriented programming via an object system named Flavors
 * Uses dynamic binding, but supports closures with a special construct
 * Integer numbers were read and printed in octal (base 8) by default
 * Dividing floating point numbers returned decimals, dividing integers returned rational numbers (fractions)

title: Lisp Machine Lisp


text:
Talk:Environmental economics

External links modified (January 2018)
Hello fellow Wikipedians,

I have just modified one external link on Environmental economics. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20140520020258/http://www.greeneconomics.org.uk/ to http://www.greeneconomics.org.uk/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 08:51, 22 January 2018 (UTC)

India Education Program course assignment
This article was the subject of an educational assignment supported by Wikipedia Ambassadors through the India Education Program.

The above message was substituted from by PrimeBOT (talk) on 19:53, 1 February 2023 (UTC)

title: Talk:Environmental economics


text:
Maskun

Maskun may refer to:
 * Monochromacy (in parts of Micronesia)
 * Maskun, Iran, a village in Mazandaran Province, Iran
 * Maskun Rural District, in Kerman Province, Iran

title: Maskun