the Univac 2200, LLVM, and national security

Project Infrastructure LLVM Dev List Archives
1

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.

2

Please stay on the original thread -- I've addressed your concern there.

3

From: llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org]
On Behalf Of Peter Lawrence via llvm-dev
Subject: [llvm-dev] the Univac 2200, LLVM, and national security

One of my previous jobs was at Unisys doing a dynamic translator for the
Univac 1100 / 2200 series computers.

As technical lead on that project, I feel I have to respond. First, the product name is now Unisys ClearPath; the Univac name has not been used for several decades. Second, Peter's position with the company was terminated after a couple of months for reasons that should now be fairly obvious.

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.

Although much of the above is technically correct, the use of "we" in the above is a bit misleading, since Peter was involved only in very early definition and design discussions, and not at all in the implementation.

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.

Using the term "decrepit" here is a serious disservice to history, Unisys, and our customers, which include numerous airlines, banks, and various government agencies around the world.

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.

The above, of course, is utter gibberish. We work closely with all of our customers and know very well how our systems are utilized.

I'm not going to bother with the rest - there's real work to be done.

- Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

4

::rimshot::