Re: Continuations

Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Wed, 17 Jul 2024 17:09:44 +0000, Scott Lurndal wrote:
 

"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:

MitchAlsup1 wrote:
 

 
Especially the COBOL stuff like EDIT and EDIT-and-MARK.

 
 
Regarding EDIT, etc., I think there are three possibilities:
 
1. They were a bad idea from the start and never should have
been put into S/360.
 
2. Putting them into S/360 was the right decision at the time,
but the changing technology (i.e. they wouldn't fit into the
initial CISC microprocessors and RISC showed the functionality
could be done other ways) made putting them into newer designs
a bad idea.
 
3. Putting them into S/360 was the right decision at the time
but the workloads changed. There was less requirement for
things like actually printing checks and general ledger
reports, and programmers moved away from COBOL, which was where
EDIT was a natural fit, to languages where there wasn't as
natural fit, so not putting EDIT into newer CPUs was the right
decision.
 
I suspect it was mostly number 3, but I think number 2 was a
part of it.

 
I also suspect it was (3).  Burroughs medium systems (B3500 etc)

used >> the edit instruction (EDT) extensively for COBOL.

 
I suspect that as compute power grew, the kinds of things we wanted
out of EDIT changed.
 
negative numbers printed in red
negative numbers surrounded with parens (-123.45)
decimal point and comma LOCAL selection
NaN
INFINITY

 
EDIT/EDT instructions were designed from the start for
COBOL fixed point arithmetic.   No Nan, No Infinities.
 
COBOL had verbs to assign the correct characters as
the decimal point and thousands separator (on the
Burroughs B3500 those characters were stored in reserved
low memory which was accessed the EDT instruction when
processing the edit rule(s)).
 
Printing in various colors or print trains were not the
responsibility of the COBOL program, but rather the operator
who mounted the print chain/train and/or ribbon for
the print job.
 
For certain applications, an edt instruction would still
be useful, but probably wouldn't be significantly more
time efficient than a set of risc-ish instructions (it
would likely be more space efficient).
 
The problem is that the modern languages don't have
a modern concept of a PICture clause.   An instruction
to format based on a printf-like format string could
be useful, I suspect, but the die area is probably more
useful as cache.

There are two separate issues here.  One is whether modern languages
should have syntax for esily formatting numbers that is "more
expressive" than what things like printf currently provide.  The other
question is about whether such should be implemented in hardware.

As I have expressed before here, I believe the answer to the first part
is "yes", but not as feature rich as a full picture clause.  I tend to
agree with you about the second.




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