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


Groups > comp.lang.forth > #21522

Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!)

Newsgroups comp.lang.forth
Date 2013-04-08 14:34 -0700
References (4 earlier) <5148759d.489569357@news.demon.co.uk> <kic08e$v5o$1@speranza.aioe.org> <-aqdnSSujs6nF9TMnZ2dnUVZ_qadnZ2d@supernews.com> <kjnd0t$iqk$1@dont-email.me> <2013Apr8.181155@mips.complang.tuwien.ac.at>
Message-ID <34654bdf-ae53-43e7-98b5-6d64178e88fc@googlegroups.com> (permalink)
Subject Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!)
From AKE <assadebrahim2000@gmail.com>

Show all headers | View raw


On Monday, April 8, 2013 5:11:55 PM UTC+1, Anton Ertl wrote:
> 
> General-purpose register machines have won (for the bigger CPUs), not
> because they are a better fit for the languages, but because they
> execute these languages fast when supported by a compiler with decent
> register allocation.
> 

It would seem this support's Knuth's choice of general-purpose register machine for his MMIX 'ideal machine'.  I've wondered why Knuth's algorithmic work did not assume a simpler, stack machine.  Perhaps this is why?  

(Of course, by his own admission he wanted to work with a model that was similar to the general direction of processor architectures, but that's a bit chicken-and-egg: he chose the register machine direction because it is the most prevalent, but it is the most prevalent presumably because it executes languages fastest when supported by a reasonably constructed optimising compiler.)

Back to comp.lang.forth | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 16:45 -0400
  Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-06 03:00 -0500
  Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-08 16:11 +0000
    Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-08 15:43 -0500
      Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:49 -0400
        Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-09 04:02 -0500
      Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-09 07:03 +0000
        Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-09 04:04 -0500
    Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) AKE <assadebrahim2000@gmail.com> - 2013-04-08 14:34 -0700
      Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-09 00:02 +0200
      Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-09 07:06 +0000

csiph-web