amforth-devel — Development discussion and user support

Re: [Amforth] imove

[Rafael G. <ast...@ya...>]

mmm ... I think the 200x proposal misses EEPROM as Data space 


________________________________
 De: Matthias Trute <mt...@we...>
Para: Everything around amforth <amf...@li...> 
Enviado: Miércoles 10 de abril de 2013 20:58
Asunto: Re: [Amforth] imove
 

Hi,

> May I suggest renaming the new implementation of imove
> ( i-addr len ram -- ) at lib/ans94/core/imove.frt to icmove:

Uhm. The naming I'd like to delay. There are some
efforts to get a consistent naming convention for
memory accesses. One example is
http://www.forth200x.org/memory-2010-06-26.txt

> Also, it seems to me that your implementation may cause ram buffer
> overflow.

The code copies flash cells. That may overrun the
RAM if an odd number of bytes is transferred. Thats
bad indeed.

Matthias


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] imove

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

Hi,

> May I suggest renaming the new implementation of imove
> ( i-addr len ram -- ) at lib/ans94/core/imove.frt to icmove:

Uhm. The naming I'd like to delay. There are some
efforts to get a consistent naming convention for
memory accesses. One example is
http://www.forth200x.org/memory-2010-06-26.txt

> Also, it seems to me that your implementation may cause ram buffer
> overflow.

The code copies flash cells. That may overrun the
RAM if an odd number of bytes is transferred. Thats
bad indeed.

Matthias

[Amforth] imove

[Enoch <ix...@ho...>]

Hello Matthias,

May I suggest renaming the new implementation of imove
( i-addr len ram -- ) at lib/ans94/core/imove.frt to icmove:

imove should be a variant of move, that is: "copy the contents of u
consecutive address units".

icmove should be a variant of cmove, that is: "copy u consecutive
characters".

Also, it seems to me that your implementation may cause ram buffer
overflow.

Regards, Enoch.

Re: [Amforth] New release 5.1

[Enoch <ix...@ho...>]

Thanks Matthias for your great work,
it is much appreciated here!

Regards, Enoch.

Re: [Amforth] New release 5.1

[Enoch W. <ix...@ho...>]

Hello Matthias,

Thank you for your great work.
It is much appreciated here!

Regards, Enoch.

GMANE seems to have taken a hiatus on amforth... so a direct mail instead. 		 	   		  

[Amforth] New release 5.1

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

Hi,

the changelog got too long, so I made a new release.

http://amforth.sourceforge.net/

Thanks to all who contributed and donated code. I really enjoyed it
very much and do hope for more :)

Matthias

Re: [Amforth] Quite trivial

[Rafael G. <ast...@ya...>]

Sorry, I was referring to Flash addresses.  :-)


________________________________
 De: Matthias Trute <mt...@we...>
Para: Everything around amforth <amf...@li...> 
Enviado: Martes 2 de abril de 2013 20:08
Asunto: Re: [Amforth] Quite trivial
 
Hi,

> Maybe it is a trivial observation, but I see that 2/ is a bad idea for
> addresses > 32KWhatever (bytes or words) since sign propagation will
> produce an incorrect address. I defined u2/ myself for that purpose.

Its not the address but the size information. The chances are too little to
hit this bug (you need plenty of external RAM for this).

Matthias
PS: Another simple (but not trival) update is 
http://amforth.sourceforge.net/TG/recipes/RAM-Efficiency.html

------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Quite trivial

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:
>> Maybe it is a trivial observation, but I see that 2/ is a bad idea for
>> addresses > 32KWhatever (bytes or words) since sign propagation will
>> produce an incorrect address. I defined u2/ myself for that purpose.
>
> Its not the address but the size information. The chances are too little to
> hit this bug (you need plenty of external RAM for this).

Hello Matthias,

What I expressed support for was adding u2/ to the standard, as
recommended by Rafael. People with strictly typed language experience
may easily forget about this subtle point.

Regards, Enoch.

Re: [Amforth] Rvalue.frt

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

Enoch,
 
> Thanks for this new useful word. Any reason for the capital R?

No real good reason but to resemble the Edefer and Rdefer's

> May I suggest adding to the standard a definition for rcvalue.

I'll leave this as an excercise to the readers. Hint: RTFM ;)

Matthias

Re: [Amforth] Quite trivial

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

Hi,

> Maybe it is a trivial observation, but I see that 2/ is a bad idea for
> addresses > 32KWhatever (bytes or words) since sign propagation will
> produce an incorrect address. I defined u2/ myself for that purpose.

Its not the address but the size information. The chances are too little to
hit this bug (you need plenty of external RAM for this).

Matthias
PS: Another simple (but not trival) update is 
http://amforth.sourceforge.net/TG/recipes/RAM-Efficiency.html

[Amforth] Rvalue.frt

[Enoch <ix...@ho...>]

Hello Matthias,

Thanks for this new useful word. Any reason for the capital R?
One would wonder why we need variable-s any more :-)
May I suggest adding to the standard a definition for rcvalue.

Regards, Enoch.

Re: [Amforth] Quite trivial

[Enoch <ix...@ho...>]

Rafael Gonzalez <ast...@ya...> writes:

> Maybe it is a trivial observation, but I see that 2/ is a bad idea for addresses > 32KWhatever (bytes or words)
> since sign propagation will produce an incorrect address. I defined u2/ myself for that purpose.

Good point, thanks!

Interestingly, RC1 does not address this important issue of sign
extension.

Yes, we should have u2/ in our lib as well.

Regards, Enoch.

> ________________________________
>  De: Enoch <ix...@ho...>
> Para: amf...@li... 
> Enviado: Lunes 1 de abril de 2013 7:29
> Asunto: [Amforth] Quite trivial
>  
> Hello Matthias & All:
>
> Here's a useful word to add to our lib (IMHO).
>
> Regards, Enoch.
>
> P/S ( f-addr count ) is produced by s"
>
> ----------------------------------------------------------------------
>
> \ copy "count" bytes from Flash to RAM
> : imove  ( f-addr count addr -- )
>    swap 0 ?do
>       over i 2/ + @i
>       i 1 and  if  ><  then
>       over i + c!
>    loop
>    2drop
> ;
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel&reg; Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game 
> on Steam. $5K grand prize plus 10 genre and skill prizes. 
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> ------------------------------------------------------------------------------
> Own the Future-Intel&reg; Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game 
> on Steam. $5K grand prize plus 10 genre and skill prizes. 
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d

Re: [Amforth] Quite trivial

[Rafael G. <ast...@ya...>]

Maybe it is a trivial observation, but I see that 2/ is a bad idea for addresses > 32KWhatever (bytes or words)
since sign propagation will produce an incorrect address. I defined u2/ myself for that purpose.

cheers
Rafael
 


________________________________
 De: Enoch <ix...@ho...>
Para: amf...@li... 
Enviado: Lunes 1 de abril de 2013 7:29
Asunto: [Amforth] Quite trivial
 
Hello Matthias & All:

Here's a useful word to add to our lib (IMHO).

Regards, Enoch.

P/S ( f-addr count ) is produced by s"

----------------------------------------------------------------------

\ copy "count" bytes from Flash to RAM
: imove  ( f-addr count addr -- )
   swap 0 ?do
      over i 2/ + @i
      i 1 and  if  ><  then
      over i + c!
   loop
   2drop
;


------------------------------------------------------------------------------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Quite trivial

[Enoch <ix...@ho...>]

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

>> : imove  ( f-addr count addr -- )
>
> Its already there: copy-string in lib(ans94/core/evaluate.frt
> and environment-q.frt
>
> I shoiuld extract the code (and rename it to something better
> what about iplace? it resembles place and indicates the
> i-memory.)

Hello Matthias,

As a general rule we should prefer picking names resembling those
already in Forth 2012 RC1 -- I guess that I am not the only one keeping
this doc at my fingertips when coding :-) That's the only reason I chose
a variant of the word MOVE. ICOMPARE is a good example.

Regards, Enoch.

Re: [Amforth] Quite trivial

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

Hi Enoch,

> : imove  ( f-addr count addr -- )

Its already there: copy-string in lib(ans94/core/evaluate.frt
and environment-q.frt

I shoiuld extract the code (and rename it to something better
what about iplace? it resembles place and indicates the
i-memory.)

Matthias

[Amforth] Quite trivial

[Enoch <ix...@ho...>]

Hello Matthias & All:

Here's a useful word to add to our lib (IMHO).

Regards, Enoch.

P/S ( f-addr count ) is produced by s"

----------------------------------------------------------------------

\ copy "count" bytes from Flash to RAM
: imove  ( f-addr count addr -- )
   swap 0 ?do
      over i 2/ + @i
      i 1 and  if  ><  then
      over i + c!
   loop
   2drop
;

Re: [Amforth] wordlist scope

[Enoch <ix...@ho...>]

Hello Matthias,

Having given further thought to r1404 and your recent comments I think
that we need to revert to the wlscope former interface to utilize this
new mechanism to its fullest. Example follows and here's the kernel
patch: http://pastebin.com/aSWRMU3V

Regards, Enoch.

\ wlscope, "wordlist scope" ( addr len -- addr' len' wid ), is a deferred word
\ which enables the AmForth application to choose the wordlist ( wid ) for the
\ new voc entry based on the input ( addr len ) string. The name of the new voc
\ entry ( addr' len' ) may be different from the input string. Note that *all*
\ created voc entry types pass through the wlscope mechanism. The default
\ wlscope action passes the input string to the output without modification and
\ uses get-current to select the wid.

\ The following example shows how to create a library of words under a special
\ wordlist (can_lib). This example also shows how to chain scope calls safely.

wordlist constant can_lib

get-order 1+ can_lib swap set-order	\ can_lib would be searched first

: can_scope  ( addr len -- addr' len' wid )
   2dup
   4 >  if				\ name length check
      s" can_" tuck icompare  if	\ name prefix check
	 4 - swap 4 + swap		\ drop prefix from created word
	 can_lib exit
      then
   else
      drop
   then
   [ ' wlscope defer@ ] literal execute
;

' can_scope is wlscope

Re: [Amforth] wordlist scope

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

Hi Enoch,

> Good, did svn update deciding conflicts in your favor :-)

;)

> Regarding the behind the scenes cleanup, do you allow merging of
> XT_HEADER into XT_DOCREATE ?

No. HEADER is useful for other things too.
I think more of something like

CREATE  -> SCOPE -> HEADER -> .
something completely different like : ... 
-> REVEAL

(bascially the lonly !E's in your patch are called REVEAL in other forth's)

This covers the SMUDGE in : and ; as well. 

---------- more unrelated stuff ------------
What about word changes? What if  can_foo is placed into 
the can wordlist *and* changes the wordlist entry name to 
foo only? Together with a recognizer that puzzles the pieces
together again, if needed.

Another idea is to organize the scopes like the recognizers
as a stack. They can be called in order and the final default
action is to place the new word in CURRENT. 

And I found this posting worth reading
http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2011-01/msg00201.html

Matthias

Re: [Amforth] wordlist scope

[Enoch <ix...@ho...>]

Enoch <ix...@ho...> writes:

> Matthias Trute <mt...@we...> writes:
>> I just applied your patch with my modification for the
>> the stack effect of the scope word. My second remark
>> would not change that (user visible) interface so I think
>> we can now play with the idea and can clean up the
>> code behind the scenes with less pressure ;)
>
> Hello Matthias,
>
> Good, did svn update deciding conflicts in your favor :-)
>
> Regarding the behind the scenes cleanup, do you allow merging of
> XT_HEADER into XT_DOCREATE ?
>
> Regards, Enoch.

Hello again,

Below is an advanced example for (the revised) "wlscope" use. It shows
how to encapsulate a large library of words. Note that since the
following code allows multiple scope installs we can and perhaps should
make "current-scope" invisible.

Any comments?

Regards, Enoch.

----------------------------------------------------------------------

wordlist constant can_list

get-order can_list rot rot 1+ set-order

: scope  ( c-addr len -- wid )
   2dup
   4 >  if				\ name length check
      s" can_" tuck icompare  if	\ name prefix check
	 2drop can_list exit
      then
   else
      drop
   then
   [ ' wlscope defer@ ] literal execute \ scope nesting safe
;

' scope is wlscope

Re: [Amforth] wordlist scope

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:
> I just applied your patch with my modification for the
> the stack effect of the scope word. My second remark
> would not change that (user visible) interface so I think
> we can now play with the idea and can clean up the
> code behind the scenes with less pressure ;)

Hello Matthias,

Good, did svn update deciding conflicts in your favor :-)

Regarding the behind the scenes cleanup, do you allow merging of
XT_HEADER into XT_DOCREATE ?

Regards, Enoch.

Re: [Amforth] wordlist scope

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

Hi Enoch,

I just applied your patch with my modification for the
the stack effect of the scope word. My second remark
would not change that (user visible) interface so I think
we can now play with the idea and can clean up the
code behind the scenes with less pressure ;)

Matthias

Re: [Amforth] wordlist scope

[Enoch <ix...@ho...>]

Hello Matthias,

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

> Hi Enoch,
>
>> > Only one remark so far.
>
> And now my second one. Its more a vague
> idea, not a streamlined chain of reason including
> a smart solution. Sorry.
>
> It is related to the way, the 
> newly created word list entry is linked into it. 
> HEADER gets the WID for which the new word
> is created. The same WID is used later on to be
> stored into the same wordlist: The surprising and
> "unmotivated" XT_STOREE in words that call 
>  (CREATE)  like VARIABLE etc. Withing these words
> there is nothing that could explain it. IMHO.
>
> At the first glance there is no reason to duplicate and
> decentralize the STOREE, but there is one, rather far away:
> Colon word definitions are hidden until the semicolon is
> executed. And the way, the search wordlist (get-order)
> is handled if the compile-to wordlist (Current) contains one
> of the get-order's entries.
>
> What I would like to have is a single place where the new word
> is defined and linked into the right wordlist. Its probably simple,
> but far from trivial. I'll think about it. 
>
> Its a fascinating change. Much more demanding than I thought 
> initially...
>
> Matthias
>
> PS: simply said: just change the stack effect of HEADER from
> (addr len wid -- wid) to something better ;)

#1 There is a strong argument to merge XT_HEADER with XT_DOCREATE as
XT_HEADER is called only by XT_DOCREATE. That's what Mr. KISS always
says :-)

#2 As for "wlscope" stack effect, if the price for our AmForth idea to
be admitted to the Forth community "hall of fame" (forth200x.org, that
is) would be for wlscope to consume its arguments, so be it: We can do
it neatly (i.e., without irritating ol' Mr. KISS) by rearranging the
order of activities in XT_HEADER and call XT_WLSCOPE after the
name-string validity check (non-empty) and after creating the dictionary
header in Flash (i.e., just before linking).

#3 Based on your response to #1 I can submit a patch, if you like. Your
code is, as you say, indeed dark (not enough comment lampposts) but is
quite easy to read!

Regards, Enoch.

 

Re: [Amforth] wordlist scope

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

Hi Enoch,

> > Only one remark so far.

And now my second one. Its more a vague
idea, not a streamlined chain of reason including
a smart solution. Sorry.

It is related to the way, the 
newly created word list entry is linked into it. 
HEADER gets the WID for which the new word
is created. The same WID is used later on to be
stored into the same wordlist: The surprising and
"unmotivated" XT_STOREE in words that call 
 (CREATE)  like VARIABLE etc. Withing these words
there is nothing that could explain it. IMHO.

At the first glance there is no reason to duplicate and
decentralize the STOREE, but there is one, rather far away:
Colon word definitions are hidden until the semicolon is
executed. And the way, the search wordlist (get-order)
is handled if the compile-to wordlist (Current) contains one
of the get-order's entries.

What I would like to have is a single place where the new word
is defined and linked into the right wordlist. Its probably simple,
but far from trivial. I'll think about it. 

Its a fascinating change. Much more demanding than I thought 
initially...

Matthias

PS: simply said: just change the stack effect of HEADER from
(addr len wid -- wid) to something better ;)

Re: [Amforth] wordlist scope

[Enoch <ix...@ho...>]

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

> Hi Enoch,
>
> Only one remark so far.
>
> You defined the scope stack effect as ( addr len -- addr len wid )
> Usually forth follows the conecpt, that a word consumes its parameters
> to generate the new data. I'd prefer to keep this idea as the general
> design pattern. That changes  scope to the stack effect (addr len -- wid )
> That requires a few more instructions (a 2DUP in (CREATE) and the get-current
> needs some glue code to be usable as a scope provider. Nothing really big, I 
> think.

Hello Matthias,

You are absolutely correct, Leo Brodie writes in 4.16 "Tip: Let
definitions consume their arguments", but I have the feeling that he
would have said (*) but you can igone this advice if it adds uncessary
cruft to your code :-)

(*) Since I don't believe that he would advocate against the KISS
principle.

> Your scope example turns to something like
>
>  : scope ( addr len -- wid)
>     drop c@ [char] _ =  if
>        _private
>     else
>        get-current 
>      then ;
>
> (not tested)
>
> The standard scope provider that uses GET-CURRENT will be
>
> : current-scope drop drop get-current ;
>
>> P/S If you approve of this patch I suggest submission of an RfD to
>> forth200x.org.
>
> You're a brave man ;)

I think that their standards committee gives too much voice to guys from
the PC era while Forth "is born" for the small µC in mind.

Regards, Enoch.

Re: [Amforth] wordlist scope

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

Hi Enoch,

Only one remark so far.

You defined the scope stack effect as ( addr len -- addr len wid )
Usually forth follows the conecpt, that a word consumes its parameters
to generate the new data. I'd prefer to keep this idea as the general
design pattern. That changes  scope to the stack effect (addr len -- wid )
That requires a few more instructions (a 2DUP in (CREATE) and the get-current
needs some glue code to be usable as a scope provider. Nothing really big, I 
think.

Your scope example turns to something like

 : scope ( addr len -- wid)
    drop c@ [char] _ =  if
       _private
    else
       get-current 
     then ;

(not tested)

The standard scope provider that uses GET-CURRENT will be

: current-scope drop drop get-current ;

> P/S If you approve of this patch I suggest submission of an RfD to
> forth200x.org.

You're a brave man ;)

Matthias