Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #21515
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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