[Info-vax] Text processing examples with Fortran requested

[John Reagan]

"Michael Moroney" <moroney at world.std.spaamtrap.com> wrote in message 
news:hdsb7t$k62$1 at pcls4.std.com...
> "John Reagan" <johnrreagan at earthlink.net> writes:
>
>>"Michael Moroney" <moroney at world.std.spaamtrap.com> wrote in message
>>news:hds5qo$heq$1 at pcls6.std.com...
>>> brooks at cuebid.usa.hp.nospam (Rob Brooks) writes:
>>>
>>>>moroney at world.std.spaamtrap.com (Michael Moroney) writes:
>>>
>>>>> I have to deal with thousands of lines of the most gawdawful macro-32
>>>>> code ever created.
>>>
>>>>yeah, well, you spent time in SHDRIVER, so you should be well-suited
>>>>to the task of dealing with convoluted MACRO-32 :-)
>>>
>>> While SHDRIVER was certainly convoluted, it's _nothing_ compared to the
>>> hideousness of what I'm dealing with now.  Seriously.
>
>>Then I'm very afraid for you!
>
>>During the port to Itanium, we instrumented the IMACRO compiler to print 
>>out
>>various internal statistics in the .LIS file (near the command qualifier
>>summary).  One of them was the total number of flow blocks found by the
>>compiler's flow analyzer.  This, along with the number of entry/exit 
>>points;
>>routines jumping into each other; etc. was used to compute a "complexity"
>>factor.  SHDRIVER blew everybody else out of the water.  By far the most
>>complex piece of Macro-32 code in the entire system from a compiler 
>>analysis
>>point of view.
>
> You remember the code I had a couple of years ago at VMS Engineering's
> Porting to Integrity seminar?  The code where everyone said "Good luck
> with that!" and then hid under their desks?  The code that found Macro-32
> compiler bugs?  *THAT* code.  It's not awful due to the number of
> code paths (although it *is* plenty complex), it's just such an awful
> design. (evolution is a more accurate description).

Oh yeah.  I remember now.  I just tasted vomit in my mouth.

That code wasn't complex but just assumed its exactly code location in 
memory (IIRC).

John