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 C.C.:
>
> 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
|