Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: Continuations
Date: Wed, 17 Jul 2024 21:14:43 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <v79c83$20v3c$1@dont-email.me>
References: <v6tbki$3g9rg$1@dont-email.me> <47689j5gbdg2runh3t7oq2thodmfkalno6@4ax.com> <v71vqu$gomv$9@dont-email.me> <116d9j5651mtjmq4bkjaheuf0pgpu6p0m8@4ax.com> <f8c6c5b5863ecfc1ad45bb415f0d2b49@www.novabbs.org> <v78s81$1tuta$1@dont-email.me> <sVSlO.45037$BYv6.44005@fx09.iad> <cb26ff16276239b273de1a6b4d306326@www.novabbs.org> <EgUlO.60668$xL%b.20040@fx17.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 17 Jul 2024 23:14:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d02dd0d7b737f1e0e4f7b53102fc2b6f";
	logging-data="2129004"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19vrLAl/yShWU1WdliKiLMe2QqAKUBVIx8="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:Am+EYKxa2vRve702jPusWrWlJy8=
Bytes: 4634

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)