Traditional COBOL environment
in [Cobol]
|
From: Michael Wojcik on 8 Apr 2010 13:45 Kerry Liles wrote: > "Nomen Nescio" <nobody(a)dizum.com> wrote in message > news:487250e8e05e60d55f2c4238a0799db0(a)dizum.com... >> What's a "stack machine"? None of the IBM hardware is stack-based, >> although >> MVS/ESA did introduce the Linkage Stack, it is only used for saving state, >> and not general purpose storage. There is no hardware notion of heap, >> stack, etc. in IBM-land, and not in most IBM system software, either. > > I took it to mean "hardware support (instructions) permitting the > implementation of stacks" A bit stronger, I think. Obviously the 360 has instructions that *permit* implementing a stack (as does any machine that's equivalent to a Turing machine, or even one that's equivalent to a PDA). "Stack machine" usually refers to an architecture that assumes and requires a stack, or at least is significantly crippled without one. If you look at the Intel x86 architecture, for example, you can see how it's designed around a stack. There's a dedicated stack-pointer register (ESP, or SP in the 16-bit x86s) and many operations update ESP and/or the stack itself. The call/return mechanism - which is built into the CPU architecture (via operations like call and ret), and not simply a convention - relies on the stack. So does interrupt handling. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 8 Apr 2010 14:04 WangVS wrote: > Richard fully understands the points I have been trying to make about > the Wang VS OS environment being a fully multitasking environment that > nicely manages resources for hundreds of concurrent tasks sharing > access to the key business files. It's a full-fledged multiuser OS. > Many such existed while MS took 10-15 years to rediscover OS > technology and finally developed NT using a crew from DEC. The virtues of Wang VS OS aside, this snip at Microsoft is historically inaccurate (and doesn't contribute anything to your thesis, I think). Microsoft had a multitasking, multiuser OS long before Windows NT - Xenix. NT development started in 1989 (when it was still slated to become OS/2 3.0); Xenix was written in 1979. Some sources claim that Xenix (either from Microsoft or from SCO, which bought the sources from Microsoft around 1980) was the most widely installed Unix flavor in the early '80s. Plenty of people at Microsoft in the late '80s had experience with multiuser OSes. And while Cutler certainly brought a number of people (mostly from VMS development) to Microsoft from Digital, NT was by no means simply created by "a crew from DEC". It incorporated significant existing technology from Windows and OS/2; I suspect the POSIX subsystem inherited bits of Xenix as well. And, of course, Microsoft also had experience with multitasking, if not multiuser, OS development with OS/2 prior to the breakup with IBM. (Multiuser OS/2 was eventually developed by Citrix around 1991.) The fact of the matter is that the market for a multiuser OS on x86 hardware was orders of magnitude smaller than the market for Windows and other single-user systems, until larger i368 machines started coming out. Xenix was available, and people who wanted a multiuser OS on such machines could get it. Eventually it was joined by BSD386 and Linux, specialty OSes like Citrix's multiuser OS/2, experimental or educational OSes like Minix, etc. But most PC owners ran MS-DOS, Windows, or OS/2, because they neither needed nor wanted a multiuser OS. It's not because Microsoft didn't know how to create one. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Richard on 8 Apr 2010 17:08 On Apr 9, 5:06 am, "Kerry Liles" <kerry.removethisandoneperiod.li...(a)gmail.com> wrote: > "Nomen Nescio" <nob...(a)dizum.com> wrote in message > > news:487250e8e05e60d55f2c4238a0799db0(a)dizum.com... > > > "Kerry Liles" <kerry.removethisandoneperiod.li...(a)gmail.com> wrote: > > >> True, but the Wang VS was based closely on the IBM 360, which I > >> believe was not a stack machine. From its early origins in the late > >> 1970s the Wang VS was designed with hardware and software use of > >> stacks clearly in mind, just as it was designed to be interactive. > > > What's a "stack machine"? None of the IBM hardware is stack-based, > > although > > MVS/ESA did introduce the Linkage Stack, it is only used for saving state, > > and not general purpose storage. There is no hardware notion of heap, > > stack, etc. in IBM-land, and not in most IBM system software, either. > > I took it to mean "hardware support (instructions) permitting the > implementation of stacks" > As I mentioned, one can always implement the use of stacks via software, but > the post I replied to indicated the Wang VS (machine?) had hardware-based > stack support like push and pop instructions (for example). With the speed > of hardware these days, it seems less relevant whether such things are > implemented in hardware or software... There is a significant relevance whether a machine is stack based or not in the style of programming languages. Stack based machines led to C and Pascal style languages where parameters are passed by pushing on the stack and using a CALL which pushes the return address which is popped by the return instruction. The difference between C style and Pascal style is which end of the call does the parameter clean up. Non-stack machines led to self-modified code and branching style of languages. COBOL for example had a no-op EXIT statement, or an implied one, that acted as the return when the PERFORM statement was implemented by storing the return branch in the the address of the EXIT statement and then branching to the label. The rules of COBOL, such as those on overlapping PERFORMs, cater for this mechanism. I presume that 'modern' IBM Cobol does not do it this way anymore and uses, say, a software stack. Or does IBM big iron instruction set actually have a stack these days. Note also that CALL did not get into the COBOL standard until '74. This meant that COBOL programs tended to become huge monoliths using PERFORMs only as this is what non-stack machines do. > in the old days (say, the mid 1970s) > hardware assist was a significant performance boost and worth the effort in > microcode.
From: robertwessel2 on 8 Apr 2010 18:38 On Apr 8, 4:08 pm, Richard <rip...(a)Azonic.co.nz> wrote: > On Apr 9, 5:06 am, "Kerry Liles" > > > > > > <kerry.removethisandoneperiod.li...(a)gmail.com> wrote: > > "Nomen Nescio" <nob...(a)dizum.com> wrote in message > > >news:487250e8e05e60d55f2c4238a0799db0(a)dizum.com... > > > > "Kerry Liles" <kerry.removethisandoneperiod.li...(a)gmail.com> wrote: > > > >> True, but the Wang VS was based closely on the IBM 360, which I > > >> believe was not a stack machine. From its early origins in the late > > >> 1970s the Wang VS was designed with hardware and software use of > > >> stacks clearly in mind, just as it was designed to be interactive. > > > > What's a "stack machine"? None of the IBM hardware is stack-based, > > > although > > > MVS/ESA did introduce the Linkage Stack, it is only used for saving state, > > > and not general purpose storage. There is no hardware notion of heap, > > > stack, etc. in IBM-land, and not in most IBM system software, either. > > > I took it to mean "hardware support (instructions) permitting the > > implementation of stacks" > > As I mentioned, one can always implement the use of stacks via software, but > > the post I replied to indicated the Wang VS (machine?) had hardware-based > > stack support like push and pop instructions (for example). With the speed > > of hardware these days, it seems less relevant whether such things are > > implemented in hardware or software... > > There is a significant relevance whether a machine is stack based or > not in the style of programming languages. > > Stack based machines led to C and Pascal style languages where > parameters are passed by pushing on the stack and using a CALL which > pushes the return address which is popped by the return instruction. > The difference between C style and Pascal style is which end of the > call does the parameter clean up. That's not really true. Consider almost all RISC machines, all of which were specifically designed to execute C. Most of them have no more hardware stack support than S/360 did. They *do* have a bunch of general purpose registers (typically 32, vs. S/360's 16), and the software convention usually dedicates one of those to being a stack pointer. Not unlike how R13 is dedicated to point to a chain of save areas in the typical S/360 conventions. And most RISC call instructions are exactly like BAL or BALR, in that they leave the return address in a register (although they don't mess up the high byte). > Non-stack machines led to self-modified code and branching style of > languages. COBOL for example had a no-op EXIT statement, or an implied > one, that acted as the return when the PERFORM statement was > implemented by storing the return branch in the the address of the > EXIT statement and then branching to the label. > > The rules of COBOL, such as those on overlapping PERFORMs, cater for > this mechanism. There were certainly architectures that made implementing a stack painful. And Cobol was targeted at those as well as more general purpose machines (like S/360). By not having local variables, and forbidding recursion, a non-stack implantation is plausible. Given that it also more precisely defines your memory requirements, it was undoubtedly an appealing concept to some language designers of the day, especially given that they were heavily influenced by assembler coding practices. I'm not sure where the PERFORM range insanity came from, although I think it was there in Cobol from the start, but it certainly isn't something that was copied by any other languages. And while the PERFORM range nonsense does make a clean stack implementation basically impossible, avoiding that, like Fortran did, would have allowed both types of implementation. IMO, Cobol's "subroutine" design was simply a huge mistake. Trying to tie it to the architectural issues of stack, vs. non-stack designs is simply wrong. And Algol (which is generally considered to be where all of the C and Pascal style languages come from, was certainly implemented on many machines of that era, both stack and non-stack. > Note also that CALL did not get into the COBOL standard until '74. > This meant that COBOL programs tended to become huge monoliths using > PERFORMs only as this is what non-stack machines do. I'm pretty sure that CALL was implemented much earlier than that on S/ 360 compilers, and on many other as well. And on S/360 they still followed the R13-based calling convention. Finally, "stack machine" actually means a couple of different things. In one sense it does mean hardware support for a stack. In another sense, it means a machine that uses the stack for operands (IOW, the "add" instruction adds the two words on the stack, and pushes the result back, rather than adding the contents of two registers) like many of the Burroughs machines, or the more modern Forth machines. Again, that's not particularly related to the design of any particular language. Which is not to say that some hardware "features" might not make certain language features problematic (or at least unpleasantly expensive). Consider the PDP-8 which stored the return address for a call in the first word of the called subroutine. Implementing recursion is clearly a problem on such a machine (but the scheme would not have helped implement PERFORM ranges either - which requires the return address be stored somewhere accessible at the end of the "THRU" paragraph).
From: Richard on 8 Apr 2010 20:33
On Apr 9, 6:04 am, Michael Wojcik <mwoj...(a)newsguy.com> wrote: > WangVS wrote: > > Richard fully understands the points I have been trying to make about > > the Wang VS OS environment being a fully multitasking environment that > > nicely manages resources for hundreds of concurrent tasks sharing > > access to the key business files. It's a full-fledged multiuser OS. > > Many such existed while MS took 10-15 years to rediscover OS > > technology and finally developed NT using a crew from DEC. > > The virtues of Wang VS OS aside, this snip at Microsoft is > historically inaccurate (and doesn't contribute anything to your > thesis, I think). > > Microsoft had a multitasking, multiuser OS long before Windows NT - > Xenix. Xenix was a licenced Unix edition 6 or 7. Most of the development work was done under contract by Doug and Larry Michels who were 'Santa Cruz Operation'. MS also had a multitasking version of MS-DOS: 4.0 and 4.1 (not to be confused with the much later 4.01). These were not very good. > NT development started in 1989 (when it was still slated to > become OS/2 3.0); Xenix was written in 1979. Some sources claim that > Xenix (either from Microsoft or from SCO, which bought the sources > from Microsoft around 1980) was the most widely installed Unix flavor > in the early '80s. Plenty of people at Microsoft in the late '80s had > experience with multiuser OSes. MS used Xenix inhouse until at least 1989. This was mostly for accounting but some development of MS-DOS software was done on it during the 80s. > And while Cutler certainly brought a number of people (mostly from VMS > development) to Microsoft from Digital, NT was by no means simply > created by "a crew from DEC". It incorporated significant existing > technology from Windows and OS/2; I suspect the POSIX subsystem > inherited bits of Xenix as well. > > And, of course, Microsoft also had experience with multitasking, if > not multiuser, OS development with OS/2 prior to the breakup with IBM. > (Multiuser OS/2 was eventually developed by Citrix around 1991.) > > The fact of the matter is that the market for a multiuser OS on x86 > hardware was orders of magnitude smaller than the market for Windows > and other single-user systems, until larger i368 machines started > coming out. Xenix was available, and people who wanted a multiuser OS > on such machines could get it. DRI's Multiuser MP/M on 8085/Z80 was released in 1978. MP/M-86 on 8086 and 8088 in 1981. Concurrent-CP/M-86 and Concurrent-DOS in the very early 80s and was developed right through the 90s. These were much more popular than Xenix especially in Europe. > Eventually it was joined by BSD386 and > Linux, specialty OSes like Citrix's multiuser OS/2, experimental or > educational OSes like Minix, etc. But most PC owners ran MS-DOS, > Windows, or OS/2, because they neither needed nor wanted a multiuser > OS. It's not because Microsoft didn't know how to create one. > Microsoft did not create Xenix. MS-DOS 4.0 and 4.1 were poor. OS/2 was written to IBM's specification and used IBM's technology which was taken by MS to make Windows 286 and 386 modes useful. It was Citrix that made OS/2 multi-user and later made NT 3.x multi-user as well. NT's later Terminal Server was built using Citrix's technology acquired when MS refused to let Citrix have NT 4 source code unless MS could have free access to all Citrix code. Multi-user systems are required when shared data systems are used. Of course this may just be a multi-user shared file system such as Netware (or previously Corvus shared disks and such). > Michael Wojcik > Micro Focus > Rhetoric & Writing, Michigan State University |