Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #1642 > unrolled thread

Re: Why is complex lea slow?

Back to article view | Back to comp.arch

Contents

  Re: Why is complex lea slow? "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-05-17 12:58 -0700
    Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-18 09:40 +0200
      Re: Why is complex lea slow? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-18 06:25 -0700
        Re: Why is complex lea slow? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-18 06:39 -0700
        Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-18 20:49 +0200
        Re: Why is complex lea slow? Andrew Reilly <areilly---@bigpond.net.au> - 2011-05-19 00:11 +0000
      Re: Why is complex lea slow? MitchAlsup <MitchAlsup@aol.com> - 2011-05-24 13:44 -0700
        Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-25 08:43 +0200
          Re: Why is complex lea slow? MitchAlsup <MitchAlsup@aol.com> - 2011-05-25 08:31 -0700
        Re: Why is complex lea slow? timcaffrey@aol.com (Tim McCaffrey) - 2011-05-25 14:53 +0000
          Re: Why is complex lea slow? MitchAlsup <MitchAlsup@aol.com> - 2011-05-25 08:31 -0700
            Re: Why is complex lea slow? timcaffrey@aol.com (Tim McCaffrey) - 2011-05-26 19:45 +0000
              Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-26 20:01 +0000
                Re: Why is complex lea slow? nmm1@cam.ac.uk - 2011-05-26 20:29 +0100
                  Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-26 20:14 +0000
                    Re: Why is complex lea slow? nmm1@cam.ac.uk - 2011-05-26 21:04 +0100
                      Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-26 20:55 +0000
                        Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-26 20:57 +0000
                        Re: Why is complex lea slow? nmm1@cam.ac.uk - 2011-05-26 21:30 +0100
                        Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-26 22:57 +0100
                          Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-27 07:42 +0200
                            Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-27 06:11 +0000
                              Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-27 07:18 +0100
                                Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-27 06:33 +0000
                                Re: Why is complex lea slow? Michael S <already5chosen@yahoo.com> - 2011-05-27 03:24 -0700
                                  Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-27 22:24 +0100
                                    Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-28 13:51 +0200
                                  Re: Why is complex lea slow? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-27 17:42 -0700
                                Re: Why is complex lea slow? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-27 17:40 -0700
                              Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-27 08:55 +0200
                                Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-27 07:42 +0000
                                  Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-27 09:24 +0100
                                    Re: Why is complex lea slow? nmm1@cam.ac.uk - 2011-05-27 08:55 +0100
                                      Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-27 10:20 +0100
                                    Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-27 08:53 +0000
                                      Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-27 10:23 +0100
                                        Re: Why is complex lea slow? kenney@cix.compulink.co.uk - 2011-05-27 23:47 -0500
                                    Re: Why is complex lea slow? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-27 17:44 -0700
                                      Re: Why is complex lea slow? Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-05-28 02:12 +0100
                                        Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-28 02:57 +0000
                                        Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-28 09:27 +0100
                                          Algol hardware representations, was: Why is complex lea slow? Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-05-28 15:26 +0100
                                        Re: Why is complex lea slow? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-28 08:57 -0700
                              Re: Why is complex lea slow? Chris Gray <cg@GraySage.com> - 2011-05-27 14:14 -0600
                        Re: Why is complex lea slow? timcaffrey@aol.com (Tim McCaffrey) - 2011-05-26 23:26 +0000
                      Re: Why is complex lea slow? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-26 21:41 -0600
                Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-27 07:37 +0200
                  Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-27 06:16 +0000
                  Re: Why is complex lea slow? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-27 17:52 -0700
    Re: Why is complex lea slow? Piotr Wyderski <peter.pan@neverland.mil> - 2011-05-19 17:13 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1921

Bill Findlay wrote:
> On 28/05/2011 01:44, in article
> 0b7485de-832d-4ca3-9010-1ff5b30dafbc@n10g2000yqf.googlegroups.com,
> "Quadibloc"<jsavard@ecn.ab.ca>  wrote:
>
>> On May 27, 2:24 am, Tom Gardner<spamj...@blueyonder.co.uk>  wrote:
>>
>>> With ICL Algol it was possible to use a standard keyboard/punch,
>>> and surround all keywords with single quotes. Of course, the
>>> single quotes themselves had to be escaped. I leave it as an
>>> exercise for the reader to determine whether they think such a
>>> scheme was practical.
>>
>> It's ugly and hideous, but IBM's ALGOL 60 compiler did much the same
>> thing. They may have used double quotes instead of escaped single
>> quotes, however, for quoting strings.
>>
>> If you mean they had to use escaped single quotes to indicate
>> keywords, though, yes, this was not practical. They should have
>> thought a bit more about how to implement a scheme more convenient to
>> the user.
>
> Of course, they did not do anything so silly as the latter.
> Here is a routine from the Whetstone Benchmark in the hardware
> representation of ICL 1900 Series Algol:
>
>     'PROCEDURE' POUT(N, J , K, X1, X2, X3, X4);
>        'VALUE' N, J , K, X1, X2, X3, X4;
>        'INTEGER' N, J, K;
>        'REAL' X1, X2, X3, X4;
>     'BEGIN'
>        WRITETEXT('('N=')');         WRITE(1, FORMAT('('NNND')'), N);
>        WRITETEXT('(''('S')'J=')');  WRITE(1, FORMAT('('NNND')'), J);
>        WRITETEXT('(''('S')'K=')');  WRITE(1, FORMAT('('NNND')'), K);
>        WRITETEXT('(''('S')'X1=')'); WRITE(1, FORMAT('('+D.DDDDDDDD')'), X1);
>        WRITETEXT('(''('S')'X2=')'); WRITE(1, FORMAT('('+D.DDDDDDDD')'), X2);
>        WRITETEXT('(''('S')'X3=')'); WRITE(1, FORMAT('('+D.DDDDDDDD')'), X3);
>        WRITETEXT('(''('S')'X4=')'); WRITE(1, FORMAT('('+D.DDDDDDDD')'), X4);
>        WRITETEXT('(''('C')'')');
>     'END' POUT;
>
> The Algol opening and closing string quote symbols are '(' and ')' --
> different, so they can be nested, as here. {The use of a nested string to
> represent a format effector: '('S')'  = space, '('C')' = newline; was
> inherited from the KDF9 Algol compilers.}
>
> "Stropping" basic symbol words like this was a pain in the neck; KDF9's
> usage of a non-escaping underline -- so that one typed, e.g., "_b_e_g_i_n"
> to get the basic symbol underlined -- was even more so.  Wirth wisely used
> reserved basic symbol words in Algol W and this style has been continued in
> its many successors, such as Pascal, Modula-n, Ada, and so on.

Since I decided to avoid writing ICL2900 Algol, I'm sure your
description is more correct than mine. I still think my choice
was correct :)

[toc] | [prev] | [next] | [standalone]

#1929 — Algol hardware representations, was: Why is complex lea slow?

On 28/05/2011 09:27, in article gm2Ep.16732$h_.9274@newsfe30.ams2, "Tom
Gardner" <spamjunk@blueyonder.co.uk> wrote:

> Bill Findlay wrote:
...
>> "Stropping" basic symbol words like this was a pain in the neck; KDF9's
>> usage of a non-escaping underline -- so that one typed, e.g., "_b_e_g_i_n"
>> to get the basic symbol underlined -- was even more so.  Wirth wisely used
>> reserved basic symbol words in Algol W and this style has been continued in
>> its many successors, such as Pascal, Modula-n, Ada, and so on.
> 
> Since I decided to avoid writing ICL2900 Algol, I'm sure your
> description is more correct than mine. I still think my choice
> was correct :)

By the time the 2900 Series came out Algol 60 was entirely obsolete, so your
judgement was impeccable. 8-)

BTW This walk down memory lane is very off-topic for comp.arch, so I've
cross-posted to alt.folklore.computers and suggest the discussion continues
there (only).

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

[toc] | [prev] | [next] | [standalone]

#1930

On May 27, 7:12 pm, Bill Findlay <yaldni...@blueyonder.co.uk> wrote:

> The Algol opening and closing string quote symbols are '(' and ')' --

I have now checked, and the little-used ALGOL compiler for the IBM 360
did exactly the same thing.

John Savard

[toc] | [prev] | [next] | [standalone]

#1902

kym@kymhorsell.com writes:

> I think it was more the shift-in/out idea to get the 36 codes
> out of 5 bits Tom was talking about.

Due to the local phone company getting rid of them, I ended up getting a
pair of Baudot TTYs many years ago. I miss the darn solidness of them,
even if it was a bit resource-heavy. You did not want your fingers in
the way when the carriage was shifting down to the letters position. Nor
in the way of the paper tape punch - very powerful solenoid!

I actually used one of them with my home-brew computer (8080-based). The
GI AY5-1015 (???) UART happily handled 5-bit characters. Due to the very
low bit rate required for the massive machinery, a simple echo by a
running program had a very noticeable delay.

The decoding mechanism on them was simply wonderful.

-Chris Gray

[toc] | [prev] | [next] | [standalone]

#1871

In article <4ddebe5b$0$13392$afc38c87@news.optusnet.com.au>, 
kym@kymhorsell.com says...
>

>
>48-bit words, 6-bit company-specific character set, 39 bits of integer 
>precision, assynetric reals from 8.75@-47 to 4.3@68, the B5500 was like 
>an alien world cf today.
>
Well, it now uses 8 bit characters, and you can use ASCII or EBCDIC (although 
most stuff uses EBCDIC internally).

BTW, integer adds & subtracts were 60 bit on the CDC machines, but 
multiply/divide used the floating point hardware, and were limited to the 
maximum "integer" they could handle (48 bits?).  But float add/subtract were 
definitely different instructions than integer add/subtract, which is not true 
on the Unisys MCP machines.

		-Tim

[toc] | [prev] | [next] | [standalone]

#1877

nmm1@cam.ac.uk writes:

> In article <4ddeb4ad$0$29364$afc38c87@news.optusnet.com.au>,
>  <kym@kymhorsell.com> wrote:
>>>>...
>>>>> Originally Burroughs Large System, then Burroughs (then Unisys) A-series.
>>>>> All descendents of the B6700 (derived from the B5000).
>>>>> With a stack architecture you don't have to worry about number of fields for 
>>>>> addressing. :)
>>>>...
>>>>Had a lot of peculiarities. Integer numbers just reals with 0 exponent.
>>>>Seems to have been needed for Algol's idea that i**j is integer if
>>>>j>=0 but real if j<0.
>>> Not at all.  Making integers simply floating-point with a fixed
>>> exponent was pretty common, not just on Burroughs.
>>
>>I worked in 5500's and 6700s in the 60s and 70s. I don't recall any other 
>>machine available to me at the time (CDC 3600, HP2000, PDP11) that 
>>"sacrified" 8 bits or more of integer range to handle compatibility with reals.
>
> If I recall, the CDC 6600 and 7600 did.  I can't recall the others.

As I heard the story, this was a happy accident.
-- 
"It used to be that the USA was pretty good at producing stuff teenaged 
boys could lose a finger or two playing with."	-- James Nicoll

[toc] | [prev] | [next] | [standalone]

#1878

kym@kymhorsell.com wrote:
> Tim McCaffrey<timcaffrey@aol.com>  wrote:
> ....
>> Originally Burroughs Large System, then Burroughs (then Unisys) A-series.
>> All descendents of the B6700 (derived from the B5000).
>> With a stack architecture you don't have to worry about number of fields for
>> addressing. :)
> ....
>
> Had a lot of peculiarities. Integer numbers just reals with 0 exponent.
> Seems to have been needed for Algol's idea that i**j is integer if
> j>=0 but real if j<0.

With both i and j integer, that seems to be exactly the way it should be 
(mathematically speaking)?

It works in IEEE fp as well, as long as the final result doesn't 
overflow the size of the mantissa, i.e. 2**52 is still an exact integer 
value and can be converted  (to a 64-bit int probably) with no 
conversion error.

Terje

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

[toc] | [prev] | [next] | [standalone]

#1884

Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> kym@kymhorsell.com wrote:
>> Tim McCaffrey<timcaffrey@aol.com>  wrote:
>> ....
>>> Originally Burroughs Large System, then Burroughs (then Unisys) A-series.
>>> All descendents of the B6700 (derived from the B5000).
>>> With a stack architecture you don't have to worry about number of fields for
>>> addressing. :)
>> ....
>> Had a lot of peculiarities. Integer numbers just reals with 0 exponent.
>> Seems to have been needed for Algol's idea that i**j is integer if
>> j>=0 but real if j<0.
> 
> With both i and j integer, that seems to be exactly the way it should be 
> (mathematically speaking)?
...

Sure, but it means the type of an expression depends on runtime values.
In at least part of the same time period FORTRAN forbade mixed modes.

-- 
> Sure. It was also once normal to not have humans, mammals or even chordates
> on the planet. LOL.
Those things are gone.
-- John Smith <assemblywizard@gmail.com>, 21 Dec 2010 22:23:15 -0800

[toc] | [prev] | [next] | [standalone]

#1908

On May 26, 11:37 pm, Terje Mathisen <"terje.mathisen at tmsw.no">
wrote:

> With both i and j integer, that seems to be exactly the way it should be
> (mathematically speaking)?
>
> It works in IEEE fp as well, as long as the final result doesn't
> overflow the size of the mantissa, i.e. 2**52 is still an exact integer
> value and can be converted  (to a 64-bit int probably) with no
> conversion error.

What, exponent zero doesn't produce a number in the range [0,1),
utterly incompatible with integer because there's no reason for
compatibility?

But then, I did notice IEEE exponents were offset, although I didn't
think they were offset by the length of the exponent field, let alone
the length of the mantissa (or, as they call it, the significand).

Oh, wait. That's not exponent zero. That's exponent 100...000 that got
offset.

Exponent zero gets you *the extreme low end of the floating-point
range*. In the case of IEEE floating-point, that is the unnormalized
numbers, including zero itself.

Given the suppressed first bit of the mantissa requiring all floats to
be normalized, I should like to see an integer format with which IEEE
754 floating-point would be compatible. As long as I wasn't required
to fully understand it and answer questions about it later.

But, hey, it _is_ true that two's complement positive integers would
look like the floats corresponding to them multiplied by a constant. A
very, very small constant. So at least integer to floating-point
conversions can be simplified by this... partial... compatibility.

John Savard

[toc] | [prev] | [next] | [standalone]

#1691

Paul A. Clayton wrote:

> In the context of LEA, the shifts are always constant and
> I was under the impression that variable shifts are
> generally less common.

The lea-related problem inspired me to do more detailed
survey and it turns out that most useful instruction got
slower on SandyBridge. Not only lea, but also bsf, bsr
and even bt (!!!) have increased their latencies to
3 cycles. Since I am a heavy user of these, and they
appear mostly in performance-critical code, the current
path Intel decided to go, i.e. making useful instructions
slow and adding tons of useless but fast "extensions" like
pcmpestri or crc32 scares me.

	Best regards
	Piotr Wyderski

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.arch

csiph-web