Re: If you were inventing CoBOL...
From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 09/03/04
- Next message: William M. Klein: "Semi-OT - for IBM mainframe customers"
- Previous message: Colin Campbell: "Re: Flowchart generator for JCL and COBOL programs"
- In reply to: Robert Wagner: "Re: If you were inventing CoBOL..."
- Next in thread: Robert Wagner: "Re: If you were inventing CoBOL..."
- Reply: Robert Wagner: "Re: If you were inventing CoBOL..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 3 Sep 2004 13:10:35 -0700
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:p68hj0p9f52si1kpsbs870up126ek6lfhh@4ax.com...
> On Fri, 3 Sep 2004 08:41:43 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
> >"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> >news:d2lgj0tsrs9tu0tqkkk3dp9n3u5fr4fsn6@4ax.com...
> >> Segments are a case of procedural modularity.
> >
> >OK, but so are called programs.
> >
> >> Only procedural code is pageable.
> >
> >*WHAT?* Please support the universality of this statement!
>
> I didn't express the point clearly enough. Second try:
>
> If the program manages memory with priority numbers on segments, the
> size of shared memory is the size of procedural code.
Ummm ... no .... that is not a Universal Truth ...
Going by ANSI X3.23-1974 syntax, where the "Segmentation Module" is not yet
marked as obsolete:
I've heard of *segment numbers*, and I've heard of the segment-limit clause
which may impact the way SECTIONs with various segment-numbers are handled,
with respect to how they're treated. For example, "The fixed portion [of
the procedural code for the program] is that part of the program which is
*logically treated as if it were always in memory*" [emphasis added].
The implementor is *not* obligated to ensure that all portions of the "fixed
portion" is indeed unconditionally and always in memory during the execution
of the program, only that the actions *of the program* are indistinguishable
from that behavior.
The implementor is *not* obligated to ensure that two SECTIONs with the same
"segment number" are phyically or logically associated with one another in
memory, only that the actions of the program are indistinguishable from that
which would obtain with such a physical or logical association.
Moreover, there is no requirement on the part of an implementor to ensure
that two copies of the same program share *any* part of their memory, much
less a specific portion of it. Some implementors choose to do so -- on
Unisys MCP systems a single instance of the object code file on disk is
"managed" by the operating system for all executors of it, and "manages" the
determination of which code segments are in memory based on how they are
used -- the ALTER behavior impacted by section-numbers is managed in the
individual "data spaces".
The *program* is not managing the memory, as I see it; the *operating
environment* is managing the memory using the segment-number of the various
SECTIONs and the SEGMENT-LIMIT clause as *guidelines* in that process.
It is precisely because *all* of this is really an implementation detail,
and because the *specifics* of fixed-versus-overlayable in various
implementations are really none of the standard committee's business, that
led to the Segmentation Module being marked as obsolete in 1985 and to its
elimination from the standard in 2002. The SECTION header remains, but
ALTER, segment-numbers and the SEGMENT-LIMIT clause are gone.
> If the program manages memory with CALL/CANCEL, the size of shared
> memory is larger because the size of some working-storage can be freed
> as well.
It is not the program that is managing the memory in the first place, it is
the operating environment. IN an environment in which program initiation
and termination are costly and in which the operating environment does a
really good job of memory management in the first place, CALL/CANCEL may be
a *much* less efficient approach than what you propose Who says all of
WORKING-STORAGE *has to be* in a monolithic block that is unconditionally
resident for the life of the program?
> I should have said freeable rather than pageable. The machines we're
> discussing didn't have virtual memory. If they had, there would have
> been no need for the programmer to manage memory.
What machines were *we* discussing? As far as I'm concerned, *we* were
discussing what COBOL *ought to do* and what features COBOL *ought to
provide* and why.
> C is the same. The reason has nothing to do with structure or
> philosophy, it's more mundane. The compiler needs to type-check
> parameters on the call. There are three ways that could be done:
>
> a. Two passes in the compiler front-end.
> Too slow.
I know of a two-pass COBOL compiler that is *triple* the speed of its
one-pass counterpart. Show me how slow a two-pass compiler always is
compared to a one-pass compiler. I've also known *six-pass* COBOL compilers
that weren't speed demons *during compilation*, but that generated
blindingly-fast object code. And what's *the* compiler front-end?
> b. Prototypes at the top.
> Too verbose.
also requires prototypes. This is similar to ALGOL's FORWARD I think.
> c. Require the callee to be seen before the caller.
> The solution they used.
The solution ALGOL, Pascal, PL/I, etc., used, which I personally prefer.
> Because Cobol doesn't require type-checking, the better idea was to
> put the called program where it logically belongs.
It's not clear to me that the "because" is true, nor is it clear to me that
"logically belongs" has been established.
> A major difference is data visability. Pascal makes everything in the
> equivalent of working-storage global.
Sort of, and Pascal is very much like its ancestor in this respect. The
philosophy there is that data *at a given level* isn't visible at a higher
level in the program, but you can see the data for all higher levels of the
program from wherever you are. I agree that COBOL's explicit declaration of
what data in the parent level you can and can't see at the child level can
be seen as an improvement.
> Parameters? We don't got to pass
> no stiinking parameters! Just reach into the pot and help yourself.
You don't have to pass "shared data" in COBOL as parameters, you can always
make it global and thus access by anyone beneath is welcome if that's what
you want.
> Cobol has been criticized for having 'an ocean of global data' since
> the beginning. That's WHY nested programs were created.
Yes, but I'd say the "global" issue is a refinement on that. Nested
programs allows the data that is accessed or used only by a given set of
logic to be associated with that logic and thus removed from the "outer
block". And if you're *really* modularizing, how much "local" data does
the "outer block" of a COBOL program in which all its real work is done in
"nested" programs really need?
> As for inheritance, I'd say ALGOL got the idea from Fortran's 'blank
> common'.
Could be, but I think the ALGOL approach is rather more powerful and
sophisticated.
> > I've never understood the particular utility of calling
> >a program one time with a parameter BY REFERENCE and the next time BY
VALUE,
>
> That's not utility, that's an error.
No, it's *explicitly* allowed by COBOL, and I believe the justification is
that one time you might *not* want to allow the callee to modify the data,
but the next time you *might*, and the standards folks didn't want to
preclude people from writing programs that did that. I wasn't there when
this decision was made, and had I been I'd almost certainly have argued
*strenuously* against it, but I have heard hints that at least one
implementor thought *copying* the data should be obligatory for BY VALUE,
and that's the way it is.
> Some day, the solution will be typecasting via introspection. The
> compiler will peek into the callee to see what it wants, then cast the
> call to match.
Not sure what you mean by this, but I think having the compiler do "Well, I
know what you *wrote*, but I've decided what you really *meant* was ..." is
a REALLY bad idea.
> To a seasoned Intel assembly programmer, it seems intuitive that a
> single instruction, memory-to-memory move is the fastest way to copy a
> string. It used to be. Now it's faster to tediously load and store a
> word at a time.
That's actually one of the big differences: COBOL allows just about
anything to be passed BY VALUE; the procedural languages didn't.
> We have compilers between us and the machine to automate optimizations
> like this. In case you cited, if all targets were nested, a smart
> compiler could disregard what the programmer wrote
NO. Can't do that unless it can be guaran-dam-teed that the results are
*unconditionally identical*.
> and optimize the
> parameter type automatically. If targets were external, a 'full make'
> would be required to optimize.
> I don't think programmers should have to hold the machine's hand like
> we used to. Stuff like this should be automated.
Some of it can, some of it is. The *standard* specifies how it should
*behave*; it isn't the *standard*'s job to make sure the implementor does it
efficiently, it's the *implementation's*.
-Chuck Stevens
- Next message: William M. Klein: "Semi-OT - for IBM mainframe customers"
- Previous message: Colin Campbell: "Re: Flowchart generator for JCL and COBOL programs"
- In reply to: Robert Wagner: "Re: If you were inventing CoBOL..."
- Next in thread: Robert Wagner: "Re: If you were inventing CoBOL..."
- Reply: Robert Wagner: "Re: If you were inventing CoBOL..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
