N-bit integers need arithmetic rules that preserve their width

A declaration of a narrow integer does not necessarily imply narrow arithmetic. C can promote operands before applying an operator, so the type used to store a value and the type used to compute with it can differ. That distinction is central to N2534, a June 9 proposal by Melanie Blower, Tommy Hoffner, and Erich Keane. Its proposed N-bit types need rules for expressions as well as a spelling for declarations.

The WG14 document log lists the paper under the title Adding Fundamental Type for N-bit Integers. The specific spelling in this revision is _ExtInt(N). This is proposed language work, so its examples should be read as descriptions of the design under consideration.

C remains useful to me partly because its interfaces make representation decisions explicit. A type that names a bit width extends that ability, but its value depends on what happens after the declaration. Arithmetic that immediately discards the requested width would undermine the reason for introducing the type.

A storage choice does not define an expression

The November working draft defines integer promotions and the usual arithmetic conversions separately from the declarations of integer types. Those rules determine the types used by expressions. An assignment to a narrower object happens after the expression has already undergone its applicable conversions.

That order matters when interpreting code intended to describe hardware. If the expression requires a wider operation, storing its eventual result in a small object does not by itself describe a small intermediate operation. A compiler may optimize under its usual rules, but the type system has already supplied a different account of the expression.

N2534 motivates its design with FPGA use, where excess width can require unnecessary hardware. It proposes exempting the new types from ordinary integer promotions. When two such operands have different widths, its description converts the narrower operand to the wider type.

The following declarations illustrate the proposal's spelling.

unsigned _ExtInt(5) sample;
unsigned _ExtInt(9) accumulator;

The width is part of each type. This gives a reader information that a broad implementation-chosen integer type cannot express as directly. It still leaves a separate question about the precision needed by each operation.

Choosing the result width

Suppose an application adds two values that individually fit in the proposed five-bit unsigned type. Their sum can require more bits than either operand. Keeping arithmetic narrow therefore makes the programmer's choice of operand types consequential.

That is an ordinary arithmetic observation with a particular effect on this design. A declaration can describe the valid range of an input without providing enough range for all calculations using that input. The expression needs its own representation decision.

A wider destination alone cannot communicate when the widening should occur. If the operation has already computed a narrow result, assigning that result to a wider object does not reconstruct information lost during the operation. Widening an operand before the operation describes a different computation.

For an application intentionally using limited-width arithmetic, this distinction can be desirable. The type records a chosen numerical model, and operations should follow that model. For an application accumulating a result that must remain exact, the operands and intermediate types need enough range for that requirement.

The proposal consequently offers expressiveness together with a responsibility. More available widths let a programmer state narrower requirements. They also create more combinations whose arithmetic behavior must be understood. A source review needs to consider the expression, including any explicit conversions, rather than reading the destination declaration alone.

Hardware intent and software implementation

N2534 allows implementations to emulate unusual widths using larger integers while preserving the specified arithmetic behavior. This separates the numerical model from the machine's native register choices. A request for a particular width does not mean that every target has a matching instruction or storage unit.

That distinction is necessary for portable source. A program can need a numerical behavior on a target whose convenient machine operations have different widths. An implementation can use the available operations as long as the result follows the language definition.

It also limits the performance claims that a declaration can support. Expressing a narrower operation can give a hardware-oriented compiler more relevant information. The same spelling on another target may require additional work to preserve that operation's behavior. The proposed type describes semantics, while the target and implementation determine how to realize them.

I regard that as a reasonable division of responsibility. C already depends on a distinction between source-level meaning and generated instructions. Making an unusual width explicit gives both the reader and the compiler a concrete requirement to preserve.

Mixed arithmetic needs a separate reading

The paper describes conversion ranks for the new types and their relationship with the existing standard types. This is important because a program rarely consists entirely of values belonging to one new type family. A literal or a conventional integer variable can change the conversions that apply to an expression.

The practical implication is that visually similar expressions can require different reasoning. An operation between two explicitly sized operands is one case. An operation combining one of them with an ordinary integer is another. The proposed exemption from promotion should not be read as a claim that every mixed expression retains the narrow operand's type.

For interface authors, that makes type consistency useful. A function accepting a conventional integer may require a conversion even when its caller has a precisely sized value. The interface's declaration determines what crosses the boundary. Choosing the new type internally does not automatically revise an external function.

Storage formats require the same precision of language. Naming a bit width for arithmetic does not by itself specify the byte sequence an application should put on a wire. A protocol needs its own representation agreement. Otherwise, a declaration intended to describe computation can become an unsupported assumption about external data.

The substantive contribution of N2534 is to connect a width-bearing type spelling with expression rules that make the width useful. Its treatment of promotion addresses the hardware motivation directly. An application using the proposed facility still has to decide which operations should preserve a narrow numerical model and which need wider intermediates.