Path: utzoo!attcan!uunet!husc6!think!ames!pasteur!ucbvax!hplabs!sdcrdcf!csun!polyslo!dorourke From: dorourke@polyslo.UUCP (David O'Rourke) Newsgroups: comp.arch Subject: Re: stack machines (Burroughs) Keywords: RISC, real-time Message-ID: <3215@polyslo.UUCP> Date: 18 Jun 88 21:27:21 GMT References: <1521@pt.cs.cmu.edu> <1532@pt.cs.cmu.edu> <476@pcrat.UUCP> <3147@polyslo.UUCP> <372@dlscg1.UUCP> Reply-To: dorourke@polyslo.UUCP (David O'Rourke) Organization: Cal Poly State University -- San Luis Obispo Lines: 142 In article <372@dlscg1.UUCP> dlsc1032@dlscg1.UUCP (Alan Beal) writes: > I can't believe I am about to defend Unisys, but I would say that the >number of lines of code in the MCP has nothing to do with the implementation >of libraries. Have you ever worked for Unisys? No I don't think so. And yes the current implementation of Libraries came about as a request from the MCP group {which I worked with at the Mission Viejo/Lake Forest plant} to the Compiler group to implement Libs. because the MCP was getting too large. Yes Unisys has always had Libs. but not until recently were they used to a great extent in internal/external production code, no one trusted them and would put the code in-line rather than porting it out to a lib, most of the time the offending programmer would claim performance. Unisys's library implmentation is quite elegant and doesn't impose a performance hit after the 1st use. Many programmers that have been with Unisys for MANY years don't see the benifit of using libs. and you have to pull teeth to get them to use any of the standard routines that are provided if they can write them themselves. One programmer designated to teach me how to program A-Series told me not to make MCP calls because of the high overhead, he said always do the simple stuff so that your program runs faster. Well if making MCP calls has such a high overhead and most programmers don't call them then what's the point of having the MCP allow external calls? Many programmers were so worried about the performance of their code that they would forsake compatibility {i.e. doing it themselves rather than the MCP which would allow future compatibility}. And if you think this is an isolated attitude you are wrong! >modularity desired in large complex systems. Take COMS for example, the >majority of COMS code is implemented as libraries, as well as BNA and the >new print subsystem. Libraries eliminate the need for binding all those >code files together - I would call this a software engineering enhancement not >a solution to the number of lines in the MCP. Yes but a great majority of programmers at Unisys don't see the benifit of this enhancement. And as for COMS being modular that's one of the reasons libaries came about. Because COMS got to be sooooo large they couldn't fit it one program so they too requested that libs. be implemented. And as far as COMS being good code well you can chuck that idea the slightest change in the MCP normally breaks COMS, if you want to test your MPC patch test it with COMS and see if it still works. Why is this you say, well because some programmer did something himself rather than going thru the standard libary call. Yes libs are implemented, but they are used as ways to break code into smaller chunks for the compiler. They are rarely used to provide a standard interface or provide future compatibility. Most programmers at Unisys that I met simply didn't bother to make calls to other libraries if they could write the code them selves. This causes lots of compatibility problems for future upgrades and nullifies one of the benifits of libs. And COMS is an interesting beast in itself. I spent 4 months going over that code and talking to anyone I could find regarding information on COMS. The mission plant has over 400 programmers working there and I talk to at least 100 of them. Asking a simple question: What does COMS do, and what does MCP do! No-one to this day answered that question with a straght forward answer. MCP and COMS are so intertwined that no one can tell them apart, there are many places in COMS that has identical subroutines as the MCP because the original programmer didn't bother to look and see if the MCP did it already, what this means is that when that part of MCP is changed someone else has to go in a change the same routine in COMS. In fact a special flag in patch manager was implemented to flag changes to either of the pieces of code and notify the appropriate department that they need to change their code. Yep Unisys has libraries alright, now could someone teach them how to use them. >If you take a good look at >libraries, aren't they implemented in a manner similar to those in OS/2? My Are you comparing A-Series to OS/2. Please the A-Series deserves better than that. OS/2 1/2 an operating system :-) >only complaint is that Unisys has not put a lot of effort in developing new >products using the newest features in the MCP, ie. libraries and port files. Have you ever watched a system using port files? Not real fast! Many of the newest features of the MCP aren't understood by the vast majority of the programmers at Unisys, hence you don't get to see a lot of software that uses them. >> And triing to keep up with all of the different versions of Algol that >> Unisys has: Newp, DC-Algol, ect.. No wonder no software gets written when >> ever you want to change something you have to work across at least three >> different versions of the same language, several different versions of the >> MCP, and you have that wonderful editor with which to look at all of this >> code. > > Here I go again defending Unisys. )-: I am not sure that you understand >how the different versions of Algol are used. Algol, DCalgol, DMalgol, and >BDMSalgol are all compiled from a single source - symbol/algol. Here are >their capabilities: I am quite aware of the different versions of Algols. If they are so similar then why does Unisys have 600-1000 {or more} page manual describing just the features of that language for each version. Each manual for each of the algols refer to the Standard Algol 60 manual which is the lowest common denominator at Unisys, it then goes on to talk about the "differences" between the "Standard" & "This version" of Algol. These manuals are LARGE, Technical, and very scant in their descriptions of the various functions. They are not the same, and many have major differences and feature specific syntax that aren't availible in the other algols. You should spend 2 or 3 weeks going between Algol ---> NeWP ----> DCAlgol and back and forth to find an obscure bug in one of the routines in the MCP. This code wasn't standard Algol and each part typically used the specialized features of that particular language. Go off and do that and then come back and tell me that all of these languages are the same and that if you know one you know them all, yeah thats true for the simple stuff, but not for the sort of stuff that Unisys typically writes. > Where are all these versions of the MCP? As far as I know we can only >purchase one version for the B7800. Again you are confusing the fact that If you will read the availible posting you will find that I worked for the A-Series group of people. They have released MPC 3.7 for the entire A-Series line of computers. It is an Upgrade from 3.6 it is not machine specific except that it has to be run on an A-Series. When I left to finish school they were already coding MCP 3.8 and planning MCP 3.9. Again I'm confusing nothing! You just don't understand. >be a mistake to say Unisys is moving towards machine code and assemblers >since the move from within is to get the Sperry side out of that mode of >operation. How would you know what the move from within is? And the version of DumpAnalyser that I used did indeed allow you to look at both the stack and the machine code that the different descriptors in the stack pointed to. >BNA - it is a nice way to connect Burroughs machines together but can I connect >our UNIX machine to it? Again, no. And speaking of BNA, it would be an >excellent vehicle in which to develop a distributed DBMS around. Are there >any plans to do this in the future? You know the answer. Ahh but when I asked my manager when we were going to implement a distributed filing system he said: "We already have a distributed file system" Well in fact they don't. The people at Unisys will tell you that they already have a distributed DBMS, and they think they do, when in fact they are sadly mistaken. The whole purpose of my original article was to indicate that although the E-Mode architecture is quite nice the software that Unisys is running on top of it is quite old and wasn't very sophisticated when it was new. Unisys needs to make some radical changes if they are going to continue to compete. There are people inside that are triing, but they have 20 years of inertia to fight, so we'll see what happens. Stay tuned. -- David M. O'Rourke Disclaimer: I don't represent the school. All opinions are mine!