Grumbling

Here are some issues in software platform design without good answers. Don’t expect suggestions in this note; I see no general proposals. I do hope to illuminate some pit-falls however. I will discuss floating point state first but potential problems such as these extend beyond FP.

There are ‘flags’ which FP ops conditionally turn on to report events that some program’s need to sense, and others can ignore. Flags can be read by the program and they stay on until turned off by explicit program command.

The program provides ‘control bits’ which govern rounding modes. More control bits indicate which of the events that set flags should also cause a fault. I reserve “information” to refer to flags and control bits in the text below.

The general question concerns the ‘scope’ of such information. ‘Scope’ is vague so I innumerate some of the specific problem under this category:

When a subroutine is called, which of this information is accessible to the callee?
Upon return which of this information is restored to the state at the call?
If a ‘thread’ is spawned, does it get this information?
When a program waits for the termination of a thread can it query the flags of the finished thread?

Few platform specifications answer these questions.

One of the problems that muddy these questions is the expansion of the concept of subroutine to calls across protection boundaries. Other words for such concepts are ‘portal calls’ or ‘gate calls’. A portal call may be programmed by someone to an untrusted program that should not have access to this information. The programmer of that call site may not even have heard of this information and cannot be expected to stash the information away before the call and restore it afterwards. Also we have not postulated that it is possible for a program to set its flags. Some programming languages may even support such mistrust today, even for ‘normal calls’, except for issues such as these.

The problems outlined above appear even without trust issues. Concepts such as ‘current default rounding mode’ is considered to have the scope of a global variable, and has all of the problems that make global scope an unpopular concept. A program with no notion of FP may rely on two libraries each with their own incompatible strategies concerning this global state. Modern languages provide solutions to these dilemmas for data but not for this information. (C is not a modern language.) It is no wonder that the programmer who must detect ‘inexact value’ (a flag) must go outside the language spec to solve his problem. What ever he finds is unlikely to be portable.

Beyond FP

Some CPUs today include stateful auxiliary units that hold crypto keys or partially accumulated hash information. Must every programmer who codes a subroutine call ponder whether such state should be passed, ignored or hidden from the callee?

Hint

Most programming languages (I can’t think of recent exceptions) buy into the notion of lexical scopes for data references. If a language allowed a rounding mode declaration in a block, many (all?) of these problems would be solved. But what are the implementation consequences? Here may be a good solution in a vastly different context.

Sending data thru a Unix pipe makes the answer clear for its association of pipes with threads which have their own virtual CPUs (in the guise of a register value set) which one imagines includes this information.