Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #59883 > unrolled thread

Forth Implementations advantages and disadvantages.

Back to article view | Back to comp.lang.forth

Contents

  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 1 of 6  [1] 2 3 4 5 6  Next page →

#59883 — Forth Implementations advantages and disadvantages.

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

You can't have all four items to the max as they are somewhat 
contradictory but I'm hoping to get a decent mix of those qualities.

So far my plan has been to write the primitives in C or Go, making it a 
Direct Threaded Token based Forth. It would use Direct Threading but 
instead of using native assembler code for the primitives it would use C 
or Go code to implement the primitives. That makes it easier to port but 
it is not lightning fast, but maybe fast enough.

The tokens would be byte size allowing for up to 256 primitives if 
desired, more with extension codes, an array of addresses would be used 
to speed it up some instead of a bunch of IF statements or CASE statements.

This scheme would allow the easy porting of the Forth to any CPU that 
has a C compiler and for custom FPGA CPUs things are a little more 
complicated, as an assembler and the primitives would be written using 
the assembler or the primitives would be the actual CPU instructions. In 
either case it's a little more messy.

Items one through three are well supported with the above scheme but 
item four is not so well. If a particular version will be used a lot and 
the extra speed is needed then the use of assembler primitives instead 
of tokens would create a good speed increase, but this would not be done 
for most CPUs.

Currently I use Dr. Tings eForth to Meta-compile a Forth for FPGA CPUs 
and it does a good job but I would like to have my own software. Maybe 
I'm wrong here and continuing this approach is not a bad option.

Any suggestions, opinions, or general comments would be appreciated.


-- 
Cecil - k5nwa

[toc] | [next] | [standalone]

#59884

Am Freitag, 26. Mai 2017 21:49:41 UTC+2 schrieb Cecil - k5nwa:
> 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
> 
> You can't have all four items to the max as they are somewhat 
> contradictory but I'm hoping to get a decent mix of those qualities.
> 
> So far my plan has been to write the primitives in C or Go, making it a 
> Direct Threaded Token based Forth. It would use Direct Threading but 
> instead of using native assembler code for the primitives it would use C 
> or Go code to implement the primitives. That makes it easier to port but 
> it is not lightning fast, but maybe fast enough.
> 
> The tokens would be byte size allowing for up to 256 primitives if 
> desired, more with extension codes, an array of addresses would be used 
> to speed it up some instead of a bunch of IF statements or CASE statements.
> 
> This scheme would allow the easy porting of the Forth to any CPU that 
> has a C compiler and for custom FPGA CPUs things are a little more 
> complicated, as an assembler and the primitives would be written using 
> the assembler or the primitives would be the actual CPU instructions. In 
> either case it's a little more messy.
> 
> Items one through three are well supported with the above scheme but 
> item four is not so well. If a particular version will be used a lot and 
> the extra speed is needed then the use of assembler primitives instead 
> of tokens would create a good speed increase, but this would not be done 
> for most CPUs.
> 
> Currently I use Dr. Tings eForth to Meta-compile a Forth for FPGA CPUs 
> and it does a good job but I would like to have my own software. Maybe 
> I'm wrong here and continuing this approach is not a bad option.
> 
> Any suggestions, opinions, or general comments would be appreciated.
> 
> 
> -- 
> Cecil - k5nwa

You asked for a general comment: stay as close to _real_ applications as possible, don't spend time on tool cosmetics ( unless it is good fun ;-)
or building your own tools ( unless you can afford the time to neglect
the real applications while building the tools which might at the end
of the days be inferior to what you expected )

Solutions for real world problems are always the best and most satisfying.

[toc] | [prev] | [next] | [standalone]

#59886

On 5/26/2017 3:17 PM, minforth@arcor.de wrote:
> Am Freitag, 26. Mai 2017 21:49:41 UTC+2 schrieb Cecil - k5nwa:
>> 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
>>
>> You can't have all four items to the max as they are somewhat
>> contradictory but I'm hoping to get a decent mix of those qualities.
>>
>> So far my plan has been to write the primitives in C or Go, making it a
>> Direct Threaded Token based Forth. It would use Direct Threading but
>> instead of using native assembler code for the primitives it would use C
>> or Go code to implement the primitives. That makes it easier to port but
>> it is not lightning fast, but maybe fast enough.
>>
>> The tokens would be byte size allowing for up to 256 primitives if
>> desired, more with extension codes, an array of addresses would be used
>> to speed it up some instead of a bunch of IF statements or CASE statements.
>>
>> This scheme would allow the easy porting of the Forth to any CPU that
>> has a C compiler and for custom FPGA CPUs things are a little more
>> complicated, as an assembler and the primitives would be written using
>> the assembler or the primitives would be the actual CPU instructions. In
>> either case it's a little more messy.
>>
>> Items one through three are well supported with the above scheme but
>> item four is not so well. If a particular version will be used a lot and
>> the extra speed is needed then the use of assembler primitives instead
>> of tokens would create a good speed increase, but this would not be done
>> for most CPUs.
>>
>> Currently I use Dr. Tings eForth to Meta-compile a Forth for FPGA CPUs
>> and it does a good job but I would like to have my own software. Maybe
>> I'm wrong here and continuing this approach is not a bad option.
>>
>> Any suggestions, opinions, or general comments would be appreciated.
>>
>>
>> -- 
>> Cecil - k5nwa
> 
> You asked for a general comment: stay as close to _real_ applications as possible, don't spend time on tool cosmetics ( unless it is good fun ;-)
> or building your own tools ( unless you can afford the time to neglect
> the real applications while building the tools which might at the end
> of the days be inferior to what you expected )
> 
> Solutions for real world problems are always the best and most satisfying.
> 

Building a compiler is fun in itself but there are other reasons why a 
custom Forth is needed.

Well a problem I see specially with custom FPGA CPUs is that there are 
not any tools available for the unique device. So I have two choices 
available to have my own super easy to port Forth software or modify an 
existing tool to meta-compile a Forth system to a CPU that has none 
available, this is more complex than having my own easily ported Forth. 
In either case I will have to build my own tools since they will not be 
available.

Another advantage to my own compiler is that when I work on various CPUs 
the software is identical. One of the things noted while doing research 
is that there are Forth available for many CPUs but they all have their 
differences which could be changed so they are closely matched but that 
is a lot more work than having an easily ported Forth that are identical 
to each other.

With the second option which is to modify an existing tool there are 
several choices also.

eForth can be easily used to create an Assembler and Meta-Compiler I 
already have all the software, it's just a question of modifying 
existing software to the CPU of the day.

I also have two commercial Forth systems that optimize machine code and 
have a lot of features, VFX Forth by MPE and SwiftForth by Forth Inc 
either could be used to generate the Assembler and Meta-Compiler needed 
to create my own Forth tools.

Originally I wanted to use Go to create a Forth Virtual Machine at the 
core of a eForth tools but I'm finding some issues that make it harder 
for me to create what I want. This project does not need to be done in 
Go or C instead using Forth might be a better option.

There is no simple solution, the more I look at it the more options that 
come up.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#59894

> Well a problem I see specially with custom FPGA CPUs is that there are 
> not any tools available for the unique device. So I have two choices 
> available to have my own super easy to port Forth software or modify an 
> existing tool to meta-compile a Forth system to a CPU that has none 
> available, this is more complex than having my own easily ported Forth. 
> In either case I will have to build my own tools since they will not be 
> available.

When I hear "FPGA CPU" I think it can be any kind of an animal... And I saw
really really weird architectures. It's hard to say what kind of threading
technique is best for such a CPU before seeing it. The problem is that
for one CPU a tokenizing forth can be ok, but for another one it can be
awfully slow... There is a well-known example, of the very well-known 8051 
CPU. It has such a poor support for memory addressing that the only decent
forth threading for it is just STC. Everything else (even DTC) is so slow
that's embarassing.

[toc] | [prev] | [next] | [standalone]

#59895

On 5/27/2017 12:31 AM, Raimond Dragomir wrote:
>> Well a problem I see specially with custom FPGA CPUs is that there are
>> not any tools available for the unique device. So I have two choices
>> available to have my own super easy to port Forth software or modify an
>> existing tool to meta-compile a Forth system to a CPU that has none
>> available, this is more complex than having my own easily ported Forth.
>> In either case I will have to build my own tools since they will not be
>> available.
> 
> When I hear "FPGA CPU" I think it can be any kind of an animal... And I saw
> really really weird architectures. It's hard to say what kind of threading
> technique is best for such a CPU before seeing it. The problem is that
> for one CPU a tokenizing forth can be ok, but for another one it can be
> awfully slow... There is a well-known example, of the very well-known 8051
> CPU. It has such a poor support for memory addressing that the only decent
> forth threading for it is just STC. Everything else (even DTC) is so slow
> that's embarassing.
> 

That is why I'm having a hard time deciding what to do, the 
possibilities are too large and varied so no one solution works great.

So far the best solution is Direct Token Threaded with the proviso that 
if used often and its not fast enough the it could be modified to use 
assembler primitives instead of C that would not be a big change.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#59893

Cecil Bayona wrote on 5/26/2017 3:49 PM:
> 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
>
> You can't have all four items to the max as they are somewhat
> contradictory but I'm hoping to get a decent mix of those qualities.
>
> So far my plan has been to write the primitives in C or Go, making it a
> Direct Threaded Token based Forth. It would use Direct Threading but
> instead of using native assembler code for the primitives it would use C
> or Go code to implement the primitives. That makes it easier to port but
> it is not lightning fast, but maybe fast enough.
>
> The tokens would be byte size allowing for up to 256 primitives if
> desired, more with extension codes, an array of addresses would be used
> to speed it up some instead of a bunch of IF statements or CASE statements.
>
> This scheme would allow the easy porting of the Forth to any CPU that
> has a C compiler and for custom FPGA CPUs things are a little more
> complicated, as an assembler and the primitives would be written using
> the assembler or the primitives would be the actual CPU instructions. In
> either case it's a little more messy.
>
> Items one through three are well supported with the above scheme but
> item four is not so well. If a particular version will be used a lot and
> the extra speed is needed then the use of assembler primitives instead
> of tokens would create a good speed increase, but this would not be done
> for most CPUs.
>
> Currently I use Dr. Tings eForth to Meta-compile a Forth for FPGA CPUs
> and it does a good job but I would like to have my own software. Maybe
> I'm wrong here and continuing this approach is not a bad option.
>
> Any suggestions, opinions, or general comments would be appreciated.

"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?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#59896

On 5/27/2017 12:09 AM, rickman wrote:
> Cecil Bayona wrote on 5/26/2017 3:49 PM:

>> Currently I use Dr. Tings eForth to Meta-compile a Forth for FPGA CPUs
>> and it does a good job but I would like to have my own software. Maybe
>> I'm wrong here and continuing this approach is not a bad option.
>>
>> Any suggestions, opinions, or general comments would be appreciated.
> 
> "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?
> 

Having total control so it can be the way I want it can be important. I 
really don't know of any Forth whose main goal is easy porting which is 
the most important feature I desire. Most Forth are either all 
assembler, or a mix of assembler and Forth, either one is hard to port, 
there are a few written in C but they fail at being simple to understand 
and change.

eForth is the closest to those goals that doesn't break the bank and 
there are a multitude of architectures available, Indirect Threaded, 
Direct Threaded, Subroutine Threaded, and even Token Threaded versions 
of eForth so in the end that might not be a bad way to go but no matter 
what when a new FPGA CPU or an existing one is modified one needs to 
port the software to the new device.

Before I put a lot of effort into creating something from scratch it 
might be worth the effort to attempt to port an existing eForth version 
to a different CPU and see how practical that is. port ep16 eForth to 
become ep32 eForth that would be a nice test as I have working ep32 
software to compare it to. If it works OK then no need to write anything 
from scratch just port a new version as needed. ep16 CPU eForth to J1 
CPU eForth might also be a nice test since the CPUs are quite different.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#59897

Cecil Bayona wrote on 5/27/2017 1:59 AM:
> On 5/27/2017 12:09 AM, rickman wrote:
>> Cecil Bayona wrote on 5/26/2017 3:49 PM:
>
>>> Currently I use Dr. Tings eForth to Meta-compile a Forth for FPGA CPUs
>>> and it does a good job but I would like to have my own software. Maybe
>>> I'm wrong here and continuing this approach is not a bad option.
>>>
>>> Any suggestions, opinions, or general comments would be appreciated.
>>
>> "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?
>>
>
> Having total control so it can be the way I want it can be important. I
> really don't know of any Forth whose main goal is easy porting which is
> the most important feature I desire. Most Forth are either all
> assembler, or a mix of assembler and Forth, either one is hard to port,
> there are a few written in C but they fail at being simple to understand
> and change.
>
> eForth is the closest to those goals that doesn't break the bank and
> there are a multitude of architectures available, Indirect Threaded,
> Direct Threaded, Subroutine Threaded, and even Token Threaded versions
> of eForth so in the end that might not be a bad way to go but no matter
> what when a new FPGA CPU or an existing one is modified one needs to
> port the software to the new device.
>
> Before I put a lot of effort into creating something from scratch it
> might be worth the effort to attempt to port an existing eForth version
> to a different CPU and see how practical that is. port ep16 eForth to
> become ep32 eForth that would be a nice test as I have working ep32
> software to compare it to. If it works OK then no need to write anything
> from scratch just port a new version as needed. ep16 CPU eForth to J1
> CPU eForth might also be a nice test since the CPUs are quite different.

If the Forth is not written in assembler, how would it be ported to 
custom CPU designs?  Actually I have no idea where you are going with 
this.  You talk about writing a "super easy to port" Forth, but I 
haven't read how you might go about this.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#59923

On 5/27/2017 1:09 AM, rickman wrote:
> Cecil Bayona wrote on 5/27/2017 1:59 AM:
>> On 5/27/2017 12:09 AM, rickman wrote:
>>> Cecil Bayona wrote on 5/26/2017 3:49 PM:
>>
>>>> Currently I use Dr. Tings eForth to Meta-compile a Forth for FPGA CPUs
>>>> and it does a good job but I would like to have my own software. Maybe
>>>> I'm wrong here and continuing this approach is not a bad option.
>>>>
>>>> Any suggestions, opinions, or general comments would be appreciated.
>>>
>>> "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?
>>>
>>
>> Having total control so it can be the way I want it can be important. I
>> really don't know of any Forth whose main goal is easy porting which is
>> the most important feature I desire. Most Forth are either all
>> assembler, or a mix of assembler and Forth, either one is hard to port,
>> there are a few written in C but they fail at being simple to understand
>> and change.
>>
>> eForth is the closest to those goals that doesn't break the bank and
>> there are a multitude of architectures available, Indirect Threaded,
>> Direct Threaded, Subroutine Threaded, and even Token Threaded versions
>> of eForth so in the end that might not be a bad way to go but no matter
>> what when a new FPGA CPU or an existing one is modified one needs to
>> port the software to the new device.
>>
>> Before I put a lot of effort into creating something from scratch it
>> might be worth the effort to attempt to port an existing eForth version
>> to a different CPU and see how practical that is. port ep16 eForth to
>> become ep32 eForth that would be a nice test as I have working ep32
>> software to compare it to. If it works OK then no need to write anything
>> from scratch just port a new version as needed. ep16 CPU eForth to J1
>> CPU eForth might also be a nice test since the CPUs are quite different.
> 
> If the Forth is not written in assembler, how would it be ported to 
> custom CPU designs?  Actually I have no idea where you are going with 
> this.  You talk about writing a "super easy to port" Forth, but I 
> haven't read how you might go about this.
> 

If the primitives are written in C then a recompile with a C for a 
different CPU would generate a Forth for that CPU. Some minor work on 
the I/O words might be needed but that is relatively simple.

A custom FPGA CPU would not have a C compiler but in any case is would 
still be not that difficult to write an assembler to be used in creating 
the primitives, in some cases the CPU instructions are the primitives so 
that is easy to implement.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#59927

Cecil Bayona wrote on 5/27/2017 10:35 AM:
> On 5/27/2017 1:09 AM, rickman wrote:
>> Cecil Bayona wrote on 5/27/2017 1:59 AM:
>>> On 5/27/2017 12:09 AM, rickman wrote:
>>>> Cecil Bayona wrote on 5/26/2017 3:49 PM:
>>>
>>>>> Currently I use Dr. Tings eForth to Meta-compile a Forth for FPGA CPUs
>>>>> and it does a good job but I would like to have my own software. Maybe
>>>>> I'm wrong here and continuing this approach is not a bad option.
>>>>>
>>>>> Any suggestions, opinions, or general comments would be appreciated.
>>>>
>>>> "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?
>>>>
>>>
>>> Having total control so it can be the way I want it can be important. I
>>> really don't know of any Forth whose main goal is easy porting which is
>>> the most important feature I desire. Most Forth are either all
>>> assembler, or a mix of assembler and Forth, either one is hard to port,
>>> there are a few written in C but they fail at being simple to understand
>>> and change.
>>>
>>> eForth is the closest to those goals that doesn't break the bank and
>>> there are a multitude of architectures available, Indirect Threaded,
>>> Direct Threaded, Subroutine Threaded, and even Token Threaded versions
>>> of eForth so in the end that might not be a bad way to go but no matter
>>> what when a new FPGA CPU or an existing one is modified one needs to
>>> port the software to the new device.
>>>
>>> Before I put a lot of effort into creating something from scratch it
>>> might be worth the effort to attempt to port an existing eForth version
>>> to a different CPU and see how practical that is. port ep16 eForth to
>>> become ep32 eForth that would be a nice test as I have working ep32
>>> software to compare it to. If it works OK then no need to write anything
>>> from scratch just port a new version as needed. ep16 CPU eForth to J1
>>> CPU eForth might also be a nice test since the CPUs are quite different.
>>
>> If the Forth is not written in assembler, how would it be ported to
>> custom CPU designs?  Actually I have no idea where you are going with
>> this.  You talk about writing a "super easy to port" Forth, but I
>> haven't read how you might go about this.
>>
>
> If the primitives are written in C then a recompile with a C for a
> different CPU would generate a Forth for that CPU. Some minor work on
> the I/O words might be needed but that is relatively simple.
>
> A custom FPGA CPU would not have a C compiler but in any case is would
> still be not that difficult to write an assembler to be used in creating
> the primitives, in some cases the CPU instructions are the primitives so
> that is easy to implement.

Do you see the problem with these two statements?  According to your 
concept you would be keeping N versions of your Forth, one in C and many 
in assembly.

I would also point out that in addition to needing a C compiler for each 
target, you will still need to change the source code to account for 
differences in hardware.

Try looking at existing implementations, Mecrisp would be a good 
example.  It has been ported to many different CPUs with two mainstream 
processor ISAs as well as some FPGA designs.  It is always done in 
assembly, but that's not really an important factor.  The issue is each 
version has to be different to account for differences in the hardware.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#59929

On 5/27/2017 11:22 AM, rickman wrote:
> Cecil Bayona wrote on 5/27/2017 10:35 AM:
>> On 5/27/2017 1:09 AM, rickman wrote:
>>> Cecil Bayona wrote on 5/27/2017 1:59 AM:
>>>> On 5/27/2017 12:09 AM, rickman wrote:
>>>>> Cecil Bayona wrote on 5/26/2017 3:49 PM:
>>>>
>>>>>> Currently I use Dr. Tings eForth to Meta-compile a Forth for FPGA 
>>>>>> CPUs
>>>>>> and it does a good job but I would like to have my own software. 
>>>>>> Maybe
>>>>>> I'm wrong here and continuing this approach is not a bad option.
>>>>>>
>>>>>> Any suggestions, opinions, or general comments would be appreciated.
>>>>>
>>>>> "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?
>>>>>
>>>>
>>>> Having total control so it can be the way I want it can be important. I
>>>> really don't know of any Forth whose main goal is easy porting which is
>>>> the most important feature I desire. Most Forth are either all
>>>> assembler, or a mix of assembler and Forth, either one is hard to port,
>>>> there are a few written in C but they fail at being simple to 
>>>> understand
>>>> and change.
>>>>
>>>> eForth is the closest to those goals that doesn't break the bank and
>>>> there are a multitude of architectures available, Indirect Threaded,
>>>> Direct Threaded, Subroutine Threaded, and even Token Threaded versions
>>>> of eForth so in the end that might not be a bad way to go but no matter
>>>> what when a new FPGA CPU or an existing one is modified one needs to
>>>> port the software to the new device.
>>>>
>>>> Before I put a lot of effort into creating something from scratch it
>>>> might be worth the effort to attempt to port an existing eForth version
>>>> to a different CPU and see how practical that is. port ep16 eForth to
>>>> become ep32 eForth that would be a nice test as I have working ep32
>>>> software to compare it to. If it works OK then no need to write 
>>>> anything
>>>> from scratch just port a new version as needed. ep16 CPU eForth to J1
>>>> CPU eForth might also be a nice test since the CPUs are quite 
>>>> different.
>>>
>>> If the Forth is not written in assembler, how would it be ported to
>>> custom CPU designs?  Actually I have no idea where you are going with
>>> this.  You talk about writing a "super easy to port" Forth, but I
>>> haven't read how you might go about this.
>>>
>>
>> If the primitives are written in C then a recompile with a C for a
>> different CPU would generate a Forth for that CPU. Some minor work on
>> the I/O words might be needed but that is relatively simple.
>>
>> A custom FPGA CPU would not have a C compiler but in any case is would
>> still be not that difficult to write an assembler to be used in creating
>> the primitives, in some cases the CPU instructions are the primitives so
>> that is easy to implement.
> 
> Do you see the problem with these two statements?  According to your 
> concept you would be keeping N versions of your Forth, one in C and many 
> in assembly.

An assembler version would be a rare thing, it's just an option that is 
available if the extra work is merited but for most I would not need it. 
One starts with the C version for most CPUs that is good enough.
> 
> I would also point out that in addition to needing a C compiler for each 
> target, you will still need to change the source code to account for 
> differences in hardware.

C is available for just about every CPU in existence except custom FPGA 
and that is handled by a simple assembler and Meta-compiler.

> 
> Try looking at existing implementations, Mecrisp would be a good 
> example.  It has been ported to many different CPUs with two mainstream 
> processor ISAs as well as some FPGA designs.  It is always done in 
> assembly, but that's not really an important factor.  The issue is each 
> version has to be different to account for differences in the hardware.
> 

Actually Mecrisp is not a great example, assembler is the least portable 
method there is, if it were in C one would use the built in libraries to 
setup the clock, and do I/O, part of that is telling the C compiler what 
device you are compiling it for and the C compiler will take care of the 
differences assembler does not do that for you.

I currently use C and Pascal with embedded CPUs, switching chips used is 
not a major problem, part of the project settings is identifying the CPU 
used and the compiler takes care of the details. So this is a minor 
issue, that is one reason for using C one can re-compile software for 
different CPUs with at most minor software changes, the big minus is 
that it's not as fast as assembler, with a lot of CPUs it's still fast 
enough so not big deal.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#59931

Cecil Bayona wrote on 5/27/2017 12:53 PM:
> On 5/27/2017 11:22 AM, rickman wrote:
>> Cecil Bayona wrote on 5/27/2017 10:35 AM:
>>>
>>> If the primitives are written in C then a recompile with a C for a
>>> different CPU would generate a Forth for that CPU. Some minor work on
>>> the I/O words might be needed but that is relatively simple.
>>>
>>> A custom FPGA CPU would not have a C compiler but in any case is would
>>> still be not that difficult to write an assembler to be used in creating
>>> the primitives, in some cases the CPU instructions are the primitives so
>>> that is easy to implement.
>>
>> Do you see the problem with these two statements?  According to your
>> concept you would be keeping N versions of your Forth, one in C and many
>> in assembly.
>
> An assembler version would be a rare thing, it's just an option that is
> available if the extra work is merited but for most I would not need it. One
> starts with the C version for most CPUs that is good enough.

I'm not following you.  Every custom CPU design will require either a C 
compiler be written or the coding will have to be in assembler.  Are you 
saying you expect custom FPGA CPUs to only be supported rarely?  I thought 
you had this as one of your requirements.


>> I would also point out that in addition to needing a C compiler for each
>> target, you will still need to change the source code to account for
>> differences in hardware.
>
> C is available for just about every CPU in existence except custom FPGA and
> that is handled by a simple assembler and Meta-compiler.

Yes, assembly will be required.  That's what I'm saying.  You seem to be 
brushing this off somehow.  So you will need a C version along with a number 
of assembly language versions.  That is a real PITA to try to keep in sync 
as you add features.


>> Try looking at existing implementations, Mecrisp would be a good example.
>> It has been ported to many different CPUs with two mainstream processor
>> ISAs as well as some FPGA designs.  It is always done in assembly, but
>> that's not really an important factor.  The issue is each version has to
>> be different to account for differences in the hardware.
>>
>
> Actually Mecrisp is not a great example, assembler is the least portable
> method there is, if it were in C one would use the built in libraries to
> setup the clock, and do I/O, part of that is telling the C compiler what
> device you are compiling it for and the C compiler will take care of the
> differences assembler does not do that for you.

Dismissing Mecrisp as a vehicle to learn about porting Forth across CPUs is 
disingenuous.  The issue is how it has to change.  It exists for multiple 
CPUs and and multiple manufacturers.  Go study it and learn from it.  You 
will also find that a C compiler is not needed to take advantage of the 
manufacturer's experience.  They provide a setup file in assembly, not C.

Libraries are not always compatible.  There may be library routines, but 
they aren't called the same way or do the same functions across different 
CPUs.  I've had this discussion before relating to the importance of staying 
with one CPU line.  It has been pointed out the main difference in coding 
for a CPU is the variation between manufacturers rather than CPU ISAs.  The 
important point here is using C and libraries doesn't solve the porting 
problem for you.


> I currently use C and Pascal with embedded CPUs, switching chips used is not
> a major problem, part of the project settings is identifying the CPU used
> and the compiler takes care of the details. So this is a minor issue, that
> is one reason for using C one can re-compile software for different CPUs
> with at most minor software changes, the big minus is that it's not as fast
> as assembler, with a lot of CPUs it's still fast enough so not big deal.

That depends on what you are doing in the programs you write.  Have you done 
much embedded work that writes to the Flash?  Works in low power modes?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#59933

On 05/27/2017 11:53 AM, Cecil Bayona wrote:
> Actually Mecrisp is not a great example, assembler is the least portable
> method there is, if it were in C one would use the built in libraries to
> setup the clock, and do I/O, part of that is telling the C compiler what
> device you are compiling it for and the C compiler will take care of the
> differences assembler does not do that for you.
> 
> I currently use C and Pascal with embedded CPUs, switching chips used is
> not a major problem, part of the project settings is identifying the CPU
> used and the compiler takes care of the details. So this is a minor
> issue, that is one reason for using C one can re-compile software for
> different CPUs with at most minor software changes, the big minus is
> that it's not as fast as assembler, with a lot of CPUs it's still fast
> enough so not big deal.
> 

This makes no sense to me at all.

The C compiler knows nothing about the hardware, all it knows is how to
generate code for the CPU. The care and feeding of things like UARTS is
up to the user.


You might get lucky and find that someone else has already written code
to make a UART dance the way you want it to but that isn't likely.

Worse, the CPUs have supporting hardware (clock generation, etc.) that
can vary between devices. The compiler has no clue.

My C code startup looks a lot like my assembly code startup for the
MSP430. Turn off the watch dog, configure the clocks, start a timer,
etc. They are both equally portable between devices, ie. not very.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

[toc] | [prev] | [next] | [standalone]

#59935

On 5/27/2017 12:24 PM, David Schultz wrote:
> On 05/27/2017 11:53 AM, Cecil Bayona wrote:
>> Actually Mecrisp is not a great example, assembler is the least portable
>> method there is, if it were in C one would use the built in libraries to
>> setup the clock, and do I/O, part of that is telling the C compiler what
>> device you are compiling it for and the C compiler will take care of the
>> differences assembler does not do that for you.
>>
>> I currently use C and Pascal with embedded CPUs, switching chips used is
>> not a major problem, part of the project settings is identifying the CPU
>> used and the compiler takes care of the details. So this is a minor
>> issue, that is one reason for using C one can re-compile software for
>> different CPUs with at most minor software changes, the big minus is
>> that it's not as fast as assembler, with a lot of CPUs it's still fast
>> enough so not big deal.
>>
> 
> This makes no sense to me at all.
> 
> The C compiler knows nothing about the hardware, all it knows is how to
> generate code for the CPU. The care and feeding of things like UARTS is
> up to the user.
> 
> 
> You might get lucky and find that someone else has already written code
> to make a UART dance the way you want it to but that isn't likely.
> 
> Worse, the CPUs have supporting hardware (clock generation, etc.) that
> can vary between devices. The compiler has no clue.
> 
> My C code startup looks a lot like my assembly code startup for the
> MSP430. Turn off the watch dog, configure the clocks, start a timer,
> etc. They are both equally portable between devices, ie. not very.
> 

Libraries are part of the C development environment. I have no clue what 
C compilers others are using but with my C compilers I do not need to 
use assembler at all, libraries are provided to initialize and use the 
hardware, all I have to change is the CPU in use and the software will 
work on different CPU devices. Some changes might be needed in some 
cases but it's minor.

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.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#59937

On 05/27/2017 01:13 PM, Cecil Bayona wrote:
> Libraries are part of the C development environment.

The libraries of which you are speaking are specific to a particular
vendors system. gcc includes some library code but it is for generic
things that work across all devices (sprintf for example) and not for
specific hardware like UARTs or timers.

> I have no clue what
> C compilers others are using but with my C compilers I do not need to
> use assembler at all,

I don't use assembler with C either but the initialization code is the
same either way. One is in C and the other is in assembler. Customized
for the particular device.



-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

[toc] | [prev] | [next] | [standalone]

#59940

Cecil Bayona wrote on 5/27/2017 2:13 PM:
> On 5/27/2017 12:24 PM, David Schultz wrote:
>> On 05/27/2017 11:53 AM, Cecil Bayona wrote:
>>> Actually Mecrisp is not a great example, assembler is the least portable
>>> method there is, if it were in C one would use the built in libraries to
>>> setup the clock, and do I/O, part of that is telling the C compiler what
>>> device you are compiling it for and the C compiler will take care of the
>>> differences assembler does not do that for you.
>>>
>>> I currently use C and Pascal with embedded CPUs, switching chips used is
>>> not a major problem, part of the project settings is identifying the CPU
>>> used and the compiler takes care of the details. So this is a minor
>>> issue, that is one reason for using C one can re-compile software for
>>> different CPUs with at most minor software changes, the big minus is
>>> that it's not as fast as assembler, with a lot of CPUs it's still fast
>>> enough so not big deal.
>>>
>>
>> This makes no sense to me at all.
>>
>> The C compiler knows nothing about the hardware, all it knows is how to
>> generate code for the CPU. The care and feeding of things like UARTS is
>> up to the user.
>>
>>
>> You might get lucky and find that someone else has already written code
>> to make a UART dance the way you want it to but that isn't likely.
>>
>> Worse, the CPUs have supporting hardware (clock generation, etc.) that
>> can vary between devices. The compiler has no clue.
>>
>> My C code startup looks a lot like my assembly code startup for the
>> MSP430. Turn off the watch dog, configure the clocks, start a timer,
>> etc. They are both equally portable between devices, ie. not very.
>>
>
> Libraries are part of the C development environment. I have no clue what C
> compilers others are using but with my C compilers I do not need to use
> assembler at all, libraries are provided to initialize and use the hardware,
> all I have to change is the CPU in use and the software will work on
> different CPU devices. Some changes might be needed in some cases but it's
> minor.
>
> 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 don't know why you feel this is negativity.  This is a discussion.  You 
have described something that appears to have some flaws.  We are pointing 
out the flaws.  What would you prefer, that we be a cheering section without 
even reading what you are writing?

I am not clear on what you expect libraries to do for you.  As you say, the 
parts of Forth that will change between CPUs will be limited, but not zero. 
You will need to tailor the communications and the memory map along with 
various details about how you access memory such as writing to the on chip 
flash or the on board external memories such as serial Flash or RAM.

I'm not "against" writing a C compiler for a custom CPU.  But I think it is 
no small job.  Most custom CPUs Forth would be ported to will be stack 
processors of one type or another.  I would believe it is a much bigger job 
than porting the Forth code itself by writing a C compiler than to just 
write the Forth in assembly for such a CPU.  This provides a relatively easy 
way to fully optimize the code for such processors which typically have some 
feature(s) to facilitate Forth code in some way.

I do know of one custom stack CPU with a C compiler, the ZPU.  But then it 
was designed explicitly to run C code with no thought to running Forth.  It 
has even been used commercially although not very widely.

All I'm saying is that using C to facilitate porting between CPUs will not 
be as straightforward as you make it out to be.  Most of the Mecrisp ports 
are ARM CPUs and there is still a fair amount of work involved in doing a 
port between CPUs with the same ISA.  That's why I suggested you look at 
Mecrisp to learn about the issues involved.

I'm not trying to tell you not to do it.  I'm trying to help by pointing you 
to some useful information.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#59948

On 5/27/2017 1:53 PM, rickman wrote:
> Cecil Bayona wrote on 5/27/2017 2:13 PM:
>> On 5/27/2017 12:24 PM, David Schultz wrote:
>>> On 05/27/2017 11:53 AM, Cecil Bayona wrote:
>>>> Actually Mecrisp is not a great example, assembler is the least 
>>>> portable
>>>> method there is, if it were in C one would use the built in 
>>>> libraries to
>>>> setup the clock, and do I/O, part of that is telling the C compiler 
>>>> what
>>>> device you are compiling it for and the C compiler will take care of 
>>>> the
>>>> differences assembler does not do that for you.
>>>>
>>>> I currently use C and Pascal with embedded CPUs, switching chips 
>>>> used is
>>>> not a major problem, part of the project settings is identifying the 
>>>> CPU
>>>> used and the compiler takes care of the details. So this is a minor
>>>> issue, that is one reason for using C one can re-compile software for
>>>> different CPUs with at most minor software changes, the big minus is
>>>> that it's not as fast as assembler, with a lot of CPUs it's still fast
>>>> enough so not big deal.
>>>>
>>>
>>> This makes no sense to me at all.
>>>
>>> The C compiler knows nothing about the hardware, all it knows is how to
>>> generate code for the CPU. The care and feeding of things like UARTS is
>>> up to the user.
>>>
>>>
>>> You might get lucky and find that someone else has already written code
>>> to make a UART dance the way you want it to but that isn't likely.
>>>
>>> Worse, the CPUs have supporting hardware (clock generation, etc.) that
>>> can vary between devices. The compiler has no clue.
>>>
>>> My C code startup looks a lot like my assembly code startup for the
>>> MSP430. Turn off the watch dog, configure the clocks, start a timer,
>>> etc. They are both equally portable between devices, ie. not very.
>>>
>>
>> Libraries are part of the C development environment. I have no clue 
>> what C
>> compilers others are using but with my C compilers I do not need to use
>> assembler at all, libraries are provided to initialize and use the 
>> hardware,
>> all I have to change is the CPU in use and the software will work on
>> different CPU devices. Some changes might be needed in some cases but 
>> it's
>> minor.
>>
>> 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 don't know why you feel this is negativity.  This is a discussion.  
> You have described something that appears to have some flaws.  We are 
> pointing out the flaws.  What would you prefer, that we be a cheering 
> section without even reading what you are writing?
> 

Criticism is OK but it need to be accompanied with at least hints to a 
possible solution otherwise it doesn't help much, and it seems people 
are looking for a perfect solution, there usually isn't one, all 
approaches may have some problems just what is one that the problems are 
not as severe.

> I am not clear on what you expect libraries to do for you.  As you say, 
> the parts of Forth that will change between CPUs will be limited, but 
> not zero. You will need to tailor the communications and the memory map 
> along with various details about how you access memory such as writing 
> to the on chip flash or the on board external memories such as serial 
> Flash or RAM.

It doesn't need to be zero just minimal issues if possible, I've already 
mention that communication and other issues might need adjustment, not 
perfect but not the end.

> 
> I'm not "against" writing a C compiler for a custom CPU.  But I think it 
> is no small job.  Most custom CPUs Forth would be ported to will be 
> stack processors of one type or another.  I would believe it is a much 
> bigger job than porting the Forth code itself by writing a C compiler 
> than to just write the Forth in assembly for such a CPU.  This provides 
> a relatively easy way to fully optimize the code for such processors 
> which typically have some feature(s) to facilitate Forth code in some way.
> 
> I do know of one custom stack CPU with a C compiler, the ZPU.  But then 
> it was designed explicitly to run C code with no thought to running 
> Forth.  It has even been used commercially although not very widely.
> 

I already mentioned the same, FPGAs do not have a C compiler so a 
different approach is necessary, a customized assembler and 
meta-compiler is needed, I already have that software so a customization 
would be needed. An FPGA requires more work but then the alternative is 
to assemble code with a pencil and paper.

Also I mentioned that I do not intend to write a C compiler, that is not 
needed for FPGAs the answer does not lie with C. That being said, I have 
written my own C compiler in the past, and enhanced SmallC by quite a 
bit so it's not an impossible task for me.

> All I'm saying is that using C to facilitate porting between CPUs will 
> not be as straightforward as you make it out to be.  Most of the Mecrisp 
> ports are ARM CPUs and there is still a fair amount of work involved in 
> doing a port between CPUs with the same ISA.  That's why I suggested you 
> look at Mecrisp to learn about the issues involved.
> 

Mecrisp uses assembler the most un-portable way to write software, a C 
compiler handles those issues a lot better than assembler.

> I'm not trying to tell you not to do it.  I'm trying to help by pointing 
> you to some useful information.
> 

Thanks

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#59965

In article <ogcfde$9qi$1@dont-email.me>,
Cecil Bayona  <cbayona@cbayona.com> wrote:
<SNIP>
>Libraries are part of the C development environment. I have no clue what
>C compilers others are using but with my C compilers I do not need to
>use assembler at all, libraries are provided to initialize and use the
>hardware, all I have to change is the CPU in use and the software will
>work on different CPU devices. Some changes might be needed in some
>cases but it's minor.

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.  1]
Then give me one example of a usefull uP application that
doesn't use one of those.

I'm sick of the "it is C, so it is portable" dogma.

>
>--
>Cecil - k5nwa

1] A manufacturer may strive for compatibility between her uP's
and sometimes succeed.
-- 
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]

#59975

Albert van der Horst wrote on 5/28/2017 4:09 AM:
> In article <ogcfde$9qi$1@dont-email.me>,
> Cecil Bayona  <cbayona@cbayona.com> wrote:
> <SNIP>
>> Libraries are part of the C development environment. I have no clue what
>> C compilers others are using but with my C compilers I do not need to
>> use assembler at all, libraries are provided to initialize and use the
>> hardware, all I have to change is the CPU in use and the software will
>> work on different CPU devices. Some changes might be needed in some
>> cases but it's minor.
>
> 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.  1]
> Then give me one example of a usefull uP application that
> doesn't use one of those.
>
> I'm sick of the "it is C, so it is portable" dogma.
>
>>
>> --
>> Cecil - k5nwa
>
> 1] A manufacturer may strive for compatibility between her uP's
> and sometimes succeed.

I recall having a conversation some 10 years ago (or more) about how ARM 
would be taking over the world.  Mostly this was based on how it is to the 
designer's advantage to stick with one CPU type and not need to port between 
ISAs in order to switch manufacturers with the ebb and flow of technology 
and economics.  A strong argument against this was the fact that it is much 
more work to port the peripheral code than the code directly supporting CPU 
features.

In the end ARM has taken over despite our conversation.  But that does not 
invalidate the complexity of porting an app of any kind between processors.

For the most part coding in C will only help you with the parts that could 
also be easily coded in Forth.  Most of what is left will either need to be 
coded in assembly for performance or will need to be tailored to the 
processor/board in use and so will be rewritten regardless of the language.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#59976

On 5/28/2017 3:09 AM, Albert van der Horst wrote:
> In article <ogcfde$9qi$1@dont-email.me>,
> Cecil Bayona  <cbayona@cbayona.com> wrote:
> <SNIP>
>> Libraries are part of the C development environment. I have no clue what
>> C compilers others are using but with my C compilers I do not need to
>> use assembler at all, libraries are provided to initialize and use the
>> hardware, all I have to change is the CPU in use and the software will
>> work on different CPU devices. Some changes might be needed in some
>> cases but it's minor.
> 
> 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.  1]
> Then give me one example of a usefull uP application that
> doesn't use one of those.

My last application was an oven controller, it did not need to go in low 
power mode as it's AC powered while in use, and it did not need or use 
any A/D converters as the temperature was read via a SIO device. So 
those are arbitrary requirements that are not always valid.
> 
> I'm sick of the "it is C, so it is portable" dogma.

Well then take two aspirins drink plenty of fluids and go to bed early 
and you will feel a lot better in the morning. You can also buy an 
inexpensive book on C on eBay and burn it so you can feel better.

It's a lot more portable than assembler was my point, the C and Pascal 
I currently use take a setting in the project definition as to what CPU 
chip, and what clock one desires and the initialization software is set 
for you, the Pascal version also take parameters in the project settings 
about the power down modes desired and sets the software for you. So 
within the limits of the CPU supported by those compilers it is fairly 
portable.

Personally I'm not a fan of C even less of C++ I stopped using them a 
long time ago and only recently have I started using C for small 
projects just to get reacquainted again but I prefer Pascal to C any day 
of the week, and prefer Forth even more. At the start of this endeavor 
the use of C required fewer changes when porting the software compared 
to assembler so it was not a desired option but it was the only one that 
made sense at the time. And yes I'm aware that some items require 
customization when changing CPUs so it's not 100% portable but so what 
when compared to the alternatives, nothing is 100% portable.

I will be looking at alternative use of assembler that minimizes the 
needed changes when porting, it it works out then I will not be using C 
at all so both of us can be happier.

> 
>>
>> --
>> Cecil - k5nwa
> 
> 1] A manufacturer may strive for compatibility between her uP's
> and sometimes succeed.
> 


-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.forth

csiph-web