Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #59883 > unrolled thread
| Started by | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| First post | 2017-05-26 14:49 -0500 |
| Last post | 2017-05-28 21:38 -0700 |
| Articles | 20 on this page of 105 — 16 participants |
Back to article view | Back to comp.lang.forth
Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 14:49 -0500
Re: Forth Implementations advantages and disadvantages. minforth@arcor.de - 2017-05-26 13:17 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 17:53 -0500
Re: Forth Implementations advantages and disadvantages. Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 22:31 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 00:57 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 01:09 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 00:59 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 02:09 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 09:35 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 12:22 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 11:53 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 13:13 -0400
Re: Forth Implementations advantages and disadvantages. David Schultz <abuse@127.0.0.1> - 2017-05-27 12:24 -0500
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 13:13 -0500
Re: Forth Implementations advantages and disadvantages. David Schultz <abuse@127.0.0.1> - 2017-05-27 13:33 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 14:53 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 14:44 -0500
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 10:09 +0200
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 12:57 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 12:14 -0500
Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-28 16:11 -0700
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 02:11 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 01:54 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 03:22 -0400
Re: Forth Implementations advantages and disadvantages. Joel Rees <joel.rees@gmail.com> - 2017-05-28 15:46 -0700
Re: Forth Implementations advantages and disadvantages. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-27 01:23 -0500
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 09:29 -0500
Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-27 11:36 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 14:25 -0500
Re: Forth Implementations advantages and disadvantages. Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-27 21:58 -0400
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 11:20 -0700
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 15:20 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 14:20 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 18:33 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 18:50 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 20:13 -0400
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 10:23 +0200
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 12:26 -0500
Re: Forth Implementations advantages and disadvantages. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 04:22 -0500
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-30 11:49 +0200
Re: Forth Implementations advantages and disadvantages. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 05:07 -0500
Re: Forth Implementations advantages and disadvantages. Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-30 18:58 +0200
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 12:28 -0500
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 20:14 +0200
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 14:08 -0500
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-29 10:52 +0200
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 12:50 -0500
Re: Forth Implementations advantages and disadvantages. Alex <alex@rivadpm.com> - 2017-05-29 19:06 +0100
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 20:00 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 22:29 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 22:10 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 11:22 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 14:45 -0700
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 18:25 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 21:43 -0500
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-06-01 11:27 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-06-01 12:50 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-06-01 12:47 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-06-01 16:23 -0400
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-06-01 16:32 -0400
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-06-01 12:08 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-06-01 21:47 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-06-02 06:34 -0700
Re: Forth Implementations advantages and disadvantages. foxaudioresearch@gmail.com - 2017-06-02 07:13 -0700
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-06-02 07:57 -0700
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-03 02:17 +0200
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 21:07 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 21:48 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 00:52 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 09:17 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 12:16 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 19:21 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 23:13 -0500
Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-30 01:07 -0700
Re: Forth Implementations advantages and disadvantages. Alex <alex@rivadpm.com> - 2017-05-30 15:54 +0100
Re: Forth Implementations advantages and disadvantages. Alex <alex@rivadpm.com> - 2017-05-29 19:02 +0100
Re: Forth Implementations advantages and disadvantages. Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-29 11:06 -0700
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 19:29 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 23:01 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-30 14:53 -0700
Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-29 13:59 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 17:03 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 19:37 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 22:52 -0500
Re: Forth Implementations advantages and disadvantages. Mark Wills <markwills1970@gmail.com> - 2017-05-28 11:49 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 14:12 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 02:35 -0400
Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-27 21:04 -0700
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 21:56 -0700
Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-28 01:10 -0700
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 13:21 -0400
Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-28 11:53 -0700
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 15:09 -0700
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 02:40 -0400
Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-29 13:10 -0700
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-30 00:57 -0400
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 02:17 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 11:50 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 13:52 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 13:47 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 03:19 -0400
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 15:40 -0700
Re: Forth Implementations advantages and disadvantages. Joel Rees <joel.rees@gmail.com> - 2017-05-28 16:31 -0700
Re: Forth Implementations advantages and disadvantages. Joel Rees <joel.rees@gmail.com> - 2017-05-28 20:17 -0700
Opinions on a C language header for words? Joel Rees <joel.rees@gmail.com> - 2017-05-28 21:38 -0700
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-05-29 13:59 -0700 |
| Message-ID | <874lw3peg4.fsf@nightsong.com> |
| In reply to | #60006 |
Cecil Bayona <cbayona@cbayona.com> writes: > Borland made Turbo Pascal and other Turbo products like Turbo C and > Turbo Prolog... won't run in Windows 10 64 bits There's a free download of Turbo Pascal 5.5 that will probably run on a DOS emulator: http://edn.embarcadero.com/article/20803 James Hague wrote a famous comparison of code size between Turbo Pascal and newer software: http://prog21.dadgum.com/116.html I've been wanting to try Turbo Pascal sometime.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-29 17:03 -0500 |
| Message-ID | <ogi5km$fl5$1@dont-email.me> |
| In reply to | #60029 |
On 5/29/2017 3:59 PM, Paul Rubin wrote: > Cecil Bayona <cbayona@cbayona.com> writes: >> Borland made Turbo Pascal and other Turbo products like Turbo C and >> Turbo Prolog... won't run in Windows 10 64 bits > > There's a free download of Turbo Pascal 5.5 that will probably > run on a DOS emulator: > > http://edn.embarcadero.com/article/20803 > > James Hague wrote a famous comparison of code size between Turbo Pascal > and newer software: > > http://prog21.dadgum.com/116.html > > I've been wanting to try Turbo Pascal sometime. > You can get a free copy now of Delphi 7 which is for Windows, and you can also a free version of the current software Delphi 10.2 for Windows, or Linux but there are massive changes to the interface that makes it totally different from Delphi 7 which I liked a lot. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-29 19:37 -0700 |
| Message-ID | <8962ea01-91b5-4c4d-bbd6-5d237fff5ebf@googlegroups.com> |
| In reply to | #60006 |
On Sunday, May 28, 2017 at 10:52:58 PM UTC-7, Cecil - k5nwa wrote: > On 5/28/2017 11:48 PM, hughaguilar96@gmail.com wrote: > > BTW: Lemmings don't actually follow each other over a cliff in a mass-suicide as most people believe: > > http://www.adfg.alaska.gov/index.cfm?adfg=wildlifenews.view_article&articles_id=56 > > I know that but is now means to most people, following the crowd without > thinking to disastrous results, sounds familiar? Well, if you use the word lemming incorrectly, just because you are following the crowd who use the word lemming incorrectly, then that would make you a lemming! But, wait --- if I say that you are a lemming because you use the word lemming incorrectly, then I am using the word lemming incorrectly too, and this makes me a lemming as well (assuming the incorrect usage of the word lemming). If lemmings could talk, what would they use the word "human" to mean?
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-29 22:52 -0500 |
| Message-ID | <ogiq3u$2io$1@dont-email.me> |
| In reply to | #60037 |
On 5/29/2017 9:37 PM, hughaguilar96@gmail.com wrote: > On Sunday, May 28, 2017 at 10:52:58 PM UTC-7, Cecil - k5nwa wrote: >> On 5/28/2017 11:48 PM, hughaguilar96@gmail.com wrote: >>> BTW: Lemmings don't actually follow each other over a cliff in a mass-suicide as most people believe: >>> http://www.adfg.alaska.gov/index.cfm?adfg=wildlifenews.view_article&articles_id=56 >> >> I know that but is now means to most people, following the crowd without >> thinking to disastrous results, sounds familiar? > > Well, if you use the word lemming incorrectly, just because you are following the crowd who use the word lemming incorrectly, then that would make you a lemming! > > But, wait --- if I say that you are a lemming because you use the word lemming incorrectly, then I am using the word lemming incorrectly too, and this makes me a lemming as well (assuming the incorrect usage of the word lemming). > > If lemmings could talk, what would they use the word "human" to mean? > A bunch of crazy animals that often don't think and follow others to bad consequences. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-05-28 11:49 -0700 |
| Message-ID | <f5b89778-32a4-478c-b3f8-44842dd5f21e@googlegroups.com> |
| In reply to | #59956 |
The solution is obvious. Use a Forth processor. No need for an assembler or C or C++ or Go or a cross-compiler or a meta-compiler. The chip *is* Forth. I don't think you can get much more portable than that.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-28 14:12 -0500 |
| Message-ID | <ogf77l$64r$1@dont-email.me> |
| In reply to | #59984 |
On 5/28/2017 1:49 PM, Mark Wills wrote: > The solution is obvious. Use a Forth processor. No need for an assembler or C or C++ or Go or a cross-compiler or a meta-compiler. The chip *is* Forth. > > I don't think you can get much more portable than that. > Even with a Forth CPU you still need an assembler to create the code in memory, and a meta compiler to create a resident version of Forth that runs in a CPU. Forth is a lot more that a bunch of primitives. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-29 02:35 -0400 |
| Message-ID | <oggf93$j91$1@dont-email.me> |
| In reply to | #59984 |
Mark Wills wrote on 5/28/2017 2:49 PM: > The solution is obvious. Use a Forth processor. No need for an assembler or C or C++ or Go or a cross-compiler or a meta-compiler. The chip *is* Forth. > > I don't think you can get much more portable than that. I don't think such a processor has ever been built. Do you know of one? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2017-05-27 21:04 -0700 |
| Message-ID | <5e09c5fb-62da-4942-b13c-70a8f6f6ee1d@googlegroups.com> |
| In reply to | #59955 |
On Saturday, May 27, 2017 at 10:00:39 PM UTC-5, hughag...@gmail.com wrote: > On Saturday, May 27, 2017 at 12:20:48 PM UTC-7, Cecil - k5nwa wrote: > > I'm not sure that using a limited MSP430 instruction set is the way to > > go, it has a very nice instruction set but maybe a Portable Instruction > > Set that has some added primitive like instructions might be a better > > choice or a combination of the two. One way to find out is to test some > > examples by using a decent Macro Assembler to generate the code and see > > what is useful and what is not needed. > > > > I have some pretty decent Macro Processor software that is extremely > > capable of manipulating text and do all sorts of translation, maybe it's > > time to dig it out and see how good is a Portable Assembler and how > > efficient it is at generating efficient code for multiple CPUs. > > Well, it should be a 16-bit processor. In the 32-bit world, ARM assembly-language already is the "portable assembly language" because 99% of the boards use an ARM processor. > > I just said the MSP430 because it is a common 16-bit processor. What application program do you have in mind? Is there some reason why the MSP430 wouldn't be a good choice for building a board? > > The PDP11 would be another possibility. It has these points in favor of it: > > 1.) the PDP11 has 8 registers rather than 16, which makes it a good choice for an FPGA (the number of registers is the primary factor in how much chip resources are needed, and how expensive the FPGA is). > > 2.) There are public-domain implementations of the PDP11 available in Verilog, which is not true of the MSP430. > > 3.) The PDP11 has a very orthogonal and straight-forward instruction set, which is not true of the 8086, although it is true of the MSP430. ]>There are public-domain implementations of the PDP11 available in Verilog, ]> which is not true of the MSP430. http://opencores.org/project,neo430 (VHDL) http://opencores.org/project,openmsp430 (Verilog)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-27 21:56 -0700 |
| Message-ID | <35d1e54d-3500-472e-b813-95fcd89deaa3@googlegroups.com> |
| In reply to | #59958 |
On Saturday, May 27, 2017 at 9:05:01 PM UTC-7, jim.bra...@ieee.org wrote: > On Saturday, May 27, 2017 at 10:00:39 PM UTC-5, hughag...@gmail.com wrote: > ]>There are public-domain implementations of the PDP11 available in Verilog, > ]> which is not true of the MSP430. > > http://opencores.org/project,neo430 (VHDL) > http://opencores.org/project,openmsp430 (Verilog) Cool! I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 --- I doubt that Cecil cares about saving a few dollars however, as he is only planning on making one board for his own use --- price only matters to people who are producing boards in a high volume. I'm just speculating as to requirements and prices --- I don't really know anything about FPGAs, so I can't really answer the question.
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2017-05-28 01:10 -0700 |
| Message-ID | <14799416-ead3-4d94-8196-caaafe2a121f@googlegroups.com> |
| In reply to | #59959 |
On Saturday, May 27, 2017 at 11:56:50 PM UTC-5, hughag...@gmail.com wrote: > On Saturday, May 27, 2017 at 9:05:01 PM UTC-7, jim.bra...@ieee.org wrote: > > On Saturday, May 27, 2017 at 10:00:39 PM UTC-5, hughag...@gmail.com wrote: > > ]>There are public-domain implementations of the PDP11 available in Verilog, > > ]> which is not true of the MSP430. > > > > http://opencores.org/project,neo430 (VHDL) > > http://opencores.org/project,openmsp430 (Verilog) > > Cool! > > I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 --- I doubt that Cecil cares about saving a few dollars however, as he is only planning on making one board for his own use --- price only matters to people who are producing boards in a high volume. > > I'm just speculating as to requirements and prices --- I don't really know anything about FPGAs, so I can't really answer the question. ]>I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 Ugh, just the opposite neo430 ~1000 LUTs openmsp430 ~1400 LUTs pdp11-34verilog 2500-3400 LUTs pdp2011 huge w11 3400+ LUTs PDP11 web links: http://www.heeltoe.com/download/pdp11/README.html http://pdp2011.sytse.net/wordpress/pdp-11/ http://opencores.org/project,w11 Modern low cost FPGAs run about 1K LUTs to the dollar. And even "small" FPGAs have 10K LUTs plus multipliers and dual port RAM
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-28 13:21 -0400 |
| Message-ID | <ogf0ov$f85$1@dont-email.me> |
| In reply to | #59966 |
jim.brakefield@ieee.org wrote on 5/28/2017 4:10 AM: > On Saturday, May 27, 2017 at 11:56:50 PM UTC-5, hughag...@gmail.com wrote: >> On Saturday, May 27, 2017 at 9:05:01 PM UTC-7, jim.bra...@ieee.org wrote: >>> On Saturday, May 27, 2017 at 10:00:39 PM UTC-5, hughag...@gmail.com wrote: >>> ]>There are public-domain implementations of the PDP11 available in Verilog, >>> ]> which is not true of the MSP430. >>> >>> http://opencores.org/project,neo430 (VHDL) >>> http://opencores.org/project,openmsp430 (Verilog) >> >> Cool! >> >> I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 --- I doubt that Cecil cares about saving a few dollars however, as he is only planning on making one board for his own use --- price only matters to people who are producing boards in a high volume. >> >> I'm just speculating as to requirements and prices --- I don't really know anything about FPGAs, so I can't really answer the question. > > ]>I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 > > Ugh, just the opposite > neo430 ~1000 LUTs > openmsp430 ~1400 LUTs > pdp11-34verilog 2500-3400 LUTs > pdp2011 huge > w11 3400+ LUTs > > PDP11 web links: > http://www.heeltoe.com/download/pdp11/README.html > http://pdp2011.sytse.net/wordpress/pdp-11/ > http://opencores.org/project,w11 I'm a bit surprised by those numbers. But then they are about the implementations rather than the ISAs. I would have expected to the two architectures to be about the same size really. The LSI-11 was a single chip (well, a few chips counting the microcode) CPU at a very early time in IC fabrication technology. I don't know how many gates were used, but I'd have expected it to be on a par with similar CPUs. Much of the size of a CPU design is in the width of the data path and the complexity of the modes as well as the extent of parallelism (not in the sense of multiple instructions in parallel, but in performing the various functions of the instruction in parallel). If I get time I may learn something about these two processors and compare them. > Modern low cost FPGAs run about 1K LUTs to the dollar. > And even "small" FPGAs have 10K LUTs plus multipliers and dual port RAM The $1/1kLUT is only a rough approximation and only holds at the very low end. Price per LUT goes down very quickly with larger sizes. No small part of the cost of most ICs relates to putting the durn things in a package with pins and testing it. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2017-05-28 11:53 -0700 |
| Message-ID | <170376cd-6b0c-4764-83a9-61e5b1fc1963@googlegroups.com> |
| In reply to | #59977 |
On Sunday, May 28, 2017 at 12:21:52 PM UTC-5, rickman wrote: > jim.brakefield@ieee.org wrote on 5/28/2017 4:10 AM: > > On Saturday, May 27, 2017 at 11:56:50 PM UTC-5, hughag...@gmail.com wrote: > >> On Saturday, May 27, 2017 at 9:05:01 PM UTC-7, jim.bra...@ieee.org wrote: > >>> On Saturday, May 27, 2017 at 10:00:39 PM UTC-5, hughag...@gmail.com wrote: > >>> ]>There are public-domain implementations of the PDP11 available in Verilog, > >>> ]> which is not true of the MSP430. > >>> > >>> http://opencores.org/project,neo430 (VHDL) > >>> http://opencores.org/project,openmsp430 (Verilog) > >> > >> Cool! > >> > >> I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 --- I doubt that Cecil cares about saving a few dollars however, as he is only planning on making one board for his own use --- price only matters to people who are producing boards in a high volume. > >> > >> I'm just speculating as to requirements and prices --- I don't really know anything about FPGAs, so I can't really answer the question. > > > > ]>I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 > > > > Ugh, just the opposite > > neo430 ~1000 LUTs > > openmsp430 ~1400 LUTs > > pdp11-34verilog 2500-3400 LUTs > > pdp2011 huge > > w11 3400+ LUTs > > > > PDP11 web links: > > http://www.heeltoe.com/download/pdp11/README.html > > http://pdp2011.sytse.net/wordpress/pdp-11/ > > http://opencores.org/project,w11 > > I'm a bit surprised by those numbers. But then they are about the > implementations rather than the ISAs. I would have expected to the two > architectures to be about the same size really. The LSI-11 was a single > chip (well, a few chips counting the microcode) CPU at a very early time in > IC fabrication technology. I don't know how many gates were used, but I'd > have expected it to be on a par with similar CPUs. Much of the size of a > CPU design is in the width of the data path and the complexity of the modes > as well as the extent of parallelism (not in the sense of multiple > instructions in parallel, but in performing the various functions of the > instruction in parallel). > > If I get time I may learn something about these two processors and compare > them. > > > > Modern low cost FPGAs run about 1K LUTs to the dollar. > > And even "small" FPGAs have 10K LUTs plus multipliers and dual port RAM > > The $1/1kLUT is only a rough approximation and only holds at the very low > end. Price per LUT goes down very quickly with larger sizes. No small part > of the cost of most ICs relates to putting the durn things in a package with > pins and testing it. > > -- > > Rick C >> I'm a bit surprised by those numbers. But then they are about the >> implementations rather than the ISAs. I would have expected to the two >> architectures to be about the same size really. First, didn't spend much time on generating these numbers. Much depends on the module you use as top. And a SOC version with many peripherals or memory caching can easily double the LUT count. Generally I run bare cores. Second the skill of the implementer can easily make a factor of two difference in LUT count or Fmax. Third, one can trade micro-code for speed. You can the find outdated spreadsheets at http://opencores.org/project,up_core_list Goal was to determine designs with best figure of merit (Fmax/LUT count adjusted for data width and number of clocks per instruction). Do not consider the results more accurate than, say, +/-30%
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-28 15:09 -0700 |
| Message-ID | <0dbb6743-1463-429d-9037-4075d0569e1a@googlegroups.com> |
| In reply to | #59985 |
On Sunday, May 28, 2017 at 11:53:38 AM UTC-7, jim.bra...@ieee.org wrote: > Third, one can trade micro-code for speed. Well, yeah! This is why it was possible to put the MiniForth processor on the Lattice isp1048 PLD in 1994 --- nobody else had a processor on that PLD, and this was generally considered to be impossible --- the hardware used pretty minimal chip resources, but the Forth primitives had to be written in assembly-language (what would typically be described as micro-code, although we didn't use that term at the time). Anyway, I don't think it is meaningful to compare how big of an FPGA is needed for various processors, without considering whether microcode is used or not, or how capable your microcode is, or a multitude of other design decisions. It is not like there is a standard way to implement a processor in an FPGA --- there are several techniques available --- there are a lot of trade-offs that the HDL writer will have to make, in regard to which feature combination (high-speed, low-size, low-price, low-power, etc.) he is trying to maximize (and, no, you can't maximize all of them).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-29 02:40 -0400 |
| Message-ID | <oggfir$j91$2@dont-email.me> |
| In reply to | #59985 |
jim.brakefield@ieee.org wrote on 5/28/2017 2:53 PM: > On Sunday, May 28, 2017 at 12:21:52 PM UTC-5, rickman wrote: >> jim.brakefield@ieee.org wrote on 5/28/2017 4:10 AM: >>> On Saturday, May 27, 2017 at 11:56:50 PM UTC-5, hughag...@gmail.com wrote: >>>> On Saturday, May 27, 2017 at 9:05:01 PM UTC-7, jim.bra...@ieee.org wrote: >>>>> On Saturday, May 27, 2017 at 10:00:39 PM UTC-5, hughag...@gmail.com wrote: >>>>> ]>There are public-domain implementations of the PDP11 available in Verilog, >>>>> ]> which is not true of the MSP430. >>>>> >>>>> http://opencores.org/project,neo430 (VHDL) >>>>> http://opencores.org/project,openmsp430 (Verilog) >>>> >>>> Cool! >>>> >>>> I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 --- I doubt that Cecil cares about saving a few dollars however, as he is only planning on making one board for his own use --- price only matters to people who are producing boards in a high volume. >>>> >>>> I'm just speculating as to requirements and prices --- I don't really know anything about FPGAs, so I can't really answer the question. >>> >>> ]>I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 >>> >>> Ugh, just the opposite >>> neo430 ~1000 LUTs >>> openmsp430 ~1400 LUTs >>> pdp11-34verilog 2500-3400 LUTs >>> pdp2011 huge >>> w11 3400+ LUTs >>> >>> PDP11 web links: >>> http://www.heeltoe.com/download/pdp11/README.html >>> http://pdp2011.sytse.net/wordpress/pdp-11/ >>> http://opencores.org/project,w11 >> >> I'm a bit surprised by those numbers. But then they are about the >> implementations rather than the ISAs. I would have expected to the two >> architectures to be about the same size really. The LSI-11 was a single >> chip (well, a few chips counting the microcode) CPU at a very early time in >> IC fabrication technology. I don't know how many gates were used, but I'd >> have expected it to be on a par with similar CPUs. Much of the size of a >> CPU design is in the width of the data path and the complexity of the modes >> as well as the extent of parallelism (not in the sense of multiple >> instructions in parallel, but in performing the various functions of the >> instruction in parallel). >> >> If I get time I may learn something about these two processors and compare >> them. >> >> >>> Modern low cost FPGAs run about 1K LUTs to the dollar. >>> And even "small" FPGAs have 10K LUTs plus multipliers and dual port RAM >> >> The $1/1kLUT is only a rough approximation and only holds at the very low >> end. Price per LUT goes down very quickly with larger sizes. No small part >> of the cost of most ICs relates to putting the durn things in a package with >> pins and testing it. >> >> -- >> >> Rick C > >>> I'm a bit surprised by those numbers. But then they are about the >>> implementations rather than the ISAs. I would have expected to the two >>> architectures to be about the same size really. > > First, didn't spend much time on generating these numbers. Much depends on the module you use as top. And a SOC version with many peripherals or memory caching can easily double the LUT count. Generally I run bare cores. > > Second the skill of the implementer can easily make a factor of two difference in LUT count or Fmax. > > Third, one can trade micro-code for speed. Yeah, that's why I said the numbers reflected the "implementations rather than the ISAs". > You can the find outdated spreadsheets at http://opencores.org/project,up_core_list > Goal was to determine designs with best figure of merit (Fmax/LUT count adjusted for data width and number of clocks per instruction). > Do not consider the results more accurate than, say, +/-30% Interesting. I will try to take a look at it. I would have worked on something like this myself, but there are so many crap cores at opencores that are poorly documented (nearly all of them) or just plain incomplete. I don't know how many are clones of some old CPU. I was turned off from looking at them further. This was maybe 2002-2005 I think. I do remember as time passed the signal to noise ratio got worse and not better. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2017-05-29 13:10 -0700 |
| Message-ID | <f04d05ce-bd6c-4d18-a1da-ee7534b78199@googlegroups.com> |
| In reply to | #60009 |
On Monday, May 29, 2017 at 1:40:45 AM UTC-5, rickman wrote: > jim.brakefield@ieee.org wrote on 5/28/2017 2:53 PM: > > On Sunday, May 28, 2017 at 12:21:52 PM UTC-5, rickman wrote: > >> jim.brakefield@ieee.org wrote on 5/28/2017 4:10 AM: > >>> On Saturday, May 27, 2017 at 11:56:50 PM UTC-5, hughag...@gmail.com wrote: > >>>> On Saturday, May 27, 2017 at 9:05:01 PM UTC-7, jim.bra...@ieee.org wrote: > >>>>> On Saturday, May 27, 2017 at 10:00:39 PM UTC-5, hughag...@gmail.com wrote: > >>>>> ]>There are public-domain implementations of the PDP11 available in Verilog, > >>>>> ]> which is not true of the MSP430. > >>>>> > >>>>> http://opencores.org/project,neo430 (VHDL) > >>>>> http://opencores.org/project,openmsp430 (Verilog) > >>>> > >>>> Cool! > >>>> > >>>> I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 --- I doubt that Cecil cares about saving a few dollars however, as he is only planning on making one board for his own use --- price only matters to people who are producing boards in a high volume. > >>>> > >>>> I'm just speculating as to requirements and prices --- I don't really know anything about FPGAs, so I can't really answer the question. > >>> > >>> ]>I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 > >>> > >>> Ugh, just the opposite > >>> neo430 ~1000 LUTs > >>> openmsp430 ~1400 LUTs > >>> pdp11-34verilog 2500-3400 LUTs > >>> pdp2011 huge > >>> w11 3400+ LUTs > >>> > >>> PDP11 web links: > >>> http://www.heeltoe.com/download/pdp11/README.html > >>> http://pdp2011.sytse.net/wordpress/pdp-11/ > >>> http://opencores.org/project,w11 > >> > >> I'm a bit surprised by those numbers. But then they are about the > >> implementations rather than the ISAs. I would have expected to the two > >> architectures to be about the same size really. The LSI-11 was a single > >> chip (well, a few chips counting the microcode) CPU at a very early time in > >> IC fabrication technology. I don't know how many gates were used, but I'd > >> have expected it to be on a par with similar CPUs. Much of the size of a > >> CPU design is in the width of the data path and the complexity of the modes > >> as well as the extent of parallelism (not in the sense of multiple > >> instructions in parallel, but in performing the various functions of the > >> instruction in parallel). > >> > >> If I get time I may learn something about these two processors and compare > >> them. > >> > >> > >>> Modern low cost FPGAs run about 1K LUTs to the dollar. > >>> And even "small" FPGAs have 10K LUTs plus multipliers and dual port RAM > >> > >> The $1/1kLUT is only a rough approximation and only holds at the very low > >> end. Price per LUT goes down very quickly with larger sizes. No small part > >> of the cost of most ICs relates to putting the durn things in a package with > >> pins and testing it. > >> > >> -- > >> > >> Rick C > > > >>> I'm a bit surprised by those numbers. But then they are about the > >>> implementations rather than the ISAs. I would have expected to the two > >>> architectures to be about the same size really. > > > > First, didn't spend much time on generating these numbers. Much depends on the module you use as top. And a SOC version with many peripherals or memory caching can easily double the LUT count. Generally I run bare cores. > > > > Second the skill of the implementer can easily make a factor of two difference in LUT count or Fmax. > > > > Third, one can trade micro-code for speed. > > Yeah, that's why I said the numbers reflected the "implementations rather > than the ISAs". > > > > You can the find outdated spreadsheets at http://opencores.org/project,up_core_list > > Goal was to determine designs with best figure of merit (Fmax/LUT count adjusted for data width and number of clocks per instruction). > > Do not consider the results more accurate than, say, +/-30% > > Interesting. I will try to take a look at it. I would have worked on > something like this myself, but there are so many crap cores at opencores > that are poorly documented (nearly all of them) or just plain incomplete. I > don't know how many are clones of some old CPU. I was turned off from > looking at them further. This was maybe 2002-2005 I think. I do remember > as time passed the signal to noise ratio got worse and not better. > > -- > > Rick C ]>there are so many crap cores at opencores that are poorly documented About 400 microprocessor cores at opencores or elsewhere on the web About 200 or so give reasonable results. Anything with less than 16 instructions is usually too simple to be useful Only about 40 written to run without modifications on any FPGA family Most of the time, a design will run on Altera or Xilinx and not both Have found about 70 Forth cores and only have results on ~20 BTW It took several months to make all the runs. Don't relish repeating the effort. It would be much easier if each design had complete project files:(
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-30 00:57 -0400 |
| Message-ID | <ogitth$r81$2@dont-email.me> |
| In reply to | #60027 |
jim.brakefield@ieee.org wrote on 5/29/2017 4:10 PM: > On Monday, May 29, 2017 at 1:40:45 AM UTC-5, rickman wrote: >> jim.brakefield@ieee.org wrote on 5/28/2017 2:53 PM: >>> On Sunday, May 28, 2017 at 12:21:52 PM UTC-5, rickman wrote: >>>> jim.brakefield@ieee.org wrote on 5/28/2017 4:10 AM: >>>>> On Saturday, May 27, 2017 at 11:56:50 PM UTC-5, hughag...@gmail.com wrote: >>>>>> On Saturday, May 27, 2017 at 9:05:01 PM UTC-7, jim.bra...@ieee.org wrote: >>>>>>> On Saturday, May 27, 2017 at 10:00:39 PM UTC-5, hughag...@gmail.com wrote: >>>>>>> ]>There are public-domain implementations of the PDP11 available in Verilog, >>>>>>> ]> which is not true of the MSP430. >>>>>>> >>>>>>> http://opencores.org/project,neo430 (VHDL) >>>>>>> http://opencores.org/project,openmsp430 (Verilog) >>>>>> >>>>>> Cool! >>>>>> >>>>>> I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 --- I doubt that Cecil cares about saving a few dollars however, as he is only planning on making one board for his own use --- price only matters to people who are producing boards in a high volume. >>>>>> >>>>>> I'm just speculating as to requirements and prices --- I don't really know anything about FPGAs, so I can't really answer the question. >>>>> >>>>> ]>I suspect that the MSP430 requires a bigger and more expensive FPGA than the PDP11 >>>>> >>>>> Ugh, just the opposite >>>>> neo430 ~1000 LUTs >>>>> openmsp430 ~1400 LUTs >>>>> pdp11-34verilog 2500-3400 LUTs >>>>> pdp2011 huge >>>>> w11 3400+ LUTs >>>>> >>>>> PDP11 web links: >>>>> http://www.heeltoe.com/download/pdp11/README.html >>>>> http://pdp2011.sytse.net/wordpress/pdp-11/ >>>>> http://opencores.org/project,w11 >>>> >>>> I'm a bit surprised by those numbers. But then they are about the >>>> implementations rather than the ISAs. I would have expected to the two >>>> architectures to be about the same size really. The LSI-11 was a single >>>> chip (well, a few chips counting the microcode) CPU at a very early time in >>>> IC fabrication technology. I don't know how many gates were used, but I'd >>>> have expected it to be on a par with similar CPUs. Much of the size of a >>>> CPU design is in the width of the data path and the complexity of the modes >>>> as well as the extent of parallelism (not in the sense of multiple >>>> instructions in parallel, but in performing the various functions of the >>>> instruction in parallel). >>>> >>>> If I get time I may learn something about these two processors and compare >>>> them. >>>> >>>> >>>>> Modern low cost FPGAs run about 1K LUTs to the dollar. >>>>> And even "small" FPGAs have 10K LUTs plus multipliers and dual port RAM >>>> >>>> The $1/1kLUT is only a rough approximation and only holds at the very low >>>> end. Price per LUT goes down very quickly with larger sizes. No small part >>>> of the cost of most ICs relates to putting the durn things in a package with >>>> pins and testing it. >>>> >>>> -- >>>> >>>> Rick C >>> >>>>> I'm a bit surprised by those numbers. But then they are about the >>>>> implementations rather than the ISAs. I would have expected to the two >>>>> architectures to be about the same size really. >>> >>> First, didn't spend much time on generating these numbers. Much depends on the module you use as top. And a SOC version with many peripherals or memory caching can easily double the LUT count. Generally I run bare cores. >>> >>> Second the skill of the implementer can easily make a factor of two difference in LUT count or Fmax. >>> >>> Third, one can trade micro-code for speed. >> >> Yeah, that's why I said the numbers reflected the "implementations rather >> than the ISAs". >> >> >>> You can the find outdated spreadsheets at http://opencores.org/project,up_core_list >>> Goal was to determine designs with best figure of merit (Fmax/LUT count adjusted for data width and number of clocks per instruction). >>> Do not consider the results more accurate than, say, +/-30% >> >> Interesting. I will try to take a look at it. I would have worked on >> something like this myself, but there are so many crap cores at opencores >> that are poorly documented (nearly all of them) or just plain incomplete. I >> don't know how many are clones of some old CPU. I was turned off from >> looking at them further. This was maybe 2002-2005 I think. I do remember >> as time passed the signal to noise ratio got worse and not better. >> >> -- >> >> Rick C > > ]>there are so many crap cores at opencores that are poorly documented > > About 400 microprocessor cores at opencores or elsewhere on the web > About 200 or so give reasonable results. > Anything with less than 16 instructions is usually too simple to be useful > Only about 40 written to run without modifications on any FPGA family > Most of the time, a design will run on Altera or Xilinx and not both > Have found about 70 Forth cores and only have results on ~20 > > BTW > It took several months to make all the runs. > Don't relish repeating the effort. > It would be much easier if each design had complete project files:( I feel your pain. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-28 02:17 -0400 |
| Message-ID | <ogdpqo$s6n$1@dont-email.me> |
| In reply to | #59955 |
hughaguilar96@gmail.com wrote on 5/27/2017 11:00 PM: > On Saturday, May 27, 2017 at 12:20:48 PM UTC-7, Cecil - k5nwa wrote: >> I'm not sure that using a limited MSP430 instruction set is the way to >> go, it has a very nice instruction set but maybe a Portable Instruction >> Set that has some added primitive like instructions might be a better >> choice or a combination of the two. One way to find out is to test some >> examples by using a decent Macro Assembler to generate the code and see >> what is useful and what is not needed. >> >> I have some pretty decent Macro Processor software that is extremely >> capable of manipulating text and do all sorts of translation, maybe it's >> time to dig it out and see how good is a Portable Assembler and how >> efficient it is at generating efficient code for multiple CPUs. > > Well, it should be a 16-bit processor. In the 32-bit world, ARM assembly-language already is the "portable assembly language" because 99% of the boards use an ARM processor. > > I just said the MSP430 because it is a common 16-bit processor. What application program do you have in mind? Is there some reason why the MSP430 wouldn't be a good choice for building a board? > > The PDP11 would be another possibility. It has these points in favor of it: > > 1.) the PDP11 has 8 registers rather than 16, which makes it a good choice for an FPGA (the number of registers is the primary factor in how much chip resources are needed, and how expensive the FPGA is). Not trying to get on your case, but you are talking outside your realm of familiarity. Many FPGAs provide small RAMs for exactly this sort of thing. In Xilinx derived parts the look up tables used to create logic can be used as register files. Each one is a 16x1 RAM (or in newer parts 64x1). So restricting the register count to 8 is of little value in conserving resources. There are many other things that impact resources in a much greater way. > 2.) There are public-domain implementations of the PDP11 available in Verilog, which is not true of the MSP430. > > 3.) The PDP11 has a very orthogonal and straight-forward instruction set, which is not true of the 8086, although it is true of the MSP430. I don't think the issue would be how nice the "virtual" instruction set is. The issue is how well it will map to the plurality of targets. Most FPGA targets will be stack machines which don't even have register files. Most likely programming a stack machine using an assembly language for a register based processor would be difficult to make efficient. Actually, it isn't even just targeting multiple processors with the programming language. The issue is writing a Forth in assembly for a register based machine and then translating that into an efficient Forth for a stack based machine. Maybe this can be done. But I don't see it as being a better solution than just taking the easy route and programming the Forth in assembly for the given target. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-28 11:50 -0500 |
| Message-ID | <ogeutn$8qh$1@dont-email.me> |
| In reply to | #59962 |
On 5/28/2017 1:17 AM, rickman wrote: > hughaguilar96@gmail.com wrote on 5/27/2017 11:00 PM: >> The PDP11 would be another possibility. It has these points in favor >> of it: >> >> 1.) the PDP11 has 8 registers rather than 16, which makes it a good >> choice for an FPGA (the number of registers is the primary factor in >> how much chip resources are needed, and how expensive the FPGA is). > > Not trying to get on your case, but you are talking outside your realm > of familiarity. Many FPGAs provide small RAMs for exactly this sort of > thing. In Xilinx derived parts the look up tables used to create logic > can be used as register files. Each one is a 16x1 RAM (or in newer > parts 64x1). So restricting the register count to 8 is of little value > in conserving resources. There are many other things that impact > resources in a much greater way. > > All kinds of useful information is coming out of this topic, I been using Lattice FPGAs so far because its a decent tool for low $, but I did buy one Xilinx board for more serious work and it's an Artix 7 board, with a lot of LUTS and Memory for use in larger CPUs. That is nice to know in case I want to create a more conventional Register based CPU. >> 2.) There are public-domain implementations of the PDP11 available in >> Verilog, which is not true of the MSP430. >> >> 3.) The PDP11 has a very orthogonal and straight-forward instruction >> set, which is not true of the 8086, although it is true of the MSP430. > > I don't think the issue would be how nice the "virtual" instruction set > is. The issue is how well it will map to the plurality of targets. Most > FPGA targets will be stack machines which don't even have register > files. Most likely programming a stack machine using an assembly > language for a register based processor would be difficult to make > efficient. Stack machines is my current line of interest so far the richest machine I've used uses the following registers; TOS top of Data Stack TRS top of Return Stack W a temporary register IX an Index register to use with memory access specially in accessing arrays of data. IP Instruction Pointer Add to that a Data and Return Stack but those are not registers but their pointers use a small register not directly accessible. Not a whole lot of registers specially when compared to a MSP430 CPU with 16 general registers, or an ARM CPU with 32 general registers. > > Actually, it isn't even just targeting multiple processors with the > programming language. The issue is writing a Forth in assembly for a > register based machine and then translating that into an efficient Forth > for a stack based machine. Maybe this can be done. But I don't see it > as being a better solution than just taking the easy route and > programming the Forth in assembly for the given target. > Using PAC (Portable Assembler Code) mnemonics when moving the code to another CPU the primitives and other assembler code does not need to be changed, only the assembler needs to be changed and that would need changes no matter what scheme one uses, so it is simpler to port using a PAC assembler. It's not the traditional way where you have to re-write all the assembly code but times are changing we are not in the 70s anymore. I tend to think that this is a superior way to write a Forth that is efficient and easy to port qualities that with traditional assemble code are at odds with each other. Mind you no matter what one uses there are some CPU specific items that need to be update such clock management and I/O but those need changing with a new CPU no matter what way one uses so it something to be dealt with. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-28 13:52 -0400 |
| Message-ID | <ogf2ir$leh$1@dont-email.me> |
| In reply to | #59974 |
Cecil Bayona wrote on 5/28/2017 12:50 PM: > On 5/28/2017 1:17 AM, rickman wrote: >> hughaguilar96@gmail.com wrote on 5/27/2017 11:00 PM: > >>> The PDP11 would be another possibility. It has these points in favor of it: >>> >>> 1.) the PDP11 has 8 registers rather than 16, which makes it a good >>> choice for an FPGA (the number of registers is the primary factor in how >>> much chip resources are needed, and how expensive the FPGA is). >> >> Not trying to get on your case, but you are talking outside your realm of >> familiarity. Many FPGAs provide small RAMs for exactly this sort of >> thing. In Xilinx derived parts the look up tables used to create logic can >> be used as register files. Each one is a 16x1 RAM (or in newer parts >> 64x1). So restricting the register count to 8 is of little value in >> conserving resources. There are many other things that impact resources >> in a much greater way. >> >> > > All kinds of useful information is coming out of this topic, I been using > Lattice FPGAs so far because its a decent tool for low $, but I did buy one > Xilinx board for more serious work and it's an Artix 7 board, with a lot of > LUTS and Memory for use in larger CPUs. That is nice to know in case I want > to create a more conventional Register based CPU. All of the Lattice FPGAs have the LUT RAM available as distributed RAM like the Xilinx parts. The main Lattice FPGA lines are from licenses obtained by buying the ORCA line of FPGAs from Lucent. These licenses in turn were bought by Lucent from Xilinx at a time when Lucent was second sourcing the basic XC3000 and maybe the XC4000 devices. The iCE40 parts are from Silicon Blue bought some years ago. The basic design patents on Xilinx FPGAs have expired so many functions of Xilinx LUTs are available to all including distributed memory. >>> 2.) There are public-domain implementations of the PDP11 available in >>> Verilog, which is not true of the MSP430. >>> >>> 3.) The PDP11 has a very orthogonal and straight-forward instruction set, >>> which is not true of the 8086, although it is true of the MSP430. >> >> I don't think the issue would be how nice the "virtual" instruction set >> is. The issue is how well it will map to the plurality of targets. Most >> FPGA targets will be stack machines which don't even have register files. >> Most likely programming a stack machine using an assembly language for a >> register based processor would be difficult to make efficient. > > Stack machines is my current line of interest so far the richest machine > I've used uses the following registers; > > TOS top of Data Stack > TRS top of Return Stack > W a temporary register > IX an Index register to use with memory access specially in accessing arrays > of data. > IP Instruction Pointer > > Add to that a Data and Return Stack but those are not registers but their > pointers use a small register not directly accessible. > > Not a whole lot of registers specially when compared to a MSP430 CPU with 16 > general registers, or an ARM CPU with 32 general registers. Big difference... The registers in a stack machine need to be separate, so they use FFs for the registers and LUTs for the input and output muxes. A RAM is a bunch of registers with output muxes to share the output bus. A register file can be efficiently implemented in a small RAM which utilizes the internal muxes rather than LUTs. Regardless of how many registers a design has, the real driver of logic usage is usually muxes. You can have one register (top of data stack for example) which is fed by many sources and the mux will end up being huge. I know this from experience... ;) The way to keep your design small and efficient is to focus on the micro-ops required to implement an instruction to keep these interconnects to a minimum. The reason why an ARM CPU in an FPGA will be much bigger than an MSP430 is the complexity of interconnections. I think it is the M1 that is intended for FPGA usage. I expect this is very stripped own using more cycles with less happening in each one compared to an M0. >> Actually, it isn't even just targeting multiple processors with the >> programming language. The issue is writing a Forth in assembly for a >> register based machine and then translating that into an efficient Forth >> for a stack based machine. Maybe this can be done. But I don't see it as >> being a better solution than just taking the easy route and programming >> the Forth in assembly for the given target. >> > > Using PAC (Portable Assembler Code) mnemonics when moving the code to > another CPU the primitives and other assembler code does not need to be > changed, only the assembler needs to be changed and that would need changes > no matter what scheme one uses, so it is simpler to port using a PAC > assembler. It's not the traditional way where you have to re-write all the > assembly code but times are changing we are not in the 70s anymore. You seem to be laser focused on the idea that rewriting the tool has to be easier than rewriting the code. I don't know of any portable assemblers that work the way you describe. So you will need to write this from scratch. > I tend to think that this is a superior way to write a Forth that is > efficient and easy to port qualities that with traditional assemble code are > at odds with each other. Mind you no matter what one uses there are some CPU > specific items that need to be update such clock management and I/O but > those need changing with a new CPU no matter what way one uses so it > something to be dealt with. I don't see any advantage at all. Either way you need to generate native code for the processor you are using. One way you recode a few Forth words which gives you native code *and* gives you an opportunity to optimize the code easily. The other way you have existing "portable" assembler code which now has to be translated/compiled to native code by a tool that needs to be rewritten for the target processor. Then if you want optimized code you likely need to rewrite the "portable" assembly code. I am ready to return to my self-assigned task of documenting Mecrisp on the MSP430. Let me know how your project goes. If you need any advice on FPGA CPUs, I'm happy to lend my experience. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-28 13:47 -0500 |
| Message-ID | <ogf5pj$10u$1@dont-email.me> |
| In reply to | #59980 |
On 5/28/2017 12:52 PM, rickman wrote: > Cecil Bayona wrote on 5/28/2017 12:50 PM: >> On 5/28/2017 1:17 AM, rickman wrote: > > All of the Lattice FPGAs have the LUT RAM available as distributed RAM > like the Xilinx parts. The main Lattice FPGA lines are from licenses > obtained by buying the ORCA line of FPGAs from Lucent. These licenses > in turn were bought by Lucent from Xilinx at a time when Lucent was > second sourcing the basic XC3000 and maybe the XC4000 devices. > > The iCE40 parts are from Silicon Blue bought some years ago. The basic > design patents on Xilinx FPGAs have expired so many functions of Xilinx > LUTs are available to all including distributed memory. > > >> >> Stack machines is my current line of interest so far the richest machine >> I've used uses the following registers; >> >> TOS top of Data Stack >> TRS top of Return Stack >> W a temporary register >> IX an Index register to use with memory access specially in accessing >> arrays >> of data. >> IP Instruction Pointer >> >> Add to that a Data and Return Stack but those are not registers but their >> pointers use a small register not directly accessible. >> >> Not a whole lot of registers specially when compared to a MSP430 CPU >> with 16 >> general registers, or an ARM CPU with 32 general registers. > > Big difference... The registers in a stack machine need to be separate, > so they use FFs for the registers and LUTs for the input and output > muxes. A RAM is a bunch of registers with output muxes to share the > output bus. A register file can be efficiently implemented in a small > RAM which utilizes the internal muxes rather than LUTs. > A normal register file uses RAM because they are all wired the same but a Forth register needs to be FF because the registers are not wired to the same places? I assume then that in a regular register file CPU the use of dual ported RAM allows the use of two register at the same time. > Regardless of how many registers a design has, the real driver of logic > usage is usually muxes. You can have one register (top of data stack > for example) which is fed by many sources and the mux will end up being > huge. I know this from experience... ;) > > The way to keep your design small and efficient is to focus on the > micro-ops required to implement an instruction to keep these > interconnects to a minimum. > Since the CPUs that I'm interested in for the most part single clock to execute an instruction types then one ends up using an lot of muxes. >> Using PAC (Portable Assembler Code) mnemonics when moving the code to >> another CPU the primitives and other assembler code does not need to be >> changed, only the assembler needs to be changed and that would need >> changes >> no matter what scheme one uses, so it is simpler to port using a PAC >> assembler. It's not the traditional way where you have to re-write all >> the >> assembly code but times are changing we are not in the 70s anymore. > > You seem to be laser focused on the idea that rewriting the tool has to > be easier than rewriting the code. I don't know of any portable > assemblers that work the way you describe. So you will need to write > this from scratch. That is because changing the PAC assembler is a fairly simple task versus re-writing all the primitives. Don't forget that in the conventional way you have to do massive changes to the assembler and then you have to rewrite all the primitives and associated assembler code. While using PAC all we need to change is the code generated by the assembler and the job is done. That is a lot easier than a rewrite of the assembler and all the code words. In either case the tools have to be changed there is no getting away from that, with PAC the changes are fewer and simpler. In either case one needs to change a few specific items having to do with I/O and CPU items like writing to Flash so neither has an advantage there. > > >> I tend to think that this is a superior way to write a Forth that is >> efficient and easy to port qualities that with traditional assemble >> code are >> at odds with each other. Mind you no matter what one uses there are >> some CPU >> specific items that need to be update such clock management and I/O but >> those need changing with a new CPU no matter what way one uses so it >> something to be dealt with. > > I don't see any advantage at all. Either way you need to generate > native code for the processor you are using. One way you recode a few > Forth words which gives you native code *and* gives you an opportunity > to optimize the code easily. The other way you have existing "portable" > assembler code which now has to be translated/compiled to native code by > a tool that needs to be rewritten for the target processor. Then if you > want optimized code you likely need to rewrite the "portable" assembly > code. That is because I'm laser focused as you mentioned, PAC code can be optimized just the same as native code, the assembler generates native code its just that the mnemonics are the same for many CPUs so the assembler needs fewer changes to it when porting to a new CPU. > > I am ready to return to my self-assigned task of documenting Mecrisp on > the MSP430. Let me know how your project goes. If you need any advice > on FPGA CPUs, I'm happy to lend my experience. > Not an exciting task but one that needs to be done. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web