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


Groups > comp.lang.forth > #21515

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

From anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups comp.lang.forth
Subject Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!)
Date 2013-04-08 16:11 +0000
Organization Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID <2013Apr8.181155@mips.complang.tuwien.ac.at> (permalink)
References (3 earlier) <ki967o$kc7$1@speranza.aioe.org> <5148759d.489569357@news.demon.co.uk> <kic08e$v5o$1@speranza.aioe.org> <-aqdnSSujs6nF9TMnZ2dnUVZ_qadnZ2d@supernews.com> <kjnd0t$iqk$1@dont-email.me>

Show all headers | View raw


rickman <gnuarm@gmail.com> writes:
>On 3/20/2013 6:06 AM, Andrew Haley wrote:
>> I don't think that C is a good fit.  If you look at the ideal C
>> processor it's not going to look like a typical register machine.
>> You'd have something more like the Hobbit.  C works well on modern
>> processors because of heroic efforts by compiler writers.
>
>I have not looked at the Hobbit, but I have seen the ZPU.  It is an HDL 
>design for a processor intended to be used on FPGAs.  It was 
>specifically designed to run C code and yet, it is a stack machine.  Go 
>figure...

And the JVM is a stack machine with locals.  And the Lilith
(Modula-2); and P-Code (Pascal).  And the B5000 and B6500 (Algol).
These are all stack machines (with locals support), because it's easy
to generate code for such an architecture.

Is it ideal?  Andrew Haley thinks so, but people preferring fast
machines don't.  The CDC 6600 (designed for maximum speed and running
Fortran programs) ran Algol 60 about 5 times faster than the B5500
(designed for Algol)
(http://archive.computerhistory.org/resources/text/algol/algol_bulletin/EX/nac42.pdf
page 55 reports 5910-8790 Statements/s for the B5500 and 32400-43000
Statements/s for the CDC6600).

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.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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