My apologies to the list if my point is redundant, as I have not read all the previous entries for this thread. But perhaps the word "overhead" has more than one meaning. What is the overhead to the organization of supporting an Assembler language programmer in salary and machine time to code and debug vs. that of a higher-level language programmer? Execution time overhead is not the only possible component of "overhead." Think about how many more instructions it would take in Assembler to code this simple Fortran statement: X=Y+3. I would code in Assembler something like this: L Rx,Y L Ry,=F'3' AR Rx,Ry ST Rx,X Yes, I know all sorts of "faster" ways to do it and with fewer instructions. And it could be done with only one very wise and pre-existing macro, but that's an argument for the development of such macros, which would turn the Assembler into a pseudo-higher-level language, but not all programming problems can be implemented in pre-existing macros. And any higher-level language is going to translate the example statement into more or less a similar set of Assembler statements.
Bill Fairchild Rocket Software -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Chris Mason Sent: Tuesday, April 05, 2011 5:58 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: CPU: ASSM vs ENTERPRISE COBOL Bernd Since we're telling stories, this reminds me of a time in the early 1970s when IBM was "pushing" PL/I. I was in a technical support centre and a salesman called me in order to ask - presumably "pass on" - a question. He said that it was known that PL/I carried an "overhead" but "What was the "overhead" with assembler?". I answered with as much sympathy replacing the natural scorn as I possibly could! But now, having read this thread, I wonder if I gave the right answer! Chris Mason ----- Original Message ----- From: "Bernd Oppolzer" <bernd.oppol...@t-online.de> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Sent: Tuesday, April 05, 2011 10:01 AM Subject: Re: CPU: ASSM vs ENTERPRISE COBOL That reminds me of an old story where someone tried to test the performance of programming languages by coding the following short program in PL/1 and ASSEMBLER (this was on the now historic Telefunken TR 440 hardware): SUM = 0; DO I = 1 TO 100000; SUM = SUM + I; END; PUT SKIP LIST (SUM); The result was: PL/1 was much much faster, because the optimizing compiler unrolled the loop and completely performed the computation during compile time and simply generated code to print the result. This was the MULTICS PL/1 compiler, which was sold to the Telefunken company and ported to the TR 440. The ASSEMBLER programmer, of course, coded the loop. Kind regards Bernd
