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

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

The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

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

Contents

  The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-02 09:33 -0700
    Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-02 10:35 -0700
      Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-02 11:46 -0700
        Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-03 00:04 -0700
          Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-04 00:41 -0700
            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc rickman <gnuarm@gmail.com> - 2016-08-04 09:35 -0400
              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-04 10:08 -0500
    Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc Brad Eckert <hwfwguy@gmail.com> - 2016-08-02 15:45 -0700
      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-02 19:56 -0500
        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-02 22:43 -0700
        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-03 00:12 -0700
          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-03 02:42 -0500
            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-03 10:41 -0700
              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-03 12:56 -0500
              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-03 13:09 -0500
                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc rickman <gnuarm@gmail.com> - 2016-08-03 14:15 -0400
                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Richard Owlett <rowlett@cloud85.net> - 2016-08-03 18:00 -0500
                    Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-05 20:35 -0700
                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 00:16 -0500
                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 16:58 -0700
                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 18:01 -0700
                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 21:28 -0500
                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 19:46 -0700
                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 22:54 -0500
                                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-06 21:39 -0700
                                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-06 22:28 -0700
                                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 23:49 -0700
                                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 02:32 -0500
                                    Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-07 01:06 -0700
                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 07:05 -0500
                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 13:01 -0700
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 16:02 -0500
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 14:20 -0700
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc franck.bensusan@gmail.com - 2016-08-08 03:13 -0700
                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-08 11:25 -0500
                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-07 13:55 -0700
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 16:22 -0500
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 15:03 -0700
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 23:02 -0700
                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc "Elizabeth D. Rather" <erather@forth.com> - 2016-08-07 21:10 -1000
                                                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-09 00:36 -0700
                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 09:06 +0000
                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 09:33 -0700
                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 11:31 -0700
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 12:35 -0700
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 16:11 -0500
                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 22:43 -0700
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 22:48 -0700
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 08:34 +0000
                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-08 23:59 -0700
                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 13:53 +0000
                                                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-10 19:56 -0700
                                                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-11 00:33 -0700
                                                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-11 11:58 +0000
                                                    Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-11 13:16 -0700
                                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc stephen@mpeforth.com (Stephen Pelc) - 2016-08-11 23:36 +0000
                                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-11 20:49 -0700
                                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-28 11:20 -0700
                                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-28 17:33 -0700
                                                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-28 21:10 -0500
                                                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-28 22:49 -0700
                                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-12 23:10 -0700
                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-06 20:20 -0700
                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 09:58 -0700
                                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-07 11:08 -0700
                                  Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 09:10 +0000
                                    Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 10:47 +0000
                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JennyB <jennybrien@googlemail.com> - 2016-08-08 13:44 -0700
                                    Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc mhx@iae.nl - 2016-08-08 11:32 -0700
                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 06:13 +0000
                                      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 06:19 +0000
                                        Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc mhx@iae.nl - 2016-08-09 02:54 -0700
                                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 10:22 +0000
                          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc lawrencedo99@gmail.com - 2016-08-15 20:33 -0700
                            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-16 10:40 -0700
                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc lawrencedo99@gmail.com - 2016-08-17 02:21 -0700
                              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-17 11:14 -0700
          Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Roberto Waltman <usenet@rwaltman.com> - 2016-08-03 18:21 -0400
      Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc rickman <gnuarm@gmail.com> - 2016-08-03 02:46 -0400
    Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc endlessboomcapitalism@gmail.com - 2016-08-13 09:51 -0700
      Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-13 12:18 -0700
        Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc endlessboomcapitalism@gmail.com - 2016-08-14 19:13 -0700
          Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-15 07:43 -0700
            Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-15 12:34 -0500
              Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Brad Eckert <hwfwguy@gmail.com> - 2016-08-17 22:08 -0700
                Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-18 15:26 -0700
        Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc endlessboomcapitalism@gmail.com - 2016-08-14 19:18 -0700
        Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-15 08:24 -0700
          Re: The Fourth Forth eBook in our little series  - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-15 08:31 -0700
            Re: The Fourth Forth eBook in our little series - Programming Forth- Stephen Pelc "WJ" <w_a_x_man@yahoo.com> - 2016-08-19 23:54 +0000
              Re: The Fourth Forth eBook in our little series - Programming Forth- Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-20 01:43 -0700

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#49823 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Saturday, August 6, 2016 at 4:58:14 PM UTC-7, hughag...@gmail.com wrote:
> If Forth would embrace inheritance and general-purpose data-structures, this would give Forth an obvious advantage over C --- but the Forth-200x committee seem to be dedicated to imposing C's restrictions on Forth --- the Forth-200x committee wants Forth to be an RPN version of C, with no distinction between Forth and C except postfix-versus-infix (which is really meaningless).

Most likely, the reason why Elizabeth Rather is opposed to the use of inheritance such as I use in my novice-package, is because Forth Inc. is selling SwiftForth on the basis that it has SWOOP which is a vendor-specific OOP package --- one of their main selling points is that OOP is not available under ANS-Forth --- this is why they don't want a simple OOP system such as mine to be used under ANS-Forth.

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

#49827 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On 8/6/2016 6:58 PM, hughaguilar96@gmail.com wrote:
> On Friday, August 5, 2016 at 10:16:08 PM UTC-7, Cecil - k5nwa wrote:
>> A long time ago I started using Borland Delphi for writing work related
>> and personal software but I could not afford the horribly expensive
>> database capable version at the time. I ended writing my own Self
>> Balancing B-Tree multi key database library, it was complex to figure it
>> out, and it took me a while to get it right, but once it was working I
>> would use it all over the place. It was very fast, it took little space,
>> and was very flexible so for years I used it for all sorts of tools and
>> applications. Yet when I mentioned on this list that it would be nice to
>> have a library with the much simpler link list, you would have thought I
>> said that babies should be starved, and burned alive, some people were
>> all over me criticizing my desire for a convenient link list in a
>> library, after all Forth itself uses linked list.
>
> If you get your self-balancing B-Tree to work, I will put it in the novice-package --- that way you can be sure that nobody will ever use it! --- everything in the novice-package automatically gets dismissed as "crap" by the committee...
>
> I am not aware of any other language in which code-libraries are forbidden. Languages have various levels of support for code-libraries, and the better support the language has, the better the language is. Nobody forbids code-libraries though, other than the ANS-Forth and Forth-200x committees (and COBOL too).
>
> What is sad about this, is that Forth has better support for code-libraries than C does. In C, a struct has to start on offset zero. If the parent struct is made into the first field of the child struct, this won't work because now you need to doubly dereference the field names (use two -> or two . operators). Of course, if you have a struct inheriting from a struct which inherits from another struct, then you have to triply dereference the field names. If you typecast your pointer to the parent struct, you can avoid multiple dereferencing of the field names, but now SIZEOF doesn't work correctly anymore because it gives the parent size rather than the child size. All in all, inheritance in C is a nightmare. By comparison, inheritance in Forth is easy --- yet ANS-Forth culture absolutely forbids having structs inherit from each other --- Pelc went out of his way to give us STRUCT[ which has no purpose at all except to force the starting offset to be zero and hence to make Forth look like C along with C's restrictions against inheritance.
>
> If Forth would embrace inheritance and general-purpose data-structures, this would give Forth an obvious advantage over C --- but the Forth-200x committee seem to be dedicated to imposing C's restrictions on Forth --- the Forth-200x committee wants Forth to be an RPN version of C, with no distinction between Forth and C except postfix-versus-infix (which is really meaningless).
>
>
I been looking at the printed listing and I'm not sure it will be 
practical to translate it to Forth, it makes heavy use of structures, 
pointers to structures. With many people demanding that Forth continue 
to stay in the 1970s, no libraries, no structures, no decently built 
object system, it will be hard to duplicate the Pascal code. Most likely 
I will work eventually in an interface to MySQL and leave it at that, no 
hurry there. I need MySQL capability eventually as I have several web 
sites I maintain and they run on MySQL, I would like to build some 
conversion programs to manipulate and modify MySQL databases used in 
those sites.

First I need to decide on what Forth system I will use for my desktops 
computers, that is why I been playing with different Forth and Forth 
like systems. I will be using two different Forths, one for desktops, 
with decent library system and tools. The other a stripped down Forth 
for embedded systems, I been using eForth for that purpose lately and 
it's not bad for that purpose,  there are plenty of versions available 
for various CPUs, but I have sources to one version that is easily 
migrated, I been using it with FPGA Forth CPUs and it's working well.


>> I also have been looking to see if anyone in the past has created a
>> decent library system, which is another item that is considered heresy
>> in the Forth community here, yet ANS Forth uses primitive libraries but
>> most won't admit it, they are called word sets. Recently I saw a post on
>> ideas for a library system where  you can have public and private words,
>> I will be looking at it next week and see if the ideas are useful for
>> what I need.
>
> As I mentioned in that thread, I had this working under UR/Forth 30 years ago, but I had to delve into UR/Forth internal workings, so my code wasn't Forth-83.
>
> There has been no improvement in ANS-Forth --- this is still banned, but you may be able to get it working for a specific compiler by delving into the internal workings of that compiler.
>
> What is sad about this, is that it is trivial to implement --- most of the time is spent in disassembling the compiler to figure out how dictionary headers are stored internally --- if you have this info though (the compiler-writer obviously does) then the implementation is the work of one hour or less.
>
> This was banned from ANS-Forth specifically for the purpose of making code-libraries difficult to implement --- you end up with a lot of name clashes --- this makes the code-library less useful, proving the point of those you say that code-libraries are taboo.
>
I remember UR/Forth, never owned it, but they advertised all over, maybe 
I should have spent the money but there were many free versions 
available so I used those. I wasn't fond of Forth83 just like WinForth 
later, it tried to have everything but little in terms of useful modern 
programing features.

-- 
Cecil - k5nwa

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

#49829 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Saturday, August 6, 2016 at 7:28:45 PM UTC-7, Cecil - k5nwa wrote:
> On 8/6/2016 6:58 PM, hughaguilar96@gmail.com wrote:
> > On Friday, August 5, 2016 at 10:16:08 PM UTC-7, Cecil - k5nwa wrote:
> >> A long time ago I started using Borland Delphi for writing work related
> >> and personal software but I could not afford the horribly expensive
> >> database capable version at the time. I ended writing my own Self
> >> Balancing B-Tree multi key database library, it was complex to figure it
> >> out, and it took me a while to get it right, but once it was working I
> >> would use it all over the place. It was very fast, it took little space,
> >> and was very flexible so for years I used it for all sorts of tools and
> >> applications. 
> >> ...
> I been looking at the printed listing and I'm not sure it will be 
> practical to translate it to Forth, it makes heavy use of structures, 
> pointers to structures. With many people demanding that Forth continue 
> to stay in the 1970s, no libraries, no structures, no decently built 
> object system, it will be hard to duplicate the Pascal code. 

I don't see any problem with porting Pascal code into ANS-Forth --- just ignore the committee and their demand that we don't use structs --- I do fine in my novice-package ignoring them, and if you going to get your code into the novice-package you will have to ignore them too.

I have a book on Pascal-S that supported nested functions. I know that Borland's Turbo-Pascal did not support nested functions though --- it was a trimmed-down non-standard Pascal --- I would assume that Borland's Delphi also did not support nested functions, but I never delved into Delphi very deeply.

If Delphi Pascal is pretty comparable to Turbo Pascal, there should be no difficulty in porting to Forth. I hope that you do provide B-Trees to the novice-package --- I don't know enough about B-Trees to do this myself (without quite a lot of research) --- if you do it though, that would be pretty cool.

> Most likely 
> I will work eventually in an interface to MySQL and leave it at that, no 
> hurry there. I need MySQL capability eventually as I have several web 
> sites I maintain and they run on MySQL, I would like to build some 
> conversion programs to manipulate and modify MySQL databases used in 
> those sites.
> 
> First I need to decide on what Forth system I will use for my desktops 
> computers, that is why I been playing with different Forth and Forth 
> like systems. I will be using two different Forths, one for desktops, 
> with decent library system and tools. The other a stripped down Forth 
> for embedded systems, I been using eForth for that purpose lately and 
> it's not bad for that purpose,  there are plenty of versions available 
> for various CPUs, but I have sources to one version that is easily 
> migrated, I been using it with FPGA Forth CPUs and it's working well.

Eventually I will bring out Straight Forth. I'm taking my time with that --- I have a lot to learn --- I want to avoid standardizing my ignorance, so I'm holding off on releasing it.

In the meantime, just use VFX. My rquotations work on VFX and SwiftForth --- I could get them to work on any Forth system, most likely, but don't know until I try --- VFX generates pretty fast code, so it could be used for commercial programming.

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

#49831 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On 8/6/2016 9:46 PM, hughaguilar96@gmail.com wrote:
> On Saturday, August 6, 2016 at 7:28:45 PM UTC-7, Cecil - k5nwa wrote:
>> On 8/6/2016 6:58 PM, hughaguilar96@gmail.com wrote:
>>> On Friday, August 5, 2016 at 10:16:08 PM UTC-7, Cecil - k5nwa wrote:
>>>> A long time ago I started using Borland Delphi for writing work related
>>>> and personal software but I could not afford the horribly expensive
>>>> database capable version at the time. I ended writing my own Self
>>>> Balancing B-Tree multi key database library, it was complex to figure it
>>>> out, and it took me a while to get it right, but once it was working I
>>>> would use it all over the place. It was very fast, it took little space,
>>>> and was very flexible so for years I used it for all sorts of tools and
>>>> applications.
>>>> ...
>> I been looking at the printed listing and I'm not sure it will be
>> practical to translate it to Forth, it makes heavy use of structures,
>> pointers to structures. With many people demanding that Forth continue
>> to stay in the 1970s, no libraries, no structures, no decently built
>> object system, it will be hard to duplicate the Pascal code.
>
> I don't see any problem with porting Pascal code into ANS-Forth --- just ignore the committee and their demand that we don't use structs --- I do fine in my novice-package ignoring them, and if you going to get your code into the novice-package you will have to ignore them too.
>
> I have a book on Pascal-S that supported nested functions. I know that Borland's Turbo-Pascal did not support nested functions though --- it was a trimmed-down non-standard Pascal --- I would assume that Borland's Delphi also did not support nested functions, but I never delved into Delphi very deeply.
>
> If Delphi Pascal is pretty comparable to Turbo Pascal, there should be no difficulty in porting to Forth. I hope that you do provide B-Trees to the novice-package --- I don't know enough about B-Trees to do this myself (without quite a lot of research) --- if you do it though, that would be pretty cool.
>
Delphi generated fairly good code, and it does allow defining a function 
inside a function with access to the parents variables, those routines 
were very fast with old PCs it could store and sort about 10 thousand 
records per second, reading was even faster. I'm not sure that MySQL 
could be that fast but I never tested it to see how efficient it was.

Fully functional quotations would really be useful in implementing the 
conversion. I used to have some programs that would translate C or Turbo 
Pascal code to Forth, and it was very thorough, most of the time the 
generated code needed no changes, but I lost it a long time ago.

One wonders why so many are so against structures, and libraries, it's 
hard to understand, maybe they have never used a good implementation of 
these things to see how helpful they are in implementing and managing 
software, in any case I live in the 21th Century not the 7th Century so 
in the end I will do what I want.


>> Most likely
>> I will work eventually in an interface to MySQL and leave it at that, no
>> hurry there. I need MySQL capability eventually as I have several web
>> sites I maintain and they run on MySQL, I would like to build some
>> conversion programs to manipulate and modify MySQL databases used in
>> those sites.
>>
>> First I need to decide on what Forth system I will use for my desktops
>> computers, that is why I been playing with different Forth and Forth
>> like systems. I will be using two different Forths, one for desktops,
>> with decent library system and tools. The other a stripped down Forth
>> for embedded systems, I been using eForth for that purpose lately and
>> it's not bad for that purpose,  there are plenty of versions available
>> for various CPUs, but I have sources to one version that is easily
>> migrated, I been using it with FPGA Forth CPUs and it's working well.
>
> Eventually I will bring out Straight Forth. I'm taking my time with that --- I have a lot to learn --- I want to avoid standardizing my ignorance, so I'm holding off on releasing it.
>
> In the meantime, just use VFX. My rquotations work on VFX and SwiftForth --- I could get them to work on any Forth system, most likely, but don't know until I try --- VFX generates pretty fast code, so it could be used for commercial programming.
>

I have VFX Standard and it works well, it's faster than SwiftForth which 
I also own a copy with source.  I don't have the source to VFX Standard 
but I can't afford to buy the source, I have a copy as an item needed to 
compile the ARM Pro Compiler for which I have the source. It's not the 
evaluation copy so I can save copies of the modified system so 
theoretically that could be my Desktop version but I wish I had the 
source, one day Stephen Pelc will retire or an accident can happen, and 
I will be in a pickle if there are problems, Windows is a moving target 
and eventually it could cause problems. I hate to invest a lot of my 
time to build the libraries to have the items I need and have no 
guarantee that I will not have wasted my efforts.

A thought that often passes my mind is why not take eForth and flesh it 
out a little more, then use it to create the libraries I want and have 
full source to the darn thing. The version I have has a cross compiler 
so one could generate a stand alone target system, for whatever CPU one 
cares to modify it for but that is a lot of work, so I keep looking, but 
having source is a item high on the list. eForth is my fallback system 
if I can't find something with source that is workable.

-- 
Cecil - k5nwa

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

#49832 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Saturday, August 6, 2016 at 10:54:17 PM UTC-5, Cecil - k5nwa wrote:
> A thought that often passes my mind is why not take eForth and flesh it
> out a little more, then use it to create the libraries I want and have
> full source to the darn thing.

"Other people want to stay in the 1970s!"

"I've decided to ignore VFX, SwiftForth, iForth, Win32Forth, wina,
which all work after a fashion on Windows, so that I can start from
scratch with a Forth from the 1970s."

#JustCecilleThings

You two deserve each other.


-- Julian

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

#49833 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

Julian Fondren <julian.fondren@gmail.com> writes:
> "I've decided to ignore VFX, SwiftForth, iForth, Win32Forth, wina,
> which all work after a fashion on Windows

Fwiw, Gforth also works on Windows, though it doesn't have any Windows
GUI calls built in.  It runs in a dos box.  Maybe that's enough for some
purposes.  

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

#49834 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Saturday, August 6, 2016 at 8:54:17 PM UTC-7, Cecil - k5nwa wrote:
> On 8/6/2016 9:46 PM, hughaguilar96@gmail.com wrote:
> > I have a book on Pascal-S that supported nested functions. I know that Borland's Turbo-Pascal did not support nested functions though --- it was a trimmed-down non-standard Pascal --- I would assume that Borland's Delphi also did not support nested functions, but I never delved into Delphi very deeply.
> >
> > If Delphi Pascal is pretty comparable to Turbo Pascal, there should be no difficulty in porting to Forth. I hope that you do provide B-Trees to the novice-package --- I don't know enough about B-Trees to do this myself (without quite a lot of research) --- if you do it though, that would be pretty cool.
> >
> Delphi generated fairly good code, and it does allow defining a function 
> inside a function with access to the parents variables, those routines 
> were very fast with old PCs it could store and sort about 10 thousand 
> records per second, reading was even faster. I'm not sure that MySQL 
> could be that fast but I never tested it to see how efficient it was.
> Fully functional quotations would really be useful in implementing the 
> conversion. 

Well, Pascal-S had nested functions that only remained valid so long as the parent function remained in scope. Pascal-S allowed nested functions within nested functions, and it maintained a "display-pointer chain" so the lowest level function had access to all the local variables all the way up to the highest level function. This is very complicated! If your code relies on this, it is not going to be supported in Straight Forth. My quotations don't have locals of their own --- only the parent function has locals --- quotations can be nested, but there is no display-pointer chain because all of them just use the parent function's locals. Straight Forth is pretty simple, and the programs are expected to be pretty simple --- I don't actually know what all that complexity in Pascal-S was for --- I think it was just gratuitous complexity, like in a science-fair project, without any practical purpose. The rquotations that I wrote earlier for VFX and SwiftForth are pretty restrictive --- Straight Forth is more robust because it uses a fat-xt and so the quotation doesn't have to be executed at a certain level below the parent.

Try using the rquotations first under VFX. If that doesn't work, then I will get back to work on Straight Forth and put together a working system that you can use which will have the fat-xt quotations. If that doesn't work, then you are out of luck --- I don't intend Straight Forth to be any more complicated than this --- Straight Forth is intended to be about half the size of ANS-Forth with about twice the features, but nothing super-complicated.

Don't worry too much about VFX being closed-source --- you can always port your program to another system later on if necessary --- it is unlikely that you will be relying on any aspects of VFX that you will be unable to figure out how they work internally.

> A thought that often passes my mind is why not take eForth and flesh it 
> out a little more, then use it to create the libraries I want and have 
> full source to the darn thing. The version I have has a cross compiler 
> so one could generate a stand alone target system, for whatever CPU one 
> cares to modify it for but that is a lot of work, so I keep looking, but 
> having source is a item high on the list. eForth is my fallback system 
> if I can't find something with source that is workable.

I looked into eForth briefly, but I was stymied by the lack of documentation. I needed a reference document of the words in the system. I wasn't interested in learning the internal workings. I just wanted to be able to write basic programs, but I didn't know how to do things like reading text files, and I didn't have time to figure this out by delving into the source-code (I was getting paid to write a program; I couldn't spend days just figuring out how to read a text file). Because of this, I switched over to VFX.

It is possible that this documentation exists and I just couldn't find it. I can't believe anybody would ever use eForth if there wasn't documentation. Nothing on the website helped though. It is possible that I needed to buy one of their books, but I wasn't going to buy books randomly, so I sent an email asking which book I needed --- I never got any reply --- it is possible that C.H.Ting was already having health problems at that time that prevented him from continuing to support eForth.

If you have documentation for eForth, I would be willing to take a look at eForth again. Also, because I'm not getting paid now, I'm no longer under the gun, so I have more time to just explore the source-code. I might be able to make something of eForth yet.

In many ways, my goals with Straight Forth are similar to C.H.Ting's goals with eForth --- powerful and straightforward --- the exact opposite of ANS-Forth, which was a weak and ambiguous.

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

#49835 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On 8/7/2016 1:49 AM, hughaguilar96@gmail.com wrote:
> On Saturday, August 6, 2016 at 8:54:17 PM UTC-7, Cecil - k5nwa wrote:
>
>> A thought that often passes my mind is why not take eForth and flesh it
>> out a little more, then use it to create the libraries I want and have
>> full source to the darn thing. The version I have has a cross compiler
>> so one could generate a stand alone target system, for whatever CPU one
>> cares to modify it for but that is a lot of work, so I keep looking, but
>> having source is a item high on the list. eForth is my fallback system
>> if I can't find something with source that is workable.
>
> I looked into eForth briefly, but I was stymied by the lack of documentation. I needed a reference document of the words in the system. I wasn't interested in learning the internal workings. I just wanted to be able to write basic programs, but I didn't know how to do things like reading text files, and I didn't have time to figure this out by delving into the source-code (I was getting paid to write a program; I couldn't spend days just figuring out how to read a text file). Because of this, I switched over to VFX.
>
> It is possible that this documentation exists and I just couldn't find it. I can't believe anybody would ever use eForth if there wasn't documentation. Nothing on the website helped though. It is possible that I needed to buy one of their books, but I wasn't going to buy books randomly, so I sent an email asking which book I needed --- I never got any reply --- it is possible that C.H.Ting was already having health problems at that time that prevented him from continuing to support eForth.
>
> If you have documentation for eForth, I would be willing to take a look at eForth again. Also, because I'm not getting paid now, I'm no longer under the gun, so I have more time to just explore the source-code. I might be able to make something of eForth yet.
>
> In many ways, my goals with Straight Forth are similar to C.H.Ting's goals with eForth --- powerful and straightforward --- the exact opposite of ANS-Forth, which was a weak and ambiguous.
>
Give me a couple of days, I'm in the middle of something not computer 
related, I found several sources of documentation on eForth, enough to 
be dangerous maybe, but better than a sharp stick in the eye. I have 
several sources of documentation on eForth from C H Ting.
-- 
Cecil - k5nwa

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

#49836 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

Cecil Bayona <cbayona@cbayona.com> writes:
> I found several sources of documentation on eForth, enough to
> be dangerous maybe, but better than a sharp stick in the eye. I have
> several sources of documentation on eForth from C H Ting.

Bill Muench's site is down but you can probably find his eforth pages in
the wayback machine.  IIRC there was eforth itself, a metacompiler for
eforth, and a juiced-up version of eforth with more optimizations than
the stripped down version.  Ting's version was different in that it was
bootstrapped from x86 assembly code, which he felt was easier for Forth
newbies to understand.  Jeff Fox has some discussion of this idea on his
site someplace.  I found the original eforth code to be quite readable,
but it is a very minimal Forth that uses a lot of clever tricks to be
tiny.  

There is a C conversion here that is also simple:

 http://chiselapp.com/user/tehologist/repository/compc/home

Mostly I don't understand quite what you're trying to do.  Gforth is
reasonably fast and well documented, and it has plenty of creature
comforts (at least in the language implementation).  So I'd probably use
it if the target machine is powerful enough for it.  For smaller targets
there's lots of other choices such as FlashForth, Mecrisp, CamelForth,
etc. etc. in addition to eForth.  Plus of course there are the
commercial implementations, that have real compilers, good support,
etc., at the expense of actual $$$$.  And then there are variants like
oForth and 8th, that are more machine hungry than traditional Forth, but
that can make life easier in various ways.

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

#49839 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On 8/7/2016 3:06 AM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> I found several sources of documentation on eForth, enough to
>> be dangerous maybe, but better than a sharp stick in the eye. I have
>> several sources of documentation on eForth from C H Ting.
>
> Bill Muench's site is down but you can probably find his eforth pages in
> the wayback machine.  IIRC there was eforth itself, a metacompiler for
> eforth, and a juiced-up version of eforth with more optimizations than
> the stripped down version.  Ting's version was different in that it was
> bootstrapped from x86 assembly code, which he felt was easier for Forth
> newbies to understand.  Jeff Fox has some discussion of this idea on his
> site someplace.  I found the original eforth code to be quite readable,
> but it is a very minimal Forth that uses a lot of clever tricks to be
> tiny.
>

I'll look there but I often found that the Wayback machine doesn't 
include downloads, which is OK if all you want is the web pages but you 
never can tell, so I'll look.

> There is a C conversion here that is also simple:
>
>  http://chiselapp.com/user/tehologist/repository/compc/home
>
Interesting version, I'll look at it. The eForth version I'm currently 
using has a meta-compiler so it generates a native code version to run 
on the target system, that is and advantage because of it's ability to 
run faster in the target system.

> Mostly I don't understand quite what you're trying to do.  Gforth is
> reasonably fast and well documented, and it has plenty of creature
> comforts (at least in the language implementation).  So I'd probably use
> it if the target machine is powerful enough for it.  For smaller targets
> there's lots of other choices such as FlashForth, Mecrisp, CamelForth,
> etc. etc. in addition to eForth.  Plus of course there are the
> commercial implementations, that have real compilers, good support,
> etc., at the expense of actual $$$$.  And then there are variants like
> oForth and 8th, that are more machine hungry than traditional Forth, but
> that can make life easier in various ways.
>
   What am I trying to do? I wonder myself but what I'm looking for is a 
simple Forth that is easy to understand and modify for some embedded but 
mostly custom Forth CPUs. The version I'm using is not your standard 
eForth version, it starts out as a Windows version of eForth, it has a 
very simple meta-compiler, and assembler, and a source version of eForth 
that uses very few machine language primitives, and mostly it's written 
in eForth itself so it's easy to convert to other CPUs. It's from C H 
Ting but it's not the Standard eForth you find out there,  he uses it in 
his FPGA projects because it's so easy to modify for new CPUs which is 
what I'm working with.

GForth on the other hand is build for desktop use, not easily changeable 
to other CPUs and quite large sot not suited for my purposes. I am aware 
of other Forth such as meCrisp, and NoForth for embedded use, both of 
these seem to be excellent at what they do, their issue is that adapting 
them to use with custom FPGA CPUs is not trivial task compared to the 
eForth version I mentioned above.

As for other desktop tools I did purchased a copy of 8th and I'm looking 
at oForth for a special desktop project that require a lot of list and 
text manipulation, hopefully one of them will work for that purposes.

There is a certain appeal to eForth because of it's simplicity, and 
using it for custom CPUs and for the Desktop with a souped up version 
would make life a little easier in the sense that for both targets one 
is basically using similar versions of Forth.
-- 
Cecil - k5nwa

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

#49852 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Sunday, August 7, 2016 at 5:05:56 AM UTC-7, Cecil - k5nwa wrote:
> ...I'm looking 
> at oForth for a special desktop project that require a lot of list and 
> text manipulation...

What does oForth provide in regard to linked lists and strings that I don't provide in the novice package? LIST.4TH and STRING-STACK.4TH pretty much cover those two subjects, I think.

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

#49855 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On 8/7/2016 3:01 PM, hughaguilar96@gmail.com wrote:
> On Sunday, August 7, 2016 at 5:05:56 AM UTC-7, Cecil - k5nwa wrote:
>> ...I'm looking
>> at oForth for a special desktop project that require a lot of list and
>> text manipulation...
>
> What does oForth provide in regard to linked lists and strings that I don't provide in the novice package? LIST.4TH and STRING-STACK.4TH pretty much cover those two subjects, I think.
>
I'm not sure but oForth have Listbuffers, mutable list of items with 
your standard features, get, save, insert, copy,and delete items or 
entire list, plain list are immutable so they are not as useful but 
still usable to hold non-changing data such as conversion patterns. I'm 
not an expert so take the information on this reply with a grain of salt.

I'm not familiar enough with your novice package enough to tell you the 
difference between your software and these two Forth like programs. Next 
week I have allotted some time to compare oForth, 8th, and VFX with your 
library to see which are more usable, and efficient.

8th does not have list that I can find, but it has arrays of containers 
that can be used for a similar purpose, it's different in the sense that 
they are "containers" which are just pointers and can hold any type of 
object including other containers, copying, of an item means copying the 
pointer not the data so it's more efficient when manipulating a lot of 
containers. That scheme is not efficient when using integers but can be 
efficient with complex containers.

8th is also quite different from Forth in other ways, I have not found 
Builds, Does or any compiler words to define words with a compile time 
and a different run time behavior that would be rather limiting, but I'm 
not familiar enough to be 100% confident that it is so, I could have 
missed it somehow.
-- 
Cecil - k5nwa

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

#49857 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Sunday, August 7, 2016 at 2:02:49 PM UTC-7, Cecil - k5nwa wrote:
> On 8/7/2016 3:01 PM, hughaguilar96@gmail.com wrote:
> > On Sunday, August 7, 2016 at 5:05:56 AM UTC-7, Cecil - k5nwa wrote:
> >> ...I'm looking
> >> at oForth for a special desktop project that require a lot of list and
> >> text manipulation...
> >
> > What does oForth provide in regard to linked lists and strings that I don't provide in the novice package? LIST.4TH and STRING-STACK.4TH pretty much cover those two subjects, I think.
> >
> I'm not sure but oForth have Listbuffers, mutable list of items with 
> your standard features, get, save, insert, copy,and delete items or 
> entire list, plain list are immutable so they are not as useful but 
> still usable to hold non-changing data such as conversion patterns. I'm 
> not an expert so take the information on this reply with a grain of salt.
> 
> I'm not familiar enough with your novice package enough to tell you the 
> difference between your software and these two Forth like programs. Next 
> week I have allotted some time to compare oForth, 8th, and VFX with your 
> library to see which are more usable, and efficient.

You may also want to look at Factor. I was impressed by how Factor uses one data-structure for pretty much everything. This is the "sequence." It is possible to build other data-structures, but for the most part sequences are used unless you have some special need that sequences don't support. Having one data-structure like this makes the programs consistent and easy to read --- this was my inspiration for LIST.4TH --- I use lists for pretty much everything in the novice-package.

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

#49872 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

Le dimanche 7 août 2016 23:02:49 UTC+2, Cecil - k5nwa a écrit :
> I'm not sure but oForth have Listbuffers, mutable list of items with 
> your standard features, get, save, insert, copy,and delete items or 
> entire list, plain list are immutable so they are not as useful but 
> still usable to hold non-changing data such as conversion patterns. I'm 
> not an expert so take the information on this reply with a grain of salt.
> 

Yes.

Items into listbuffers are not limited to integers.
They can also be others objects, or even other lists. 
In that case, the listbuffer holds a pointer to the object. For instance : 

ListBuffer new
12 over add
12.3 over add 
4 seq over add
"abcdef" over add
[ "abc" , "def" , "ghi" ] over add
.s
[1] (ListBuffer) [12, 12.3, [1, 2, 3, 4], abcdef, [abc, def, ghi]]
ok
#size over map .s
1] (List) [1, 1, 4, 6, 3]
2] (ListBuffer) [12, 12.3, [1, 2, 3, 4], abcdef, [abc, def, ghi]]
ok

But you are right : for small integers, the listbuffer (and lists) holds 
the integer value, not a pointer to this integer.

Franck
http://www.oforth.com

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

#49876 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On 8/8/2016 5:13 AM, franck.bensusan@gmail.com wrote:
> Le dimanche 7 août 2016 23:02:49 UTC+2, Cecil - k5nwa a écrit :
>> I'm not sure but oForth have Listbuffers, mutable list of items with
>> your standard features, get, save, insert, copy,and delete items or
>> entire list, plain list are immutable so they are not as useful but
>> still usable to hold non-changing data such as conversion patterns. I'm
>> not an expert so take the information on this reply with a grain of salt.
>>
>
> Yes.
>
> Items into listbuffers are not limited to integers.
> They can also be others objects, or even other lists.
> In that case, the listbuffer holds a pointer to the object. For instance :
>
> ListBuffer new
> 12 over add
> 12.3 over add
> 4 seq over add
> "abcdef" over add
> [ "abc" , "def" , "ghi" ] over add
> .s
> [1] (ListBuffer) [12, 12.3, [1, 2, 3, 4], abcdef, [abc, def, ghi]]
> ok
> #size over map .s
> 1] (List) [1, 1, 4, 6, 3]
> 2] (ListBuffer) [12, 12.3, [1, 2, 3, 4], abcdef, [abc, def, ghi]]
> ok
>
> But you are right : for small integers, the listbuffer (and lists) holds
> the integer value, not a pointer to this integer.
>
> Franck
> http://www.oforth.com
>
Thanks for the extra information, I should have been more clear, in that 
the ListBuffer could hold not just integers, I just mentioned "items" 
and didn't specify what the items were.

ListBuffer is a very powerful and useful feature in oForth, quite handy 
for use with applications that require complex data structures and its 
manipulation. That is one of many powerful features in oForth that are 
helpful in writing applications. The only negative I would say about 
oForth is the documentation, alas a failing of many programs, otherwise 
oForth seems to have been built with a purpose, which is to efficiently 
write applications for the desktop computer.

I have two pieces of software that I been interested in lately, and they 
both have complex data storage and manipulation, One is a BT+ database 
program to be converted from Delphi Pascal, the second a complex Text 
Macro Processing Tool. In trying to figure out what software tools I 
will use, so I will be trying out some test programs in 8th, oForth, and 
VFX Forth with Hugh's library. I will be looking at ease of 
implementation, and the speed as in both software tools, speed is vital 
in order for them to be usable.

Today I started the process, I'm trying to figure out a test which will 
be representative of the task that will need to be done in writing those 
two applications, yet be as simple as possible. Unfortunately my brain 
seems fixated in a Delphi Pascal solution, I sometimes find it hard to 
think in terms of Forth when complex programs need to be created, when 
thinking about complex task my brain wants to switch to Delphi Pascal on 
auto-pilot, I'm hoping to fix that with these two projects.
-- 
Cecil - k5nwa

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

#49854 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

Cecil Bayona <cbayona@cbayona.com> writes:
> The eForth version I'm currently using has a meta-compiler so it
> generates a native code version to run on the target system

Oh that's interesting--I don't think I've seen it.  Is it online?

>   What am I trying to do? I wonder myself but what I'm looking for is
> a simple Forth that is easy to understand and modify for some embedded
> but mostly custom Forth CPUs. 

Do you mean a resident Forth that will run on a softcore CPU of your own
design?  Or a cross-compiler like the one Bernd uses for his b16?  If
you want a tiny resident Forth, eForth seems like a good starting point.
For cross-compilation, eForth is pretty limited unless you extend it a
lot, so you might want to use something more featureful.

> There is a certain appeal to eForth because of it's simplicity, and
> using it for custom CPUs and for the Desktop with a souped up version
> would make life a little easier in the sense that for both targets one
> is basically using similar versions of Forth.

I'll be interested in seeing the souped up version when you have it.
The version I played with was imho too limited for comfort, compared to
other Forths out there.

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

#49858 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On 8/7/2016 3:55 PM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> The eForth version I'm currently using has a meta-compiler so it
>> generates a native code version to run on the target system
>
> Oh that's interesting--I don't think I've seen it.  Is it online?

Yes one version is available with the code to work on the Ting's ep16 CPU.
>
>>   What am I trying to do? I wonder myself but what I'm looking for is
>> a simple Forth that is easy to understand and modify for some embedded
>> but mostly custom Forth CPUs.
>
> Do you mean a resident Forth that will run on a softcore CPU of your own
> design?  Or a cross-compiler like the one Bernd uses for his b16?  If
> you want a tiny resident Forth, eForth seems like a good starting point.
> For cross-compilation, eForth is pretty limited unless you extend it a
> lot, so you might want to use something more featureful.

The meta compiler provided will compile the source that is used to 
create a target version of eForth that runs in the FPGA target softcore 
CPU. Quite useful, you run native eForth on your target CPU.
>
>> There is a certain appeal to eForth because of it's simplicity, and
>> using it for custom CPUs and for the Desktop with a souped up version
>> would make life a little easier in the sense that for both targets one
>> is basically using similar versions of Forth.
>
> I'll be interested in seeing the souped up version when you have it.
> The version I played with was imho too limited for comfort, compared to
> other Forths out there.
>
It will be a while, I'm doing research to see if something else out 
there would be a better choice, eForth is my fallback position , it does 
advantages in that the same basic Forth would be used in softcores and 
the desktop, with the desktop being clearly more capable.
-- 
Cecil - k5nwa

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

#49859 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Sunday, August 7, 2016 at 1:55:12 PM UTC-7, Paul Rubin wrote:
> For cross-compilation, eForth is pretty limited unless you extend it a
> lot, so you might want to use something more featureful.

I have said many times that a cross-compiler needs these features:
1.) LITERAL is vectored so the built-in outer-interpreter can be used and when it encounters a number in a TARG colon word it compiles that number into the target memory rather than the host memory.
2.) The ability to take an xt and determine the following attributes: 
    what vocabulary it is in
    immediate or non-immediate
    smudged or not smudged
    smudge-ready or not smudge-ready
3.) The ability to take an xt and modify those attributes.
4.) CONTEXT and CURRENT have to work like they did in Forth-83.
5.) FIND has to work correctly.

I have fixed ANS-Forth so #4 and #5 are true now. There is nothing I can do in ANS-Forth to obtain #1 #2 and #3 however --- these have all been banned in the ANS-Forth Standard.

Would it be easier to modify eForth to provide these features? I would expect so!

Other than this, I don't really need a "featureful" Forth system to write a cross-compiler --- I do need it to be 32-bit though, as there isn't enough memory in a 16-bit system to both hold the target image and the cross-compiler --- I can do this in 16-bit UR/Forth though, by allocating a 64KB segment to be the target image, and using ES to address it. I started MFX in the 16-bit UR/Forth, but then had to switch to the 32-bit UR/Forth because MFX itself became too big to fit in the 64KB DS segment; also, the MiniForth needed 64KW (128KB) target images for both code and data memory --- all in all, MFX was just too big to run under 16-bit UR/Forth.

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

#49866 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On Sunday, August 7, 2016 at 3:03:12 PM UTC-7, hughag...@gmail.com wrote:
> I have said many times that a cross-compiler needs these features:
> 1.) LITERAL is vectored so the built-in outer-interpreter can be used and when it encounters a number in a TARG colon word it compiles that number into the target memory rather than the host memory.
> 2.) The ability to take an xt and determine the following attributes: 
>     what vocabulary it is in
>     immediate or non-immediate
>     smudged or not smudged
>     smudge-ready or not smudge-ready
> 3.) The ability to take an xt and modify those attributes.
> 4.) CONTEXT and CURRENT have to work like they did in Forth-83.
> 5.) FIND has to work correctly.
> 
> I have fixed ANS-Forth so #4 and #5 are true now. There is nothing I can do in ANS-Forth to obtain #1 #2 and #3 however --- these have all been banned in the ANS-Forth Standard.

I am not sure I follow you here.

By ANS-Forth, do you mean Forth-94? What about EuroForth?

I worked on a cross compiler, but got the semantics for different
modes wrong. I will need to restart that work at some point, but now I
am a little bit too busy with other things.

This is why I want to figure out if I should go for search-order based
compilation state, to make FIND only find compiling words during
compilation. I do not feel comfortable with double-xts at the moment.

I do not understand in what way the standard prevent you from making a
cross compiler? Conceptionally what I did was to have a record of
low-level compiling primitives, one for host compilation and one for
target cross-compilation. The words that change between compilation
modes simply swap these records. Then the low-level standard words in
Forth that compile to memory simply invoke primitives in the active
compiler record.

I just put whatever functions I needed in that record.

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

#49868 — Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc

On 8/7/16 8:02 PM, Håkan Thörngren wrote:
> On Sunday, August 7, 2016 at 3:03:12 PM UTC-7, hughag...@gmail.com wrote:
>> I have said many times that a cross-compiler needs these features:
>> 1.) LITERAL is vectored so the built-in outer-interpreter can be used and when it encounters a number in a TARG colon word it compiles that number into the target memory rather than the host memory.
>> 2.) The ability to take an xt and determine the following attributes:
>>     what vocabulary it is in
>>     immediate or non-immediate
>>     smudged or not smudged
>>     smudge-ready or not smudge-ready
>> 3.) The ability to take an xt and modify those attributes.
>> 4.) CONTEXT and CURRENT have to work like they did in Forth-83.
>> 5.) FIND has to work correctly.
>>
>> I have fixed ANS-Forth so #4 and #5 are true now. There is nothing I can do in ANS-Forth to obtain #1 #2 and #3 however --- these have all been banned in the ANS-Forth Standard.
>
> I am not sure I follow you here.
>
> By ANS-Forth, do you mean Forth-94? What about EuroForth?
>
> I worked on a cross compiler, but got the semantics for different
> modes wrong. I will need to restart that work at some point, but now I
> am a little bit too busy with other things.
>
> This is why I want to figure out if I should go for search-order based
> compilation state, to make FIND only find compiling words during
> compilation. I do not feel comfortable with double-xts at the moment.
>
> I do not understand in what way the standard prevent you from making a
> cross compiler? Conceptionally what I did was to have a record of
> low-level compiling primitives, one for host compilation and one for
> target cross-compilation. The words that change between compilation
> modes simply swap these records. Then the low-level standard words in
> Forth that compile to memory simply invoke primitives in the active
> compiler record.
>
> I just put whatever functions I needed in that record.

There are a number of Forth cross-compilers that represent extensions of 
ANS/ISO Forth, and have been for over 20 years. You may find a 
discussion of standard Forth cross-compilers here: 
http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2007-06/msg00283.html

Both FORTH, Inc. and MPE offer cross-compilers based on this model, 
although both companies have improved their offerings since these 
documents were written. Still, the basic principles are there. The 
articles provide a good philosophical framework. You may also try and 
exercise the cross compilers from FORTH, Inc. and MPE using free 
evaluation versions to get a feel for the technology as well as the 
"look and feel" (which is not described in the documents). The download 
from FORTH, Inc. includes complete documentation. I assume the MPE one 
does, too.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

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

csiph-web