Very good point; the function prologs and epilogs of LE conforming functions (or procedures) in PL/1 or COBOL programs just modify "next available byte" pointers into the preallocated storage area for all procedures and do no individual GETMAIN/FREEMAIN of their save areas etc.
But anyway: if looking at the code that the recent compilers produce, you can see re-arrangeing of operations due to pipelineing considerations, even in PL/1. Of course, you see more aggressive optimization in C, because the language allows it. And: the compilers use the newest machine instructions, if the options are set this way - the human coder sometimes just doesn't know them - my experience. Kind regards Bernd Am 05.04.2011 17:13, schrieb Chris Craddock:
so far everyone seems to be assuming that it is the assembly language "business logic" that is drastically slower. Sight unseen I would guess that has almost nothing to do with it. The thing with HLLs is that their startup costs are (typically) higher than assembly language programs, but once they are running they typically pull ahead. That's because the HLL program (once running) does almost no system services other than perhaps I/O. Lots (most?) of assembly language programs use system services (getmain/freemain, recovery etc) with some frequency and those system service calls can easily and very quickly dominate the pathlength for the entire application. The more reasonable comparison would be between the Cobol application and an LE conforming assembly language equivalent. CC
