Re: interesting use of NEXT SENTENCE vs. CONTINUE



Chuck,

This is an excellent response and I understand the points you made.

There are things here which you attribute to me which I never said (I don't
use phrases like 'universal truism' unless I am responding and quoting
someone else, so I don't believe that was what I said.)

I believe I may be too sensitive to having code attacked out of left field
(I wasn't expecting what you did), and I think you are too sensitive to real
or imagined 'attacks' on Unisys. (Which, as you pointed out, have never come
from me...)

These days I don't do compiler maintenance, but I HAVE done in the past, so
I understand your feeling.

Let's have another look at what has come out of this:

1. Myself (and anybody else who's interested) has gained insight into what
might be considered a 'different' architecture. GOOD.
2. I have had to change my mind about something, based on empirical
evidence, that I had always believed to be true. I realise now that it isn't
as true as I believed, so it is a qualified amendment. GOOD.
3. You had a chance to point out how adherence to the standard can improve
portability of code. GOOD.
4. There were a few spin offs which reminded us (well, certainly me, maybe
some others who have been following this) of things we 'know' but sometimes
forget... like data conversion being many times more important to
optimisation that virtually anything else. GOOD.
5. Modern optimizing compilers (and, as pointed out by Michael, hardware
chips) mean that many ideas we may have acquired and held for years
regarding efficiency, are simply not relevant in terms of modern systems.
GOOD.

Good results.

I know you are a very professional practitioner and I have nothing but
respect for your dedication, and knowledge. I was miffed at your dissection
of code I posted without expecting dissection... Guess I should know
better... :-)

Pax?

Pete.

TOP POST - remainder unsnipped for reference.

Nothing new below.

"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
news:d9eppi$4hg$1@xxxxxxxxxxxxxxxxxxxxxxx
> "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
> news:3hup97Ffr9fhU1@xxxxxxxxxxxxxxxxx
>
> > That is absolutely correct. I DID think any old compiler would be able
to
> > compile it WITH MINOR MODIFICATIONS for a specific platform.
> >
> > And I mean MINOR.
>
> Pete, that's not how it came across to me; it was more like "here's code
> that I've written to be compilable with any compiler", and having to spend
a
> *whole lot* of time in general dealing with folks who assume that a
> platform-specific extension to COBOL (of any sort, from any vendor) should
> be presumed to be portable to and applicable on any other vendor's
platform,
> I'm *very* sensitive to what is portable to/from/on our platforms and the
> platforms of others, and what is not. I have to be; it's part of my job.
>
> > I am not optimistic enough to expect 100% compatibility and I'm
certainly
> > not going to go to the Standard to see what SHOULD work.
>
> If you write your COBOL code avoiding the things that are marked as
> extensions in the language reference materials for the compiler you're
> using, you should be able to attain 100% compatibility. You don't have to
> shell out the princely sum of $18 for a copy of the standard to determine
> whether the code you write is standard or not; you could make use of your
> vendor's tools to do the same thing. And in this case, the standard to
> which your vendor's compiler conforms is most likely the '85 standard,
> which, not being the current one, is rather harder to find.
>
> < In the time I've
> > done that (always assuming I'm prepared to buy a copy of the standard
from
> > ANSI (and I am most definitely NOT)), I could've compiled the code, read
> the
> > diagnostics, corrected whatever is wrong, and got it working.
>
> Yes, you could. Might've been nice if you had!
>
> > Unlike you Chuck, I am uninterested in the standard. My only concern is
> what
> > works on the target platform.
>
> If the target platform is Unisys MCP COBOL85, then one way to make sure
that
> it works on that target platform is to start with *standards-compliant*
> COBOL.
>
> > The fact is that code, even when it IS
> > completely portable, would need to be modified for the target platform
in
> > order to optimize it anyway.
>
> Yes, that was *exactly* the point of my comments on 77-vs.-01/12, USAGE
and
> numeric capacity issues.
>
> > You mentioned the arithmetic formats and lengths preferred on your
> platform.
> > I ran tests on mine with lengths from s9(4) up to S9(18) using comp and
> > comp-5. Obviously the very short tests don't mean much.
>
> I ran tests changing J from COMP to DISPLAY to BINARY to BINARY EXTENDED,
> and came up with DRAMATICALLY different results. That's why I brought it
> up. The differences obfuscate the timings for the things we're actually
> trying to measure, and may even drive the timing differences into the
level
> of noise.
>
> One of the things I've had to learn how to spot in compiler support work
is
> how to minimize the cost of measurement and how to ensure that the
> measurements are accurate and appropriately representative.
>
> I've also had to work out explanations for bizarre results. For instance,
I
> have a strong sense that an unconditional branch to the
> immediately-following machine instruction confuses the heck out of the
> particular machine I'm running on, causing a "restart" of the instruction.
> I don't know that for sure, but the timings seem to support this. I may
> research this further at some point, but I have other priorities. And
the
> anomaly almost certainly wouldn't occur on a sizable percentage of our
> product line.
>
> > You should have your discussion about 01 levels and 77 levels with a
> system
> > programmer who uses a machine where memory synchronization is important,
> and
> > chastising me for defining a subscript that wasn't used, is so petty
it's
> > unbelievable.
>
> By the same token I've read some sentiment on CLC that declaring items at
> Level 77 serves only to provide compatibility with ancient editions of
> COBOL. There's never a difference in access-time among items declared at
> 77, 01 or 05, and thus there's absolutely no practical reason ever to use
> 77's. My response is "uh... no... that's not correct, not as a universal
> truism."
>
> > It WAS used in another version of the code that wasn't
> > published. I simply paste a block of subscripts in the format shown,
into
> > every program I write. The block ends at P (with O being skipped to
avoid
> > confusion with zero). I usually remove the ones that are not used after
> the
> > code is debugged and working (exactly as I did this time, but not for
the
> > version I posted).
>
> That indeed is a reasonable style choice. It begs the question, however,
as
> to whether that particular style choice is *universally* appropriate.
>
> > And yes, I do use INDEXED BY and indexes also.
>
> Good!
>
> > I never went to any pains to make this code suitable for any purpose
OTHER
> > THAN the one I stated so I feel that much of your commentary was really
> just
> > cheap shots.
>
> Not my intent. The code wasn't suitable for the purpose for which I was
led
> (correctly or not) to believe you intended it, that is, for it to provide
> meaningful results on the system I work on.
>
> You've been asking for performance numbers from *our* system on *your*
> programs for some days now, and since you posted this particular code in a
> message to me, I presumed (correctly or otherwise) that it was your intent
> that I provide you my results from that program.
>
> In order to provide you any performance numbers at all I had to make
certain
> changes to the program -- which brought it into conformance with the '85
> standard -- and certain other changes to the program to render those
numbers
> meaningful, some of which (Binary Extended) made use of extensions to the
> standard, some of which did not.
>
> (I think I failed to point out that inline comments -- *> -- are an
> implementor extension to ANSI '85 COBOL, not specified therein. 2002
COBOL
> has them. Personally, I really like inline comments, I think their
absence
> from COBOL was a serious shortcoming in comparison to the likes of ALGOL
and
> Pascal, and our COBOL85 implementation accepts them. If I could get away
> with this extension I'd put it in our COBOL74 as well, but that counts as
a
> New Feature and we're not doing New Features in COBOL74. One problem,
> though: not all implementations support an Area B that extends beyond
> column 72 of the source line. Ours currently does not; I deleted the
inline
> comments because I knew them irrelevant to *compilation* and *execution*.)
>
> I felt it appropriate to present what changes I needed to make to get past
> the compilation, and what changes I needed to make to minimize the impact
of
> the measurements on the results. Once I was done, the only "nonstandard"
> parts of my example seem to be the use of Usage Binary Extended (it
differs
> from Binary only in that code isn't generated to apply the "odometer
effect"
> when an item of )and the implementor-name specification for Console in
> Special-Names (I could have changed the DISPLAY ... UPON CONSOLE to simply
> DISPLAY ... and actually remained within "Nucleus Level 1" of the '85
> standard! UPON is Level 2.).
>
> > If your point was that the code, as written, was not portable, then I
have
> > no issue with that. If your point was it needed to comply with the
> standard
> > to be portable, then my response is "Bollocks!".
>
> I think the *best* way to write code that can be compiled on any platform
> whose COBOL implementation conforms to a given COBOL standard is to avoid
> the vendor's extensions beyond the standard.
>
> > The only thing that would
> > make it run on the target platform is if it fits the implementation on
> that
> > platform, as defined by the compiler vendor.
>
> I agree. If the compiler vendor has agreed to conform the implementation
to
> the standard, then a subset of "fits the implementation on that platform"
is
> "conforms to the standard", and it is *very* likely that that subset "fits
> the implementation on any platform" presuming the implementation conforms
to
> the standard.
>
> > I am well aware of the overheads in using DISPLAY UPON and in using
> ACCEPT.
> > The original code had a comment saying something to the effect of 'do
this
> > any way you like'.
>
> Unless I missed something somewhere, I didn't see that.
>
> > I NEVER use ACCEPT and DISPLAY in production environments
> > and would write the results to a log file and use FUNCTION CURRENT-DATE
> > rather than ACCEPT from TIME.(I think the last time I used that was 20
> years
> > ago in an IBM environment where there were no intrinsic functions.)
>
> > But, at least as far as I'm concerned, all of that is beside the point.
>
> Which point? The universal truisms that a GO TO that's been ALTERed runs
> faster on limited-memory systems than a comparison and conditional branch,
> or for that matter that a comparison with a conditional branch testing the
> result is always slower than an unconditional branch? I think I've
> demonstrated that both of *those* points are not universal truisms!
>
> > You can sidetrack the real issue all you like with a display of pedantry
> > based on the standard. It cuts no ice with me whatsoever.
>
> > I have written working COBOL code for at least seven platforms and never
> > once referred to the X23 or any other standard in order to do so. I have
> > maintained my own and other people's code without this 'Bible' as well.
So
> > exactly what use is it to the coal face programmer? Absolutely none.
They
> do
> > their jobs perfectly well without it.
>
> I work on the COBOL *compilers* and I refer to the standards *very* often.
> I could not provide a COBOL compiler that provides support for
> standards-compliant -- and thus portable -- code without doing so.
>
> > I really do appreciate the time you put into explaining the assembler
and
> > architecture for your platform and I found it interesting. But I'm
simply
> > appalled at your reponse to a trivial code snippet, intended for a
> specific
> > purpose (which it achieved), and the fact that you would then take it
> apart
> > based on compliance with 'Holy Writ'.
>
> I took it apart because I needed to take it apart to make it run on our
> platform. I detailed the changes I needed to make because I thought your
> expectation was that it would compile and run *with no changes* on *any*
> platform.
>
> I'm a little testy on *that* particular topic because many times in this
> forum (though not from you, to the best of my memory), the response to my
> comment "That doesn't work on a Unisys MCP platform" was something along
the
> lines of "it works on any computer that really matters to anyone", and
that
> ends up being a not-so-veiled slap at the company for which I work, and
the
> relevance of its products in the marketplace.
>
> > I don't care. The exercise was about the relative speed of branch and
> > compare instructions, on most platforms. I changed some of my ideas
after
> > running tests.
>
> Your premise wasn't originally "most", it was "universal truism".
>
> > (When is the last time you changed one of yours?)
>
> Yesterday. Why?
>
> >
> > I am sorry for the inconvenience you incurred. You didn't HAVE to spend
> time
> > doing anything. If you had posted to me privately or publicly stating
that
> > there was difficulty in getting it to run on a Unisys platform, I might
> have
> > taken another look at it or got a friend who has access to such a
platform
> > to run it for me. I said I believed the code was portable because I did
> > believe that. (Still do...). However, I would expect a reasonable person
> to
> > make minor modifications for their platform where necessary. My point is
> > that SOME amendment would be needed to optimize it for a given platform
> > anyway...
>
> I needed to change it to get it to compile. If the source code is truly
> portable it will compile in any implementation. I also changed it to
reduce
> the "metering costs".
>
> > The fact is that you PREFERRED to make thunder about standard compliance
> > than to address the issue. That's OK.
>
> I thought I *did* address the issues you raised. I also detailed the
> changes I needed to make to your "portable" program in order to address
> those issues.
>
> > It simply diminishes my opinion of you.
>
> A pity. How many language compilers do you personally maintain and
enhance?
> Are you required by the marketplace to guarantee personally that any of
them
> are compliant with some national or international "de jure" rather than
"de
> facto" standard? In my case the answer to the first is "seven by myself,
a
> couple of others with help" and to the second "yes, at least three of
them".
> I work hard on the standards committees to *enhance* and *encourage*
> universal portability. I would not have written the proposal for the '08
> standard for 128-bit draft-IEEE-754 floating-point formats in decimal and
in
> binary, and for arithmetic performed directly in those formats (basically
> taking the arithmetic rules *out* of the COBOL standard!) if I did not
> believe in the usefulness of complete portability. I just don't define
> "portable" as "compiles and runs as is on machines whose extensions
> slavishly follow the IBM implementation", nor do I define it as "requires
> major surgery before it will run in a different operating environment".
>
> > Michael said it all when he said: "Some things are obvious
> > (unnecessary buffer copies, for example), but empirical data is
> > really the way to go."
>
> > Amen to that.
>
> I certainly agree.
>
> -Chuck Stevens
>
>
>



.



Relevant Pages

  • Re: C portability is a myth
    ... > solicitation for the availability of a compiler for a given platform. ... If the source is pure Standard C ... can be successfully ported to all implementations. ...
    (comp.lang.c)
  • Re: compile+link Fujitsu Linux
    ... The Cobol standard has supported pointers for six years, ... It is common for most of a large business application to be written in Cobol, ... You don't know Python then. ... chosen the compiler options and link parameters that work best for me. ...
    (comp.lang.cobol)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... I DID think any old compiler would be able to ... > compile it WITH MINOR MODIFICATIONS for a specific platform. ... > not going to go to the Standard to see what SHOULD work. ... If you write your COBOL code avoiding the things that are marked as ...
    (comp.lang.cobol)
  • Re: Syntax for union parameter
    ... lets the compiler take advantage of some feature on a particular platform ... existent) standard and allow the code to operate the same on all platforms. ... fact specify the mechanics, even though you had not intended to do so. ... implemented on almost any new platform is a C compiler. ...
    (comp.lang.c)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... > implementations that purport to conform to a COBOL standard is to write ... I DID think any old compiler would be able to ... compile it WITH MINOR MODIFICATIONS for a specific platform. ... >> Portability depends on where you plan to port (or more likely where ...
    (comp.lang.cobol)