amforth-devel — Development discussion and user support

[Amforth] Table driven CRC-8 generator/checker

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

Hello Matthias & all,

Please find in <http://pastebin.com/BRHaitj9> my complete CRC-8 implementation
for peer review and library inclusion if there is interest.

crc8.frt demonstrates how MARK can be used to reclaim the code space of table
generators via the persistence of data in PAD.

This CRC-8 implementation is more efficient than that of
lib/hardware/1wire-crc8.frt if messages are transmitted/recived on a
byte-by-byte basis.

Regards, Enoch.

PS1: Is there any reference implementation for [if] [else] [then]. I need them
and would be ready to help if needed.

PS2: I assumed that my amforth-shell.py patch was accepted :-)

Re: [Amforth] Wish to FORGET

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

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

> PPS: I'm not fully and finally against FORGET, I simply won't implement
> it. And probably never include it into amforth.

Hello Matthias,

That's ok for now :-) 

I solved the problem of removing table generators with marker,
communicating their output to unaffected code via PAD.

BTW, how do you like my latest amforth-shell patch? I use appl_defs.frt
as a project wide configuration file including, for example, a DEBUG
flag that introduces various tests to the code. In this context, I am
waiting for your new [if] [else] [then] implementation. 

Thanks + Regards, Enoch.

Re: [Amforth] Wish to FORGET

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

Hi Enoch,

>> I have absolutely no problem that FORGET will be forgotten.
> 
> Here's an interesting article by one of Forth greats:
> "Proposal: un-obsolete FORGET"
> http://www.forth200x.org/unobsolete-forget.txt
> 
> The author sees FORGET as a useful tool for hot system upgrade.

Compare FIND with MARKER

Find name, then delete name from the dictionary along with all words
added to the dictionary after name.

vs.

Remove the definition of name and all subsequent definitions.

As far as I can tell, there is no difference. Both remove not
only the word affected but all what's defined afterwards (which
somehow contradicts what you want to do, IIRC).

> FORGET is useful when a human redefines an existing
> word in the command line, finds a bug, and wants to
> correct it:

FORGET has only one advantage: It does not need planning.

My problem with FORGET arises from the sentence

"If the Search-Order word set is present, FORGET searches the
compilation word list."

And the other word lists? That is IMHO the source for
fragmentation.

> By the way, there are "marketing reasons" for Amforth to acquire
> FORGET-fullness :-)

LOL. The most ultimate reason...


Matthias

PS: did you note the dates? Michael wrote his statement in 2009,
the forth2012RC was published 3 years later and FORGET is not
re-animated there.

PPS: I'm not fully and finally against FORGET, I simply won't implement
it. And probably never include it into amforth.

Re: [Amforth] Wish to FORGET

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

Hello Matthias,

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

> Hi,
>
>> Indeed, your suggested use of MARKER is what I anticipated but I have to
>> agree with you, it would be too difficult/dangerous for an average
>> programmer to try.
>
> I wrote "difficult" not "too difficult" A subtle difference.
>
>> Hence, let us revisit FORGET.
>> I agree with you again that with Flash memory "de-fragmemetation" is
>> not an option. However, there is a solution if you agree to modify
>> the dictionary structure just a bit. I believe that you are familiar
>> with the various "dynamic storage allocation" algorithms (Knuth, Vol
>> 1, Fundamental Algorithms, 2.5 Dynamic Storage Allocation). What if
>> we introduce one bit for each definition which means "FREE" or
>> "IN-USE". FORGET would become: (1) Mark the definition as FREE (2) if
>> possible, merge this newly freed Flash space with adjacent Flash free
>> definitions. For the purpose of this algorithm the "unused dictionary
>> space" would be just another free definition space on our linked
>> list.  When compiling, we can compile into the largest free
>> definition space or choose another strategy.
>
> That may work. The only problem I have with it is: A colon
> definition does not know how much space it needs in advance.
> So how do you decide, which fragment do you use with a particular
> definition? And what do you do, if such an limit is reached?
>
>> By the way, I don't agree with Forth-RC1 comment on FORGET which
>> says as follows: "This word is obsolescent and is included as a
>> concession to existing implementations."
>
> I have absolutely no problem that FORGET will be forgotten.

Here's an interesting article by one of Forth greats:
"Proposal: un-obsolete FORGET"
http://www.forth200x.org/unobsolete-forget.txt

The author sees FORGET as a useful tool for hot system upgrade. He
writes:

"""
Typical use
===========

FORGET is useful when a human redefines an existing
word in the command line, finds a bug, and wants to
correct it:
"""

By the way, there are "marketing reasons" for Amforth to acquire
FORGET-fullness :-)

Regards, Enoch.


>
>> (2) How else can one implement "Dynamic Software Updating" 
>> <http://en.wikipedia.org/wiki/Dynamic_Software_Updating>.
>
> Do you really have non-disruptive software upgrades in mind?
> That is so much far beyond the scope of my little toy,  that
> I even decline any ambitions in this direction.
>
>> As I am not a Forth expert (yet), did any other flash based Forth 
>> introduce FORGET?
>
> I assume, most of them do not have word lists and hence do not have
> the problems arising from them ;) There are a few members
> of this list, that may tell better.
>
> Matthias
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Are [if] [else] [then] really working?

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

Hi Enoch,

> SOS:
> 
> It seems that even simple (single line) cases fail:

Mee too. Sorry.

Matthias

Re: [Amforth] Variations on .S

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

Hello Michael,

Let's add one important case to your fine collection.
Here is .s implementation in openfirmware/forth/kernel/kernel.fth:

: (.s        (s -- )
   depth 0 ?do  depth i - 1- pick n.  loop
;
: .s         (s -- )
   depth 0<
   if   ." Stack Underflow "  sp0 @ sp!
   else depth
        if (.s else ." Empty " then
   then
;

Using the usual "stack picture" (of-course).  Since only Matthias has
commit rights, it's his call. I don't suggest to fork over this issue
though :-)

Regards, Enoch.


"Michael Kalus" <mi-...@t-...>
writes:

> Hi.
> Lets take a look at some common Forths, Revision appended.
> They do it in the typed order left to right.
> Only VFX does it top down linewise, like amforth in its older days.
> Though not a "standard", typed order is "Normative Kraft des  
> Faktischen".
> (google: "normative power of the factual")
>
> Brodies I like best. Unfortunately he does not tell us how the  
> negative numbers are treated.
>
> Regards, Michael
> :-)
>
> -
> Revision of Examples
>
> gforth:
> 11 -22 33 .s <3> 11 -22 33  ok
>
>
> win32forth:
> 11 -22 33 .s [3] 11 -22 33  ok...
> (with a dot for each item, none if empty stack)
>
>
> VFX Forth for Windows IA32:
> 11 -22 33 .s
> DATA STACK
>       top
>               33 0000:0021
>              -22 FFFF:FFEA
>               11 0000:000B
>   ok-3
>
>
> SwiftX MSP430 EVALUATION 3.5.9 12-Apr-2011:
> 11 -22 33 .s
> 11 -22 33 <-Top  ok
>
>
> And last but not least, the Masters Voice:
> Starting Forth by Leo Brodie - Chapter 2
> http://www.forth.com/starting-forth/sf2/sf2.html
>
> <snip>
> A Handy Hint
> A Non-destructive Stack Print
>
> Beginners who are just learning to manipulate numbers on the stack in  
> useful ways very often find themselves typing a series of dots to see  
> what's on the stack after their manipulations. The problem with dots,  
> though, is that they don't leave the numbers on the stack for future  
> manipulation.
>
> The Forth word .S prints out all the values that happen to be on the  
> stack "non-destructively"; that is, without removing them. Let's test  
> it, first with nothing on the stack:
>
> .S <0>  ok
>
> As you can see, in this version of .S, we see at least one number.  
> This is the number of items actually on the stack.
>
> Now let's try with numbers on the stack:
>
> 1 2 3 .S <3> 1 2 3  ok
>
> ROT .S <3> 2 3 1  ok
> </snip>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Variations on .S

[Michael K. <mi-...@t-...>]

Hi.
Lets take a look at some common Forths, Revision appended.
They do it in the typed order left to right.
Only VFX does it top down linewise, like amforth in its older days.
Though not a "standard", typed order is "Normative Kraft des  
Faktischen".
(google: "normative power of the factual")

Brodies I like best. Unfortunately he does not tell us how the  
negative numbers are treated.

Regards, Michael
:-)

-
Revision of Examples

gforth:
11 -22 33 .s <3> 11 -22 33  ok


win32forth:
11 -22 33 .s [3] 11 -22 33  ok...
(with a dot for each item, none if empty stack)


VFX Forth for Windows IA32:
11 -22 33 .s
DATA STACK
      top
              33 0000:0021
             -22 FFFF:FFEA
              11 0000:000B
  ok-3


SwiftX MSP430 EVALUATION 3.5.9 12-Apr-2011:
11 -22 33 .s
11 -22 33 <-Top  ok


And last but not least, the Masters Voice:
Starting Forth by Leo Brodie - Chapter 2
http://www.forth.com/starting-forth/sf2/sf2.html

<snip>
A Handy Hint
A Non-destructive Stack Print

Beginners who are just learning to manipulate numbers on the stack in  
useful ways very often find themselves typing a series of dots to see  
what's on the stack after their manipulations. The problem with dots,  
though, is that they don't leave the numbers on the stack for future  
manipulation.

The Forth word .S prints out all the values that happen to be on the  
stack "non-destructively"; that is, without removing them. Let's test  
it, first with nothing on the stack:

.S <0>  ok

As you can see, in this version of .S, we see at least one number.  
This is the number of items actually on the stack.

Now let's try with numbers on the stack:

1 2 3 .S <3> 1 2 3  ok

ROT .S <3> 2 3 1  ok
</snip>

[Amforth] Are [if] [else] [then] really working?

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

Hello Matthias & all,

SOS:

It seems that even simple (single line) cases fail:

Amforth (r1383):
~~~~~~~~~~~~~~~~
1 [if] s" yes" [else] s" no" [then] type → freezing
0 [if] s" yes" [else] s" no" [then] type → freezing

1 [if] s" hello" [then] type → hello ok
0 [if] s" hello" [then] type → freezing

Gforth:
~~~~~~~
1 [if] s" yes" [else] s" no" [then] type yes ok
0 [if] s" yes" [else] s" no" [then] type  no ok

Thank you, Enoch.

Re: [Amforth] amforth-shell.py patch proposal

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

Hello Matthias & all:

> Matthias Trute <mt...@we...> writes:
>> That makes sense. But appl_own.py as the filenname..... There should
>> be better ones. Or a more generic approach. I'm not a python expert,
>> but many python directories contain a file named __init__.py to do
>> something useful.
>
> Seems too "pythonic" for me :-)
> In fact, I would have preferred it to be appl_owns.frt with
> "$D5 constant CRC8PLY" lines, only that I am too lazy :-)
>

Thanks for the encouragement. I hope that my new attempt to patch
amforth-shell.py is better.

Patch: http://pastebin.com/ENbdSkj5

Usage:

Create a file in the application directory called appl_defs.frt:
Yes, a forth file :-)

\ example

0 constant false
-1 constant true
$d5 constant CRC8PLY
-1 constant CRC8MSB

Let's create the test.frt:

\ #error-on-output no

(
$d5 constant CRC8PLY
-1 constant CRC8MSB
)

CRC8PLY .
CRC8MSB .

$ make shell
AMFORTH_LIB=.:/home/enoch/avr/amforth/trunk/lib python /home/enoch/avr/amforth/trunk/tools/amforth-shell.py -p /dev/ttyUSB2
|I=appl_defs: example
|I=appl_defs: 4 loaded
|I=Entering amforth interactive interpreter
|I=getting MCU name..
|I=successfully loaded register definitions for at90can128
|I=getting filenames on the host
|I=  Reading .
|I=  Reading /home/enoch/avr/amforth/trunk/lib
(AT90CAN128)> #include test.frt
|D=#include test.frt
|I=getting filenames on the host
|I=  Reading .
|I=  Reading /home/enoch/avr/amforth/trunk/lib
|I=using test.frt from/home/enoch/private/project
**** /home/enoch/private/project
|I=getting MCU name..
|I=successfully loaded register definitions for at90can128
|F=/home/enoch/private/project/test.frt
|D|    1|\ #error-on-output no
|W|    2|
|C|    3|(
|C|    4|$d5 constant CRC8PLY
|C|    5|-1 constant CRC8MSB
|C|    6|)
|W|    7|
|S|    8|CRC8PLY .
|O|    8|213
|S|    9|CRC8MSB .
|O|    9|-1
|W|   10|
*

Regards, Enoch.

Re: [Amforth] amforth-shell.py patch proposal

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

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

> Enoch,
>
>> I said, how nice it would be if amforth-shell would do it for me just
>> like it does with Atmel's register/bit defs.
>
> That makes sense. But appl_own.py as the filenname..... There should
> be better ones. Or a more generic approach. I'm not a python expert,
> but many python directories contain a file named __init__.py to do
> something useful.

Seems too "pythonic" for me :-)
In fact, I would have preferred it to be appl_owns.frt with
"$D5 constant CRC8PLY" lines, only that I am too lazy :-)

Regards, Enoch.

>> 
>> By the way, I surround the above constants with () which amforth-shell.py
>> respects but amforth itself does not. That's just perfect!
>
> Uhm. Other would have call it a bug ;)
>
> Matthias
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] amforth-shell.py patch proposal

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

Enoch,

> I said, how nice it would be if amforth-shell would do it for me just
> like it does with Atmel's register/bit defs.

That makes sense. But appl_own.py as the filenname..... There should
be better ones. Or a more generic approach. I'm not a python expert,
but many python directories contain a file named __init__.py to do
something useful.

> 
> By the way, I surround the above constants with () which amforth-shell.py
> respects but amforth itself does not. That's just perfect!

Uhm. Other would have call it a bug ;)

Matthias

Re: [Amforth] Wish to FORGET

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

Erich Waelde <ew....@na...> writes:

> Hi Enoch,
>
> On 03/04/2013 04:03 AM, Enoch wrote:
>
>> The code at<http://pastebin.com/1YtVdMeg>  will expire in 4 weeks.
>
> See? In 4 weeks the code is gone. If you had added it to the message
> in the first place, then anyone could find it even in years, if
> the mail archive is still available on the net or locally on my or
> your hard disk --- even for offline searching and viewing.

Hi Erich,

What if I wanted it to self expire as the code wasn't "fully baked".  If
my code is taken by Matthias then it would no doubt reach posterity :-)
but I am not there yet. Besides, pastebin makes downloading easier and
guarantees the integrity of the downloaded code. Mail system, if you are
not careful with safe line length, would do bad things to your code.

> So call me a mailing list die hard --- that's fine. And I you would
> please be so kind as to add your lines to the message in the future.
> I'm not afraid of a lengthy message. Thanks!

I take a solemn oath to submit the final crc8.frt for peer review!

Regards, Enoch.

> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] amforth-shell.py patch proposal

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

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

> Hi Enoch,
>
>>
>> As I promised to generalize crc8.frt (#1) a question was raised how would
>> the user configure it to its use, namely, select the generating
>> polynomial byte and the needed bit order (#2).
>> 
>> I answered the question through the following amforth-shell.py
>> improvement which introduces a local appl_owns.py substitutions file.
>> 
>> Without further ado here's the patch and its use for your perusal:
>> 
>> Patch: http://pastebin.com/uDK7fk9N
>
> A few notes
>
> +        sys.path.insert(0, ".")
>          if os.environ.has_key("AMFORTH_LIB"):
>            self._search_list = os.environ["AMFORTH_LIB"].split(":")
> -        else:
> -          self._search_list=["."]
>
> During my tests I found that change less useful. I run the shell
> not only from the appl directory but also from $HOME, so adding
> "." to the search path leads to a huge amount of files, the
> shell reads in upon start (on my system it took more than only
> a few seconds. And I have 8GB RAM, but my $HOME is bigger). So
> I reject this part of the patch. Sorry.

Point taken, I'll amend. My project resides outside the amforth
hierarchy, hence, I did not notice the hit.

> For the other stuff "appl_own.py" I've not opinion yet. What
> exactly is the problem you want to solve? What I would like to
> have is something that could the following (forth code!)
>
> [undefined] foo
>   #include foo
> [endif]

That all came in context of crc8.frt. It needs two configurable
constants as both the polynomial chosen and the reading order are
application specific (in fact MSB first is considered the reverse
order).

(
$D5 constant CRC8PLY 
-1 constant CRC8MSB
)

I said, how nice it would be if amforth-shell would do it for me just
like it does with Atmel's register/bit defs.

By the way, I surround the above constants with () which amforth-shell.py
respects but amforth itself does not. That's just perfect!

Regards, Enoch.


>
> for which the shell sends the content of foo unless foo is already
> defined. The control words are not sent to the controller as well.
>
> File oriented forth's have something like that, and I think the
> shell is capable of doing something similiar.
>
> Matthias
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Wish to FORGET

[Erich W. <ew....@na...>]

Hi Enoch,

On 03/04/2013 04:03 AM, Enoch wrote:

> The code at<http://pastebin.com/1YtVdMeg>  will expire in 4 weeks.

See? In 4 weeks the code is gone. If you had added it to the message
in the first place, then anyone could find it even in years, if
the mail archive is still available on the net or locally on my or
your hard disk --- even for offline searching and viewing.

So call me a mailing list die hard --- that's fine. And I you would
please be so kind as to add your lines to the message in the future.
I'm not afraid of a lengthy message. Thanks!

Cheers,
Erich

Re: [Amforth] Variations on .S

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

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

> Hi,
>
>> Hello Erich & all,
>> 
>> The focus of my .s comment was on Matthias non standard stack listing
>> order,
>
> Since there is no standard format, my variant cannot be non-standard.
> Thats impossible by definition.
>
> I updated http://amforth.sourceforge.net/TG/recipes/Dumps.html
> with Erich's examples. There should everyone find a solution
> that suits him/her.

I like your approach, holding up to your convictions while respecting
other people opinions.

Regards, Enoch.

>
> Matthias
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Wish to FORGET

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

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

> Hi,
>
>> Indeed, your suggested use of MARKER is what I anticipated but I have to
>> agree with you, it would be too difficult/dangerous for an average
>> programmer to try.
>
> I wrote "difficult" not "too difficult" A subtle difference.
>
>> Hence, let us revisit FORGET.
>> I agree with you again that with Flash memory "de-fragmemetation" is
>> not an option. However, there is a solution if you agree to modify
>> the dictionary structure just a bit. I believe that you are familiar
>> with the various "dynamic storage allocation" algorithms (Knuth, Vol
>> 1, Fundamental Algorithms, 2.5 Dynamic Storage Allocation). What if
>> we introduce one bit for each definition which means "FREE" or
>> "IN-USE". FORGET would become: (1) Mark the definition as FREE (2) if
>> possible, merge this newly freed Flash space with adjacent Flash free
>> definitions. For the purpose of this algorithm the "unused dictionary
>> space" would be just another free definition space on our linked
>> list.  When compiling, we can compile into the largest free
>> definition space or choose another strategy.
>
> That may work. The only problem I have with it is: A colon
> definition does not know how much space it needs in advance.
> So how do you decide, which fragment do you use with a particular
> definition? And what do you do, if such an limit is reached?
>
>> By the way, I don't agree with Forth-RC1 comment on FORGET which
>> says as follows: "This word is obsolescent and is included as a
>> concession to existing implementations."
>
> I have absolutely no problem that FORGET will be forgotten.
>
>> (2) How else can one implement "Dynamic Software Updating" 
>> <http://en.wikipedia.org/wiki/Dynamic_Software_Updating>.
>
> Do you really have non-disruptive software upgrades in mind?
> That is so much far beyond the scope of my little toy,  that
> I even decline any ambitions in this direction.

Matthias, 

Please don't call your work a toy! Before landing here I even considered
a commercial package such as SwiftX for AVR and I found it, IMHO,
inferior.

Regarding the "forget" question. The simplest approach is to select each
new deinition the largest available free space fragement to compile
into. If the Forth programmer is well trained he/she factors his/her
code into small pieces and reutilization of "forgetten" definitions
would be high.

Anyway, that's not a high priority issue for me now, it's part of my
exploration of my new "ecosystem" :-)

Regards, Enoch.





>
>> As I am not a Forth expert (yet), did any other flash based Forth 
>> introduce FORGET?
>
> I assume, most of them do not have word lists and hence do not have
> the problems arising from them ;) There are a few members
> of this list, that may tell better.
>
> Matthias
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] amforth-shell.py patch proposal

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

Hi Enoch,

>
> As I promised to generalize crc8.frt (#1) a question was raised how would
> the user configure it to its use, namely, select the generating
> polynomial byte and the needed bit order (#2).
> 
> I answered the question through the following amforth-shell.py
> improvement which introduces a local appl_owns.py substitutions file.
> 
> Without further ado here's the patch and its use for your perusal:
> 
> Patch: http://pastebin.com/uDK7fk9N

A few notes

+        sys.path.insert(0, ".")
         if os.environ.has_key("AMFORTH_LIB"):
           self._search_list = os.environ["AMFORTH_LIB"].split(":")
-        else:
-          self._search_list=["."]

During my tests I found that change less useful. I run the shell
not only from the appl directory but also from $HOME, so adding
"." to the search path leads to a huge amount of files, the
shell reads in upon start (on my system it took more than only
a few seconds. And I have 8GB RAM, but my $HOME is bigger). So
I reject this part of the patch. Sorry.

For the other stuff "appl_own.py" I've not opinion yet. What
exactly is the problem you want to solve? What I would like to
have is something that could the following (forth code!)

[undefined] foo
  #include foo
[endif]

for which the shell sends the content of foo unless foo is already
defined. The control words are not sent to the controller as well.

File oriented forth's have something like that, and I think the
shell is capable of doing something similiar.

Matthias

Re: [Amforth] Wish to FORGET

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

Hi,

> Indeed, your suggested use of MARKER is what I anticipated but I have to
> agree with you, it would be too difficult/dangerous for an average
> programmer to try.

I wrote "difficult" not "too difficult" A subtle difference.

> Hence, let us revisit FORGET.
> I agree with you again that with Flash memory "de-fragmemetation" is
> not an option. However, there is a solution if you agree to modify
> the dictionary structure just a bit. I believe that you are familiar
> with the various "dynamic storage allocation" algorithms (Knuth, Vol
> 1, Fundamental Algorithms, 2.5 Dynamic Storage Allocation). What if
> we introduce one bit for each definition which means "FREE" or
> "IN-USE". FORGET would become: (1) Mark the definition as FREE (2) if
> possible, merge this newly freed Flash space with adjacent Flash free
> definitions. For the purpose of this algorithm the "unused dictionary
> space" would be just another free definition space on our linked
> list.  When compiling, we can compile into the largest free
> definition space or choose another strategy.

That may work. The only problem I have with it is: A colon
definition does not know how much space it needs in advance.
So how do you decide, which fragment do you use with a particular
definition? And what do you do, if such an limit is reached?

> By the way, I don't agree with Forth-RC1 comment on FORGET which
> says as follows: "This word is obsolescent and is included as a
> concession to existing implementations."

I have absolutely no problem that FORGET will be forgotten.

> (2) How else can one implement "Dynamic Software Updating" 
> <http://en.wikipedia.org/wiki/Dynamic_Software_Updating>.

Do you really have non-disruptive software upgrades in mind?
That is so much far beyond the scope of my little toy,  that
I even decline any ambitions in this direction.

> As I am not a Forth expert (yet), did any other flash based Forth 
> introduce FORGET?

I assume, most of them do not have word lists and hence do not have
the problems arising from them ;) There are a few members
of this list, that may tell better.

Matthias

Re: [Amforth] Variations on .S

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

Hi,

> Hello Erich & all,
> 
> The focus of my .s comment was on Matthias non standard stack listing
> order,

Since there is no standard format, my variant cannot be non-standard.
Thats impossible by definition.

I updated http://amforth.sourceforge.net/TG/recipes/Dumps.html
with Erich's examples. There should everyone find a solution
that suits him/her.

Matthias

[Amforth] amforth-shell.py patch proposal

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

Hello Matthias & all:

As I promised to generalize crc8.frt (#1) a question was raised how would
the user configure it to its use, namely, select the generating
polynomial byte and the needed bit order (#2).

I answered the question through the following amforth-shell.py
improvement which introduces a local appl_owns.py substitutions file.

Without further ado here's the patch and its use for your perusal:

Patch: http://pastebin.com/uDK7fk9N

Example:

$ cat appl_owns.py
# amforth-shell.py application specific forth substitutions

APPL_OWNS = { 'DEBUG': '1' }

$ make shell

...snip...

(AT90CAN128)> DEBUG .
1  ok

Regards, Enoch.

#1 Assuming that Matthias places it in ${AMFORTH}/lib/crc8.frt :-)
#2 With no real constant-s to pay for in the user code.

Re: [Amforth] Wish to FORGET

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

Hello Matthias,

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

> Hi Enoch,
>
>
>> How can I reclaim the Flash memory of the crc8_msb_table word itself?
>> 
>> (1) Our Tools Ext don't include FORGET.
>> 
>> (2) I could use Core Ext MARKER if we had a deferred facility of
>> sort. I.e., create a deferred table and fill it using a transient
>> crc8_msb_table (which MARKER would afterwards help to remove).
>
> There is no simple way. I did not actually test it, but I'd
> start as follows. First define the dictionary header for the data
> (create), allocate the flash room for it (dp 128 + to dp), now the
> marker and finally all the words that you want to dispose after filling
> the data flash area (use !i, not , ). Hmm. sounds not only difficult, it
> is indeed.
>
>> Among Forth main strengths is the ability to change itself at run-time
>> (aka "reflection"). Can we apply it without the penalty of accumulating
>> redundant code?
>
> The major problem (and the reason why I dropped FORGET) is
> fragmentation. The current memory "management" is the trivial
> append/remove approach. The last time FORGET worked for the
> dictionary was until the introduction of wordlists. A flash
> memory manager that can deal with fragmentation is unlikly
> to earn its own size (your CRC table could be pre-computed
> on the host side as well and only the resulting table goes
> to the controller. Just like the magic numbers in lib/sinus.frt).

Indeed, your suggested use of MARKER is what I anticipated but I have to
agree with you, it would be too difficult/dangerous for an average
programmer to try.

Hence, let us revisit FORGET. I agree with you again that with Flash
memory "de-fragmemetation" is not an option. However, there is a
solution if you agree to modify the dictionary structure just a bit. I
believe that you are familiar with the various "dynamic storage
allocation" algorithms (Knuth, Vol 1, Fundamental Algorithms, 2.5
Dynamic Storage Allocation). What if we introduce one bit for each
definition which means "FREE" or "IN-USE". FORGET would become: (1) Mark
the definition as FREE (2) if possible, merge this newly freed Flash
space with adjacent Flash free definitions. For the purpose of this
algorithm the "unused dictionary space" would be just another free
definition space on our linked list.  When compiling, we can compile
into the largest free definition space or choose another strategy.

By the way, I don't agree with Forth-RC1 comment on FORGET which says as
follows: "This word is obsolescent and is included as a concession to
existing implementations."

Because:

(1) In Flash restricted situations what other solution there is for the
program to change itself while running...

(2) How else can one implement "Dynamic Software Updating"
<http://en.wikipedia.org/wiki/Dynamic_Software_Updating>.

As I am not a Forth expert (yet), did any other flash based Forth
introduce FORGET?

Regards, Enoch.

>
> Matthias
> PS: how long last the pastebin files? They look good.

Thanks, 4 more weeks but I promised to improve upon it.



>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Wish to FORGET

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

Hi Erich,

While my CRC-8 code may be of interest I did not want it to become the
focus of conversation and this is why I posted the code as a
"pastebin". My focus was on Forth ability to modify the program
structure during program execution and indeed Matthias has addressed
this very topic.

I intend to contribute my CRC-8 code once it is completed with
crc8_lsb_table construction. It is my opinion that full length code
should not be posted on any mailing list. It is what pasebin was
invented for <http://en.wikipedia.org/wiki/Pastebin> (*). If you have
another "pastebin" site to suggest I am open to hear.

The code at <http://pastebin.com/1YtVdMeg> will expire in 4 weeks. I
hope to submit the final version for review beforehand. You are
*welcome* to comment if you find my code style or approach deficient.

Regards, Enoch.

(*) Nautilus, GNOME file manager, has an extension that makes pastebin
uploads (very) easy.


Erich Waelde <ew....@na...> writes:

> Enoch,
>
> On 03/03/2013 05:22 AM, Enoch wrote:
>> I wrote a table driven CRC-8 routine for short messages using any
>> generating polynomial, seehttp://pastebin.com/1YtVdMeg
>> (I didn't like the slow approach of lib/hardware/1wire-crc8.frt).
>
> If you want me to look at your code, you better include it in
> the message. pastebin creates an external dependency, which does
> imho not fit with mailing lists.
>
> Erich
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Variations on .S

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

Hello Erich & all,

The focus of my .s comment was on Matthias non standard stack listing
order, not on the implementation. This decision, in my opinion, slows
down a Forth trained programmer who is accustomed to maintaining the
standard "stack picture" in his mind.

If you wonder what is "System 1" / "System 2" that I referred to in my
communication see http://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow
for a brief description.

Regards, Enoch. 

Erich Waelde <ew....@na...> writes:

> Hi,
>
> On 03/02/2013 06:22 AM, Enoch wrote:
>> Hello Matthias&  all,
>> 
>> Regarding .S
>> 
>> Indeed, says Forth 2012 RC1, "the format of the display is
>> implementation-dependent".
>> 
>> However, doesn't GFORTH display order make a better sense:
>> 
>> 1 2 3 .s<3>  1 2 3  ok
>> 
>> While ours:
>> 
>>> 1 2 3 .s
>> 3 2 1  ok
>> 
>
> One of the great things on Forth imho is that you can make
> the system do, what your eyes please. So a few variations
> on " .s " :
>
>
> \ variations on dot-s
> \ dot-s, one way, signed output:
> : ds  sp@ sp0 1 cells - do i @  . -2 +loop ;
>
> \ dot-s, one way, unsigned output:
> : uds sp@ sp0 1 cells - do i @ u. -2 +loop ;
>
> \ dot-s, the other way (reverse?), signed output:
> : rs  sp@ sp0      swap do i @  .  2 +loop ;
>
> \ dot-s, the other way, unsigned output:
> : urs sp@ sp0      swap do i @ u.  2 +loop ;
>
> \ dot-s, verbose, as it used to be in earlier versions of amforth:
> :  dsv  depth dup 0 do i u. dup i - cells sp0 swap - dup u. @  . cr loop ;
> : udsv  depth dup 0 do i u. dup i - cells sp0 swap - dup u. @ u. cr loop ;
>
> And watch the show:
>
> 	|> .s
> 	|65530 5 4 3 2 1  ok
> 	|> ds
> 	|1 2 3 4 5 -6  ok
> 	|> uds
> 	|1 2 3 4 5 65530  ok
> 	|> hex uds
> 	|1 2 3 4 5 FFFA  ok
> 	|> rs
> 	|-6 5 4 3 2 1  ok
> 	|> urs
> 	|65530 5 4 3 2 1  ok
> 	|> dsv
> 	|0 1539 -6
> 	|1 1541 5
> 	|2 1543 4
> 	|3 1545 3
> 	|4 1547 2
> 	|5 1549 1
> 	| ok
> 	|>
>
> Just never assume that your preferred solution solves the same
> problem for everyone else. I read words/depth.asm for enlightenment,
> and I chose the above without using pick, because pick needs to be
> added to the dictionary. Obviously there is more than one way to
> do this. You may *want* error checking. I don't. If I do a mistake,
> well I excuse the system for crashing.
>
> Cheers,
> Erich
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

[Amforth] Variations on .S (was: .S “dot-s”)

[Erich W. <ew....@na...>]

Hi,

On 03/02/2013 06:22 AM, Enoch wrote:
> Hello Matthias&  all,
> 
> Regarding .S
> 
> Indeed, says Forth 2012 RC1, "the format of the display is
> implementation-dependent".
> 
> However, doesn't GFORTH display order make a better sense:
> 
> 1 2 3 .s<3>  1 2 3  ok
> 
> While ours:
> 
>> 1 2 3 .s
> 3 2 1  ok
> 

One of the great things on Forth imho is that you can make
the system do, what your eyes please. So a few variations
on " .s " :


\ variations on dot-s
\ dot-s, one way, signed output:
: ds  sp@ sp0 1 cells - do i @  . -2 +loop ;

\ dot-s, one way, unsigned output:
: uds sp@ sp0 1 cells - do i @ u. -2 +loop ;

\ dot-s, the other way (reverse?), signed output:
: rs  sp@ sp0      swap do i @  .  2 +loop ;

\ dot-s, the other way, unsigned output:
: urs sp@ sp0      swap do i @ u.  2 +loop ;

\ dot-s, verbose, as it used to be in earlier versions of amforth:
:  dsv  depth dup 0 do i u. dup i - cells sp0 swap - dup u. @  . cr loop ;
: udsv  depth dup 0 do i u. dup i - cells sp0 swap - dup u. @ u. cr loop ;

And watch the show:

	|> .s
	|65530 5 4 3 2 1  ok
	|> ds
	|1 2 3 4 5 -6  ok
	|> uds
	|1 2 3 4 5 65530  ok
	|> hex uds
	|1 2 3 4 5 FFFA  ok
	|> rs
	|-6 5 4 3 2 1  ok
	|> urs
	|65530 5 4 3 2 1  ok
	|> dsv
	|0 1539 -6
	|1 1541 5
	|2 1543 4
	|3 1545 3
	|4 1547 2
	|5 1549 1
	| ok
	|>

Just never assume that your preferred solution solves the same
problem for everyone else. I read words/depth.asm for enlightenment,
and I chose the above without using pick, because pick needs to be
added to the dictionary. Obviously there is more than one way to
do this. You may *want* error checking. I don't. If I do a mistake,
well I excuse the system for crashing.

Cheers,
Erich

Re: [Amforth] .S “dot-s”

[Michael K. <mi-...@t-...>]

Oh, sorry. Forgot that the list strips attachments.
Michael


; Enochs .S
VE_DOTS:
     .dw $FF02
     .db ".s"
     .dw VE_HEAD
     .set VE_HEAD = VE_DOTS
XT_DOTS:
     .dw DO_COLON
PFA_DOTS:
; ( -- )
; stack picture listing order
     .dw XT_DEPTH
PFA_DOTS0:
     .dw XT_DUP
     .dw XT_DOCONDBRANCH
     .dw PFA_DOTS1
     .dw XT_DUP
     .dw XT_PICK
     .dw XT_DOT
     .dw XT_1MINUS
     .dw XT_DOBRANCH
     .dw PFA_DOTS0
PFA_DOTS1:
     .dw XT_DROP
     .dw XT_EXIT




; old form giving index#, address and value of stack items.
; ( -- ) Tools
; R( -- )
; stack dump
VE_DOTSS:
     .dw $ff02
     .db ".s"
     .dw VE_HEAD
     .set VE_HEAD = VE_DOTSS
XT_DOTSS:
     .dw DO_COLON
PFA_DOTSS:
     .dw XT_CR
     .dw XT_DEPTH, XT_1PLUS
     .dw XT_GREATERZERO
     .dw XT_DOCONDBRANCH
     .dw PFA_DOTSS0
; <old.s>
     .dw XT_SP_FETCH
     .dw XT_DEPTH
     .dw XT_1MINUS
     .dw XT_ZERO
     .dw XT_DOQDO
     .dw PFA_DOTSS2
PFA_DOTSS1:
     .dw XT_SLITERAL
     .dw 2
     .db "[]"
     .dw XT_ITYPE
     .dw XT_DUP
     .dw XT_I
     .dw XT_DUP
     .dw XT_UDOT     ; index of cell
     .dw XT_2STAR
     .dw XT_PLUS
     .dw XT_DUP
     .dw XT_DOLITERAL
     .dw 4
     .dw XT_UZERODOTR     ; address of cell
     .dw XT_DOLITERAL
     .dw 0x3A
     .dw XT_EMIT, XT_SPACE
     .dw XT_FETCH
     .dw XT_UDOT     ; content of cell
     .dw XT_CR
     .dw XT_DOLOOP
     .dw PFA_DOTSS1
PFA_DOTSS2:
     .dw XT_DROP
     .dw XT_EXIT
; </old.s>
PFA_DOTSS0:
     .dw XT_SLITERAL
     .dw 3
     .db "suf",0
     .dw XT_ITYPE
     .dw XT_EXIT



Am 03.03.2013 um 13:17 schrieb Erich Waelde:

> Michael,
>
> On 03/03/2013 01:00 AM, Michael Kalus wrote:
>
>> Here is the old form for your collection. It is "Stack UnderFlow"
>> save, telling "SUF" if you do one.
>> Maybe you have it already. Michael
>>
>>
>> -------------- next part --------------
>
> If you, too, want me to look at your code, you better
> add it to the message text. At least I do not see
> an attachment.
>
> Erich
>
> ---------------------------------------------------------------------- 
> --------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel