Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!rutgers!mtunx!att!ihnp4!upba!eecae!dsacng1!dlscg1!dlsc1032 From: dlsc1032@dlscg1.UUCP (Alan Beal) Newsgroups: comp.arch Subject: Re: stack machines (Burroughs) Keywords: RISC, real-time Message-ID: <372@dlscg1.UUCP> Date: 15 Jun 88 13:25:16 GMT References: <1521@pt.cs.cmu.edu> <1532@pt.cs.cmu.edu> <476@pcrat.UUCP> <3147@polyslo.UUCP> Organization: Defense Logistics Services Center Lines: 92 In article <3147@polyslo.UUCP>, dorourke@polyslo.UUCP (David O'Rourke) writes: > At last count system 3.7 was somewhere in the neighborhood of 700-800 > thousand lines, the only reason Unisys was forced to implement libraries is > because the MCP was getting so big the compilier couldn't treat it as one > single program anymore. 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. The DMSII accessroutines were one of the first versions of libraries even though it wasn't called a library and DMSII has been around since the 70's. I can not speak of Unisys's intent, but libraries offer the 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. If you take a good look at libraries, aren't they implemented in a manner similar to those in OS/2? My 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. > 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: 1) Algol - normal application development capabilities 2) BDMSalgol - Algol plus DMSII capabilities 3) DCalgol - Algol plus data communications and system programming capabilities. No DMSII capabilities. 4) DMalgol - DCalgol plus DMS accessing and development capabilities Which version of algol is used is determined by the type of programming involved and I never seem to get confused on which version to use. 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 each machine series has a tailored MCP for that particular machine in order to handle the way memory is managed and other gory details, but basicly the functionality is the same between MCPs. > Even Unisys is moving towards knowing Machine code, they have a new > piece of software called DumpAnalyser, they seemed to feel the need to spend > three weeks teaching me how to use it {they do this for all new employee's}. > And if you think what it puts out is Algol code you are sadly mistaken, it's > basicly for "reading" the stack of a program, and if that's not machine code > I don't know what is, they still don't have an assembler, but they're now > allowing the programmers to "look" at the code produced by the compiler. How many application programmers out there have used Dump Analyzer? How many know what it is? Dump Analyzer is a tool for systems programmers to analyze memory dumps, ie. what programs where in the mix at the time of the dump and where did they bomb off. Our staff spends a lot of time using this tool and at times have looked at the machine code of the offending program, but for the most part the machine code offers little insight into the cause of the problem and usually the problem is passed on to Unisys to solve. I would agree that knowledge of the stack architecture is very helpful, especially in debugging programs. However, most people can debug their programs without ever looking at machine code. Finally, the stack is not machine code but an internal data structure for storing variables, pointers to data, and recording the environment of the program. It would 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. Software is the name of the game for most companies now. IBM realizes this. Unisys does not. The Burroughs side of Unisys has concentrated on further enhancing its current software and has not made great efforts at developing new products. For example, LINC was developed by a company in New Zealand and was purchased by Burroughs as a 4GL. How many people like to use LINC? It has nice syntax like 'MOVE ; FIELD1 FIELD2'. Would you call this an end-user or programming language? Then there was GATEWAY developed by Joseph and Cogan which was competing with COMS. Burroughs bought J & C and now we have COMS. What happened to GATEWAY? And now we have SIM, a semantic database system sitting on top of DMSII. Does it offer SQL a or provide access to other DBMS systems like DB2? No, of course it doesn't. And how about 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. -- Alan Beal DLSC-ZBC Autovon 932-4160 Defense Logistics Services Center Commercial (616)961-4160 Battle Creek, MI 49015 FTS 552-4160 UUCP: {uunet!gould,cbosgd!osu-cis}!dsacg1!dlscg2!abeal