A Formal Instruction Set Architecture Definition

XCore Project reviews, ideas, videos and proposals.
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

A Formal Instruction Set Architecture Definition

Post by lilltroll »

I found this impressive work presented by Steve Wright
https://www.xcore.com/projects/formal-i ... tion-xcore

that XMOS has agreed to make fully public including code.
10 Results
10.1 Specification Improvements

Formal construction of the ISA specification revealed several issues in the published
specification, generally falling into three classes. Direct errors occurred where a
compiled executable would not execute under the specified behaviour: examples of
these were certain incorrectly specified operand field locations within an instruction.
Ambiguities can exist which can be open to misinterpretation and potentially lead to
differences in behaviour: for example addition calculations being in fact modulo
operation rather than a conventional addition with supporting exception condition on
overflow. Finally, omissions of certain functional conditions were discovered,
typically esoteric exception scenarios. For example, the requirement for dissimilar
destination registers during dual-destination instructions enabled discovery of an
undocumented exception implemented by the XCore for these instructions: the actual
machine robustly detects this error condition and yields an exception. Another
instruction was specified with different behaviours depending on the value of one of
its included immediate fields. Separate refinements were constructed for the two
forms of the instruction from separate abstract events, effectively defining separate
instructions, with differing exception conditions
From chapter 12
Completion of the model has driven the enhancement of the employed methodology
and tools, and numerous corrections to the existing ISA specification have been
identified and reported via the XMOS reporting system. The technical aspect of the
project has been dominated by the complexity of functionality specific to the XCore
ISA, and the model provides a valuable test-article for further analysis. Enhancements
made to the Rodin tool’s automatic prover have been submitted to the open-source
community for inclusion into further releases
1) What does this mean for the toolchain ?
Will this type of work fix small differences between the simulator and the real ISA, and thus also change the asm->machinecode compiler.

2) What is the problem in general that there is opcodes that isn't specified?
I know that the commodore C64 had many opcodes that didn't correspond to a documented operation, but some of the could be used anyway. On the other hand that made emulation of the C64 into a large amount of work, since the emulator had to emulate all possible opcodes that a programmer could use and the outcome of that.


Probably not the most confused programmer anymore on the XCORE forum.
User avatar
matrix
Active Member
Posts: 62
Joined: Sat Sep 17, 2011 12:05 pm

Post by matrix »

Hi Lilltroll,
1) What does this mean for the toolchain ?
Will this type of work fix small differences between the simulator and the real ISA, and thus also change the asm->machinecode compiler.
Is there currently a way to estimate the worst- and best case of the differences, given the current
toolchain ?

Matrix
User avatar
stevewright
New User
Posts: 3
Joined: Mon Sep 26, 2011 4:57 pm

Post by stevewright »

Hello Folks,

Many thanks for the interest, and the excellent questions.

> What does this mean for the toolchain ?
The good news is that the issues found will not effect the toolchain, as both the compiler and assembler match the ISA exactly: the mismatch was in the published doc. Where it gets interesting would be for the low-level programmer writing assembler or someone creating a new binary generator tool. It is especially interesting for stuff involving exception triggering. For most systems this doesn't matter, as these systems are fair weather sailors: it gets important for safety critical and security systems, which suffer from physical corruption or injected attack.

> fix small differences between the simulator and the real ISA
I didn't have time to write one, but one of most useful aspects of this kind of formal analysis is the way it drives testsuite coverage (see my paper http://www.springerlink.com/content/q045464k553448j6/). If this gets done in the future, it will allow a thorough comparison of simulator and silicon under all these weirdy conditions.

>What is the problem in general that there is opcodes that isn't specified?
This isn't a problem with the ISA, more an incompleteness in my formal model: XMOS have deliberately left some placeholders in the ISA to accomodate new instructions in a future porduct. At the moment, hitting them will yield an ET_ILLEGAL_INSTRUCTION exception.

Cheers

Steve
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

stevewright wrote:Hello Folks,

Many thanks for the interest, and the excellent questions.

> What does this mean for the toolchain ?
The good news is that the issues found will not effect the toolchain, as both the compiler and assembler match the ISA exactly: the mismatch was in the published doc. Where it gets interesting would be for the low-level programmer writing assembler or someone creating a new binary generator tool. It is especially interesting for stuff involving exception triggering. For most systems this doesn't matter, as these systems are fair weather sailors: it gets important for safety critical and security systems, which suffer from physical corruption or injected attack.

> fix small differences between the simulator and the real ISA
I didn't have time to write one, but one of most useful aspects of this kind of formal analysis is the way it drives testsuite coverage (see my paper http://www.springerlink.com/content/q045464k553448j6/). If this gets done in the future, it will allow a thorough comparison of simulator and silicon under all these weirdy conditions.

>What is the problem in general that there is opcodes that isn't specified?
This isn't a problem with the ISA, more an incompleteness in my formal model: XMOS have deliberately left some placeholders in the ISA to accomodate new instructions in a future porduct. At the moment, hitting them will yield an ET_ILLEGAL_INSTRUCTION exception.

Cheers

Steve

Ahaa I think I earlier found some errors, then I tried the "low level" asm instead of the traditional, e.g.

LDWI .....

instead of

ldw r0, dp[r1]

Just as an example, but MACCS, LONG ADD and some others didn't have the correct doc, some time ago. Long Div was strange as well.
Probably not the most confused programmer anymore on the XCORE forum.
User avatar
stevewright
New User
Posts: 3
Joined: Mon Sep 26, 2011 4:57 pm

Post by stevewright »

Hello Folks

> Is there currently a way to estimate the worst- and best case of the differences, given the current
toolchain ?
For the "events" in the formal model that correspond to normal operation, the model fully "deterministic", i.e. one-and-only-one event can occur for a given set of events. Therefore, there should be no difference between simulator and silicon - the testing that I referred to earlier would demonstrate this.

However, the model is deliberately "non-deterministic" for multiple, simultaneous exceptions occuring (a tall order, but it could be made to happen). This means that the precidence of one exception over another is not specified, and two implementations (e.g. sim and si) could *conceivably* implement them differently. It seems a pedentic point, but again people get worried about these things an security applications - for example, it's an issue in the JVM world.

Cheers
Steve