amforth-devel — Development discussion and user support

Re: [Amforth] Waking up a dormant forum :-)

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

Hello Matthias,

Ok, I think that we can sum up the manifesto concerning standard words
implementation as follows:

* Prefer AVR assembly language if the speed improvement is significant
  while code bloating is insignificant.

* VM assembly language is ugly (.dw FETCH vs. @) thus, whenever
  possible, define new words in Forth and leave VM coding for the
  compiler to do.

Now let's roll up our sleeves :-)

Regards, Enoch.


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

> Hi Enoch,
>
>> Can somebody give me good reasons why we should not convert
>> words/*.asm implementations (as much as possible) from VM assembly
>> to AVR assembly.
>
> I should do so, perhaps ;)
>
>>
>> For example:
>
> A well chosen one, indeed.
>
>> There are two good reasons to prefer the AVR implementation:
>>
>> 1. Speed (10x faster?)
>
> Speed is always an argument. Size too. And maintainability.
> And the indisputable fact that forth makes more fun than
> assembler.
>
>> 2. Ease of debugging through the Studio.
>
> I used the AVR Studio years ago when I started
> with the inner core of amforth. Since it worked
> (around version 0.1) I never used it again.
>
>> Comments? [flames :-)]
>
> You example patch is welcome, it is indeed an
> improvement in both size and speed. Thanks for it;
> the current code is an artefact from the times
> I thought an 3 byte cell size is worth doing.
>
> In general I'd like to see as much as possible
> code written in forth. Most of the "VM" code
> solves the chicken-and-egg problem, I should
> remove what's not needed for that purpose and
> put it into the lib/ directory tree. But I
> already hear the screams, that this stripped
> system will be too difficult to use.
>
> I found it interesting that quite a lot of
> forth code examples need less space than the
> respective assembly code. Trivialities excluded.
>
> Matthias
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j

Re: [Amforth] Waking up a dormant forum :-)

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

Hi.



Am 08.06.2013 um 02:37 schrieb Enoch:

> "Michael Kalus" <mi-...@t-...>
> writes:
>
>> Hi.
>>
>>> ..but not sacrifying compactness
>>
>> Here is what you can do with NO vm kernel word at all:
>>   http://mecrisp.sourceforge.net/
>> ..standalone native code Forth for MSP430 microcontroller chips...
>> ..It fits tightly into 9kb of Flash and runs with 512 Bytes of Ram...
>>
>> By the way, its free. Use whatever routine you like, a great pit.
>> A good job Matthias did there - no not Trute, is Koch this time. :-)
>>
>> Good luck!
>> Michael
>>
>
> Hello Michael,
>
> Not again what's the best 8 bit micro :-) I chose the AVR a couple of
> years ago for its better open source C support. Now we are here at
> AmForth to make its Forth variant the best around too!

Mecrisp is just an example that it can be done, and it could be done  
on AVR as well I guess.


> And our Matthias is doing great job and he has demonstratd being  
> open to
> criticism too!

Thats true, without doubt.

> We still have to convince him though what's the correct
> stack order .s ;-)

Which is without doubt too. ;-)

Michael




>
> Cheers, Enoch.
>
>>
>>
>>
>>
>>
>>
>>
>>
>> Am 07.06.2013 um 10:11 schrieb Rafael Gonzalez:
>>
>>> One of the criteria that you should use is that the pure assembly
>>> implementation should not exceed
>>> in size to the VM assembly implementation +10% (let's give a
>>> margin, ok?)
>>> Speed, yes but not sacrifying compactness
>>> Rafael
>>>
>>>
>>> ________________________________
>>>  De: Enoch <ix...@ho...>
>>> Para: amf...@li...
>>> Enviado: Jueves 6 de junio de 2013 21:37
>>> Asunto: [Amforth] Waking up a dormant forum :-)
>>>
>>>
>>> Hello AmForth-ers,
>>>
>>> Can somebody give me good reasons why we should not convert words/
>>> *.asm
>>> implementations (as much as possible) from VM assembly to AVR
>>> assembly.
>>>
>>> For example:
>>>
>>> ; ( a-addr1 -- a-addr2 )
>>> ; Arithmetics
>>> ; add the size of an address-unit to a-addr1
>>> VE_CELLPLUS:
>>>     .dw $ff05
>>>     .db "cell+",0
>>>     .dw VE_HEAD
>>>     .set VE_HEAD = VE_CELLPLUS
>>>
>>> Current implementation:
>>> =======================
>>>
>>> XT_CELLPLUS:
>>>     .dw DO_COLON
>>> PFA_CELLPLUS:
>>> .if CELLSIZE == 2 ;
>>>     .dw XT_1PLUS
>>>     .dw XT_1PLUS
>>> .else
>>>     .dw XT_DOLITERAL
>>>     .dw CELLSIZE
>>>     .dw XT_PLUS
>>> .endif
>>>     .dw XT_EXIT
>>>
>>>
>>> Suggested implementation:
>>> =========================
>>>
>>> XT_CELLPLUS: .dw pc + 1
>>>   adiw tosl, CELLSIZE
>>>   jmp_ DO_NEXT
>>>
>>>
>>> There are two good reasons to prefer the AVR implementation:
>>>
>>> 1. Speed (10x faster?)
>>> 2. Ease of debugging through the Studio.
>>>
>>> Comments? [flames :-)]
>>>
>>> Thanks, Enoch.
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> --------
>>> How ServiceNow helps IT people transform IT departments:
>>> 1. A cloud service to automate IT design, transition and operations
>>> 2. Dashboards that offer high-level views of enterprise services
>>> 3. A single system of record for all IT processes
>>> http://p.sf.net/sfu/servicenow-d2d-j
>>> _______________________________________________
>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>> -------------------------------------------------------------------- 
>>> --
>>> --------
>>> How ServiceNow helps IT people transform IT departments:
>>> 1. A cloud service to automate IT design, transition and operations
>>> 2. Dashboards that offer high-level views of enterprise services
>>> 3. A single system of record for all IT processes
>>> http://p.sf.net/sfu/servicenow-d2d-j
>>> _______________________________________________
>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>>
>> --------------------------------------------------------------------- 
>> ---------
>> How ServiceNow helps IT people transform IT departments:
>> 1. A cloud service to automate IT design, transition and operations
>> 2. Dashboards that offer high-level views of enterprise services
>> 3. A single system of record for all IT processes
>> http://p.sf.net/sfu/servicenow-d2d-j
>
>
> ---------------------------------------------------------------------- 
> --------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Waking up a dormant forum :-)

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

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

> Hi.
>
>> ..but not sacrifying compactness
>
> Here is what you can do with NO vm kernel word at all:
>   http://mecrisp.sourceforge.net/
> ..standalone native code Forth for MSP430 microcontroller chips...
> ..It fits tightly into 9kb of Flash and runs with 512 Bytes of Ram...
>
> By the way, its free. Use whatever routine you like, a great pit.
> A good job Matthias did there - no not Trute, is Koch this time. :-)
>
> Good luck!
> Michael
>

Hello Michael,

Not again what's the best 8 bit micro :-) I chose the AVR a couple of
years ago for its better open source C support. Now we are here at
AmForth to make its Forth variant the best around too!

And our Matthias is doing great job and he has demonstratd being open to
criticism too! We still have to convince him though what's the correct
stack order .s ;-)

Cheers, Enoch.

>
>
>
>
>
>
>
>
> Am 07.06.2013 um 10:11 schrieb Rafael Gonzalez:
>
>> One of the criteria that you should use is that the pure assembly  
>> implementation should not exceed
>> in size to the VM assembly implementation +10% (let's give a  
>> margin, ok?)
>> Speed, yes but not sacrifying compactness
>> Rafael
>>
>>
>> ________________________________
>>  De: Enoch <ix...@ho...>
>> Para: amf...@li...
>> Enviado: Jueves 6 de junio de 2013 21:37
>> Asunto: [Amforth] Waking up a dormant forum :-)
>>
>>
>> Hello AmForth-ers,
>>
>> Can somebody give me good reasons why we should not convert words/ 
>> *.asm
>> implementations (as much as possible) from VM assembly to AVR
>> assembly.
>>
>> For example:
>>
>> ; ( a-addr1 -- a-addr2 )
>> ; Arithmetics
>> ; add the size of an address-unit to a-addr1
>> VE_CELLPLUS:
>>     .dw $ff05
>>     .db "cell+",0
>>     .dw VE_HEAD
>>     .set VE_HEAD = VE_CELLPLUS
>>
>> Current implementation:
>> =======================
>>
>> XT_CELLPLUS:
>>     .dw DO_COLON
>> PFA_CELLPLUS:
>> .if CELLSIZE == 2 ;
>>     .dw XT_1PLUS
>>     .dw XT_1PLUS
>> .else
>>     .dw XT_DOLITERAL
>>     .dw CELLSIZE
>>     .dw XT_PLUS
>> .endif
>>     .dw XT_EXIT
>>
>>
>> Suggested implementation:
>> =========================
>>
>> XT_CELLPLUS: .dw pc + 1
>>   adiw tosl, CELLSIZE
>>   jmp_ DO_NEXT
>>
>>
>> There are two good reasons to prefer the AVR implementation:
>>
>> 1. Speed (10x faster?)
>> 2. Ease of debugging through the Studio.
>>
>> Comments? [flames :-)]
>>
>> Thanks, Enoch.
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------- 
>> --------
>> How ServiceNow helps IT people transform IT departments:
>> 1. A cloud service to automate IT design, transition and operations
>> 2. Dashboards that offer high-level views of enterprise services
>> 3. A single system of record for all IT processes
>> http://p.sf.net/sfu/servicenow-d2d-j
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> ---------------------------------------------------------------------- 
>> --------
>> How ServiceNow helps IT people transform IT departments:
>> 1. A cloud service to automate IT design, transition and operations
>> 2. Dashboards that offer high-level views of enterprise services
>> 3. A single system of record for all IT processes
>> http://p.sf.net/sfu/servicenow-d2d-j
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j

Re: [Amforth] Waking up a dormant forum :-)

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

Hi Enoch,

> Can somebody give me good reasons why we should not convert
> words/*.asm implementations (as much as possible) from VM assembly
> to AVR assembly.

I should do so, perhaps ;)

>
> For example:

A well chosen one, indeed.

> There are two good reasons to prefer the AVR implementation:
>
> 1. Speed (10x faster?)

Speed is always an argument. Size too. And maintainability.
And the indisputable fact that forth makes more fun than
assembler.

> 2. Ease of debugging through the Studio.

I used the AVR Studio years ago when I started
with the inner core of amforth. Since it worked
(around version 0.1) I never used it again.

> Comments? [flames :-)]

You example patch is welcome, it is indeed an
improvement in both size and speed. Thanks for it;
the current code is an artefact from the times
I thought an 3 byte cell size is worth doing.

In general I'd like to see as much as possible
code written in forth. Most of the "VM" code
solves the chicken-and-egg problem, I should
remove what's not needed for that purpose and
put it into the lib/ directory tree. But I
already hear the screams, that this stripped
system will be too difficult to use.

I found it interesting that quite a lot of
forth code examples need less space than the
respective assembly code. Trivialities excluded.

Matthias

Re: [Amforth] Waking up a dormant forum :-)

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

Hi.

> ..but not sacrifying compactness

Here is what you can do with NO vm kernel word at all:
  http://mecrisp.sourceforge.net/
..standalone native code Forth for MSP430 microcontroller chips...
..It fits tightly into 9kb of Flash and runs with 512 Bytes of Ram...

By the way, its free. Use whatever routine you like, a great pit.
A good job Matthias did there - no not Trute, is Koch this time. :-)

Good luck!
Michael









Am 07.06.2013 um 10:11 schrieb Rafael Gonzalez:

> One of the criteria that you should use is that the pure assembly  
> implementation should not exceed
> in size to the VM assembly implementation +10% (let's give a  
> margin, ok?)
> Speed, yes but not sacrifying compactness
> Rafael
>
>
> ________________________________
>  De: Enoch <ix...@ho...>
> Para: amf...@li...
> Enviado: Jueves 6 de junio de 2013 21:37
> Asunto: [Amforth] Waking up a dormant forum :-)
>
>
> Hello AmForth-ers,
>
> Can somebody give me good reasons why we should not convert words/ 
> *.asm
> implementations (as much as possible) from VM assembly to AVR
> assembly.
>
> For example:
>
> ; ( a-addr1 -- a-addr2 )
> ; Arithmetics
> ; add the size of an address-unit to a-addr1
> VE_CELLPLUS:
>     .dw $ff05
>     .db "cell+",0
>     .dw VE_HEAD
>     .set VE_HEAD = VE_CELLPLUS
>
> Current implementation:
> =======================
>
> XT_CELLPLUS:
>     .dw DO_COLON
> PFA_CELLPLUS:
> .if CELLSIZE == 2 ;
>     .dw XT_1PLUS
>     .dw XT_1PLUS
> .else
>     .dw XT_DOLITERAL
>     .dw CELLSIZE
>     .dw XT_PLUS
> .endif
>     .dw XT_EXIT
>
>
> Suggested implementation:
> =========================
>
> XT_CELLPLUS: .dw pc + 1
>   adiw tosl, CELLSIZE
>   jmp_ DO_NEXT
>
>
> There are two good reasons to prefer the AVR implementation:
>
> 1. Speed (10x faster?)
> 2. Ease of debugging through the Studio.
>
> Comments? [flames :-)]
>
> Thanks, Enoch.
>
>
>
>
>
> ---------------------------------------------------------------------- 
> --------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> ---------------------------------------------------------------------- 
> --------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Waking up a dormant forum :-)

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

One of the criteria that you should use is that the pure assembly implementation should not exceed 
in size to the VM assembly implementation +10% (let's give a margin, ok?)
Speed, yes but not sacrifying compactness
Rafael


________________________________
 De: Enoch <ix...@ho...>
Para: amf...@li... 
Enviado: Jueves 6 de junio de 2013 21:37
Asunto: [Amforth] Waking up a dormant forum :-)
 

Hello AmForth-ers,

Can somebody give me good reasons why we should not convert words/*.asm
implementations (as much as possible) from VM assembly to AVR
assembly. 

For example:

; ( a-addr1 -- a-addr2 ) 
; Arithmetics
; add the size of an address-unit to a-addr1
VE_CELLPLUS:
    .dw $ff05
    .db "cell+",0
    .dw VE_HEAD
    .set VE_HEAD = VE_CELLPLUS

Current implementation:
=======================

XT_CELLPLUS:
    .dw DO_COLON
PFA_CELLPLUS:
.if CELLSIZE == 2 ;
    .dw XT_1PLUS
    .dw XT_1PLUS
.else
    .dw XT_DOLITERAL
    .dw CELLSIZE
    .dw XT_PLUS
.endif
    .dw XT_EXIT


Suggested implementation:
=========================

XT_CELLPLUS: .dw pc + 1
  adiw tosl, CELLSIZE
  jmp_ DO_NEXT


There are two good reasons to prefer the AVR implementation:

1. Speed (10x faster?)
2. Ease of debugging through the Studio.

Comments? [flames :-)]

Thanks, Enoch.





------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Waking up a dormant forum :-)

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

Hello AmForth-ers,

Can somebody give me good reasons why we should not convert words/*.asm
implementations (as much as possible) from VM assembly to AVR
assembly. 

For example:

; ( a-addr1 -- a-addr2 ) 
; Arithmetics
; add the size of an address-unit to a-addr1
VE_CELLPLUS:
    .dw $ff05
    .db "cell+",0
    .dw VE_HEAD
    .set VE_HEAD = VE_CELLPLUS

Current implementation:
=======================

XT_CELLPLUS:
    .dw DO_COLON
PFA_CELLPLUS:
.if CELLSIZE == 2 ;
    .dw XT_1PLUS
    .dw XT_1PLUS
.else
    .dw XT_DOLITERAL
    .dw CELLSIZE
    .dw XT_PLUS
.endif
    .dw XT_EXIT


Suggested implementation:
=========================

XT_CELLPLUS: .dw pc + 1
  adiw tosl, CELLSIZE
  jmp_ DO_NEXT


There are two good reasons to prefer the AVR implementation:

1. Speed (10x faster?)
2. Ease of debugging through the Studio.

Comments? [flames :-)]

Thanks, Enoch.

Re: [Amforth] MARKER fixed

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

Hello Matthias,

Matthias Trute <mt...@we...> writes:
> I think that reparing marker this way is only half of the
> story. IMHO marker became unmaintainable (at least
> for me) so I changed it completely following the idea
> from Michael: keep the whole EEPROM instead of
> a structured dump of it. The eeprom content got slightly
> re-arranged to bundle the to-be-saved data at the 
> beginning and a value is used to determine the amount
> of this data: (marker)

I would like to note that Michael's approach of backing up "everything"
goes beyond the requirement of the current standard:

------------------------------------------------------------------------
6.2.1850 MARKER
Restore all dictionary allocation and search order pointers to the state
they had just prior to the definition of name. Remove the definition of
name and all subsequent definitions.  Restoration of any structures
still existing that could refer to deleted definitions or deal- located
data space is not necessarily provided.
------------------------------------------------------------------------

Thus, I am conflictied in accepting the new implementation. Need to give
it further thought.

>> See: http://pastebin.com/iWp7MRmv
>> 
>> Here's the new REVERSE word for those objecting to pastebins :-)
>
> You yourself fell into that trap as well, IIRC ;) Thanks for using email

Well, an important forum member expressed a strong dislike to using
"perishable" pastebins. I certainly wanted to please him ;-)

> for this definition. I do not yet understand it, but I'm sure it will work ;)

REVERSE ( X1 .. Xn n -- Xn .. X1 n ) is bound to see good use beyond
that original MARKER bug-fix. Collecting data into the stack inherently
reverses its order... hence, this new and efficient REVERSE
implementation can come handy.

Understanding REVERSE requires some kernel knowledge (specifically, how
the data stack is constructed). There's nothing wrong in that -- we do
here AmForth programming, not Forth stuff for the academia :-)

Regards, Enoch.

Re: [Amforth] amforth-shell.py, a small new feature

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

Hi Enoch,

> Hello AmForth-ers,
> 
> May I suggest the following humble patch to the fabulous shell.

applied. Thanks
Matthias

Re: [Amforth] MARKER fixed

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

Hi Enoch,

> Hello Matthias & All:
> 
> MARKER was restoring word-lists in the reverse order.

Sorry for that. 

> Fixed via a new
> REVERSE word which is expected to be useful on its own.

Indeed. See below.

I think that reparing marker this way is only half of the
story. IMHO marker became unmaintainable (at least
for me) so I changed it completely following the idea
from Michael: keep the whole EEPROM instead of
a structured dump of it. The eeprom content got slightly
re-arranged to bundle the to-be-saved data at the 
beginning and a value is used to determine the amount
of this data: (marker)

> 
> See: http://pastebin.com/iWp7MRmv
> 
> Here's the new REVERSE word for those objecting to pastebins :-)

You yourself fell into that trap as well, IIRC ;) Thanks for using email
for this definition. I do not yet understand it, but I'm sure it will work ;)

Matthias

[Amforth] amforth-shell.py, a small new feature

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

Hello AmForth-ers,

May I suggest the following humble patch to the fabulous shell.

Adds --log argument to the shell invocation line to collect the
"distilled" Forth lines that were uploaded to the microcontroller
system.

http://pastebin.com/pgeZRjGH

Regards, Enoch.

[Amforth] MARKER fixed

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

Hello Matthias & All:

MARKER was restoring word-lists in the reverse order. Fixed via a new
REVERSE word which is expected to be useful on its own.

See: http://pastebin.com/iWp7MRmv

Here's the new REVERSE word for those objecting to pastebins :-)

\ ( X1 .. Xn n -- Xn .. X1 n )
: reverse
   >r
   sp@ sp@ r@ cells +			\ ( bot-addr top-addr )
   begin
      over over <			\ bot top cross each other?
   while				\ no
      dup @ >r				\ save top-cell content
      over @ over !			\ replace top-cell
      over r> swap !			\ replace bot-cell
      cell- swap cell+ swap
   repeat
   2drop
   r>
;

Regards, Enoch.

Re: [Amforth] MARKER

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

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

> Hi Enoch.
>
> Here it is. I have no idea if it works with current amforth.
> Some hints which amforth words have changed in versions >3.6 are  
> given in the srouce, there may be more since.
>
> I factored ,EE to copy eeprom to flash and POPEE to out it back to  
> eeprom - not that elegant notation.
>
> ; : ,ee ( -- )
> ;   here , heap , edp ,  edp 8 do i e@ ,  2 +loop ;
> ; : popee ( adr n -- )
> ;    0 do dup i + i@  i 2* 2 + e! loop drop ;
> ; : marker ( -- )
> ;   edp >r here >r
> ;   ,ee create r> , r> ,
> ;   does> >r r@ i@ r> 1+ i@ popee ;
>
>
> Regards, Michael
>

Thanks Michael,

I'll be visting MARKER pretty soon. A reliable one is an absolute
necessity for field code replacement.

Regards, Enoch.

Re: [Amforth] MARKER

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

Hi Enoch.

Here it is. I have no idea if it works with current amforth.
Some hints which amforth words have changed in versions >3.6 are  
given in the srouce, there may be more since.

I factored ,EE to copy eeprom to flash and POPEE to out it back to  
eeprom - not that elegant notation.

; : ,ee ( -- )
;   here , heap , edp ,  edp 8 do i e@ ,  2 +loop ;
; : popee ( adr n -- )
;    0 do dup i + i@  i 2* 2 + e! loop drop ;
; : marker ( -- )
;   edp >r here >r
;   ,ee create r> , r> ,
;   does> >r r@ i@ r> 1+ i@ popee ;


Regards, Michael


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





Am 05.05.2013 um 09:23 schrieb Enoch:

> Hello Michael Kalus,
>
> IIRC Matthias mentioned that you have once written a MARKER version  
> that
> backs up the entire EEPROM to the Flash memory.
> IMHO that's the correct
> approach. Can you post this code again. On GMANE I found a broken
> dropbox link from 2010.
>
> If I have to write from scratch all MARKER words would be on a  
> wordlist of
> their own. The first MARKER should be produced during compile of the
> kernel. The following MARKERs would be successive deltas...
>
> Thanks, Enoch.
>
>
> ---------------------------------------------------------------------- 
> --------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] MARKER

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

Hello Michael Kalus,

IIRC Matthias mentioned that you have once written a MARKER version that
backs up the entire EEPROM to the Flash memory. IMHO that's the correct
approach. Can you post this code again. On GMANE I found a broken
dropbox link from 2010.

If I have to write from scratch all MARKER words would be on a wordlist of
their own. The first MARKER should be produced during compile of the
kernel. The following MARKERs would be successive deltas...

Thanks, Enoch.

Re: [Amforth] arduino mega256

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

hi,

> I was asked to put amforth on an arduino mega 256 as
> well. I suspect the file mega128 does not fit.
> What changes would be needed to create a mega256.asm file?
> Anyone has this done already?

Start with ...releases/5.1/appl/atmega2561

The 256x devices are somewhat special, they need
a few small modifications (all are in the above directory,
no need to change anything else)

Matthias
PS: German speakers (or better readers) may look at a VD somewhere at
www.forth-ev.de, I've written a small article for the 256x series
a year or two ago about what makes them special and how I
got amforth on them.

Re: [Amforth] arduino leonardo

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

Hi,

> I got an arduino leonardo and was asked to flash
> amforth onto this device.
> 
> I set up a copy of ...amforth/releases/5.1/appl/arduino.
> I can successfully build and flash a duemilanove and
> an uno. Not so successful for the leonardo:
> 
> bash> make leonardo.hex
> Producing Hexfiles for Arduino leonardo
> /home/ew/Forth/amforth/releases/5.1/core\amforth.asm(21): error:
> *** Flash size exceeded, please edit your dict_appl_core file to
> use less space! Aborting.

Cannot reproduce

~/Projekte/amforth.svn/releases/5.1/appl/arduino$ ant leonardo.hex
Unable to locate tools.jar. Expected to find it in /usr/lib/jvm/java-7-
openjdk-amd64/lib/tools.jar
Buildfile: /home/mt/Projekte/amforth.svn/releases/5.1/appl/arduino/build.xml

leonardo.hex:
     [echo] Producing Hexfiles for atmega32u4

BUILD SUCCESSFUL
Total time: 13 seconds
~/Projekte/amforth.svn/releases/5.1/appl/arduino$ 

Note that avrdude is not capable to program the EEPROM properly.
You'll need a small patch for the avrdude.conf 
(http://savannah.nongnu.org/bugs/?36901)

2nd Note: The usart used for the command terminal is a real one (labeled RX1 
and TX1 on the board), not some USB virtual comport.

Matthias

Re: [Amforth] arduino leonardo

[Jan K. <kro...@ho...>]

Dear Erich,
 
Is it posible to get the ready files to flash into my arduino?
Have a lot of trouble to get is assembled.
 
Cheers,
 
Jan Kromhout
Hellevoetsluis-NL
 
 

> Date: Wed, 1 May 2013 22:19:49 +0200
> From: ew....@na...
> To: amf...@li...
> Subject: [Amforth] arduino leonardo
> 
> Hello,
> 
> I got an arduino leonardo and was asked to flash
> amforth onto this device.
> 
> I set up a copy of ...amforth/releases/5.1/appl/arduino.
> I can successfully build and flash a duemilanove and
> an uno. Not so successful for the leonardo:
> 
> bash> make leonardo.hex
> Producing Hexfiles for Arduino leonardo
> /home/ew/Forth/amforth/releases/5.1/core\amforth.asm(21): error: 
> *** Flash size exceeded, please edit your dict_appl_core file to 
> use less space! Aborting.
> 
> Assembly failed, 1 errors, 6 warnings
> make: *** [leonardo.hex] Error 1
> 
> 
> I tried to move stuff around, but to no avail.
> Anyone had more luck with this? Fuse settings?
> Any pointers are welcome.
> 
> 
> Cheers,
> Erich
> 
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
 		 	   		  

[Amforth] arduino leonardo

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

Hello,

I got an arduino leonardo and was asked to flash
amforth onto this device.

I set up a copy of ...amforth/releases/5.1/appl/arduino.
I can successfully build and flash a duemilanove and
an uno. Not so successful for the leonardo:

bash> make leonardo.hex
Producing Hexfiles for Arduino leonardo
/home/ew/Forth/amforth/releases/5.1/core\amforth.asm(21): error: 
*** Flash size exceeded, please edit your dict_appl_core file to 
use less space! Aborting.

Assembly failed, 1 errors, 6 warnings
make: *** [leonardo.hex] Error 1


I tried to move stuff around, but to no avail.
Anyone had more luck with this? Fuse settings?
Any pointers are welcome.


Cheers,
Erich

[Amforth] arduino mega256

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

Hello,

I was asked to put amforth on an arduino mega 256 as
well. I suspect the file mega128 does not fit.
What changes would be needed to create a mega256.asm file?
Anyone has this done already?

Cheers,
Erich

Re: [Amforth] amforth-shell.py bugfix

[Keith A. <ca...@pi...>]

{-- Thu, 25 Apr 2013 11:46:23 -0400: Enoch <ix...@ho...> wrote: --}

  Enoch> Your amforth-shell.py is designed for importing and that's a good
  Enoch> starting point. I am sure that we can copy ideas from the various python
  Enoch> development approaches under emacs to modify gforth.el. All that we need
  Enoch> is ... time :-)

Exactly.

  Enoch> Did you make any significant changes to gforth.el? All I did thus far is
  Enoch> just adding some keywords and change indentation to follow the
  Enoch> openfirmware style.

No, I haven't made any modifications yet.  I'd be interested in seeing
yours though.

  --- Keith

Re: [Amforth] Soft Interrupt Handlers

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

Hi,

> By the way, did you have an opportunity to look at MARKER? I think it
> does not preserve well wordlist order.

I havn't had the time to check this problem. Sorry.

> It's non-trivial code so just if
> you don't have time for this now I'll have a go at it myself.

Its probably a good idea to change MARKER more radically: Keep
the whole allocated EEPROM contents and restore it later. Michael
Kalus (IIRC) once (years ago) had this idea but I lost his code :(

Matthias

Re: [Amforth] amforth-shell.py bugfix

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

Keith Amidon <ca...@pi...> writes:

> {-- Tue, 23 Apr 2013 12:12:50 -0400: Enoch <ix...@ho...> wrote: --}
>
>   Enoch> Specialized IDEs are great but for me it's Emacs for
>   Enoch> everything. 
>
> It's emacs for everything for me as well.  Take a look at the mail user
> agent this email comes from...  ;-)
>
>   Enoch> I am using (a customized version of) gforth.el from the gforth
>   Enoch> project. As we are all dreaming now... I hope to see Gforth
>   Enoch> specifics replaced by AmForth specifics (sending code via
>   Enoch> serial I/O rather to an inferior Gforth process). Time to wake
>   Enoch> up now :-)
>
> I did briefly look at modifying the forth-mode code from gforth to work
> with amforth using amforth-shell.py to manage the interaction.  In
> principle it shouldn't be terribly difficult to do but forth-mode seemed
> fairly gforth specific and I didn't want to spend the time to try and
> abstract it in addition to writing another backend.  
>
> I haven't actually tried this but I think that a poor-man's version of
> emacs integration can be achieved by using shell-command-on-region, by
> default bound to "M-|", and the command "amforth-shell -p /dev/<tty>".
> This should send the region to amforth-shell as standard input which
> will be sent to the device.  The output will be in a buffer named
> "*Shell Command Output*" which you can review to make sure the upload
> was successful.

Hi Keith,

Your amforth-shell.py is designed for importing and that's a good
starting point. I am sure that we can copy ideas from the various python
development approaches under emacs to modify gforth.el. All that we need
is ... time :-)

Did you make any significant changes to gforth.el? All I did thus far is
just adding some keywords and change indentation to follow the
openfirmware style.

Regards, Enoch.

Re: [Amforth] amforth-shell.py bugfix

[Keith A. <ca...@pi...>]

{-- Tue, 23 Apr 2013 12:12:50 -0400: Enoch <ix...@ho...> wrote: --}

  Enoch> Specialized IDEs are great but for me it's Emacs for
  Enoch> everything. 

It's emacs for everything for me as well.  Take a look at the mail user
agent this email comes from...  ;-)

  Enoch> I am using (a customized version of) gforth.el from the gforth
  Enoch> project. As we are all dreaming now... I hope to see Gforth
  Enoch> specifics replaced by AmForth specifics (sending code via
  Enoch> serial I/O rather to an inferior Gforth process). Time to wake
  Enoch> up now :-)

I did briefly look at modifying the forth-mode code from gforth to work
with amforth using amforth-shell.py to manage the interaction.  In
principle it shouldn't be terribly difficult to do but forth-mode seemed
fairly gforth specific and I didn't want to spend the time to try and
abstract it in addition to writing another backend.  

I haven't actually tried this but I think that a poor-man's version of
emacs integration can be achieved by using shell-command-on-region, by
default bound to "M-|", and the command "amforth-shell -p /dev/<tty>".
This should send the region to amforth-shell as standard input which
will be sent to the device.  The output will be in a buffer named
"*Shell Command Output*" which you can review to make sure the upload
was successful.

        --- Keith

Re: [Amforth] amforth-shell.py bugfix

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

Hello Rafael,

Specialized IDEs are great but for me it's Emacs for everything. I am
using (a customized version of) gforth.el from the gforth project. As we
are all dreaming now... I hope to see Gforth specifics replaced by
AmForth specifics (sending code via serial I/O rather to an inferior
Gforth process). Time to wake up now :-)

Regards, Enoch.

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

> Other  interesting papers by the same author
> http://www.holonforth.com/holon/papers/ef89.htm
>
> http://www.holonforth.com/holon/papers/ef94.htm
>
> http://www.holonforth.com/holon/papers/ef95.htm
>
>
>
> ________________________________
>  De: Rafael Gonzalez <ast...@ya...>
> Para: Everything around amforth <amf...@li...> 
> Enviado: Martes 23 de abril de 2013 12:01
> Asunto: Re: [Amforth] amforth-shell.py bugfix
>  
>
>
> I think the python script is becoming more and more complex.
>
> Maybe it is the time to switch to an umbilical-like system.
>
> For that, a new tool is needed and HolonU may be what your are looking for.
> http://www.holonforth.com/new/holon.html
>
>
> Probably you can attach a communication backend to the target system
>
> See the tool history and use case using an old stlye Text User Inetrface in DOS
> http://www.holonforth.com/using.htm
>
>
> This is one of the developments that has impacted me most
>
> Greetings
> Rafael
>
>
>
> ________________________________
>  De: Matthias Trute <mt...@we...>
> Para: Everything around amforth <amf...@li...> 
> Enviado: Sábado 20 de abril de 2013 9:30
> Asunto: Re: [Amforth] amforth-shell.py bugfix
>  
>
> Hi Hannu,
>
>> Take words and see them all. Produce dot file and make callgraph or
>> wordgraph. Anyway to see what gets used where and in which order.
>
> Crazy. I think, a real forth interpreter with a modified code generator
> (like the debugger in amforth) would be easier to use than a python
> based heuristic parser that does not understand forth. Maybe gforth
> is a better place to start with.
>
> 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
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service 
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr