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

Groups > alt.folklore.computers > #154787 > unrolled thread

disARMed

Back to article view | Back to alt.folklore.computers

Contents

  disARMed "gareth" <no.spam@thank.you.invalid> - 2015-12-04 11:13 +0000
    Re: disARMed Bob Eager <news0005@eager.cx> - 2015-12-04 11:52 +0000
    Re: disARMed Ahem A Rivet's Shot <steveo@eircom.net> - 2015-12-04 12:11 +0000
    Re: disARMed scott@slp53.sl.home (Scott Lurndal) - 2015-12-04 14:07 +0000
    Re: disARMed Morten Reistad <first@last.name.invalid> - 2015-12-04 13:30 +0100
      Re: disARMed cb@elaine.df.lth.se (Christian Brunschen) - 2015-12-05 16:35 +0000
    Re: disARMed Andrew Swallow <am.swallow@btinternet.com> - 2015-12-04 17:03 +0000
    Re: disARMed Jon Elson <jmelson@wustl.edu> - 2015-12-04 14:00 -0600
      Re: disARMed "gareth" <no.spam@thank.you.invalid> - 2015-12-05 20:12 +0000
        Re: disARMed Jon Elson <jmelson@wustl.edu> - 2015-12-07 16:54 -0600
      Re: disARMed Stephen Sprunk <stephen@sprunk.org> - 2015-12-06 13:35 -0600
        Re: disARMed timcaffrey420@gmail.com - 2015-12-06 17:28 -0800
    Re: disARMed Howard S Shubs <howard@shubs.net> - 2015-12-05 10:53 +0000
      Re: disARMed "gareth" <no.spam@thank.you.invalid> - 2015-12-05 12:07 +0000
        Re: disARMed Howard S Shubs <howard@shubs.net> - 2015-12-07 06:17 +0000
          Re: disARMed "gareth" <no.spam@thank.you.invalid> - 2015-12-07 10:35 +0000
            Re: disARMed Andy Burns <usenet.feb2014@adslpipe.co.uk> - 2015-12-07 12:22 +0000
              Re: disARMed "gareth" <no.spam@thank.you.invalid> - 2015-12-07 12:32 +0000
                Re: disARMed Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-12-07 18:22 +0000
                  Re: disARMed "gareth" <no.spam@thank.you.invalid> - 2015-12-07 18:30 +0000
      Re: disARMed Peter Flass <peter_flass@yahoo.com> - 2015-12-05 08:11 -0500
        Re: disARMed Ahem A Rivet's Shot <steveo@eircom.net> - 2015-12-05 14:21 +0000
          Re: disARMed Jon Elson <elson@pico-systems.com> - 2015-12-05 13:38 -0600
            Re: disARMed Michael Black <et472@ncf.ca> - 2015-12-05 16:45 -0500
              Re: disARMed "gareth" <no.spam@thank.you.invalid> - 2015-12-05 23:38 +0000
            Re: disARMed Ahem A Rivet's Shot <steveo@eircom.net> - 2015-12-05 21:49 +0000
            Re: disARMed Stan Barr <plan.b@bluesomatic.org> - 2015-12-06 08:01 +0000
              Re: disARMed hda <agent700@ay.invalid> - 2015-12-06 12:16 +0100
                Re: disARMed Stan Barr <plan.b@bluesomatic.org> - 2015-12-06 16:13 +0000
                  Re: disARMed Morten Reistad <first@last.name.invalid> - 2015-12-06 20:51 +0100
            Re: disARMed scott@slp53.sl.home (Scott Lurndal) - 2015-12-07 14:52 +0000
            Re: disARMed Walter Banks <walter@bytecraft.com> - 2015-12-07 14:33 -0500
              Re: disARMed jmfbahciv <See.above@aol.com> - 2015-12-08 13:58 +0000
          Re: disARMed scott@slp53.sl.home (Scott Lurndal) - 2015-12-07 14:49 +0000
        Re: disARMed David Wade <dave.g4ugm@gmail.com> - 2015-12-05 15:14 +0000
          Re: disARMed Anne & Lynn Wheeler <lynn@garlic.com> - 2015-12-05 08:42 -0800
            Re: disARMed Quadibloc <jsavard@ecn.ab.ca> - 2015-12-05 17:20 -0800
        Re: disARMed Jon Elson <elson@pico-systems.com> - 2015-12-05 13:35 -0600
          Re: disARMed Quadibloc <jsavard@ecn.ab.ca> - 2015-12-06 03:09 -0800
          Re: disARMed Morten Reistad <first@last.name.invalid> - 2015-12-06 12:16 +0100
            Re: disARMed "gareth" <no.spam@thank.you.invalid> - 2015-12-06 13:09 +0000
        Re: disARMed scott@slp53.sl.home (Scott Lurndal) - 2015-12-07 14:47 +0000
          Re: disARMed "Osmium" <r124c4u102@comcast.net> - 2015-12-07 13:38 -0600
            Re: disARMed Jon Elson <jmelson@wustl.edu> - 2015-12-07 16:37 -0600
              Re: disARMed Stan Barr <plan.b@bluesomatic.org> - 2015-12-08 08:00 +0000
              Re: disARMed "Osmium" <r124c4u102@comcast.net> - 2015-12-08 07:33 -0600
            Re: disARMed scott@slp53.sl.home (Scott Lurndal) - 2015-12-08 14:23 +0000
            Re: disARMed Peter Flass <peter_flass@yahoo.com> - 2015-12-08 11:55 -0500
              Re: disARMed Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-12-08 20:21 +0000
              Re: disARMed "Charles Richmond" <numerist@aquaporin4.com> - 2015-12-08 16:48 -0600

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

#154825

"Morten Reistad" <first@last.name.invalid> wrote in message 
news:31idjc-rg1.ln1@sambook.reistad.name...
>
> I have done a lot of x86 vs arm7 comparisons the last 2 years. I work a 
> lot
> designing process control stuff (rather mundane telemetry and control, but
> it pays the bills) and I have been using arm almost exclusively.

Interesting because my formative years that brought me here to Chippenham
were doing SCADA using PDP11 assembler, and a little of RTL/2 in the
final year.

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

#154838

Peter Flass <peter_flass@yahoo.com> writes:
>Howard S Shubs <howard@shubs.net> wrote:
>> On 2015-12-04, gareth <no.spam@thank.you.invalid> wrote:
>>> Having now studied the ARM insruction set, I admit to some disappointment
>>> because arithmetic and logical operations are only possible between 
>>> registers,
>>> unlike previous CPUs such as the PDP11 and 80X86 series, which inevitably
>>> will mean an INCREASE in code size because of the need to load registers
>>> first and then unload them after, unless I have missed something because
>> 
>> To put it simply, in terms of importance,
>> 
>> RISC: size < speed
>> CISC: size > speed
>> 
>> More instructions which run faster lead to better performance even
>> though you have to do more.  
>
>Given the Mount of silicon available today, shouldn't it be possible to an
>engine to execute CISC instructions as fast as the equivalent amount of
>work in RISC instructions?  Since this would be done once and could
>presumably be well tuned, it might turn out better performance than an
>average programmer and/or compiler on a RISC system.

RISC instructions are designed such that they may be executed in
a single clock cycle (absent load latencies, which range in the
3-6 cycle range from level one cache memory).

Many CISC instructions require unbounded execution time (e.g.
the VAX MOVC5 instruction, or the Burroughs medium systems MVS
(move string) instruction).   These instructions can lead to
interrupt latency issues if they're not designed to be restarted.

scott

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

#154846

"Scott Lurndal" wrote:

> RISC instructions are designed such that they may be executed in
> a single clock cycle (absent load latencies, which range in the
> 3-6 cycle range from level one cache memory).

Well, *that* got my attention.  There go multiply, divide and floating 
point.  But looking at the web a bit, ISTM that both IBM and HP (and, I 
suppose, others) did a Clinton on this - redefining words to suit their 
purpose.. I suppose if I had the patience I would find these are called 
"co-processors" or this is "RISC Mark-II" or some such weaseling.  I think I 
will just tentatively reach the conclusion, for my purposes, that RISC is no 
longer a definitive collection of letters. In any serious discussion one 
must ask "Which RISC are *you* talking about". 

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

#154851

Osmium wrote:

> "Scott Lurndal" wrote:
> 
> I think
> I will just tentatively reach the conclusion, for my purposes, that RISC
> is no longer a definitive collection of letters. In any serious discussion
> one must ask "Which RISC are *you* talking about".
This has been true from the beginning.  There have been MANY RISC 
implementations that took very different schemes to implement what they were 
doing.  There have been some general concepts that most of them followed, 
but plenty of innovation, too.  I'm not sure this is at all settled, even 
today.  ARM has sure spread a wide net over the whole arena, but there are 
still a number of other impementations working on their own versions.

Jon

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

#154859

On Mon, 07 Dec 2015 16:37:16 -0600, Jon Elson <jmelson@wustl.edu> wrote:
> Osmium wrote:
>
>> "Scott Lurndal" wrote:
>> 
>> I think
>> I will just tentatively reach the conclusion, for my purposes, that RISC
>> is no longer a definitive collection of letters. In any serious discussion
>> one must ask "Which RISC are *you* talking about".
> This has been true from the beginning.  There have been MANY RISC 
> implementations that took very different schemes to implement what they were 
> doing.  There have been some general concepts that most of them followed, 
> but plenty of innovation, too.  I'm not sure this is at all settled, even 
> today.  ARM has sure spread a wide net over the whole arena, but there are 
> still a number of other impementations working on their own versions.

MIPS is still around...Imagination Technologies, who do MIPS stuff, are
based in Kings Langley, not far from ARM in Cambridge.  This whole
thing seems to be becoming an English preserve :-)

-- 
Stan Barr     plan.b@bluesomatic.org

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

#154862

"Jon Elson" wrote:


> Osmium wrote:

>> I think
>> I will just tentatively reach the conclusion, for my purposes, that RISC
>> is no longer a definitive collection of letters. In any serious 
>> discussion
>> one must ask "Which RISC are *you* talking about".

> This has been true from the beginning.  There have been MANY RISC
> implementations that took very different schemes to implement what they 
> were
> doing.  There have been some general concepts that most of them followed,
> but plenty of innovation, too.  I'm not sure this is at all settled, even
> today.  ARM has sure spread a wide net over the whole arena, but there are
> still a number of other impementations working on their own versions.

What little reading I did on the subject made me think it was a cute name 
for "microcode for the masses". 

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

#154864

"Osmium" <r124c4u102@comcast.net> writes:
>"Scott Lurndal" wrote:
>
>> RISC instructions are designed such that they may be executed in
>> a single clock cycle (absent load latencies, which range in the
>> 3-6 cycle range from level one cache memory).
>
>Well, *that* got my attention.  There go multiply, divide and floating

scalar Multiply and fused multiply-and-add can be done in 4 cycles.
Signed/Unsigned scalar divide is maximum 14 cycles (less for smaller dividend/divisors).

Floating operations are 2 to 6 cycles, depending on operation.  Floating
divides (64-bit) can take 22 cycles.  FSQRT(32/64) is 17/31 cycles.

None of this makes them less "RISC", although to be fair, some of the
original RISC processors had off-chip FPU's (a la 80387) and MMU's (88200).

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

#154867

Osmium <r124c4u102@comcast.net> wrote:
> "Scott Lurndal" wrote:
> 
>> RISC instructions are designed such that they may be executed in
>> a single clock cycle (absent load latencies, which range in the
>> 3-6 cycle range from level one cache memory).
> 
> Well, *that* got my attention.  There go multiply, divide and floating 
> point.  But looking at the web a bit, ISTM that both IBM and HP (and, I 
> suppose, others) did a Clinton on this - redefining words to suit their 
> purpose.. I suppose if I had the patience I would find these are called 
> "co-processors" or this is "RISC Mark-II" or some such weaseling.  I think I 
> will just tentatively reach the conclusion, for my purposes, that RISC is no 
> longer a definitive collection of letters. In any serious discussion one 
> must ask "Which RISC are *you* talking about". 
> 
> 

Wasn't it one of the early Sun boxes that used two instructions to do
division?  That's carrying the idea of RISC a bit too far.

-- 
Pete

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

#154876

On 2015-12-08, Peter Flass <peter_flass@yahoo.com> wrote:

> Wasn't it one of the early Sun boxes that used two instructions to do
> division?  That's carrying the idea of RISC a bit too far.

Maybe they wanted to be compatible with RPG, which required a
second operation to fetch the remainder.  :-)

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

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

#154881

"Peter Flass" <peter_flass@yahoo.com> wrote in message 
news:99861372.471285495.469641.peter_flass-yahoo.com@news.eternal-september.org...
> Osmium <r124c4u102@comcast.net> wrote:
>> "Scott Lurndal" wrote:
>>
>>> RISC instructions are designed such that they may be executed in
>>> a single clock cycle (absent load latencies, which range in the
>>> 3-6 cycle range from level one cache memory).
>>
>> Well, *that* got my attention.  There go multiply, divide and floating
>> point.  But looking at the web a bit, ISTM that both IBM and HP (and, I
>> suppose, others) did a Clinton on this - redefining words to suit their
>> purpose.. I suppose if I had the patience I would find these are called
>> "co-processors" or this is "RISC Mark-II" or some such weaseling.  I 
>> think I
>> will just tentatively reach the conclusion, for my purposes, that RISC is 
>> no
>> longer a definitive collection of letters. In any serious discussion one
>> must ask "Which RISC are *you* talking about".
>>
>>
>
> Wasn't it one of the early Sun boxes that used two instructions to do
> division?  That's carrying the idea of RISC a bit too far.
>

ISTM that the Cray I supercomputer had *no* divide instruction.  It divided 
by doing a reciprocal instruction and then a multiply instrution.  Perhaps 
this is the kind of thing you are referring to.

-- 

numerist at aquaporin4 dot com

[toc] | [prev] | [standalone]

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

Back to top | Article view | alt.folklore.computers

csiph-web