Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Unisys Phasing Out Decades-Old Mainframe Processor For x86

Soulskill posted about a month and a half ago | from the get-off-my-lawn dept.

Hardware 113

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.

cancel ×

113 comments

Sorry! There are no comments related to the filter you selected.

UniSys? (-1)

Anonymous Coward | about a month and a half ago | (#47260693)

Dead or alive?

DEAD!

Re:UniSys? (1)

Dcnjoe60 (682885) | about a month and a half ago | (#47262333)

Dead or alive?

DEAD!

We won't know until somebody opens the box and looks.

Unisys's (0, Offtopic)

Anonymous Coward | about a month and a half ago | (#47260701)

Not Unisys'

Re:Unisys's (1)

Chrisq (894406) | about a month and a half ago | (#47261025)

Unisys's

Not Unisys'

Yes but hypothetically Multisys'

Re:Unisys's (0)

Anonymous Coward | about a month and a half ago | (#47262827)

Worked for Unisys ages ago. Their custom chip fab design building shut down years ago...

Re:Unisys's (1)

BronsCon (927697) | about a month and a half ago | (#47264527)

Actually [oxforddictionaries.com] ...

what's the point anymore (2, Interesting)

Anonymous Coward | about a month and a half ago | (#47260705)

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 (1)

dreamchaser (49529) | about a month and a half ago | (#47261317)

Probably because there is so much old code, and the new servers will just require a recompile rather than outright porting to a new OS?

Re:what's the point anymore (1)

halfdan the black (638018) | about a month and a half ago | (#47262433)

Wrong. If Unisys mainframes are anything like IBM s390, then almost everything is written in assembler. So, unless they have a whole hardware translation / emulation layer, you can't just re-compile. Going to a new processor architecture if everything is written in assembler, its much easier just to throw everything out and re-start.

Re:what's the point anymore (0)

Anonymous Coward | about a month and a half ago | (#47262587)

RTFA

Firmware layer that translates the OS code for execution on x86 chips.

Re:what's the point anymore (5, Informative)

Vlad_the_Inhaler (32958) | about a month and a half ago | (#47262905)

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 (5, Interesting)

idontgno (624372) | about a month and a half ago | (#47263059)

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 [wikipedia.org] . 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 (1)

jandrese (485) | about a month and a half ago | (#47263501)

Wow, color me amazed that such an architecture still exists in 2014.

Re:what's the point anymore (1)

riis138 (3020505) | about a month and a half ago | (#47263761)

You know what they say, if it ain't broke....

Such an architecture still exists . . . (2)

Latent Heat (558884) | about a month and a half ago | (#47264275)

you mean X86? (ba-doom boom!)

Re:what's the point anymore (1)

Darinbob (1142669) | about a month and a half ago | (#47265309)

36 bit words were very common for awhile, so a 9-bit byte is a somewhat natural extension from that. Such architectures existed as current state of the art models at the same time as the x86 direct ancestor, the 4004 was born.

It seems a bit ironic that some people here seem to think that throwing all the old Unisys software and starting from scratch so that it can be replaced by a chip that has never been able to throw off its old baggage or compatibility shackles. After all today's core i7 processors are all a direct descendant for the 4004, with a continuous unbroken backwards compatibility (if sometimes as the result of a promise of automatic assembler translation).

Re:what's the point anymore (1)

sconeu (64226) | about a month and a half ago | (#47263535)

Is Plus a derivative of SPRITE? When I interviewed at Burroughs back in '84, they were all excited about their new language SPRITE.

Re:what's the point anymore (0)

Anonymous Coward | about a month and a half ago | (#47263763)

Little nitpicking for sake of clarity:

Assembly: is a low-level programming language for a computer, or other programmable device, in which there is a very strong (generally one-to-one) correspondence between the language and the architecture's machine code instructions.
Assembler: is a program which creates object code by translating combinations of mnemonics and syntax for operations and addressing modes into their numerical equivalents.

Re:what's the point anymore (1)

AdamHaun (43173) | about a month and a half ago | (#47264041)

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

Nice to know there's still some non-DSP hardware out there with oddly-sized bytes. Maybe not so nice if you have to develop for it, but it gives me examples to point to when people ask why C's data types are defined the way they are.

Re:what's the point anymore (2)

Darinbob (1142669) | about a month and a half ago | (#47266259)

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.

Re:what's the point anymore (3, Funny)

Waffle Iron (339739) | about a month and a half ago | (#47264243)

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."

RTFA (1)

IwantToKeepAnon (411424) | about a month and a half ago | (#47262481)

The switch to x86 processors won't affect existing Unisys customers looking to upgrade older mainframes with faster systems. x86 Dorado servers will continue to support the ClearPath OS 2200 operating system, while the Libra line will support the ClearPath MCP operating system. 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.

Half a century (5, Informative)

Animats (122034) | about a month and a half ago | (#47260715)

That's over half a century of the UNIVAC 36-bit architecture, going back to the UNIVAC 1107 [wikipedia.org] . 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 (4, Interesting)

_merlin (160982) | about a month and a half ago | (#47260781)

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 (1)

Anonymous Coward | about a month and a half ago | (#47260821)

I thought the special effects of that nature in the 80s were done by Qantels?

Re:Half a century (2)

_merlin (160982) | about a month and a half ago | (#47261037)

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 (1)

torsmo (1301691) | about a month and a half ago | (#47263085)

I remember seeing a test match between Australia and New Zealand on Nine, which had the Unisys logo, if my memory serves me right.

Re:Half a century (2, Informative)

Anonymous Coward | about a month and a half ago | (#47260823)

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

Re:Half a century (1)

Ginger Unicorn (952287) | about a month and a half ago | (#47261381)

The graph flattens off and starts to dip at 2009, then the steep rise after that is an estimate. they could just have easily drawn a line going downwards.

Face the music & answer 2 questions troll (-1)

Anonymous Coward | about a month and a half ago | (#47261531)

Re:Half a century (1)

bytesex (112972) | about a month and a half ago | (#47260873)

Wasn't Unisys in the eighties still Sperry and Univac?

Re:Half a century (1)

Anonymous Coward | about a month and a half ago | (#47260897)

They merged in 1986.

Re:Half a century (1)

Vlad_the_Inhaler (32958) | about a month and a half ago | (#47262995)

Sperry Univac was one company back then, probably formed by a merger or takeover in the 60's or 70's (I can't be bothered to look up Wackypedia).

What happened in 1986 was that Burroughs' CEO (Michael Blumenthal, previously Secretary for somethingorother in the Carter administration) launched a Leveraged Buyout of Sperry. Sperry fought it but lost, the resulting company was then renamed Unisys and had so much debt from the takeover that it had to divest assets to simply survive. Blumenthal himself did very well out of the deal, I don't think anyone else did.

WRONG (0)

Anonymous Coward | about a month and a half ago | (#47261039)

IBM still develops new generations of S/360 processors. POWER is still developed for AS400 and Unix.

IBM Z still uses custom CPUs (2)

sirwired (27582) | about a month and a half ago | (#47261231)

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... [wikipedia.org]

Re:IBM Z still uses custom CPUs (1)

RabidReindeer (2625839) | about a month and a half ago | (#47261459)

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... [wikipedia.org]

I was under the impression that the POWER chipset was specifically designed as a chip realization of the iSeries CPU, actually dating back to when it was still the AS/400, possibly even the System/38.

IBM fielded a desktop mainframe (the Model 9000) that contained a pair of Motorola MC68000 chips, one with a special mask for the System/360 instruction set. The instruction architecture of the MC68000 was a lot like the System/360 instruction architecture, so it was a good fit.

Unfortunately, the Model 9000 was a commercial failure.

Re:IBM Z still uses custom CPUs (0)

Anonymous Coward | about a month and a half ago | (#47262365)

Technically they could run on x86-64+emulator (like the FX!32 of DEC) without serious perfomance loss. But that would threaten their mainframe-lock-in. So they continue to invest into the S/360 instruction set, despite being not faster than Intel, but of course massively more expensive.

Re: IBM Z still uses custom CPUs (0)

Anonymous Coward | about a month and a half ago | (#47264493)

POWER CPUs are faster than Intel. Though mostly because of the faster clock speeds and gargantuan cache.

Re:IBM Z still uses custom CPUs (1)

Jeremy Erwin (2054) | about a month and a half ago | (#47263961)

Might it have been related to the PC XT 370 [cpushack.com] card and the Micro 370 project?

Re:IBM Z still uses custom CPUs (2)

TheRaven64 (641858) | about a month and a half ago | (#47261589)

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 (2)

MoonlessNights (3526789) | about a month and a half ago | (#47262489)

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.

Re: Half a century (1)

rayzat (733303) | about a month and a half ago | (#47261253)

IBM is deploying system I on power now but they are still making custom z processors for the mainframe, although the mainframe can also have some power and x86 processors they really aren't for mainframe processing just hi RAS local access for offloading certain workloads. It's going to be interesting what arm does. There are multiple vendors looking at arm based servers with hp already having one out.

Re:Half a century (1)

Megol (3135005) | about a month and a half ago | (#47261273)

That is a (in some circles) popular myth but not reality. IBM still designs and manufacture the Z line that still are compatible with (most) old 360 software.
While IBM could use an emulator it would be hard or impossible to keep up the performance running dusty decks and there would be another rather complex emulation layer that would need to be verified while keeping the extreme reliability the customers expect from their mainframes.

What is true is that there is some cross pollination of ideas and building blocks between the Power and Z designs. The designs themselves are quite different.

Re:Half a century (0)

Anonymous Coward | about a month and a half ago | (#47261467)

IBM did have a plan to move mini and mainframe to POWER. Ultimately, system z did *not* make the move, just system i.

Re:Half a century (1)

SemiChemE (3528759) | about a month and a half ago | (#47264251)

Hmm... Did somebody forget to tell IBM? They released their 32nm based z-series chips a couple years back, and appear to be on track to release their next 22nm based chip within the next year.

Re:Half a century (0)

Anonymous Coward | about a month and a half ago | (#47260785)

While this is an extreme, it does make me think how we seem to be in an era of software development dominated by change for the sake of change and rapid, unnecessary obsolescence.

Re:Half a century (1)

K. S. Kyosuke (729550) | about a month and a half ago | (#47260791)

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.

Re:Half a century (3, Informative)

Guy Harris (3803) | about a month and a half ago | (#47260881)

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 (4, Informative)

Required Snark (1702878) | about a month and a half ago | (#47261151)

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 [wikipedia.org] 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.)

Well, (0)

Anonymous Coward | about a month and a half ago | (#47261267)

I disagree with your analysis. Memory-safe languages and their compiler can provide the same "safety" net as stack machines of Burroughs.

See this for an efficient memory-safe variant of C++:

http://sourceforge.net/p/sappeurcompiler/code-0/HEAD/tree/trunk/doc/SAPPEUR.pdf?format=raw

(Yeah, it is from myself and it is quite prototypical,but can already be used)

Re:Well, (1, Insightful)

Nutria (679911) | about a month and a half ago | (#47261413)

Memory-safe languages and their compiler can provide the same "safety" net

But no one uses them.

Re:Well, (1)

Anonymous Coward | about a month and a half ago | (#47261443)

Both Java and C# are memory-safe and in widespread use. They are not delivering utmost efficiency, though. That is because you cannot allocate complex data types on the stack or as an array of object values.

And they don't have destructors, a very elegant, efficient and safety-improving mechanism.

Re:Well, (1)

Anonymous Coward | about a month and a half ago | (#47262025)

Both Java and C# are memory-safe and in widespread use.

That'll be why Eclipse regularly crashes with segmentation faults.

Re:Well, (0)

Anonymous Coward | about a month and a half ago | (#47262307)

I know these problems, but they are down to the incompetence of the JVM implementors. They should have focused on essential functionality, correctness and reliability instead of "lets add new features every year".

It appears MS are doing a much better job with their .Net runtimes.

Finally, you don't need a VM at all - you can compile it into machine code directly. See Sappeur and gcj.

Re:Well, (1)

TheSunborn (68004) | about a month and a half ago | (#47263043)

When Eclipse is crashing with a segmentation fault, it is almost always in swt. So the problem is with the native code which swt calls in order to interface with the underlying operation system.

That can only be solved by writing the entire Operation system in a safe language, but nobody is working on that.

I have newer seen Eclipse segfault outsite swt code.

Re:Well, (1)

serviscope_minor (664417) | about a month and a half ago | (#47263835)

I have newer seen Eclipse segfault outsite swt code.

Then there's either a bug in the JVM, or something in SWT has scribbled over memory creating a segfault later.

Re:Well, (0)

Anonymous Coward | about a month and a half ago | (#47264933)

I have seen the JVM crash on PDFs when running the YaCY Volks-Search-Engine. My understanding is that the PDF parser is pure Java. So yes, the JVM crashes then and now when it certainly should not.

Re:Well, (0)

Anonymous Coward | about a month and a half ago | (#47263385)

jdk and the jre and the jvm are written in c or c++ instead of rust in 2020...

Re:Well, (0)

Anonymous Coward | about a month and a half ago | (#47264259)

Both Java and C# are memory-safe and in widespread use.

That'll be why Eclipse regularly crashes with segmentation faults.

Which is why JVMs are soooo secure, right?

Re:Well, (0)

Anonymous Coward | about a month and a half ago | (#47262917)

BS, as there's no guarantee that malicious code was written in your supposedly 'safe' language.

Re:Well, (0)

Anonymous Coward | about a month and a half ago | (#47263613)

Memory-safe languages and their compiler can provide the same "safety" net as stack machines of Burroughs.

No, they can't, because they don't protect against malicious code deliberately crafted to avoid the checks that the language, compiler, or run-time attempt to enforce. Think someone writing their own compiler or assembler.

Burroughs hardware -- the hardware, mind -- wouldn't run code not tagged as executable by a trusted compiler. Trusted, because only a program marked as a trusted compiler could modify the tag bits on such code. And only the OS (essentially, kernel level) could tag a program as a trusted compiler -- via a console (-only) command.

Sure, still open to a human (the system operator) messing it up. In my B6700 days I came up with two theoretical hacks, one involving DCALGOL (which implies you've already got the equivalent of root access anyway) and another involving the manipulation of a Burroughs backup tape on a non-Burroughs machine (you'd need access to get the tape loaded, and the backup format was security by obscurity).

-- Alastair

No, Sappeur can (0)

Anonymous Coward | about a month and a half ago | (#47265101)

On slide 11 and 12 of the Sappeur presentation I propose exactly the approach you describe for Sappeur programs, plus some Public-Key assurance.

http://sourceforge.net/p/sappeurcompiler/code-0/HEAD/tree/trunk/doc/SAPPEUR.pdf?format=raw

You could actually rid yourself of the MMU, if you only ran code from "trusted" compilers.

(Precisely speaking there is not yet a "private" specifier for Sappeur class members, but that would be quite trivial to add to the existing compiler. That is of course a precondition for this scheme to work. MS has been doing it with their C# language: http://en.wikipedia.org/wiki/Singularity_%28operating_system%29)

Re:Half a century (0)

Anonymous Coward | about a month and a half ago | (#47262555)

Oh for mod points. I cut my teeth on a Burroughs 6700 in the '70s. (Also worked for SMBX) Awesome architecture.

Re:Half a century (0)

Anonymous Coward | about a month and a half ago | (#47263663)

The hardware and software were designed concurrently. This means that the system is very efficient and not very prone to software errors.

citation needed.

i can give you lots of examples of concurrent hardware/software design that didn't work out well.
consider most vendor drivers!

Re:Half a century (1)

Darinbob (1142669) | about a month and a half ago | (#47266327)

A problem with Burroughs' machines though is that they kept a tight control over the languages that could be used with it. At my university someone had wanted to write a Lisp system for it and needed to actually get permission from Burroughs first lest their code break other programs on the system. In some sense a part of the security involved only using approved Burrough's tools. because you really could screw up the machine if you used some code that did unusual things (there may not have been an assembler, but there was machine code).

Re:Half a century (1)

Nutria (679911) | about a month and a half ago | (#47261389)

I thought this was the descendant of Burroughs B5000?

TFA explains that one line is from Sperry, and the other from Burroughs.

Re:Half a century (2)

Animats (122034) | about a month and a half ago | (#47265121)

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.

Re:Half a century (1)

Jecel Assumpcao Jr (5602) | about a month and a half ago | (#47266227)

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.)

The Altos were not too Nova-like, but the built-in part of their microcode did implement the Nova instruction set (except that the I/O instructions were used for other stuff). Alan had been previously using Novas in his projects (Smalltalk-72 was first implemented in Nova BASIC and then assembly, for example) and this allowed him to quickly port to the Alto.

Goodnight Sweet Prince (0)

Anonymous Coward | about a month and a half ago | (#47260731)

I wonder if it'll end up in a trash heap or whether it's enough of a relic to be put in a museum

Captcha: Fortify

Goodnight Sweet Prince (0)

Anonymous Coward | about a month and a half ago | (#47261279)

I wonder if you can simply hit your fingers with a hammer and stop bothering us.

I'm still mad... (0)

edibobb (113989) | about a month and a half ago | (#47260753)

I'm still mad at Unisys for abusing the GIF patent.

Re:I'm still mad... (-1)

Anonymous Coward | about a month and a half ago | (#47261001)

Then don't read wiki, poser! The only thing you are mad about is no one gives a shit what you think.

Re:I'm still mad... (1)

Darinbob (1142669) | about a month and a half ago | (#47266333)

Hurray for PNG though, too bad it took so many years for major browsers to adopt it.

Case Mod (1, Offtopic)

smitty_one_each (243267) | about a month and a half ago | (#47260769)

I want to case mod an old AN/UYK-7 chassis and panel with a multi-core motherboard and storage. Anyone know where to shop?

Computerworld is a little slow (3, Informative)

rudy_wayne (414635) | about a month and a half ago | (#47260825)

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

Oct 19, 2010

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

Re:Computerworld is a little slow (0)

Anonymous Coward | about a month and a half ago | (#47260987)

The old line was kept around until the Intel versions were sufficiently mature and fast enough for all existing workloads.

Re:Computerworld is a little slow (1)

Anonymous Coward | about a month and a half ago | (#47261063)

x86 was powerful enough for at least 10 years now. It was probably much more due to "business" (customer lockin) reasons, inertia (those folks developing that Unisys CPU) and a lack of a proper binary translator from Unisys.

IBM did some research on binary translation as far back as the 1990s. DEC had the FX32! translator which demonstrated that the concept is quite feasible.

IBM still has the financial resources to develop CPUs for a niche market, because their three niches (mainframe, mini, Unix) are large enough to fund the CPU design efforts. The technical "edge" (e.g. error correction/detection features) from their own CPUs is rather moderate, though. Don't forget that they incur a whole bunch of hardware bugs from their exotic CPUs, also. The IBM mainframe CPU which I dealt with had more serious bugs than the Intel CPUs. Intel simply has more people and money to squash bugs; and they have many more beta users.

Intels economy of scale has essentially taken out all competitors on the high end.

signed

"Der Computer" as they call me in my native country.

Some Unisys Patents, DEC FX!32 (0)

Anonymous Coward | about a month and a half ago | (#47261077)

http://www.faqs.org/patents/app/20140130026

http://en.wikipedia.org/wiki/FX!32

https://www.usenix.org/legacy/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf

Sad how this great American company DEC was killed by bozo competitors like Bill Gates.

Unisys Binary Translation (1)

Anonymous Coward | about a month and a half ago | (#47261091)

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

Re:Unisys Binary Translation (3, Interesting)

tlambert (566799) | about a month and a half ago | (#47261221)

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... [wikipedia.org]

...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).

Re: Unisys Binary Translation (0)

Anonymous Coward | about a month and a half ago | (#47262251)

Apple did not acquire Transitive. They licensed the technology.
IBM acquired Transitive.

Re:Unisys Binary Translation (0)

Anonymous Coward | about a month and a half ago | (#47262927)

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.

Maybe they tried working with Transative in the mid 2000s. Maybe Transative failed. Maybe the Transitive people couldn't do what was asked of them. Maybe their performance numbers didn't work out.

Remember that what Apple is doing is translating binary apps. What Unisys needs done is translating / emulating whole sections of the OS. That is a lot harder.

Re:Unisys Binary Translation (1)

tlambert (566799) | about a month and a half ago | (#47264573)

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.

Maybe they tried working with Transative in the mid 2000s. Maybe Transative failed. Maybe the Transitive people couldn't do what was asked of them. Maybe their performance numbers didn't work out.

Remember that what Apple is doing is translating binary apps. What Unisys needs done is translating / emulating whole sections of the OS. That is a lot harder.

That actually predates the code actually working reasonably well. I believe Apple also had an exclusivity license for some of the code.

If you count only the BSD system calls, it would have been a small job; if you add the mach, sysctl, fcnt, ioctl, and other multiplex BSD system calls, there was parameter and endian switching work that happened for in excess of about 8000 APIs, and that's not including the Mach message contents diddling that had to take place between the binary application and the native runtime environment, and other programs running on the same system which may or may not have been running under Rosetta (in fact, the original DSMOS relied upon Rosetta refusing to run on non-Apple platforms, and a critical system component being compiled only for PPC, rather than both PPC and Intel).

This amount of interface translation is about comparable, in terms of effort, and in terms of runtime overhead.

And yes, I'm certain the numbers *didn't* work out, if there was such a program attempted, since they aren't working out today, as it says in the article. It's the reason they haven't already killed off the CMOS chips, they just expect that they will be able to do so in 2015, which gives them about a year and a half to either get their numbers up or throw hardware at the problem.

If they are going to take the "throw hardware at it" approach to hitting their target date (about the only reasonable chance of hitting it), it's going to take a hell of a lot more than in place retargeting the code using LLVM-IR on the existing binaries.

Re:Unisys Binary Translation (0)

Anonymous Coward | about a month and a half ago | (#47265029)

If you count only the BSD system calls, it would have been a small job; if you add the mach, sysctl, fcnt, ioctl, and other multiplex BSD system calls.

But the 2200 isn't a BSD machine. It isn't even unix. You can not substitute directly OS calls from linux to 2200.

This amount of interface translation is about comparable, in terms of effort, and in terms of runtime overhead.

How can you say that? Translating a subset of 64 or 32bit powerpc applications to x86 is far simpler then translating an entire system that is 36 bit, ones compliment, segmented memory, and must be both bug compatible and performant to x86.

And yes, I'm certain the numbers *didn't* work out, if there was such a program attempted,

So I take it you never worked there or at least near the 2200 line, and certainly not near the engineers and have no inside information.

If they are going to take the "throw hardware at it" approach to hitting their target date (about the only reasonable chance of hitting it), it's going to take a hell of a lot more than in place retargeting the code using LLVM-IR on the existing binaries.

It sounds like you assume they haven't been working on this for a long time. Why would you make that assumption?

Also the 2200 cmos chips stopped getting faster when? ~2000? ~2002? So as the intel chips have improved vastly this last 10-15 years the goal has been static.

Re:Unisys Binary Translation (1)

Jeremy Erwin (2054) | about a month and a half ago | (#47264229)

...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).

Why didn't they fix the broken build and archival process? Or is "fuck it, it's too old" deeply engrained in Apple's corporate culture?

Re:Some Unisys Patents, DEC FX!32 (0)

Anonymous Coward | about a month and a half ago | (#47263651)

dude, DEC, far more so than most companies, suffered from the problem of:

1) approaching half the employees literally doing no actual work at the office for the 40hrs-per-week they were there.
+ sure, the ones that did do work were some crazy capable engineers, but that only goes so far when you've got that much dead weight

2) a significant number of the above, and some of those actually doing work too, spending a number of hours-per-week getting it on with their co-workers.
+ yes, DEC was where a number of people played melrose place, and "did it" at the office on their desks, or conference tables, or the parking lot, or anywhere else that was mildly-private. this was during office hours. there were enough nooks in crannies in some of those buildings that you'd likely not be caught, at least not in flagrante. and if you were, odds are your boss was banging one of the chicks in the office anyway, so no harm no foul.

3) management that seemed to think that selling 10 of something for $15k each was better than selling 100 of that something for $2k each.

yeah, DEC was "great" from the perspective of a 20-30-something engineer working there, but otherwise, it left much to be desired.

Re:Some Unisys Patents, DEC FX!32 (1)

Darinbob (1142669) | about a month and a half ago | (#47266373)

DEC got off the ground as the better and more agile alternative to IBM, especially for smaller computers. It really was very innovative. However after some years it really started to look like a full blown clone of IBM, just as bulky and bureaucratic, and blind to the more nimble competition coming in from the sides.

Re:Computerworld is a little slow (1)

iggymanz (596061) | about a month and a half ago | (#47262195)

never in three decades working with IBM mainframes have I ever seen bugs in emulation of instruction set, did you have "whippy-shit" programmers who were replying on some of the undocumented or unsupported "combination" instructions?

Re:Computerworld is a little slow (0)

Anonymous Coward | about a month and a half ago | (#47262447)

I don't remember the details - it was a "real" (not a P390; it cost 2 Million Euros or so) S/390 ca 2000 with 2 CPUs. It was initially unable to properly perform integer divison. We ran on their mainframe Unix (can't recall the name - OpenSomething). A microcode update from the labs fixed the issue.

I think it was this: http://www-03.ibm.com/systems/z/os/zos/features/unix/

The Unix thing was also dog-slow in traversing the file system and the "fixed" CPUs did not perfom better than an AMD x64 CPU of that time in my CPU benchmarks.

Their AIX/Power machines and their xlCr Compiler was quite good, though. I always liked to work on these IBM machines. They were more than equal to HPUX and Solaris machines, which we also had.

The real shocker was IBM delivering a CPU without properly working basic functionality. They apparently had big-time quality issues then.

Re:Computerworld is a little slow (1)

iggymanz (596061) | about a month and a half ago | (#47262583)

I've never used any Unix or Linux on IBM (or Amdahl) mainframe, that's a weird use case that I couldn't imagine cost justification. Big iron Unix boxes are now kicking the mainframe's butt in database benchmarks.

Re:Computerworld is a little slow (1)

Darinbob (1142669) | about a month and a half ago | (#47266541)

The Power was nice (though greatly improved by PowerPC), but AIX was just so strange. It quacked like a Unix duck, it swam like a Unix duck, but it didn't look at all like a Unix duck. It's like they took a good long look at Unix, realized that it was a good thing, but then decided that they would stamp it on every level with the IBM look and feel. Maybe they thought that if it didn't look like it was a product of a committee that their traditional customers would not want it. The AIX machine at one place I worked at was the least desirable for the developers to use, and the one with the most porting headaches. Even the "man" command didn't work as expected.

Who the fuck cares if it didn't? (-1)

Anonymous Coward | about a month and a half ago | (#47260921)

If it ain't intel it ain't worth shit! Read that headline again! Won't be long now until your phone, tabs, cars, and everything you hold dear, runs by way of Intel. Intel RUELZ!

An impressive technical feat (1)

Anonymous Coward | about a month and a half ago | (#47262201)

The Unisys systems are ones-complement, 36-bit systems, with overlay managers for their banks of memory; the Univac side of the house still supports running 'lost-deck' code from the 1950s. As in, the executable exists, but the source code was lost decades ago. So there is NO way to 'just recompile'.

Re:An impressive technical feat (1)

Vlad_the_Inhaler (32958) | about a month and a half ago | (#47263049)

Seconded.
There are two character-sets which are in use, an ancient 6-bit one which is still used for a lot of internal functions and 9-bit ascii. The 6-bit one is mostly used by systems programmers.

The biggest surprise... (1)

rnturn (11092) | about a month and a half ago | (#47262783)

... to me was that Unisys was still selling computer systems. The only time I thought about the company in recent years was when dealing with their help desk software package. Prior to that my last contact with the company was having to use an aging 110x mainframe that was running EXEC-something. A horrible user interface, BTW. It seemed to be designed to make using the system a major pain in the butt. I was so happy when a co-worker pointed out that I could move my code onto the PDP-11 and actually get some work done.

True Story (1)

digsbo (1292334) | about a month and a half ago | (#47262829)

I played in a band with a guy who sold some significant patents to Unisys for their mainframes and worked in the CTO office. Smart guy, actually worked as a pro musician for a while in the 70s with David Bromberg (session player for the hippie giants like Joan Baez). 6 or 7 years ago, I was interviewing a guy applying to be my manager. He also worked at Unisys, and so I asked him if he knew the guy with the IP, and he got a funny look on his face - he did know him, and said there was antagonism in that relationship. Apparently there was a longstanding feud between the older big iron guys and the newer architecture team. It's interesting to me to see that play out.

Re:True Story (1)

Gothmolly (148874) | about a month and a half ago | (#47263623)

David Bromberg is hardly a "session player for the hippie giants like Joan Baez", he's an amazing musician in his own right.

Re:True Story (1)

digsbo (1292334) | about a month and a half ago | (#47264837)

Fair enough; I doubt many people here would have known him on his own. Did not mean to belittle him in any way. Met him once, briefly.

Re:True Story (0)

Anonymous Coward | about a month and a half ago | (#47263829)

I worked at Burroughs before the merger with Sperry. We weren't allowed to say "IBM". Punched cards were not the "ibm cards" we used in college; they even had special flow charting templates with Burroughs' name because the only ones you could buy in a store were made by IBM.

Now get off my lawn

thus proving my theory (1)

MossStan (2635555) | about a month and a half ago | (#47266399)

facebook is only for zombies.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>