Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #51568 > unrolled thread
| Started by | Walter Banks <walter@bytecraft.com> |
|---|---|
| First post | 2016-10-03 08:22 -0400 |
| Last post | 2016-10-17 22:05 +0000 |
| Articles | 20 on this page of 159 — 26 participants |
Back to article view | Back to comp.lang.forth
Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 08:22 -0400
Re: Stack Sizes foxaudioresearch@gmail.com - 2016-10-03 07:00 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 11:14 -0400
Re: Stack Sizes Bernd Linsel <bl1@gmx.com> - 2016-10-03 18:20 +0200
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-03 11:30 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-03 15:27 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 18:12 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-03 17:52 -0500
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-03 16:06 -0700
Re: Stack Sizes Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-10-04 08:31 +0100
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-04 08:46 +0000
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 10:38 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-04 11:59 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-05 09:59 +0000
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 10:16 -0400
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-06 08:21 +0000
Re: Stack Sizes minforth@arcor.de - 2016-10-04 05:00 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 08:49 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-03 16:28 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 10:36 -0400
Re: Stack Sizes Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-10-04 16:15 -0400
Re: Stack Sizes Brad Eckert <hwfwguy@gmail.com> - 2016-11-09 09:56 -0800
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-11-12 09:15 -0500
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-03 10:35 -0500
Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-11 01:01 +0000
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-03 10:21 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 11:06 -0400
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-03 15:22 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 18:04 -0400
Re: Stack Sizes Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-04 20:46 +0200
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 15:40 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 12:26 -0700
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 15:44 -0500
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 16:32 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 20:01 -0400
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 07:39 +0000
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 20:36 -0500
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 21:28 -0700
Re: Stack Sizes alex <alex@rivadpm.com> - 2016-10-05 22:07 +0100
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-06 00:05 -0700
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-06 02:17 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-04 19:27 -0400
Re: Stack Sizes Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-05 18:58 +0200
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 13:17 -0400
Re: Stack Sizes Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-22 12:35 +0200
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 12:18 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 16:07 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 15:50 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 17:36 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 17:14 -0500
Re: Stack Sizes "Elizabeth D. Rather" <erather@forth.com> - 2016-10-05 14:48 -1000
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 20:49 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-03 16:32 +0000
Re: Stack Sizes Chris Curl <ccurl609@gmail.com> - 2016-10-03 13:53 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 17:54 -0400
Re: Stack Sizes Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-10-03 23:40 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 11:30 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-03 21:47 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 11:22 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-04 11:44 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 15:53 -0400
Re: Stack Sizes Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-10-04 16:15 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 14:31 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-06 08:48 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-06 13:08 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-06 19:11 -0400
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-06 12:08 -0700
Re: Stack Sizes alex <alex@rivadpm.com> - 2016-10-06 21:47 +0100
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-06 19:05 -0400
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-06 21:57 -0400
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-06 19:21 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-07 00:10 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-06 23:14 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-07 02:26 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-06 23:57 -0700
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-07 08:18 -0500
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-07 10:52 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-09 16:22 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-10 01:49 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-10 10:21 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-10 22:39 -0400
Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-10 12:36 +0200
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-13 13:45 -0700
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-14 01:16 -0700
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-15 20:38 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-16 02:00 -0400
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-16 18:38 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-16 22:27 -0400
Re: Straight Forth Re: Stack Sizes Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-10-16 21:14 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 00:35 -0400
Re: Straight Forth Re: Stack Sizes Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-10-16 23:31 -0700
Re: Straight Forth Re: Stack Sizes "Elizabeth D. Rather" <erather@forth.com> - 2016-10-16 20:36 -1000
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-17 13:11 -0700
Re: Straight Forth Re: Stack Sizes Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-17 19:14 -0400
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-17 21:53 +0000
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-17 16:54 -0700
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-21 22:13 +0000
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-21 17:46 -0700
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-23 22:26 +0000
Re: Straight Forth Re: Stack Sizes JUERGEN <epldfpga@aol.com> - 2016-10-24 09:13 -0700
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-24 16:28 -0700
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-24 17:20 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-24 22:23 -0400
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-11-04 20:39 +0000
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-16 22:42 -0700
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-17 11:12 +0200
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-17 09:20 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 19:11 -0400
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-17 16:40 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 20:19 -0400
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-17 17:25 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 20:50 -0400
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-18 02:04 +0200
Re: Straight Forth Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-18 06:13 +0000
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-16 15:21 -0700
Re: Straight Forth Re: Stack Sizes Doug Hoffman <glidedog@gmail.com> - 2016-10-17 04:09 -0400
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-17 13:48 -0700
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-18 02:12 +0200
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-18 00:35 -0700
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-18 12:53 +0200
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-18 12:12 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 16:53 +0000
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-09 08:34 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-09 16:03 +0000
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-10 03:25 -0500
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-10 10:29 -0500
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-11 05:19 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-10 14:41 +0000
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-10 20:23 +0200
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-11 05:16 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-12 12:54 +0000
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-12 18:27 +0200
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-12 17:06 +0000
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-12 13:01 -0500
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-12 17:07 -0400
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-13 03:18 +0200
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-14 14:26 -0400
Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-12 20:30 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-13 15:52 +0000
Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-13 15:05 -0700
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-14 03:08 -0500
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-14 14:41 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-07 12:33 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-08 01:12 -0400
Re: Stack Sizes Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-07 23:05 -0400
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-07 21:56 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-08 07:23 -0400
Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-11 22:39 -0700
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-07 08:21 +0200
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-07 09:22 +0200
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-07 09:35 +0200
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-07 10:51 -0700
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-07 13:21 -0500
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-07 20:40 +0200
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-07 20:53 +0200
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 07:35 +0000
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-07 01:09 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 15:59 +0000
Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-17 22:05 +0000
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-03 08:22 -0400 |
| Subject | Stack Sizes |
| Message-ID | <nstii2$8pl$1@gioia.aioe.org> |
I am currently working on a stack processor ISA. What better place to ask about stacks. How many? single stack or two or three. What depth? Why? w..
[toc] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-10-03 07:00 -0700 |
| Message-ID | <5d771b3c-0099-43eb-9373-c25f0d40e843@googlegroups.com> |
| In reply to | #51568 |
On Monday, October 3, 2016 at 8:22:29 AM UTC-4, Walter Banks wrote: > I am currently working on a stack processor ISA. > > What better place to ask about stacks. > > How many? single stack or two or three. > What depth? > Why? > > > w.. In this forum you could get more questions than answers I believe. For the record the Forth VM is 2 stacks. Parameter stack and Return stack. IF you are planning to program this machine in Forth you really don't need more than that however there are people who prefer to add stacks for other purposes for example Floating point math. The fascinating thing to new people to Forth is that stack size actually tends to be less (in general) in Forth programs versus more conventional languages because the programmer is using the parameter stack more like an assembler programmer uses registers. The numerical ramification of this is that Forth hardware can get away with as few as 18 stack elements for each stack. You can study some of the current Forth style stack machines like B16 or J1 to see what others have done. Now a small stack will fail if you write recursive routines but for everyday solving problems in Forth it is manageable. So the questions: What language will you use for this machine? Will you need recursion? If if it's only for Algol style languages 1 stack and and a base pointer register for stack frames works just fine IMHO. For Forth, 2 very fast hardware stacks of modest size gets you of what you need. YMMV BF
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-03 11:14 -0400 |
| Message-ID | <nstsl8$s41$1@gioia.aioe.org> |
| In reply to | #51569 |
On 2016-10-03 10:00 AM, foxaudioresearch@gmail.com wrote: > On Monday, October 3, 2016 at 8:22:29 AM UTC-4, Walter Banks wrote: >> I am currently working on a stack processor ISA. >> >> What better place to ask about stacks. >> >> How many? single stack or two or three. What depth? Why? >> >> >> w.. > > In this forum you could get more questions than answers I believe. > > For the record the Forth VM is 2 stacks. Parameter stack and Return > stack. IF you are planning to program this machine in Forth you > really don't need more than that however there are people who prefer > to add stacks for other purposes for example Floating point math. > > The fascinating thing to new people to Forth is that stack size > actually tends to be less (in general) in Forth programs versus more > conventional languages because the programmer is using the parameter > stack more like an assembler programmer uses registers. The numerical > ramification of this is that Forth hardware can get away with as few > as 18 stack elements for each stack. > > You can study some of the current Forth style stack machines like B16 > or J1 to see what others have done. > > Now a small stack will fail if you write recursive routines but for > everyday solving problems in Forth it is manageable. > > So the questions: > > What language will you use for this machine? > > Will you need recursion? > > If if it's only for Algol style languages 1 stack and and a base > pointer register for stack frames works just fine IMHO. > > For Forth, 2 very fast hardware stacks of modest size gets you of > what you need. I have looked at what others have done but have very little information on how they made their choices. For example, does anyone have any regression tests that illustrates the issues of stacks? I guess what is modest hardware size. How big is needed to accommodate most applications given that a user or compiler makes a reasonable attempt to write good code. Most massively recursion pathological cases can generally be optimized away for example. w..
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2016-10-03 18:20 +0200 |
| Message-ID | <nsu0fs$ehj$1@newsreader4.netcologne.de> |
| In reply to | #51572 |
On 10/3/2016 5:14 PM, Walter Banks wrote: > > I have looked at what others have done but have very little information > on how they made their choices. For example, does anyone have any > regression tests that illustrates the issues of stacks? > > I guess what is modest hardware size. How big is needed to accommodate most > applications given that a user or compiler makes a reasonable attempt to > write good code. > > Most massively recursion pathological cases can generally be optimized > away for example. Perhaps you should read P. Koopman's excellent book on stack computers. It is online available at https://users.ece.cmu.edu/~koopman/stack_computers/ . Regards, Bernd
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-03 11:30 -0500 |
| Message-ID | <nsu12m$fe3$1@dont-email.me> |
| In reply to | #51576 |
On 10/3/2016 11:20 AM, Bernd Linsel wrote: > On 10/3/2016 5:14 PM, Walter Banks wrote: >> >> I have looked at what others have done but have very little information >> on how they made their choices. For example, does anyone have any >> regression tests that illustrates the issues of stacks? >> >> I guess what is modest hardware size. How big is needed to accommodate >> most >> applications given that a user or compiler makes a reasonable attempt to >> write good code. >> >> Most massively recursion pathological cases can generally be optimized >> away for example. > > Perhaps you should read P. Koopman's excellent book on stack computers. > It is online available at > https://users.ece.cmu.edu/~koopman/stack_computers/ . > > Regards, > Bernd > The ep16 and ep32 from C. H. Ting uses 32 levels for each of the stacks, more than enough without taxing the resources, I'm in the process of designing my own CPU so far it looks like I will be using 256 levels for each stacks. I want it to handle a modest level of recursion. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-03 15:27 -0400 |
| Message-ID | <nsubfd$og4$1@dont-email.me> |
| In reply to | #51577 |
On 10/3/2016 12:30 PM, Cecil Bayona wrote: > On 10/3/2016 11:20 AM, Bernd Linsel wrote: >> On 10/3/2016 5:14 PM, Walter Banks wrote: >>> >>> I have looked at what others have done but have very little information >>> on how they made their choices. For example, does anyone have any >>> regression tests that illustrates the issues of stacks? >>> >>> I guess what is modest hardware size. How big is needed to accommodate >>> most >>> applications given that a user or compiler makes a reasonable attempt to >>> write good code. >>> >>> Most massively recursion pathological cases can generally be optimized >>> away for example. >> >> Perhaps you should read P. Koopman's excellent book on stack computers. >> It is online available at >> https://users.ece.cmu.edu/~koopman/stack_computers/ . >> >> Regards, >> Bernd >> > The ep16 and ep32 from C. H. Ting uses 32 levels for each of the stacks, > more than enough without taxing the resources, I'm in the process of > designing my own CPU so far it looks like I will be using 256 levels for > each stacks. I want it to handle a modest level of recursion. I used 256 word stacks in my CPU design, but this makes the stack pointers longer than desirable and slowed the design. Actually, it was the flags on the stack addresses that were the long pole in the tent, but they had to go through the entire address carry chain and so were limited by the stack pointer length. I probably should have tossed the flags. I used 256 word stacks because they shared a single dual port block RAM with 512 words. If I go back to this design I will likely use a larger hunk of memory and do the rotation context thing to use multiple virtual machines where the stack RAM holds N smaller stacks for N virtual CPUs. RAM is cheap on FPGAs usually. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-03 18:12 -0400 |
| Message-ID | <nsul3p$cpj$1@gioia.aioe.org> |
| In reply to | #51577 |
On 2016-10-03 12:30 PM, Cecil Bayona wrote: > On 10/3/2016 11:20 AM, Bernd Linsel wrote: >> On 10/3/2016 5:14 PM, Walter Banks wrote: >>> >>> I have looked at what others have done but have very little >>> information on how they made their choices. For example, does >>> anyone have any regression tests that illustrates the issues of >>> stacks? >>> >>> I guess what is modest hardware size. How big is needed to >>> accommodate most applications given that a user or compiler makes >>> a reasonable attempt to write good code. >>> >>> Most massively recursion pathological cases can generally be >>> optimized away for example. >> >> Perhaps you should read P. Koopman's excellent book on stack >> computers. It is online available at >> https://users.ece.cmu.edu/~koopman/stack_computers/ . >> >> Regards, Bernd >> > The ep16 and ep32 from C. H. Ting uses 32 levels for each of the > stacks, more than enough without taxing the resources, I'm in the > process of designing my own CPU so far it looks like I will be using > 256 levels for each stacks. I want it to handle a modest level of > recursion. > Both are good references, I have read Koopman's book and have a some other Ting material. I will check out your Ting link in another post. One more question. Have there been single stack forth implementations. What are the issues? w..
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-03 17:52 -0500 |
| Message-ID | <nsunf3$2u3$1@dont-email.me> |
| In reply to | #51585 |
On 10/3/2016 5:12 PM, Walter Banks wrote: > On 2016-10-03 12:30 PM, Cecil Bayona wrote: >> On 10/3/2016 11:20 AM, Bernd Linsel wrote: >>> On 10/3/2016 5:14 PM, Walter Banks wrote: >>>> >>>> I have looked at what others have done but have very little >>>> information on how they made their choices. For example, does >>>> anyone have any regression tests that illustrates the issues of >>>> stacks? >>>> >>>> I guess what is modest hardware size. How big is needed to >>>> accommodate most applications given that a user or compiler makes >>>> a reasonable attempt to write good code. >>>> >>>> Most massively recursion pathological cases can generally be >>>> optimized away for example. >>> >>> Perhaps you should read P. Koopman's excellent book on stack >>> computers. It is online available at >>> https://users.ece.cmu.edu/~koopman/stack_computers/ . >>> >>> Regards, Bernd >>> >> The ep16 and ep32 from C. H. Ting uses 32 levels for each of the >> stacks, more than enough without taxing the resources, I'm in the >> process of designing my own CPU so far it looks like I will be using >> 256 levels for each stacks. I want it to handle a modest level of >> recursion. >> > > Both are good references, I have read Koopman's book and have a some > other Ting material. I will check out your Ting link in another post. > > One more question. Have there been single stack forth implementations. > What are the issues? > > w.. Others here may know of some but Forth basically needs two stacks as a minimum, in implementing Forth on CPU chips that have only one stack the other stack is simulated using a dedicated register. One stack only has some issues in that subroutine call information gets in the way of data items on the stack, that why two stacks are needed as a minimum. Early Stack computers had only one stack and that didn't work out well. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-10-03 16:06 -0700 |
| Message-ID | <87y425xcb4.fsf@nightsong.com> |
| In reply to | #51585 |
Walter Banks <walter@bytecraft.com> writes: > Both are good references, I have read Koopman's book and have a some > other Ting material. I will check out your Ting link in another post. You might also look at Eric LaForest's thesis "Second-Generation Stack Computer Architecture": http://uwaterloo.ca/independent-studies/sites/ca.independent-studies/files/uploads/files/eric_laforest_thesis.pdf
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2016-10-04 08:31 +0100 |
| Message-ID | <20161004083103.4569b5b5@HP-6550b> |
| In reply to | #51576 |
On Mon, 3 Oct 2016 18:20:21 +0200 Bernd Linsel <bl1@gmx.com> wrote: > Perhaps you should read P. Koopman's excellent book on stack > computers. It is online available at > https://users.ece.cmu.edu/~koopman/stack_computers/ . Good advice, the book is perhaps the easily only locatable reference for this type of information, and a good read. From section 6.4[1] it seemed to me that a depth of 12 items for stack caches is a sweet spot. The fill/spill rate here is mostly under 1%. So if you fetch 4 instructions per memory cycle then fill/spill memory access will peak at one per 25 instruction fetches. A return stack cache of this size has similar memory usage. Jan Coombs -- [1] 6.4 STACK MANAGEMENT ISSUES https://users.ece.cmu.edu/~koopman/stack_computers/sec6_4.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-04 08:46 +0000 |
| Message-ID | <2016Oct4.104604@mips.complang.tuwien.ac.at> |
| In reply to | #51596 |
Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes:
>On Mon, 3 Oct 2016 18:20:21 +0200
>Bernd Linsel <bl1@gmx.com> wrote:
>
>> Perhaps you should read P. Koopman's excellent book on stack
>> computers. It is online available at=20
>> https://users.ece.cmu.edu/~koopman/stack_computers/ .
>
>Good advice, the book is perhaps the easily only locatable
>reference for this type of information, and a good read.=20
Another reference is my first stack caching paper [ertl95pldi]. You
can find more data in
<http://www.complang.tuwien.ac.at/misc/stack-caching-data/>.
@InProceedings{ertl95pldi,
author = "M. Anton Ertl",
title = "Stack Caching for Interpreters",
crossref = "sigplan95",
pages = "315--327",
url = "http://www.complang.tuwien.ac.at/papers/ertl95pldi.ps.gz",
abstract = "An interpreter can spend a significant part of its
execution time on arguments of virtual machine
instructions. This paper explores two methods to
reduce this overhead for virtual stack machines by
caching top-of-stack values in (real machine)
registers. The {\em dynamic method} is based on
having, for every possible state of the cache, one
specialized version of the whole interpreter; the
execution of an instruction usually changes the
state of the cache and the next instruction is
executed in the version corresponding to the new
state. In the {\em static method} a state machine
that keeps track of the cache state is added to the
compiler. Common instructions exist in specialized
versions for several states, but it is not necessary
to have a version of every instruction for every
cache state. Stack manipulation instructions are
optimized away."
}
@Proceedings{sigplan95,
booktitle = "SIGPLAN Conference on Programming Language
Design and Implementation (PLDI'95)",
title = "SIGPLAN Conference on Programming Language
Design and Implementation (PLDI'95)",
year = "1995",
key = "PLDI '95"
}
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-04 10:38 -0400 |
| Message-ID | <nt0etv$13ec$3@gioia.aioe.org> |
| In reply to | #51597 |
On 2016-10-04 4:46 AM, Anton Ertl wrote:
> Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes:
>> On Mon, 3 Oct 2016 18:20:21 +0200
>> Bernd Linsel <bl1@gmx.com> wrote:
>>
>>> Perhaps you should read P. Koopman's excellent book on stack
>>> computers. It is online available at=20
>>> https://users.ece.cmu.edu/~koopman/stack_computers/ .
>>
>> Good advice, the book is perhaps the easily only locatable
>> reference for this type of information, and a good read.=20
>
> Another reference is my first stack caching paper [ertl95pldi]. You
> can find more data in
> <http://www.complang.tuwien.ac.at/misc/stack-caching-data/>.
>
> @InProceedings{ertl95pldi,
> author = "M. Anton Ertl",
> title = "Stack Caching for Interpreters",
> crossref = "sigplan95",
> pages = "315--327",
> url = "http://www.complang.tuwien.ac.at/papers/ertl95pldi.ps.gz",
Thanks for the reference.
w..
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-04 11:59 -0700 |
| Message-ID | <b90bb725-f797-4ca5-9163-4ab10001fdc0@googlegroups.com> |
| In reply to | #51597 |
On Tuesday, October 4, 2016 at 2:18:12 AM UTC-7, Anton Ertl wrote:
> Another reference is my first stack caching paper [ertl95pldi]. You
> can find more data in
> <http://www.complang.tuwien.ac.at/misc/stack-caching-data/>.
>
> @InProceedings{ertl95pldi,
> author = "M. Anton Ertl",
> title = "Stack Caching for Interpreters",
> crossref = "sigplan95",
> pages = "315--327",
> url = "http://www.complang.tuwien.ac.at/papers/ertl95pldi.ps.gz",
> abstract = "An interpreter can spend a significant part of its
> execution time on arguments of virtual machine
> instructions. This paper explores two methods to
> reduce this overhead for virtual stack machines by
> caching top-of-stack values in (real machine)
> registers. The {\em dynamic method} is based on
> having, for every possible state of the cache, one
> specialized version of the whole interpreter; the
> execution of an instruction usually changes the
> state of the cache and the next instruction is
> executed in the version corresponding to the new
> state. In the {\em static method} a state machine
> that keeps track of the cache state is added to the
> compiler. Common instructions exist in specialized
> versions for several states, but it is not necessary
> to have a version of every instruction for every
> cache state. Stack manipulation instructions are
> optimized away."
When I designed the Stundurd, I was working on the assumption that memory-access is significantly slower than register-access, and hence the key to boosting performance was to hold data in registers as much as possible. I allow zero, one or two of the top data-stack items to be held in registers. All of the machine-code primitives have multiple versions, which expect 0, 1 or 2 items in registers and leave 0, 1 or 2 items in registers. The compiler has to be smart about compiling the correct versions of the primitives so they match up --- a primitive that leaves some number of top items in registers has to be followed by a primitive that expects the same number of top items in registers --- the goal is minimize how many stack-juggling primitives get compiled (primitives that move data-stack items into or out of registers, but don't do any useful work).
All in all, I thought my design was pretty cool. A lot of people (including Walter Banks) told me that my design was obsolete however. I was thinking about processors as they existed in the mid-1990s (when the MiniForth/RACE was developed), but that modern processors are different --- nowadays an FPGA will have all of its RAM inside of the chip, and hence there is no difference in speed between "memory" and "registers" which are actually the same thing.
Anton Ertl's paper (as much as I can tell from the abstract) seems to be promoting the same idea that I was working on --- why doesn't anybody tell him that this idea is obsolete and hasn't been meaningful since the mid-1990s? --- IIRC, he was one of the many people who slammed my Stundurd design as being 20 years obsolete from day one.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-05 09:59 +0000 |
| Message-ID | <2016Oct5.115932@mips.complang.tuwien.ac.at> |
| In reply to | #51611 |
hughaguilar96@gmail.com writes:
>When I designed the Stundurd, I was working on the assumption that memory-a=
>ccess is significantly slower than register-access, and hence the key to bo=
>osting performance was to hold data in registers as much as possible. I all=
>ow zero, one or two of the top data-stack items to be held in registers. Al=
>l of the machine-code primitives have multiple versions, which expect 0, 1 =
>or 2 items in registers and leave 0, 1 or 2 items in registers. The compile=
>r has to be smart about compiling the correct versions of the primitives so=
> they match up --- a primitive that leaves some number of top items in regi=
>sters has to be followed by a primitive that expects the same number of top=
> items in registers
That's what gforth-fast is doing (although it uses only 0 or 1 items
on many architectures, and 0-3 on PowerPC and ARM64).
>All in all, I thought my design was pretty cool. A lot of people (including=
> Walter Banks) told me that my design was obsolete however. I was thinking =
>about processors as they existed in the mid-1990s (when the MiniForth/RACE =
>was developed), but that modern processors are different --- nowadays an FP=
>GA will have all of its RAM inside of the chip, and hence there is no diffe=
>rence in speed between "memory" and "registers" which are actually the same=
> thing.
>
>Anton Ertl's paper (as much as I can tell from the abstract) seems to be pr=
>omoting the same idea that I was working on --- why doesn't anybody tell hi=
>m that this idea is obsolete and hasn't been meaningful since the mid-1990s=
>?
Maybe you should check whether the claims are true. Of course, for an
FPGA-based CPU, you can make registers as slow as RAM if you want, but
why would you do that, and why would you use a register machine for
implementing Forth on an FPGA in the first place?
Anyway, on hard CPUs there is a significant difference between
register access and L1 cache access (and the fairy tale about
memory/cache accesses being as fast as register accesses has already
been told in the 1990s).
In particular, if you store to memory and then load from the same
spot, as you do if keep TOS in memory, this takes at least 4 cycles on
a modern Intel CPU, whereas just keeping it in a register costs 0
cycles. And similar for other hard CPUs.
If you already keep the TOS in a register, then adding the option to
allow 0 buys a little bit, optionally using 2 buys some more, and
optionally using 3 buys very little more. Here are timing results for
a Cortex A53 executing ARM64 code:
sieve bubble matrix fib fft version
0.390 0.490 0.270 0.520 0.260 2016-04-27 (0-1 registers)
0.330 0.370 0.250 0.480 0.290 2010-05-27 (0-3 registers)
For more results, take a look at
@InProceedings{ertl&gregg05,
author = {M. Anton Ertl and David Gregg},
title = {Stack Caching in {Forth}},
crossref = {euroforth05},
pages = {6--15},
url = {http://www.complang.tuwien.ac.at/papers/ertl%26gregg05.ps.gz},
pdfurl = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/ertl%26gregg05.pdf},
OPTnote = {not refereed},
abstract = {Stack caching speeds Forth up by keeping stack items
in registers, reducing the number of memory accesses
for stack items. This paper describes our work on
extending Gforth's stack caching implementation to
support more than one register in the canonical
state, and presents timing results for the resulting
Forth system. For single-representation stack
caches, keeping just one stack item in registers is
usually best, and provides speedups up to a factor
of 2.84 over the straight-forward stack
representation. For stack caches with multiple stack
representations, using the one-register
representation as canonical representation is
usually optimal, resulting in an overall speedup of
up to a factor of 3.80 (and up to a factor of 1.53
over single-representation stack caching).}
}
@Proceedings{euroforth05,
title = {21st EuroForth Conference},
booktitle = {21st EuroForth Conference},
year = {2005},
key = {EuroForth'05},
editor = {M. Anton Ertl},
url = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/proceedings.pdf}
}
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-05 10:16 -0400 |
| Message-ID | <nt31uj$hvt$1@dont-email.me> |
| In reply to | #51622 |
On 10/5/2016 5:59 AM, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
>> When I designed the Stundurd, I was working on the assumption that memory-a=
>> ccess is significantly slower than register-access, and hence the key to bo=
>> osting performance was to hold data in registers as much as possible. I all=
>> ow zero, one or two of the top data-stack items to be held in registers. Al=
>> l of the machine-code primitives have multiple versions, which expect 0, 1 =
>> or 2 items in registers and leave 0, 1 or 2 items in registers. The compile=
>> r has to be smart about compiling the correct versions of the primitives so=
>> they match up --- a primitive that leaves some number of top items in regi=
>> sters has to be followed by a primitive that expects the same number of top=
>> items in registers
>
> That's what gforth-fast is doing (although it uses only 0 or 1 items
> on many architectures, and 0-3 on PowerPC and ARM64).
>
>> All in all, I thought my design was pretty cool. A lot of people (including=
>> Walter Banks) told me that my design was obsolete however. I was thinking =
>> about processors as they existed in the mid-1990s (when the MiniForth/RACE =
>> was developed), but that modern processors are different --- nowadays an FP=
>> GA will have all of its RAM inside of the chip, and hence there is no diffe=
>> rence in speed between "memory" and "registers" which are actually the same=
>> thing.
>>
>> Anton Ertl's paper (as much as I can tell from the abstract) seems to be pr=
>> omoting the same idea that I was working on --- why doesn't anybody tell hi=
>> m that this idea is obsolete and hasn't been meaningful since the mid-1990s=
>> ?
>
> Maybe you should check whether the claims are true. Of course, for an
> FPGA-based CPU, you can make registers as slow as RAM if you want, but
> why would you do that, and why would you use a register machine for
> implementing Forth on an FPGA in the first place?
The claim that block RAM is as fast as registers is not completely true.
The clock setup and clock to data delays are close enough, but
registers (even if implemented in a LUT) are async read while block RAM
is synchronous on reads as well as writes. This means you have to jump
through hoops to read a block RAM in the same clock cycle the address is
presented.
There are some tricks you can play to work around that, but they are
messy and one adds half a clock cycle to the output delay (clocking the
RAM on the falling edge rather than the rising edge. The other one I
sometimes use is to treat the register in the read path as an address
latch. It is updated on every clock cycle, but only used if the
instruction is a read. In my CPU design this means it mirrors the top
of the return stack since that is where addresses are used rather than
on the data stack.
> Anyway, on hard CPUs there is a significant difference between
> register access and L1 cache access (and the fairy tale about
> memory/cache accesses being as fast as register accesses has already
> been told in the 1990s).
>
> In particular, if you store to memory and then load from the same
> spot, as you do if keep TOS in memory, this takes at least 4 cycles on
> a modern Intel CPU, whereas just keeping it in a register costs 0
> cycles. And similar for other hard CPUs.
But that will vary across CPUs. If the comparison is for embedded
systems you need to consider other CPUs and caches. I believe some of
the lower end ARMs, CM3/CM4, run the caches as fast as registers, but
I'm not sure.
> If you already keep the TOS in a register, then adding the option to
> allow 0 buys a little bit, optionally using 2 buys some more, and
> optionally using 3 buys very little more. Here are timing results for
> a Cortex A53 executing ARM64 code:
>
> sieve bubble matrix fib fft version
> 0.390 0.490 0.270 0.520 0.260 2016-04-27 (0-1 registers)
> 0.330 0.370 0.250 0.480 0.290 2010-05-27 (0-3 registers)
>
> For more results, take a look at
>
> @InProceedings{ertl&gregg05,
> author = {M. Anton Ertl and David Gregg},
> title = {Stack Caching in {Forth}},
> crossref = {euroforth05},
> pages = {6--15},
> url = {http://www.complang.tuwien.ac.at/papers/ertl%26gregg05.ps.gz},
> pdfurl = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/ertl%26gregg05.pdf},
> OPTnote = {not refereed},
> abstract = {Stack caching speeds Forth up by keeping stack items
> in registers, reducing the number of memory accesses
> for stack items. This paper describes our work on
> extending Gforth's stack caching implementation to
> support more than one register in the canonical
> state, and presents timing results for the resulting
> Forth system. For single-representation stack
> caches, keeping just one stack item in registers is
> usually best, and provides speedups up to a factor
> of 2.84 over the straight-forward stack
> representation. For stack caches with multiple stack
> representations, using the one-register
> representation as canonical representation is
> usually optimal, resulting in an overall speedup of
> up to a factor of 3.80 (and up to a factor of 1.53
> over single-representation stack caching).}
> }
>
> @Proceedings{euroforth05,
> title = {21st EuroForth Conference},
> booktitle = {21st EuroForth Conference},
> year = {2005},
> key = {EuroForth'05},
> editor = {M. Anton Ertl},
> url = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/proceedings.pdf}
> }
>
> - anton
>
--
Rick C
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-06 08:21 +0000 |
| Message-ID | <2016Oct6.102113@mips.complang.tuwien.ac.at> |
| In reply to | #51623 |
rickman <gnuarm@gmail.com> writes:
>On 10/5/2016 5:59 AM, Anton Ertl wrote:
>> Anyway, on hard CPUs there is a significant difference between
>> register access and L1 cache access (and the fairy tale about
>> memory/cache accesses being as fast as register accesses has already
>> been told in the 1990s).
>>
>> In particular, if you store to memory and then load from the same
>> spot, as you do if keep TOS in memory, this takes at least 4 cycles on
>> a modern Intel CPU, whereas just keeping it in a register costs 0
>> cycles. And similar for other hard CPUs.
>
>But that will vary across CPUs. If the comparison is for embedded
>systems you need to consider other CPUs and caches. I believe some of
>the lower end ARMs, CM3/CM4, run the caches as fast as registers, but
>I'm not sure.
And the fairy tale is still told and believed today. It must be a
very attractive fantasy to be so persistent.
What is the reality: First of all, ARM is a load/store architecture,
so unless the loads and stores take 0 cycles (they don't, see below)
on these machines, keeping the TOS in memory will cost more than
keeping it in a register. Likewise for other stack items, although
there are tradeoffs to consider there that complicate the analysis.
Now, concerning the instruction timings, the "Cortex-M3 Technical
Reference Manual"
<http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337h/CHDDIGAC.html>
says:
|Operation Description Assembler Cycles
|Load Word LDR Rd, [Rn, <op2>] 2[c]
|Store Word STR Rd, [Rn, <op2>] 2[c]
|
|[c] Neighboring load and store single instructions can pipeline their
|address and data phases. This enables these instructions to complete
|in a single execution cycle.
I very much doubt that [c] applies if you have a store followed by a
load to the same address, so I would guess that this sequence costs at
least 4 cycles. For concrete data, measure it. I would not be
surprised if additional latency would become visible when the load
reads data very soon after the store has written it.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2016-10-04 05:00 -0700 |
| Message-ID | <c7066d2b-cd0d-405e-9905-4265c4d23d93@googlegroups.com> |
| In reply to | #51596 |
Am Dienstag, 4. Oktober 2016 09:31:05 UTC+2 schrieb Jan Coombs: > On Mon, 3 Oct 2016 18:20:21 +0200 > Bernd Linsel <bl1@gmx.com> wrote: > > > Perhaps you should read P. Koopman's excellent book on stack > > computers. It is online available at > > https://users.ece.cmu.edu/~koopman/stack_computers/ . > > Good advice, the book is perhaps the easily only locatable > reference for this type of information, and a good read. > > From section 6.4[1] it seemed to me that a depth of 12 items > for stack caches is a sweet spot. The fill/spill rate here is > mostly under 1%. > > So if you fetch 4 instructions per memory cycle then fill/spill > memory access will peak at one per 25 instruction fetches. > > A return stack cache of this size has similar memory usage. > > Jan Coombs > -- > [1] 6.4 STACK MANAGEMENT ISSUES > https://users.ece.cmu.edu/~koopman/stack_computers/sec6_4.html That "sweet spot" stack depth of 12 is an average stack spill figure of otherwise uncomparable programs. In other words it is not very useful. My own real world experience is that it might be sufficient for simple control programs. On the other hand for number crunching (e.g. controller algorithms involving linear system math) or Forth systems without locals, stack depths of say 32 are a bare design minimum.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-04 08:49 -0400 |
| Message-ID | <nt08he$ngo$1@gioia.aioe.org> |
| In reply to | #51596 |
On 2016-10-04 3:31 AM, Jan Coombs wrote: > On Mon, 3 Oct 2016 18:20:21 +0200 > Bernd Linsel <bl1@gmx.com> wrote: > >> Perhaps you should read P. Koopman's excellent book on stack >> computers. It is online available at >> https://users.ece.cmu.edu/~koopman/stack_computers/ . > > Good advice, the book is perhaps the easily only locatable > reference for this type of information, and a good read. > > From section 6.4[1] it seemed to me that a depth of 12 items > for stack caches is a sweet spot. The fill/spill rate here is > mostly under 1%. > > So if you fetch 4 instructions per memory cycle then fill/spill > memory access will peak at one per 25 instruction fetches. > > A return stack cache of this size has similar memory usage. These stack sizes are very close to our metrics derived from several hundred real (shipped) application code running on a variety of embedded systems. w..
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-10-03 16:28 -0700 |
| Message-ID | <87twctxbab.fsf@nightsong.com> |
| In reply to | #51572 |
Walter Banks <walter@bytecraft.com> writes: > I guess what is modest hardware size. How big is needed to accommodate > most applications given that a user or compiler makes a reasonable > attempt to write good code. What do you mean by "most applications"? Applications that run on workstations, mobile phones, internet servers etc. usually consume far more resources than the applications that run on stack processors from the Forth world. Large Forth applications (there are a few) usually run on large machines (PC's etc.) so maybe aren't relevant to your question. Forth programs on stack machines or microcontrollers generally avoid complicated control flow and tend to use between a few and some dozens of stack cells, plus up to a few K of memory cells. The GA144 cpus iirc have 10 data stack levels (T and S registers plus an 8-level circular buffer) and 9 return stack levels (R register plus 8-level circular buffer) but they are very small cpus. The Novix used off-chip stack memory with 256 elements for each stack, plus a few on-chip registers for the top levels. The J1 appears to have 32 levels for each stack: http://excamera.com/sphinx/fpga-j1.html If you can say the application area your processor is targeted at, you might get better advice. If it's a general purpose processor that has to run mainstream software, you probably want a conventional architecture. The main reason other than recreation I can think of to make a stack CPU is you want some tiny sequencer in a little corner of a bigger FPGA application. In that case you probably want to size the CPU to handle the surrounding application's specific requirements. In the designs I've seen, you can choose the stack size by changing a couple lines of Verilog.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-04 10:36 -0400 |
| Message-ID | <nt0epk$13ec$1@gioia.aioe.org> |
| In reply to | #51588 |
On 2016-10-03 7:28 PM, Paul Rubin wrote: > Walter Banks <walter@bytecraft.com> writes: >> I guess what is modest hardware size. How big is needed to >> accommodate most applications given that a user or compiler makes a >> reasonable attempt to write good code. > > What do you mean by "most applications"? Applications that run on > workstations, mobile phones, internet servers etc. usually consume > far more resources than the applications that run on stack processors > from the Forth world. Large Forth applications (there are a few) > usually run on large machines (PC's etc.) so maybe aren't relevant to > your question. > > Forth programs on stack machines or microcontrollers generally avoid > complicated control flow and tend to use between a few and some > dozens of stack cells, plus up to a few K of memory cells. The GA144 > cpus iirc have 10 data stack levels (T and S registers plus an > 8-level circular buffer) and 9 return stack levels (R register plus > 8-level circular buffer) but they are very small cpus. The Novix > used off-chip stack memory with 256 elements for each stack, plus a > few on-chip registers for the top levels. The J1 appears to have 32 > levels for each stack: http://excamera.com/sphinx/fpga-j1.html > > If you can say the application area your processor is targeted at, > you might get better advice. If it's a general purpose processor > that has to run mainstream software, you probably want a > conventional architecture. > > The main reason other than recreation I can think of to make a stack > CPU is you want some tiny sequencer in a little corner of a bigger > FPGA application. In that case you probably want to size the CPU to > handle the surrounding application's specific requirements. In the > designs I've seen, you can choose the stack size by changing a couple > lines of Verilog. > The application area is embedded systems in general. Like most processors in this area processors tend to be used in application areas rather than general purpose processors. The application area that it is most likely to be used in is distributed control and instrumentation. It is being implemented with some configurations having multiprocessors. The basic processor will be running at about 150Mips. I have worked on quite a few of these developments over the last 30 years or so. We have prototypes running on fpga's. A lot of the motivation of starting this thread is to get a different perspective on stack usage and design outside of the metrics I have for C and asm based applications used in similar area's of embedded systems. I have been making a point of staying away from implementation languages for a very specific reason. This processor will in all likelihood be programed in a variant of C. As several people here have pointed out C requires "..." which is true when you look at the C generic history. Most certainly the open source tools have genetics going back to the open C compiler tools. To make a point mapping locals on a stack frame in a PDP-11 was probably a good way to implement locals on that platform but as I have shown in many compilers not the only way. It doesn't have to be that way C is a language that describes a problem and the compiler writers (me) have to map the problem effectively on the target. I have targeted C compilers to embedded processors, forth, functional languages and even in one case a form of state machine. We have adapted the language to support event driven applications. Forth has a much larger component of implementation built into the actual application code. This brings me back to the actual questions. My role in the tool development of this project is more like a forth programmer than a C programmer. The code creation trials and tribulations of this user group are very close to the choices I am making writing the optimizer for the code generator for this processor. To address one last point you have made the underlying verilog or vhdl implementing the ISA is flexible and easily changed I agree. We have done that many times over the last year or so to understand the impact of changes on code generation. w..
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web