Sujet : Re: Continuations
De : mitchalsup (at) *nospam* aol.com (MitchAlsup1)
Groupes : comp.archDate : 17. Jul 2024, 17:17:22
Autres entêtes
Organisation : Rocksolid Light
Message-ID : <0f7b4deb1761f4c485d1dc3b21eb7cb3@www.novabbs.org>
References : 1 2 3 4 5 6
User-Agent : Rocksolid Light
On Wed, 17 Jul 2024 1:41:12 +0000, John Savard wrote:
On Tue, 16 Jul 2024 20:51:17 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:
>
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.
>
I will agree with that; the 68000 and the x86 don't have those things
either.
>
Even if my personal inclination has been to include them too.
>
On the other hand, I am advocating that some Elementary Functions be
raised to first class citizens of ISA so that SIM() is 20 cycles instead
of 150 cycles. Why, because today, we understand enough about the cal-
culations, polynomials, error sources, to build in HW things that are
just as accurate as SW can build and nearly 7×-10× faster.
>
I thought this was already the case; the 8087 had transcendental
functions, and so did the 486 DX and from that onwards, and this was
also the case with the 68881 and 68882.
>
Of course, even if they're citizens of the ISA, they could be
second-class citizens, whatever the definition of that might be.
While they were "in" the ISAs, they would take thousands of cycles
while FP would only take hundreds of cycles.
What I am talking about is to improve their performance until a
sin() takes about the same number of cycles of FDIV, not 10× more.
>
Here, my personal inclination is to simply include the raw CORDIC
calculation as an instruction, with bounds checking, special cases,
and any fancy stuff in software. On the grounds that some things are
too complicated for a classic old-style ISA.
This is a tradeoff in size versus cycles. I choose to stop when
sin() was as fast as FDIV.
>
That, too, is of course a bad decision from a practical perspective.
Imagine a situation where::
s = sin(x);
c = cos(x);
is faster and more accurate than:
s = sin(x);
c = sqrt(1-s^2);
!!!
{{ignoring the fact that cos() can be negative where sqrt() cannot.}}
>
John Savard