amforth-devel — Development discussion and user support

[Amforth] Classic Forth quote...

[Young, R. S. <ras...@in...>]

All,

> "Yesterday I demonstrated Amforth to my friend. It took fifteen
> minutes to write 1-wire code and read temperature and put it on LCD.
> The solution was far from perfect but extremely good."

To summarize:

1. 15 minutes

2. Far from perfect (good, fast, cheap - pick any two)

3. Did exactly what it should.

That's forth to the core!

R.

Re: [Amforth] Future documentation ideas

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

Hi Hannu,

> Yesterday I demonstrated Amforth to my friend. It took fifteen
> minutes to write 1-wire code and read temperature and put it on LCD.
> The solution was far from perfect but extremely good. 

Sounds like a very good candidate for the cookbook / recipe
collection on the webpage. Can you please send me (directly) your
code and (perhaps) some more details (schematics or a
photo)?

> And about refcard... As it is made from tex file could it be possible
> to put index to pdf? all words listed in alphabetical order.

The tex-file itself is a generated one. I think the reference index
gets as big as the reference card itself..

> I would write myself but these are questions for me also and my isn't
> good enough to put in public.

As long as your code works, it is worth publishing. Trust me,
no-one is allowed to complain until he/she does a better job ;)


Matthias

[Amforth] Future documentation ideas

[Hannu V. <vu...@ms...>]

Hi!

I have been playing with Forth about six months. It all started with need to script one program and I went to ficl and got excited. I wanted run Forth on AVR and ended to amforth. So I can say I'm newbie still.

Yesterday I demonstrated Amforth to my friend. It took fifteen minutes to write 1-wire code and read temperature and put it on LCD. The solution was far from perfect but extremely good. It raised some questions and discussion.

Stuff that I think not so experienced people like to read is how to handle strings. To print in terminal and handle in memory. Like provide some small examples.

> samplestringtutorial
Who are you? user
How old are you? 25
Nice to meet you 25 year old user

Another topic is that EEPROM is covered just listing some words in refcard. How to make Evariable or something similar. Is that handled some special way?

And about refcard... As it is made from tex file could it be possible to put index to pdf? all words listed in alphabetical order.

These kind of ideas came to my mind after my meeting.

I would write myself but these are questions for me also and my isn't good enough to put in public.

Best regards,
Hannu Vuolasaho
 		 	   		  

Re: [Amforth] Compiling Amforth 4.9 - forward labels in macros

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

Hi Marcin,

>>> avrasm2 generally does not allow using not-yet-defind
>>> labels in macros like this.
>>
>> really? I doubt it.
> 
> To be correct: ifdef returns false for 
> forward references and therefore jmp is assembled
> by AVRASM2. 

And avra does not the same?

A quick test (placing the code of the inner interpreter as
the last code ever included) resulted in many jmp's, placing
it in front of the many primitives from dict_core.inc
gives many rjmp (as is should be).

Since the DOLOOP words are the only part of the code that
cause the trouble (to my surprise btw) I'll simply swap the
ordering in the dict_core file and make a note to myself to
never change that again ;) Rev 1273 work

Matthias

Re: [Amforth] Compiling Amforth 4.9 - forward labels in macros

[Marcin C. <sa...@sa...>]

>> Matthias Trute <mt...@we...> wrote:
> Hi,
>
>> avrasm2 generally does not allow using not-yet-defind
>> labels in macros like this.
>
> really? I doubt it.

To be correct: ifdef returns false for 
forward references and therefore jmp is assembled
by AVRASM2. 

>> 2) add a nop after "rjmp" in the "jmp_" macro to keep
>>    sizes of the macro expansion constant.
>
> That would contradict one of the 2 intentions of
> the macro: size savings (the other one is speed).

I agree, but...

> 3) get an smart jump instruction.

... how do solve the problem:

    jmp_ A:
    nop
    nop
A:  

The final address of A depends on the size
of jmp_ expansion, that may be 1 word
or 2 words. Size of the jmp_ expansion
depends on how for A is. Isn't that
a circular reference?

//Marcin

Re: [Amforth] Compiling Amforth 4.9 - forward labels in macros

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

Hello Marcin,
thanks for your reply.

On 08/18/2012 09:53 PM, Marcin Cieslak wrote:
> On Sat, 18 Aug 2012, Erich Waelde wrote:
>
>
>>> 1) revert to amforth 4.4 hardcoded "rjmp" since we can
>>>      assume the distance is pretty small here.
>>
>> I have included doplusloop.asm from amforth-4.4 into the build
>> from amforth-4.5, and verified the difference in source. Result:
>> amforth built with avrasm2 works, whereas
>> amforth built with avra fails to connect via serial interface.
>
> I think doplusloop.asm has "rjmp" in all recent versions.
> Can you try this "doloop.asm"?

Sure.
creating a 4.5 system, with the original order of
doloop doplusloop unloop in dict_core.inc
replacing words/doloop.asm with the file from amforth-4.4

diff -wu releases/4.{4,5}/core/words/doloop.asm
--- releases/4.4/core/words/doloop.asm	2011-05-24 
20:11:11.207999857 +0200
+++ releases/4.5/core/words/doloop.asm	2011-06-29 
20:04:52.754880362 +0200
@@ -17,4 +17,4 @@
      cp zl, temp2
      cpc zh, temp3
      breq PFA_DOPLUSLOOP1
-    rjmp PFA_DOPLUSLOOP3
+    jmp_ PFA_DOPLUSLOOP3

building amforth with avra creates a working system --- I can
talk to it on the serial prompt.  :-)

>
> I see that r1071 changed lots of jumps, but most
> of them (like DO_NEXT) should be fine - they are
> referring to the already-defined labels.
>
> ------------------------------------------------------------------------
> r1071 | mtrute | 2011-06-03 18:49:08 +0200 (Fri, 03 Jun 2011) | 1 line
>
> use the smart jump instruction everywhere
> ------------------------------------------------------------------------
>
> //Marcin

I'm not sure, what to make of the current state of information.
So I leave this to the experts.

Cheers,
Erich

Re: [Amforth] Compiling Amforth 4.9 - forward labels in macros

[Marcin C. <sa...@sa...>]

On Sat, 18 Aug 2012, Erich Waelde wrote:


> > 1) revert to amforth 4.4 hardcoded "rjmp" since we can
> >     assume the distance is pretty small here.
> 
> I have included doplusloop.asm from amforth-4.4 into the build
> from amforth-4.5, and verified the difference in source. Result:
> amforth built with avrasm2 works, whereas
> amforth built with avra fails to connect via serial interface.

I think doplusloop.asm has "rjmp" in all recent versions.
Can you try this "doloop.asm"?

I see that r1071 changed lots of jumps, but most
of them (like DO_NEXT) should be fine - they are
referring to the already-defined labels.

------------------------------------------------------------------------
r1071 | mtrute | 2011-06-03 18:49:08 +0200 (Fri, 03 Jun 2011) | 1 line

use the smart jump instruction everywhere
------------------------------------------------------------------------

//Marcin

Re: [Amforth] Compiling Amforth 4.9

[Hannu V. <vu...@ms...>]

Hi!

Sorry about long delay. I was out of net for a while.

Here are two files. They are the successing windows build from appl directory (my_forth.zip) and same thing from Linux and Avra (from_linux.tar.gz)

Hopefully these have some help making Amforth better.

Best regards,
Hannu Vuolasaho

----------------------------------------
> To: amf...@li...
> From: sa...@sa...
> Date: Fri, 10 Aug 2012 16:27:09 +0000
> Subject: Re: [Amforth] Compiling Amforth 4.9
>
> >> Hannu Vuolasaho <vu...@ms...> wrote:
> >
> > Sorry. Maybe I wasn't quite clear. Im building Amforth 4.9
> >
> >
> > $ avra --version
> > AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
> >
> > I think I'm getting on with this. problems with .overlap org errors required git version of Avra.
> >
> > http://permalink.gmane.org/gmane.comp.lang.forth.amforth/1047 instructed to add one .equ MCUSR = MCUCSR line.
> > bm_PARITY problem was solved changing order of serial setting and driver.
> >
> > I also had wrong appnotes :( After I copied from avrassembler2 appnotes, amfort compiled.
> >
> > However binary doesn't work :(
>
> Can you generate a list file (-l listfile) and also send me resulting .hex files?
>
> I would like also to try it here - what should I set up in my environment?
>
> Did you succeed using avrasm2? can you send me resulting hex files and the listfile
> as well?
>
> By the way: the newest git master from avra finally supports -o, -e and -d options
> to change the flash output, EEPROM, and debug file names. Finally!
>
> //Marcin
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
 		 	   		  

Re: [Amforth] Compiling Amforth 4.9 - forward labels in macros

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

Hello,

On 08/18/2012 10:12 AM, Matthias Trute wrote:

> Does the patch
>
> diff --git a/core/dict_core.inc b/core/dict_core.inc
> index b7ddeb1..d88f9f6 100644
> --- a/core/dict_core.inc
> +++ b/core/dict_core.inc
> @@ -74,8 +74,8 @@
>   .include "words/dodo.asm"
>   .include "words/doqdo.asm"
>   .include "words/i.asm"
> -.include "words/doloop.asm"
>   .include "words/doplusloop.asm"
> +.include "words/doloop.asm"
>   .include "words/unloop.asm"
>
>
> help?
Yes. avra is then producing a working system.
:-)

The same observation holds for amforth-4.9!


> Does the quick fix from workaround
> 1) give a working system?
No. see my other reply in thread.


If someone needs files, please speak up.

Cheers,
Erich

Re: [Amforth] Compiling Amforth 4.9 - forward labels in macros

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

Hello,

On 08/18/2012 04:10 AM, Marcin Cieslak wrote:
> On Fri, 17 Aug 2012, Erich Waelde wrote:
>> I have made tests
>> 1. compile avra from git
>> commit a6e8b2957953810dae6467eeb4905bfc5ea6c33e
>> Author: Marcin Cieslak<sa...@sa...>
>> Date:   Wed Aug 8 17:01:30 2012 +0200
>
<schnipp>


>
> Generated jump goes one word too far (it is "jump 5 words forward"
> and not "jump 4 words forward"). It can even be seen
> that the length of a macro expansion is wrongly estimated
> (it says the whole code is 7 words, while it is only 6).
>
> avrasm2 generally does not allow using not-yet-defind
> labels in macros like this.
>
> There are two forward jumps in the code of amforth:
>
> 1. There is no problem with "jmp_ PFA_COLD" since the
> distance to PFA_COLD does to depend on the size of the
> macro expanded.
>
> 2. Only "jmp_ PFA_DOPLUSLOOP3" is problematic since the label
> address depends on the size of the macro - and this can
> change .. depending on the target address of the label.
>
> Amforth 4.4 works because it had "rjmp PFA_DOPLUSLOOP3"
> hardcoded and not jmp_ macro.
>
>
> So there are two workarounds for amforth:
>
> 1) revert to amforth 4.4 hardcoded "rjmp" since we can
>     assume the distance is pretty small here.

I have included doplusloop.asm from amforth-4.4 into the build
from amforth-4.5, and verified the difference in source. Result:
amforth built with avrasm2 works, whereas
amforth built with avra fails to connect via serial interface.

So, while the above observation may still hold, it seems not to 
be the only problem.


Since I would really appreciate avra being able to build 
amforth, is there anything else I can do?


>
> 2) add a nop after "rjmp" in the "jmp_" macro to keep
>     sizes of the macro expansion constant.
>
>
> Solutions:
>
> 1) AVRA may disallow forward refences in the macros.
>
> 2) Detecting the impossibility to determine
>     the value.
>
> 3) ...
>
> //Marcin

Cheers,
Erich

Re: [Amforth] Compiling Amforth 4.9 - forward labels in macros

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

Hi,

> Generated jump goes one word too far (it is "jump 5 words forward"
> and not "jump 4 words forward"). It can even be seen
> that the length of a macro expansion is wrongly estimated
> (it says the whole code is 7 words, while it is only 6).
> 
> avrasm2 generally does not allow using not-yet-defind
> labels in macros like this.

really? I doubt it.

> 
> So there are two workarounds for amforth:
> 
> 1) revert to amforth 4.4 hardcoded "rjmp" since we can
>    assume the distance is pretty small here.
> 
> 2) add a nop after "rjmp" in the "jmp_" macro to keep
>    sizes of the macro expansion constant.

That would contradict one of the 2 intentions of
the macro: size savings (the other one is speed).

> 
> 
> Solutions:
> 
> 1) AVRA may disallow forward refences in the macros.
> 
> 2) Detecting the impossibility to determine
>    the value.
> 
> 3) ...

3) get an smart jump instruction.

I vote for 3) ;)

Does the patch

diff --git a/core/dict_core.inc b/core/dict_core.inc
index b7ddeb1..d88f9f6 100644
--- a/core/dict_core.inc
+++ b/core/dict_core.inc
@@ -74,8 +74,8 @@
 .include "words/dodo.asm"
 .include "words/doqdo.asm"
 .include "words/i.asm"
-.include "words/doloop.asm"
 .include "words/doplusloop.asm"
+.include "words/doloop.asm"
 .include "words/unloop.asm"


help? Does the quick fix from workaround
1) give a working system?


Matthias

Re: [Amforth] Compiling Amforth 4.9 - forward labels in macros

[Marcin C. <sa...@sa...>]

On Fri, 17 Aug 2012, Erich Waelde wrote:

> Hello Marcin,
> 
> I have made tests
> 1. compile avra from git
> commit a6e8b2957953810dae6467eeb4905bfc5ea6c33e
> Author: Marcin Cieslak <sa...@sa...>
> Date:   Wed Aug 8 17:01:30 2012 +0200

> Does this help?

Yes, thank you.

It seems the problem described in this thread:

http://thread.gmane.org/gmane.comp.lang.forth.amforth/1353/focus=1354

is related to calculation of forward referenced labels in a macro.


Consider the following code (correctly assembled):

                .device atmega32
          PFA_COLD:
C:000000 c004           rjmp    PFA_DOPLUSLOOP3
C:000001 0000           nop
C:000002 0000           nop
C:000003 0000           nop
C:000004 0000           nop
          PFA_DOPLUSLOOP3:      
C:000005 9508           ret
Used memory blocks:
   code      :  Start = 0x0000, End = 0x0005, Length = 0x0006 (6 words), Overlap=N


Segment usage:
   Code      :         6 words (12 bytes)
   Data      :         0 bytes
   EEPROM    :         0 bytes


But this:

                .device atmega32
                  .macro jmp_
                         ; a more flexible macro
                        .ifdef @0
                        .if (@0-pc > 2040) || (pc-@0>2040)
                          jmp @0
                          .else   
                          rjmp @0
                          .endif
                          .else
                          jmp @0
                          .endif
                  .endmacro
          PFA_COLD:
C:000000   +    jmp_    PFA_DOPLUSLOOP3
         

          .ifdef PFA_DOPLUSLOOP3
          .if (PFA_DOPLUSLOOP3-pc > 2040) || (pc-PFA_DOPLUSLOOP3>2040)
:000000 c005      rjmp PFA_DOPLUSLOOP3
          .endif
          .else
C:000001 0000           nop
C:000002 0000           nop
C:000003 0000           nop
C:000004 0000           nop
          PFA_DOPLUSLOOP3:      
C:000005 9508           ret
Used memory blocks:
   code      :  Start = 0x0000, End = 0x0006, Length = 0x0007 (7 words), Overlap=N


Segment usage:
   Code      :         7 words (14 bytes)
   Data      :         0 bytes
   EEPROM    :         0 bytes

Assembly completed with no errors.



Generated jump goes one word too far (it is "jump 5 words forward"
and not "jump 4 words forward"). It can even be seen
that the length of a macro expansion is wrongly estimated
(it says the whole code is 7 words, while it is only 6).

avrasm2 generally does not allow using not-yet-defind
labels in macros like this.

There are two forward jumps in the code of amforth:

1. There is no problem with "jmp_ PFA_COLD" since the 
distance to PFA_COLD does to depend on the size of the
macro expanded.

2. Only "jmp_ PFA_DOPLUSLOOP3" is problematic since the label 
address depends on the size of the macro - and this can
change .. depending on the target address of the label.

Amforth 4.4 works because it had "rjmp PFA_DOPLUSLOOP3"
hardcoded and not jmp_ macro.


So there are two workarounds for amforth:

1) revert to amforth 4.4 hardcoded "rjmp" since we can
   assume the distance is pretty small here.

2) add a nop after "rjmp" in the "jmp_" macro to keep
   sizes of the macro expansion constant.


Solutions:

1) AVRA may disallow forward refences in the macros.

2) Detecting the impossibility to determine
   the value.

3) ...

//Marcin

Re: [Amforth] Compiling Amforth 4.9

[Marcin C. <sa...@sa...>]

>> Hannu Vuolasaho <vu...@ms...> wrote:
>
> Sorry. Maybe I wasn't quite clear. Im building Amforth 4.9
>
>
> $ avra --version
> AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
>
> I think I'm getting on with this. problems with .overlap org errors required git version of Avra.
>
> http://permalink.gmane.org/gmane.comp.lang.forth.amforth/1047 instructed to add one .equ MCUSR = MCUCSR line.
> bm_PARITY problem was solved changing order of serial setting and driver.
>
> I also had wrong appnotes :( After I copied from avrassembler2 appnotes, amfort compiled. 
>
> However binary doesn't work :(

Can you generate a list file (-l listfile) and also send me resulting .hex files?

I would like also to try it here - what should I set up in my environment?

Did you succeed using avrasm2? can you send me resulting hex files and the listfile
as well?

By the way: the newest git master from avra finally supports -o, -e and -d options
to change the flash output, EEPROM, and debug file names. Finally!

//Marcin

Re: [Amforth] Compiling Amforth 4.9

[Hannu V. <vu...@ms...>]

Sorry. Maybe I wasn't quite clear. Im building Amforth 4.9


$ avra --version
AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)

I think I'm getting on with this. problems with .overlap org errors required git version of Avra.

http://permalink.gmane.org/gmane.comp.lang.forth.amforth/1047 instructed to add one .equ MCUSR = MCUCSR line.
bm_PARITY problem was solved changing order of serial setting and driver.

I also had wrong appnotes :( After I copied from avrassembler2 appnotes, amfort compiled. 

However binary doesn't work :(

Anyway I was able to compile and flash in AVRstudio.

With avra I still have these warnings:
../../core/words/brackettick.asm(6) : Warning : A .DB segment with an odd number of bytes is detected. A zero byte is added.
../../core/words/tick.asm(6) : Warning : A .DB segment with an odd number of bytes is detected. A zero byte is added.
done

To get everything working some investigation should be done. However ATmega128 is quite old controller and no-one uses it. (except me)

Best regards,
Hannu Vuolasaho

----------------------------------------
> Date: Thu, 2 Aug 2012 18:48:40 +0200
> From: ew....@na...
> To: amf...@li...
> Subject: Re: [Amforth] Compiling Amforth 4.9
>
> Hello Hannu,
>
> I just checked:
> + avra built from git:
> 21f54ca HEAD@{0}: pull : Fast-forward
> cf495f3 HEAD@{1}: clone: from
> git://avra.git.sourceforge.net/gitroot/avra/avra
>
> + I can compile amforth-4.2 for atmega32
> + I can compile amforth-4.5 for atmega32 as well
> I have not checked whether they actually work.
> + I can compile amforth-4.6 for atmega32 --- but it doesn't
> work! The same files compiled with wine+avrasm2 do work. I sort
> of remember, that avra failed on me before with amforth 4.6. I
> have never gotten around to find the commit in amforth, which
> made avra choke.
>
> So:
> a. what version of avra are you using? Maybe you have a long
> forgotten version from the git repo somewhere but not in PATH?
> b. Are you still using amforth 4.5? If so,
> c. can you still compile for the 328?
> Maybe this narrows down the possible causes. Hopefully someone
> else has more experience with the atmega128.
>
> Cheers,
> Erich
>
> On 08/02/2012 05:59 AM, Hannu Vuolasaho wrote:
>>
>> Hello everybody!
>>
>> I once compiled succesfully Amforth 4.5 and have been used it for a until last week. My MCU changed from ATMega 328 to ATMega128.
>>
>> Now I need to build Amforth for that and I can't get it done. I've copied from program files/Atmel/AVR Tools/avrAssembler/Appnotes to amforth's root as Atmel/Appnotes2 copied template to
>> my_project_amforth and chaged MCU and assembler from makefile. From template.asm I've changed the clockspeed to right.
>>
>> I'm getting this out of make:
>>
>> $ make
>> avra -I ../../Atmel/Appnotes2 -I ../../core -I ../../core/devices/atmega128 --listmac -l template.lst -m template.map template.asm
>> AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
>> Copyright (C) 1998-2010. Check out README file for more info
>>
>> AVRA is an open source assembler for Atmel AVR microcontroller family
>> It can be used as a replacement of 'AVRASM32.EXE' the original assembler
>> shipped with AVR Studio. We do not guarantee full compatibility for avra.
>>
>> AVRA comes with NO WARRANTY, to the extent permitted by law.
>> You may redistribute copies of avra under the terms
>> of the GNU General Public License.
>> For more information about these matters, see the files named COPYING.
>>
>> Pass 1...
>> ../../core/devices/atmega128/device.asm(52) : Error : Unknown directive: .OVERLAP
>> ../../core/devices/atmega128/device.asm(122) : Error : Unknown directive: .NOOVERLAP
>> template.asm(34) : Error : Found no label/variable/constant named bm_ASYNC
>> template.asm(38) : Error : Found no label/variable/constant named bm_ENABLE_TX
>> ../../core/words/cold.asm(12) : Error : [Macro: ../../core/macros.asm: 51:] Found no label/variable/constant named MCUSR
>> ../../core/words/cold.asm(16) : Error : [Macro: ../../core/macros.asm: 59:] Found no label/variable/constant named MCUSR
>> ../../core/amforth.asm(18) : Error : Found no label/variable/constant named NRWW_START_ADDR
>> ../../core/amforth-eeprom.inc(56) : Error : .BYTE directive can only be used in data segment (.DSEG)
>> Error: Overlapping Code-segments :
>> Start = 0x0004, End = 0x0004, Length = 0x0001
>> Start = 0x0004, End = 0x03C6, Length = 0x03C3
>> Please check your .ORG directives !
>> Error: Overlapping Code-segments :
>> Start = 0x0006, End = 0x0006, Length = 0x0001
>> Start = 0x0004, End = 0x03C6, Length = 0x03C3
>> Please check your .ORG directives !
>> Error: Overlapping Code-segments :
>> Start = 0x0008, End = 0x0008, Length = 0x0001
>> Start = 0x0004, End = 0x03C6, Length = 0x03C3
>> Please check your .ORG directives !
>> Error: Overlapping Code-segments :
>> Start = 0x000A, End = 0x000A, Length = 0x0001
>> Start = 0x0004, End = 0x03C6, Length = 0x03C3
>> Please check your .ORG directives !
>> <<SNIP>>
>> make: *** [template.hex] Error 1
>>
>> Now. What did I do wrong? Except been using Linux as desktop,,, I've tried to read amforth.pdf and follow those instructions but please someone point out my mistake.
>>
>> Best Regards,
>> Hannu Vuolasaho
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
 		 	   		  

Re: [Amforth] Compiling Amforth 4.9

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

Hello Hannu,

I just checked:
+ avra built from git:
   21f54ca HEAD@{0}: pull : Fast-forward
   cf495f3 HEAD@{1}: clone: from 
git://avra.git.sourceforge.net/gitroot/avra/avra

+ I can compile amforth-4.2 for atmega32
+ I can compile amforth-4.5 for atmega32 as well
I have not checked whether they actually work.
+ I can compile amforth-4.6 for atmega32 --- but it doesn't 
work! The same files compiled with wine+avrasm2 do work. I sort 
of remember, that avra failed on me before with amforth 4.6. I 
have never gotten around to find the commit in amforth, which 
made avra choke.

So:
a. what version of avra are you using? Maybe you have a long 
forgotten version from the git repo somewhere but not in PATH?
b. Are you still using amforth 4.5? If so,
c. can you still compile for the 328?
Maybe this narrows down the possible causes. Hopefully someone 
else has more experience with the atmega128.

Cheers,
Erich

On 08/02/2012 05:59 AM, Hannu Vuolasaho wrote:
>
> Hello everybody!
>
> I once compiled succesfully Amforth 4.5 and have been used it for a until last week. My MCU changed from ATMega 328 to ATMega128.
>
> Now I need to build Amforth for that and I can't get it done. I've copied from program files/Atmel/AVR Tools/avrAssembler/Appnotes to amforth's root as Atmel/Appnotes2 copied template to
>   my_project_amforth and chaged MCU and assembler from makefile. From template.asm I've changed the clockspeed to right.
>
> I'm getting this out of make:
>
> $ make
> avra -I ../../Atmel/Appnotes2 -I ../../core -I ../../core/devices/atmega128 --listmac -l template.lst -m template.map template.asm
> AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
> Copyright (C) 1998-2010. Check out README file for more info
>
>     AVRA is an open source assembler for Atmel AVR microcontroller family
>     It can be used as a replacement of 'AVRASM32.EXE' the original assembler
>     shipped with AVR Studio. We do not guarantee full compatibility for avra.
>
>     AVRA comes with NO WARRANTY, to the extent permitted by law.
>     You may redistribute copies of avra under the terms
>     of the GNU General Public License.
>     For more information about these matters, see the files named COPYING.
>
> Pass 1...
> ../../core/devices/atmega128/device.asm(52) : Error   : Unknown directive: .OVERLAP
> ../../core/devices/atmega128/device.asm(122) : Error   : Unknown directive: .NOOVERLAP
> template.asm(34) : Error   : Found no label/variable/constant named bm_ASYNC
> template.asm(38) : Error   : Found no label/variable/constant named bm_ENABLE_TX
> ../../core/words/cold.asm(12) : Error   : [Macro: ../../core/macros.asm: 51:] Found no label/variable/constant named MCUSR
> ../../core/words/cold.asm(16) : Error   : [Macro: ../../core/macros.asm: 59:] Found no label/variable/constant named MCUSR
> ../../core/amforth.asm(18) : Error   : Found no label/variable/constant named NRWW_START_ADDR
> ../../core/amforth-eeprom.inc(56) : Error   : .BYTE directive can only be used in data segment (.DSEG)
> Error: Overlapping Code-segments :
>    Start = 0x0004, End = 0x0004, Length = 0x0001
>    Start = 0x0004, End = 0x03C6, Length = 0x03C3
> Please check your .ORG directives !
> Error: Overlapping Code-segments :
>    Start = 0x0006, End = 0x0006, Length = 0x0001
>    Start = 0x0004, End = 0x03C6, Length = 0x03C3
> Please check your .ORG directives !
> Error: Overlapping Code-segments :
>    Start = 0x0008, End = 0x0008, Length = 0x0001
>    Start = 0x0004, End = 0x03C6, Length = 0x03C3
> Please check your .ORG directives !
> Error: Overlapping Code-segments :
>    Start = 0x000A, End = 0x000A, Length = 0x0001
>    Start = 0x0004, End = 0x03C6, Length = 0x03C3
> Please check your .ORG directives !
> <<SNIP>>
> make: *** [template.hex] Error 1
>
> Now. What did I do wrong? Except been using Linux as desktop,,, I've tried to read amforth.pdf and follow those instructions but please someone point out my mistake.
>
> Best Regards,
> Hannu Vuolasaho
>   		 	   		
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Compiling Amforth 4.9

[Hannu V. <vu...@ms...>]

Hello everybody!

I once compiled succesfully Amforth 4.5 and have been used it for a until last week. My MCU changed from ATMega 328 to ATMega128.

Now I need to build Amforth for that and I can't get it done. I've copied from program files/Atmel/AVR Tools/avrAssembler/Appnotes to amforth's root as Atmel/Appnotes2 copied template to
 my_project_amforth and chaged MCU and assembler from makefile. From template.asm I've changed the clockspeed to right.

I'm getting this out of make:

$ make
avra -I ../../Atmel/Appnotes2 -I ../../core -I ../../core/devices/atmega128 --listmac -l template.lst -m template.map template.asm
AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
Copyright (C) 1998-2010. Check out README file for more info

   AVRA is an open source assembler for Atmel AVR microcontroller family
   It can be used as a replacement of 'AVRASM32.EXE' the original assembler
   shipped with AVR Studio. We do not guarantee full compatibility for avra.

   AVRA comes with NO WARRANTY, to the extent permitted by law.
   You may redistribute copies of avra under the terms
   of the GNU General Public License.
   For more information about these matters, see the files named COPYING.

Pass 1...
../../core/devices/atmega128/device.asm(52) : Error   : Unknown directive: .OVERLAP
../../core/devices/atmega128/device.asm(122) : Error   : Unknown directive: .NOOVERLAP
template.asm(34) : Error   : Found no label/variable/constant named bm_ASYNC
template.asm(38) : Error   : Found no label/variable/constant named bm_ENABLE_TX
../../core/words/cold.asm(12) : Error   : [Macro: ../../core/macros.asm: 51:] Found no label/variable/constant named MCUSR
../../core/words/cold.asm(16) : Error   : [Macro: ../../core/macros.asm: 59:] Found no label/variable/constant named MCUSR
../../core/amforth.asm(18) : Error   : Found no label/variable/constant named NRWW_START_ADDR
../../core/amforth-eeprom.inc(56) : Error   : .BYTE directive can only be used in data segment (.DSEG)
Error: Overlapping Code-segments :
  Start = 0x0004, End = 0x0004, Length = 0x0001
  Start = 0x0004, End = 0x03C6, Length = 0x03C3
Please check your .ORG directives !
Error: Overlapping Code-segments :
  Start = 0x0006, End = 0x0006, Length = 0x0001
  Start = 0x0004, End = 0x03C6, Length = 0x03C3
Please check your .ORG directives !
Error: Overlapping Code-segments :
  Start = 0x0008, End = 0x0008, Length = 0x0001
  Start = 0x0004, End = 0x03C6, Length = 0x03C3
Please check your .ORG directives !
Error: Overlapping Code-segments :
  Start = 0x000A, End = 0x000A, Length = 0x0001
  Start = 0x0004, End = 0x03C6, Length = 0x03C3
Please check your .ORG directives !
<<SNIP>>
make: *** [template.hex] Error 1

Now. What did I do wrong? Except been using Linux as desktop,,, I've tried to read amforth.pdf and follow those instructions but please someone point out my mistake.

Best Regards,
Hannu Vuolasaho
 		 	   		  

[Amforth] New Release 4.9 tagged

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

Hi all,

I've just tagged the release 4.9. The core itself did not change that
much (except that I finally managed to create the device files from the
Partdesciption files from AVR Studio 6). This gives not only some new
controllers but also the register bitnames (I used the bitmap values
verbatim from the XML files, C code has usually bit position numbers).

The lib directory tree is completly re-structured. I got rid of files
like "misc.frt" which no-body would ever consider to use. From the
forth200x came the structures. Some hardware modules were added in
a more systematic fashion: timer and twi/i2c.

The new shell from Keith got a few more features (blame all bugs on me,
not Keith).

Did you ever got interested in the date of easter? load
examples/easter.frt and get it for any year after 1582 ;)

Enjoy
Matthias

Re: [Amforth] Filename completion for the amforth shell

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

{-- Sat, 14 Jul 2012 20:33:29 +0200: Matthias <mt...@we...> wrote: --}

  >> Nice.  Maintaining completion while supporting search directories
  >> invalidates my original solution for completion and implementing it
  >> is definitely a jump in complexity.

  Matthias> But its very convenient. Simply saying "#include
  Matthias> marker.<TAB>" and to get it without having trouble to find
  Matthias> the right directory is really cool.

Certainly!  It's definitely worth the jump in complexity.  The code just
has to be a bit messier to handle it.

  >> I think another limitation is that the use of the #cd directive to
  >> change directories won't work in files any longer.

  Matthias> I dont think that this is a showstopper for the fully
  Matthias> recursive file lookup. You dont need to do a change dir if
  Matthias> all files are directly available. The list of the base
  Matthias> directories could be expanded at runtime, maybe.

I agree that it isn't a show-stopper but it is still useful if you have
some directories with code that you don't normally need and so keep off
the search path but still want to access conveniently.

  >> os.path.normpath(os.path.join(os.path.join(wd, filename))

  Matthias> python's path magic is only for the brave.

Hmmm.... I suspect that was a typing mistake, especially since there
aren't enough closing brackets.  Probably there was only supposed to be
one of those os.path.join calls...  ;-)

  >> This will essentially return the union of the glob matches for the
  >> supplied completion text in all possible search directories if the
  >> completion text is not already an absolute filename.  It might get
  >> slow if you have a lot of large directories on your search path,
  >> but I suspect it will be fine.  I also expect I didn't get it
  >> really right but I think it should be close enough that you could
  >> get it working if you started with this.

  Matthias> I'll give it a try. Thanks.

I'd love to try it out myself but I haven't had time to get my
microcontrollers unpacked and setup again after we moved recently.  Let
me know how it goes.

       --- Keith

Re: [Amforth] Filename completion for the amforth shell

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

Hi Keith,

> Nice.  Maintaining completion while supporting search directories 
> invalidates my original solution for completion and implementing it 
> is definitely a jump in complexity.

But its very convenient. Simply saying "#include marker.<TAB>" and
to get it without having trouble to find the right directory is really
cool.

> I think another limitation is that the use of the #cd directive to 
> change directories won't work in files any longer.

I dont think that this is a showstopper for the fully recursive
file lookup. You dont need to do a change dir if all files are
directly available. The list of the base directories could
be expanded at runtime, maybe.

> os.path.normpath(os.path.join(os.path.join(wd, filename))

python's path magic is only for the brave.

> This will essentially return the union of the glob matches for the 
> supplied completion text in all possible search directories if the 
> completion text is not already an absolute filename.  It might get 
> slow if you have a lot of large directories on your search path, but 
> I suspect it will be fine.  I also expect I didn't get it really 
> right but I think it should be close enough that you could get it 
> working if you started with this.

I'll give it a try. Thanks.

Matthias

Re: [Amforth] Filename completion for the amforth shell

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

{-- Thu, 12 Jul 2012 20:50:28 +0200: Matthias <mt...@we...> wrote: --}

  Matthias> Hi Keith, I've played with filename completion for your
  Matthias> remarkable shell. First the good news: it works (for
  Matthias> me). The bad news is that the code is by far not as readable
  Matthias> as yours. But I tried my best.

Nice.  Maintaining completion while supporting search directories
invalidates my original solution for completion and implementing it is
definitely a jump in complexity.

<description of _filedirs map based implementation omitted>

  Matthias> The drawback of the current code is that you cannot give
  Matthias> directory names any more. Only the filenames itself are
  Matthias> allowed. This is fine for me, but may bother the users.

I think another limitation is that the use of the #cd directive to
change directories won't work in files any longer.  Preserving this is
slightly tricky because of the way the code tracks nested directory
changes in files included with the #include directory, but to do so I
would replace the call to:

 os.path.normpath(os.path.join(os.path.join(wd, filename))

near the top of the upload_files() method with a call to a function
like:

def find_upload_file(self, filename, working_directory):
    if os.path.isabs(filename):
        return filename   # Don't search if given absolute path
    for p in self._search_path:
        fn = os.path.normpath(os.path.join(p, filename))
        if not os.path.isabs(fn):
           fn = os.path.normpath(os.path.join(working_directory, fn))
        if os.path.exists(fn):
             return fn
    return filename        # The attempt to open later will fail...

I think this should handle everything required to get the search
behavior working if at startup you split the AMFORTH_LIB environment
variable contents into the "self._search_path" instance variable.  Note
I haven't actually tried to implement just typed it in.  It would be an
alternative to the way you have it implemented right now.

The completion support is trickier.  Roughly, I would replace the code
in the _rl_completer function for #include and #edit directives with
something like:

if os.path.isabs(text):
   self._rl_matches = glob.glob(text + "*")
else:
   self._rl_matches = itertools.chain(map(lambda p: \
        glob.glob(os.path.join(p, text) + "*"), self._search_path))

This will essentially return the union of the glob matches for the
supplied completion text in all possible search directories if the
completion text is not already an absolute filename.  It might get slow
if you have a lot of large directories on your search path, but I
suspect it will be fine.  I also expect I didn't get it really right but
I think it should be close enough that you could get it working if you
started with this.

It's really nice to see these additional features being added!

       --- Keith

[Amforth] Filename completion for the amforth shell

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

Hi Keith,

I've played with filename completion  for your remarkable
shell. First the good news: it works (for me). The bad news is that
the code is by far not as readable as yours. But I tried my best.

What does it do

Upon startup (and whenver a general update seems appropriate) it
reads the whole directory tree under the current directory and
all directories the environment variable AMFORTH_LIB points to.

While doing so it tries to recognize double occurencies of the
same file (e.g. if ./lib/test.frt and $AMFORTH_LIB/test.frt are
the same file it counts only as one -- difficult to check). For
every file the directories are stored in canonical form in a map
(self._filedirs). Whenever a filename needs to be processed
the program checks if it is unique over all directories (the
map contains 1 entry for that file).

If that check succeeds, the file is processed the usual way.
If not, an error message is printed.

In interactive mode, the #include command works the same.
With filename completion (without telling the number of
directories however).

The drawback of the current code is that you cannot give
directory names any more. Only the filenames itself are
allowed. This is fine for me, but may bother the users.

mt@ayla:~/amforth/trunk/tools$ ./amforth-shell.py -p /dev/ttyUSB0
--no-error-on-output
|I=Entering amforth interactive interpreter
|I=using device.py for atmega328p
(ATmega328P)> #include test<TAB>
test2.frt           tester-amforth.frt  tester.frt
(ATmega328P)> #include test2.frt
|D=#include test2.frt
|I=using test2.frt from /home/mt/amforth/lib
|I=mcudef
|I=using device.py for atmega328p
|F=/home/mt/Projekte/avr/forth/amforth/lib/test2.frt
|C|    1|\ this is a test
|S|    2|100 200 + .
|O|    2|300
|S|    3|1000 ms
(ATmega328P)>

The current code is in the repository (rev 1251)

Matthias

Re: [Amforth] New forth interaction script

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

Hello Keith,

On 07/09/2012 03:05 AM, Keith Amidon wrote:
> {-- Sun, 08 Jul 2012 20:01:02 +0200: Erich<ew....@na...>  wrote: --}
>
>    Erich>  More info below ...
>    >>  I found a minor thing that puzzles me:
>    >>  |C| 11|\ PORTD 7 portpin: PD.7 ( define portD pin #7)
>    >>  |E| 12|\ PD.7 high ( turn portD pin #7 on, i.e. set it high-level)
>    >>  |E=Illegal nested comment
>    >>  make: *** [marker] Error 1
>
>    Erich>  This can be worked around by adding a space before the
>    Erich>  closing ')'.
>    Erich>  ...
>    Erich>  |C|   10|\ Use it this way:
>    Erich>  |C|   11|\ PORTD 7 portpin: PD.7  ( define portD pin #7 )
>    Erich>  |C|   12|\ PD.7 high              ( turn portD pin #7 on, i.e. set it high-level )
>
> Ah, yes, I forgot I didn't take care of that.  You may notice that the
> line starts with |C|.  To reduce the amount of data sent to the
> microcontroller the script detects lines that are all comments or
> whitespace and doesn't send them.
>
> When I originally wrote this support I was under the mistaken impression
> that comments delimited by parenthesis had the following
> characteristics:
>
> 1: the start parenthesis had to be surrounded by whitespace (true I
>     believe)
True.

> 2: the end parenthesis had to be surrounded by whitespace (false I
>     believe)
Looking at the code: XT_CSCAN looks for character 'c' (from 
stack) in the input stream. " ( " is in lparenthesis.asm and 
looks for the next closing paren ')'.
so: False.

> 3: these comments could span multiple lines, similar to the way that
>     C "/* */" comments can (also false I believe)
False. cscan will look in the current input buffer. gforth barks 
as well when trying to break comment over more lines.

>
> I forgot to go clean this up when I discovered the problem.  I'll add
> that to my list of things to try to get to when I get a chance to work
> on the script.  Alas, it doesn't look like that is going to happen this
> weekend as I had hoped after all.

No sweat! Folks start using your tool in unexpected ways, that's 
all :-)

Cheers,
Erich

Re: [Amforth] New forth interaction script

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

{-- Sun, 08 Jul 2012 20:01:02 +0200: Erich <ew....@na...> wrote: --}

  Erich> More info below ...
  >> I found a minor thing that puzzles me:
  >> |C| 11|\ PORTD 7 portpin: PD.7 ( define portD pin #7)
  >> |E| 12|\ PD.7 high ( turn portD pin #7 on, i.e. set it high-level)
  >> |E=Illegal nested comment
  >> make: *** [marker] Error 1

  Erich> This can be worked around by adding a space before the
  Erich> closing ')'.
  Erich> ...
  Erich> |C|   10|\ Use it this way:
  Erich> |C|   11|\ PORTD 7 portpin: PD.7  ( define portD pin #7 )
  Erich> |C|   12|\ PD.7 high              ( turn portD pin #7 on, i.e. set it high-level )

Ah, yes, I forgot I didn't take care of that.  You may notice that the
line starts with |C|.  To reduce the amount of data sent to the
microcontroller the script detects lines that are all comments or
whitespace and doesn't send them.  

When I originally wrote this support I was under the mistaken impression
that comments delimited by parenthesis had the following
characteristics:

1: the start parenthesis had to be surrounded by whitespace (true I
   believe)
2: the end parenthesis had to be surrounded by whitespace (false I
   believe)
3: these comments could span multiple lines, similar to the way that
   C "/* */" comments can (also false I believe)

I forgot to go clean this up when I discovered the problem.  I'll add
that to my list of things to try to get to when I get a chance to work
on the script.  Alas, it doesn't look like that is going to happen this
weekend as I had hoped after all.  

    --- Keith

Re: [Amforth] New forth interaction script

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

Hi all,
>>
>>    Matthias>  I collect the changes in the repository at
>>    Matthias>  http://amforth.svn.sourceforge.net/viewvc/amforth/trunk/tools/amforth-term.py?view=log

Just for the record: I renamed the tool to amforth-shell, You'll find it
here:
http://amforth.svn.sourceforge.net/viewvc/amforth/trunk/tools/amforth-shell.py?view=log


Matthias
PS: Funny, that no-one uses a PC Forth (gforth) for such tools ;)

Re: [Amforth] New forth interaction script

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

More info below ...

> I found a minor thing that puzzles me:
> 
> |I=mcudef
> |I=using device.py for atmega32
> |F=/home/ew/Forth/atmega/46_trunk-2/lib/bitnames.frt
> |C| 1|\ V 1.3 02.11.2007
> |W| 2|
> |C| 3|\ Code: Matthias Trute
> |C| 4|\ Text: M.Kalus
> |W| 5|
> |C| 6|\ A named port pin puts a bitmask on stack, wherin the set 
> bit indicates which
> |C| 7|\ bit of the port register corresponds to the pin.
> |C| 8|\ And then puts the address of its port on stack too.
> |W| 9|
> |C| 10|\ Use it this way:
> |C| 11|\ PORTD 7 portpin: PD.7 ( define portD pin #7)
> |E| 12|\ PD.7 high ( turn portD pin #7 on, i.e. set it high-level)
> |E=Illegal nested comment
> make: *** [marker] Error 1

This can be worked around by adding a space before the
closing ')'.
...
|C|   10|\ Use it this way:
|C|   11|\ PORTD 7 portpin: PD.7  ( define portD pin #7 )
|C|   12|\ PD.7 high              ( turn portD pin #7 on, i.e. set it high-level )
...


> Illegal nested comment? Not quite. "\ " starts a comment, which
> extends to the end of line, no questions asked. This is probably
> simple to fix, but I have not yet looked into the code.

Erich