Traditional COBOL environment
in [Cobol]
|
From: Richard on 8 Apr 2010 21:45 On Apr 9, 10:38 am, "robertwess...(a)yahoo.com" <robertwess...(a)yahoo.com> wrote: > 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. I am not sure which bits you think are 'not true'. > Consider almost all RISC machines, all of > which were specifically designed to execute C. My claim was that "Stack based machines led to C style languages", not the other way around. RISC machines were later, whether any of them were "specifically designed to execute C" is arguable. > Most of them have no > more hardware stack support than S/360 did. I am not sure what you count as 'most'. I would think that 'most' RISC processors by numbers are ARM and they certainly have a stack. SPARC and MIPS do have stacks too. > 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). > C optimizers on CISC can use registers for passing parameters too. SPARC seems to go further with register windowing but: """The drawback is that upon interactions with the system the registers need to be flushed to the stack, necessitating a long sequence of writes to memory of data that is often mostly garbage. Register windows was a bad idea that was caused by simulation studies that considered only programs in isolation, as opposed to multitasking workloads, and by considering compilers with poor optimization. It also caused considerable problems in implementing high-end Sparc processors such as the SuperSparc, although more recent implementations have dealt effectively with the obstacles. Register windows is now part of the compatibility legacy and not easily removed from the architecture.) """ > > 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. > Pascal certainly was influenced by Algol and in fact was originally called Algol-W when it was submitted to the Algol-68 committee who were looking for a replacement language. C derived from B which was a derivitive of BCPL (Basic Combined Programming Language with Basic meaning fundamental or simplified and nothing to do with BASIC), a simplified CPL which was an unfinished language combining ideas from several others at the Atlas Computer Laboratory including ACL (Atlas Commercial Language) and APL (Atlas Programming Language). One of the major difference between Algol and Pascal like languages and C and BPCL like languages is that in the former the assignment (:=) is a statement while in the latter assignment (=) is an operator. While C and Algol have a vague similarity C is not derived from Algol at all. Another difference is that C was always intended to be compiled from many small files (which is why header .h files are used) while Pascal was intended by Wirth to always be compiled from one single file per program. > > 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. Most features in the standard were based on features already implemented by one or more vendors. ICL initially extended the ENTER, which was to introduce in-line code, to call external routines. In particular for disk access (also in the standard for '74) it was necessary to "ENTER PLAN routinename". Later we did get CALL and EXIT PROGRAM (but not the IBMism GOBACK). > 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. It is related to Forth actually, which implemented a stack virtual machine and RPN notation on an 1130 (which is why it is not spelled fourth) well before they built a 'Forth Machine'. > 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). Which is probably why there was never a COBOL on PDP-8.
From: Clark F Morris on 8 Apr 2010 22:18 On Thu, 8 Apr 2010 18:58:38 +0200 (CEST), Nomen Nescio <nobody(a)dizum.com> wrote: >"Kerry Liles" <kerry.removethisandoneperiod.liles(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. Take a look at the LE manuals for the z series. They have implement HEAP storage and I believe there are now stacking instructions.
From: robertwessel2 on 9 Apr 2010 03:34 On Apr 8, 8:45 pm, Richard <rip...(a)Azonic.co.nz> wrote: > On Apr 9, 10:38 am, "robertwess...(a)yahoo.com" > > > 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. > > I am not sure which bits you think are 'not true'. > > > Consider almost all RISC machines, all of > > which were specifically designed to execute C. > > My claim was that "Stack based machines led to C style languages", not > the other way around. RISC machines were later, whether any of them > were "specifically designed to execute C" is arguable. > > > Most of them have no > > more hardware stack support than S/360 did. > > I am not sure what you count as 'most'. I would think that 'most' RISC > processors by numbers are ARM and they certainly have a stack. SPARC > and MIPS do have stacks too. ARM certainly has a hardware stack register (several, in fact), and is fairly usual in the RISC world - it's also not very RISCy, in a number of important ways.. While SPARC has register windows, it does not have a dedicated hardware stack register. MIPS does not, Alpha does not, POWER/PPC does not... All of those *do* have conventions for using a GP register for a stack pointer. And the calling convention was hardly related to the language - C's variable argument lists makes a case for caller cleanup and passing arguments right to left, but it's certainly not required by either language (and implementations of both exist that violate the "conventional" rules. > > 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). > > C optimizers on CISC can use registers for passing parameters too. > SPARC seems to go further with register windowing but: Register windows were a Good Idea(tm) in the short time between when the RISC concepts were being developed, and people figured out how to do efficient graph coloring algorithms for register allocation. A main motivation for SPARCs register windows was that it was thought to be too hard to do efficient register allocation in compilers. As it turns out, it's not. Everyone thought the concept was mostly dead, until Intel revived a variation thereof for Itanium. > > > 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. > > Pascal certainly was influenced by Algol and in fact was originally > called Algol-W when it was submitted to the Algol-68 committee who > were looking for a replacement language. C derived from B which was a > derivitive of BCPL (Basic Combined Programming Language with Basic > meaning fundamental or simplified and nothing to do with BASIC), a > simplified CPL which was an unfinished language combining ideas from > several others at the Atlas Computer Laboratory including ACL (Atlas > Commercial Language) and APL (Atlas Programming Language). C borrows heavily from both CPL/BCPL/B and from Algol. It is clearly in the Algol family, even if it's also in the CPL family. > One of the major difference between Algol and Pascal like languages > and C and BPCL like languages is that in the former the assignment > (:=) is a statement while in the latter assignment (=) is an operator.. > While C and Algol have a vague similarity C is not derived from Algol > at all. Minor syntactic differences aside, block structure, local variables, named parameters, and a number of other features are the important things Algol contributed to almost all later languages. > Another difference is that C was always intended to be compiled from > many small files (which is why header .h files are used) while Pascal > was intended by Wirth to always be compiled from one single file per > program. Again, an attribute of a particular language. Pascal was intended to be a teaching language (and in fact was not originally intended to have an actual implementation - rather the students would use it as a fairly formal pseudo-code for doing their algorithm homework. The lack of separate compilation is a Pascal issue, not an Algol one (and one which was fixed in Modula, for example). > > > 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. > > Most features in the standard were based on features already > implemented by one or more vendors. ICL initially extended the ENTER, > which was to introduce in-line code, to call external routines. In > particular for disk access (also in the standard for '74) it was > necessary to "ENTER PLAN routinename". Later we did get CALL and EXIT > PROGRAM (but not the IBMism GOBACK). > > > 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. > > It is related to Forth actually, which implemented a stack virtual > machine and RPN notation on an 1130 (which is why it is not spelled > fourth) well before they built a 'Forth Machine'. The Buroughs machines (from the early sixties), and the notion of a stack machine, significantly predate Forth. Froth Machines, aka stack machines specifically designed to execute Forth, did, of course, postdate Forth itself (Chuck Moore himself being the lead designer behind the first one). Note that the 1130 was not actually a stack machine in any sense of the word. FWIW, while pure Forth machines are not well suited to executing C (somewhat oddly because of their poor support for a C style stack), many of the Forth chips implement a frame pointer register for just that purpose.
From: Richard on 9 Apr 2010 16:49 On Apr 9, 7:34 pm, "robertwess...(a)yahoo.com" <robertwess...(a)yahoo.com> wrote: > On Apr 8, 8:45 pm, Richard <rip...(a)Azonic.co.nz> wrote: > > > > > On Apr 9, 10:38 am, "robertwess...(a)yahoo.com" > > > > 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. > > > I am not sure which bits you think are 'not true'. > > > > Consider almost all RISC machines, all of > > > which were specifically designed to execute C. > > > My claim was that "Stack based machines led to C style languages", not > > the other way around. RISC machines were later, whether any of them > > were "specifically designed to execute C" is arguable. > > > > Most of them have no > > > more hardware stack support than S/360 did. > > > I am not sure what you count as 'most'. I would think that 'most' RISC > > processors by numbers are ARM and they certainly have a stack. SPARC > > and MIPS do have stacks too. > > ARM certainly has a hardware stack register (several, in fact), and is > fairly usual in the RISC world - it's also not very RISCy, in a number > of important ways.. It may well be different from what others call RISC but then all chip designs are different for many reasons. "The ARM2 was possibly the simplest useful 32-bit microprocessor in the world, with only 30,000 transistors." As to number there are over a billion ARM processors made each year. > While SPARC has register windows, it does not > have a dedicated hardware stack register. The 68000 also does not have a dedicated stack register. While SPARC does not have PUSH and POP it does have SAVE and RESTORE which uses a stack. > MIPS does not, Alpha does > not, POWER/PPC does not... All of those *do* have conventions for > using a GP register for a stack pointer. > > And the calling convention was hardly related to the language - C's > variable argument lists makes a case for caller cleanup and passing > arguments right to left, but it's certainly not required by either > language (and implementations of both exist that violate the > "conventional" rules. Actually with C the parameter evaluation order is required, granted thate where the parameters are passed can be implementation dependent. Evaluation order is important because, in C, parameters can be expressions and expressions can assign values (= is an operator not a statement) or call functions. > > > 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). > > > C optimizers on CISC can use registers for passing parameters too. > > SPARC seems to go further with register windowing but: > > Register windows were a Good Idea(tm) in the short time between when > the RISC concepts were being developed, and people figured out how to > do efficient graph coloring algorithms for register allocation. A > main motivation for SPARCs register windows was that it was thought to > be too hard to do efficient register allocation in compilers. As it > turns out, it's not. Everyone thought the concept was mostly dead, > until Intel revived a variation thereof for Itanium. Itanium has a hardware register stack. > > > > 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. > > > Pascal certainly was influenced by Algol and in fact was originally > > called Algol-W when it was submitted to the Algol-68 committee who > > were looking for a replacement language. C derived from B which was a > > derivitive of BCPL (Basic Combined Programming Language with Basic > > meaning fundamental or simplified and nothing to do with BASIC), a > > simplified CPL which was an unfinished language combining ideas from > > several others at the Atlas Computer Laboratory including ACL (Atlas > > Commercial Language) and APL (Atlas Programming Language). > > C borrows heavily from both CPL/BCPL/B and from Algol. It is clearly > in the Algol family, even if it's also in the CPL family. > > > One of the major difference between Algol and Pascal like languages > > and C and BPCL like languages is that in the former the assignment > > (:=) is a statement while in the latter assignment (=) is an operator. > > While C and Algol have a vague similarity C is not derived from Algol > > at all. > > Minor syntactic differences aside, Assignment is not a 'minor' syntactic difference. Beyond a superficial similarity it is a significant semantic difference. > block structure, local variables, > named parameters, and a number of other features are the important > things Algol contributed to almost all later languages. > > > Another difference is that C was always intended to be compiled from > > many small files (which is why header .h files are used) while Pascal > > was intended by Wirth to always be compiled from one single file per > > program. > > Again, an attribute of a particular language. Pascal was intended to > be a teaching language (and in fact was not originally intended to > have an actual implementation - rather the students would use it as a > fairly formal pseudo-code for doing their algorithm homework. I am not sure why you think that it was not intended to have an actual implementation: * Wirth proposed it as a successor to Algol-60 and submitted it as such to the IFIP Working Group that eventually led to Algol-68. * "Wirth supervised a high quality implementation for the IBM/360 at Stanford University that was widely distributed." Certainly Wirth promoted it as a teaching language rather than one for implementing large (or even small) projects, but implementations were always necessary so that the code could be proven. > The > lack of separate compilation is a Pascal issue, not an Algol one (and > one which was fixed in Modula, for example). > > > > > > > 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. > > > Most features in the standard were based on features already > > implemented by one or more vendors. ICL initially extended the ENTER, > > which was to introduce in-line code, to call external routines. In > > particular for disk access (also in the standard for '74) it was > > necessary to "ENTER PLAN routinename". Later we did get CALL and EXIT > > PROGRAM (but not the IBMism GOBACK). > > > > 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. > > > It is related to Forth actually, which implemented a stack virtual > > machine and RPN notation on an 1130 (which is why it is not spelled > > fourth) well before they built a 'Forth Machine'. > > The Buroughs machines (from the early sixties), and the notion of a > stack machine, significantly predate Forth. My claims have been that the hardware led to the language. You seem to think, again, that I made a claim the other way around. The Wiki article of forth backs this up with "Influenced by: Burroughs large systems, ..". > Froth Machines, aka stack > machines specifically designed to execute Forth, did, of course, > postdate Forth itself (Chuck Moore himself being the lead designer > behind the first one). Note that the 1130 was not actually a stack > machine in any sense of the word. FWIW, while pure Forth machines are > not well suited to executing C (somewhat oddly because of their poor > support for a C style stack), many of the Forth chips implement a > frame pointer register for just that purpose.
From: robertwessel2 on 9 Apr 2010 17:47
On Apr 9, 3:49 pm, Richard <rip...(a)Azonic.co.nz> wrote: > On Apr 9, 7:34 pm, "robertwess...(a)yahoo.com" <robertwess...(a)yahoo.com> > wrote: > > > > > > > On Apr 8, 8:45 pm, Richard <rip...(a)Azonic.co.nz> wrote: > > > > On Apr 9, 10:38 am, "robertwess...(a)yahoo.com" > > > > > 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. > > > > I am not sure which bits you think are 'not true'. > > > > > Consider almost all RISC machines, all of > > > > which were specifically designed to execute C. > > > > My claim was that "Stack based machines led to C style languages", not > > > the other way around. RISC machines were later, whether any of them > > > were "specifically designed to execute C" is arguable. > > > > > Most of them have no > > > > more hardware stack support than S/360 did. > > > > I am not sure what you count as 'most'. I would think that 'most' RISC > > > processors by numbers are ARM and they certainly have a stack. SPARC > > > and MIPS do have stacks too. > > > ARM certainly has a hardware stack register (several, in fact), and is > > fairly usual in the RISC world - it's also not very RISCy, in a number > > of important ways.. > > It may well be different from what others call RISC but then all chip > designs are different for many reasons. "The ARM2 was possibly the > simplest useful 32-bit microprocessor in the world, with only 30,000 > transistors." > > As to number there are over a billion ARM processors made each year. > > > While SPARC has register windows, it does not > > have a dedicated hardware stack register. > > The 68000 also does not have a dedicated stack register. While SPARC > does not have PUSH and POP it does have SAVE and RESTORE which uses a > stack. SAVE and RESTORE only move the register window, and at best implement only a small part of a stack as required by C/Pascal/Algol-like language. You cannot, for example, create a full C activation record on SPARC with just SAVE/RESTORE, unless you can fit all the parameters and local variable into the available register. > > MIPS does not, Alpha does > > not, POWER/PPC does not... All of those *do* have conventions for > > using a GP register for a stack pointer. > > > And the calling convention was hardly related to the language - C's > > variable argument lists makes a case for caller cleanup and passing > > arguments right to left, but it's certainly not required by either > > language (and implementations of both exist that violate the > > "conventional" rules. > > Actually with C the parameter evaluation order is required, granted > thate where the parameters are passed can be implementation dependent. > Evaluation order is important because, in C, parameters can be > expressions and expressions can assign values (= is an operator not a > statement) or call functions. Not sure what you mean by that, but the order of evaluations of the operands in a function call is *not* defined by C. The commas separating the parameters are not sequence points. The function call "f(a=b, a=c);" is undefined, since there's no guarantee which parameter will be evaluated first. > > > > 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). > > > > C optimizers on CISC can use registers for passing parameters too. > > > SPARC seems to go further with register windowing but: > > > Register windows were a Good Idea(tm) in the short time between when > > the RISC concepts were being developed, and people figured out how to > > do efficient graph coloring algorithms for register allocation. A > > main motivation for SPARCs register windows was that it was thought to > > be too hard to do efficient register allocation in compilers. As it > > turns out, it's not. Everyone thought the concept was mostly dead, > > until Intel revived a variation thereof for Itanium. > > Itanium has a hardware register stack. Sort of. It has a rotating window, and a register save engine to demand save/restore registers, but that doesn't implement a C-like stack, which in typical implementations uses one of the (non-rotating) GP regs as a typical frame pointer. Most of the time IPF programs have one stack for register saves (which the application usually doe not access directly), and another for activation records (aka the "C stack"). Basically identical to SPARC. Of course Intel and HP insist that IPF isnt actually RISC (not that anyone who isnt in marketing takes them seriously). > > > > > 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. > > > > Pascal certainly was influenced by Algol and in fact was originally > > > called Algol-W when it was submitted to the Algol-68 committee who > > > were looking for a replacement language. C derived from B which was a > > > derivitive of BCPL (Basic Combined Programming Language with Basic > > > meaning fundamental or simplified and nothing to do with BASIC), a > > > simplified CPL which was an unfinished language combining ideas from > > > several others at the Atlas Computer Laboratory including ACL (Atlas > > > Commercial Language) and APL (Atlas Programming Language). > > > C borrows heavily from both CPL/BCPL/B and from Algol. It is clearly > > in the Algol family, even if it's also in the CPL family. > > > > One of the major difference between Algol and Pascal like languages > > > and C and BPCL like languages is that in the former the assignment > > > (:=) is a statement while in the latter assignment (=) is an operator. > > > While C and Algol have a vague similarity C is not derived from Algol > > > at all. > > > Minor syntactic differences aside, > > Assignment is not a 'minor' syntactic difference. Beyond a superficial > similarity it is a significant semantic difference. While the handling of assignment is a significant difference, C and Algol have more than "a vague similarity." Most people consider Algol to be one of C's ancestors. You'll find many variations of the following diagram: http://www.comphist.org/computing_history/new_page_12_files/image002.gif You may disagree, but I wont belabor the point further. > > block structure, local variables, > > named parameters, and a number of other features are the important > > things Algol contributed to almost all later languages. > > > > Another difference is that C was always intended to be compiled from > > > many small files (which is why header .h files are used) while Pascal > > > was intended by Wirth to always be compiled from one single file per > > > program. > > > Again, an attribute of a particular language. Pascal was intended to > > be a teaching language (and in fact was not originally intended to > > have an actual implementation - rather the students would use it as a > > fairly formal pseudo-code for doing their algorithm homework. > > I am not sure why you think that it was not intended to have an actual > implementation: Well, if Wirth himself says I'm wrong... "Occasionally, it has been claimed that Pascal was designed as a language for teaching. Although this is correct, its use in teaching was not the only goal. In fact, I do not believe in using tools and formalisms in teaching that are inadequate for any practical task." - Niklaus Wirth, from the 1984 ACM A.M. Turing award lecture. > * Wirth proposed it as a successor to Algol-60 and submitted it as > such to the IFIP Working Group that eventually led to Algol-68. Wirth proposed Algol-W as the Algol-60 successor (which was rejected and what ended up being Algol-68 was adopted instead). Pascal was a descendent of Algol-W, and other than indirectly via that parentage, had no real influence on Algol-68 . |