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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-05-28 16:11 -0700 |
| Message-ID | <87bmqcpoem.fsf@nightsong.com> |
| In reply to | #59965 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: > Yes libraries are in the C development environment of about every > microprocessor. Now give me one example of an AD conversion or > switching to low power mode that is portable between two different > micro processors using the portable C. This is sort of what the Arduino environment provides.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-29 02:11 -0400 |
| Message-ID | <oggdrq$ftc$1@dont-email.me> |
| In reply to | #59992 |
Paul Rubin wrote on 5/28/2017 7:11 PM: > albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >> Yes libraries are in the C development environment of about every >> microprocessor. Now give me one example of an AD conversion or >> switching to low power mode that is portable between two different >> micro processors using the portable C. > > This is sort of what the Arduino environment provides. Isn't the Arduino written for AVR processors? Other people may have written Arduino like libraries, but if the thing being controlled doesn't work the same way, you can't control it using the same code. I suppose if you abstract away the hardware differences you can use different hardware the same way, but at what cost? There are tons of ADCs for example. They aren't intended for the same tasks and don't have the same functionality. So there is no library that will utilize them properly without changes in the calling code. I guess this is becoming a bit of beating a dead horse. I will be interested in seeing what Cecil comes up with. :) -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-29 01:54 -0500 |
| Message-ID | <ogggc3$mpo$1@dont-email.me> |
| In reply to | #60007 |
On 5/29/2017 1:11 AM, rickman wrote: > Paul Rubin wrote on 5/28/2017 7:11 PM: >> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >>> Yes libraries are in the C development environment of about every >>> microprocessor. Now give me one example of an AD conversion or >>> switching to low power mode that is portable between two different >>> micro processors using the portable C. >> >> This is sort of what the Arduino environment provides. > > Isn't the Arduino written for AVR processors? Other people may have > written Arduino like libraries, but if the thing being controlled > doesn't work the same way, you can't control it using the same code. I > suppose if you abstract away the hardware differences you can use > different hardware the same way, but at what cost? There are tons of > ADCs for example. They aren't intended for the same tasks and don't > have the same functionality. So there is no library that will utilize > them properly without changes in the calling code. > > I guess this is becoming a bit of beating a dead horse. > > I will be interested in seeing what Cecil comes up with. :) > The Arduino software platform and its libraries are available for AVR, MSP430, PIC, dsPIC, PIC 32, MIPS, ARM, and esp8266 that I know off, there maybe others. They all program the same way. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-29 03:22 -0400 |
| Message-ID | <oggi0t$qh4$2@dont-email.me> |
| In reply to | #60010 |
Cecil Bayona wrote on 5/29/2017 2:54 AM: > On 5/29/2017 1:11 AM, rickman wrote: >> Paul Rubin wrote on 5/28/2017 7:11 PM: >>> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >>>> Yes libraries are in the C development environment of about every >>>> microprocessor. Now give me one example of an AD conversion or >>>> switching to low power mode that is portable between two different >>>> micro processors using the portable C. >>> >>> This is sort of what the Arduino environment provides. >> >> Isn't the Arduino written for AVR processors? Other people may have >> written Arduino like libraries, but if the thing being controlled doesn't >> work the same way, you can't control it using the same code. I suppose if >> you abstract away the hardware differences you can use different hardware >> the same way, but at what cost? There are tons of ADCs for example. They >> aren't intended for the same tasks and don't have the same functionality. >> So there is no library that will utilize them properly without changes in >> the calling code. >> >> I guess this is becoming a bit of beating a dead horse. >> >> I will be interested in seeing what Cecil comes up with. :) >> > The Arduino software platform and its libraries are available for AVR, > MSP430, PIC, dsPIC, PIC 32, MIPS, ARM, and esp8266 that I know off, there > maybe others. They all program the same way. Really, so you can just take source code for an application and it will run on any of those processors without modification? Then I guess your job is done! -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-28 15:46 -0700 |
| Message-ID | <b244f5cf-4da6-4b8b-8745-9ed696dfbdbf@googlegroups.com> |
| In reply to | #59893 |
On Saturday, May 27, 2017 at 2:09:48 PM UTC+9, rickman wrote: > [...] > > "I would like to have my own software". Why is this important? I don't > get it. If you have software you can use as you wish, why does it > matter who wrote it? Maybe he thinks he'd understand software he wrote better than software others wrote? -- Joel Rees Delusions of being a novelist: http://reiisi.blogspot.com/p/novels-i-am-writing.html
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-27 01:23 -0500 |
| Message-ID | <X-idnVs5bsfNhrTEnZ2dnUU7-c2dnZ2d@supernews.com> |
| In reply to | #59883 |
Cecil Bayona <cbayona@cbayona.com> wrote: > I'm working on a Forth system with the following properties in order of > importance; > > 1. Easy to migrate to other CPUs. > 2. Good and simple to understand. > 3. Small > 4. Fast I'm not sure that it's possible to have 1 and 2. Mind you, that depends on how you define "easy": if it includes rewriting a bunch of primitives for each CPU, then it's possible to have both. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-27 09:29 -0500 |
| Message-ID | <ogc2a1$uv7$1@dont-email.me> |
| In reply to | #59900 |
On 5/27/2017 1:23 AM, Andrew Haley wrote: > Cecil Bayona <cbayona@cbayona.com> wrote: >> I'm working on a Forth system with the following properties in order of >> importance; >> >> 1. Easy to migrate to other CPUs. If the primitives are written in C then it's easy to port it to another CPU that has a C compiler, just re-compile. If it's a FPGA CPU with no C compiler then one would need to write an assembler for the device, specially with a stack CPU that would be a very simple assembler, the primitives would be either in assembler or the instructions are the primitives. >> 2. Good and simple to understand. That depends on the Forth implemented, since this is for embedded CPUs, keeping the Forth simple entails being selective about what is in it, no 2400 word Forth but keeping it under 300 words. >> 3. Small A token Forth would be very small since most Forth words would take one byte. Keep the number of words down to the necessities will help keep it small. >> 4. Fast Here is the big issue, items 1-3 make it hard for it to be fast except in the case of a FPGA CPU, if the CPU will be used a lot and it needs to be faster, then a re-write of the primitives to use assembler will speed it up, this is to be done only when the speed is vital. > > I'm not sure that it's possible to have 1 and 2. Mind you, that > depends on how you define "easy": if it includes rewriting a bunch of > primitives for each CPU, then it's possible to have both. > > Andrew. > The alternative to writing a Forth from scratch is to use an existing compiler and modify the assembler and Meta-compiler for each CPU, which is not that bad. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-05-27 11:36 -0700 |
| Message-ID | <87fufqp2or.fsf@nightsong.com> |
| In reply to | #59922 |
Cecil Bayona <cbayona@cbayona.com> writes: > A token Forth would be very small since most Forth words would take > one byte. Keep the number of words down to the necessities will help > keep it small. But then you need the VM that can understand what to do about the byte codes, and there's its overhead, etc.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-27 14:25 -0500 |
| Message-ID | <ogcjjv$o3a$1@dont-email.me> |
| In reply to | #59939 |
On 5/27/2017 1:36 PM, Paul Rubin wrote: > Cecil Bayona <cbayona@cbayona.com> writes: >> A token Forth would be very small since most Forth words would take >> one byte. Keep the number of words down to the necessities will help >> keep it small. > > But then you need the VM that can understand what to do about the byte > codes, and there's its overhead, etc. > Not much overhead if one has an array of the addresses of the primitive, use the token as the index and go to the routine point at. This might become moot in any case as Hugh Aguilar has pointed to a possible solution that requires no High Level Language at all while being easy to port. I will do some testing to see if it works out OK. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-05-27 21:58 -0400 |
| Message-ID | <20170527215826.4448fc1e@_> |
| In reply to | #59922 |
On Sat, 27 May 2017 09:29:34 -0500 Cecil Bayona <cbayona@cbayona.com> wrote: > If the primitives are written in C then it's easy to port it to > another CPU that has a C compiler, just re-compile. For the most part, I think that's true, as my ITC Forth interpreter has it's primitives in C and the rest in Forth. However, IIRC, the loop constructs in Forth use the processor overflow flag. This is not available in C. You'll have to work around this. Another issue I had was with the line buffering that's used by default with C. Each compiler has different implementations of non-buffered input, and sometimes different functions to change the settings. > >> 2. Good and simple to understand. > > That depends on the Forth implemented, since this is for embedded > CPUs, keeping the Forth simple entails being selective about what is > in it, no 2400 word Forth but keeping it under 300 words. Are you wanting the Forth code or C code to be "good and simple to understand"? If most of the code is in Forth and only the primitives are in C, then it'll be understandable to a Forth programmer, for the most part. > >> 3. Small > > A token Forth would be very small since most Forth words would take > one byte. Keep the number of words down to the necessities will help > keep it small. If your Forth is based on primitives, like eForth, then the size is primarily dependent on how many high-level Forth words you create. > >> 4. Fast > > Here is the big issue, items 1-3 make it hard for it to be fast > except in the case of a FPGA CPU, if the CPU will be used a lot and > it needs to be faster, then a re-write of the primitives to use > assembler will speed it up, this is to be done only when the speed is > vital. You'll need 30 to 60 or so primitives to prevent it from being exceptionally slow. These should mostly fit cleanly onto the instruction set of the processor you use. You can speed it up somewhat by using efficient definitions for stack operations and Forth words that execute frequently. Rod Pemberton --
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-27 11:20 -0700 |
| Message-ID | <5e95a740-f9cd-4f6b-a806-59afb1e5e5d6@googlegroups.com> |
| In reply to | #59900 |
On Friday, May 26, 2017 at 11:23:17 PM UTC-7, Andrew Haley wrote: > Cecil Bayona <cbayona@cbayona.com> wrote: > > I'm working on a Forth system with the following properties in order of > > importance; > > > > 1. Easy to migrate to other CPUs. > > 2. Good and simple to understand. > > 3. Small > > 4. Fast > > I'm not sure that it's possible to have 1 and 2. Mind you, that > depends on how you define "easy": if it includes rewriting a bunch of > primitives for each CPU, then it's possible to have both. > > Andrew. I think that both #1 and #2 are possible. Write an assembler for the MSP430 and write your Forth in this assembly-language and have your Forth use this assembly-language to generate code. Use a subset of the MSP430, rather than the entire instruction set (think: "MSP430; the Good Parts"). To port your Forth to another processor, you rewrite the assembler so it generates code for the new processor rather than for the MSP430. You do NOT rewrite your Forth system. The PIC24 should be easy because most of the MSP430 instructions will correspond one-to-one with PIC24 instructions. The PIC24 has more registers than the MSP430 and more addressing modes, but you won't use any of these extra features, so you won't be using the full power of the PIC24. The 6812 will be more difficult because you don't have as many registers as the MSP430. Some of the MSP430 registers will have to be implemented as pseudo-registers (memory variables). Some of the MSP430 instructions will generate multiple 6812 instructions rather than correspond one-to-one. I picked the MSP430 as the target to write your original system for, because it is a popular processor and is pretty useful. The MSP430 is in the middle of the field --- some processors, such as the PIC24, are more powerful --- some processors, such as the 6812, are less powerful. I think that your idea of using C or Go is totally wrong --- you are introducing huge complications for yourself, and your end result will be inefficient --- use the technique that I described and you will have an uncomplicated system, easy portability, and good efficiency (especially on the MSP430). On Saturday, May 27, 2017 at 11:13:18 AM UTC-7, Cecil - k5nwa wrote: > I get the impression that just about everyone with a few exceptions is > against a custom compiler, so pray tell where does one get compilers for > custom or oddball CPUs? > > The negativity is off the chart but then this is c.l.f so I should have > expected it. I'm in favor of a custom compiler! Don't listen to the nattering nabobs of negativity --- listen to me --- Mr. Positive!
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-27 15:20 -0400 |
| Message-ID | <ogcjan$mgr$1@dont-email.me> |
| In reply to | #59936 |
hughaguilar96@gmail.com wrote on 5/27/2017 2:20 PM: > On Friday, May 26, 2017 at 11:23:17 PM UTC-7, Andrew Haley wrote: >> Cecil Bayona <cbayona@cbayona.com> wrote: >>> I'm working on a Forth system with the following properties in order of >>> importance; >>> >>> 1. Easy to migrate to other CPUs. >>> 2. Good and simple to understand. >>> 3. Small >>> 4. Fast >> >> I'm not sure that it's possible to have 1 and 2. Mind you, that >> depends on how you define "easy": if it includes rewriting a bunch of >> primitives for each CPU, then it's possible to have both. >> >> Andrew. > > I think that both #1 and #2 are possible. Write an assembler for the MSP430 and write your Forth in this assembly-language and have your Forth use this assembly-language to generate code. Use a subset of the MSP430, rather than the entire instruction set (think: "MSP430; the Good Parts"). > > To port your Forth to another processor, you rewrite the assembler so it generates code for the new processor rather than for the MSP430. You do NOT rewrite your Forth system. > > The PIC24 should be easy because most of the MSP430 instructions will correspond one-to-one with PIC24 instructions. The PIC24 has more registers than the MSP430 and more addressing modes, but you won't use any of these extra features, so you won't be using the full power of the PIC24. > > The 6812 will be more difficult because you don't have as many registers as the MSP430. Some of the MSP430 registers will have to be implemented as pseudo-registers (memory variables). Some of the MSP430 instructions will generate multiple 6812 instructions rather than correspond one-to-one. > > I picked the MSP430 as the target to write your original system for, because it is a popular processor and is pretty useful. The MSP430 is in the middle of the field --- some processors, such as the PIC24, are more powerful --- some processors, such as the 6812, are less powerful. > > I think that your idea of using C or Go is totally wrong --- you are introducing huge complications for yourself, and your end result will be inefficient --- use the technique that I described and you will have an uncomplicated system, easy portability, and good efficiency (especially on the MSP430). > > On Saturday, May 27, 2017 at 11:13:18 AM UTC-7, Cecil - k5nwa wrote: >> I get the impression that just about everyone with a few exceptions is >> against a custom compiler, so pray tell where does one get compilers for >> custom or oddball CPUs? >> >> The negativity is off the chart but then this is c.l.f so I should have >> expected it. > > I'm in favor of a custom compiler! > Don't listen to the nattering nabobs of negativity --- listen to me --- Mr. Positive! Let's compare the three methods of trying to port a single Forth to a variety of targets. Those targets will only include embedded processors which makes the job a bit less global. It will include typical small CPUs like the ARM CM3 and CM4 as well as other processors like the MSP430 and AVR, PIC, et cetera. Let's also include various stack processors like the J1, B16, F18A, et cetera. I won't list any particularly, but rather the issues involved in porting to them. The methods I'll list include C coding, assembly coding, Forth with a metacompiler and finally a "special" language tailored to this application (essentially a custom language along with a custom back end for each processor). I'll add an X to a column if that issue requires changes to source or tool for that method in all or nearly all cases. I'll use a lower case 'c' when it is required only for custom processors. Issues C coding Assembly Forth Special --------------------- --------- -------- ------ ------- Processor c X X X Flash memory X X X X Comms c X c X Memory map X X X X Peripherals X X X X Board level functions X X X X Speed optimizations X X X X Memory use optimizations X X X X What other issues will require special handling? I wasn't expecting this to show all methods to require special handling in almost all cases, but I guess that's the way it is. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-27 14:20 -0500 |
| Message-ID | <ogcjbv$n7p$1@dont-email.me> |
| In reply to | #59936 |
On 5/27/2017 1:20 PM, hughaguilar96@gmail.com wrote: > On Friday, May 26, 2017 at 11:23:17 PM UTC-7, Andrew Haley wrote: >> Cecil Bayona <cbayona@cbayona.com> wrote: >>> I'm working on a Forth system with the following properties in order of >>> importance; >>> >>> 1. Easy to migrate to other CPUs. >>> 2. Good and simple to understand. >>> 3. Small >>> 4. Fast >> >> I'm not sure that it's possible to have 1 and 2. Mind you, that >> depends on how you define "easy": if it includes rewriting a bunch of >> primitives for each CPU, then it's possible to have both. >> >> Andrew. > > I think that both #1 and #2 are possible. Write an assembler for the MSP430 and write your Forth in this assembly-language and have your Forth use this assembly-language to generate code. Use a subset of the MSP430, rather than the entire instruction set (think: "MSP430; the Good Parts"). I already have source code for eForth for the MSP430 in Direct Threaded, and Subroutine Threaded versions written in MSP430 Assembler. > > To port your Forth to another processor, you rewrite the assembler so it generates code for the new processor rather than for the MSP430. You do NOT rewrite your Forth system. > > The PIC24 should be easy because most of the MSP430 instructions will correspond one-to-one with PIC24 instructions. The PIC24 has more registers than the MSP430 and more addressing modes, but you won't use any of these extra features, so you won't be using the full power of the PIC24. > > The 6812 will be more difficult because you don't have as many registers as the MSP430. Some of the MSP430 registers will have to be implemented as pseudo-registers (memory variables). Some of the MSP430 instructions will generate multiple 6812 instructions rather than correspond one-to-one. > > I picked the MSP430 as the target to write your original system for, because it is a popular processor and is pretty useful. The MSP430 is in the middle of the field --- some processors, such as the PIC24, are more powerful --- some processors, such as the 6812, are less powerful. > > I think that your idea of using C or Go is totally wrong --- you are introducing huge complications for yourself, and your end result will be inefficient --- use the technique that I described and you will have an uncomplicated system, easy portability, and good efficiency (especially on the MSP430). > Interesting idea, I've read about it before but it was not in my thoughts. There have been proposals for a Portable Assembler code many times, and Go supports assembler mixed with high level code which is not unusual but it uses it's own Portable Assembler Code so for various CPUs the assembler code is not changed but the compiler generates code according to the CPU one is compiling for. It uses a generic register and instruction set that is basic to many CPUs, so you end up with software using assembler that supports several CPUs without any changes. > On Saturday, May 27, 2017 at 11:13:18 AM UTC-7, Cecil - k5nwa wrote: >> I get the impression that just about everyone with a few exceptions is >> against a custom compiler, so pray tell where does one get compilers for >> custom or oddball CPUs? >> >> The negativity is off the chart but then this is c.l.f so I should have >> expected it. > > I'm in favor of a custom compiler! > Don't listen to the nattering nabobs of negativity --- listen to me --- Mr. Positive! > Interesting proposal and I can see it being faster than using C or Go while still being easy to port. 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. LOL.....Mr Positive, allrighty then. Thanks, something to consider as it might get high scores in all four categories. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-27 18:33 -0400 |
| Message-ID | <ogcum7$r9t$2@dont-email.me> |
| In reply to | #59945 |
Cecil Bayona wrote on 5/27/2017 3:20 PM: > On 5/27/2017 1:20 PM, hughaguilar96@gmail.com wrote: >> On Friday, May 26, 2017 at 11:23:17 PM UTC-7, Andrew Haley wrote: >>> Cecil Bayona <cbayona@cbayona.com> wrote: >>>> I'm working on a Forth system with the following properties in order of >>>> importance; >>>> >>>> 1. Easy to migrate to other CPUs. >>>> 2. Good and simple to understand. >>>> 3. Small >>>> 4. Fast >>> >>> I'm not sure that it's possible to have 1 and 2. Mind you, that >>> depends on how you define "easy": if it includes rewriting a bunch of >>> primitives for each CPU, then it's possible to have both. >>> >>> Andrew. >> >> I think that both #1 and #2 are possible. Write an assembler for the >> MSP430 and write your Forth in this assembly-language and have your Forth >> use this assembly-language to generate code. Use a subset of the MSP430, >> rather than the entire instruction set (think: "MSP430; the Good Parts"). > > I already have source code for eForth for the MSP430 in Direct Threaded, and > Subroutine Threaded versions written in MSP430 Assembler. > >> >> To port your Forth to another processor, you rewrite the assembler so it >> generates code for the new processor rather than for the MSP430. You do >> NOT rewrite your Forth system. >> >> The PIC24 should be easy because most of the MSP430 instructions will >> correspond one-to-one with PIC24 instructions. The PIC24 has more >> registers than the MSP430 and more addressing modes, but you won't use any >> of these extra features, so you won't be using the full power of the PIC24. >> >> The 6812 will be more difficult because you don't have as many registers >> as the MSP430. Some of the MSP430 registers will have to be implemented as >> pseudo-registers (memory variables). Some of the MSP430 instructions will >> generate multiple 6812 instructions rather than correspond one-to-one. >> >> I picked the MSP430 as the target to write your original system for, >> because it is a popular processor and is pretty useful. The MSP430 is in >> the middle of the field --- some processors, such as the PIC24, are more >> powerful --- some processors, such as the 6812, are less powerful. >> >> I think that your idea of using C or Go is totally wrong --- you are >> introducing huge complications for yourself, and your end result will be >> inefficient --- use the technique that I described and you will have an >> uncomplicated system, easy portability, and good efficiency (especially on >> the MSP430). >> > > Interesting idea, I've read about it before but it was not in my thoughts. > There have been proposals for a Portable Assembler code many times, and Go > supports assembler mixed with high level code which is not unusual but it > uses it's own Portable Assembler Code so for various CPUs the assembler code > is not changed but the compiler generates code according to the CPU one is > compiling for. It uses a generic register and instruction set that is basic > to many CPUs, so you end up with software using assembler that supports > several CPUs without any changes. > >> On Saturday, May 27, 2017 at 11:13:18 AM UTC-7, Cecil - k5nwa wrote: >>> I get the impression that just about everyone with a few exceptions is >>> against a custom compiler, so pray tell where does one get compilers for >>> custom or oddball CPUs? >>> >>> The negativity is off the chart but then this is c.l.f so I should have >>> expected it. >> >> I'm in favor of a custom compiler! >> Don't listen to the nattering nabobs of negativity --- listen to me --- >> Mr. Positive! >> > > Interesting proposal and I can see it being faster than using C or Go while > still being easy to port. > > 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. > > > LOL.....Mr Positive, allrighty then. > > Thanks, something to consider as it might get high scores in all four > categories. I'm not sure what advantage "portable" assembly language would have over a metacompiled Forth. Both approaches require writing a back end for the tool. A metacompiled Forth has one HUGE advantage for developing a Forth system... it's in Forth. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-27 18:50 -0500 |
| Message-ID | <ogd35r$9cp$1@dont-email.me> |
| In reply to | #59951 |
On 5/27/2017 5:33 PM, rickman wrote: > Cecil Bayona wrote on 5/27/2017 3:20 PM: >> On 5/27/2017 1:20 PM, hughaguilar96@gmail.com wrote: >> >>> >>> To port your Forth to another processor, you rewrite the assembler so it >>> generates code for the new processor rather than for the MSP430. You do >>> NOT rewrite your Forth system. >>> >>> The PIC24 should be easy because most of the MSP430 instructions will >>> correspond one-to-one with PIC24 instructions. The PIC24 has more >>> registers than the MSP430 and more addressing modes, but you won't >>> use any >>> of these extra features, so you won't be using the full power of the >>> PIC24. >>> >>> The 6812 will be more difficult because you don't have as many registers >>> as the MSP430. Some of the MSP430 registers will have to be >>> implemented as >>> pseudo-registers (memory variables). Some of the MSP430 instructions >>> will >>> generate multiple 6812 instructions rather than correspond one-to-one. >>> >>> I picked the MSP430 as the target to write your original system for, >>> because it is a popular processor and is pretty useful. The MSP430 is in >>> the middle of the field --- some processors, such as the PIC24, are more >>> powerful --- some processors, such as the 6812, are less powerful. >>> >>> I think that your idea of using C or Go is totally wrong --- you are >>> introducing huge complications for yourself, and your end result will be >>> inefficient --- use the technique that I described and you will have an >>> uncomplicated system, easy portability, and good efficiency >>> (especially on >>> the MSP430). >>> >> >> Interesting idea, I've read about it before but it was not in my >> thoughts. >> There have been proposals for a Portable Assembler code many times, >> and Go >> supports assembler mixed with high level code which is not unusual but it >> uses it's own Portable Assembler Code so for various CPUs the >> assembler code >> is not changed but the compiler generates code according to the CPU >> one is >> compiling for. It uses a generic register and instruction set that is >> basic >> to many CPUs, so you end up with software using assembler that supports >> several CPUs without any changes. >> >> >> Interesting proposal and I can see it being faster than using C or Go >> while >> still being easy to port. >> >> 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. >> >> >> LOL.....Mr Positive, allrighty then. >> >> Thanks, something to consider as it might get high scores in all four >> categories. > > I'm not sure what advantage "portable" assembly language would have over > a metacompiled Forth. Both approaches require writing a back end for > the tool. A metacompiled Forth has one HUGE advantage for developing a > Forth system... it's in Forth. > It would be part of the Forth System and written in Forth, instead of having a specific assembler to each CPU with it's own set on mnemonics it would use a Portable Instruction Set, the same mnemonics for all the CPUs, to change it to a different CPU one would change the generated code which is fairly easy to do. Primitives would use the Portable Instructions Set so there would be no need to change them when switching to a different CPU as the assembler would generate the machine code for the CPU currently in use. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-27 20:13 -0400 |
| Message-ID | <ogd4gv$ck9$1@dont-email.me> |
| In reply to | #59952 |
Cecil Bayona wrote on 5/27/2017 7:50 PM: > On 5/27/2017 5:33 PM, rickman wrote: >> Cecil Bayona wrote on 5/27/2017 3:20 PM: >>> On 5/27/2017 1:20 PM, hughaguilar96@gmail.com wrote: > >>> >>>> >>>> To port your Forth to another processor, you rewrite the assembler so it >>>> generates code for the new processor rather than for the MSP430. You do >>>> NOT rewrite your Forth system. >>>> >>>> The PIC24 should be easy because most of the MSP430 instructions will >>>> correspond one-to-one with PIC24 instructions. The PIC24 has more >>>> registers than the MSP430 and more addressing modes, but you won't use any >>>> of these extra features, so you won't be using the full power of the PIC24. >>>> >>>> The 6812 will be more difficult because you don't have as many registers >>>> as the MSP430. Some of the MSP430 registers will have to be implemented as >>>> pseudo-registers (memory variables). Some of the MSP430 instructions will >>>> generate multiple 6812 instructions rather than correspond one-to-one. >>>> >>>> I picked the MSP430 as the target to write your original system for, >>>> because it is a popular processor and is pretty useful. The MSP430 is in >>>> the middle of the field --- some processors, such as the PIC24, are more >>>> powerful --- some processors, such as the 6812, are less powerful. >>>> >>>> I think that your idea of using C or Go is totally wrong --- you are >>>> introducing huge complications for yourself, and your end result will be >>>> inefficient --- use the technique that I described and you will have an >>>> uncomplicated system, easy portability, and good efficiency (especially on >>>> the MSP430). >>>> >>> >>> Interesting idea, I've read about it before but it was not in my thoughts. >>> There have been proposals for a Portable Assembler code many times, and Go >>> supports assembler mixed with high level code which is not unusual but it >>> uses it's own Portable Assembler Code so for various CPUs the assembler code >>> is not changed but the compiler generates code according to the CPU one is >>> compiling for. It uses a generic register and instruction set that is basic >>> to many CPUs, so you end up with software using assembler that supports >>> several CPUs without any changes. >>> >>> >>> Interesting proposal and I can see it being faster than using C or Go while >>> still being easy to port. >>> >>> 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. >>> >>> >>> LOL.....Mr Positive, allrighty then. >>> >>> Thanks, something to consider as it might get high scores in all four >>> categories. >> >> I'm not sure what advantage "portable" assembly language would have over a >> metacompiled Forth. Both approaches require writing a back end for the >> tool. A metacompiled Forth has one HUGE advantage for developing a Forth >> system... it's in Forth. >> > > It would be part of the Forth System and written in Forth, instead of having > a specific assembler to each CPU with it's own set on mnemonics it would use > a Portable Instruction Set, the same mnemonics for all the CPUs, to change > it to a different CPU one would change the generated code which is fairly > easy to do. Primitives would use the Portable Instructions Set so there > would be no need to change them when switching to a different CPU as the > assembler would generate the machine code for the CPU currently in use. As I have said, I think that is not appreciable different from writing a few core Forth words in generic assembler and coding the rest of the Forth tool in Forth. I guess the terms used in discussing this are far too broad to be able to actually make any comparisons. For your basic assembler instruction set I can refer you to a reference that has some suggestions. https://users.ece.cmu.edu/~koopman/stack_computers/stack_computers_book.pdf -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-28 10:23 +0200 |
| Message-ID | <oge1eq$lu8$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #59951 |
In article <ogcum7$r9t$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >Cecil Bayona wrote on 5/27/2017 3:20 PM: <SNIP> > >I'm not sure what advantage "portable" assembly language would have over a >metacompiled Forth. Both approaches require writing a back end for the >tool. A metacompiled Forth has one HUGE advantage for developing a Forth >system... it's in Forth. Truely "portable" or "high level" assembly is a pipe dream. Using macro's to make assembly more portable surely is feasible. ciforth may be a good example of that, using m4 a lot. I can turn my indirect threaded Forth ciforth into a direct threaded Forth rather easily, while Forth in c is probably subroutine threaded. (At first sight I would think it infeasible to make an indirect threaded Forth in c but apparently gforth has a threaded version.) > >-- > >Rick C Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-28 12:26 -0500 |
| Message-ID | <ogf11q$g4d$1@dont-email.me> |
| In reply to | #59967 |
On 5/28/2017 3:23 AM, Albert van der Horst wrote: > In article <ogcum7$r9t$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> Cecil Bayona wrote on 5/27/2017 3:20 PM: > <SNIP> >> >> I'm not sure what advantage "portable" assembly language would have over a >> metacompiled Forth. Both approaches require writing a back end for the >> tool. A metacompiled Forth has one HUGE advantage for developing a Forth >> system... it's in Forth. > > Truely "portable" or "high level" assembly is a pipe dream. > Using macro's to make assembly more portable surely is feasible. > ciforth may be a good example of that, using m4 a lot. > Some here have problems accepting that there is no 100% portable software, some are closer than others but none are 100%. > I can turn my indirect threaded Forth ciforth into a direct threaded Forth > rather easily, while Forth in c is probably subroutine threaded. > (At first sight I would think it infeasible to make an indirect threaded > Forth in c but apparently gforth has a threaded version.) > I'm not familiar with programming under Linux which I assume you use, I currently use Windows and in Windows there has been a concerted effort to turn the Intel CPU into a Harvard CPU byt putting more and more limits on how the software can be written. Code cannot be executed out of the data space, and the code space is protected from changes is the direction they are heading in, they already mentioned that that is direction they are head for and soon it will not be optional right now it's optional. Under that scenario Forth will not be able to extend itself in the code area, and the data area cannot contain code so that leaves Forth in a hard place. > > Groetjes Albert > -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-30 04:22 -0500 |
| Message-ID | <YradnReRhdNvpLDEnZ2dnUU7-IWdnZ2d@supernews.com> |
| In reply to | #59978 |
Cecil Bayona <cbayona@cbayona.com> wrote: >> > I'm not familiar with programming under Linux which I assume you use, I > currently use Windows and in Windows there has been a concerted effort > to turn the Intel CPU into a Harvard CPU byt putting more and more > limits on how the software can be written. > > Code cannot be executed out of the data space, and the code space is > protected from changes is the direction they are heading in, they > already mentioned that that is direction they are head for and soon it > will not be optional right now it's optional. > > Under that scenario Forth will not be able to extend itself in the code > area, and the data area cannot contain code so that leaves Forth in a > hard place. Microsoft's very own CLR depends on the ability to generate code on the fly and to patch it as it runs, so this ability is not going away any time soon. Plenty of other language runtimes (Java, Javascript, etc.) need to do this too. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-30 11:49 +0200 |
| Message-ID | <ogjf85$cem$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #60054 |
In article <YradnReRhdNvpLDEnZ2dnUU7-IWdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Cecil Bayona <cbayona@cbayona.com> wrote: >>> >> I'm not familiar with programming under Linux which I assume you use, I >> currently use Windows and in Windows there has been a concerted effort >> to turn the Intel CPU into a Harvard CPU byt putting more and more >> limits on how the software can be written. >> >> Code cannot be executed out of the data space, and the code space is >> protected from changes is the direction they are heading in, they >> already mentioned that that is direction they are head for and soon it >> will not be optional right now it's optional. >> >> Under that scenario Forth will not be able to extend itself in the code >> area, and the data area cannot contain code so that leaves Forth in a >> hard place. > >Microsoft's very own CLR depends on the ability to generate code on >the fly and to patch it as it runs, so this ability is not going away >any time soon. Plenty of other language runtimes (Java, Javascript, >etc.) need to do this too. I'm presenting ciforth to Debian. They are definitely a bit upset to see a program that has one section that is readable, writable and executable. Tools get upset too. ( In wheezy `strip' strips lina to nothing.) In one of the reactions it was mentioned that googles `go' does something similar, so that wouldn't not block admission of ciforth as a Debian package. > >Andrew. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web