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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-04 15:53 -0400 |
| Message-ID | <nt11bf$785$1@gioia.aioe.org> |
| In reply to | #51609 |
On 2016-10-04 2:44 PM, hughaguilar96@gmail.com wrote: > 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. I doubt very much that you can implement any application in asm for any compiler we have written that I cannot code the same application in the high level language in equal or smaller code and timing. One of the tests we do is to make sure that code fragments will result in the ISA of the processor. This means that any asm program can be written in the HHL and produce the same code, but compilers use the whole instruction set and do better program and data flow accounting than people opening for opportunities for better implementation. w..
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> |
|---|---|
| Date | 2016-10-04 16:15 -0400 |
| Message-ID | <20161004161542.7506380b@_> |
| In reply to | #51614 |
On Tue, 4 Oct 2016 15:53:19 -0400 Walter Banks <walter@bytecraft.com> wrote: > On 2016-10-04 2:44 PM, hughaguilar96@gmail.com wrote: > > 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. > > I doubt very much that you can implement any application in asm for > any compiler we have written that I cannot code the same application > in the high level language in equal or smaller code and timing. > Not to start a flame war, but this is not a conclusion that assembly and Forth programmers generally accept. They are generally of the belief that they can outdo any compiler. They don't grasp how powerful the optimization is on modern C compilers. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-05 14:31 -0700 |
| Message-ID | <c4fc4201-a8c3-485d-a822-15297947ea72@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: > > 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. Here "stuff" means "stack-processors." > 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) My understanding is that you think of Forth as being intermediate code that a C compiler would generate for a stack-processor. Your interest in stack-processors is that you believe they use less resources in an FPGA than register-processors use. You don't see any point in hand-coding Forth code, for the same reason that you don't see any point in hand-coding assembly-language code --- you believe that a modern C compiler can generate this low-level code as well or better than it can be hand-written --- you assume that all programmers will want to program in C rather than hand-write assembly-language or Forth code. Am I reading you wrong? Are these assumptions incorrect? Have you ever written any Forth programs? I saw another design once, for the F3C processor, that was based on these ideas. The designer wrote the "assembler" for his processor in Java (he just modified an assembler written for another processor to work with his F3C instead). He was assuming that a compiler (possibly a C compiler written in Java, or maybe an ANTLR compiler for some C-like language) would generate the assembly-language code and feed it into this assembler --- he had no intention of writing a Forth compiler --- it was obvious that he had never seen a Forth compiler and didn't know that any such thing exists. His F3C design made no effort to make function calls fast or small, so he apparently didn't know that Forth code is typically heavily factored. AFAIK, Rickman is the same --- he doesn't program in Forth himself (he has never posted any Forth code on comp.lang.forth and he appears to know nothing about the subject) --- his only interest in stack-processors is that he believes they use less resources in an FPGA than register-processors use. Apparently many FPGA guys have read Koopman's book and have become interested in stack-processors because of Koopman's idea that stack-processors use less resources in an FPGA than register-processors use --- none of these guys have ever programmed in Forth, nor do they have any intention of ever doing so --- they think of Forth as a kind of assembly-language that could, like any other assembly-language, be used as the back-end for a C compiler. My Straight Forth has two built-in data-structures, which are the array and the chain (an ordered container keyed on a string) --- not that C only has the array. By comparison, ANS-Forth doesn't have any data-structures --- because of this, a lot of people think of ANS-Forth as being an assembly-language --- all assembly-languages lack support for data-structures, but instead require that all data-structures be hand-written. For example, an array would have you multiply the index by the element-size and then add the result to the base address --- in x86 assembly-language you get an addressing-mode that does all of this in one instruction, but in most assembly-languages you need multiple instructions --- so, ANS-Forth could be considered to be a lower-level assembly-language than x86 assembly-language. Elizabeth Rather says: -------------------------------------------------------- Virtually every Forth application needs some kind of array structures. The reason that some general-purpose one might be "little used" is because it's so easy to make a version that does *exactly* what the application needs rather than some generic definition. ... The objective is to master the toolset and be able to think clearly about exactly what kind of arrays will be useful in your application and then build exactly that kind. -------------------------------------------------------- Elizabeth Rather is the reason why people think of Forth as being an assembly-language --- they don't want to program in Forth --- they suppose that a C compiler might be able to generate Forth code though, which would be useful if the target is a stack-processor.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-06 08:48 -0400 |
| Message-ID | <nt5h7q$uvr$1@gioia.aioe.org> |
| In reply to | #51633 |
On 2016-10-05 5:31 PM, hughaguilar96@gmail.com wrote: > 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: >>> 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. > > Here "stuff" means "stack-processors." > >> 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) > > My understanding is that you think of Forth as being intermediate > code that a C compiler would generate for a stack-processor. No I think that the forth community have a knowledge base of programming stack processors that is useful to understand to implement code generators for compilers for stack machines. For what it is worth wrote a test code generator one time that generated forth as part of a project looking at code reliability and stack processor code generation sequences. At various other times we have generated C, FORTRAN, Pascal, lisp, trac from C source. > > Your interest in stack-processors is that you believe they use less > resources in an FPGA than register-processors use. That is probably true but our use of fpga's is mostly for ISA prototypes on a wide range of architectures. We have worked on risc, conventional register and microcoded ISA's each for their own reasons. > > You don't see any point in hand-coding Forth code, for the same > reason that you don't see any point in hand-coding assembly-language > code Far from what I believe. > --- you believe that a modern C compiler can generate this low-level > code as well or better than it can be hand-written That has been demonstrably true for at least 20 years that a good C modern C compiler can equal or better hand written assembler in code size and/or execution time. > --- you assume that all programmers will want to program in C rather > than hand-write assembly-language or Forth code. Not true. I assume that programmers will program in the language appropriate for the job with the tools that they are familiar with on the available platform that suites the application. > Am I reading you wrong? Are these assumptions incorrect? Some are as I have pointed out. > Have you ever written any Forth programs? Yes. w..
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-10-06 13:08 -0700 |
| Message-ID | <87d1jdxmu3.fsf@nightsong.com> |
| In reply to | #51645 |
Walter Banks <walter@bytecraft.com> writes: > At various other times we have generated C, FORTRAN, Pascal, lisp, > trac from C source. Trac, you mean Calvin Mooers' old language? #(ps, #(rs)) ? Wow! That is cool. Trac is even more unusual than Forth ;-)
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-06 19:11 -0400 |
| Message-ID | <nt6lnf$1elq$1@gioia.aioe.org> |
| In reply to | #51648 |
On 2016-10-06 4:08 PM, Paul Rubin wrote: > Walter Banks <walter@bytecraft.com> writes: >> At various other times we have generated C, FORTRAN, Pascal, lisp, >> trac from C source. > > Trac, you mean Calvin Mooers' old language? #(ps, #(rs)) ? > > Wow! That is cool. Trac is even more unusual than Forth ;-) > Yup, that one, didn't ever release it I didn't want to be sued. Also targeted SAM at one point. (SAM Same As Moores :) functionally but quite different syntax. w..
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2016-10-06 12:08 -0700 |
| Message-ID | <c4268116-7fd1-41e1-bccc-5c58cbaabb7f@googlegroups.com> |
| In reply to | #51568 |
On Monday, October 3, 2016 at 7:22:29 AM UTC-5, 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.. ]> I am currently working on a stack processor ISA. Checked out the ByteCraft website where there is a 2009 article on avoiding having a stack. Agree that non-recursive routines can have their data "frame" allocated in global memory. Which can be cached just as well as a software stack. However, the number of bits needed to specify a location in global memory exceeds that needed when using a stack or when using a frame pointer? That is: code size should be smaller for using the data stack mechanism rather than global or even frame offsets? (has anyone ever proposed compressing Forth address literals?) As to how many stacks: multiple data stacks makes it easier to do a multiple issue per clock stack machine. (warning: bright idea ahead) Each stack has a single write port and multiple read ports (a common feature of FPGA RAMs). Thus an ALU for each stack which can read from any of the stacks and write results to its stack. Jim Brakefield
[toc] | [prev] | [next] | [standalone]
| From | alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-10-06 21:47 +0100 |
| Message-ID | <nt6d8m$941$1@dont-email.me> |
| In reply to | #51647 |
On 06/10/16 20:08, jim.brakefield@ieee.org wrote: > On Monday, October 3, 2016 at 7:22:29 AM UTC-5, 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.. > > ]> I am currently working on a stack processor ISA. > > Checked out the ByteCraft website where there is a 2009 article on avoiding having a stack. There are many systems that don't have stacks supported by the processor hardware. The IBM S/360 and its successors are one example. Its instruction set has no equivalent of the x86 PUSH and POP. The standard calling convention (the S-type linkage) uses doubly linked lists. The caller provides a register save area for the callee's use. Of course, one could create a synthetic stack by using a register pointer to memory, but it would require the register to be additionally incremented or decremented after a load or store.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-06 19:05 -0400 |
| Message-ID | <nt6lb6$1e9r$1@gioia.aioe.org> |
| In reply to | #51647 |
On 2016-10-06 3:08 PM, jim.brakefield@ieee.org wrote: > On Monday, October 3, 2016 at 7:22:29 AM UTC-5, 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.. > > ]> I am currently working on a stack processor ISA. > > Checked out the ByteCraft website where there is a 2009 article on > avoiding having a stack. Agree that non-recursive routines can have > their data "frame" allocated in global memory. Which can be cached > just as well as a software stack. However, the number of bits needed > to specify a location in global memory exceeds that needed when using > a stack or when using a frame pointer? That is: code size should be > smaller for using the data stack mechanism rather than global or even > frame offsets? (has anyone ever proposed compressing Forth address > literals?) > > As to how many stacks: multiple data stacks makes it easier to do a > multiple issue per clock stack machine. (warning: bright idea ahead) > Each stack has a single write port and multiple read ports (a common > feature of FPGA RAMs). Thus an ALU for each stack which can read > from any of the stacks and write results to its stack. > > Jim Brakefield It is always about tradeoff's for dynamic memory. Compiled stacks require larger address space but address space comes in 8 bits generally and 8 bits for dynamic space in most embedded applications is rarely enough. What is interesting is the price can be much less depending on the data flow analysis of the application and dynamic memory for compiled stack may be just as likely to accessed by a index register as it is to be directly accessed. Two things have come out of our metrics related to this. Most (actually essentially all) recursion gets optimized out of embedded applications. The second thing is the run time overhead of procedural languages like C to tear down stack frames at run time is 0.5% to 1% often more vs none for compiled stacks. The last point (I know more than 2) is that dynamic array support on the stack is notoriously weak in many ISA's but in compiled stack has the the same support as normal globals. > (has anyone ever proposed compressing Forth address literals?) I have looked at compressed constants and code at the ISA level in a couple processor projects in both cases for various reasons it wasn't a win. w..
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-06 21:57 -0400 |
| Message-ID | <nt6veh$mic$1@dont-email.me> |
| In reply to | #51647 |
On 10/6/2016 3:08 PM, jim.brakefield@ieee.org wrote: > On Monday, October 3, 2016 at 7:22:29 AM UTC-5, 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.. > > ]> I am currently working on a stack processor ISA. > > Checked out the ByteCraft website where there is a 2009 article on > avoiding having a stack. Agree that non-recursive routines can have > their data "frame" allocated in global memory. Which can be cached > just as well as a software stack. However, the number of bits needed > to specify a location in global memory exceeds that needed when using > a stack or when using a frame pointer? That is: code size should be > smaller for using the data stack mechanism rather than global or even > frame offsets? (has anyone ever proposed compressing Forth address > literals?) I used a sort of compression in my instruction set for all literals. An instruction that uses an address contains a short literal in the instruction. If the literal required is too long to fit in the instruction a literal extension can be prepended as an additional instruction. So literals take up space in instruction sized pieces. Is that what you mean? > As to how many stacks: multiple data stacks makes it easier to do a > multiple issue per clock stack machine. (warning: bright idea ahead) > Each stack has a single write port and multiple read ports (a common > feature of FPGA RAMs). Thus an ALU for each stack which can read > from any of the stacks and write results to its stack. > > Jim Brakefield > -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2016-10-06 19:21 -0700 |
| Message-ID | <d3174888-b58a-4df1-8bd6-6c5702729da2@googlegroups.com> |
| In reply to | #51653 |
On Thursday, October 6, 2016 at 8:57:53 PM UTC-5, rickman wrote: > On 10/6/2016 3:08 PM, jim.brakefield@ieee.org wrote: > > On Monday, October 3, 2016 at 7:22:29 AM UTC-5, 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.. > > > > ]> I am currently working on a stack processor ISA. > > > > Checked out the ByteCraft website where there is a 2009 article on > > avoiding having a stack. Agree that non-recursive routines can have > > their data "frame" allocated in global memory. Which can be cached > > just as well as a software stack. However, the number of bits needed > > to specify a location in global memory exceeds that needed when using > > a stack or when using a frame pointer? That is: code size should be > > smaller for using the data stack mechanism rather than global or even > > frame offsets? (has anyone ever proposed compressing Forth address > > literals?) > > I used a sort of compression in my instruction set for all literals. An > instruction that uses an address contains a short literal in the > instruction. If the literal required is too long to fit in the > instruction a literal extension can be prepended as an additional > instruction. So literals take up space in instruction sized pieces. Is > that what you mean? > > > > As to how many stacks: multiple data stacks makes it easier to do a > > multiple issue per clock stack machine. (warning: bright idea ahead) > > Each stack has a single write port and multiple read ports (a common > > feature of FPGA RAMs). Thus an ALU for each stack which can read > > from any of the stacks and write results to its stack. > > > > Jim Brakefield > > > > > -- > > Rick C ]> I used a sort of compression in my instruction set for all literals. An ]> instruction that uses an address contains a short literal in the ]> instruction. If the literal required is too long to fit in the ]> instruction a literal extension can be prepended as an additional ]> instruction. So literals take up space in instruction sized pieces. Is ]> that what you mean? Yes, this is my preference. People with more design experience may prefer variable length instructions with various literal/immediate sizes (there exist ISA's of both types). At a more abstract level considering the information content of the instruction stream, global and non-recursive local variables can be accessed via a base and offset, where the offset is generally shorter than a full memory address. If there is frame pointer, then the offset is likely to be even shorter. If the Forth PICK instruction is used for this purpose (requires that locations on the stack of locals is known to the compiler(1)), then a ~dozen PICK offsets can be folded into the op-code space. The inverse of the PICK instruction (e.g. TO) is not needed to update locals, just PICK the new value(s) and prune the stack on return. (1) Personally like the idea of keeping parameters and locals on the data stack. However one can also have a PICK from the return stack or from a frame pointer or from some other stack. Jim Brakefield
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-07 00:10 -0400 |
| Message-ID | <nt777n$9oq$1@dont-email.me> |
| In reply to | #51654 |
On 10/6/2016 10:21 PM, jim.brakefield@ieee.org wrote: > On Thursday, October 6, 2016 at 8:57:53 PM UTC-5, rickman wrote: >> On 10/6/2016 3:08 PM, jim.brakefield@ieee.org wrote: >>> On Monday, October 3, 2016 at 7:22:29 AM UTC-5, 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.. >>> >>> ]> I am currently working on a stack processor ISA. >>> >>> Checked out the ByteCraft website where there is a 2009 article >>> on avoiding having a stack. Agree that non-recursive routines >>> can have their data "frame" allocated in global memory. Which >>> can be cached just as well as a software stack. However, the >>> number of bits needed to specify a location in global memory >>> exceeds that needed when using a stack or when using a frame >>> pointer? That is: code size should be smaller for using the data >>> stack mechanism rather than global or even frame offsets? (has >>> anyone ever proposed compressing Forth address literals?) >> >> I used a sort of compression in my instruction set for all >> literals. An instruction that uses an address contains a short >> literal in the instruction. If the literal required is too long to >> fit in the instruction a literal extension can be prepended as an >> additional instruction. So literals take up space in instruction >> sized pieces. Is that what you mean? >> >> >>> As to how many stacks: multiple data stacks makes it easier to do >>> a multiple issue per clock stack machine. (warning: bright idea >>> ahead) Each stack has a single write port and multiple read ports >>> (a common feature of FPGA RAMs). Thus an ALU for each stack >>> which can read from any of the stacks and write results to its >>> stack. >>> >>> Jim Brakefield >>> >> >> >> -- >> >> Rick C > > ]> I used a sort of compression in my instruction set for all > literals. An ]> instruction that uses an address contains a short > literal in the ]> instruction. If the literal required is too long > to fit in the ]> instruction a literal extension can be prepended as > an additional ]> instruction. So literals take up space in > instruction sized pieces. Is ]> that what you mean? > > Yes, this is my preference. People with more design experience may > prefer variable length instructions with various literal/immediate > sizes (there exist ISA's of both types). > > At a more abstract level considering the information content of the > instruction stream, global and non-recursive local variables can be > accessed via a base and offset, where the offset is generally shorter > than a full memory address. If there is frame pointer, then the > offset is likely to be even shorter. If the Forth PICK instruction > is used for this purpose (requires that locations on the stack of > locals is known to the compiler(1)), then a ~dozen PICK offsets can > be folded into the op-code space. The inverse of the PICK > instruction (e.g. TO) is not needed to update locals, just PICK the > new value(s) and prune the stack on return. > > (1) Personally like the idea of keeping parameters and locals on the > data stack. However one can also have a PICK from the return stack > or from a frame pointer or from some other stack. Most of this is beyond what I wish to address in an CPU in an FPGA. I see them as simple beasts not unlike Chuck's F18 or Bernd Paysan's b16. After seeing the J1 I realized I had too much in my CPU design. The J1 is amazingly simple and yet effective. At some point I want to try some alternatives that I think may be useful. A register/stack hybrid by giving a limited range of access into the stack for operands. The trick is to provide enough that it is useful without complicating the hardware. The initial tests I did seemed to show improvement in instruction counts and consequently speed as well. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-10-06 23:14 -0700 |
| Message-ID | <87k2dkwuqs.fsf@nightsong.com> |
| In reply to | #51655 |
rickman <gnuarm@gmail.com> writes: > A register/stack hybrid by giving a limited range of access into the > stack for operands. This sounds like a register window architecture, e.g. SPARC. They were in vogue in workstation processors for a while, but then went out of favor, I think because of difficulties making them superscalar or something like that. For a small fpga softcore maybe that doesn't matter.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-07 02:26 -0400 |
| Message-ID | <nt7f6v$r4e$1@dont-email.me> |
| In reply to | #51656 |
On 10/7/2016 2:14 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> A register/stack hybrid by giving a limited range of access into the >> stack for operands. > > This sounds like a register window architecture, e.g. SPARC. They were > in vogue in workstation processors for a while, but then went out of > favor, I think because of difficulties making them superscalar or > something like that. For a small fpga softcore maybe that doesn't > matter. Lol, no, I don't think not being "superscalar" matters to a MISC CPU. Not familiar with register window, but that sounds a bit like it, but put it on top of a stack. The idea is to do away with most of the stack manipulations, OVER, DUP, etc. buy implementing them with small offsets and stack pointer adjustments other than +1/0/-1. One of the issues in stack machines is dealing with more than a couple or three stack items. I think a small offset into the stack will make this work a lot better. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-10-06 23:57 -0700 |
| Message-ID | <87fuo8wsr0.fsf@nightsong.com> |
| In reply to | #51657 |
rickman <gnuarm@gmail.com> writes: > One of the issues in stack machines is dealing with more than a couple > or three stack items. I think a small offset into the stack will make > this work a lot better. The SPARC had a 24-register window, where each level of call got 8 local registers and could also see the local sets of the two higher calls. It seemed like a good idea at the time. I never dealt with it directly so I don't know what nonobvious issues it had, if any. https://en.wikipedia.org/wiki/SPARC
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-10-07 08:18 -0500 |
| Message-ID | <xY-dnVB12fghPWrKnZ2dnUU7-eXNnZ2d@supernews.com> |
| In reply to | #51659 |
Paul Rubin <no.email@nospam.invalid> wrote: > rickman <gnuarm@gmail.com> writes: >> One of the issues in stack machines is dealing with more than a couple >> or three stack items. I think a small offset into the stack will make >> this work a lot better. > > The SPARC had a 24-register window, where each level of call got 8 local > registers and could also see the local sets of the two higher calls. It > seemed like a good idea at the time. I never dealt with it directly so > I don't know what nonobvious issues it had, if any. The decision to go with register windows was based on a bunch of benchmarks which seemed to indicate a performance improvement over something more conventional. But the benchmarks weren't representative enough, and the fixed size of the windows was problematic because registers are left unused. In the end, register windows are a loss: sophisticated register allocators can generate better code which uses fewer physical registers. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-07 10:52 -0400 |
| Message-ID | <nt8cs6$bmf$1@gioia.aioe.org> |
| In reply to | #51668 |
On 2016-10-07 9:18 AM, Andrew Haley wrote: > Paul Rubin <no.email@nospam.invalid> wrote: >> rickman <gnuarm@gmail.com> writes: >>> One of the issues in stack machines is dealing with more than a >>> couple or three stack items. I think a small offset into the >>> stack will make this work a lot better. >> >> The SPARC had a 24-register window, where each level of call got 8 >> local registers and could also see the local sets of the two higher >> calls. It seemed like a good idea at the time. I never dealt with >> it directly so I don't know what nonobvious issues it had, if any. > > The decision to go with register windows was based on a bunch of > benchmarks which seemed to indicate a performance improvement over > something more conventional. But the benchmarks weren't > representative enough, and the fixed size of the windows was > problematic because registers are left unused. In the end, register > windows are a loss: sophisticated register allocators can generate > better code which uses fewer physical registers. Better code yes from register allocators. Part of this is a delusion as well. The goal often was to have faster context switches and for various reasons that didn't materialize. RAM fragmentation became a problem. After the promising generalizations and promises register windows when it came to details they didn't work very well. The idea has been around since at least the 70's with the TI9900. w..
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-09 16:22 -0700 |
| Message-ID | <4f3794f4-58f2-47b7-8d27-b2b246e325f1@googlegroups.com> |
| In reply to | #51670 |
On Friday, October 7, 2016 at 7:52:57 AM UTC-7, Walter Banks wrote: > The idea has been around > since at least the 70's with the TI9900. Mark Wills is our big TI9900 guy around here. Is the IT9900 still used at all? I have read that it was the best processor of its era --- I have also read however that the TI99/4A was the worst computer of its era --- somewhat like putting a race-car engine in a go-kart. All of this talk about register allocation is somewhat interesting, but I'm taking a much simpler approach in Straight Forth. Note that a "number" in Straight Forth is a 64-bit fixed-point with an assumed unity of 2^32, which is why I refer to a "fractional part" later. Here is an excerpt from my document: ----------------------------------------------------------------------------- In Straight Forth we have four user registers: PTR CNT REG and ACC. Note that PTR and CNT can only hold integers (the fractional part is zero'd) --- PTR and CNT are typically used together to describe an array and the term PC refers to this register pair. ... REG and ACC are general-purpose registers (I haven't studied cmForth, but have read that it had a register like this too). PTR and CNT can't have a fractional part, so they aren't general-purpose. For the most part, PTR and CNT are used for passing data into and back out of HOFs. A HOF is a "higher-order function" that executes an xt (typically a quotation). In functions that don't call any HOFs, the PTR and CNT user registers can be used for other purposes --- this isn't idiomatic however --- iteration is done in HOFs and so calling HOFs is pretty common (the PTR and CNT user registers were provided to help boost the speed of iteration). The user registers are always saved and restored upon entrance and exit of any function or quotation. It is possible for a calling function to pass data into a sub-function in the user registers, but it is not possible for the sub-function to return data to the calling function in the user registers. The sub-function saves the user registers upon entrance but it doesn't initialize them, so they still have the calling function's values inside of the sub-function. The sub-function restores the user registers upon exit though, so when the calling function resumes the user register values are unchanged. The user registers are like local variables (rather than global variables) in that they can be used in a function and they won't get clobbered by a sub-function. The user registers are different from local variables however in that they can be used to pass data into sub-functions (by comparison, sub-functions don't have access to calling functions' local variables). The exception to the above rule is that a HOF (higher-order function) does not save and restore PTR and CNT (it does save and restore REG and ACC). A HOF is defined with HOF: rather than colon, but is otherwise just like a colon function. A HOF can pass data back up to the calling function in PTR and CNT. In Straight Forth it is idiomatic that all iteration should be done inside of HOFs. The programmer generally does not use BEGIN WHILE REPEAT anywhere except inside of HOFs. A function that calls a HOF can use REG and ACC like local variables (REG and ACC won't get clobbered by the HOF), but PTR and CNT will be used for passing data into and out of the HOF (they will get clobbered by the HOF). If the HOF doesn't pass any data back up to the calling function in PTR and CNT, but just restores PTR and CNT, then the HOF can be defined with colon rather than with HOF: because colon restores these automatically. When calling a HOF, PC is first set to describe the data-structure that will be traversed. Some HOFs traverse the entire data-structure, in which case PC will be restored. Other HOFs traverse the data-structure until the executed xt returns a TRUE, at which time they early-exit. In this case, the HOF will return on the data-stack some information about what caused the early-exit. The HOF will also return PC set to describe the remainder of the data-structure that hasn't been traversed yet. Oftentimes the HOF will be called repeatedly until the entire data-structure has been traversed. Because the HOF returns PC set to describe the remainder, the HOF can be called again using this PC to search the remainder of the data-structure --- this can be done repeatedly until the entire data-structure has been searched. A novice-level Straight Forth programmer should only use the built-in HOFs; he should not write his own HOFs and he should not use BEGIN WHILE REPEAT (iteration is a common source of bugs, which is why novices are discouraged from using BEGIN WHILE REPEAT). An intermediate-level Straight Forth programmer may write his own HOFs and use BEGIN WHILE REPEAT inside of them, but should not use BEGIN WHILE REPEAT anywhere except inside of his HOFs, and he should not write very many HOFs. It is idiomatic for all Straight Forth programmers from novice to advanced to program in a novice-level manner (using the built-in HOFs) as much as possible because this makes the programs easy to read by others who may be novice-level. The built-in data-structures are the array and the chain (an ordered container with a string as a key). These should be adequate for 99% of all Straight Forth programs. In rare circumstances it will be necessary to use some other data-structure, in which case HOFs will have to be written to support that data-structure (a HOF is used to traverse a data-structure). Straight Forth programmers should not introduce new data-structures unless necessary, because doing so makes their programs hard to read, but they should stick with novice-level techniques (using the two built-in data-structures) as much as possible --- the programmers should not strive to prove that they are intermediate-level or (woo hoo!) advanced-level --- the goal with Straight Forth is to write programs that do something useful and which are easy to read by everybody including novices.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-10 01:49 -0400 |
| Message-ID | <ntfa4m$gmj$1@dont-email.me> |
| In reply to | #51733 |
On 10/9/2016 7:22 PM, hughaguilar96@gmail.com wrote: > On Friday, October 7, 2016 at 7:52:57 AM UTC-7, Walter Banks wrote: >> The idea has been around since at least the 70's with the TI9900. > > Mark Wills is our big TI9900 guy around here. > > Is the IT9900 still used at all? I have read that it was the best > processor of its era --- I have also read however that the TI99/4A > was the worst computer of its era --- somewhat like putting a > race-car engine in a go-kart. It's era included the PDP-11 computer line and LSI-11 computer chips. I think trying to claim some sort of superiority of one line of computer designs over another is a bit pointless. How do you measure "best"? The TI-990 was a reasonably popular mini-computer line, but never had overwhelming sales. The TMS9900 chip came in a humongous 64 pin package and required a 4 phase clock, not entirely different from many of the first CPUs like the 8080. But the 9900 had exactly one significant successor, the 9995 which had an 8 bit data bus. All in all this product line didn't get much traction other than in TI's own computers. I can't imagine you can buy any 9900 type chips other than HDL in an FPGA. I've got a 9900 computer board I modified to use 2716 EPROMs rather than the old 2708 EPROMs. I also built a 9995 board with some 8 kB of fast RAM and one EPROM. Both are still around somewhere, haven't touched them in years. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-10 10:21 -0500 |
| Message-ID | <ntgbl9$40n$1@dont-email.me> |
| In reply to | #51735 |
On 10/10/2016 12:49 AM, rickman wrote: > On 10/9/2016 7:22 PM, hughaguilar96@gmail.com wrote: >> On Friday, October 7, 2016 at 7:52:57 AM UTC-7, Walter Banks wrote: >>> The idea has been around since at least the 70's with the TI9900. >> >> Mark Wills is our big TI9900 guy around here. >> >> Is the IT9900 still used at all? I have read that it was the best >> processor of its era --- I have also read however that the TI99/4A >> was the worst computer of its era --- somewhat like putting a >> race-car engine in a go-kart. > > It's era included the PDP-11 computer line and LSI-11 computer chips. I > think trying to claim some sort of superiority of one line of computer > designs over another is a bit pointless. How do you measure "best"? The > TI-990 was a reasonably popular mini-computer line, but never had > overwhelming sales. The TMS9900 chip came in a humongous 64 pin package > and required a 4 phase clock, not entirely different from many of the > first CPUs like the 8080. But the 9900 had exactly one significant > successor, the 9995 which had an 8 bit data bus. All in all this > product line didn't get much traction other than in TI's own computers. > > I can't imagine you can buy any 9900 type chips other than HDL in an > FPGA. I've got a 9900 computer board I modified to use 2716 EPROMs > rather than the old 2708 EPROMs. I also built a 9995 board with some 8 > kB of fast RAM and one EPROM. Both are still around somewhere, haven't > touched them in years. > The device was slow by later standards but it never stood a change, programming wise it was decent. TI used every trick to possibly cripple the CPU in the TI99/4, unfortunately that is a horrible market ploy that most likely backfired on them. Most likely designers that saw the performance of the TI99/4 were turned off before they looked at the device. You can still find the chips an the TI99/4 on eBay for all it's worth. Actually those EPROMs you mentioned are rather expensive, the much larger sizes are way cheaper. The 1Mb 28c1000 parts are available inexpensively and are prime parts from distributors. I recently bought some 27C256 and 29C256 devices for a CDP 1802, and Z80 projects and they cost more than the 28c1000 parts which are 4X bigger and way faster. As soon as I can find some decent wire-wrap 32 pin sockets I will buy some of those chips and save some money on future projects even if I only use part of the devices. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web