Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #21525
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| 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-09 00:02 +0200 |
| Organization | 1&1 Internet AG |
| Message-ID | <kjveoq$2kd$1@online.de> (permalink) |
| References | (5 earlier) <kic08e$v5o$1@speranza.aioe.org> <-aqdnSSujs6nF9TMnZ2dnUVZ_qadnZ2d@supernews.com> <kjnd0t$iqk$1@dont-email.me> <2013Apr8.181155@mips.complang.tuwien.ac.at> <34654bdf-ae53-43e7-98b5-6d64178e88fc@googlegroups.com> |
AKE wrote: > 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? IMHO, the register machines won, because you can implement Tomasulo's instruction scheduling algorithm with registers, but it doesn't make that much sense to do it with stack machines (you can, it is just more complicated - and more complicated means that you'll lose the race). Example: The T800 transputer, a simple stack machine with the workspace pointer as helper for C-like languages, was pretty impressive back when it was introduced. But trying to improve the instruction level parallelism resulted in a monster, the T9000. In essence, the T9000 was the "ultra- CISC" processor, combining many simple T800 operations into long and powerful instructions, which were hard to decode... There were other approaches at improving ILP, like SIMD and VLIW, but compiler support for them never got out of some particular niches. It's also interesting that AMD dropped SIMD+VLIW on their most recent GPU architecture, even though GPUs had algorithms that were easy to compile for SIMD+VLIW. But apparently, it's even better to just split the workload on many, many simple cores. Still a register architecture, though. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
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