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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> |
|---|---|
| Date | 2016-10-04 16:15 -0400 |
| Message-ID | <20161004161527.4f266f33@_> |
| In reply to | #51604 |
On Tue, 4 Oct 2016 10:36:36 -0400 Walter Banks <walter@bytecraft.com> wrote: > As several people here have pointed out C requires "..." Many C compilers have limitations and poorly implemented features. IIRC, PCC didn't implement structs correctly, and GCC doesn't implement 'register' declared variables correctly. GCC implements all sorts of extensions to the language. TenDRA was supposedly very pedantic, but it didn't implement tail calls. And, so on ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-11-09 09:56 -0800 |
| Message-ID | <9eb6a316-af32-48d4-9952-a59a7c28ff97@googlegroups.com> |
| In reply to | #51604 |
On Tuesday, October 4, 2016 at 7:36:40 AM UTC-7, Walter Banks wrote: > On 2016-10-03 7:28 PM, Paul Rubin wrote: > 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. > Maybe you should talk to Leon Wagner at FORTH Inc. They have a SwiftX Pro version with a 32-bit soft CPU, called the SC20. The SC20 is kind of like a mini SHBOOM with a rather classical programming model. The optimizer doesn't really have to do much, as it's translating Forth to Forth. The licensing terms are pretty simple: The VHDL is bundled with the SwiftX license. It's maybe 50% slower than the fastest Forth CPUs (like the J1) in FPGAs due to muxes in the data paths. But, the ISA has high semantic density so I think it would compare favorably to the other stack machines out there. I designed it as a hobby while I was working for a chip company, so it's intended to be ASIC friendly. In regards to stack sizes, it uses small stack caches (8 or 16 cells each) that automatically spill/refill. You can see slides from the 2010 Forth Day presentation here: http://www.forth.org/svfig/kk/11-2010-Wagner&Eckert.pdf It's a little skimpy on support packages. I'll probably take that up in 2017 as I'll be using the SC20 in projects.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-11-12 09:15 -0500 |
| Message-ID | <o0786o$1650$1@gioia.aioe.org> |
| In reply to | #52488 |
On 2016-11-09 12:56 PM, Brad Eckert wrote: > On Tuesday, October 4, 2016 at 7:36:40 AM UTC-7, Walter Banks wrote: >> On 2016-10-03 7:28 PM, Paul Rubin wrote: 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. >> > Maybe you should talk to Leon Wagner at FORTH Inc. They have a > SwiftX Pro version with a 32-bit soft CPU, called the SC20. The SC20 > is kind of like a mini SHBOOM with a rather classical programming > model. The optimizer doesn't really have to do much, as it's > translating Forth to Forth. The licensing terms are pretty simple: > The VHDL is bundled with the SwiftX license. > > It's maybe 50% slower than the fastest Forth CPUs (like the J1) in > FPGAs due to muxes in the data paths. But, the ISA has high semantic > density so I think it would compare favorably to the other stack > machines out there. I designed it as a hobby while I was working for > a chip company, so it's intended to be ASIC friendly. In regards to > stack sizes, it uses small stack caches (8 or 16 cells each) that > automatically spill/refill. You can see slides from the 2010 Forth > Day presentation here: > http://www.forth.org/svfig/kk/11-2010-Wagner&Eckert.pdf > > It's a little skimpy on support packages. I'll probably take that up > in 2017 as I'll be using the SC20 in projects. > Thanks for posting the slide set describing SC20. It is pretty much as described and would be competitive with many of the 32 bit processors out there. One thing that I have discovered looking at many ISA's has been the designers often panic during the design process when they find a sequence that is particularly inefficient. They fix the sequence with ISA changes that have small amounts of almost invisible loss of bit efficiency or higher execution times. Many cases they would be better off taking the efficiency hit on rarely used corner cases. In designing an ISA it is important to have a very good understanding of the intended applications. One of the processors that I worked on the ISA and wrote a supporting tool set we actually wrote two code generators targeting different application area's. We actually ship both variations of the compiler either will compile code intended for the other application area the difference is the 2 or 3% difference in code size and execution time. It was this project that we started looking at formalized approaches early strategy passes in the compiler extracting data and control flow as being almost as important as comprehensive optimization. w..
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-03 10:35 -0500 |
| Message-ID | <nsttrc$2bp$1@dont-email.me> |
| In reply to | #51569 |
On 10/3/2016 9: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. > > YMMV > > BF > C.H. Tings ep16 Forth CPU is available from forth.org it contains VHDL source, a custom version of eForth that is resident, and documentation on both the VHDL code and the eForth code. The special eForth version is easily modifiable to work for other CPUs. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2016-10-11 01:01 +0000 |
| Message-ID | <nthdlr$guj$2@dont-email.me> |
| In reply to | #51569 |
Am Mon, 03 Oct 2016 07:00:39 -0700 schrieb foxaudioresearch: > You can study some of the current Forth style stack machines like B16 or > J1 to see what others have done. b16's stack sizes are simply configurable in powers of two. I used different sizes for different projects; but either 8 or 16 usually were "big enough" for my projects. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-03 10:21 -0400 |
| Message-ID | <nstphb$hbj$2@dont-email.me> |
| In reply to | #51568 |
On 10/3/2016 8:22 AM, 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? Yes. 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. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-03 11:06 -0400 |
| Message-ID | <nsts6g$rbi$1@gioia.aioe.org> |
| In reply to | #51570 |
On 2016-10-03 10:21 AM, rickman wrote: > On 10/3/2016 8:22 AM, 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? > > Yes. > > 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. > I have a couple metrics that are useful. We ran several hundred actual applications through an analysis package we wrote and found the maximum stack depth in the real applications to be 13 (In about a half dozen of the applications) We did a recursion study of many applications with an instrumented compiler. In the same group of programs and a whole bunch more we found that recursion in real code was needed very rarely. Most code that is written with recursion either through a chain of functions or a recursive function can be optimized by a reasonable compiler to not need recursion. I don't have any specific metrics but I haven't seen any expressions that have required more than 4 levels of data stack to process. It guess that it depends on what? w..
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-03 15:22 -0400 |
| Message-ID | <nsub5v$lvl$1@dont-email.me> |
| In reply to | #51571 |
On 10/3/2016 11:06 AM, Walter Banks wrote: > On 2016-10-03 10:21 AM, rickman wrote: >> On 10/3/2016 8:22 AM, 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? >> >> Yes. >> >> 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. >> > > I have a couple metrics that are useful. We ran several hundred actual > applications through an analysis package we wrote and found the maximum > stack depth in the real applications to be 13 (In about a half dozen of > the applications) You never said what language you are using. Should I assume Forth? I know in C programs the stack usage can be many, many kilobytes if not megabytes. > We did a recursion study of many applications with an instrumented > compiler. In the same group of programs and a whole bunch more we found > that recursion in real code was needed very rarely. Most code that is > written with recursion either through a chain of functions or a > recursive function can be optimized by a reasonable compiler to not need > recursion. I've never met a compiler I thought was truly reasonable. > I don't have any specific metrics but I haven't seen any expressions > that have required more than 4 levels of data stack to process. > > It guess that it depends on what? Yes, it definitely depends on "what". -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-03 18:04 -0400 |
| Message-ID | <nsukl5$br5$1@gioia.aioe.org> |
| In reply to | #51579 |
On 2016-10-03 3:22 PM, rickman wrote: > On 10/3/2016 11:06 AM, Walter Banks wrote: >> On 2016-10-03 10:21 AM, rickman wrote: >>> On 10/3/2016 8:22 AM, 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? >>> >>> Yes. >>> >>> 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. >>> >> >> I have a couple metrics that are useful. We ran several hundred >> actual applications through an analysis package we wrote and found >> the maximum stack depth in the real applications to be 13 (In >> about a half dozen of the applications) > > You never said what language you are using. Should I assume Forth? I > know in C programs the stack usage can be many, many kilobytes if not > megabytes. I haven't said what language for a variety of reasons. C for example in many implementations don't always have a data stack to work with and don't always use it when they have. Forth is in some ways a special case in terms of language implementation. The ISA I am working on has some similarities to some forth ISA's. >> We did a recursion study of many applications with an instrumented >> compiler. In the same group of programs and a whole bunch more we >> found that recursion in real code was needed very rarely. Most >> code that is written with recursion either through a chain of >> functions or a recursive function can be optimized by a reasonable >> compiler to not need recursion. > > I've never met a compiler I thought was truly reasonable. :) Probably the best argument for compiled code is compilers get to start over every time they are called to make code generation choices and hand code gets to evolve living with some historical artifacts over time. w..
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2016-10-04 20:46 +0200 |
| Message-ID | <57f3f915$0$875$e4fe514c@news.xs4all.nl> |
| In reply to | #51570 |
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 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
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-04 15:40 -0400 |
| Message-ID | <nt10k9$61u$1@gioia.aioe.org> |
| In reply to | #51610 |
On 2016-10-04 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 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. My understanding of 4TH is it compiles to an intermediate H code that can interpreted / compiled on a variety of targets if I have been looking at the correct website. I am an old UCSD pascal fan as well. One and two stacks have been what we have been doing most of our simulations with. I quickly at one point looked at the implications of three stacks (return, and two data) The idea that we could code up a tree type expression evaluation. What I found and it maybe the mix of regression tests we created from applications was we generated slightly faster and smaller code a single stack than we could with two stacks. Our three stack solution had no advantages over the two or single stack solution. One interesting thing that has come out of this thread is there is some consistency with about 12 levels needed for subroutine return. (Totally consistent with our metrics of 13 levels for actual applications) Data stacks have produced a different set of comments. In part is the roles that data stacks are used for. Local variables, expression evaluation and saving machine state for interrupts or event programming applications. Local variables are the wild card in this. They can in some languages be quite large. Expression evaluation is a more manageable problem to evaluate. I had expected that data stack requirements for forth applications could easily be larger than that used by other languages and approaches to expression evaluation. I may not be looking in the right place but essentially all the forth code that I have looked at had similar metrics to code created by other approaches. 4 or 5 data stack levels in applications was about the limit we have seen for expression evaluation. If the 8 level comment you made above is mostly about expression evaluation then that is close to what we have found in the 4 or 5 level metrics we keep seeing in our tests. What I haven't seen is anyone pointing to an application area that any particular language that gains performance by using more stack space which has been a surprise. w..
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-05 12:26 -0700 |
| Message-ID | <b21bd81e-a189-4abd-a931-197e3653caa7@googlegroups.com> |
| In reply to | #51613 |
On Tuesday, October 4, 2016 at 12:41:00 PM UTC-7, Walter Banks wrote: > On 2016-10-04 2:46 PM, Hans Bezemer wrote: > > 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. > > My understanding of 4TH is it compiles to an intermediate H code that > can interpreted / compiled on a variety of targets if I have been > looking at the correct website. I am an old UCSD pascal fan as well. This is what Java does with its JVM --- define a VM that is simulated on a variety of different target processors --- I don't think this is a good idea because you are interpreting opcodes at run-time when this work should be done at compile-time (JIT supposedly works around this problem, but it is complicted, and you are still doing work at run-time that could have been done at compile-time). I've pretty much moved on from the Stundurd idea. My new idea is the "hugh-niversal assembler." This is an assembly-language for a hypothetical Forth-centric processor. Different versions of the assembler will generate machine-code for different target processors. The Forth compiler will be a traditional STC Forth that uses a built-in Forth assembler to generate the code. By switching out the assembler however, the same compiler can be retargeted to different targets without needing to be rewritten. In some cases, the hypothetical processor will be less powerful than the actual processor, in which case the actual processor will not be used to its full potential. For example, the actual processor may have more registers than the hypothetical processor, in which case these extra registers won't get used (an example would be the PIC24 with 20 registers). In some cases, the hypothetical processor will be more powerful than the actual processor, in which case some instructions will assemble into multiple machine-code instructions, or possibly into a subroutine call. For example, the actual processor may have fewer registers than the hypothetical processor, in which case some registers will have to be memory variables (an example would be the MC6812 with 4 registers). The hypothetical processor is a pretty close match to the 16-bit x86, so anybody who has written an MS-DOS Forth compiler using an 8086 Forth assembler should be able to easily port it over to use the hugh-niversal Forth assembler. The 80186 was a terrible micro-controller 25 years ago, and it is totally obsolete now --- that was because it had too much interrupt latency, and it was slow as molasses --- these problems aren't inherent in the design however; the hugh-niversal assembler should generate code for the PIC24 that is almost as fast as code written in PIC24 assembly-language. Here is an excerpt from my document: ---------------------------------------------------------------------------- Anton Ertl's PAF (Portable Assembler for Forth) has major problems: 1.) His PAF is for 32-bit processors. This makes no sense, as the ARM is used in maybe 99% of all 32-bit micro-controllers (the MIPS, ColdFire, etc. make up the remainder) --- he should just write his Forth in ARM assembly-language if he wants portability in the 32-bit world. 2.) He believes that the register set size can be abstracted away. This is not true --- the number of registers is the one thing that has to be fixed --- a big part of designing any Forth system is dedicating the registers to specific uses, and the designer needs to know how many registers he has in order to do this. 3.) He considers abstracting away the register set size to be his primary goal --- to accomplish this, he is removing features from Forth that get in the way of this misguided goal --- when (if) he gets PAF to work, his Forth will be crippled. 4.) He still doesn't want lambda functions to be added to Forth --- so for all of his effort, the final result will still just be a typical lame Forth --- the lack of lambda functions has always been Forth's greatest weakness. 5.) He seems to have no concern at all for efficiency. Gforth was utterly useless for micro-controller programming --- his goal with Gforth was portability, but Gforth was so slow that it was never used in any commercial application, so there are no programs to port --- PAF will be more of the same. The idea for HUGHasm came from PAF, but HUGHasm is different in every way --- HUGHasm is a design that makes sense in the real-world of commercial micro-controllers; it is not an academic exercise like PAF. ---------------------------------------------------------------------------- > One and two stacks have been what we have been doing most of our > simulations with. I quickly at one point looked at the implications of > three stacks (return, and two data) The idea that we could code up a > tree type expression evaluation. > > What I found and it maybe the mix of regression tests we created from > applications was we generated slightly faster and smaller code a single > stack than we could with two stacks. > > Our three stack solution had no advantages over the two or single stack > solution. I have Straight Forth that has multiple stacks, but it is for 64-bit desktop-computers; it is not for micro-controllers. Here is an excerpt from my document: ---------------------------------------------------------------------------- In a function, there are several places to hold data: single-stack --- This called the "data-stack" in ANS-Forth etc.. double-stack --- This is where double-precision numbers, ratios and BFIs are held. float-stack --- This is where floats are held. string-stack --- This is where strings are held (strings can also be held on the single-stack). return-stack --- This is used for temporarily holding data inside of functions. This can't be used for passing data into functions. user registers --- These are the VEC PTR CNT and REG registers. PTR CNT and VEC are used by HOFs for iteration, and REG is general-purpose. local variables --- These are used for temporarily hoding data inside of functions. They can't be used for passing data into functions, although they can be used for passing data into and out of quotations. The single-stack is the fundamental working-storage for Straight Forth; the same as in ANS-Forth and all other Forths. We have DUP OVER SWAP ROT etc. for juggling the values on the single-stack. We have + - * / etc. for doing arithmetic on single-precision numbers on the single-stack. Double-precision numbers and ratios are held on the double-stack. We have DDUP DOVER DSWAP DROT etc. for juggling the values on the double-stack. We have D+ D- D* D/ etc. for doing arithmetic on double-precision numbers on the double-stack. We have RAT+ RAT- RAT* RAT/ etc. for doing arithmetic on ratios on the double-stack. Mixed-precision arithmetic will move data from one stack to another. For example, S>D pops a value from the single-stakc and pushes it to the double-stack as a double-precision number. Similarly, M* pops two values from the single-stack and pushes their product to the double-stack, and M/ pops the numerator from the double-stack and pops the denominator from the single-stack and pushes the quotient to the single-stack. Also, S>RAT pops a value from the single-stack and pushes it to the double-stack as a ratio, whereas RAT>S pops a ratio from the double-stack and pushes it as a quotient to the single-stack. All the numbers on the single-stack (in the Fixed version) are effectively ratios that always have a denominator of 2^32 (unity). ---------------------------------------------------------------------------- > One interesting thing that has come out of this thread is there is some > consistency with about 12 levels needed for subroutine return. (Totally > consistent with our metrics of 13 levels for actual applications) I said 16, but only because 8 seemed to be too small --- 12 should be okay. In Straight Forth the float-stack is only 8 deep --- this was done because the most likely target processor will be the 64-bit x86 that has an 8-deep float-stack in hardware --- this is pretty small, so the programmer is encouraged to hold floats in local variables rather than leave them on the float-stack (note that in Straight Forth any data type can be stored in local variables). The other stacks are plenty big, so the programmer never has to worry about overflow. The data-stack is gigantic --- this is mostly done to allow C functions to be called. Straight Forth is for desktop computers. A micro-controller Forth would not have so many stacks. I think a single and a double stack would be sufficient for data (micro-controllers don't work with strings or float very much). A 16-bit micro-controller is going to work with double-precision integers or ratios though (because 16-bit integers don't provide enough precision) --- so a double-stack is worthwhile --- maybe not though, as all the data coming in from ADC ports or going out DAC ports is 16-bit (maybe only 12-bit). I don't really have enough experience with micro-controllers to design a Forth standard for micro-controllers --- also, I'm dubious that a standard is needed, because the programs aren't going to be portable anyway due to being tightly tied to the I/O --- Mark Wills thinks that I/O can be abstracted out and standardized, and he has more experience with micro-controllers than I do, so maybe he is right. > What I haven't seen is anyone pointing to an application area that any > particular language that gains performance by using more stack space > which has been a surprise. I agree that there aren't many applications that benefit from having big stacks --- certainly not in micro-controllers --- maybe occasionally in desktop-computer programs that do recursive-descent searches. My N-Queens program dumps all of the data onto the data-stack --- this requires a big stack --- a better technique though would be to dump this into a linked-list. Also, in the novice-package I have functions that take variable numbers of parameters on the data-stack (with a zero sentinel underneath the valid data) --- these may work with dozens of data --- once again though, it could be argued that this data should be in a linked-list.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-05 15:44 -0500 |
| Message-ID | <nt3om1$8rj$1@dont-email.me> |
| In reply to | #51627 |
On 10/5/2016 2:26 PM, hughaguilar96@gmail.com wrote: > I've pretty much moved on from the Stundurd idea. My new idea is the "hugh-niversal assembler." This is an assembly-language for a hypothetical Forth-centric processor. Different versions of the assembler will generate machine-code for different target processors. The Forth compiler will be a traditional STC Forth that uses a built-in Forth assembler to generate the code. By switching out the assembler however, the same compiler can be retargeted to different targets without needing to be rewritten. > > In some cases, the hypothetical processor will be less powerful than the actual processor, in which case the actual processor will not be used to its full potential. For example, the actual processor may have more registers than the hypothetical processor, in which case these extra registers won't get used (an example would be the PIC24 with 20 registers). > > In some cases, the hypothetical processor will be more powerful than the actual processor, in which case some instructions will assemble into multiple machine-code instructions, or possibly into a subroutine call. For example, the actual processor may have fewer registers than the hypothetical processor, in which case some registers will have to be memory variables (an example would be the MC6812 with 4 registers). > > The hypothetical processor is a pretty close match to the 16-bit x86, so anybody who has written an MS-DOS Forth compiler using an 8086 Forth assembler should be able to easily port it over to use the hugh-niversal Forth assembler. The 80186 was a terrible micro-controller 25 years ago, and it is totally obsolete now --- that was because it had too much interrupt latency, and it was slow as molasses --- these problems aren't inherent in the design however; the hugh-niversal assembler should generate code for the PIC24 that is almost as fast as code written in PIC24 assembly-language. > > Here is an excerpt from my document: > The idea for HUGHasm came from PAF, but HUGHasm is different in every way --- HUGHasm is a design that makes sense in the real-world of commercial micro-controllers; it is not an academic exercise like PAF. > ---------------------------------------------------------------------------- Interesting, on and off I have worked on a project using a funky virtual machine but somewhat different from your idea. The Forth compiler generates an internal form, basically micro-primitives, it takes several micro-primitives do do simple operations such a DUP, SWAP, + etc. many of those micro-primitives translate to a single instruction on a decent CPU. Here is where I take a turn in a different direction, before the assembler generates the code for the CPU an optimizer steps in and looks for patterns of micro-primitives, if a match is found then a simpler pattern replaces the old pattern, these substitutions are directed by a template file that specifies how to optimize the code. After the optimizer is finished the code is handed over to the assembler that generates actual machine code for a specific CPU. I have experimented with limited versions and it works quite well, the assembler which translates the optimized micro-primitives has intimate knowledge of the CPU and generates quite good code, the optimizer has improved the micro primitives and simplified complex operations. When changing to a new CPU one changes the assembler, and may optionally change some of the templates to take special advantage of the target CPU but overall little changes take place. It seems complicated, the optimizer is the bear in this setup but it can be quite fast and once done it set, the payoff is the generated code which tends to be quite good, so running efficiency is the target of the scheme. Over the years I have had computers come and go so some of my test code was lost but I want to resurrect it again, I have not forgotten the basics on what was done, and now I'm getting close to settling down on my Forth software setup so it will soon time to give it a go again. The main thrust is for use with embedded CPUs, the non-ARM variety for that I leave it to MPE. Lately I have developed a resurgent interest in old CPUs CDP1802, 6502, 6809, Z80, and new FPGA ones, right now it's CDP1802 time. I'm not a fan of Intel 386 assembler so for PC's I'll stick to my MPE VFX 7 Pro. compiler. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-05 16:32 -0700 |
| Message-ID | <60e003f5-ea51-42d2-a1cc-0479c25e2870@googlegroups.com> |
| In reply to | #51629 |
On Wednesday, October 5, 2016 at 1:44:00 PM UTC-7, Cecil - k5nwa wrote: > Interesting, on and off I have worked on a project using a funky virtual > machine but somewhat different from your idea. > > The Forth compiler generates an internal form, basically > micro-primitives, it takes several micro-primitives do do simple > operations such a DUP, SWAP, + etc. many of those micro-primitives > translate to a single instruction on a decent CPU. > > Here is where I take a turn in a different direction, before the > assembler generates the code for the CPU an optimizer steps in and looks > for patterns of micro-primitives, if a match is found then a simpler > pattern replaces the old pattern, these substitutions are directed by a > template file that specifies how to optimize the code. After the > optimizer is finished the code is handed over to the assembler that > generates actual machine code for a specific CPU. That doesn't diverge very much from my design. I was thinking of having multiple versions of each instruction, each with a different configuration in regard to how many of the top stack items (0, 1 or 2) are expected in registers and how many (0, 1 or 2) are returned in registers. You are thinking of having a single version of each instruction, and then having a peephole optimizer in the assembler fix them up internally so they pass values in registers rather than push a value to memory and immediately pop it out of memory Either way, this is peephole optimization --- I have the compiler doing it --- you have the assembler doing it. Your method might be better. For one thing, the target processor may not have very many registers, in which case you make the assembler only support 0 or 1 top items in registers, rather than 0, 1 or 2. OTOH, your method puts the complexity in the assembler rather than the compiler --- this is a disadvantage because the assembler has to be rewritten for every new target --- if the complexity is in the compiler, then it gets written once, but doesn't have to get rewritten again. SwiftForth code is always good for a laugh: : init-list ( node -- node ) 0 over ! ; ok see init-list 478F0F 4 # EBP SUB 83ED04 478F12 EBX 0 [EBP] MOV 895D00 478F15 0 # EBX MOV BB00000000 478F1A 4 # EBP SUB 83ED04 478F1D EBX 0 [EBP] MOV 895D00 478F20 4 [EBP] EBX MOV 8B5D04 478F23 0 [EBP] EAX MOV 8B4500 478F26 EAX 0 [EBX] MOV 8903 478F28 4 [EBP] EBX MOV 8B5D04 478F2B 8 # EBP ADD 83C508 478F2E RET C3 ok see over 405C5F 4 # EBP SUB 83ED04 405C62 EBX 0 [EBP] MOV 895D00 405C65 4 [EBP] EBX MOV 8B5D04 405C68 RET C3 ok see ! 40572F 0 [EBP] EAX MOV 8B4500 405732 EAX 0 [EBX] MOV 8903 405734 4 [EBP] EBX MOV 8B5D04 405737 8 # EBP ADD 83C508 40573A RET C3 ok All that SwiftForth does is inline primitives' code rather than compile a CALL to it --- here a literal number (0) is pasted in, then OVER is pasted in, then ! is pasted in --- there is no peephole-optimization being done.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-05 20:01 -0400 |
| Message-ID | <nt448q$eig$1@dont-email.me> |
| In reply to | #51636 |
On 10/5/2016 7:32 PM, hughaguilar96@gmail.com wrote: > On Wednesday, October 5, 2016 at 1:44:00 PM UTC-7, Cecil - k5nwa > wrote: >> Interesting, on and off I have worked on a project using a funky >> virtual machine but somewhat different from your idea. >> >> The Forth compiler generates an internal form, basically >> micro-primitives, it takes several micro-primitives do do simple >> operations such a DUP, SWAP, + etc. many of those micro-primitives >> translate to a single instruction on a decent CPU. >> >> Here is where I take a turn in a different direction, before the >> assembler generates the code for the CPU an optimizer steps in and >> looks for patterns of micro-primitives, if a match is found then a >> simpler pattern replaces the old pattern, these substitutions are >> directed by a template file that specifies how to optimize the >> code. After the optimizer is finished the code is handed over to >> the assembler that generates actual machine code for a specific >> CPU. > > That doesn't diverge very much from my design. > > I was thinking of having multiple versions of each instruction, each > with a different configuration in regard to how many of the top stack > items (0, 1 or 2) are expected in registers and how many (0, 1 or 2) > are returned in registers. That would need to be supported by the CPU directly, no? In essence the CPU would have to know how many stack items are in registers and call the appropriate microcode to execute the appropriate primitive. Otherwise how would the compiler know what to expect when a word is compiled into another word? Given that any word can be called my a number of other words, how can a compiler know what is happening at run time? I'm not entirely clear on the context of this use of stack caching. Normally this is a technique used to facilitate the use of multiple registers in a standard CPU. The trick is to know when to adjust the stack item count in registers and when such an adjustment would be counter productive. It would not be unreasonable to keep in registers more items than typically needed by any one word and only adjust when required. So hysteresis could facilitate this. If a stack push is needed when the register count is already at max does a flush of n items. A stack pop when the register usage count is at the minimum does a cache fill. But how can a standard CPU know when to do this? Either the CPU needs to have hardware support for this, which standard CPUs don't have, or extra instructions are required for every stack operation to check the register usage count. Am I missing something? If stack caching doesn't always keep the same number of items in registers, how can a standard CPU keep track of when to fill and flush? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-07 07:39 +0000 |
| Message-ID | <2016Oct7.093908@mips.complang.tuwien.ac.at> |
| In reply to | #51637 |
rickman <gnuarm@gmail.com> writes:
>On 10/5/2016 7:32 PM, hughaguilar96@gmail.com wrote:
>> I was thinking of having multiple versions of each instruction, each
>> with a different configuration in regard to how many of the top stack
>> items (0, 1 or 2) are expected in registers and how many (0, 1 or 2)
>> are returned in registers.
>
>That would need to be supported by the CPU directly, no? In essence the
>CPU would have to know how many stack items are in registers and call
>the appropriate microcode to execute the appropriate primitive.
>Otherwise how would the compiler know what to expect when a word is
>compiled into another word?
If you do it in the compiler (static stack caching), you typically
have a canonical stack state, and force the stack representation into
this state at the start of a definition and at other places where you
would otherwise get problems. Gforth returns to the canonical state
(one stack item in a register) at every basic block boundary (branch,
branch target). For straight-line code, the compiler always knows in
which state the previous VM instruction ended and can compile the
appropriate version of the current VM instruction. For more on that,
read [ertl&gregg05].
If you do it in the VM interpreter (dynamic stack caching), every VM
instruction knows at which state it ends, and jumps to the version of
the next VM instruction for that state (similar to what you describe
for a microcoded CPU). In that case the compiler does not need to be
aware of stack caching. For more on that, read [ertl95].
@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"
}
@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 | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-05 20:36 -0500 |
| Message-ID | <nt49pn$i9j$1@dont-email.me> |
| In reply to | #51636 |
On 10/5/2016 6:32 PM, hughaguilar96@gmail.com wrote: > On Wednesday, October 5, 2016 at 1:44:00 PM UTC-7, Cecil - k5nwa wrote: >> Interesting, on and off I have worked on a project using a funky virtual >> machine but somewhat different from your idea. >> >> The Forth compiler generates an internal form, basically >> micro-primitives, it takes several micro-primitives do do simple >> operations such a DUP, SWAP, + etc. many of those micro-primitives >> translate to a single instruction on a decent CPU. >> >> Here is where I take a turn in a different direction, before the >> assembler generates the code for the CPU an optimizer steps in and looks >> for patterns of micro-primitives, if a match is found then a simpler >> pattern replaces the old pattern, these substitutions are directed by a >> template file that specifies how to optimize the code. After the >> optimizer is finished the code is handed over to the assembler that >> generates actual machine code for a specific CPU. > > That doesn't diverge very much from my design. > > I was thinking of having multiple versions of each instruction, each with a different configuration in regard to how many of the top stack items (0, 1 or 2) are expected in registers and how many (0, 1 or 2) are returned in registers. > > You are thinking of having a single version of each instruction, and then having a peephole optimizer in the assembler fix them up internally so they pass values in registers rather than push a value to memory and immediately pop it out of memory > > Either way, this is peephole optimization --- I have the compiler doing it --- you have the assembler doing it. > > Your method might be better. For one thing, the target processor may not have very many registers, in which case you make the assembler only support 0 or 1 top items in registers, rather than 0, 1 or 2. > > OTOH, your method puts the complexity in the assembler rather than the compiler --- this is a disadvantage because the assembler has to be rewritten for every new target --- if the complexity is in the compiler, then it gets written once, but doesn't have to get rewritten again. > The optimizer is not built into the assembler its a separate entity, it remains the same no matter what chip you use, it uses an external file with templates, if you want to add additional optimization you add it to the templates, the optimizer itself is not changed. Basically the compiler bundles a word definition and all that it contains and send it to the optimizer, it rearranges the code and sends it to the assembler, the assembler generates the code, it knows the internal details to generate efficient code, but it still is fairly simple. Code that is inline between code definitions is bundles and sent to the optimizer to optimize before working again on the next word definition. Anyway, I had it working very well many years ago, and it supported a multitude of CPUs but, that was a long time ago and it is lost, I would like to re-create it again in the not too distant future. The part that is fairly difficult is the optimizer, it generally a very powerful and flexible macro processor, that is difficult to do efficiently, I used to use a balanced link list to speed up the searching. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-05 21:28 -0700 |
| Message-ID | <70af2adb-dc65-4f2c-9a76-71cf87125e8a@googlegroups.com> |
| In reply to | #51639 |
On Wednesday, October 5, 2016 at 6:36:06 PM UTC-7, Cecil - k5nwa wrote: > On 10/5/2016 6:32 PM, hughaguilar96@gmail.com wrote: > > Your method might be better. For one thing, the target processor may not have very many registers, in which case you make the assembler only support 0 or 1 top items in registers, rather than 0, 1 or 2. > > > > OTOH, your method puts the complexity in the assembler rather than the compiler --- this is a disadvantage because the assembler has to be rewritten for every new target --- if the complexity is in the compiler, then it gets written once, but doesn't have to get rewritten again. > > > > The optimizer is not built into the assembler its a separate entity, it > remains the same no matter what chip you use, it uses an external file > with templates, if you want to add additional optimization you add it to > the templates, the optimizer itself is not changed. If the optimizer is not built into the assembler, and only the assembler contains target-specific information, then we haven't diverged at all --- you already are using the same method that I'm using. As I said above though, the disadvantage of this is that the number of registers in the hypothetical processor is fixed --- this will be the same no matter how many registers the target processor has. I also said, in that excerpt: "[Anton Ertl] believes that the register set size can be abstracted away. This is not true --- the number of registers is the one thing that has to be fixed --- a big part of designing any Forth system is dedicating the registers to specific uses, and the designer needs to know how many registers he has in order to do this." I said: "I was thinking of having multiple versions of each instruction, each with a different configuration in regard to how many of the top stack items (0, 1 or 2) are expected in registers and how many (0, 1 or 2) are returned in registers." Michael Barry said that having all of these primitives is not necessary. He recommended that the primitives do this at run-time. He said that the top value of the data-stack would always be held in a registers (the TOS register) and the second value of the data-stack may or may not be held in a register (the SOS register). There would be a flag that would indicate TRUE if SOS was popped or FALSE if it the second value was in memory: 1.) If a primitive (a "consumer") needs SOS then it checks the flag at the beginning and pops SOS from memory if the flag is FALSE. 2.) If a primitive (a "producer") needs SOS in memory then it checks the flag at the beginning and pushes SOS to memory if the flag is TRUE. 3.) Either way, the primitive sets the flag at the end to indicate if SOS is popped or if the second value is in memory. A "producer" is a primitive that leaves more data on the data-stack (LIT and OVER etc.) and a "consumer" is a primitive that leaves less data on the data-stack (+ and DROP etc.). I got the terms "producer" and "consumer" from ISYS Forth (for the Apple-IIc) which did peephole-optimization. The programmer (I think his name was Robert Illyes) said that Forth code mostly alternates producers and consumers, which is why the stack never gets very deep. His code optimizer allowed the Y:A register-pair to be used to pass the TOS from one primitive to the next when possible, although all of the stack was in memory nominally. I won't go into all the details here because the 65c02 is not something that people care about nowadays. I will say that his code optimizer was quite good! My own 65c02 cross-compiler was essentially just ISYS Forth except that it ran on an MS-DOS machine and was written in UR/Forth and generated 65c02 machine-code, but it was compatible with ISYS in every way. Michael Barry got this idea of the SOS-valid flag from some old processor from the 1960s (maybe a Burroughs). Unfortunately I can't find the thread in which he discussed this. I did find a thread in which Bernd Linsel supported Michael Barry's idea: https://groups.google.com/forum/#!searchin/comp.lang.forth/Michael$20optimization%7Csort:date/comp.lang.forth/n5mkONylBBs/RdMW_nOkCwAJ In this thread I said: On Sunday, October 11, 2015 at 10:14:30 PM UTC-7, hughag...@gmail.com wrote: > On Sunday, October 11, 2015 at 9:12:03 AM UTC-7, Bernd Linsel wrote: > > Your idea of having several stack configurations (SOS valid or not) > > in order to simplify compiler optimization is not bad, although, as > > you mention in 19.5. Michael Barry's suggestion, the processor itself > > can decide if it is necessary to huff or puff before a primitive, as > > it always can track the validity of SOS. > > Yes. I'm really thinking that I should just go with Michael's suggestion and get rid of all the redundancy. Right now I'm holding off until I can talk to hardware designer and find out if it is possible for microcode to branch. On the MiniForth I was told that branching was very expensive to implement, and I was required to write all of the primitives without any branching --- I'm assuming the same limitation for the Stundurd --- the MiniForth was 20 years ago though, and this limitation may no longer be an issue. Here is section 19.5 from the Stundurd document that Bernd Linsel is referencing: ============================================================================ section 19.5) an interesting suggestion Michael Barry says this: ---------------------------------------------------------------------------- In the simplest FMITE, I believe there are two internal states for the parameter stack: huffed and puffed. If the FMITE keeps an internal flag that keeps track of this, it can insert a huff or puff automatically BEFORE the currently decoded instruction, but only if the current state is wrong for that particular instruction. Latency would be a maximum of a single huff or puff, and would usually be zero. By putting this atomic latency in its own clock slot (BEFORE the current instruction, not AFTER), the maximum clock speed wouldn't hardly suffer at all. All of your mnemonics that have a suffix like 01, 12, 21, could be consolidated into a single op-code and mnemonic with no suffix, because the cpu would know by the current state and the op-code it has just decoded whether or not it will have to insert a one cycle delay to huff or puff. HUFF01, HUFF12, and PUFF21 could be completely eliminated from the op-code matrix, because they would be internalized, and only used as dictated by the current instruction stream. There would be no need to worry about leaving the processor in any given huff/puff state after any instruction or exit (or interrupt, for that matter), because any necessary state changes would be handled by the cpu when the following instruction is fetched and decoded. I believe that some of the Burroughs mainframes were doing this 50 years ago, so it's a proven strategy. The best analogy that comes to mind is a manual transmission vs. an automatic: your assembly code examples expend a lot of effort to keep all the huffers and puffers in harmony by manually clutching and shifting gears (states) as needed. You don't have to upshift or downshift an automatic, you just put it in "drive" and let it decide the best gear for the circumstances. In my experience, it usually makes the most efficient choice for the given road (instruction stream), unless it's broken. And you don't have to worry about spilling your coffee or dropping your cigarette by having to reach for the gearshift in traffic. It should also be possible to get the compiler to recognize and favor more efficient sequences (like NIP DROP instead of DROP DROP, so the cpu doesn't have to work so hard automatically huffing and puffing). ---------------------------------------------------------------------------- Michael Barry is a professional auto-mechanic, which is presumably why his explanation concluded with an automobile analogy. As an historical note, Henry Ford originally wanted an automatic transmission because he didn't believe that the average American was capable of learning how to operate a clutch, and he expected that if only a manual transmission were offered then automobiles would only be purchased by "gear heads" (the term for technology enthusiasts in the early 20th century), whereas the common people would continue to use horses. Unfortunately, his engineers informed him that the automatic-transmission technology was not ready for prime-time yet, so he had to go with a manual transmission. The people managed, although 50 years later when automatic-transmissions were introduced everybody jumped on the technology as they apparently had had quite enough of spilling their coffee and dropping their cigarettes. Michael programs as a hobby, mostly in 6502 assembly language for retro computers from the 1980s. His idea is pretty good. There would be a one-bit register flag (lets call it SV for "SOS valid") that would be set to TRUE if SOS has the second-on-stack value in it or set to FALSE if SOS is invalid. Each primitive would set SV appropriately when it concluded. Most of the primitives would also examine SV before beginning, and either huff a datum into SOS or puff a datum out of SOS depending upon which they need. Some primitives, such as LIT-PLUS don't care if SOS is valid or not because they only work with TOS and so they would ignore SV and leave it as-is for the next primitive to worry about. The advantage of this scheme is that there would be fewer primitives needed to do the same thing as currently being done. Right now, there is a lot of redundancy such as SWAP12 and SWAP22 that essentially do the same thing, but are only different in regard to whether they expect SOS to be valid or not. All of these redundant primitives could be replaced with a single primitive, such as SWAP for SWAP12 and SWAP22. We still have 64 primitives total available though, so a lot of what currently are macros could become primitives --- for example, we could have a TUCK primitive (currently we have TUCK12 and TUCK22 macros, each expanding to two primitives). Also, a single primitive only takes up one byte, so it could fit in the skip-area of a skippy primitive along with another primitive, reducing the need to put a BRANCH in the skip-area and the code elsewhere. The overall program would be smaller --- reducing bloat could be an issue for big programs (we only have 32KB of non-volatile memory, and only 16KB of that is accessible by CALL) --- also, reducing bloat increases speed because less time is spent fetching and decoding opcodes. The disadvantage is that most of the primitives would be slower because they have to test SV before beginning and also set SV at the end. This likely won't make much of a difference in an FPGA. In an emulation however, it could make a big difference. The AVR is not too bad, because the T flag could be used as SV, but most processors (such as the MSP-430 or PIC24) would require a 16-bit register to be used for SV which is wasteful of resources (it might be possible to use the Carry flag, although you would have to be careful not to accidently clobber it in your NEXT code). Another disadvantage is that this scheme requires primitives to be able to branch internally (depending upon the state of SV at the beginning). My experience with the MiniForth, is that primitives can't branch internally --- I assume that this is very expensive to implement in an FPGA --- Mark Wills says that I'm thinking in terms of 20-year-old technology and that modern FPGAs are much more powerful and don't have this limitation. I'm not familiar enough with FPGAs to know if this is true or not (maybe it is only true for big expensive FPGAs but not for small inexpensive FPGAs). Right now, I'm sticking with the simple plan of having the huffing and puffing figured out at compile-time (the cross-compiler generates either SWAP12 or SWAP22 as appropriate). Michael's idea with this being done at run-time is something to consider though --- maybe a second version of the processor can do this.
[toc] | [prev] | [next] | [standalone]
| From | alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-10-05 22:07 +0100 |
| Message-ID | <nt3q22$e31$1@dont-email.me> |
| In reply to | #51627 |
On 05/10/16 20:26, hughaguilar96@gmail.com wrote: > On Tuesday, October 4, 2016 at 12:41:00 PM UTC-7, Walter Banks wrote: >> On 2016-10-04 2:46 PM, Hans Bezemer wrote: >>> 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. >> >> My understanding of 4TH is it compiles to an intermediate H code that >> can interpreted / compiled on a variety of targets if I have been >> looking at the correct website. I am an old UCSD pascal fan as well. > > This is what Java does with its JVM --- define a VM that is simulated > on a variety of different target processors --- I don't think this > is a good idea because you are interpreting opcodes at run-time > when this work should be done at compile-time (JIT supposedly works > around this problem, but it is complicted, and you are still doing > work at run-time that could have been done at compile-time). > 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.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-06 00:05 -0700 |
| Message-ID | <e5fdb4c2-31b2-42c2-a29b-cd81b691cf65@googlegroups.com> |
| In reply to | #51631 |
On Wednesday, October 5, 2016 at 2:07:29 PM UTC-7, alex wrote: > On 05/10/16 20:26, hughaguilar96@gmail.com wrote: > > On Tuesday, October 4, 2016 at 12:41:00 PM UTC-7, Walter Banks wrote: > >> On 2016-10-04 2:46 PM, Hans Bezemer wrote: > >>> 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. > >> > >> My understanding of 4TH is it compiles to an intermediate H code that > >> can interpreted / compiled on a variety of targets if I have been > >> looking at the correct website. I am an old UCSD pascal fan as well. > > > > This is what Java does with its JVM --- define a VM that is simulated > > on a variety of different target processors --- I don't think this > > is a good idea because you are interpreting opcodes at run-time > > when this work should be done at compile-time (JIT supposedly works > > around this problem, but it is complicted, and you are still doing > > work at run-time that could have been done at compile-time). > > > > 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. Maybe so. My goal with the ITC version of Straight Forth is to generate code that is twice as fast as SwiftForth code (about half as fast as VFX code), which is the minimum needed for it to be useful for writing commercial software. If it is not this fast, I may delve into JIT. I'm expecting that basic compile-time peephole optimization should be adequate though. JIT is pretty complicated --- I'm hoping to avoid that!
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web