[llvm-dev] the Univac 2200, LLVM, and national security

[Peter Lawrence via llvm-dev]

John,
         One of my previous jobs was at Unisys doing a dynamic translator
for the Univac 1100 / 2200 series computers.  We chose LLVM for the base
of the translator for its modularity, optimizations, and x86 code generation.
We wrote a front-end that parsed Univac instructions and generated IR
for them. It all ran on X86-Linux boxes which with some special peripheral
adaptors were then plug-in replacements for Univac hardware.

You might be wondering what anyone was doing with the very ancient and
very decrepit Univac computer, which it turns out is a very interesting question.

The problem is that no one at Unisys knows for sure what was being done with
Univac computers because it is classified top secret information, no one at Unisys
had that clearance, and if they did they couldn’t talk about it.

But there was plenty of speculation. The Univac computer was popular around
the time of the start of the Cold War, so most folks believed there are Univac
computers that are running our nuclear missiles and our strategic defense,
that for various reasons can’t be upgraded. In particular some of the source
code no longer exists, hence the need for a dynamic translator to execute
the existing binaries.

So where is this discussion going, another great question.

Now imagine that somewhere in these Univac binaries, for which source code
no longer exists, there is something that translates to something like
	foo (int a) {
		if (a == a)
			S;
	}
I know it is a stretch, but imagine this is the result of some other optimizations,
and suppose that ‘a’ ends up “undef”, by some other sequence of optimizations,

Then it is possible that in spite of the intention that statement ’S’ always gets
executed, this can’t be guaranteed in the current LLVM.


So the question about what the compiler should do in the case of function-
inlining suddenly isn’t so academic, it is possible that our current nuclear 
missiles and strategic defense actually require a consistent behavior.


So I hope you will join me in thinking LLVM should exhibit consistent behavior
in these sorts of situations, regardless of what might be allowed by the C
standard.


Peter Lawrence.