[Info-vax] DCL Integer Overflow

[VAXman- at SendSpamHere.ORG]

In article <ok5m7q$439$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2017-07-12, VAXman-  @SendSpamHere.ORG <VAXman- at SendSpamHere.ORG> wrote:
>> In article <ok570q$hnf$6 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>>>On 2017-07-12, VAXman-  @SendSpamHere.ORG <VAXman- at SendSpamHere.ORG> wrote:
>>>> I've spent years in the bowels of DCL and know very well how it works.  I
>>>> wouldn't write 90% of the stuff I've seen in DCL and the other 10% is not
>>>> well written DCL for what it DOES do well.  I have -- there was a thread
>>>> here a year or so ago -- extended DCL with with a few more modern program-
>>>> ming constructs (while, for) but it doesn't make the fact that it's read-
>>>> as-it-goes interpreted any better.  Try booting VMS with my DCL debugger
>>>> active and you'll soon see that inordinate amounts of time are spent just
>>>> looking (scanning) for target labels -- the greatest offenders being in
>>>> the network startups.  A newer scripting language won't make this aspect
>>>> any better.  A Ramanujan-Sato series in ANY scripting language will take 
>>>> some appreciable lifetime to converge. ;)
>>>>
>>>
>>>And if you take a step back then perhaps the question should become
>>>whether the scripting language should not be using labels in that
>>>fashion and instead using more modern constructs where you know exactly
>>>where you need to go to in order to perform the next iteration of
>>>the loop.
>>
>><rolleyes>
>>
>> OK.  WHILE/END-WHILE FOR/NEXT will solve this?  Where's the END-WHILE? Or
>> the NEXT?  YOU DO NOT KNOW until you're read through the code scanning for
>> it.  
>
>Actually I'd like to back up a step and ask a question. With your
>observation above, I thought you were saying above that DCL was
>scanning the code for the label every time it was referenced.

The first time there's a reference to a label (GOTO, GOSUB, CALL), DCL needs
to scan through the procedure to find its target.  Once it's found, DCL makes
a "label" symbol which contains the RFA for the target procedure line.



>That's why I thought a structured programming language would help
>because most of the time, when you continue the loop, you are jumping
>directly back to the start of the loop. The interpreter already knows
>the location of this because you have gone through it in order to be
>able to get to where you are in the code.

Depending upon the implementation, that could be.  There's housekeeping that
is needed to know WHICH loop statement to return to when/if there are nested
loops.



>But I've just remembered that I thought I once read that DCL labels
>were cached somewhere once they have been found. If that's true then
>I don't understand why you are seeing significant CPU time after they
>have been found for the first time.

They're stored in the symbol table and they're also stored by their procedure
level.  So, if procedure A invokes procedure B (eg. $ @B.COM), DCL will need
to scan B.COM whenever a label is a target.  If B.COM then EXITs (returns)
back to A.COM, those B.COM's symbols are no longer valid.  If A.COM invokes
B.COM again, all of that label scanning and label symbol building is redone.
The startups for the networks, especially TCP/IP, do this repeatedly and to
many procedure depths.  That is why, if one doesn't understand how DCL works,
it is not a good idea to write it like a high level language.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.