Architecture

Purpose and scope

ExecutePTOInstruction is the total entry point for one encoded PTO instruction and returns either PTOInstruction_Executed or PTOInstruction_Rejected.

It separates command-form dispatch from scalar dispatch and provides one explicit rejection path for unmatched 64-bit inputs.

Concepts and visible state

• The input carrier is bits(64) and length_bits is restricted to 16, 32, 48, or 64.
• DecodeCommandForm is tried first. A recognized command form is passed to ExecuteCommandInstruction.
• If no command form matches and length is not 64, the low 48 bits are passed to ExecuteScalarInstruction with the original 16/32/48 length.

Rules and interactions

A command execution status maps directly to the top-level executed/rejected status.

A scalar execution status maps in the same way after the command decoder reports no form.

An unmatched 64-bit input begins an architectural instruction attempt, sets Fault_IllegalInstruction at ReadTPC(), and returns rejected.

Architectural boundaries

This dispatcher does not duplicate command or scalar legality and operation semantics; it delegates them to their current owners.

The explicit illegal-instruction path applies only after command decoding fails and the selected length is 64.

Related owners

• Command dispatch owner
• Scalar dispatch owner

Purpose and scope

The execution context is the central owner for the principal architecture-visible scalar, control, fault, memory, maintenance, extended-system-register, and trap-context storage used while PTO executes.

A Core has four private scalar register files. An instruction carries one absolute GPR selector, but each PE resolves that selector in its own register file.

Concepts and state families

• PTO-STATE-ARCH-GPR owns the PE-private register files, while PTO-STATE-ARCH-TEMPORARY-QUEUES owns the T and U value queues together with per-entry validity.
• PTO-STATE-ARCH-PROGRAM-CONTROL owns PC, BPC, bundle activity, return and commit values, and predicate registers; PTO-STATE-ARCH-FAULT owns the last fault and its address.
• PTO-STATE-ARCH-MEMORY owns modeled bytes, reservation state, fence selectors, captured memory events, and the current memory agent.
• Maintenance epochs, extended system registers, ACR-indexed trap metadata, saved trap contexts, and the current ACR belong to their explicitly declared state families in this unit.

Queue rules and interactions

ReadTemporaryQueue selects the T queue when use_t_queue is true and the U queue otherwise, returning the value at the requested relative index.

TemporaryQueueSourceAvailable applies the same T-or-U selection to the validity snapshots and returns the validity entry at the requested relative index. When a push shifts a value, it shifts the corresponding validity entry with that value.

PushTemporaryQueue inserts the new value at index 0, marks that entry valid, and shifts both values and validity from indices 0 through 2 into indices 1 through 3 of the selected queue.

Boundaries

T and U are independent queues: a push to one queue does not modify the value or validity snapshot of the other queue.

A push retains the four newest entries of the selected queue. The previous index 3 entry is replaced when indices 0 through 2 shift upward.

This unit declares shared architectural storage, but it does not by itself define every transition over that storage. Memory ordering, reset, system-register behavior, and trap recovery remain in their dedicated ASL owners.

Related owners

• System-register addressing is the declared dependency for the execution-context unit.
• Memory ordering interprets the memory events stored here.
• Reference profile provides concrete access and trap-context behavior for the PTO v0 profile.

Purpose and scope

This unit collects the fixed namespace sizes used by the PTO programming model and defines the representation bridge between semantic PE identities and the four-bit PE mask.

It is the place to check counts and identity-to-mask indexing. It does not define instruction behavior or memory ordering.

Namespaces and identities

The scalar namespace has 32 register encodings, including 24 absolute GPRs and two temporary queues of depth 4. The unit also fixes 8 predicate registers of width 32, 16 ACRs, 64 Tile registers, and 64 Shared Tile registers.

Semantic PE identities are the integers 0 through 3, conventionally read as PE0 through PE3.

Identity-to-mask rule

PTOPEMaskBitOfPEIdentity maps a semantic PE identity to the corresponding mask index by subtracting it from 3.

This bridge is necessary because PE0 occupies the high bit of the four-bit architectural mask: PE0 maps to bit 3, PE1 to bit 2, PE2 to bit 1, and PE3 to bit 0.

Model boundaries

PTO_MODEL_MEMORY_AGENTS and PTO_MODEL_MEMORY_EVENTS size the executable model at 4 agents and 16 events. Their PTO_MODEL_ names identify them as model bounds; this page does not generalize those values into additional implementation requirements.

Related owners

• Architecture overview is the dependency that establishes the top-level architecture identity.
• Scalar registers uses the current memory-agent identity for per-PE GPR access.
• Tile registers is the named Tile-register programming-model owner.

Purpose and scope

This unit decides whether a captured candidate memory execution is allowed by PTO-TSO. It validates the event set, builds the required ordering relations, and rejects any candidate whose required relation contains a cycle.

The final query, MemoryExecutionAllowedTSO, requires candidate validity and acyclicity of both the same-location execution relation and the externally visible preserved-order relation.

Event relations

• Coherence orders writes to the same location by increasing coherence_rank; reads-from connects a write to a read whose read_from field names that write.
• External reads-from keeps reads whose source is an initial write or belongs to a different agent; from-read connects a read to a distinct coherence successor of the write it observed.
• Same-agent program order at one location and preserved program order across locations provide the two program-order views used by the acyclicity checks.
• A fence contributes an edge only when it lies between two events from the same agent and both event classes match its predecessor and successor masks.

Candidate rules

Every accessed location has exactly one initial-write event, and each initial write has coherence rank 0.

Every later write to a location has a unique nonzero coherence rank with an immediate predecessor at the preceding rank.

Every read names an in-range write to the same location and carries the value written by that source. A successful atomic write immediately follows its read source in coherence order.

PTO-TSO preserves read-to-memory and memory-to-write program order. A write followed by a read of another location is the relaxed pair unless an atomic event, acquire/release order, or a matching fence restores the edge.

Boundaries and fail-closed cases

Mixed-size or partially overlapping accesses are rejected when their ranges overlap but they do not describe the same location. This owner therefore does not silently invent byte-level coherence for such candidates.

An atomic event does not create a from-read edge to its own write side; from-read considers only a distinct coherence successor.

An empty event set is not a valid candidate execution, although the acyclicity helper itself treats an empty relation as acyclic.

Related owners

• Atomicity is this unit's declared dependency and defines the event properties on which ordering relies.
• Memory events defines event construction and capture.
• Execution context owns the captured event array, event count, fence selectors, and current memory agent.

Purpose and scope

This unit owns tile hands, the public five-bit data-type namespace, tile data-layout and storage-layout enums, pad values, and location intent.

It is the boundary between encoded DataType fields and the typed values consumed by numeric and tile execution owners.

Concepts and visible state

• TileHand names T, U, M, and N; TileDataType contains 15 floating/scale members, five signed integer members, and five unsigned integer members.
• TileDataTypeEncoding is bits(5). Codes 0..14, 16..20, and 24..28 are assigned; 15, 21..23, and 29..31 are reserved.
• The unit separately defines transformation-oriented TileDataLayout, physical TileLayout, TilePadValue, and TileLocation namespaces.

Rules and interactions

TileDataTypeEncodingValid accepts exactly the three assigned code ranges; TileDataTypeFromEncoding requires validity before mapping.

TileDataTypeToEncoding is the reverse mapping. Code 0 means TileDataType_FP64, not absent or inherited.

DTYPE_NONE is code 31 and is only a field-level sentinel; it is deliberately not a TileDataType and has no width, format, or arithmetic semantics.

Architectural boundaries

Reserved data-type codes reject before architectural effects and remain available for future extension.

TileLayout_ImplementationDefined exists for non-architectural model fixtures; no assigned B.DATR layout code maps to it.

Related owners

• Numeric format dispatch
• Packed concept
• Hardware numeric profile

Purpose and scope

This unit centralizes fault, service-request, and interrupt entry plus trap-status packing. For synchronous SetFaultWithCause, context save and redirection to a target AccessControlRing occur only when the code is not Fault_None.

Trap-entry state

• SetFaultWithCause records the fault code, address, cause, and trap status for every input code.
• When the code is not Fault_None, it saves context, selects the target AccessControlRing as current, and redirects TPC. For Fault_None, it keeps the source ring and performs neither the save nor the redirect.
• RaiseServiceRequest checks permission, saves a resume TPC four bytes past the source TPC, and enters the service target.
• RaiseInterrupt marks the interrupt pending and enters only when that interrupt is enabled.

State-transition rules

• Synchronous fault entry sets asynchronous false and makes the trap argument valid for nonzero faults.
• Interrupt entry sets asynchronous true, records trap number 44, and places the InterruptID in argument 0.
• ClearFault clears current-ring fault reporting without reconstructing an earlier context.
• PackTrapStatus and UnpackTrapStatus map asynchronous, argument-valid, 24-bit cause, and 6-bit number fields.

Commit boundaries

Fault_BundlePostCommit is represented as a successful-commit boundary trap: the continuation has already been chosen when the context is saved. A denied service request instead raises Fault_IllegalInstruction and returns false.

Related owners

• PTO-ARCH-STATE-TRAP-CONTEXT owns the saved-context representation.
• Trap-context recovery defines the inverse profile path for a recoverable saved context.

Purpose and scope

PTO is defined here as a 64-bit architecture: PTO_XLEN is 64, and the current architecture identity is version 0.

This entry point deliberately stays small. It establishes the top-level ownership, state-closure, completion-and-event, tile-capacity, and release-verification contracts while leaving instruction behavior to the reachable ASL owners.

Concepts and visible state

Architecture-visible state is exactly the closed set of named state owners listed below.

• Scalar and control state comprises PTO-STATE-ARCH-GPR, PTO-STATE-ARCH-TEMPORARY-QUEUES, PTO-STATE-ARCH-PROGRAM-CONTROL, and PTO-STATE-ARCH-FAULT.
• System state comprises PTO-STATE-ARCH-MEMORY, PTO-STATE-ARCH-MAINTENANCE, PTO-STATE-ARCH-SYSTEM-REGISTERS, PTO-STATE-ARCH-EXTENDED-SYSTEM-REGISTERS, PTO-STATE-ARCH-TRAP-CONTEXT, and PTO-STATE-ARCH-GQM.
• Tile and bundle execution add PTO-STATE-TILE-LOCAL, PTO-STATE-TILE-SHARED, and PTO-STATE-BLOCK-CONTROL to that closed set.

Rules and interactions

Current architectural meaning is owned by mnemonic or architecture ASL. Catalogs and Markdown are deterministic projections or evidence, not alternate semantic owners.

Accepted instruction completion and architecture-visible memory events are determined by the reachable dispatch, completion, and memory-event ASL owners.

Every member of the closed state set changes only through an accepted ASL transition owned by the corresponding state unit.

Architectural boundaries

Local and Shared tile allocations use independent capacity pools. One B.IOT Local object may select only 128 B..64 KiB; multiple Local objects on the same PE may jointly consume that PE's 256 KiB Local pool. B.IOS denotes one Core-wide Shared allocation from a separate 256 KiB pool.

A release candidate is valid only for the exact commit that passes the pinned ASL model, all independent AVS results, coverage, projection, and release-evidence checks.

Related owners

• Execution context inventories the principal architectural state and temporary-queue operations.
• Memory ordering defines the event relations used to accept or reject a candidate PTO-TSO execution.
• Reference profile supplies deterministic profile implementations for profile-defined hooks.