Further double work

I updated scope_rt to use the "double read and compare" method to reliably sample doubles. I also created a test component designed to detect half-stored doubles. Update: I also tested on a 64-bit system.

And things look good so far!

Reliably capturing doubles

It's tricky in scope_rt to capture doubles, because the design calls for it to be able to do so even when not running in a thread with floating-point. This means it has to use only integer instructions to do it.

There are two cases: scope_rt is interrupting a slower thread (including a userspace component), or it is interrupted by a faster thread.

In the first case, the basic atomicity guarantee says that scope_rt will accurately read either the old value or the new value, but never a value between the two.

In the second case, it's possible that scope_rt is interrupted after the first half is read and reads a different second half after it is returned to.

To fix this, I borrow a trick I learned from jmkasunich in stepgen, which is to read the 8 bytes twice; if the values match, then it must be a consistent read.

Testing reading and writing of doubles

The 'doubletest' component produces a sequence of special numbers: the numbers are ones that can be exactly represented by doubles. They are of the form i + i / 2^32 with i being an integer. This number has bits set in both 32-bit halves, and those bits are both related to "i" because of the form of the numbers. The "update" function repeatedly writes numbers of this form to an output, and the "check" function repeatedly checks that the input value is in the correct form.

So far I've let this run for several hours with very fast threads (8us and 32us) and I haven't yet captured an incorrect result. However, the hypothetical window for trouble is very small window--if it's 1 CPU cycle, that's less than 1ns. These threads are loading the system severely enough that the fast thread appears to interrupt the slow thread multiple times (judging from thread times and function tmaxes), so maybe it a test that would routinely hit this <1ns window if it existed. However, my confidence stems much more from my analysis of gcc's generated code and processor datasheets than from a specific test to find a possible 1ns window for incorrect results.

Files currently attached to this page:

doubles-rev2.patch	14.4kB
doubletest.comp	388 bytes
doubletest.hal	435 bytes

Further double work

Tags:

Reliably capturing doubles

Testing reading and writing of doubles