Unisys Phasing Out Decades-Old Mainframe Processor For x86

angry tapir writes: Unisys is phasing out its decades-old mainframe processor. The chip is used in some of Unisys' ClearPath flagship mainframes, but the company is moving to Intel's x86 chips in Libra and Dorado servers in the ClearPath line. The aging CMOS chip will be "sunsetted" in Libra servers by the end of August and in the Dorado line by the end of 2015. Dorado 880E and 890E mainframes will use the CMOS chip until the servers are phased out, which is set to happen by the end of 2015.

Comments

what's the point anymore

[Anonymous Coward]

why go with unisys when their new servers won't run your old crap. god knows anyone buying from them could spec out a xeon server from anywhere.

Re:what's the point anymore

[Vlad_the_Inhaler]

Speaking as someone who programs and administers computers on the Dorado line, that is total bollox. dreamchaser's post is also inaccurate.

Part of the Exec (= OS) is written in Assembler, the rest is in a proprietary language called Plus (a bit like Pascal) or C.
The same applies to processors and libraries provided by Unisys or third parties.
User programs can be in Fortran, Cobol, C or Assembler. Pascal and PL/1 were dropped a few years back, use of Plus in non-Unisys-written code is unsupported.

The key part of the article was Both the OSes will execute tasks on Intel's Xeon server chips through a firmware layer that translates the OS code for execution on x86 chips. Existing programs will work without recompilation, it is the Exec which needs to make the accomodations.

I don't know much (ok, anything at all) about the Libre lines but the Dorado machines have some very unusual characteristics such as 9-bit bytes which would render anything other than hardware compatibility a total disaster necessitating a forced conversion to another platform immediately.

Re:what's the point anymore

[idontgno]

I don't know much (ok, anything at all) about the Libre lines but the Dorado machines have some very unusual characteristics such as 9-bit bytes which would render anything other than hardware compatibility a total disaster necessitating a forced conversion to another platform immediately.

Right. Goes back to the multiple-of-9-bit native word length of the the entire 11xx/22xx heritage, back to the Univac 418. Since bytes aren't the native access mode in that architecture anyway, they're an afterthought and rather harder to code for in assembler.

That's not the only oddity of that architecture, too. 1s complement math? Negative zero?

Yeah. I'm an old grey geek that started out on an 1180 back in the day. Mostly assembler real-time stuff.

I'm a bit misty-eyed at the thought of that heritage code running, essentially, by run-time emulation rather than natively.

Sic transit gloria mundi.

Re:what's the point anymore

[Waffle Iron]

the Dorado machines have some very unusual characteristics such as 9-bit bytes

Now I'm picturing Nigel in front of a rack of Unisys machines:

"These go to nine bits."

Re:what's the point anymore

[Darinbob]

The 8-bit bytes is really sort of arbitrary. For quite some time there were many computers that did not have character addressible memory and the focus was on what word size was best. 36 bits words were common for some time, with an 18-bit half word being used on decsystem 10 which could hold a word pointer. So that 36 bits could either be 4 8-bit characters with an extra 4 bits for meta information (often used by garbage collector), or else 4 9-bit characters, 5 7-bit characters, or even 6 6-bit characters. Especially when your output device is a teletype with upper-case only, 6-bit characters make sense.

The original Dungeon/Zork game was written for decsystem 10 in a sort of unusual Lisp dialect, and that source code has some stuff that just won't work in a straight forward way on a 32-bit machine; 5 characters stored in a word, a word that stores 34 bit flags, and so on.

Half a century

[Animats]

That's over half a century of the UNIVAC 36-bit architecture, going back to the UNIVAC 1107. The operating system in use today, originally EXEC 8, later OS 1100, later OS 2200, first ran on the UNIVAC 1108 in 1966.

Some programs from the 1970s will still run today. Some from that era are still being maintained and distributed.

Re:Half a century

[_merlin]

I first became aware of Unisys in the '80s when the Australian TV broadcasters used their stuff for instant replay, drawing annotations over stills, and slow motion. They got to display their "Unisys Computer" logo in the corner. Never actually had to use them professionally though. Looks like the future is becoming homogenous. IBM dropped the specialised AS/400 and System Z CPUs and migrated to POWER; everyone else seems to be dropping specialised CPUs and moving to x86 or POWER as well.

Re:Half a century

[Anonymous Coward]

Yep, X86 is definitely taking over. http://regmedia.co.uk/2011/01/05/nvidia-arm-x86-shipments.gif

Re:Half a century

[Guy Harris]

Uh, I thought this was the descendant of Burroughs B5000? You know, the computer that Alan Kay tells everyone to take a look at to understand how silly today's architectures look in comparison.

It's both the descendants of the 36-bit Univac 1108 and the 48-bit-plus-tags Burroughs 6500 (very much like, but not compatible with, the B5000).

Re:Half a century

[_merlin]

Probably depended on the broadcaster. Whoever had the rights to broadcast the cricket in Sydney in the late 80s was using Unisys, and displaying their branding.

Re:Half a century

[Required Snark]

The Burroughs part is a tagged memory architecture. There is no assembler, a variant of ALGOL is the system programming language. It's a hardware stack machine. Each memory word has tag bits that identify what kind of information is stored. Memory addressing is through segments, which do hardware bounds checking. Check out http://en.wikipedia.org/wiki/Burroughs_large_systems for details.

The hardware and software were designed concurrently. This means that the system is very efficient and not very prone to software errors. Because of the hardware addressing mechanisms and the memory protection bits, this machine was immune to many of the security issues that plague modern CPU architectures. It is near to impossible to break security, because it is enforced by a combination of hardware and software. No current x86/Power/Sparc/??? will ever be as secure as this kind of machine. (The Mill CPU has some of the same characteristics, but lacks tagged memory bits in main memory.)

As a field, computing took a wrong turn when it went after MIPS as a measure of "goodness". Using hardware resources to enforce secure computing address the fundamental problem of writing reliable software. It protects against coding errors and against malicious attacks. Now that hardware is cheap, the additional cost of tag bits in memory or address range checking could be easily supported.

But we're stuck with fast insecure architectures and there seems to be no turning back. It wouldn't be surprising that current systems are in fact less efficient when you take into account the cost of trying to make insecure hardware secure along with the costs associated with software failures and stolen data, corrupted data bases, down time, debugging, etc. (By the way, Burroughs systems had great up times, which was also true of Symbolics Lisp systems, which also had memory tag bits and was programmed from the bottom up in a high level language.)

Re:Half a century

[Animats]

Uh, I thought this was the descendant of Burroughs B5000? You know, the computer that Alan Kay tells everyone to take a look at to understand how silly today's architectures look in comparison.

That's the other Unisys line; they have an A-series (from Burroughs) and a B-series (from UNIVAC).

I used a B5500, at UC Santa Cruz, in a summer course on computer architecture in 1975, taught by one of its designers. Burroughs donated the obsolete machine, and we stepped it through instructions from its maintenance panel, watching the stack hardware work. We were also taken up to Xerox PARC to meet Alan Kay and see the original prototype Alto machines, years before Steve Jobs did. (They were really Data General Nova machines inside, with different microcode.)

Burroughs machines never matched C well. It's an assumption of C that the memory is one big numbered address space. That's not how the Burroughs machines work. Memory, as seen by user programs, is a tree, like a file system. A local variable has an address something like Program7.Function23.Variable3(numeric). As with a file system, you don't know the underlying hardware address.

The basic type on those machines is a 48-bit number. Integers and floating point numbers have the same format. The word has a sign, an exponent sign, an exponent, and a mantissa. The binary point is at the low end. So integers up to 2^32 and floats have the same representation. The hardware will convert a result to float when it overflows an integer. This, again, is something C isn't ready for.

Computerworld is a little slow

[rudy_wayne]

http://esj.com/articles/2010/1...

Oct 19, 2010

" This week the company updated its Libra and Dorado mainframe lines, touting a new all-Intel architecture,"

Re:Unisys Binary Translation

[tlambert]

http://www.compilerjobs.com/db/jobs_view.php?editid1=525

So they are looking for Rosetta - the technology Apple acquired for running PPC binaries on the x86 using binary translation.

Well, good luck to them; even though they could just license the technology, they probably won't. The job posting says they are relying on LLVM-IR as a means of translating the code.

In case they care, Apple acquired the company that produced Rosetta, so that's where you want to start to license it, or Facebook last year acquired a small company that did the same type of thing. I doubt they'd be able to hire the engineers away from Google, but if they're interested, Google has NACL and PiNACL which have to use similar techniques.

It's funny how everything old is new again, isn't it? IR is basically becoming ANDF from 1989 http://en.wikipedia.org/wiki/A...

...and there's a good reason that Avie Tevanian went with "fat binaries" instead of TenDRA style ANDF or IR, and there's a good reason we (at Apple) extended it to Intel systems, rather than continuing on with Rosetta (though, to be fair, there isn't really a technical reason for the death of Classic or Rosetta, other than a broken build and archival process, really).

IBM Z still uses custom CPUs

[sirwired]

IBM Z-series mainframes still use a customized CPU, although the i-Series did indeed move to POWER some time ago.

http://en.wikipedia.org/wiki/I...

Re:IBM Z still uses custom CPUs

[TheRaven64]

The Z-series and POWER are not quite separate chips. They're separate instruction decoders but they're largely the same pipelines after that. There are some tweaks, but within a generation they share more design than either does with the previous generation of the same processor.

Re:IBM Z still uses custom CPUs

[MoonlessNights]

That largely applies to pretty much everything but there are actual cases where Z and P are incredibly different so unifying their back-end implementations will be potentially limiting in the future. Specifically, I am referring to memory coherence model: Z assumes a rigid write-back ordering where P allowed these to be highly out of sync, between cores. Now, I am not sure if any modern P implementations actually exploit this flexibility so the difference might be moot but this decision could be limiting in the future.

Such an architecture still exists . . .

[Latent Heat]

you mean X86? (ba-doom boom!)