On 7/18/2013 6:46 AM, Paul Gilmartin wrote:
On Thu, 18 Jul 2013 08:13:02 -0400, John Gilmore wrote:
COBOL optimization has always been problematic for two reasons.
The less important of them is that, until now at least, some
syntactically interesting features of the language have been
implemented very poorly. Some COBOL EVALUATEs are, for example,
functionally very like a C switch or a PL/I select(<single
character>). They have not, however, been inplemented in COBOL using
a branch table, as such constructs are in C and PL/I, but as if nested
IFs had been written.
Which might be the proper implementation if the cases are sparse.
Best to start with the median case value and bisect recursively.
Storage is cheap nowadays, particularly if it's not accessed. But
a large and sparse branch table is an invitation to page faults.
I thought in today's systems paging was pretty rare.
More important, COBOL arrays were for long too small to meet the
requirements of many applications. For this reason, the practice of
extending these arrays informally by (mis)appropriating the storage
immediately following too-small ones for phantom elements addressed
using formally illicit subscripts has been common.
In the past, you've deplored as "nanny languages" (IIRC) those
which generate code to prevent such abuses.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
