Overview

Not every SLEIGH-versus-hardware mismatch is a fixable specification bug. This chapter separates decoding and semantic defects from unsupported behavior, feature or configuration mismatches, unpredictable results, unmodeled state, language limits, and one-instruction experiment boundaries. It then connects each class to a response: edit and retest, implement or mark a boundary, represent uncertainty, improve the reference, extend the language, or add completeness and sequence testing. Proposed SLEIGH improvements address both maintainability and expressiveness, but remain proposals rather than validated guarantees.

Learning outcomes

A mismatch is evidence to classify, not automatic proof of a SLEIGH defect.
Wrong decoding or semantics can be edited, while unsupported behavior, unpredictability, and language limits need different responses.
SLEIGH proposals for templates, helpers, vector and floating-point constructs, uncertainty, and alignment address distinct assurance gaps but are not validated guarantees.

Keywords

SLEIGHtriagesemanticsalignmentfloating-pointuncertainty

Where Correctness Meets the Language's Limits

This chapter diagnoses the boundary between a SLEIGH specification defect and a mismatch that the current language, architecture, or experiment cannot represent cleanly. The focus is repairability: when should a maintainer edit a constructor or semantic definition, when is a language extension needed, and when must the result remain explicitly uncertain? The reader should leave with a classification model that treats every discrepancy as evidence worth explaining without treating every discrepancy as a confirmed bug.

The distinction matters because the differential method can be more sensitive than the language being tested. A hardware comparison may reveal a real alignment exception that current SLEIGH has no direct way to state. It may expose a floating-point format or rounding rule that the p-code layer does not model. It may encounter an architecturally unpredictable output for which hardware supplies one result but no universal expected value. These are not reasons to discard the observation. They are reasons to state what kind of correctness the specification can currently support.

Not every mismatch is a fixable specification bug

Begin with the observation: the SLEIGH-derived emulator and the hardware reference produced different recorded outcomes for a generated instruction and initial state. The first diagnostic question is whether the instruction was decoded correctly. A wrong constructor, missing context condition, bad overlap rule, or incorrect ordering can select the wrong form before semantics are even considered. If decoding is right, the next question is whether the p-code expresses the architectural effects correctly: the operation, width, flag, default result, memory access, and order of reads and writes.

Those are ordinary specification defects in the sense that the represented behavior can be repaired by editing the model. The study found examples of an operation expressed with the wrong Boolean operator, a byte store represented as a word store, and division-by-zero behavior left to an execution environment rather than specified. It also found aliasing mistakes in which a source was overwritten before a later p-code operation had consumed it, or a temporary of the correct width was updated without writing the result back to the architectural destination. These failures are within the semantic contract the specification is attempting to express. A targeted state makes them visible; a maintainer can in principle change the specification and retest.

The next possibility is unimplemented or unsupported behavior. SLEIGH permits placeholder or custom p-code operations for instructions whose semantics are not fully represented. A SLEIGH-based emulator cannot execute an absent semantic body in the same way as hardware. Similarly, a specification may refer to model-specific registers or other processor state that the test environment does not represent. The resulting discrepancy is useful evidence that the toolchain has a fidelity boundary, but it should not be counted as an ordinary semantic typo without investigating what is missing.

A related case is a feature mismatch between the specification and the reference. The specification may include an instruction or extension that is not enabled in the hardware configuration used for testing.

Published by DeepMox

FAQ

When is a SLEIGH mismatch a specification defect?

It is a specification defect when the intended architectural behavior is defined and the current constructor or semantic definition expresses it incorrectly, such as a wrong operator, width, default, or read/write order.

Why might a hardware mismatch require a language extension?

It may require a language extension when the behavior depends on properties current SLEIGH cannot express cleanly, such as alignment requirements, floating-point formats or rounding, vector semantics, or explicit unpredictability.

How should unpredictable processor behavior be represented?

It should be represented as uncertainty rather than corrected to whichever value one hardware run returns, because an unpredictable result has no universal expected value.

Previous12 minSLEIGH Validation Across Five Architectures

Next12 minSLEIGH Correctness Is a Process

SLEIGH Limits and Mismatch Triage

Where Correctness Meets the Language's Limits

Not every mismatch is a fixable specification bug

FAQ