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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-10-06 02:17 -0500 |
| Message-ID | <IOWdnRFAXJzwZ2jKnZ2dnUU7-UvNnZ2d@supernews.com> |
| In reply to | #51631 |
alex <alex@rivadpm.com> wrote: > JITs are valuable because they allow compiling work to be done at > run time that isn't possible at compile time. For instance, an > array's shape may not be known at compile time, but driven by > external data; JIT compiling SQL statements, where optimisations can > be made at runtime based on the input data; JIT parallelization for > unknown workloads or unknown compute & processor availability; etc. The other crucial thing is that a JIT can optimize only along hot code paths, ignoring everything else. This makes it possible to inline extremely deep, eliminating call overhead, removing dynamic memory allocation, and eliminating many branches. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-04 19:27 -0400 |
| Message-ID | <nt1dsi$9ba$2@dont-email.me> |
| In reply to | #51610 |
On 10/4/2016 2:46 PM, Hans Bezemer wrote: > rickman wrote: >> There are many answers to your question and they all related to what you >> want to do with the processor. It has been stated many times that for >> most apps, an 8 element stack is enough. But if you wish to support >> recursion a million elements may not be enough. >> >> Some designs use one stack, others use as many as four. Again, it all >> depends. > True. 4tH has got a single, shared return/data stack of 512 elements. I > chose for thaty configuration because you can have programs which need > quite some return stack depth, but few data elements - or the > inverse. "Stack full" means the stack pointers cross. I think you mean you have two separate stacks sharing one block of memory, one growing up and the other growing down. That's not really a single stack. There are two stack pointers. > I got an FP package that uses the datastack (shared) and one that has its > own stack. On top of that, I got a small lib that allows me to create my > own stacks: > > ---8<--- > : stack dup ! ; ( stack --) > : a@ @ @ ; ( stack -- n) > : >a 1 cells over +! @ ! ; ( n stack --) > : a> dup a@ -1 cells rot +! ; ( stack -- n) > : adepth dup @ swap - ; ( stack -- n) > ---8<--- > > On average, the standard stack is more than sufficient - unless you want to > do something crazy like the Ackermann function (unoptimized). > > The only place I was really cramming as much on this poor stack was the 4tH > preprocessor doing nested macros. I even had to off load the data elements > to a separate stack. > > Hans Bezemer > -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2016-10-05 18:58 +0200 |
| Message-ID | <57f5312f$0$16964$e4fe514c@news.xs4all.nl> |
| In reply to | #51619 |
rickman wrote: > I think you mean you have two separate stacks sharing one block of > memory, one growing up and the other growing down. That's not really a > single stack. There are two stack pointers. Absolutely correct. But since there is no way to tell whether a item on a certain location on any particular moment is a data- or a return item, I consider it a shared stack. All a matter of definition, I guess. But you know what I meant and that's the important point ;-) Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-05 13:17 -0400 |
| Message-ID | <nt3cjh$rq3$1@dont-email.me> |
| In reply to | #51624 |
On 10/5/2016 12:58 PM, Hans Bezemer wrote: > rickman wrote: >> I think you mean you have two separate stacks sharing one block of >> memory, one growing up and the other growing down. That's not really a >> single stack. There are two stack pointers. > Absolutely correct. But since there is no way to tell whether a item on a > certain location on any particular moment is a data- or a return item, I > consider it a shared stack. All a matter of definition, I guess. But you > know what I meant and that's the important point ;-) I'm a bit lost now... Why can't you tell what's data and what's return addresses? Isn't that what the stack pointers are for? I guess you are really saying the same thing as before, the two stacks share the same block of memory so any memory location can be either data or return address... but it should be easy to tell which it is. To my thinking the stack pointers define the stack, so having two independent pointers means two stacks. But I'm glad you mentioned this. In FPGAs it is common to use a block of RAM as two RAMs since they are dual ported. Sharing one block RAM between two stacks is common. I didn't occur to me until now to use the opposite direction stack pointers to maximize the available space. This does preclude Chuck's trick of making the stack wrap around so it can be used as a ring buffer. But then the size has to be pretty small to be useful. I believe the F18A has a 10 deep data stack, top and second on stack registers and an 8 deep ring buffer. The return stack is just the top of stack and an 8 deep ring buffer. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2016-10-22 12:35 +0200 |
| Message-ID | <580b40e4$0$877$e4fe514c@news.xs4all.nl> |
| In reply to | #51625 |
rickman wrote: > On 10/5/2016 12:58 PM, Hans Bezemer wrote: >> rickman wrote: >>> I think you mean you have two separate stacks sharing one block of >>> memory, one growing up and the other growing down. That's not really a >>> single stack. There are two stack pointers. >> Absolutely correct. But since there is no way to tell whether a item on a >> certain location on any particular moment is a data- or a return item, I >> consider it a shared stack. All a matter of definition, I guess. But you >> know what I meant and that's the important point ;-) > > I'm a bit lost now... Why can't you tell what's data and what's return > addresses? Isn't that what the stack pointers are for? > > I guess you are really saying the same thing as before, the two stacks > share the same block of memory so any memory location can be either data > or return address... but it should be easy to tell which it is. > > To my thinking the stack pointers define the stack, so having two > independent pointers means two stacks. > > But I'm glad you mentioned this. In FPGAs it is common to use a block > of RAM as two RAMs since they are dual ported. Sharing one block RAM > between two stacks is common. I didn't occur to me until now to use the > opposite direction stack pointers to maximize the available space. > > This does preclude Chuck's trick of making the stack wrap around so it > can be used as a ring buffer. But then the size has to be pretty small > to be useful. I believe the F18A has a 10 deep data stack, top and > second on stack registers and an 8 deep ring buffer. The return stack > is just the top of stack and an 8 deep ring buffer. > Again, you're right. The stack pointers are the ONLY way to tell what is what - which is pretty obvious, because the system must know what is what. I meant that if you just look at the block of memory itself, you can't because any location can be occupied by a return- or data-item. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-05 12:18 -0500 |
| Message-ID | <nt3cjs$rh7$1@dont-email.me> |
| In reply to | #51624 |
On 10/5/2016 11:58 AM, Hans Bezemer wrote: > rickman wrote: >> I think you mean you have two separate stacks sharing one block of >> memory, one growing up and the other growing down. That's not really a >> single stack. There are two stack pointers. > Absolutely correct. But since there is no way to tell whether a item on a > certain location on any particular moment is a data- or a return item, I > consider it a shared stack. All a matter of definition, I guess. But you > know what I meant and that's the important point ;-) > > Hans Bezemer > If one has a 1K deep block of RAM, and the stack pointers are 9 bits, one having bit 10 high, the other having bit 10 low. the two stacks will never run into each other, they will each wrap around their own 512 byte space. Another scheme is one stack grows down and starts at the top of RAM, the other starts at the bottom and grows upwards. all is OK as long as the sum of the depth of both stacks is not 1024 or greater. This has more flexibility as one stack can be way bigger than the other as needed. In this case the stack pointers are 10 bits. In both cases one would buffer the stacks with registers as the TOS, I like one for the Program Stack and two levels of buffering for the DATA stack so that the top 3 Data stack levels are ready to be used with no delays. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-05 16:07 -0400 |
| Message-ID | <nt3mih$1k3$1@dont-email.me> |
| In reply to | #51626 |
On 10/5/2016 1:18 PM, Cecil Bayona wrote: > > > On 10/5/2016 11:58 AM, Hans Bezemer wrote: >> rickman wrote: >>> I think you mean you have two separate stacks sharing one block of >>> memory, one growing up and the other growing down. That's not really a >>> single stack. There are two stack pointers. >> Absolutely correct. But since there is no way to tell whether a item on a >> certain location on any particular moment is a data- or a return item, I >> consider it a shared stack. All a matter of definition, I guess. But you >> know what I meant and that's the important point ;-) >> >> Hans Bezemer >> > If one has a 1K deep block of RAM, and the stack pointers are 9 bits, > one having bit 10 high, the other having bit 10 low. the two stacks will > never run into each other, they will each wrap around their own 512 byte > space. > > Another scheme is one stack grows down and starts at the top of RAM, the > other starts at the bottom and grows upwards. all is OK as long as the > sum of the depth of both stacks is not 1024 or greater. This has more > flexibility as one stack can be way bigger than the other as needed. In > this case the stack pointers are 10 bits. > > In both cases one would buffer the stacks with registers as the TOS, I > like one for the Program Stack and two levels of buffering for the DATA > stack so that the top 3 Data stack levels are ready to be used with no > delays. Not sure why having the top three items of the stack available is important. The CPU I designed had a register for the top of stack and used the block RAM for the next on stack. The block RAM looks like a register so for all intents and purposes, this functionally was two registers as the top two items on the stack. This arrangement allows all the more common Forth words to be implemented in one clock cycle. The only one I can think of off the top of my head that can't be supported by this is ROT, which according to Koopman is 13 in dynamic frequency of use averaging about 2% and not in the list of the top 18 in static frequency of use, so not a terrible thing to construct from primitives. Why do you feel it useful to cache three stack items on chip? Unless the stack was in external RAM and the three cached stack items were used as a flexible FIFO to minimize memory accesses, I don't see the utility. Is this to accommodate combining instructions for parallel execution? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-05 15:50 -0500 |
| Message-ID | <nt3p33$aqp$1@dont-email.me> |
| In reply to | #51628 |
On 10/5/2016 3:07 PM, rickman wrote: > On 10/5/2016 1:18 PM, Cecil Bayona wrote: >> >> >> On 10/5/2016 11:58 AM, Hans Bezemer wrote: >>> rickman wrote: >>>> I think you mean you have two separate stacks sharing one block of >>>> memory, one growing up and the other growing down. That's not really a >>>> single stack. There are two stack pointers. >>> Absolutely correct. But since there is no way to tell whether a item >>> on a >>> certain location on any particular moment is a data- or a return item, I >>> consider it a shared stack. All a matter of definition, I guess. But you >>> know what I meant and that's the important point ;-) >>> >>> Hans Bezemer >>> >> If one has a 1K deep block of RAM, and the stack pointers are 9 bits, >> one having bit 10 high, the other having bit 10 low. the two stacks will >> never run into each other, they will each wrap around their own 512 byte >> space. >> >> Another scheme is one stack grows down and starts at the top of RAM, the >> other starts at the bottom and grows upwards. all is OK as long as the >> sum of the depth of both stacks is not 1024 or greater. This has more >> flexibility as one stack can be way bigger than the other as needed. In >> this case the stack pointers are 10 bits. >> >> In both cases one would buffer the stacks with registers as the TOS, I >> like one for the Program Stack and two levels of buffering for the DATA >> stack so that the top 3 Data stack levels are ready to be used with no >> delays. > > Not sure why having the top three items of the stack available is > important. The CPU I designed had a register for the top of stack and > used the block RAM for the next on stack. The block RAM looks like a > register so for all intents and purposes, this functionally was two > registers as the top two items on the stack. This arrangement allows > all the more common Forth words to be implemented in one clock cycle. > The only one I can think of off the top of my head that can't be > supported by this is ROT, which according to Koopman is 13 in dynamic > frequency of use averaging about 2% and not in the list of the top 18 in > static frequency of use, so not a terrible thing to construct from > primitives. > > Why do you feel it useful to cache three stack items on chip? Unless > the stack was in external RAM and the three cached stack items were used > as a flexible FIFO to minimize memory accesses, I don't see the utility. > Is this to accommodate combining instructions for parallel execution? > No Parallel execution yet, but just because. TOS and the RAM itself are enough for many operations, but there are also a bunch that reaches for the third item, with two registers and RAM that makes the top 3 stack items accessible with no speed penalty so makes things a little faster. No much but it doesn't cost much to have TOS and two lower levels available. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-05 17:36 -0400 |
| Message-ID | <nt3rp4$im7$1@dont-email.me> |
| In reply to | #51630 |
On 10/5/2016 4:50 PM, Cecil Bayona wrote: > > > On 10/5/2016 3:07 PM, rickman wrote: >> On 10/5/2016 1:18 PM, Cecil Bayona wrote: >>> >>> >>> On 10/5/2016 11:58 AM, Hans Bezemer wrote: >>>> rickman wrote: >>>>> I think you mean you have two separate stacks sharing one block of >>>>> memory, one growing up and the other growing down. That's not >>>>> really a >>>>> single stack. There are two stack pointers. >>>> Absolutely correct. But since there is no way to tell whether a item >>>> on a >>>> certain location on any particular moment is a data- or a return >>>> item, I >>>> consider it a shared stack. All a matter of definition, I guess. But >>>> you >>>> know what I meant and that's the important point ;-) >>>> >>>> Hans Bezemer >>>> >>> If one has a 1K deep block of RAM, and the stack pointers are 9 bits, >>> one having bit 10 high, the other having bit 10 low. the two stacks will >>> never run into each other, they will each wrap around their own 512 byte >>> space. >>> >>> Another scheme is one stack grows down and starts at the top of RAM, the >>> other starts at the bottom and grows upwards. all is OK as long as the >>> sum of the depth of both stacks is not 1024 or greater. This has more >>> flexibility as one stack can be way bigger than the other as needed. In >>> this case the stack pointers are 10 bits. >>> >>> In both cases one would buffer the stacks with registers as the TOS, I >>> like one for the Program Stack and two levels of buffering for the DATA >>> stack so that the top 3 Data stack levels are ready to be used with no >>> delays. >> >> Not sure why having the top three items of the stack available is >> important. The CPU I designed had a register for the top of stack and >> used the block RAM for the next on stack. The block RAM looks like a >> register so for all intents and purposes, this functionally was two >> registers as the top two items on the stack. This arrangement allows >> all the more common Forth words to be implemented in one clock cycle. >> The only one I can think of off the top of my head that can't be >> supported by this is ROT, which according to Koopman is 13 in dynamic >> frequency of use averaging about 2% and not in the list of the top 18 in >> static frequency of use, so not a terrible thing to construct from >> primitives. >> >> Why do you feel it useful to cache three stack items on chip? Unless >> the stack was in external RAM and the three cached stack items were used >> as a flexible FIFO to minimize memory accesses, I don't see the utility. >> Is this to accommodate combining instructions for parallel execution? >> > No Parallel execution yet, but just because. > > TOS and the RAM itself are enough for many operations, but there are > also a bunch that reaches for the third item, with two registers and RAM > that makes the top 3 stack items accessible with no speed penalty so > makes things a little faster. No much but it doesn't cost much to have > TOS and two lower levels available. I'm trying to understand what "bunch" of operations use three stack items. The only common one that comes to mind is ROT. There is not much reason to optimize infrequently used operations. If you are designing a MISC, the extra register may be more than you think. The register itself is not so much, but the data path connecting the registers and functional units blossoms dramatically when adding registers. In FPGAs and most ASICs, there are no "busses". Instead every data source on a bus is an input to a mux. If controlled separately, this mux must be duplicated for every register written to. The logic required can be order n^2. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-05 17:14 -0500 |
| Message-ID | <nt3tvc$tdt$1@dont-email.me> |
| In reply to | #51634 |
On 10/5/2016 4:36 PM, rickman wrote: > On 10/5/2016 4:50 PM, Cecil Bayona wrote: >> >>>>> Why do you feel it useful to cache three stack items on chip? Unless >>> the stack was in external RAM and the three cached stack items were used >>> as a flexible FIFO to minimize memory accesses, I don't see the utility. >>> Is this to accommodate combining instructions for parallel execution? >>> >> No Parallel execution yet, but just because. >> >> TOS and the RAM itself are enough for many operations, but there are >> also a bunch that reaches for the third item, with two registers and RAM >> that makes the top 3 stack items accessible with no speed penalty so >> makes things a little faster. No much but it doesn't cost much to have >> TOS and two lower levels available. > > I'm trying to understand what "bunch" of operations use three stack > items. The only common one that comes to mind is ROT. There is not > much reason to optimize infrequently used operations. > > If you are designing a MISC, the extra register may be more than you > think. The register itself is not so much, but the data path connecting > the registers and functional units blossoms dramatically when adding > registers. In FPGAs and most ASICs, there are no "busses". Instead > every data source on a bus is an input to a mux. If controlled > separately, this mux must be duplicated for every register written to. > The logic required can be order n^2. > I'm thinking ahead to an optimizing compiler that will combine multiple instructions into one, for that end reaching into the third item happens more often than a normal Forth program. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-10-05 14:48 -1000 |
| Message-ID | <f5ydnWENyNXcAmjKnZ2dnUU7-QvNnZ2d@supernews.com> |
| In reply to | #51634 |
On 10/5/16 11:36 AM, rickman wrote: > On 10/5/2016 4:50 PM, Cecil Bayona wrote: >> >> >> On 10/5/2016 3:07 PM, rickman wrote: >>> On 10/5/2016 1:18 PM, Cecil Bayona wrote: >>>> >>>> >>>> On 10/5/2016 11:58 AM, Hans Bezemer wrote: >>>>> rickman wrote: >>>>>> I think you mean you have two separate stacks sharing one block of >>>>>> memory, one growing up and the other growing down. That's not >>>>>> really a >>>>>> single stack. There are two stack pointers. >>>>> Absolutely correct. But since there is no way to tell whether a item >>>>> on a >>>>> certain location on any particular moment is a data- or a return >>>>> item, I >>>>> consider it a shared stack. All a matter of definition, I guess. But >>>>> you >>>>> know what I meant and that's the important point ;-) >>>>> >>>>> Hans Bezemer >>>>> >>>> If one has a 1K deep block of RAM, and the stack pointers are 9 bits, >>>> one having bit 10 high, the other having bit 10 low. the two stacks >>>> will >>>> never run into each other, they will each wrap around their own 512 >>>> byte >>>> space. >>>> >>>> Another scheme is one stack grows down and starts at the top of RAM, >>>> the >>>> other starts at the bottom and grows upwards. all is OK as long as the >>>> sum of the depth of both stacks is not 1024 or greater. This has more >>>> flexibility as one stack can be way bigger than the other as needed. In >>>> this case the stack pointers are 10 bits. >>>> >>>> In both cases one would buffer the stacks with registers as the TOS, I >>>> like one for the Program Stack and two levels of buffering for the DATA >>>> stack so that the top 3 Data stack levels are ready to be used with no >>>> delays. >>> >>> Not sure why having the top three items of the stack available is >>> important. The CPU I designed had a register for the top of stack and >>> used the block RAM for the next on stack. The block RAM looks like a >>> register so for all intents and purposes, this functionally was two >>> registers as the top two items on the stack. This arrangement allows >>> all the more common Forth words to be implemented in one clock cycle. >>> The only one I can think of off the top of my head that can't be >>> supported by this is ROT, which according to Koopman is 13 in dynamic >>> frequency of use averaging about 2% and not in the list of the top 18 in >>> static frequency of use, so not a terrible thing to construct from >>> primitives. >>> >>> Why do you feel it useful to cache three stack items on chip? Unless >>> the stack was in external RAM and the three cached stack items were used >>> as a flexible FIFO to minimize memory accesses, I don't see the utility. >>> Is this to accommodate combining instructions for parallel execution? >>> >> No Parallel execution yet, but just because. >> >> TOS and the RAM itself are enough for many operations, but there are >> also a bunch that reaches for the third item, with two registers and RAM >> that makes the top 3 stack items accessible with no speed penalty so >> makes things a little faster. No much but it doesn't cost much to have >> TOS and two lower levels available. > > I'm trying to understand what "bunch" of operations use three stack > items. The only common one that comes to mind is ROT. There is not > much reason to optimize infrequently used operations. Source, destination, count? There's a bunch of words (moves, compares) that take those three. Not a huge bunch, though. > If you are designing a MISC, the extra register may be more than you > think. The register itself is not so much, but the data path connecting > the registers and functional units blossoms dramatically when adding > registers. In FPGAs and most ASICs, there are no "busses". Instead > every data source on a bus is an input to a mux. If controlled > separately, this mux must be duplicated for every register written to. > The logic required can be order n^2. > Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-05 20:49 -0500 |
| Message-ID | <nt4aic$jf6$1@dont-email.me> |
| In reply to | #51638 |
On 10/5/2016 7:48 PM, Elizabeth D. Rather wrote: > On 10/5/16 11:36 AM, rickman wrote: >> On 10/5/2016 4:50 PM, Cecil Bayona wrote: >>> >>> >>> On 10/5/2016 3:07 PM, rickman wrote: >>>> On 10/5/2016 1:18 PM, Cecil Bayona wrote: >>>>> >>>>> >>>>> On 10/5/2016 11:58 AM, Hans Bezemer wrote: >>>>>> rickman wrote: >>>>>>> I think you mean you have two separate stacks sharing one block of >>>>>>> memory, one growing up and the other growing down. That's not >>>>>>> really a >>>>>>> single stack. There are two stack pointers. >>>>>> Absolutely correct. But since there is no way to tell whether a item >>>>>> on a >>>>>> certain location on any particular moment is a data- or a return >>>>>> item, I >>>>>> consider it a shared stack. All a matter of definition, I guess. But >>>>>> you >>>>>> know what I meant and that's the important point ;-) >>>>>> >>>>>> Hans Bezemer >>>>>> >>>>> If one has a 1K deep block of RAM, and the stack pointers are 9 bits, >>>>> one having bit 10 high, the other having bit 10 low. the two stacks >>>>> will >>>>> never run into each other, they will each wrap around their own 512 >>>>> byte >>>>> space. >>>>> >>>>> Another scheme is one stack grows down and starts at the top of RAM, >>>>> the >>>>> other starts at the bottom and grows upwards. all is OK as long as the >>>>> sum of the depth of both stacks is not 1024 or greater. This has more >>>>> flexibility as one stack can be way bigger than the other as >>>>> needed. In >>>>> this case the stack pointers are 10 bits. >>>>> >>>>> In both cases one would buffer the stacks with registers as the TOS, I >>>>> like one for the Program Stack and two levels of buffering for the >>>>> DATA >>>>> stack so that the top 3 Data stack levels are ready to be used with no >>>>> delays. >>>> >>>> Not sure why having the top three items of the stack available is >>>> important. The CPU I designed had a register for the top of stack and >>>> used the block RAM for the next on stack. The block RAM looks like a >>>> register so for all intents and purposes, this functionally was two >>>> registers as the top two items on the stack. This arrangement allows >>>> all the more common Forth words to be implemented in one clock cycle. >>>> The only one I can think of off the top of my head that can't be >>>> supported by this is ROT, which according to Koopman is 13 in dynamic >>>> frequency of use averaging about 2% and not in the list of the top >>>> 18 in >>>> static frequency of use, so not a terrible thing to construct from >>>> primitives. >>>> >>>> Why do you feel it useful to cache three stack items on chip? Unless >>>> the stack was in external RAM and the three cached stack items were >>>> used >>>> as a flexible FIFO to minimize memory accesses, I don't see the >>>> utility. >>>> Is this to accommodate combining instructions for parallel execution? >>>> >>> No Parallel execution yet, but just because. >>> >>> TOS and the RAM itself are enough for many operations, but there are >>> also a bunch that reaches for the third item, with two registers and RAM >>> that makes the top 3 stack items accessible with no speed penalty so >>> makes things a little faster. No much but it doesn't cost much to have >>> TOS and two lower levels available. >> >> I'm trying to understand what "bunch" of operations use three stack >> items. The only common one that comes to mind is ROT. There is not >> much reason to optimize infrequently used operations. > > Source, destination, count? There's a bunch of words (moves, compares) > that take those three. Not a huge bunch, though. > >> If you are designing a MISC, the extra register may be more than you >> think. The register itself is not so much, but the data path connecting >> the registers and functional units blossoms dramatically when adding >> registers. In FPGAs and most ASICs, there are no "busses". Instead >> every data source on a bus is an input to a mux. If controlled >> separately, this mux must be duplicated for every register written to. >> The logic required can be order n^2. >> > > Cheers, > Elizabeth > It will try to combine multiple instructions and generate a better sequence hence sometime having access to the 3rd stack item come handy. In a z80 it would use indexed access but on a stack machine that may not be possible. The Forth CPU I'm thinking of creating would have two index registers to access general memory but not the stacks which is a separate memory space, but I may change my mind on that issue, nothing is final until one is six feet under. The FPGA I will use has 21K 4 input LUTs it should be plenty for what I'm thinking about, a somewhat similar implementation minus the index registers I have been working on uses 28% of a 5K LUT device. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-03 16:32 +0000 |
| Message-ID | <2016Oct3.183201@mips.complang.tuwien.ac.at> |
| In reply to | #51568 |
Walter Banks <walter@bytecraft.com> writes:
>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?
For Forth, a data stack with 32 cells will still occasionally overflow
on naturally recursive tasks. If you can work around that (either the
programmer, the compiler, or the run-time system avoids or deals with
the stack overflow), then 32 cells is plenty, 16 cells won't cause
many overflows, and Chuck Moore decided to go with 6 in IIRC the C18;
not sure what's the number on the GA parts.
For Forth, you want a data stack and a return stack; if you have FP,
also an FP stack. For locals you may be able to make do with the
return stack, although alignment concerns are an issue if you support
FP locals; in that case, possibly a separate locals stack.
- 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 | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-10-03 13:53 -0700 |
| Message-ID | <fb01b5ff-f58f-42b5-89f7-6f7a1c437069@googlegroups.com> |
| In reply to | #51568 |
This is good information ... in my little implementation, I am (was) using 1K (256 values ... it is a 32-bit implementation) for each stack. It looks like I can back that off considerably. I am going to change them to be 64 cells each. From the sound of it, even 64 is probably overkill. Re the original question, assuming they are easy to configure, why not start with sizes that seem reasonable and tweak it as issues arise? I imagine that is what you are doing ... looking for insight into what reasonable starting sizes would be, from people who have "been there and done that" ... Cheers, Chris
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-03 17:54 -0400 |
| Message-ID | <nsuk2i$aiq$1@gioia.aioe.org> |
| In reply to | #51582 |
On 2016-10-03 4:53 PM, Chris Curl wrote: > This is good information ... in my little implementation, I am (was) using > 1K (256 values ... it is a 32-bit implementation) for each stack. It looks > like I can back that off considerably. I am going to change them to be 64 > cells each. From the sound of it, even 64 is probably overkill. > > Re the original question, assuming they are easy to configure, why not > start with sizes that seem reasonable and tweak it as issues arise? > > I imagine that is what you are doing ... looking for insight into what > reasonable starting sizes would be, from people who have "been there and > done that" ... This is a commercial processor that I am trying to replace cut and try with design. It is pretty easy at this point to change stack(s) sizes but various choices have implementation ramifications. The underlying processor core ISA has been running since late 2013. w..
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> |
|---|---|
| Date | 2016-10-03 23:40 -0400 |
| Message-ID | <20161003234046.3761250b@_> |
| In reply to | #51568 |
On Mon, 3 Oct 2016 08:22:26 -0400 Walter Banks <walter@bytecraft.com> wrote: > I am currently working on a stack processor ISA. > > What better place to ask about stacks. Just over a year ago we had a discussion on stack size here. (See "Metrics on stack usage" on c.l.f. by Anton Ertl) > How many? single stack or two or three. You'll need one stack for C or two stacks for Forth. > What depth? You'll need about 32 for Forth at a minimum. > Why? Philip Koopman did a simulation of register spills versus stack size in 1990 for Forth. "The right answer, then, to how big stacks should be is 16 or 32 elements, no more" said Philip Koopman in "Design Tradeoffs in Stack Computers," Forth Dimensions, Volume 11 Number 6, March/April 1990. http://users.ece.cmu.edu/~koopman/forth/4thdim_11_6.pdf Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-04 11:30 -0400 |
| Message-ID | <nt0hvi$19nh$1@gioia.aioe.org> |
| In reply to | #51592 |
On 2016-10-03 11:40 PM, Rod Pemberton wrote: > On Mon, 3 Oct 2016 08:22:26 -0400 > Walter Banks <walter@bytecraft.com> wrote: > >> I am currently working on a stack processor ISA. >> >> What better place to ask about stacks. > > Just over a year ago we had a discussion on stack size here. > (See "Metrics on stack usage" on c.l.f. by Anton Ertl) > >> How many? single stack or two or three. > > You'll need one stack for C or two stacks for Forth. > >> What depth? > > You'll need about 32 for Forth at a minimum. > >> Why? > > Philip Koopman did a simulation of register spills versus stack size in > 1990 for Forth. "The right answer, then, to how big stacks should be is > 16 or 32 elements, no more" said Philip Koopman in "Design Tradeoffs in > Stack Computers," Forth Dimensions, Volume 11 Number 6, March/April > 1990. > > http://users.ece.cmu.edu/~koopman/forth/4thdim_11_6.pdf > Thanks for reminding me of this paper. There is some interesting information in it. I looked at it a two or three years ago looking for ISA approaches to stack processors. The whole design process of stack processors has matured and can now be quite a bit more bit efficient. Koopman's comments on stack size is backed by some real insight into it. Thanks. w..
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-03 21:47 -0700 |
| Message-ID | <480aaff9-bb16-43df-bbe7-5b32f6e39f3f@googlegroups.com> |
| In reply to | #51568 |
On Monday, October 3, 2016 at 5:22:29 AM UTC-7, Walter Banks wrote: > I am currently working on a stack processor ISA. What is the point of this project? If you want to program in Forth, you could buy RACE chips from Testra and use my MFX that I wrote in 1994 --- or use their on-chip Forth compiler that they wrote in MFX --- if you are going to delve into writing your own primitives in assembly-language, then you need MFX, but the on-chip Forth is easier to use because it is interactive (MFX is a cross-compiler). But, you don't want to program in Forth! My understanding from your emails to me is that you consider Forth to be an ugly language, and you are well aware that it is very difficult to hire Forth programmers who are any good (there are only a handful on the whole planet) --- your only interest in a stack-processor is so it can be a target for your C compiler that you wrote years ago (there are millions of C programmers on the planet). You think that a stack-processor will use less FPGA resources that a register-based processor --- but, you already tried this experiment and it was a failure. So, once again, what is the point? Why are you still interested in this stuff? Your company has a huge investment in the MC6808 processor. I already told you how this design could be tweaked slightly so that it would make a good target for Forth, but your C compiler would still generate code for it with only a minor modification. A hybrid C/Forth processor! My expectation was that new programs could be written in Forth (because Forth is interactive and easier to program in), and they could call C functions that have already been written, so there would be a smooth transition from C to Forth. You were totally uninterested. You were worried that the minor modification to your C compiler would break existing C programs (it wouldn't, unless C programs were accessing the return-address, which is highly non-standard). You also agreed with me that nobody other than myself would ever want to program the processor in Forth --- all C programmers hate Forth and will refuse to program in Forth, or will purposely write the most ugly and inefficient Forth code possible in order to make Forth look bad. In my design, I introduced a new stack used for return-addresses, which would be an 8-bit register, but I also said that this could be made 5-bit (32 deep) if necessary. The stack used for parameters would be 16-bit --- it already is 16-bit on the MC6808 --- Forth doesn't need such a deep data-stack, but C does, and the design is supposed to support both Forth and C so it is necessary to have the big stack in order for your legacy C programs to continue to work. So, that answers your question that you are now asking yet again --- this question has already been answered thoroughly, not just by me, but by everybody --- you need two stacks for Forth (rather than the one that C needs), but they can be pretty small (16 deep for each is a minimum, although 32 deep for the return-stack is somewhat safer, and 128 deep if you are going to support local variables). This design was the only idea I had --- it seemed like a killer idea, considering your already heavy investment in the MC6808 --- if you didn't like it though, then I don't have any other ideas for you, except perhaps to start from scratch with the Stundurd or something similar which is a pretty big undertaking.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-04 11:22 -0400 |
| Message-ID | <nt0hf4$18n4$1@gioia.aioe.org> |
| In reply to | #51594 |
On 2016-10-04 12:47 AM, hughaguilar96@gmail.com wrote: > On Monday, October 3, 2016 at 5:22:29 AM UTC-7, Walter Banks wrote: >> I am currently working on a stack processor ISA. > > What is the point of this project? > > If you want to program in Forth, you could buy RACE chips from Testra > and use my MFX that I wrote in 1994 --- or use their on-chip Forth > compiler that they wrote in MFX --- if you are going to delve into > writing your own primitives in assembly-language, then you need MFX, > but the on-chip Forth is easier to use because it is interactive (MFX > is a cross-compiler). For a implement once, mass distribution how is this important? > > But, you don't want to program in Forth! My understanding from your > emails to me is that you consider Forth to be an ugly language, and > you are well aware that it is very difficult to hire Forth > programmers who are any good (there are only a handful on the whole > planet) --- your only interest in a stack-processor is so it can be a > target for your C compiler that you wrote years ago (there are > millions of C programmers on the planet). You think that a > stack-processor will use less FPGA resources that a register-based > processor --- but, you already tried this experiment and it was a > failure. It was!! news to me. Do the design math. > > So, once again, what is the point? Why are you still interested in > this stuff? > Want to define "stuff" so I actually know what you are talking about. > Your company has a huge investment in the MC6808 processor. I already > told you how this design could be tweaked slightly so that it would > make a good target for Forth, but your C compiler would still > generate code for it with only a minor modification. A hybrid C/Forth > processor! My expectation was that new programs could be written in > Forth (because Forth is interactive and easier to program in), and > they could call C functions that have already been written, so there > would be a smooth transition from C to Forth. You were totally > uninterested. > You were worried that the minor modification to your C > compiler would break existing C programs (it wouldn't, unless C > programs were accessing the return-address, which is highly > non-standard). You also agreed with me that nobody other than myself > would ever want to program the processor in Forth --- all C > programmers hate Forth and will refuse to program in Forth, or will > purposely write the most ugly and inefficient Forth code possible in > order to make Forth look bad. > > In my design, I introduced a new stack used for return-addresses, > which would be an 8-bit register, but I also said that this could be > made 5-bit (32 deep) if necessary. The stack used for parameters > would be 16-bit --- it already is 16-bit on the MC6808 --- Forth > doesn't need such a deep data-stack, but C does, and the design is > supposed to support both Forth and C so it is necessary to have the > big stack in order for your legacy C programs to continue to work. > So, that answers your question that you are now asking yet again --- > this question has already been answered thoroughly, not just by me, > but by everybody --- you need two stacks for Forth (rather than the > one that C needs), but they can be pretty small (16 deep for each is > a minimum, although 32 deep for the return-stack is somewhat safer, > and 128 deep if you are going to support local variables). What design information do you have that determines stack size? > > This design was the only idea I had --- it seemed like a killer idea, > considering your already heavy investment in the MC6808 --- if you > didn't like it though, then I don't have any other ideas for you, > except perhaps to start from scratch with the Stundurd or something > similar which is a pretty big undertaking. > There are a lot of strawman arguments in here that are both untrue or misleading. My views on forth you expressed are certainly incorrect, and the role of the MC6808. To be clear to I will (and have) used any language that is appropriate to describe an application area. My job as always is to translate the application into executable code. Most of our C compilers are not written in C. (All but two) The MC6808 and follow on 6808 family developments 68HC08, 68S08 and RS08 were projects we did most of the work on 35 years ago. Since then we implemented about 30 C compilers and about a dozen other compilers to support various other languages. Since then I have personally been part of the design of about a dozen other commercial ISA's in diversified application areas. Most of my work has been in data flow modelling in ISA design. w..
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-04 11:44 -0700 |
| Message-ID | <ba5032ce-29ad-49c3-a122-08d517ee016f@googlegroups.com> |
| In reply to | #51606 |
On Tuesday, October 4, 2016 at 8:22:16 AM UTC-7, Walter Banks wrote: > On 2016-10-04 12:47 AM, hughaguilar96@gmail.com wrote: > > On Monday, October 3, 2016 at 5:22:29 AM UTC-7, Walter Banks wrote: > >> I am currently working on a stack processor ISA. > > > > What is the point of this project? > > > > If you want to program in Forth, you could buy RACE chips from Testra > > and use my MFX that I wrote in 1994 --- or use their on-chip Forth > > compiler that they wrote in MFX --- if you are going to delve into > > writing your own primitives in assembly-language, then you need MFX, > > but the on-chip Forth is easier to use because it is interactive (MFX > > is a cross-compiler). > > For a implement once, mass distribution how is this important? Interactive design gets a program debugged and tested faster --- this might get you to market first --- you can't actually have mass distribution until you have a working board, otherwise you waste a truckload of money, but being second to market with a working board is also a sure way to waste a truckload of money. After you have gotten a toe-hold on the market, you most likely will redesign your board to use a less-expensive chip --- when you do this, you will likely rewrite in assembly language because a lot of those small chips (the PIC18, 80c320, etc.) don't really support high-level languages very well. The nice thing about the RACE (the chip previously known as MiniForth) is that you can develop your program using the interactive on-chip Forth system and get your board working with minimal sweat-equity invested. Later on you can rewrite a lot of the Forth code in assembly-language for the second version, which will be less expensive to manufacture and have higher performance, but will involve more sweat-equity. I wrote the RACE assembler/simulator as part of MFX, and I can tell you right now that learning to use it is difficult (only one other person than myself has ever done this) --- it is an extremely low-level assembly-language (as compared to PIC18 or 80c320 assembly-language) --- this is not something that you want to delve into until you can be reasonably sure that there is money to be made. If there is no money to be made, you might as well devote your life to playing Go --- that is also mind-blowingly difficult --- it is fun though, and you get to meet interesting people from around the world, neither of which is true of becoming the world's third RACE assembly-language programmer.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web