amforth-devel — Development discussion and user support

Re: [Amforth-devel] u*/mod should multiply unsigned?

[Ulrich H. <uh...@xl...>]

As far as I know, there is no statement in the standard
about the location of (standard or non-standard) definitions whatsoever.

A file with math utility words seems appropriate.

Regards,
		Ulli


Am 21.07.2008 um 18:54 schrieb Kalus Michael:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Matthias.
>
>
> Am 19.07.2008 um 11:34 schrieb Matthias Trute:
>
>>> I vote for dropping it or move it into, hm, maybe lib/misc.frt ?
>>
>> how about a lib/math.frt? I put a sqrt word into it as well.
>
> Ok, why not? Where does the ANS forth standard put non-standard words?
> Maybe we ask Ulrich as well?
>
> Michael
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFIhL80J3DLQCvSXtcRAh4FAJ45DeOlTLsjzhnrTek5khYwzrIdrwCguvRf
> RVxB8HlxbcyLizAvNf4Cink=
> =kaUw
> -----END PGP SIGNATURE-----

Re: [Amforth-devel] u*/mod should multiply unsigned?

[Kalus M. <mic...@on...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Matthias.


Am 19.07.2008 um 11:34 schrieb Matthias Trute:

>> I vote for dropping it or move it into, hm, maybe lib/misc.frt ?
>
> how about a lib/math.frt? I put a sqrt word into it as well.

Ok, why not? Where does the ANS forth standard put non-standard words?
Maybe we ask Ulrich as well?

Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIhL80J3DLQCvSXtcRAh4FAJ45DeOlTLsjzhnrTek5khYwzrIdrwCguvRf
RVxB8HlxbcyLizAvNf4Cink=
=kaUw
-----END PGP SIGNATURE-----

Re: [Amforth-devel] u*/mod should multiply unsigned?

[Matthias T. <mt...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kalus Michael wrote:

 > I vote for dropping it or move it into, hm, maybe lib/misc.frt ?

how about a lib/math.frt? I put a sqrt word into it as well.

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIgbUm9bEHdGEMFjMRAuLjAJ9+rSvqepJptEr97xkuo3OyAUgKWwCg17JB
pu1u5otoLFkT/VQsXKzw+tA=
=o8V9
-----END PGP SIGNATURE-----

Re: [Amforth-devel] u*/mod should multiply unsigned?

[Kalus M. <mic...@on...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.


Am 17.07.2008 um 16:44 schrieb Matthias Trute:
>> In dpans forth there is no "u*/mod"  at all;  even gforth has no such
>> word.
>>
>> I wonder how it sneeked into amforth?
>
> Good question, and I do not find the test case anymore in my
> unchanged core.frt file...

Must have been something where an unsigned double precision  
intermediate calculation has been nessesary (= mixed precision  
arithmetic)

Mixed precision means you take 2 unsigned single precision integers,  
multiply into double precision so you dont loose the overflow if it  
happens to have one, then calculate division and remainder using this  
double precision intermediate result.

If you do it with * and /mod you get wrong results when overflow of  
the product ocures. (Thats why there is no u* or u/mod to get mixed  
up with.)

So, instead of creating an extra *core* word named  u*/mod  I think  
its more clean programming to use um* and um/mod inline instead.

um*    ( u1 u2 – ud)    \ core “u-m-star”
um/mod ( ud u3 – u4 u5) \ core “u-m-slash-mod”

The inlined phrase

  ( u1 u2 u3 – u4 u5 )  >r um* r> um/mod

should work as well and you can see what happens and test it.

Further more as u*/mod is not standard (as far as I can see) you  
loose portability of code. And as it is not coded in assembler but in  
high level, I can not see any speed benefit. As it comes along whit  
another level of nesting, it slows down calculaton a littel bit instead.


> Sorry about the confusion, I'll change the code as suggested

I vote for dropping it or move it into, hm, maybe lib/misc.frt ?

(Yes, I like amforth to be as lean as possible to meet standards. Is  
it getting too fat and needs review? ;-)


Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIf5CWJ3DLQCvSXtcRAszuAJ9b9EXOII8L89KDdjXkXIYF/KCDUQCeN0mI
hn2c7eRpFsIFRkMand3oSvI=
=ZiD/
-----END PGP SIGNATURE-----

Re: [Amforth-devel] u*/mod should multiply unsigned?

[Matthias T. <mt...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

Kalus Michael wrote:

> In dpans forth there is no "u*/mod"  at all;  even gforth has no such  
> word.
> 
> I wonder how it sneeked into amforth?

Good question, and I do not find the test case anymore in my
unchanged core.frt file....

Sorry about the confusion, I'll change the code as suggested

Thanks+cu
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIf1qy9bEHdGEMFjMRAh3rAKDa0XXRcs/w1blK9/fYnzpfeJCEKgCffVQQ
ByFU3SKVslEKj7WGCVyRhY4=
=ZrST
-----END PGP SIGNATURE-----

Re: [Amforth-devel] words: tuck/under etc

[Matthias T. <mt...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Bernard Mentink wrote:

> I don't know if the limitation is in the pearl script  for sending to the
> device, or in the actual interpreter .... must have a good look at both.

Much simpler: It is configurable paramter at build-time. Just edit your
application master file and change the value of TIBSIZE to something
different (bigger).

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIf1pM9bEHdGEMFjMRAhKpAJ4hOBJ4oRO4Cy0M55nCJ3exuXhxywCgjVCb
1BGg6rvqEjjew+blUieo3HM=
=rdaJ
-----END PGP SIGNATURE-----

Re: [Amforth-devel] words: tuck/under etc

[Bernard M. <bme...@gm...>]

Hi Michael,

Yes, thanks for the explaination on how the "]" word was working in this
code, it all makes sense now .... I have to get my head around what is
happening at compile time and run time with the create/does> words ....

By the way everyone, on writing this code and laying out some large FSM
tables to use in anger ... I have come across what I think is a bug. When
the lines get longer than 80 characters the interpreter does not accept
input and misses some of my table .... with modern editors having a much
wider column width this is a severe limitation in writing descriptive FSM's
as I like to have the "action" word and the "state" word fairly discriptive
..., with the width only 80 wide I am limited to names only 3/4 characters
or so with 5 inputs wide for example ..

I don't know if the limitation is in the pearl script  for sending to the
device, or in the actual interpreter .... must have a good look at both.

Cheers,
Bernard


On Thu, Jul 17, 2008 at 10:15 AM, Kalus Michael <mic...@on...>
wrote:

> Hi Bernard.
>
>
> Am 16.07.2008 um 23:32 schrieb Bernard Mentink:
>
> > I implemented the "Elegant FSM" version of Julien's code Section
> > 3.3 i.e:
> >
> > The FSM is then defined as
> >
> > 4 WIDE FSM:
> > \ input:  |  other?  |  num?   |  minus?  |   dp?     |
> > \ state:  ---------------------------------------------
> >    ( 0 )     DROP >0    EMIT >1   EMIT >1     EMIT >2
> >    ( 1 )     DROP >1    EMIT >1   DROP >1     EMIT >2
> >    ( 2 )     DROP >2    EMIT >2   DROP >2     DROP >2 ;
> >
> >
> > That seems to me the most readable and flexible of all his examples.
> > I have given Mathias the code for including in the Lib.
>
> Well, so you finaly got used to the ]-trick of FSM:
>
> I agree, this way to set up the array realy looks good.
>
> Something like   ' drop , ' >0 ,  ..   is uglier.
>
> :-)
> Michael
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] words: tuck/under etc

[Kalus M. <mic...@on...>]

Hi Bernard.


Am 16.07.2008 um 23:32 schrieb Bernard Mentink:

> I implemented the "Elegant FSM" version of Julien's code Section  
> 3.3 i.e:
>
> The FSM is then defined as
>
> 4 WIDE FSM:
> \ input:  |  other?  |  num?   |  minus?  |   dp?     |
> \ state:  ---------------------------------------------
>    ( 0 )     DROP >0    EMIT >1   EMIT >1     EMIT >2
>    ( 1 )     DROP >1    EMIT >1   DROP >1     EMIT >2
>    ( 2 )     DROP >2    EMIT >2   DROP >2     DROP >2 ;
>
>
> That seems to me the most readable and flexible of all his examples.
> I have given Mathias the code for including in the Lib.

Well, so you finaly got used to the ]-trick of FSM:

I agree, this way to set up the array realy looks good.

Something like   ' drop , ' >0 ,  ..   is uglier.

:-)
Michael

Re: [Amforth-devel] words: tuck/under etc

[Bernard M. <bme...@gm...>]

Hi Michael,

I implemented the "Elegant FSM" version of Julien's code Section 3.3 i.e:

The FSM is then defined as

4 WIDE FSM:
\ input:  |  other?  |  num?   |  minus?  |   dp?     |
\ state:  ---------------------------------------------
   ( 0 )     DROP >0    EMIT >1   EMIT >1     EMIT >2
   ( 1 )     DROP >1    EMIT >1   DROP >1     EMIT >2
   ( 2 )     DROP >2    EMIT >2   DROP >2     DROP >2 ;


That seems to me the most readable and flexible of all his examples.
I have given Mathias the code for including in the Lib.

Cheers,
Bernard.

On Thu, Jul 17, 2008 at 5:16 AM, Kalus Michael <mic...@on...>
wrote:

> Hi Bernard.
>
>
> Am 15.07.2008 um 03:03 schrieb Bernard Mentink:
>
> > And lastly, the FSM code is:
> >
> > : FSM:       ( width -- )  CREATE  ,  ]
> >         DOES>  ( n adr -- )
> >                TUCK  @  mystate @  *   +   CELLS   CELL+  +
> >                ( adr')  PERFORM  ;
> >
> >  I notice he enters into compile mode with the "]" word just before
> > the
> > DOES> word, is that necessary to do with the latest CREATE/DOES code?
>
> In the meantime I studied Nobles Code (1). Hope I got it right what
> he is doing there.
>
>
> This is what the ] does:
>
> He ceates a defining word called FSM: and during compiletime of FSM:
> the ] is compiled into the definition. At runtime of FSM: the ] is
> executed. Now this starts compilation of all the words following the
> word defined by the defining word until the closing ; enters
> execution again.
>
>
> In Nobles example "3.2. A Better FSM" FSM: defines <Fixed.Pt#> and
> thereafter compiles the list of execution tokens:
>
> 4 WIDE FSM: <Fixed.Pt#>   ( action# -- )
> \            other   num    -     .      \ state
>              DROP    (00)  (00)  (02)    \ 0
>              DROP    (00)  DROP  (02)    \ 1
>              DROP    (02)  DROP  DROP  ; \ 2
>
>
> If you do not want to use that ]-trick, because it makes your program
> code more mysterious,  you archive the same result this way:
>
> 4 WIDE FSM: <Fixed.Pt#>   ( action# -- )
> \              other       num        -        .         \ state
>              ' DROP ,    ' (00) ,  ' (00) ,  ' (02) ,    \ 0
>              ' DROP ,    ' (00) ,  ' DROP ,  ' (02) ,    \ 1
>              ' DROP ,    ' (02) ,  ' DROP ,  ' DROP ,    \ 2
>
> This way it is more obvious what comes into the array.
>
>
> So the use of ] has nothing to do with the CREATE/DOES Part of
> creating a new defining word. ok?
>
> Michael
>
>
> (1) Finite State Machines in Forth; J. V. Noble
>     http://dec.bournemouth.ac.uk/forth/jfar/index.html
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] u*/mod should multiply unsigned?

[Alexander G. <ale...@an...>]

>>>>> "Matthias" == Matthias Trute <mt...@we...> writes:

    Matthias> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

    Matthias> Ho Alexander

    Matthias> Alexander Guy wrote:
    >> Greetings, First of all, thanks to all of the developers for
    >> making amforth available; I've found it extremely useful.

    Matthias> Thank you, and allow me a simple question: what do you
    Matthias> do with amforth?

I've been using it to test automotive engine control units:

     http://www.efi101.com/forum/viewtopic.php?t=3619&highlight=simulation

.. specifically I've been generating simulated engine position information, to see how the ECUs react to changes in engine speed.

    >> I think I've run into a bug related to u*/mod.  It's listed as
    >> accepting unsigned values, but (as of amforth v2.8) uses m* for
    >> multiplication.  Shouldn't it be using um*?

    Matthias> The u*/mod currently passes the Hayes Test, but I'll
    Matthias> check your fix ASAP, it is too obvious to be ignored ;=)

Great.  Thanks.


Alexander

Re: [Amforth-devel] u*/mod should multiply unsigned?

[Kalus M. <mic...@on...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.


Am 16.07.2008 um 21:21 schrieb Matthias Trute:
>>  I think I've run
>> into a bug related to u*/mod.  It's listed as accepting unsigned
>> values, but (as of amforth v2.8) uses m* for multiplication.
>> Shouldn't it be using um*?
>
> The u*/mod currently passes the Hayes Test, but I'll check your fix
> ASAP, it is
> too obvious to be ignored ;=)

In dpans forth there is no "u*/mod"  at all;  even gforth has no such  
word.

I wonder how it sneeked into amforth?

Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIflVVJ3DLQCvSXtcRAhvWAKD+CdNr0CQvh1F96xptWTr8feXWrACgovtb
fYscooOwVhN4suaBVf/lmog=
=3rze
-----END PGP SIGNATURE-----

Re: [Amforth-devel] u*/mod should multiply unsigned?

[Matthias T. <mt...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ho Alexander

Alexander Guy wrote:
> Greetings, First of all, thanks to all of the developers for making
> amforth available; I've found it extremely useful.

Thank you, and allow me a simple question: what do you do with amforth?
I get only very vage project descriptions, if anything at all; but am
very
interested what people do with amforth (you can answer me directly,
I won't disclose your ideas)...

>  I think I've run
> into a bug related to u*/mod.  It's listed as accepting unsigned
> values, but (as of amforth v2.8) uses m* for multiplication.
> Shouldn't it be using um*?

The u*/mod currently passes the Hayes Test, but I'll check your fix
ASAP, it is
too obvious to be ignored ;=)

Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIfkol9bEHdGEMFjMRApJKAJ9ITjFy1hbMEL6ddCr/4OSenMT9bgCfYZI/
MDtF1UfDM98AQmDpHH9eofc=
=7Jqh
-----END PGP SIGNATURE-----

Re: [Amforth-devel] words: tuck/under etc

[Kalus M. <mic...@on...>]

Hi Bernard.


Am 15.07.2008 um 03:03 schrieb Bernard Mentink:

> And lastly, the FSM code is:
>
> : FSM:       ( width -- )  CREATE  ,  ]
>         DOES>  ( n adr -- )
>                TUCK  @  mystate @  *   +   CELLS   CELL+  +
>                ( adr')  PERFORM  ;
>
>  I notice he enters into compile mode with the "]" word just before  
> the
> DOES> word, is that necessary to do with the latest CREATE/DOES code?

In the meantime I studied Nobles Code (1). Hope I got it right what  
he is doing there.


This is what the ] does:

He ceates a defining word called FSM: and during compiletime of FSM:  
the ] is compiled into the definition. At runtime of FSM: the ] is  
executed. Now this starts compilation of all the words following the  
word defined by the defining word until the closing ; enters  
execution again.


In Nobles example "3.2. A Better FSM" FSM: defines <Fixed.Pt#> and  
thereafter compiles the list of execution tokens:

4 WIDE FSM: <Fixed.Pt#>   ( action# -- )
\            other   num    -     .      \ state
              DROP    (00)  (00)  (02)    \ 0
              DROP    (00)  DROP  (02)    \ 1
              DROP    (02)  DROP  DROP  ; \ 2


If you do not want to use that ]-trick, because it makes your program  
code more mysterious,  you archive the same result this way:

4 WIDE FSM: <Fixed.Pt#>   ( action# -- )
\              other       num        -        .         \ state
              ' DROP ,    ' (00) ,  ' (00) ,  ' (02) ,    \ 0
              ' DROP ,    ' (00) ,  ' DROP ,  ' (02) ,    \ 1
              ' DROP ,    ' (02) ,  ' DROP ,  ' DROP ,    \ 2

This way it is more obvious what comes into the array.


So the use of ] has nothing to do with the CREATE/DOES Part of  
creating a new defining word. ok?

Michael


(1) Finite State Machines in Forth; J. V. Noble
     http://dec.bournemouth.ac.uk/forth/jfar/index.html

Re: [Amforth-devel] words: tuck/under etc

[Ulrich H. <uh...@xl...>]

Hi Mike,

> Hm, what makes the differencce in using
> : perform   postpone @ postpone execute ; ( A )
> instead of
> : perform  @ execute ; ( B )
> then? Speed?


it has to be either

: perform ( compiling: -- ) ( interpreting:  xt -- )
      postpone @  postpone execute ;
immediate

or just

: perform ( xt -- )  @ execute ;

The latter is the typical definition.

The first definition compiles code so in principle
could be removed from the final program. This however
is seldomly done as only few Forth systems support
temporary definitions.

Speedwise the first version might be slightly faster as
less nesting is done. However the effect is probably
marginal and not worth the effort....

I personally would define PERFOM only for
porting code. I believe

@ EXECUTE

makes a fine phrase to be writen in source.
If I build data/control structures it will be hidden in
that definition anyway, like:

: Case:  ( -- )  Create Does>  ( i*x -- j*x ) cells + @ execute ;

Case: choice   ' dup ,  ' swap , ' drop ,

10   0 choice ( dup )
20   1 choise ( swap )
2 choice ( drop )   2 choice ( drop )   2 choice  ( drop )


F83 has PERFORM implemented in code which might
have the speed advantage.... Benchmarking required.

Regards,
			Ulli


Am 16.07.2008 um 10:37 schrieb Kalus Michael:

> Hi Ulli.
>
> Am 16.07.2008 um 08:12 schrieb Ulrich Hoffmann:
>>> Is the solution now to use *: perform postpone @ postpone execute;
>>> *??
>> yes
>
> Hm, what makes the differencce in using
> : perform   postpone @ postpone execute ; ( A )
> instead of
> : perform  @ execute ; ( B )
> then? Speed?
>
> Looks like Version A acts like an makro compiling @ and EXECUTE into
> your definition, so that at runtime there will be less overhead
> because we skip one NEXT level this way? If speed does not matter
> that much version B will do the same thing?
>
> Michael
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] words: tuck/under etc

[Kalus M. <mic...@on...>]

Hi Ulli.

Am 16.07.2008 um 08:12 schrieb Ulrich Hoffmann:
>> Is the solution now to use *: perform postpone @ postpone execute;  
>> *??
> yes

Hm, what makes the differencce in using
: perform   postpone @ postpone execute ; ( A )
instead of
: perform  @ execute ; ( B )
then? Speed?

Looks like Version A acts like an makro compiling @ and EXECUTE into  
your definition, so that at runtime there will be less overhead  
because we skip one NEXT level this way? If speed does not matter  
that much version B will do the same thing?

Michael

Re: [Amforth-devel] words: tuck/under etc

[Ulrich H. <uh...@xl...>]

Hi Bernie, Mike,

> Is the solution now to use *: perform postpone @ postpone execute; *??


yes

In Forth-83 there were two distinct words for user defined
compilation: COMPILE for non-immediate words and [COMPILE] for
immediate words.

However some special Forth systems had immediate words which
are non-immediate in typical systems: for example cmForth
defines @ as an immediate compiler macro.

Thus the use of COMPILE and [COMPILE] was not portable to
those systems.

POSTPONE tries to hide the immediateness
of the compiled word, so POSTPONE @ compiles the
correct code whether or not @ is immediate.

Interesting enough, if you want to emulate POSTPONE
on older systems with COMPILE and [COMPILE] you have
to deal with the immediateness of the compiled word in
order to hide it...

Regards,
		Ulli

Am 15.07.2008 um 23:28 schrieb Bernard Mentink:

> Thanks Michael,
>
> I don't understand German but I get the code, I had found the  
> definition to
> tuck elsewhere, I just wanted to check it was correct.
>
> Also I am still having trouble with the old style forth in the
> definition :*perform compile @ compile execute ;
> *
> Is the solution now to use *: perform postpone @ postpone execute; *??
>
> Cheers,
> Bernie
>
> 2008/7/16 Kalus Michael <mic...@on...>:
>
>> Guten Abend Bernard.
>>
>> Am 15.07.2008 um 03:03 schrieb Bernard Mentink:
>>> .. does anyone
>>> have the definition for "tuck" at hand?
>>
>> : tuck ( w1 w2 – w2 w1 w2 ) \ core-ext "tuck"
>>  swap over ;
>>
>> Beispiel aus gforth:
>>
>> 11 22 .s
>> <2> 11 22  ok
>> tuck .s
>> <3> 22 11 22  ok
>>
>> 33 44 .s
>> <5> 22 11 22 33 44  ok
>> swap over .s
>> <6> 22 11 22 44 33 44  ok
>>
>> Tuck ist nützlich wenn es als code definiert ist, weil die
>> Kkombiantion SWAP OVER doch häufiger vorkommt. Ist aber nicht sooo
>> dringend das zu implementieren, es sei denn du hättest wirklich sehr
>> laufzeitkritischen Code hast.
>>
>> Grüße, Michael
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Amforth-devel mailing list
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] words: tuck/under etc

[Bernard M. <bme...@gm...>]

Thanks Michael,

I got the code working. I used *: perform @ execute ;* , did not need the
"compile" word.
I also had to tweak the code a bit to take care of atmel 16 bit word
addressing, but apart from that it works fine.

I will post the code to be included in the library, that is if anyone finds
writing state machines useful, I personally use them all the time to make
code faster and more readable ......

Cheers,
Bernie

On Wed, Jul 16, 2008 at 10:37 AM, Kalus Michael <mic...@on...>
wrote:

> Bernhard.
>
> Am 15.07.2008 um 03:03 schrieb Bernard Mentink:
>
> >
> > Also, in the FSM code he defines a PERFORM word as:  .... : PERFORM
> > compile
> > @ compile execute ;
> > Would the same thing in amForth be: .... : PERFORM defer @ defer
> > execute ;
> > or do we still use "compile"???? I am a bit
> > rusty on what "defer" does.
> >
>
> No idea what ist goin on here.
>
> I found a definition in former F83 for the 6502 cpu:
>
> : PERFORM ( ADDR -- )   @ EXECUTE ;
>
>
> gforth doc says:
>  ...execute performs the semantics represented by the
> XT (i.e., for XTs produced with ' the interpretation semantics).
>
> So:  ' swap execute   simply does  SWAP
>
> To get an execution vector you can store an XT (execution token) into
> a variable and PERFORM this variable with the phrase  @ EXECUTE
>
>
>
> variable dance
>
> ' hiphop dance !
> ...
> perform dance
> ...
> ' walz dance !
> ...
> perform dance
>
>
> Does this help?  Michael
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] words: tuck/under etc

[Kalus M. <mic...@on...>]

Bernhard.

Am 15.07.2008 um 03:03 schrieb Bernard Mentink:

>
> Also, in the FSM code he defines a PERFORM word as:  .... : PERFORM  
> compile
> @ compile execute ;
> Would the same thing in amForth be: .... : PERFORM defer @ defer  
> execute ;
> or do we still use "compile"???? I am a bit
> rusty on what "defer" does.
>

No idea what ist goin on here.

I found a definition in former F83 for the 6502 cpu:

: PERFORM ( ADDR -- )   @ EXECUTE ;


gforth doc says:
  ...execute performs the semantics represented by the
XT (i.e., for XTs produced with ’ the interpretation semantics).

So:  ' swap execute   simply does  SWAP

To get an execution vector you can store an XT (execution token) into  
a variable and PERFORM this variable with the phrase  @ EXECUTE



variable dance

' hiphop dance !
...
perform dance
...
' walz dance !
...
perform dance


Does this help?  Michael

Re: [Amforth-devel] words: tuck/under etc

[Kalus M. <mic...@on...>]

Hi Bernhard.

Am 15.07.2008 um 03:03 schrieb Bernard Mentink:

>
> : FSM:       ( width -- )  CREATE  ,   ]
>         DOES>  ( n adr -- )
>                TUCK  @  mystate @  *   +   CELLS   CELL+  +
>                ( adr')  PERFORM  ;
>

May be you want to post you quesion on usenet: comp.lang.forth

Or you may ask Ulrich Hoffman, he is very familiar with those older  
forths too.


Michael

Re: [Amforth-devel] words: tuck/under etc

[Kalus M. <mic...@on...>]

Hi Bernhard.

Am 15.07.2008 um 23:28 schrieb Bernard Mentink:
> I don't understand German but I get the code,

Oh, did not think of it for a moment, Im sorry.

>> Tuck ist nützlich wenn es als code definiert ist, weil die
>> Kkombiantion SWAP OVER doch häufiger vorkommt. Ist aber nicht sooo
>> dringend das zu implementieren, es sei denn du hättest wirklich sehr
>> laufzeitkritischen Code hast.

So here it is in English:

Tuck i useful if you define it in assember code. It then replaces  
SWAP OVER so your programm runs faster. Only needed if your program  
has run time critical code around SWAP OVER phrases.

Michael

Re: [Amforth-devel] words: tuck/under etc

[Bernard M. <bme...@gm...>]

Thanks Michael,

I don't understand German but I get the code, I had found the definition to
tuck elsewhere, I just wanted to check it was correct.

Also I am still having trouble with the old style forth in the
definition :*perform compile @ compile execute ;
*
Is the solution now to use *: perform postpone @ postpone execute; *??

Cheers,
Bernie

2008/7/16 Kalus Michael <mic...@on...>:

> Guten Abend Bernard.
>
> Am 15.07.2008 um 03:03 schrieb Bernard Mentink:
> > .. does anyone
> > have the definition for "tuck" at hand?
>
> : tuck ( w1 w2 – w2 w1 w2 ) \ core-ext "tuck"
>   swap over ;
>
> Beispiel aus gforth:
>
> 11 22 .s
> <2> 11 22  ok
> tuck .s
> <3> 22 11 22  ok
>
> 33 44 .s
> <5> 22 11 22 33 44  ok
> swap over .s
> <6> 22 11 22 44 33 44  ok
>
> Tuck ist nützlich wenn es als code definiert ist, weil die
> Kkombiantion SWAP OVER doch häufiger vorkommt. Ist aber nicht sooo
> dringend das zu implementieren, es sei denn du hättest wirklich sehr
> laufzeitkritischen Code hast.
>
> Grüße, Michael
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] words: tuck/under etc

[Kalus M. <mic...@on...>]

Guten Abend Bernard.

Am 15.07.2008 um 03:03 schrieb Bernard Mentink:
> .. does anyone
> have the definition for "tuck" at hand?

: tuck ( w1 w2 – w2 w1 w2 ) \ core-ext “tuck”
   swap over ;

Beispiel aus gforth:

11 22 .s
<2> 11 22  ok
tuck .s
<3> 22 11 22  ok

33 44 .s
<5> 22 11 22 33 44  ok
swap over .s
<6> 22 11 22 44 33 44  ok

Tuck ist nützlich wenn es als code definiert ist, weil die  
Kkombiantion SWAP OVER doch häufiger vorkommt. Ist aber nicht sooo  
dringend das zu implementieren, es sei denn du hättest wirklich sehr  
laufzeitkritischen Code hast.

Grüße, Michael

[Amforth-devel] words: tuck/under etc

[Bernard M. <bme...@gm...>]

Hi All,

I am trying to implement some "finite state machine" code from J. Noble. In
his example code from an older Forth standard, he uses  the word TUCK
derived from "under" as ..... : TUCK compile under ;
I cannot find the words tuck or under in amForth core words, does anyone
have the definition for "tuck" at hand?

Also, in the FSM code he defines a PERFORM word as:  .... : PERFORM compile
@ compile execute ;
Would the same thing in amForth be: .... : PERFORM defer @ defer execute ;
or do we still use "compile"???? I am a bit
rusty on what "defer" does.

And lastly, the FSM code is:

: FSM:       ( width -- )  CREATE  ,   ]
        DOES>  ( n adr -- )
               TUCK  @  mystate @  *   +   CELLS   CELL+  +
               ( adr')  PERFORM  ;

 I notice he enters into compile mode with the "]" word just before the
DOES> word, is that necessary to do with the latest CREATE/DOES code?

Thanks in advance ..
Bernie

[Amforth-devel] u*/mod should multiply unsigned?

[Alexander G. <ale...@an...>]

Greetings,
    First of all, thanks to all of the developers for making amforth available; I've found it extremely useful.  I think I've run into a bug related to u*/mod.  It's listed as accepting unsigned values, but (as of amforth v2.8) uses m* for multiplication.  Shouldn't it be using um*?

--- a/core/words/ustarslashmod.asm
+++ b/core/words/ustarslashmod.asm
@@ -9,7 +9,7 @@ XT_USTARSLASHMOD:
     .dw DO_COLON
 PFA_USTARSLASHMOD:
     .dw XT_TO_R
-    .dw XT_MSTAR
+    .dw XT_UMSTAR
     .dw XT_R_FROM
     .dw XT_UMSLASHMOD
     .dw XT_EXIT

Thanks.


Alexander

Re: [Amforth-devel] Amforth(9600), ZTerm(19200) why?

[Matthias T. <mt...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

avr feedback wrote:
> http://dev.emcelettronica.com/why-avrs-eeprom-will-be-erased-randomly
> 
> I think I will explain my problem with this article and move on. =/

That could be the reason why I sometimes (ok, nearly every time)
see the turnkey action (output of VER to the serial line)
whilest flashing a new image. Not that it ever did any harm
to my code/hardware, but it is funny to see it at all....

But: you should get rid of your problems by re-flashing the hexfiles
a second time. The content of the EEPROM is than correct and the default
turnkey action does not change EEPROM content.  Another solution would
be to flash the eeprom content ahead of the flash content (simply
change the order for the avrdude call in the Makefile). Please let me
know, if this works.

There are a few more possible work-arounds e.g. changing the addresses
in  the .eseg area, but it is rather difficult since the addresses are
hard coded in the coresponding words/*.asm files.

Matthias

PS: despite the current problems, I made a new release...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIZVC59bEHdGEMFjMRAimwAJ0VHGXKq/FsDZLXOAf9lvCZ/SDPygCgyxno
cUIA8xz3moxGrps6yBXqteg=
=8e9j
-----END PGP SIGNATURE-----