amforth-devel — Development discussion and user support

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

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

Enoch,

> I hope that I'm not nagging -- got more challenges for you if you don't
> object ;-)

You're welcome :)

Matthias

Re: [Amforth] Wish to FORGET

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

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

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

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

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

Re: [Amforth] Wish to FORGET

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

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).

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

[Amforth] Wish to FORGET

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

Hello Matthias & all,

Here's something beyond me in Amforth, please help:

I wrote a table driven CRC-8 routine for short messages using any
generating polynomial, see http://pastebin.com/1YtVdMeg
(I didn't like the slow approach of lib/hardware/1wire-crc8.frt).

The Flash look-up table, crc8tab, is created at compile time -- first
forming 256 PAD bytes and then packing them into 128 Flash words. DOES>
provides the run-time lookup convenience.

My question is simple:

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).

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?

Thanks, Enoch.

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

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

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

> Hi.
>
> Am 02.03.2013 um 21:27 schrieb Enoch:
>
>> : .s  ( -- )				\ stack picture listing order
>>     depth
>>     begin dup while dup pick . 1- repeat
>>     drop
>> ;
>
> Maybe you want to have that in assembler. mk

Hello Michael,

I believe that we should have things coded in asm only when there is a
distinct advantage to it. 

During development I annotate my code with numerous "stack pictures"
(aka program verification invariants) and some .s printouts
(tracepoints) to confirm. I didn't understand why I have to read those
printouts in reverse, but not any more :-)

Regards, Enoch.

>
>
> -------------- next part --------------
>
>
> ------------------------------------------------------------------------------
> 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] .S “dot-s”

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

Hi.

Am 02.03.2013 um 21:27 schrieb Enoch:

> : .s  ( -- )				\ stack picture listing order
>     depth
>     begin dup while dup pick . 1- repeat
>     drop
> ;

Maybe you want to have that in assembler. mk


-------------- next part --------------

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

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

Hi.
..
> Should I mention, that I collect good tools and ideas? ;)
>>

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 --------------

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

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

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

> Hi Enoch,
>
>> And if I have your ear :-)
>
> You'll (almost) always have it. ;)
>
>> I prefer (gforth): -1 -2 -3 .s <3> -1 -2 -3  ok
>> over (amforth): -1 -2 -3 .s 65533 65534 65535  ok
>> i.e., the regular numbers' format.
>
> Thats fine. Just remove the line in your application
> dict_appl.inc file and add your version of .S
>
> The reason why I use the u. instead of the "standard" .
> is simple: Just switch to HEX. There you have
> the same numbers that can be grepped in the LST and
> MAP files from the assembler and match the numbers
> in the DUMP output (mostly XT's and addresses).
> As I said: .s is a debugging aid for _my_ core
> development. I do not expect that it is unmodified
> useful for other purposes.
>
> Should I mention, that I collect good tools and ideas? ;)

As recommended, removed words/dot-s.asm from dict_appl.inc and added:

: .s  ( -- )				\ stack picture listing order
    depth
    begin dup while dup pick . 1- repeat
    drop
;

-1 -2 -3 .s
-1 -2 -3  ok

I hope that I'm not nagging -- got more challenges for you if you don't
object ;-)

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] .S “dot-s”

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

Hi Enoch,

> And if I have your ear :-)

You'll (almost) always have it. ;)

> I prefer (gforth): -1 -2 -3 .s <3> -1 -2 -3  ok
> over (amforth): -1 -2 -3 .s 65533 65534 65535  ok
> i.e., the regular numbers' format.

Thats fine. Just remove the line in your application
dict_appl.inc file and add your version of .S

The reason why I use the u. instead of the "standard" .
is simple: Just switch to HEX. There you have
the same numbers that can be grepped in the LST and
MAP files from the assembler and match the numbers
in the DUMP output (mostly XT's and addresses).
As I said: .s is a debugging aid for _my_ core
development. I do not expect that it is unmodified
useful for other purposes.

Should I mention, that I collect good tools and ideas? ;)

Matthias

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

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

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

> Hi Enoch,
>
>> 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:
>
> In which way: by adding the stack depth or the ordering?
>
>> 
>> 1 2 3 .s <3> 1 2 3  ok
>> 
>> While ours:
>> 
>>> 1 2 3 .s
>> 3 2 1  ok
>
> I agree that amforth's display looks confusing at the
> first glance. Expecting a but? yes: I read from left to right
> (as probably many others do too) and I expect the TOS to read
> first.
>
> Gforth's display confuses me. I always have to scan the entire
> line to get the information I want.
>
> Basically the built-in .s is a debugging aid for the
> core development. I use it rather often when I dig in
> internals. A more user friendly .s is better implemented
> as forth code, DEPTH and PICK are available (I think they
> are useful for that task).

Hello Matthias,

IMHO .s should follow Leo Brodie's "Stack Picture" comment convention
(Thinking Forth pg. 151) as we are so accustomed to it. As developers we
can reverse .s order in our mind but it is an unnecessary burden on our
slow brain (called "System 2" in Daniel Khaneman's book, Thinking, Fast
and Slow) which is supposed to be focusing on bugs.

And if I have your ear :-)
I prefer (gforth): -1 -2 -3 .s <3> -1 -2 -3  ok
over (amforth): -1 -2 -3 .s 65533 65534 65535  ok
i.e., the regular numbers' format.

Thanks, 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] .S “dot-s”

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

Hi Enoch,

> 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:

In which way: by adding the stack depth or the ordering?

> 
> 1 2 3 .s <3> 1 2 3  ok
> 
> While ours:
> 
>> 1 2 3 .s
> 3 2 1  ok

I agree that amforth's display looks confusing at the
first glance. Expecting a but? yes: I read from left to right
(as probably many others do too) and I expect the TOS to read
first.

Gforth's display confuses me. I always have to scan the entire
line to get the information I want.

Basically the built-in .s is a debugging aid for the
core development. I use it rather often when I dig in
internals. A more user friendly .s is better implemented
as forth code, DEPTH and PICK are available (I think they
are useful for that task).

Matthias

[Amforth] .S “dot-s”

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

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

Thanks, Enoch.

[Amforth] lib/forth200x/defined.frt

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

Hello Matthias & all,

[undefined] didn't work for me so I replaced it with the following
definition. I guess it's something with "immediate".

Thanks, Enoch.

svn diff lib/forth200x/defined.frt 
Index: lib/forth200x/defined.frt
===================================================================
--- lib/forth200x/defined.frt	(revision 1379)
+++ lib/forth200x/defined.frt	(working copy)
@@ -1,4 +1,2 @@
-
-\ from the proposal
-: [defined] parse-name find-name dup if swap drop then ; immediate
-: [undefined] [defined] 0= ; immediate
+: [defined] parse-name find-name if drop -1 else 0 then ; immediate
+: [undefined] parse-name find-name if drop 0 else -1 then ; immediate

Re: [Amforth] Development request

[Mikael N. <mik...@pp...>]

On Wed, 2013-02-27 at 22:01 +0100, Matthias Trute wrote:
> Mikael,
> 
> >> >From checking your code, I can imagine a few things that would break
> >> FF as well. ;)
> > I am interested to know what that could be.
> 
> In flashforth.asm I found the following lines
> 
>         rcall   DOLIT
>         .dw     dp_start
>         rcall   FETCH
>         rcall   TRUE_
>         call    EQUAL
>         call    ZEROSENSE
>         breq    WARM_3
>         rcall   EMPTY
> WARM_3:
> 
> I read them as "if dp_start is -1, call EMPTY, otherwise
> skip to WARM_3". This checks if the EEPROM got erased. Fine
> so far (a common error if you forgot to flash the eeprom
> hex file). But what if dp_start is something else?

The idea here is that the default eeprom contents is copied from flash.
The eeprom file contains just $FFFF for the turnkey to make sure that
this copy happens.
> 
> I did not analyze (or even tested) this, but an invalid
> turnkey action (e.g. assigning not an XT to turnkey) may be
> sufficient (dp_start seems to be the turnkey vector). Than
> you have no chance to recover the system automatically. (or
> you have some more lines of defence...)
If the turnkey vector is crashing the system, sooner or later the system
will restart (ctrl-o). The turnkey can then be disabled by sending ESC
to the serial port during the two first seconds of the startup. Then you
can give manually the EMPTY command to recover.

Automatic recovery was never the goal, just to have the possibility to
interrupt the system and set it to an initial state.

This is just makes working so much easier when you don't need to reflash
the chip.

> 
> > I guess it can break but remarkably seldom.
> 
> Well, seldom is a relative number ;)
> 
> You check for errors, that already happened or are
> possible. Its the same with security: You can do a lot
> of things but someone will break in nevertheless. That
> doesn't make your work bad, absolutly not!! I'm the one
> who is lazy and ignorant I put all the burden to the
> user ;)
You are following the Forth philosophy, the user is in full control.

mfg Mikael

Re: [Amforth] Development request

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

Mikael,

>> >From checking your code, I can imagine a few things that would break
>> FF as well. ;)
> I am interested to know what that could be.

In flashforth.asm I found the following lines

        rcall   DOLIT
        .dw     dp_start
        rcall   FETCH
        rcall   TRUE_
        call    EQUAL
        call    ZEROSENSE
        breq    WARM_3
        rcall   EMPTY
WARM_3:

I read them as "if dp_start is -1, call EMPTY, otherwise
skip to WARM_3". This checks if the EEPROM got erased. Fine
so far (a common error if you forgot to flash the eeprom
hex file). But what if dp_start is something else?

I did not analyze (or even tested) this, but an invalid
turnkey action (e.g. assigning not an XT to turnkey) may be
sufficient (dp_start seems to be the turnkey vector). Than
you have no chance to recover the system automatically. (or
you have some more lines of defence...)

> I guess it can break but remarkably seldom.

Well, seldom is a relative number ;)

You check for errors, that already happened or are
possible. Its the same with security: You can do a lot
of things but someone will break in nevertheless. That
doesn't make your work bad, absolutly not!! I'm the one
who is lazy and ignorant I put all the burden to the
user ;)

Matthias

Re: [Amforth] Development request

[Mikael N. <mik...@pp...>]

On Wed, 2013-02-27 at 19:59 +0100, Matthias Trute wrote:
> You drive me crazy ;)
Well it was not my intention :-;

> >From checking your code, I can imagine a few things that would break
> FF as well. ;)
I am interested to know what that could be.

I guess it can break but remarkably seldom. Everything related to the
startup is in write protected flash and the ram is initialized at
startup from flash so I cannot really imagine what can go wrong.
Usually when a chip starts misbehaving, it is some physical problem,
or the flash is bad and the chip needs to be replaced.

For instance, I had a very strange problem that after power-boot some
random EEPROM bytes were set to 0xff. It turned out that the PIC chip
had a minimum working voltage of 4 Volts, but the brown out reset
detection fuse was configured for 2.2 volts which is only valid for a
low voltage version of the chip.
 
mfg Mikael

Re: [Amforth] Address arithmetic

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

Hi,


> Amforth introduces the e-addr and f-addr concepts to match the AVR arch.
> 
> I think that it is worth mentioning that f-addr is word based and there
> is no subtype to it.
> 
> That is unlike the data space relationship (quoting forth-rc1 page 22):
> a-addr ⇒ c-addr ⇒ addr ⇒ u;

http://amforth.sourceforge.net/TG/refcard.html
has this information already. IMHO. (inspired by
Flashforth, btw).

Matthias

Re: [Amforth] where is "XT_DOTO" defined

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

Wis,

> Sorry, I can't find "XT_DOTO" (used in 'comma.asm') in any file named 'do.*'.
> 
> Where is it, please?

core/words/to.asm

(just expand your search file pattern ;) )

HTH
Matthias

[Amforth] where is "XT_DOTO" defined

[Macomson, W. <wis...@in...>]

Sorry, I can't find "XT_DOTO" (used in 'comma.asm') in any file named 'do.*'.

Where is it, please?

Thanks,

-wis 

Re: [Amforth] Development request

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

You drive me crazy ;)

> For your information, FlashForth has these robustness mechanisms built
> in.

One may find the new recipe "Unbreakable" worth studying.
http://amforth.sourceforge.net/TG/recipes/Unbreakable.html

Some information may be new, some are rather hidden. Some
ideas are from Michael (long ago) and some details still
need to be worked on. But that I will leave as an exercise
to the reader..

> The aim has been to make it so robust that a reflash should never be
> needed.
> 
> The Kernel is write protected, the memory allocation pointers in eeprom
> are initialized from write protected flash with the EMPTY command.
> 
> At boot time all dynamic data is first initialized from write protected
> flash.
> It is then up to the application to do whatever further initialization
> that is needed. That also includes setting up the application dependent
> IRQ vectors in ram. 

>From checking your code, I can imagine a few things that would break
FF as well. ;)

Matthias

[Amforth] Address arithmetic

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

Hello Matthias & all,

Just a quick doc comment. 

Amforth introduces the e-addr and f-addr concepts to match the AVR arch.

I think that it is worth mentioning that f-addr is word based and there
is no subtype to it.

That is unlike the data space relationship (quoting forth-rc1 page 22):
a-addr ⇒ c-addr ⇒ addr ⇒ u;

Thanks, Enoch.

Re: [Amforth] Development request

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

Mikael Nordman <mik...@pp...>
writes:

> Hi Enoch,
> For your information, FlashForth has these robustness mechanisms built
> in.
>
> The aim has been to make it so robust that a reflash should never be
> needed.
>
> The Kernel is write protected, the memory allocation pointers in eeprom
> are initialized from write protected flash with the EMPTY command.
>
> At boot time all dynamic data is first initialized from write protected
> flash.
> It is then up to the application to do whatever further initialization
> that is needed. That also includes setting up the application dependent
> IRQ vectors in ram. 
>
> MARKER is also supported. it restores flash, eeprom and ram allocation
> pointers. 
>
>
> BR Mikael
>
> http://flashforth.sourceforge.net

Thanks, I thought that your work was just Microchip centric.

Generally speaking, I prefer OSS development efforts to be merge-ing
rather than fork-ing :-)

Before selecting "Amforth" I tested the "avrforth" project which I found
quite dormant. Project development activity is one of the deciding
factors and Amforth, thanks to Matthias relentless work, gets very high
marks.

Sincerely, 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] Development request

[Mikael N. <mik...@pp...>]

Hi Enoch,
For your information, FlashForth has these robustness mechanisms built
in.

The aim has been to make it so robust that a reflash should never be
needed.

The Kernel is write protected, the memory allocation pointers in eeprom
are initialized from write protected flash with the EMPTY command.

At boot time all dynamic data is first initialized from write protected
flash.
It is then up to the application to do whatever further initialization
that is needed. That also includes setting up the application dependent
IRQ vectors in ram. 

MARKER is also supported. it restores flash, eeprom and ram allocation
pointers. 


BR Mikael

http://flashforth.sourceforge.net

Re: [Amforth] Need another mailing list to submit patches?

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

Hi, Enoch,

> Index: doc/source/refcard.rst

The refcard file is a generated file. I've dropped it from
the repository. (which makes it harder to generate the doc
however..).

The mailling list ist configured to strip all attachment.
That is an very useful setting, but makes live a little
harder indeed.

Matthias