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

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

who really use Forth ?

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

Contents

  who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-30 16:12 -0700
    Re: who really use Forth ? lehs <skydda.barnen@gmail.com> - 2015-10-30 16:27 -0700
      Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-30 16:53 -0700
        Re: who really use Forth ? lehs <skydda.barnen@gmail.com> - 2015-10-31 09:16 -0700
          Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-31 12:49 -0700
    Re: who really use Forth ? Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 01:27 +0100
    Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2015-10-31 00:26 +0000
      Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2015-10-31 10:46 +0000
        Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2016-06-18 01:35 +0000
    Re: who really use Forth ? Pablo Hugo Reda <pabloreda@gmail.com> - 2015-10-30 18:34 -0700
      Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2015-10-31 10:57 +0000
        Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-31 13:13 -0700
          Re: who really use Forth ? rickman <gnuarm@gmail.com> - 2015-10-31 17:22 -0400
        Re: who really use Forth ? "Rod Pemberton" <too@zxcvfeqad.cdm> - 2015-11-02 02:32 -0500
          Re: who really use Forth ? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-02 09:04 +0100
    Re: who really use Forth ? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-30 18:35 -1000
    Re: who really use Forth ? rickman <gnuarm@gmail.com> - 2015-10-31 02:51 -0400
    Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-10-30 23:52 -0700
    Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-31 00:04 -0700
      Re: who really use Forth ? rickman <gnuarm@gmail.com> - 2015-10-31 03:16 -0400
      Re: who really use Forth ? Pablo Hugo Reda <pabloreda@gmail.com> - 2015-10-31 06:00 -0700
      Re: who really use Forth ? Richard Owlett <rowlett@cloud85.net> - 2015-10-31 08:35 -0500
        Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-31 13:08 -0700
        Re: who really use Forth ? Paul Rubin <no.email@nospam.invalid> - 2015-10-31 13:40 -0700
          Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-31 13:55 -0700
      Re: who really use Forth ? hughaguilar96@gmail.com - 2015-10-31 14:10 -0700
        Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2015-11-01 11:15 +0000
          Re: who really use Forth ? Alfred Singlestone <vitonis@gmail.com> - 2015-11-02 05:37 -0800
            Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-02 05:59 -0800
    Re: who really use Forth ? stephen@mpeforth.com (Stephen Pelc) - 2015-10-31 10:17 +0000
      Re: who really use Forth ? stephen@mpeforth.com (Stephen Pelc) - 2015-10-31 16:53 +0000
    Re: who really use Forth ? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-10-31 14:04 -0700
      Re: who really use Forth ? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-11-02 10:57 +0100
    Re: who really use Forth ? lehs <skydda.barnen@gmail.com> - 2015-10-31 21:23 -0700
    Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-11-02 06:05 -0800
      Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-02 07:43 -0800
      Re: who really use Forth ? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 08:02 -0800
    Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-02 08:53 -0800
      Re: who really use Forth ? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 09:05 -0800
        Re: who really use Forth ? hughaguilar96@gmail.com - 2015-11-02 09:48 -0800
        Re: who really use Forth ? "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 08:11 -1000
    Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-02 10:39 -0800
      Re: who really use Forth ? hughaguilar96@gmail.com - 2015-11-02 16:37 -0800
        Re: who really use Forth ? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 22:59 -0800
          Re: who really use Forth ? "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 21:16 -1000
            Re: who really use Forth ? stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 11:04 +0000
              Re: who really use Forth ? "Elizabeth D. Rather" <erather@forth.com> - 2015-11-03 08:17 -1000
                Re: who really use Forth ? hughaguilar96@gmail.com - 2015-11-03 18:20 -0800
                  Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-11-03 22:26 -0800
                  Re: who really use Forth ? lehs <skydda.barnen@gmail.com> - 2015-11-03 23:21 -0800
                Re: who really use Forth ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 09:33 +0000
            Re: who really use Forth ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 11:07 +0000
              Re: who really use Forth ? Mark Wills <markwills1970@gmail.com> - 2015-11-03 03:23 -0800
                Re: who really use Forth ? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:24 +0100
          Re: who really use Forth ? Mark Wills <markwills1970@gmail.com> - 2015-11-03 01:35 -0800
          Re: who really use Forth ? rickman <gnuarm@gmail.com> - 2015-11-03 11:18 -0500
          Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2015-11-04 00:07 +0000
          Re: who really use Forth ? Alfred Singlestone <vitonis@gmail.com> - 2015-11-03 17:01 -0800
    Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-03 10:59 -0800
      Re: who really use Forth ? "Elizabeth D. Rather" <erather@forth.com> - 2015-11-03 10:00 -1000
        Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-03 13:31 -0800

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

#43034

El sábado, 31 de octubre de 2015, 4:04:21 (UTC-3), François  escribió:
> tank's to all :-)
> 
> my problem, is when i download a Forth, there is no example to help
> beginner for is first step...
> 
> And the first step must be "fun" :-p
> 
> (with my forth) i create the word BMP>SPR
> You give to it : name of BMP file, X,Y,W,H of a part of this bmp,
> and the of the new sprite.
> 54 32 32 32 BMP>SPR SPRITE1 TEST.BMP
> create a 32x32 sprite
> 
> after that, in graphic mode, i just have to enter :
> 10 10 SPRITE1
> to display my sprite at X:10 Y:10
> 
> easy, powerful ... so Forth :+)
> 
> mmmh.... i wish to do the same with standard Forth....

don't worry about standard forth, keep with you implementation!!
but Roger Levy work with bitmap sprite in SwiftForth

https://code.google.com/p/tengoku-engine/

perhaps this help you.
You code is public? Show us!!

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

#43035

François wrote:
> tank's to all :-)
>
> my problem, is when i download a Forth, there is no example to help
> beginner for is first step...
>
> And the first step must be "fun" :-p
[*SNIP*]

I'll take your second point first.

Read books by Leo Brodie
   _Starting FORTH_  [http://www.forth.com/starting-forth/]
   _Thinking FORTH_  [unsure if there is a copyright compliant 
online edition]


As to your first point, examine free/trial editions of commercial 
Forths.
   http://www.forth.com/swiftforth/dl.html [I purchased 
SwiftForth years ago]
   http://www.mpeforth.com/arena.htm

If you are referring to one of the "free" [as in 'free beer' or 
'free speech'] Forth's, ask on this list for a specific Forth of 
interest.

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

#43053

> I'll take your second point first.
> 
> Read books by Leo Brodie
>    _Starting FORTH_  [http://www.forth.com/starting-forth/]
>    _Thinking FORTH_  [unsure if there is a copyright compliant 
> online edition]

hi,

I'm not beginner in "Forth". I write my own forth (based on the
"Turbo FORTH" of MP7 ), and i use it for my projects but, it's more
and more difficult to drive hardware (i must use BIOS real mode
functions to use USB sticks for example)

I'm beginner with modern OS (Linux or Windows)


> As to your first point, examine free/trial editions of commercial 
> Forths.
>    http://www.forth.com/swiftforth/dl.html [I purchased 
> SwiftForth years ago]
>    http://www.mpeforth.com/arena.htm
> 
> If you are referring to one of the "free" [as in 'free beer' or 
> 'free speech'] Forth's, ask on this list for a specific Forth of 
> interest.

I try SwiftForh since yesterday, very powerful!, but Forth is just an hobby...
(i can't afford)

 

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

#43057

Richard Owlett <rowlett@cloud85.net> writes:
> Read books by Leo Brodie
>   _Starting FORTH_  [http://www.forth.com/starting-forth/]
>   _Thinking FORTH_  [unsure if there is a copyright compliant online edition]

From http://thinking-forth.sourceforge.net/

    Author

    Leo Brodie wrote Thinking Forth in 1984. Since the book went out of
    print now the second time (due to FIG folding up - FIG did the reprint),
    he allowed to publish Thinking Forth as electronic book under a Creative
    Commons license (attribute, non-commercial, share-alike).

You can download it from there.  It's a great book ;-).

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

#43058

Le samedi 31 octobre 2015 21:40:52 UTC+1, Paul Rubin a écrit :
> Richard Owlett <rowlett@cloud85.net> writes:
> > Read books by Leo Brodie
> >   _Starting FORTH_  [http://www.forth.com/starting-forth/]
> >   _Thinking FORTH_  [unsure if there is a copyright compliant online edition]
> 
> From http://thinking-forth.sourceforge.net/
> 
>     Author
> 
>     Leo Brodie wrote Thinking Forth in 1984. Since the book went out of
>     print now the second time (due to FIG folding up - FIG did the reprint),
>     he allowed to publish Thinking Forth as electronic book under a Creative
>     Commons license (attribute, non-commercial, share-alike).
> 
> You can download it from there.  It's a great book ;-).

I've buy this book in 1992 ;-)

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

#43060

On Saturday, October 31, 2015 at 12:04:21 AM UTC-7, François wrote:
> tank's to all :-)
> 
> my problem, is when i download a Forth, there is no example to help
> beginner for is first step...
> 
> And the first step must be "fun" :-p
> 
> (with my forth) i create the word BMP>SPR
> You give to it : name of BMP file, X,Y,W,H of a part of this bmp,
> and the of the new sprite.
> 54 32 32 32 BMP>SPR SPRITE1 TEST.BMP
> create a 32x32 sprite
> 
> after that, in graphic mode, i just have to enter :
> 10 10 SPRITE1
> to display my sprite at X:10 Y:10
> 
> easy, powerful ... so Forth :+)
> 
> mmmh.... i wish to do the same with standard Forth....

Here is a quote from my file: http://www.forth.org/Stundurd.txt
---------------------------------------------------------------------------
A good way to avoid stack-juggling is to use structs, and only have the pointers to the structs on the data-stack. Our LINE.LENGTH function shown earlier was an example of this. Stundurd provides a heap (that is something else we can expect that Charles Moore won't provide ever), so the heap should be used. Whenever several data are used together and are only meaningful in relation to each other (like the X and Y coordinates of a point), then these data should be packed together into a struct and the struct held in the heap, and only the pointer to the struct passed around on the stack. This greatly reduces the amount of data on the stack, which increases both readability and efficiency.
---------------------------------------------------------------------------

So far on comp.lang.forth, nobody has ever said anything in support of this. Also, I routinely see people doing what you are doing, which is to put all the parameters on the stack. This is a dead end! Your code will become increasingly difficult to write and hard to read, due to all of the stack-juggling.

For example, your SPRITE1 would take one parameter, which is a pointer to a struct of data-type POINT that contains two fields, which are .X and .Y (note that the dot in front of a field name is my naming convention, which is derived from Pascal). Doing this wrong (having SPRITE1 take two parameters, which are the X and Y coordinates) is an easy trap to fall into because it seems simple and obvious at first, and there is little or no stack-juggling beyond what is required for one parameter. When you get more than one point however, such as the LINE.LENGTH function that I mentioned, then my method has two parameters (the two end points) and your method has four parameters (the X and Y for both end points) --- now you have more than three parameters on the stack, and three is generally considered to be the most that you want. Lets say that you have a function called LINE.INTERSECTION that returns the intersection point of two line segments --- it would have two parameters on the stack (pointers to two structs each of data-type LINE) --- this is as compared to 8 parameters which are the X and Y coordinates of all 4 end-points involved.

You don't really need somebody to write a graphics package for you, and especially not if they do it wrong. You can write this yourself. What you need is a way to define structs. Reading "Starting Forth" and "Thinking Forth" or any other book from Forth Inc. will not help you, because none of these books teach you how to define structs.

Download my novice package: http://www.forth.org/novice.html
Learn how to define structs with the FIELD definer. Also, learn how inheritance works (study the LIST.4TH file for this). Then write your own graphics code-library on top of the novice package. If you do this and it is good code, I will include it in the next novice package release. So far, nobody has ever written any code-library on top of the novice package --- you would be the first --- that was the original intention though, that the novice package would be the basis of a variety of code-libraries.

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

#43070

hughaguilar wrote:

> Here is a quote from my file: http://www.forth.org/Stundurd.txt
> ---------------------------------------------------------------------------
> 
> A good way to avoid stack-juggling is to use structs, and only
> have the pointers to the structs on the data-stack. Our
> LINE.LENGTH function shown earlier was an example of this.
> Stundurd provides a heap (that is something else we can expect
> that Charles Moore won't provide ever), so the heap should be
> used. Whenever several data are used together and are only
> meaningful in relation to each other (like the X and Y
> coordinates of a point), then these data should be packed
> together into a struct and the struct held in the heap, and
> only the pointer to the struct passed around on the stack.
> This greatly reduces the amount of data on the stack, which
> increases both readability and efficiency.
> 
> ---------------------------------------------------------------------------
> 
> So far on comp.lang.forth, nobody has ever said anything in
> support of this. Also, I routinely see people doing what you
> are doing, which is to put all the parameters on the stack.
> This is a dead end! Your code will become increasingly
> difficult to write and hard to read, due to all of the
> stack-juggling.
> 
> For example, your SPRITE1 would take one parameter, which is a
> pointer to a struct of data-type POINT that contains two
> fields, which are .X and .Y (note that the dot in front of a
> field name is my naming convention, which is derived from
> Pascal). Doing this wrong (having SPRITE1 take two parameters,
> which are the X and Y coordinates) is an easy trap to fall
> into because it seems simple and obvious at first, and there
> is little or no stack-juggling beyond what is required for one
> parameter. When you get more than one point however, such as
> the LINE.LENGTH function that I mentioned, then my method has
> two parameters (the two end points) and your method has four
> parameters (the X and Y for both end points) --- now you have
> more than three parameters on the stack, and three is
> generally considered to be the most that you want. Lets say
> that you have a function called LINE.INTERSECTION that returns
> the intersection point of two line segments --- it would have
> two parameters on the stack (pointers to two structs each of
> data-type LINE) --- this is as compared to 8 parameters which
> are the X and Y coordinates of all 4 end-points involved.
> 
> You don't really need somebody to write a graphics package for
> you, and especially not if they do it wrong. You can write
> this yourself. What you need is a way to define structs.
> Reading "Starting Forth" and "Thinking Forth" or any other
> book from Forth Inc. will not help you, because none of these
> books teach you how to define structs.
> 
> Download my novice package: http://www.forth.org/novice.html
> 
> Learn how to define structs with the FIELD definer. Also,
> learn how inheritance works (study the LIST.4TH file for
> this). Then write your own graphics code-library on top of the
> novice package. If you do this and it is good code, I will
> include it in the next novice package release. So far, nobody
> has ever written any code-library on top of the novice package
> --- you would be the first --- that was the original intention
> though, that the novice package would be the basis of a
> variety of code-libraries.

Hugh is on the right track.

Forth has been crippled by the mystical belief of its
fanboys that keeping Forth very low-level and primitive
is The One True Way.

Forth needs structures, arrays, lists, many more
string-handling words, strings that are longer than 255
characters, better looping constructs, iterators and mappers
over arrays and lists, lambdas (quotations), etc.

And its fanboys need to stop being afraid that Mommy will
spank if they use local variables.


Remember the thread about adding two vectors?
Here's how easy it is in Oforth:

  >[1,2,3,4] [500,600,700,800] zipWith(#+) .
  [501, 602, 703, 804] ok

-- 
The report card by the American Society of Civil Engineers showed the national
infrastructure a single grade above failure, a step from declining to the point
where everyday things simply stop working the way people expect them to. ---
washingtonpost.com/local/trafficandcommuting/us-infrastructure-gets-d-in-annual-report/2013/03/19/c48cb010-900b-11e2-9cfd-36d6c9b5d7ad_story.html

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

#43105

On Sunday, November 1, 2015 at 6:17:58 AM UTC-5, WJ wrote:
> Forth has been crippled by the mystical belief of its
> fanboys that keeping Forth very low-level and primitive
> is The One True Way.
> 
> Forth needs structures, arrays, lists, many more
> string-handling words, strings that are longer than 255
> characters, better looping constructs, iterators and mappers
> over arrays and lists, lambdas (quotations), etc.
> 
> And its fanboys need to stop being afraid that Mommy will
> spank if they use local variables.

My Mommy doesn't even know Forth!

I think it's an interesting challenge to start with atoms and build useful molecules that combine into compounds that are ultimately shaped into useful tools. But then, I'm a fan, not a fanboy; I write Forth as a hobby; and I have zero influence over the direction of the language.

I don't feel mystical.

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

#43108

On Monday, November 2, 2015 at 8:37:10 AM UTC-5, Alfred Singlestone wrote:
> I think it's an interesting challenge to start with atoms and build useful molecules that combine into compounds that are ultimately shaped into useful tools. But then, I'm a fan, not a fanboy; I write Forth as a hobby; and I have zero influence over the direction of the language.

I couldn't have said it better myself!

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

#43030

On Fri, 30 Oct 2015 16:12:57 -0700 (PDT), =?ISO-8859-1?Q?Fran=E7ois?=
<francois.ganza@wanadoo.fr> wrote:

>Ok, but who really use Forth to make real programs ?

See the Candy construction planning application at
   http://constructioncomputersoftware.com/

See also
   http://www.mpeforth.com/ngr.htm

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#43044

On Sat, 31 Oct 2015 10:17:43 GMT, stephen@mpeforth.com (Stephen Pelc)
wrote:
>See the Candy construction planning application at
>   http://constructioncomputersoftware.com/
>
>See also
>   http://www.mpeforth.com/ngr.htm

It was remiss of me to forget Micross Automation.

http://www.micross.co.uk/micross-tracknet-laundry-control.shtml

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#43059

Quark-Forth - 32-bit Windows exe+dll versions of Forth with OpenGL (2D and 3D)

http://msyst.ru/downloads/quarkexe.zip

I don't want to invite you as a follower :) Indeed I just want to say it is normal to write a Forth for particular purpose.

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

#43093

On 31/10/15 22:04, Ilya Tarasov wrote:
>
> Quark-Forth - 32-bit Windows exe+dll versions of Forth with OpenGL (2D and 3D)
>
> http://msyst.ru/downloads/quarkexe.zip
>
> I don't want to invite you as a follower :) Indeed I just want to say it is normal to write a Forth for particular purpose.
>

Yes, or write extensions to existing Forth systems (Mac and Atari) for 
particular purpose. "In house" only usage wrt realtime sound and image 
processing and event scheduling. Using whatever technologies presented 
on the platform.

http://www.bmbcon.org

Some parts of the extensions are available for SwiftForth, VFX and 
iForth on the Mac.

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

#43068

Den lördag 31 oktober 2015 kl. 00:12:58 UTC+1 skrev François:
> Good evening,
> 
> When you search informations and examples about Forth,
> ...always the same :
> : square dup * ;
> 
> amazing, it's really easy to create news words, you can also
> create words to create words...
> Ok, but who really use Forth to make real programs ?
> 
> Is it possible to create applications for windows or Linux ?
> Is is possible to use openGL ?
> 
> Actually i use "my" Forth on PC in automation systems.
> (my Forth is my OS and it can read/write FAT32)
> 
> But sometimes i would like to create programs on standard Forth...
> 
> 
> regards
> François

There are nice free Forths for several operative systems, as:
SP-Forth, that has an optional optimizer compiling machine code
GForth, that is very well documented GNU Forth that even works on androids
Win32Forth

____________________
Lehs
http://forthmath.blogspot.se
https://github.com/Lehs/BIG-INTEGER-ANS-FORTH

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

#43109

Hi Hughaguilar

I'm sorry, but i don't understand how your structure can help me to
make more easy or readable Forth programs :-/

I think the beauty of Forth is programming flexibility.

My philosophy of Forth is like RISC processors : minimum of words
And if I need a particular structure in a particular program, it's
easy to create it.

When there is too much data in the stack i use variables or something like
(my forth don't have words TUCK, ROT and ROLL )

I don't care about portability, anyway, when you write parts of code
in assembler, where is the portability ?

I would write my graphical functions, but i don't know how to call system routines...

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

#43120

On Monday, November 2, 2015 at 9:05:28 AM UTC-5, François wrote:
> Hi Hughaguilar
> 
> I'm sorry, but i don't understand how your structure can help me to
> make more easy or readable Forth programs :-/
> 
> I think the beauty of Forth is programming flexibility.
> 
> My philosophy of Forth is like RISC processors : minimum of words
> And if I need a particular structure in a particular program, it's
> easy to create it.
> 
> When there is too much data in the stack i use variables or something like
> (my forth don't have words TUCK, ROT and ROLL )
> 
> I don't care about portability, anyway, when you write parts of code
> in assembler, where is the portability ?
> 
> I would write my graphical functions, but i don't know how to call system routines...
To me, a "structure" in Forth, is really just a set of words that can make
sense out of the contents of a block of memory. Trying to formalize and 
generalize a way to define and work with "structures" in Forth seems adding 
like an extra layer of complexity that places an unwanted constraint on the 
programmer using it.

But that is the beauty of Forth. It gives us the ability to express our 
solutions in any form that we find intuitive. Those programmers who prefer 
to think in terms of STRUCTs are free build a syntax for it into their 
system however they want. Others may see the world differently, and are also
free to build their own syntax that suits them.

For me, generalized structures is an unwanted language constraint that imposes an unwanted constraint on how I can express myself, not unlike the 
way C forces us to think. That is exactly the kind of constraint I have 
lived under for too long, and I want to break free from such constraints.

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

#43123

luni, 2 noiembrie 2015, 16:05:28 UTC+2, François a scris:
> Hi Hughaguilar
> 
> I'm sorry, but i don't understand how your structure can help me to
> make more easy or readable Forth programs :-/
> 
> I think the beauty of Forth is programming flexibility.
> 
> My philosophy of Forth is like RISC processors : minimum of words
> And if I need a particular structure in a particular program, it's
> easy to create it.
> 
> When there is too much data in the stack i use variables or something like
> (my forth don't have words TUCK, ROT and ROLL )
> 

Hi Fracois,
Here it is a complete file content, a tcp/ip stack written in forth
from scratch. It doesn't have the TCP implemented though (yet), but the
ARP, IP, ICMP, UDP are working, I have a tftp server based on it. Sorry for
such a long file. You may see how to use structs to write readable and
maintainable forth programs. All you need is FIELD word, and make good use of it... Enjoy!

\ ============================================================================
\ TCP/IP Stack                                      raimond.dragomir@gmail.com
\ ============================================================================
include encx24spi.qf      \ ENC424J600 spi driver
include tcpip_conf.qf     \ tcp/ip stack configuration

\ ----------------------------------------------------------------------------
\ IP Statistics counters
0 W field ipstat.myarp    \ my arp requests
  W field ipstat.myicmp   \ my icmp messages
  W field ipstat.myudp    \ my udp messages
  W field ipstat.mytcp    \ my tcp messages
  W field ipstat.arp      \ all arp messages
  W field ipstat.icmp     \ all icmp messages
  W field ipstat.udp      \ all udp messages
  W field ipstat.tcp      \ all tcp messages
  W field ipstat.iperr    \ ip errors
  W field ipstat.icmperr  \ icmp errors
  W field ipstat.udperr   \ udp errors
  W field ipstat.tcperr   \ tcp errors
constant IpStat
IpStat var ipstat
\ increment counters
: ipstat.myarp++    1 ipstat ipstat.myarp   +! ;
: ipstat.myicmp++   1 ipstat ipstat.myicmp  +! ;
: ipstat.myudp++    1 ipstat ipstat.myudp   +! ;
: ipstat.mytcp++    1 ipstat ipstat.mytcp   +! ;
: ipstat.arp++      1 ipstat ipstat.arp     +! ;
: ipstat.icmp++     1 ipstat ipstat.icmp    +! ;
: ipstat.udp++      1 ipstat ipstat.udp     +! ;
: ipstat.tcp++      1 ipstat ipstat.tcp     +! ;
: ipstat.iperr++    1 ipstat ipstat.iperr   +! ;
: ipstat.icmperr++  1 ipstat ipstat.icmperr +! ;
: ipstat.udperr++   1 ipstat ipstat.udperr  +! ;
: ipstat.tcperr++   1 ipstat ipstat.tcperr  +! ;

\ ----------------------------------------------------------------------------
ETH_PACKET_SIZE
     var EthPacket      \ the received thernet packet
   6 var MyMacAddr      \ my ethernet MAC address - read from eth. chip
variable EthPacketLen   \ the received ethernet packet length
variable AppDataPtr     \ application data pointer
variable AppDataLen     \ application data length (in bytes)

variable MyIpAddr       \ 192.168.1.100 for example
variable MyIpMask       \ 255.255.255.0 for example
variable MyIpGate       \ 192.168.1.1 for example (default gateway)

\ ----------------------------------------------------------------------------
\ Ethernet packet structure
0 6 field eth.dstmac  \ destination mac address
  6 field eth.srcmac  \ source mac address
  2 field eth.type    \ ethernet type / length
constant EthHeader

0x0008 constant ETHTYPE_IPv4    \ 0x0800 - ipv4 protocol
0x0608 constant ETHTYPE_ARP     \ 0x0806 - arp protocol

\ ARP packet structure (including the ethernet header)
EthHeader
  2 field arp.htype   \ hardware type (0x0001 for ethernet)
  2 field arp.ptype   \ protocol type (0x0800 for IPv4)
  1 field arp.hlen    \ hardware length (MAC address length) should be 6
  1 field arp.plen    \ protocol length (IP address length) should be 4
  2 field arp.op      \ operation: 0x0001=request, 0x0002=reply
  6 field arp.sha     \ sender hardware (mac) address
  4 field arp.spa     \ sender protocol (ip) address
  6 field arp.tha     \ target hardware (mac) address
  4 field arp.tpa     \ target protocol (ip) address
drop

: BroadcastMAC? \ adr -- flag
  dup cell+ h@ >r @ 0xffffffff = r> 0xffff = and ;

: MyMAC? \ adr -- flag
  dup cell+ h@ >r @ MyMacAddr @ = r> MyMacAddr cell+ h@ = and ;

: IsMyMAC? \ -- flag
  EthPacket eth.dstmac dup BroadcastMAC? swap MyMAC? or ;

\ swap mac addresses in the ethernet packet
: SwapMACs \ --
  EthPacket eth.srcmac EthPacket eth.dstmac 6 cmove
  MyMacAddr EthPacket eth.srcmac 6 cmove ;

\ IP packet structure (including the ethernet header)
EthHeader
  1 field ip.vihl     \ version and IHL
  1 field ip.tos      \ old "type of service" new DSCP + ECN. Ignored anyway.
  2 field ip.length   \ ip total length in bytes, including the ip header
  2 field ip.id       \ packet id, for (de)fragmentation
  2 field ip.offset   \ packet offset + flags for (de)fragmentation
  1 field ip.ttl      \ time to live
  1 field ip.protocol \ higher protocol code used in the ip data payload
  2 field ip.chksum   \ 16bit checksum of the ip header
  4 field ip.saddr    \ source address
  4 field ip.daddr    \ destination address
drop

\ ip.protocol
0x01 constant IP_PROTOCOL_ICMP  \ Internet Control Message Protocol
0x06 constant IP_PROTOCOL_TCP   \ Transmission Control Protocol
0x11 constant IP_PROTOCOL_UDP   \ User Datagram Protocol

\ user ip structure
0 1 field ipinfo.protocol       \ IP protocol
  2 field ipinfo.length         \ IP payload length
  4 field ipinfo.saddr          \ source address
  4 field ipinfo.daddr          \ destination address
constant IpInfo
IpInfo var ipinfo

: htons@ \ adr -- h , in network order (big endian)
  c@+ 8 lshift swap c@ + ;

: htons! \ h adr -- , in network order (big endian)
  over 8 rshift \ lo adr hi
  over c! 1+ c! ;

\ Given the adr len buffer, calculate the ip checksum
: ipchksum { | sum } \ adr len -- chksum , len in bytes
  2/ for dup htons@ sum +!  2 + next
  sum @ dup 0xffff and >r 16 rshift r> +
  0xffff xor ;

\ IP address filter
: IsMyIp? \ -- flag
  EthPacket ip.daddr @ MyIpAddr @ = ;

\ IP address and MAC address filter
: IsMe? \ -- flag
  IsMyMAC? IsMyIp? and ;

\ swap ip addresses in the ethernet packet
: SwapIPs \ --
  EthPacket ip.saddr @ EthPacket ip.daddr !
  MyIpAddr @ EthPacket ip.saddr ! ;

\ send the same ethernet packet received (it was modified in place).
: ResponseSamePacket \ --
  EthPacket EthPacketLen @ enc_packet_send ;

\ ----------------------------------------------------------------------------
\ ICMP
\ ----------------------------------------------------------------------------
\ ICMP packet structure
0 1 field icmp.type       \ icmp type field 8=echo request, 0=echo resp.
  1 field icmp.code       \ icmp code = 0
  2 field icmp.chksum     \ 16bit checksum of the icmp message
  2 field icmp.id         \ icmp identifier
  2 field icmp.seq        \ icmp sequence number
drop

: reply_echo_request \ --
  0 AppDataPtr @ icmp.type c! \ reply type is 0
  0 AppDataPtr @ icmp.chksum h! \ clear chksum field for calculation
  AppDataPtr @ AppDataLen @ ipchksum
  AppDataPtr @ icmp.chksum htons!
  SwapMACs SwapIPs \ and ip header chksum must be the same
  ResponseSamePacket ;

: check_icmp_packet \ --
  ipstat.icmp++
  IsMe? 0= if exit then
  AppDataPtr @ AppDataLen @ ipchksum 0= if
    ipstat.myicmp++
    AppDataPtr @ icmp.type h@ 0x0008 = if \ echo (ping) type=8, code=0
      reply_echo_request                  \ reply to ping
    then
  then ;

\ ----------------------------------------------------------------------------
\ UDP
\ ----------------------------------------------------------------------------
\ UDP packet structure
0 2 field udp.sport       \ udp src port
  2 field udp.dport       \ udp dst port
  2 field udp.length      \ udp msg total length (8 + udp data len)
  2 field udp.chksum      \ 16bit checksum of the icmp message
drop
variable AppUdpPtr        \ pointer to the udp message
: udp.sport@  AppUdpPtr @ udp.sport htons@ ; \ -- srcport
: udp.dport@  AppUdpPtr @ udp.dport htons@ ; \ -- dstport

\ The following global variables contain valid data for the received udp:
\  AppDataPtr : start of the udp data payload
\  AppDataLen : the length of the udp data
\  udp.sport@ : udp src port
\  udp.dport@ : udp dst port

variable app_udp_callback

: check_udp_packet \ --
  ipstat.udp++
  IsMe? 0= if exit then
  AppDataPtr @ dup AppUdpPtr ! 8 + AppDataPtr !
  AppUdpPtr @ udp.length htons@ 8 - AppDataLen !
TCPIP_DEBUG_UDP&&&
  ." udp:" cr
  ."   len="    AppUdpPtr @ udp.length htons@ .
  ."   sport="  udp.sport@ .
  ."   dport="  udp.dport@ .
  ."   applen=" AppDataLen @ . cr
  ."   appdata:" cr
  AppDataPtr @ AppDataLen @ dump
\ &
  app_udp_callback @ execute
  ipstat.myudp++ ;

\ ----------------------------------------------------------------------------
\ TCP
\ ----------------------------------------------------------------------------
: check_tcp_packet \ --
  ipstat.tcp++
  IsMe? 0= if exit then
TCPIP_DEBUG_TCP&&&
  ." tcp:" cr
  ."   appdata:" cr
  AppDataPtr @ AppDataLen @ dump
\ &
  ipstat.mytcp++ ;

\ ----------------------------------------------------------------------------
\ IP
\ ----------------------------------------------------------------------------
\ The following check_ip.xxx functions will check some ip header fields for
\ supported features, and at the same time will update the "ipinfo" fields
\ with more friendly values for the host processing. For example, the
\ ipinfo.length field will be updated with the payload length, etc.
\ The flags returned have negative logic meaning, 0 being the ok, 1 error.

\ Check the offset+flags. We don't support (de)fragmentation so the only
\ allowed values for this combined field are 0x0000 and 0x4000
: check_ip.offset \ -- err
  EthPacket ip.offset h@
  dup 0= if drop 0 exit then
  0x0040 = if 0 else 1 then ;

: check_ip.chksum \ -- err
  EthPacket ip.vihl 20 ipchksum 0<> ;

\ Check ip.vihl field for correct ip version (4) and correct length (5)
: check_ip.vihl \ -- err
  EthPacket ip.vihl c@ 0x45 <> ;

\ Check the IP protcol field for supported protocols.
: check_ip.protocol \ -- err
  0 \ ok?
  EthPacket ip.protocol c@ dup ipinfo ipinfo.protocol c!
  dup IP_PROTOCOL_ICMP = if drop exit then \ ICMP supported
  dup IP_PROTOCOL_TCP  = if drop exit then \ TCP supported
  dup IP_PROTOCOL_UDP  = if drop exit then \ ICMP supported
  drop 1+ ; \ error

\ Check the IP total length against ethernet packet length
: check_ip.length \ -- err
  1 \ error?
  EthPacket ip.length htons@
  dup 14 + EthPacketLen @ <> if drop exit then
  20 - \ payload length
  ipinfo ipinfo.length h! 1- ; \ ok

: check_ip.saddr    EthPacket ip.saddr @ ipinfo ipinfo.saddr ! ;
: check_ip.daddr    EthPacket ip.daddr @ ipinfo ipinfo.daddr ! ;

\ Check the IP packet
: check_ip_packet \ --
  check_ip.vihl     if ipstat.iperr++ exit then
  check_ip.chksum   if ipstat.iperr++ exit then
  check_ip.offset   if ipstat.iperr++ exit then
  check_ip.protocol if ipstat.iperr++ exit then
  check_ip.length   if ipstat.iperr++ exit then
  check_ip.saddr
  check_ip.daddr
TCPIP_DEBUG_IP&&&
  base @
  ." IPv4 packet:" cr
  decimal
  ."   protcol  = " ipinfo ipinfo.protocol c@ . cr
  ."   length   = " ipinfo ipinfo.length h@ . cr
  hex
  ."   src addr = " ipinfo ipinfo.saddr @ 8 u.r cr
  ."   dst addr = " ipinfo ipinfo.daddr @ 8 u.r cr
  base !
\ &
  EthPacket 14 + 20 +      AppDataPtr ! \ start of the app data
  ipinfo ipinfo.length h@  AppDataLen ! \ length of the app data
  ipinfo ipinfo.protocol c@
  dup IP_PROTOCOL_ICMP = if
    check_icmp_packet
  else
    dup IP_PROTOCOL_UDP = if
      check_udp_packet
    else
      check_tcp_packet
    then
  then drop ;

\ ----------------------------------------------------------------------------
\ ARP
\ ----------------------------------------------------------------------------
: reply_arp_request \ --
  MyMacAddr EthPacket arp.tha 6 cmove
  SwapMACs
  MyMacAddr EthPacket arp.sha 6 cmove
  EthPacket arp.spa @ EthPacket arp.tpa !
  MyIpAddr @ EthPacket arp.spa !
  0x02 EthPacket arp.op 1+ c! \ reply op
  ResponseSamePacket ;

: check_arp_packet \ --
  EthPacket arp.htype @ 0x00080100 = if \ htype, ptype ok
    EthPacket arp.hlen @ 0x01000406 = if \ hlen, plen, op=request ok
      IsMyMAC? if
        EthPacket arp.tpa @ MyIpAddr @ = if
          ipstat.myarp++
          reply_arp_request
        then
      then
    then
  then
  ipstat.arp++ ; \ total arp's

\ ----------------------------------------------------------------------------
: tcpip_loop \ --
  EthPacket ETH_PACKET_SIZE enc_packet_receive
  dup EthPacketLen ! if
TCPIP_DEBUG_IP&&&
    EthPacket EthPacketLen @ dump
\ &
    EthPacket eth.type h@
    dup ETHTYPE_IPv4 = if
      drop check_ip_packet
    else ETHTYPE_ARP = if
      check_arp_packet
    then then
  then ;

\ Print the ip statistics
TCPIP_PRINTSTATISTICS&&&
TARG
: ip \ -- , print ip statistics
  ." IP statistics:" cr
  ."   my arp     " ipstat ipstat.myarp @ 8 u.r  ." total arp  " ipstat ipstat.arp @ . cr
  ."   my icmp    " ipstat ipstat.myicmp @ 8 u.r ." total icmp " ipstat ipstat.icmp @ . cr
  ."   my udp     " ipstat ipstat.myudp @ 8 u.r  ." total udp  " ipstat ipstat.udp @ . cr
  ."   my tcp     " ipstat ipstat.mytcp @ 8 u.r  ." total tcp  " ipstat ipstat.tcp @ . cr
  ."   ip errors   " ipstat ipstat.iperr @ . cr
  ."   icmp errors " ipstat ipstat.icmperr @ . cr
  ."   udp errors  " ipstat ipstat.udperr @ . cr
  ."   tcp errors  " ipstat ipstat.tcperr @ . cr ;
\ &
TARG

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

#43127

It looks like FIELD is a defining word ... in that it creates another word 
that adds an offset to the address on the TOS. 

What you end up with is a set of words that refer to different spots in the 
buffer. So that approach is one way to build a set of words that makes sense 
of the contents of the buffer.

There are other ways to end up with the exact same set of words that don't use 
a defining word like FIELD. But a word like FIELD is elegant, because it takes 
some of the grunt work out of creating the wordset by hand.

Nice work!

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

#43128

luni, 2 noiembrie 2015, 18:53:10 UTC+2, Chris Curl a scris:
> It looks like FIELD is a defining word ... in that it creates another word 
> that adds an offset to the address on the TOS. 
> 
> What you end up with is a set of words that refer to different spots in the 
> buffer. So that approach is one way to build a set of words that makes sense 
> of the contents of the buffer.
> 
> There are other ways to end up with the exact same set of words that don't use 
> a defining word like FIELD. But a word like FIELD is elegant, because it takes 
> some of the grunt work out of creating the wordset by hand.
> 
> Nice work!

Yes, FIELD is exactly that. Very simple. Hugh's having it in the novice
package. But it is not my invention, not even Hugh's. It is older. IMO it's
a shame it is not in the 94 standard. The standard has PAD instead...

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

#43131

On Monday, November 2, 2015 at 10:05:42 AM UTC-7, Raimond Dragomir wrote:
> luni, 2 noiembrie 2015, 18:53:10 UTC+2, Chris Curl a scris:
> > It looks like FIELD is a defining word ... in that it creates another word 
> > that adds an offset to the address on the TOS. 
> > 
> > What you end up with is a set of words that refer to different spots in the 
> > buffer. So that approach is one way to build a set of words that makes sense 
> > of the contents of the buffer.
> > 
> > There are other ways to end up with the exact same set of words that don't use 
> > a defining word like FIELD. But a word like FIELD is elegant, because it takes 
> > some of the grunt work out of creating the wordset by hand.
> > 
> > Nice work!
> 
> Yes, FIELD is exactly that. Very simple. Hugh's having it in the novice
> package. But it is not my invention, not even Hugh's. It is older. IMO it's
> a shame it is not in the 94 standard. The standard has PAD instead...

I certainly didn't invent FIELD --- that has been common practice for as long as I can remember, and I started programming Forth in 1984 --- my only contribution was to speed it up somewhat from the basic CREATE DOES> implementation, but I'm not the only one to do that (Stephen Pelc also did so, but with a different implementation).

Getting back to Chris and his question about how structs can improve code, it is all about information-hiding. In a graphics package, you may be working with line-segments for example. A good way to represent these is with two end-points. They can be represented in other ways though, such as a start point and angle and a length. How they are represented can be hidden from the user though. The user just works with a single value which is a pointer to a struct of data-type LINE and he doesn't have to worry about how the line segment is represented internally (note that I'm using the word LINE to mean line-segment as a shorthand). Even if the user does know how a line-segment is represented internally, he doesn't have all this information cluttering his code all the time, as his code just works with the higher-level abstractions such as LINE and ARC etc..

Information-hiding is really one of the best ideas in computer programming! This is what distinguishes modern programs from 1970s programs --- in the bad old days, nothing was hidden --- this is why 1970s programs tended to be small, as the complexity level grew so quickly that a program that could easily be written today would have been a gigantic mess using the old techniques so even the smartest programmer would be overwhelmed and unable to get it debugged.

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

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

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

csiph-web