An extension nobody upstream will verify

A custom instruction set extension belongs to the vendor, and so does the correctness argument for the toolchain that lowers onto it. Every downstream customer inherits whatever confidence the vendor was able to produce.

Three artifacts that have to agree

The specification, the reference implementation and the shipped compiler are three separate artifacts, and keeping them in agreement is a testing problem that never closes. A release of any one of them reopens it.

Where the three are one artifact read at different levels, agreement stops being something to test for and becomes something to prove.

A custom extension in a 32 bit instruction word, and the three artifacts that define itA 32 bit instruction word divided into its fields, each marked with its bit range. The function fields and the opcode are marked as the custom extension. Below the word, three boxes labeled specification, reference and compiler, each connected to one box beneath them labeled one executable specification.One 32 Bit Instruction Word3125funct72420rs21915rs11412funct3117rd60opcodeThe ExtensionCustom Opcode SpaceThree Artifacts, Kept in Agreement by TestingSpecificationReferenceCompilerOne Executable SpecificationRead at every level, so agreement is proved
A custom extension occupies the opcode space the base ISA leaves open, and the vendor holds all three artifacts that have to agree on what it means. One executable specification, read at every level, is what makes that agreement provable rather than tested for.

LOGOS

One specification, read at every level

LOGOS is an executable specification. The same text is the reference, the input to the compiler and the subject of the proof, so an extension ships with an argument rather than a test report. The language is described under LOGOS, the language.

The language first? LOGOS, the language

Shipping an extension of your own?

Contact our team