llvm dev - Jun 2017 - the Univac 2200, LLVM, and national security

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.

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

On Wed, Jun 28, 2017 at 11:35 PM, Peter Lawrence
<peterl95124 at sbcglobal.net> wrote:
> 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.
>
>
>
>
>

> From: llvm-dev [mailto:llvm-dev-bounces at 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.

On Thu, Jun 29, 2017 at 2:53 PM, Caldarale, Charles R via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > From: llvm-dev [mailto:llvm-dev-bounces at 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.
>
::rimshot::
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170629/ae94dddc/attachment.html>