Sujet : Re: Continuations
De : SFuld (at) *nospam* alumni.cmu.edu.invalid (Stephen Fuld)
Groupes : comp.archDate : 17. Jul 2024, 17:41:37
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v78s81$1tuta$1@dont-email.me>
References : 1 2 3 4 5
User-Agent : XanaNews/1.21-f3fb89f (x86; Portable ISpell)
MitchAlsup1 wrote:
On Tue, 16 Jul 2024 16:00:59 +0000, John Savard wrote:
On Mon, 15 Jul 2024 01:59:58 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:
It only has to be Turing-equivalent (or Lisp-equivalent) to be a
general-
purpose machine. Theres nothing in that criterion that requires
gotos.
It's true that Turing-equivalence is sufficient to allow a computer
with sufficient storage available to do anything.
But we also want that stuff to be fast (under some metric).
However, the term "general-purpose" can have other meanings. The
sense in which I was using it was: a machine that is efficient at
running programs written in all popular programming languages for
the kinds of applications for which computers are normally used.
Thus, the IBM System/360 was general-purpose since it had string
manipulation instructions and decimal arithmetic in addition to
floating-point and binary integer arithmetic.
I think that history shows that those string facilities were, at best,
overkill. None of the RISC machines had any of that and were faster
and at least as general purpose as 360.
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.
-- - Stephen Fuld (e-mail address disguised to prevent spam)