"Stephen Fuld" <[email protected]d> writes:

That feature (Alter GOTO) was also in Fortran, as the, long since
deprecated, assigned GOTO statement. I believe they were there to
support some older computers that didn't have indexed jump/branch >instructions, so achieved the effect by modifying the branch
destination in the instruction itself.

Fortran's assigned goto directly corresponds to indirect branches on
modern machines, so in 1954 when Fortran was designed, the target
machines for Fortran had such instructions.

The ALTER statement looks somewhat stranger, judging from the example
given at <https://www.microfocus.com/documentation/cobol-it/4-11/user-guide/compiler-suite/procedure-division-statements-alter.html>:

...
ALTER ALTER-1-EXIT TO PROCEED TO ALTER-2-EXIT
END-IF.

DISPLAY "GO TO ALTER-1-EXIT...." LINE 4 COL 10.
GOTO ALTER-1-EXIT.

ALTER-1-EXIT.
GOTO LABEL-1.

LABEL-1.
DISPLAY "ALTER-1 EXIT!" LINE 10 COL 10.
ACCEPT DUMMY LINE 10 COL 30.
STOP RUN.

ALTER-2-EXIT.
DISPLAY "ALTER-2 EXIT!" LINE 10 COL 10.
ACCEPT DUMMY LINE 10 COL 30.
STOP RUN.

What confuses me is that there is a GOTO right in the ALTER-1-EXIT
section (or is it a procedure?). So does the ALTER change the "GOTO ALTER-1-EXIT" and every other occurence of "GOTO ALTER-1-EXIT" that
occurs in the program (as I would expect from the general rule 1. on
the web page linked above; if so, why have the "GOTO LABEL-1" which is
followed right by the label "LABEL-1."? Of is it required that the
given section or procedure starts with a GOTO, and the ALTER statement
changes that GOTO?

Let's compare this to FORTRAN's assigned goto. <https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn9j/index.html>
gives the following example:

ASSIGN 10 TO N
...
GO TO N ( 10, 20, 30, 40 )
...
10 CONTINUE
...
40 STOP

Here N could be a register, the ASSIGN statment loads a constant (the
code address of the label 10) into that register, and the GOTO N
performs a branch to that code address. The labels given in
parentheses limits the possible targets, allowing the compiler to
perform more accurate data-flow analysis and especially limit the
variables which are considered to be alive at the GOTO (I wonder when
the parenthesis part was added).

Why the strange syntax. Why not just write

N = 10

Because the ASSIGN syntax tells the compiler that it is dealing with a
label and not with an integer here, and it can perform the conversion
from label number to code address at compile time instead of having to
look the code address up in a sparse table at run-time. Another
option would have been to introduce a new type for labels, and after
declaring N to be a label the assignment above could easily have
produced code for loading the code address. But I guess the ASSIGN
feature was introduced before programming language designers tried to
attack all kinds of problems with types.

People love to point out that the assigned GOTO has been removed from
Fortran, as a damnation of the concept. But it just tells us that
Fortran programmers don't program the kind of code where this feature
is useful. Every assembly language still has this feature, and GNU C
has added it to C in the labels-as-values extension. And from there
it has spread to other C compilers: Intel's icc, Bellard's tcc, and
clang are among them. In GNU C the Fortran example looks as follows:

void *n;
n = &&l10;
...
goto *n;
...
l10: ...
...
l40:
...

Again, an existing type is used, and syntax rather than types are used
to tell the compiler what is going on. There is no way to specify the
possible targets.

I use this feature for implementing threaded-code interpreters, but
also for implementing code-copying systems (in-between things that
share some characteristics with interpreters and some with compilers).
I find it highly useful.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl wrote:

Let's compare this to FORTRAN's assigned goto. <https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn9j/index.html>
gives the following example:

ASSIGN 10 TO N
...
GO TO N ( 10, 20, 30, 40 )
...
10 CONTINUE
...
40 STOP

Here N could be a register, the ASSIGN statment loads a constant (the
code address of the label 10) into that register, and the GOTO N
performs a branch to that code address. The labels given in
parentheses limits the possible targets, allowing the compiler to
perform more accurate data-flow analysis and especially limit the
variables which are considered to be alive at the GOTO (I wonder when
the parenthesis part was added).

Why the strange syntax. Why not just write

N = 10

Because the ASSIGN syntax tells the compiler that it is dealing with a
label and not with an integer here, and it can perform the conversion
from label number to code address at compile time instead of having to
look the code address up in a sparse table at run-time. Another
option would have been to introduce a new type for labels, and after declaring N to be a label the assignment above could easily have
produced code for loading the code address. But I guess the ASSIGN
feature was introduced before programming language designers tried to
attack all kinds of problems with types.

Don't forget Fortran's alternate returns, indicated by a * in the arg list.
A caller subroutine passes *labels in the args list, and callee decides
which *label-arg it wants to return to in the RETURN statement constant expression. (This is not ambiguous because in Fortran function return
values are done by assignment to the function name, not the return
statement expression.)

call Foo (*100, *200)
...
100
...
200
...
end

subroutine Foo (*, *)
...
return 1 ! Return to callers first * label arg
...
return 2 ! Return to callers second * label arg
...
end

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

EricP wrote:

call Foo (*100, *200)
....
100
....
200
....
end

subroutine Foo (*, *)
....
return 1 ! Return to callers first * label arg
....
return 2 ! Return to callers second * label arg
....
end

The S.E.L. compiler would produce code equivalent to::

s = foo( )
switch( s )
{
case 1: ...
break;
case 2: ...
break;
}

Then the return statements simple returned the value expressed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

MitchAlsup1 wrote:

EricP wrote:

call Foo (*100, *200)
....
100
....
200
....
end

subroutine Foo (*, *)
....
return 1 ! Return to callers first * label arg
....
return 2 ! Return to callers second * label arg
....
end

The S.E.L. compiler would produce code equivalent to::

s = foo( )
switch( s )
{
case 1: ...
break;
case 2: ...
break;
}

Then the return statements simple returned the value expressed.

Yes one could do that, and assigned-GOTO could also be implemented
as a case statement. This can be more optimally implemented by loading
the label address from the arg list to a register and jumping to it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl wrote:

"Stephen Fuld" <[email protected]d> writes:

That feature (Alter GOTO) was also in Fortran, as the, long since deprecated, assigned GOTO statement. I believe they were there to
support some older computers that didn't have indexed jump/branch instructions, so achieved the effect by modifying the branch
destination in the instruction itself.

Fortran's assigned goto directly corresponds to indirect branches on
modern machines, so in 1954 when Fortran was designed, the target
machines for Fortran had such instructions.

The ALTER statement looks somewhat stranger, judging from the example
given at

<https://www.microfocus.com/documentation/cobol-it/4-11/user-guide/compiler-suite/procedure-division-statements-alter.html>:

...
ALTER ALTER-1-EXIT TO PROCEED TO ALTER-2-EXIT
END-IF.

DISPLAY "GO TO ALTER-1-EXIT...." LINE 4 COL 10.
GOTO ALTER-1-EXIT.

ALTER-1-EXIT.
GOTO LABEL-1.

LABEL-1.
DISPLAY "ALTER-1 EXIT!" LINE 10 COL 10.
ACCEPT DUMMY LINE 10 COL 30.
STOP RUN.

ALTER-2-EXIT.
DISPLAY "ALTER-2 EXIT!" LINE 10 COL 10.
ACCEPT DUMMY LINE 10 COL 30.
STOP RUN.

What confuses me is that there is a GOTO right in the ALTER-1-EXIT
section (or is it a procedure?).

It is called, consistant with the desire to make it "natural language
like", a paragraph.

So does the ALTER change the "GOTO
ALTER-1-EXIT" and every other occurence of "GOTO ALTER-1-EXIT" that
occurs in the program (as I would expect from the general rule 1. on
the web page linked above; if so, why have the "GOTO LABEL-1" which is followed right by the label "LABEL-1."?

One caveat. It has been over 40 years since I wrote any COBOL
programs, and when I was taught it, we were taught to avoid the ALTER statement, so my experience should be taken with a grain of salt.


This is a rather poor example. As best as I can tell from the full
listing on the web site you linked to, the LABEL-1 paragraph is never
executed at all! Your expectations are correct. After the Alter,
every time control is transferred to ALTER-1-Exit it will then go to ALTER-2-Exit. The only reason to have LABEL-1 immediately after the
paragraph is if the Alter was conditional. A better example usage is
some code that is executed at say the first time though,
i.e.initialization code, that execute the ALTER to skip that code on
subsequent trips through the code.

Of is it required that the
given section or procedure starts with a GOTO, and the ALTER statement changes that GOTO?

The syntax requires a paragraph that contains only the single GOTO
statement that is the target of the ALTER statement. Prior to the
ALTER statement being executed, when that paragraph is executed,
control is transferred to the target initially specified in the source
code. After the ALTER is executed, any time control is transferred to
the paragraph containing the GOTO, control will then be transferred to
the location specified in the ALTER statement. Of course, execution of
a subsequent ALTER statement can change that again.

Let's compare this to FORTRAN's assigned goto. <https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn9j/index.html>
gives the following example:

ASSIGN 10 TO N
...
GO TO N ( 10, 20, 30, 40 )
...
10 CONTINUE
...
40 STOP

Here N could be a register, the ASSIGN statment loads a constant (the
code address of the label 10) into that register, and the GOTO N
performs a branch to that code address. The labels given in
parentheses limits the possible targets, allowing the compiler to
perform more accurate data-flow analysis and especially limit the
variables which are considered to be alive at the GOTO

While not as convenient, the COBOL compiler could do the equivalent by
creating a list of all of the target paragraph names of all the ALTER
statement that specify the GOO being altered.




--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Anton Ertl <[email protected]>:

...
ALTER ALTER-1-EXIT TO PROCEED TO ALTER-2-EXIT
END-IF.
ALTER-1-EXIT.
GOTO LABEL-1.

What confuses me is that there is a GOTO right in the ALTER-1-EXIT
section (or is it a procedure?). So does the ALTER change the "GOTO >ALTER-1-EXIT" and every other occurence of "GOTO ALTER-1-EXIT" that
occurs in the program

No, it just changes that one paragraph as though it said

ALTER-1-EXIT.
GOTO ALTER-2-EXIT.

The program can flow into ALTER-1-EXIT in normal sequence, no need
get there by jumping.

The uniquely awful thing about ALTER was that there was no way to tell
whether any particular GOTO might be altered without reading the whole
program and looking for ALTER statements. It was the closest thing to
COME FROM in a language that wasn't a deliberate joke.

While the FORTRAN assigned GOTO wasn't wonderful, it was at least
clear that when you wrote GO TO N the target would depend on what was
in N.

ASSIGN 10 TO N
...
GO TO N ( 10, 20, 30, 40 )

Why the strange syntax. Why not just write

N = 10

See below.

People love to point out that the assigned GOTO has been removed from >Fortran, as a damnation of the concept. But it just tells us that
Fortran programmers don't program the kind of code where this feature
is useful.

It still has computed goto which does the same thing without needing
label variables:

GO TO (10, 42, 30), N

which says if N is 1 goto 10, if 2 goto 42, if 3 goto 30, otherwise
continue.

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> schrieb:

According to Anton Ertl <[email protected]>:

People love to point out that the assigned GOTO has been removed from >>Fortran, as a damnation of the concept. But it just tells us that
Fortran programmers don't program the kind of code where this feature
is useful.

It still has computed goto which does the same thing without needing
label variables:

GO TO (10, 42, 30), N

which says if N is 1 goto 10, if 2 goto 42, if 3 goto 30, otherwise
continue.

This has been marked as obsolescent since at least Fortran 95.
Fortran has had SELECT CASE for quite a few decades now, which
is similar to C's switch statement, except that it it much nicer
(ranges, strings, ...). Can't do Duff's Device with it, though.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 26 May 2024 18:27:32 -0000 (UTC), Stephen Fuld wrote:

It has been over 40 years since I wrote any COBOL programs,
and when I was taught it, we were taught to avoid the ALTER
statement ...

People tend to scream in horror “self-modifying code!”. But really, all it is, is a clumsy form of switch/case-statement.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

It still has computed goto which does the same thing without needing
label variables:

GO TO (10, 42, 30), N

which says if N is 1 goto 10, if 2 goto 42, if 3 goto 30, otherwise
continue.

The computed goto does not do the same thing at all. It performs a
table lookup for translating from N to the code address at run-time
(during the GOTO). You cannot use the computed goto to implement
threaded code, while AFAICS you can use the assigned goto.

Ironically, the gcc maintainers often refer to the labels-as-values
feature of GNU C "computed goto", although it corresponds to assigned
goto. The (GNU) C feature that is closest to the computed goto is
switch, with the difference being that the computed goto is dense by
design while switch may be sparse.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

EricP <[email protected]> writes:

Don't forget Fortran's alternate returns, indicated by a * in the arg list.
A caller subroutine passes *labels in the args list, and callee decides
which *label-arg it wants to return to in the RETURN statement constant >expression. (This is not ambiguous because in Fortran function return
values are done by assignment to the function name, not the return
statement expression.)

call Foo (*100, *200)
...
100
...
200
...
end

subroutine Foo (*, *)
...
return 1 ! Return to callers first * label arg
...
return 2 ! Return to callers second * label arg
...
end

Interesting. Rudimentary explicit continuation-passing style at the
dawn of programming languages. Of course, these days it would mean
that you better not use the common call and return instructions,
because the branch prediction for the return would be wrong if return
1 or return 2 would be used. But using plain jump for the call and
indirect jumps for the returns should be efficient on modern CPUs.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 27 May 2024 08:05:09 GMT, Anton Ertl wrote:

Rudimentary explicit continuation-passing style at the
dawn of programming languages.

Really just a rudimentary form of exception handling. True continuations
would allow you to resume execution within some call frame you had
previously exited.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro wrote:

On Sun, 26 May 2024 18:27:32 -0000 (UTC), Stephen Fuld wrote:

It has been over 40 years since I wrote any COBOL programs,
and when I was taught it, we were taught to avoid the ALTER
statement ...

People tend to scream in horror “self-modifying code!”. But really,
all it is, is a clumsy form of switch/case-statement.

Except, As John Levine pointed out, while with the case/switch
statement "where to go" is explicitly based on the current value of
some variable named in the statement, and assigning a value to that
variable is usually pretty close to the case/switch statement, with Alter/Assign GOTO where to go is determoned by code scattered around
the program, and often not just before in time, the value is used. So
while they may be semantically equivalent, in practice, there was a big difference in ease of user comprehension and debugging of the program.



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Anton Ertl <[email protected]>:

EricP <[email protected]> writes:

Don't forget Fortran's alternate returns, indicated by a * in the arg list.

Interesting. Rudimentary explicit continuation-passing style at the
dawn of programming languages.

Not so much. The original Fortran didn't have subroutines at all,
Fortran II added them, and let you pass function or subroutine names
for indirect calls. But I don't see the alternate returns in any 70x
or other second generation Fortran. They appeared in IBM S/360 Fortran
IV in 1965, so it's more like late morning than dawn.

The alternate subroutine returns were equivalent to storing the return
value in a hidden variable, with a computed GOTO after the call. The
manual even says so. As someone else noted, they were error returns,
not coroutines.

S/360 Fortran IV added the ENTRY statement which you could indeed use
for simple coroutines. All of a subroutine's local variables were
static, arguments were normally handled by copy-in/copy-out, and each
ENTRY statement had its own list of arguments. Any local variable or
argument not in the ENTRY list kept its value from the previous call
so you could pick up from where you left off last time.

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <[email protected]d> writes:

On Mon, 27 May 2024 08:05:09 GMT, Anton Ertl wrote:

Rudimentary explicit continuation-passing style at the
dawn of programming languages.

Really just a rudimentary form of exception handling. True continuations >would allow you to resume execution within some call frame you had
previously exited.

With continuation-passing style the called functions never return, so
you don't need all the complexities of full continuations in a
language that can return.

My expectation was that one would use the *labels for error returns
(and would avoid the need for an if after the call). But now that you
have mentioned exceptions, I wonder whether it is possible to pass a
*label on to another subroutine, and then directly return to a far-out
error handler, similar to exceptions. That would require cleaning up
the stack.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl wrote:

John Levine <[email protected]> writes:

It still has computed goto which does the same thing without needing
label variables:

GO TO (10, 42, 30), N

which says if N is 1 goto 10, if 2 goto 42, if 3 goto 30, otherwise >>continue.

The computed goto does not do the same thing at all. It performs a
table lookup for translating from N to the code address at run-time
(during the GOTO). You cannot use the computed goto to implement
threaded code, while AFAICS you can use the assigned goto.

You can use computed goto to do threaded codes when the thread switches
are cooperative (multi-threading).

Ironically, the gcc maintainers often refer to the labels-as-values
feature of GNU C "computed goto", although it corresponds to assigned
goto. The (GNU) C feature that is closest to the computed goto is
switch, with the difference being that the computed goto is dense by
design while switch may be sparse.

- anton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl wrote:

EricP <[email protected]> writes:

Don't forget Fortran's alternate returns, indicated by a * in the arg
list.
A caller subroutine passes *labels in the args list, and callee decides >>which *label-arg it wants to return to in the RETURN statement constant >>expression. (This is not ambiguous because in Fortran function return >>values are done by assignment to the function name, not the return >>statement expression.)

call Foo (*100, *200)
...
100
...
200
...
end

subroutine Foo (*, *)
...
return 1 ! Return to callers first * label arg
...
return 2 ! Return to callers second * label arg
...
end

Interesting. Rudimentary explicit continuation-passing style at the
dawn of programming languages. Of course, these days it would mean
that you better not use the common call and return instructions,
because the branch prediction for the return would be wrong if return
1 or return 2 would be used. But using plain jump for the call and
indirect jumps for the returns should be efficient on modern CPUs.

That is why the subroutine returns a value and the return point
implements the switch (control transfer to proper label.

{You DO NOT return to the label, you return normally and then
go to the proper label.}

- anton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The fact that an ALTER GOTO statement can change where a GOTO
statement branches - without any indication within the GOTO statement
itself that it may have other destinatiions than the primary one -
means that this statement is an _obvious_ method of inserting
malicious code into the source code of a program.

And indeed, given that COBOL is typically used for programs handling
financial transactions, I have no doubt that it _was_ so used.

I find this to be an example of incredibly irresponsible language
design.

John Savard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

MitchAlsup1 wrote:

Anton Ertl wrote:

EricP <[email protected]> writes:

Don't forget Fortran's alternate returns, indicated by a * in the arg
list.
A caller subroutine passes *labels in the args list, and callee decides
which *label-arg it wants to return to in the RETURN statement constant
expression. (This is not ambiguous because in Fortran function return
values are done by assignment to the function name, not the return
statement expression.)

call Foo (*100, *200)
...
100
...
200
...
end

subroutine Foo (*, *)
...
return 1 ! Return to callers first * label arg
...
return 2 ! Return to callers second * label arg
...
end

Interesting. Rudimentary explicit continuation-passing style at the
dawn of programming languages. Of course, these days it would mean
that you better not use the common call and return instructions,
because the branch prediction for the return would be wrong if return
1 or return 2 would be used. But using plain jump for the call and
indirect jumps for the returns should be efficient on modern CPUs.

That is why the subroutine returns a value and the return point
implements the switch (control transfer to proper label.

{You DO NOT return to the label, you return normally and then go to the proper label.}

You still could do it by callee loading the arg address to register
and jumping directly there.

If it uses callee stack cleanup then you load the reg and pop the
stack before jumping.

If it uses caller stack cleanup then since caller controls what jump
addresses are passed to the callee, caller follows labels 100 and 200
each with stack cleanup code then continues normally.

If it doesn't use a stack at all, as I understand IBM Fortran did,
then it doesn't need cleanup.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Savard wrote:

The fact that an ALTER GOTO statement can change where a GOTO
statement branches - without any indication within the GOTO statement
itself that it may have other destinatiions than the primary one -

But that is not quite true. The GOTO that is to altered must be the
only statement in a paragraph. Since this construction has no other
obvious purpose, its presence gives a clue that it might have been
altered.

means that this statement is an obvious method of inserting
malicious code into the source code of a program.

And note that the paragraph that is the target of the altered GOTO
statement must be within the same program, so any code so executed must
be readily available for inspection.

And indeed, given that COBOL is typically used for programs handling financial transactions, I have no doubt that it was so used.

Do you have any evidence of this?

I find this to be an example of incredibly irresponsible language
design.

Was it irresponsible in Fortran?




--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stephen Fuld wrote:

John Savard wrote:

The fact that an ALTER GOTO statement can change where a GOTO
statement branches - without any indication within the GOTO statement
itself that it may have other destinatiions than the primary one -

But that is not quite true. The GOTO that is to altered must be the
only statement in a paragraph. Since this construction has no other
obvious purpose, its presence gives a clue that it might have been
altered.

means that this statement is an obvious method of inserting
malicious code into the source code of a program.

And note that the paragraph that is the target of the altered GOTO
statement must be within the same program, so any code so executed must
be readily available for inspection.

And indeed, given that COBOL is typically used for programs handling
financial transactions, I have no doubt that it was so used.

Do you have any evidence of this?

I find this to be an example of incredibly irresponsible language
design.

Was it irresponsible in Fortran?

What appears irresponsible in 2024, with 5GHz CPUs and TBs of main
memory internet connected and used not for computing but for
leisure, is not what would look irresponsible with 5Khz CPUs with
64KB of main memory and no outside communications.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

EricP wrote:

MitchAlsup1 wrote:

Anton Ertl wrote:

EricP <[email protected]> writes:

Don't forget Fortran's alternate returns, indicated by a * in the arg
list.
A caller subroutine passes *labels in the args list, and callee decides >>>> which *label-arg it wants to return to in the RETURN statement constant >>>> expression. (This is not ambiguous because in Fortran function return
values are done by assignment to the function name, not the return
statement expression.)

call Foo (*100, *200)
...
100
...
200
...
end

subroutine Foo (*, *)
...
return 1 ! Return to callers first * label arg
...
return 2 ! Return to callers second * label arg
...
end

Interesting. Rudimentary explicit continuation-passing style at the
dawn of programming languages. Of course, these days it would mean
that you better not use the common call and return instructions,
because the branch prediction for the return would be wrong if return
1 or return 2 would be used. But using plain jump for the call and
indirect jumps for the returns should be efficient on modern CPUs.

That is why the subroutine returns a value and the return point
implements the switch (control transfer to proper label.

{You DO NOT return to the label, you return normally and then go to the

proper label.}

You still could do it by callee loading the arg address to register
and jumping directly there.

If it uses callee stack cleanup then you load the reg and pop the
stack before jumping.

If it uses caller stack cleanup then since caller controls what jump addresses are passed to the callee, caller follows labels 100 and 200
each with stack cleanup code then continues normally.

If it doesn't use a stack at all, as I understand IBM Fortran did,
then it doesn't need cleanup.

IBM FORTRAN used a list of register store areas--thus pretty much like
a stack, just without the ability to be reentrant or recursive.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 27 May 2024 15:08:42 -0600, John Savard wrote:

I find this to be an example of incredibly irresponsible language
design.

In those days, hardware was expensive, and human time was considered (relatively) cheap.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 27 May 2024 18:19:25 +0000, MitchAlsup1 wrote:

You can use computed goto to do threaded codes when the thread switches
are cooperative (multi-threading).

And in theory you could implement a Linux kernel in a Markov algorithm.
But who would want to?

The difference between computer science and maths is that computer science
is very much concerned with what is practical, not just with what is (mathematically) possible or impossible.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 27 May 2024 17:03:33 GMT, Anton Ertl wrote:

But now that you have
mentioned exceptions, I wonder whether it is possible to pass a *label
on to another subroutine, and then directly return to a far-out error handler, similar to exceptions. That would require cleaning up the
stack.

I think this is commonly done, not by a direct jump, but by a kind of “unwind” procedure.

VMS even had a special system service, SYS$UNWIND, to help with this.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Savard wrote:

On Mon, 27 May 2024 22:40:32 -0000 (UTC), "Stephen Fuld" <[email protected]d> wrote:

John Savard wrote:

I find this to be an example of incredibly irresponsible language
design.

Was it irresponsible in Fortran?

I don't understand that question. FORTRAN contained no such language construct.

It had the computed GOTO and the assigned GOTO.

The assigned GOTO was obviously what I was referring to.

snip

Now, there was also the assigned GOTO, and in a way one could
say that it was "closer" to what COBOL had.

The assigned GOTO was:

GOTO LABEL,(1035,1045,1065)

and somewhere else you would say something like

ASSIGN 1045 TO LABEL

Although this performed the same functionality as the ALTER
GOTO statement in COBOL was intended for, an assigned GOTO
still obviously had multiple different destinations, based on what
was assigned to the variable LABEL somewhere else.

What was irresponsible about ALTER GOTO was that if such a
thing existed in FORTRAN, one would have

GOTO 12

and

ALTER GOTO 12 TO 23

somewhere else. Now that would give no indication of its
presence, and it would thus be wholly confusing.

As I said before, you could easily scan the source code and find all
the ALTER statements and create a list of the potential targets similar
to the list in parentheses in Fortrans equivalent functionality. So
your objection is that the possible targets are not listed in one place?



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 27 May 2024 22:40:32 -0000 (UTC), "Stephen Fuld" <[email protected]d> wrote:

John Savard wrote:

I find this to be an example of incredibly irresponsible language
design.

Was it irresponsible in Fortran?

I don't understand that question. FORTRAN contained no such language
construct.

It had the computed GOTO and the assigned GOTO.

The computed GOTO was:

GOTO (10,20,30), I

and somewhere else you would say I=2, and so it was
obvious that the GOTO could go to 10, 20, or 30 depending on how
I was set somewhere else.

That was no more irresponsible than having an IF statement in
FORTRAN.

Now, there was also the _assigned_ GOTO, and in a way one could
say that it was "closer" to what COBOL had.

The assigned GOTO was:

GOTO LABEL,(1035,1045,1065)

and somewhere else you would say something like

ASSIGN 1045 TO LABEL

Although this performed the same _functionality_ as the ALTER
GOTO statement in COBOL was intended for, an assigned GOTO
still obviously had multiple different destinations, based on what
was assigned to the variable LABEL somewhere else.

What was irresponsible about ALTER GOTO was that if such a
thing existed in FORTRAN, one would have

GOTO 12

and

ALTER GOTO 12 TO 23

somewhere else. Now _that_ would give no indication of its
presence, and it would thus be wholly confusing.

Of course, in FORTRAN, you _can_ change 12 to 23... because
pointers to constants are passed to subroutines, but that will only
smash uses of the number 12 in _calculations_, *not* 12 as
a _line number_. But that _is_ also a serious fault in FORTRAN.
Donstants should always be copied over, and only a pointer to the
copy passed to a subroutine, to allow no chance of them being
accidentally overwritten.

John Savard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

MitchAlsup1 wrote:

Stephen Fuld wrote:

John Savard wrote:

snip

I find this to be an example of incredibly irresponsible language
design.

Was it irresponsible in Fortran?

What appears irresponsible in 2024, with 5GHz CPUs and TBs of main
memory internet connected and used not for computing but for
leisure, is not what would look irresponsible with 5Khz CPUs with
64KB of main memory and no outside communications.

Just to be clear, I don't think it was irresponsible in either
language. There were reasons for it, and perhaps they were good ones,
at least for some target architetures. But clearly over time, as you
say, they were proven to be bad (not irresponsible) decisions, and the
features in both languages were deprecated than, I believe, removed.

My point in mentioning Fortran is that semantically both languages had essentially equivalent features, yet John singled out COBOL for being irresoinsible.




--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Savard wrote:

The fact that an ALTER GOTO statement can change where a GOTO
statement branches - without any indication within the GOTO statement
itself that it may have other destinatiions than the primary one -
means that this statement is an _obvious_ method of inserting
malicious code into the source code of a program.

And indeed, given that COBOL is typically used for programs handling financial transactions, I have no doubt that it _was_ so used.

I find this to be an example of incredibly irresponsible language
design.

How is this different from having jump/call tables in any other
language, or just a standalone trampoline/indirect jump?

Under the hood, more or less the exact same thing happens: If you can
reach and modify the jump table, then you can insert your new functionality/malware before branching back to the original target.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 28 May 2024 04:06:42 -0000 (UTC), Stephen Fuld wrote:

As I said before, you could easily scan the source code ...

Who could? Remember code was on punch cards in those days, and editors did
not provide any kind of useful search/replace functionality. So all “scanning” would have been done by fallible human eyeballs.

And given how verbose COBOL code is, that just adds to the bulk of the
code needing such “scanning”.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] (MitchAlsup1) writes:

Anton Ertl wrote:

You cannot use the computed goto to implement
threaded code, while AFAICS you can use the assigned goto.

You can use computed goto to do threaded codes when the thread switches
are cooperative (multi-threading).

Threaded code <https://en.wikipedia.org/wiki/Threaded_code> has
nothing to do with multi-threading.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <[email protected]d> writes:

On Tue, 28 May 2024 04:06:42 -0000 (UTC), Stephen Fuld wrote:

As I said before, you could easily scan the source code ...

Who could? Remember code was on punch cards in those days, and editors did >not provide any kind of useful search/replace functionality. So all >“scanning” would have been done by fallible human eyeballs.

Most mainframe COBOL compilers in that era could produce a symbol
cross reference. No fallable human eyeballs involved, the computer
did the hard word of correlating symbol names with lines on which
they were referenced.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Stephen Fuld <[email protected]d>:

As I said before, you could easily scan the source code and find all
the ALTER statements ...

Hm, I'm guessing you've never dropped a box containing 2000 source cards.

COBOL dates from about 1960, while online text editors, as opposed to
coding forms and keypunches, didn't become common until the 1970s and
in some places even later.

It really mattered that it was obvious that a Fortran assigned GOTO
could go anywhere, but in COBOL an altered GOTO looked just like an
unaltered one.

Dunno why COBOL didn't have label variables instead. It wouldn't
have been any harder.
--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine wrote:

According to Stephen Fuld <[email protected]d>:

As I said before, you could easily scan the source code and find all
the ALTER statements ...

Hm, I'm guessing you've never dropped a box containing 2000 source
cards.

I have (remember using a marker to put a diagonal line across the top
of the deck to make it easier to spot an out of order card? :-(. But
that isn't the point. When I said scan, I was referring to the paper
listings that, in the day, were easily available.

COBOL dates from about 1960, while online text editors, as opposed to
coding forms and keypunches, didn't become common until the 1970s and
in some places even later.

Sure, but paper listings were available long before online text
editors. That is what I used, circa early 1970s.

It really mattered that it was obvious that a Fortran assigned GOTO
could go anywhere, but in COBOL an altered GOTO looked just like an
unaltered one.

While I suppose you could code a paragraph with only a GOTO statement, (required syntax for the ALTERable GOTO), I see no reason to, so while
the GOTO statement itself was syntactically identical to a non
ALTERable GOTO, the fact that it was in a paragraph by itself made it
unique in the source code listing.

Dunno why COBOL didn't have label variables instead. It wouldn't
have been any harder.

I don't know either.


Note that I am absolutely not arguing that ALTER GOTO was a good idea.
I am just responding to John's assertion that putting it in the
language was "irresponsible", because a programmer could "hide"
malicious code.

While I suppose any feature that makes code harder to comprehend makes
it easier to hide malicious code, John presented no evidence that
anyone ever did this, and I suspect that "easier to hide malicious
code" was not among the most important reasons for the feature's
deprecation.



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Stephen Fuld" <[email protected]d> writes:

John Levine wrote:

According to Stephen Fuld <[email protected]d>:

As I said before, you could easily scan the source code and find all
the ALTER statements ...

Hm, I'm guessing you've never dropped a box containing 2000 source
cards.

I have (remember using a marker to put a diagonal line across the top
of the deck to make it easier to spot an out of order card? :-(. But
that isn't the point. When I said scan, I was referring to the paper >listings that, in the day, were easily available.

We always used the sequence number field with COBOL, so the
deck could be sorted using a card sorter if dropped.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Scott Lurndal wrote:

"Stephen Fuld" <[email protected]d> writes:

John Levine wrote:

According to Stephen Fuld <[email protected]d>:

As I said before, you could easily scan the source code and find

all >> > the ALTER statements ...

Hm, I'm guessing you've never dropped a box containing 2000 source
cards.

I have (remember using a marker to put a diagonal line across the
top of the deck to make it easier to spot an out of order card?
:-(. But that isn't the point. When I said scan, I was referring
to the paper listings that, in the day, were easily available.

We always used the sequence number field with COBOL, so the
deck could be sorted using a card sorter if dropped.

Good point. I had forgotten about that.



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stephen Fuld <[email protected]d> schrieb:

Scott Lurndal wrote:

"Stephen Fuld" <[email protected]d> writes:

John Levine wrote:

According to Stephen Fuld <[email protected]d>:

As I said before, you could easily scan the source code and find

all >> > the ALTER statements ...

Hm, I'm guessing you've never dropped a box containing 2000 source
cards.

I have (remember using a marker to put a diagonal line across the
top of the deck to make it easier to spot an out of order card?
:-(. But that isn't the point. When I said scan, I was referring
to the paper listings that, in the day, were easily available.

We always used the sequence number field with COBOL, so the
deck could be sorted using a card sorter if dropped.

Good point. I had forgotten about that.

The ISPF editor used to add these automagically, without them being
visible, for FB80 files.

Worked great the first time I tried to run LaTeX, which was on a
mainframe... I could not make heads or tails of the error messages.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Koenig wrote:

Stephen Fuld <[email protected]d> schrieb:

Scott Lurndal wrote:

"Stephen Fuld" <[email protected]d> writes:

John Levine wrote:

According to Stephen Fuld <[email protected]d>:

As I said before, you could easily scan the source code and

find >> all >> > the ALTER statements ...

Hm, I'm guessing you've never dropped a box containing 2000

source >> >> cards.

I have (remember using a marker to put a diagonal line across the
top of the deck to make it easier to spot an out of order card?
:-(. But that isn't the point. When I said scan, I was

referring >> > to the paper listings that, in the day, were easily
available. >>

We always used the sequence number field with COBOL, so the
deck could be sorted using a card sorter if dropped.

Good point. I had forgotten about that.

The ISPF editor used to add these automagically, without them being
visible, for FB80 files.

Worked great the first time I tried to run LaTeX, which was on a
mainframe... I could not make heads or tails of the error messages.

See what problems you get when you use that newfangled technology!
:-)

*Real* programmers used actual punched cards! :-)




--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stephen Fuld <[email protected]d> schrieb:

Thomas Koenig wrote:

Stephen Fuld <[email protected]d> schrieb:

Scott Lurndal wrote:

"Stephen Fuld" <[email protected]d> writes:

John Levine wrote:

According to Stephen Fuld <[email protected]d>:

As I said before, you could easily scan the source code and

find >> all >> > the ALTER statements ...

Hm, I'm guessing you've never dropped a box containing 2000

source >> >> cards.

I have (remember using a marker to put a diagonal line across the
top of the deck to make it easier to spot an out of order card?
:-(. But that isn't the point. When I said scan, I was

referring >> > to the paper listings that, in the day, were easily
available. >>

We always used the sequence number field with COBOL, so the
deck could be sorted using a card sorter if dropped.

Good point. I had forgotten about that.

The ISPF editor used to add these automagically, without them being
visible, for FB80 files.

Worked great the first time I tried to run LaTeX, which was on a
mainframe... I could not make heads or tails of the error messages.

See what problems you get when you use that newfangled technology!
:-)

*Real* programmers used actual punched cards! :-)

Never had the chance, they were discontinued before I started
doing things on a mainframe.

But the mainframe was cool, mainly because it had a laser printer
and could do 300 dpi black/white output. That was a revelation at
a time when the best I had seen so far were dot matrix printers.

There was even a graphics terminal which could actually display
LaTeX output before printing, and you didn't even have to wait
to pick up the printout. That was extra cool, but burnt up the
allotted CPU time of a free student account faster than anything.

Before long, I got an account on UNIX workstations and never
looked back (except for using the vector computer, which also
ran a MVS variant).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stephen Fuld wrote:

Scott Lurndal wrote:

"Stephen Fuld" <[email protected]d> writes:

John Levine wrote:

According to Stephen Fuld <[email protected]d>:

As I said before, you could easily scan the source code and find

all >> > the ALTER statements ...

Hm, I'm guessing you've never dropped a box containing 2000 source
cards.

I have (remember using a marker to put a diagonal line across the
top of the deck to make it easier to spot an out of order card?
:-(. But that isn't the point. When I said scan, I was referring
to the paper listings that, in the day, were easily available.

We always used the sequence number field with COBOL, so the
deck could be sorted using a card sorter if dropped.

Good point. I had forgotten about that.

While we did have access to a card sorter,
We simply used magic marker and diagonal lines on the box of cards.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 28 May 2024 15:27:37 -0000 (UTC), John Levine wrote:

Hm, I'm guessing you've never dropped a box containing 2000 source
cards.

This is why the source code didn’t go beyond column 72: so that the last 8 columns could be used for a sequence number.

A standard piece of equipment in computer shops in those days was a card sorter: if your cards fell out of order, just stick them in there, tell it
to sort numerically on columns 73-80, and there was your deck nice and
tidy again.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 28 May 2024 04:06:42 -0000 (UTC), "Stephen Fuld" <[email protected]d> wrote:

As I said before, you could easily scan the source code and find all
the ALTER statements and create a list of the potential targets similar
to the list in parentheses in Fortrans equivalent functionality. So
your objection is that the possible targets are not listed in one place?

My objection is that the GOTO statement affected by the ALTER GOTO
does not have a form which clearly and unambiguously indicates that it
is potentially alterable by an ALTER GOTO statement.

It looks just like an ordinary GOTO statement to which no ALTER GOTO
statement has been applied.

Surely that should be obvious.

It isn't
GOTO THAT-LABEL OR MAYBE SOMEWHERE ELSE

it's just
GOTO THAT-LABEL

but that isn't really what it means.

What has to be "in one place" isn't necessarily all the possible
destinations (although that would be very helpful) but the fact of
alteration being a possibility, which is an unusual thing not normally applicable to a GOTO.

John Savard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 28 May 2024 16:54:36 -0000 (UTC), "Stephen Fuld" <[email protected]d> wrote:

Jo so while
the GOTO statement itself was syntactically identical to a non
ALTERable GOTO, the fact that it was in a paragraph by itself made it
unique in the source code listing.

I will admit that I wasn't familiar enough with COBOL to be aware of
this mitigating circumstance.

But being in a paragraph by itself doesn't make what's going on
_obvious_ even to someone not an expert in the language the way the
syntax of the assigned GOTO in FORTRAN does, so I still claim it is significantly less bad.

John Savard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 29 May 2024 04:53:26 -0000 (UTC), Lawrence D'Oliveiro
<[email protected]d> wrote:

This is why the source code didn�t go beyond column 72: so that the last 8 >columns could be used for a sequence number.

The cards were 80 columns wide because this improved on the old 45
column cards, allowing more information to be stored per card when
used with tab equipment.

Then the IBM 704 computer came along, which had a 36 bit word length.

IBM, in its infinite wisdom, decided that computer users, unlike tab
equipment users, could get by without being able to use the whole
card. So they made their card reader read the card by rows, with the
holes in the first 36 columns going in one word, and the holes in the
next 36 columns going in the next word.

The card readers probably had plugboards in them, so you could choose
a different eight columns to skip if you wanted. This would be handy
if you wanted to port programs written in ALTAC for a Philco 2000
computer.

So when FORTRAN was written, they just put the program in the columns
on the card that the computer could read, and being able to have
sequence numbers was just a happy accident. But it was found to be
sufficiently useful that it was kept in other machines that could and
did read the whole card.

So the sequence number was the effect and not the cause.

John Savard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Savard wrote:

On Tue, 28 May 2024 04:06:42 -0000 (UTC), "Stephen Fuld" <[email protected]d> wrote:

As I said before, you could easily scan the source code and find all
the ALTER statements and create a list of the potential targets similar
to the list in parentheses in Fortrans equivalent functionality. So
your objection is that the possible targets are not listed in one place?

My objection is that the GOTO statement affected by the ALTER GOTO
does not have a form which clearly and unambiguously indicates that it
is potentially alterable by an ALTER GOTO statement.

It looks just like an ordinary GOTO statement to which no ALTER GOTO statement has been applied.

Surely that should be obvious.

It isn't
GOTO THAT-LABEL OR MAYBE SOMEWHERE ELSE

it's just
GOTO THAT-LABEL

but that isn't really what it means.

What has to be "in one place" isn't necessarily all the possible
destinations (although that would be very helpful) but the fact of
alteration being a possibility, which is an unusual thing not normally applicable to a GOTO.

John Savard

I get your point. It doesn't say "goto variable" where the variable
is an immediate warning that the destination can change,
it says "goto constant" and then behind your back overwrites the constant.

The only way one can know for sure that any "goto label" actually does
goto that label is by reading every other line in the subroutine.

It would have a similar effect if it allowed
i = 42
and then elsewhere it said "alter 42 to 17".

I can see company coding standards banning this feature,
not because it might be abused, but because even when used as
intended it would be a nightmare for code maintenance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to EricP <[email protected]>:

It would have a similar effect if it allowed
i = 42
and then elsewhere it said "alter 42 to 17".

As others have noticed, many versions of Fortran let you do that due
to the way they implemented call by reference. But that was always
considered a bug.

I can see company coding standards banning this feature,
not because it might be abused, but because even when used as
intended it would be a nightmare for code maintenance.

Exactly. COBOL was remarkably casual about control flow, e.g.

A. PERFORM C through E EXACTLY 2 TIMES.

B. ...

C. ...

D. ...

E. ...

F. ...

The sequence would be A C D E C D E B C D E F

There was nothing in the code to tell you that C was the start of a subprocedure or that E was its end. "Don't do that."



--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Terje Mathisen <[email protected]> writes:

John Savard wrote:

The fact that an ALTER GOTO statement can change where a GOTO
statement branches - without any indication within the GOTO statement
itself that it may have other destinatiions than the primary one -
means that this statement is an _obvious_ method of inserting
malicious code into the source code of a program.

And indeed, given that COBOL is typically used for programs handling
financial transactions, I have no doubt that it _was_ so used.

I find this to be an example of incredibly irresponsible language
design.

How is this different from having jump/call tables in any other
language, or just a standalone trampoline/indirect jump?

Under the hood, more or less the exact same thing happens: If you can
reach and modify the jump table, then you can insert your new functionality/malware before branching back to the original target.

The ALTER facility, or any more-or-less equivalent features in other
languages, is a high-level language version of self-modifying code. Self-modifying code is bad; ALTER and friends aren't any better,
regardless of whether they are easy to implement.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 29 May 2024 01:26:26 -0600, John Savard wrote:

My objection is that the GOTO statement affected by the ALTER GOTO does
not have a form which clearly and unambiguously indicates that it is potentially alterable by an ALTER GOTO statement.

It has a label. Normal GOTO statements don’t need labels.

Not much to go on, I know, but there it is. Machine efficiency was
considered more important than program maintainability in those days.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Savard <[email protected]d> schrieb:

On Wed, 29 May 2024 04:53:26 -0000 (UTC), Lawrence D'Oliveiro
<[email protected]d> wrote:

This is why the source code didn’t go beyond column 72: so that the last 8 >>columns could be used for a sequence number.

The cards were 80 columns wide because this improved on the old 45
column cards, allowing more information to be stored per card when
used with tab equipment.

Then the IBM 704 computer came along, which had a 36 bit word length.

IBM, in its infinite wisdom, decided that computer users, unlike tab equipment users, could get by without being able to use the whole
card. So they made their card reader read the card by rows, with the
holes in the first 36 columns going in one word, and the holes in the
next 36 columns going in the next word.

Not quite: The card was read by rows using the accumulator and
the MQ register, each of which had 36 "normal" registers, for a
total of 72 bits. So, there was a valid technical reason for that
choice.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stephen Fuld wrote:

Thomas Koenig wrote:

See what problems you get when you use that newfangled technology!
:-)

*Real* programmers used actual punched cards! :-)

BTDT, never want to go back.

This was using hand-punched cards, writing FORTRAN 2 code with the
Hollerith text constants so you had to count very carefully:

FORMAT 27HTHIS IS A VERY LONG TEXT STRING...

Good riddance!

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Terje Mathisen wrote:

Stephen Fuld wrote:

Thomas Koenig wrote:

See what problems you get when you use that newfangled technology!
:-)

*Real* programmers used actual punched cards! :-)

BTDT, never want to go back.

Of course, I agree.

This was using hand-punched cards, writing FORTRAN 2 code with the
Hollerith text constants so you had to count very carefully:

FORMAT 27HTHIS IS A VERY LONG TEXT STRING...

And, as your example above demonstrates, very error prone! :-)

Good riddance!

Yup!




--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 30 May 2024 10:15:54 +0200, Terje Mathisen wrote:

This was using hand-punched cards, writing FORTRAN 2 code with the
Hollerith text constants so you had to count very carefully:

FORMAT 27HTHIS IS A VERY LONG TEXT STRING...

Hey, did you not notice the columns were numbered? So all you had to do to determine the length of the string was subtract column numbers?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro wrote:

On Thu, 30 May 2024 10:15:54 +0200, Terje Mathisen wrote:

This was using hand-punched cards, writing FORTRAN 2 code with the
Hollerith text constants so you had to count very carefully:

FORMAT 27HTHIS IS A VERY LONG TEXT STRING...

Hey, did you not notice the columns were numbered? So all you had to do to determine the length of the string was subtract column numbers?

Hey, did you not read what I wrote about this being hand-punched cards?
By the time I got to the end of the string it was too late to go back
and update the 27H count. I had to count these strings on paper, in the notebook where I had written the code before I got access to the card
puncher. (A glorified typewriter)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <[email protected]d> writes:

On Thu, 30 May 2024 10:15:54 +0200, Terje Mathisen wrote:

This was using hand-punched cards, writing FORTRAN 2 code with the
Hollerith text constants so you had to count very carefully:

FORMAT 27HTHIS IS A VERY LONG TEXT STRING...

Hey, did you not notice the columns were numbered? So all you had to do to >determine the length of the string was subtract column numbers?

Aside the fact that you needed to know the length _before_ you punched
the rest of the "very long text string" on the card? Or are you
suggesting that coding forms (which were used for third party punching)
were a prerequisite for punching program cards? In either case,
you have become quite tiresome....

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 03 Jun 2024 14:11:46 GMT, Scott Lurndal wrote:

Lawrence D'Oliveiro <[email protected]d> writes:

On Thu, 30 May 2024 10:15:54 +0200, Terje Mathisen wrote:

This was using hand-punched cards, writing FORTRAN 2 code with the
Hollerith text constants so you had to count very carefully:

FORMAT 27HTHIS IS A VERY LONG TEXT STRING...

Hey, did you not notice the columns were numbered? So all you had to do
to determine the length of the string was subtract column numbers?

Aside the fact that you needed to know the length _before_ you punched
the rest of the "very long text string" on the card? Or are you
suggesting that coding forms (which were used for third party punching)
were a prerequisite for punching program cards?

Of course people used coding forms.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 3 Jun 2024 10:33:32 +0200, Terje Mathisen wrote:

Lawrence D'Oliveiro wrote:

On Thu, 30 May 2024 10:15:54 +0200, Terje Mathisen wrote:

This was using hand-punched cards, writing FORTRAN 2 code with the
Hollerith text constants so you had to count very carefully:

FORMAT 27HTHIS IS A VERY LONG TEXT STRING...

Hey, did you not notice the columns were numbered? So all you had to do
to determine the length of the string was subtract column numbers?

Hey, did you not read what I wrote about this being hand-punched cards?
By the time I got to the end of the string it was too late to go back
and update the 27H count.

Card-punch machines had an option for that too, didn’t they? Certainly the IBM 129 that I used could do that: copy the card to a new card, up to but
not including the incorrect part, then enter the correction, then copy the
rest of the card.

Remember, punched cards had already been in use for about a century and a
half by that point, so techniques for dealing with their foibles were well-known.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro wrote:

On Mon, 03 Jun 2024 14:11:46 GMT, Scott Lurndal wrote:

Lawrence D'Oliveiro <[email protected]d> writes:

On Thu, 30 May 2024 10:15:54 +0200, Terje Mathisen wrote:

This was using hand-punched cards, writing FORTRAN 2 code with the
Hollerith text constants so you had to count very carefully:

FORMAT 27HTHIS IS A VERY LONG TEXT STRING...

Hey, did you not notice the columns were numbered? So all you had to do
to determine the length of the string was subtract column numbers?

Aside the fact that you needed to know the length _before_ you punched
the rest of the "very long text string" on the card? Or are you
suggesting that coding forms (which were used for third party punching)
were a prerequisite for punching program cards?

Of course people used coding forms.

Do you insist on not reading what we write?

I hadn't even heard of coding forms until now, almost 47 years later.
Yes, they would have made sense back then but what I had was notebooks
with a raster (5mm step?) background.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro wrote:

On Mon, 3 Jun 2024 10:33:32 +0200, Terje Mathisen wrote:

Lawrence D'Oliveiro wrote:

On Thu, 30 May 2024 10:15:54 +0200, Terje Mathisen wrote:

This was using hand-punched cards, writing FORTRAN 2 code with the
Hollerith text constants so you had to count very carefully:

FORMAT 27HTHIS IS A VERY LONG TEXT STRING...

Hey, did you not notice the columns were numbered? So all you had to do
to determine the length of the string was subtract column numbers?

Hey, did you not read what I wrote about this being hand-punched cards?
By the time I got to the end of the string it was too late to go back
and update the 27H count.

Card-punch machines had an option for that too, didn’t they? Certainly the
IBM 129 that I used could do that: copy the card to a new card, up to but
not including the incorrect part, then enter the correction, then copy the rest of the card.

I did use that mechanism to fix smaller programming mistakes, but for
the basic Hollerith counting I pretty much had to get it right the first
time, otherwise I had a 4-hour latency before getting the printout back
so it could tell me I had a counting error.

Terje


--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Terje Mathisen <[email protected]> writes:

Lawrence D'Oliveiro wrote:

On Mon, 03 Jun 2024 14:11:46 GMT, Scott Lurndal wrote:

Lawrence D'Oliveiro <[email protected]d> writes:

On Thu, 30 May 2024 10:15:54 +0200, Terje Mathisen wrote:

This was using hand-punched cards, writing FORTRAN 2 code with the
Hollerith text constants so you had to count very carefully:

FORMAT 27HTHIS IS A VERY LONG TEXT STRING...

Hey, did you not notice the columns were numbered? So all you had to do >>>> to determine the length of the string was subtract column numbers?

Aside the fact that you needed to know the length _before_ you punched
the rest of the "very long text string" on the card? Or are you
suggesting that coding forms (which were used for third party punching)
were a prerequisite for punching program cards?

Of course people used coding forms.

Do you insist on not reading what we write?

It seems not.

I hadn't even heard of coding forms until now, almost 47 years later.
Yes, they would have made sense back then but what I had was notebooks
with a raster (5mm step?) background.

Right, I just used scratch paper - coding forms were expensive
luxuries.

Then there was TSO, CANDE, TOPS and WYLBER where one would create the
card images on a green screen (no column markings) interactively.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 4 Jun 2024 11:19:38 +0200, Terje Mathisen wrote:

Lawrence D'Oliveiro wrote:

On Mon, 03 Jun 2024 14:11:46 GMT, Scott Lurndal wrote:

Lawrence D'Oliveiro <[email protected]d> writes:

On Thu, 30 May 2024 10:15:54 +0200, Terje Mathisen wrote:

Aside the fact that you needed to know the length _before_ you punched
the rest of the "very long text string" on the card? Or are you
suggesting that coding forms (which were used for third party
punching)
were a prerequisite for punching program cards?

Of course people used coding forms.

Do you insist on not reading what we write?

I hadn't even heard of coding forms until now, almost 47 years later.

Obviously it was your fault for creating extra work for yourself all those years ago, if you hadn’t even heard of coding forms until now, much too
late.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)