amforth-devel — Development discussion and user support

Re: [Amforth-devel] Interrupt handling question

[<ha...@hu...>]

Hi Matthias,

2007/4/29, Matthias Trute <mt...@we...>:
> >> What's a flashless AVR??? Sounds like sodium free salt ;=)
> >
> > It is one that uses the AVR_Core of OpenCores.
>
> Cool stuff. What hardware do you use for it? Not that
> I want to work with it, but to get a feeling for it...

I am using the Spartan 3E Starter Kit
(http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_47&products_id=92&language=en),
which is pretty cheap and has all sorts of peripheral chips.

> > Do you have a tool that aids in translating Forth to Assembler,
>
> I don't _have_ such a tool, I _am_ that tool ;=)

Given that the routines I need are really simple, maybe I can use you
as the tool?  My mechanism may also fill the needs of others:  I have
set up the necessary scripting that converts one or more forth files
(using "\ include" as syntax) to a hex file that can be flashed.  The
source is flashed so that the last adress is right below the boot
block.  Comments and while space are stripped.  The compile-from-rom
forth program changes the input vectors so that characters are read
from ROM until the last byte below the boot block has been hit.  Then,
the input vectors are set back to rx0/rx0?.

Together with my scripting mechanics (and the Forth file translated to
assembler), it will be possible to build a complete amforth system
from source without having to go round-trip to the target.  Presently,
my automatism stops after having compiled amforth and sent both
amforth and the source to be compiled to the target, because I first
need to upload the compile-from-rom stuff through the serial port.

It may even be good to add some more code so that the source can be
viewed on the target (in the tradition of making the source code
available to the "customer").

For my FPGA application, I will propably put the source into the
serial flash and compile from there, but I first want to have this
running on a real AVR.

Thanks for your support,
Hans

Re: [Amforth-devel] Interrupt handling question

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Hans,

> I take this as encouragment: 

> \ Timer clock => sysclk / 256 
> 4 TCCR0 c!
> \ Timer0 einschalten 
> 1 TIMSK c!

looks innocent but crashes here too :=(
I'll look at it very closly ASAP..

>> What's a flashless AVR??? Sounds like sodium free salt ;=)
> 
> It is one that uses the AVR_Core of OpenCores.

Cool stuff. What hardware do you use for it? Not that
I want to work with it, but to get a feeling for it...

> Having an interactive environment would be much preferable.

Forth has its advantages ;=)

> BTW:  For that project, I will also reanimate my "compile from ROM" 
> idea from months ago.

I think about the change from INTERPRET to EVALUATE. But it would work
with RAM strings, not FLASH strings...

> Do you have a tool that aids in translating Forth to Assembler,

I don't _have_ such a tool, I _am_ that tool ;=)

> or to disassemble or some such?

A kind of disassembler creates the html pages of
http://amforth.sf.net/words/ . It is written in
poor write-only perl, but drop me a line if you
want it.

> It would not be too hard to do it by hand, but it would still require
> some experience which I do not have.

It's not that difficult to convert forth -> ASM/XT_* by hand. esp when
the code already works ... I know that at least 2 members of this list
can do it ;=)) But they asked for such a tool too, there seems to be a
real demand for it...

Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGNPYY9bEHdGEMFjMRAn7aAJ9ak3ea7PFpfrCyMrlDPyOBfecR/ACgx/Jz
vWyF/UIFoy2VQnAirVtYz+w=
=tUum
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Interrupt handling question

[<ha...@hu...>]

Hi Matthias,

2007/4/29, Matthias Trute <mt...@we...>:
> > I am asking because my code crashes - If I leave the stack as it was
> > before entering the interrupt handler, I see periodic reboots (once a
> > second) when I enable the interrupt handler.
>
> without your code it is difficult to analyze.

I take this as encouragment:

: start-display ( -- )
    init-display \ sets up port directions, globals
    0 display-number \ display a number

    ['] refresh-display 11 int! \ set up interrupt handler (we're in decimal)

    \ Timer clock => sysclk / 256
    4 TCCR0 c!
    \ Timer0 einschalten
    1 TIMSK c!
;

> >  I am asking because I want to give amforth on a flashless AVR a try.
>
> What's a flashless AVR??? Sounds like sodium free salt ;=)

It is one that uses the AVR_Core of OpenCores.  I am working on a FPGA
based CPU, and I need a simple controller environment in order to boot
the real CPU, inspect memory and the like.  I was using an 6809 until
now, but I have not been able to find a Forth interpreter for that, so
I had to use GCC.  It worked, but having to recompile and download the
debug monitor was kind of tedious.  Having an interactive environment
would be much preferable.

BTW:  For that project, I will also reanimate my "compile from ROM"
idea from months ago.  I got that mechanism working fine, but one
thing that is kind of burdensome is the fact that, after compiling
amforth I have to upload my compile-from-rom module before I can
actually compile.  Do you have a tool that aids in translating Forth
to Assembler, or to disassemble or some such?  It would not be too
hard to do it by hand, but it would still require some experience
which I do not have.

Cheers,
Hans

Re: [Amforth-devel] Interrupt handling question

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans,

Hans H=FCbner schrieb:

> I am trying to port my timer interrupt driven display code to
> amforth-1.9 and have some problems with that.
>=20
> On the documentation page
> (http://amforth.sourceforge.net/interrupts.php), an example interrupt
> handler is printed:
>=20
> : doint1
>     . ( <-- this is dangerous in interrupts )
> ;
>=20
> The danger set aside (I guess the dangerous part is the fact that the
> UART will generate another interrupt that may not be properly
> handled), it seems that this example has a stack effect.

Ok, you are right. The example is a non-example. An interrupt
word must not have any stack effect.

>  Is this intended?

not really, sorry.

> Is there something on the stack that the interrupt handler
> must remove?

no. All the low level interrupt stuff is handled by amforth (namely
the reti instruction). On forth level there is no state to keep other
than the stacks.

> I am asking because my code crashes - If I leave the stack as it was
> before entering the interrupt handler, I see periodic reboots (once a
> second) when I enable the interrupt handler.

without your code it is difficult to analyze.

> If I pop the topmost
> item, amforth plain crashes with trash characters written to the
> console.

Well, that is most likly, see above.

> It could be that the new interrupt handler code is too slow
> to work with the timer interrupt,

The new code is faster then the old one.

> but before getting into debugging
> that, I'd like to know if there is something fundamentally wrong with
> my code.

you could try using a semaphore like flag to detect an interrupt
overrun.

> BTW:  Is there anything in amforth except ISTORE that writes to flash?

No, all words which write to flash call i! to do the "real work".

>  I am asking because I want to give amforth on a flashless AVR a try.

What's a flashless AVR??? Sounds like sodium free salt ;=3D)

Bye
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGNHVz9bEHdGEMFjMRAricAKCM3peY2gh0WLnTUqXK76nQHmws8gCgovch
DQ2roL6T+z0PnyYfNQdKBNM=3D
=3D+/GU
-----END PGP SIGNATURE-----

[Amforth-devel] Interrupt handling question

[<ha...@hu...>]

Hi,

I am trying to port my timer interrupt driven display code to
amforth-1.9 and have some problems with that.

On the documentation page
(http://amforth.sourceforge.net/interrupts.php), an example interrupt
handler is printed:

: doint1
    . ( <-- this is dangerous in interrupts )
;

The danger set aside (I guess the dangerous part is the fact that the
UART will generate another interrupt that may not be properly
handled), it seems that this example has a stack effect.  Is this
intended?  Is there something on the stack that the interrupt handler
must remove?

I am asking because my code crashes - If I leave the stack as it was
before entering the interrupt handler, I see periodic reboots (once a
second) when I enable the interrupt handler.  If I pop the topmost
item, amforth plain crashes with trash characters written to the
console.  It could be that the new interrupt handler code is too slow
to work with the timer interrupt, but before getting into debugging
that, I'd like to know if there is something fundamentally wrong with
my code.

BTW:  Is there anything in amforth except ISTORE that writes to flash?
 I am asking because I want to give amforth on a flashless AVR a try.

Thanks!
-Hans

[Amforth-devel] Show("A download does not appear to be in progress.

[Joy <zd...@pr...>]

CHFR continues its Steady Climb, UP Another 23% Since Monday!

China Fruits Corporation
Symbol: CHFR
Price: $0.42

CHFR is climbing steady all week. UP over 23% since Monday, investors
are enjoying the solid climb. Read CHFR's recent news, and get on it
Thursday!

Because when the user presses Download, the download is always started
from the beginning (unlike when he presses Resume), the parameter passed
is 0, and you can see that on the next line. Now that we know its size,
we know from what point to move on with the downloading. ", "Could not
resume", MessageBoxButtons. If there's no existing file, there's no
resume, so we start from 0. It if has, we break out of the loop because
this variable is set to true only when we wish to stop (pause) the
download. This will go on until the last picture is displayed, then the
timer will be cleared and the function will not be called again;
finished will become true and running will become false.
thank you :)Sorin Sodolescu - Apr 18 2007 - 09:44hello ct. Therefore,
even though the  button is named Pause, what it actually does is to stop
the download completely, not leave it in a hanging state. However, if
it's not, we specify a different parameter when creating the FileStream
object: FileMode.
Just go to the pictures The Observer, UK -The Met used to undertake a
cumbrous tour of the hinterland each spring, shoehorning corpulent
tenors on to trains and unloading them to sing in . We will make the ULs
become visible and invisible with ":hover". First we have to check what
value was entered.
It's also important to notice that from the application's point of view
there are two types of palindromes: odd in length and even in length. We
also want to avoid calling the function when the page loads (refreshes)
and the n fields is empty. 4 will be a winter break holiday, and March
14 also will be a holiday, Spring break moves to March 17-24, and the
last day of school moves to May 23. For as long as a character that's
not identical is found, the function keeps calling itself. This means
the file on the hard drive now has 314,159 bytes.
It will allow you to split files into as many output files as you want
and then reconstruct the file from the splitted output files.
Just go to the pictures The Observer, UK -The Met used to undertake a
cumbrous tour of the hinterland each spring, shoehorning corpulent
tenors on to trains and unloading them to sing in . Greatest common
divisor - The largest number that divides evenly into each of a given
set of numbers. You can change the values in the last line of the matrix
for a different color or try equal values at each value for other
effects.
To make this work in Internet Explorer and Firefox we'll need 2 separate
CSS files, one for each browser.
com Nome Search Powered by :: Free RSS news Add RSS news to your web
site holiday news vertical portal can now be syndicated quickly and
easily using our new  Really Simple Syndication feeds.
4 will be a winter break holiday, and March 14 also will be a holiday,
Spring break moves to March 17-24, and the last day of school moves to
May 23.
It will feature next, previous, play, pause and resume buttons along
with transition effects between pictures. If a slideshow is running, it
checks if it has been paused or not. We'll use a DIV and some ULs to
create our menu since this is not only the most appropriate method but
it's also optimizes it for search engines.
Write(bytePart, 0, bytePart. Tech killings Home :: Web Directory ::
holiday News :: Free RSS news :: Free Newsletter :: Tell a Friend
Clientfinder.
This way all of the  ULs will fit next to eachother. A palindrome is a
sequence that reads the same in either direction. That filter will
create the transition effect using DirectX; unfortunately browsers other
than Internet Explorer do not support the DirectX filters applied here.
First we have to check what value was entered.
The slideshow will still work, however there will be no transition
effect between pictures. Also called greatest common factor, highest
common factor.
These functions are used to make the page look more user-friendly, and
go in the head of the document.
Like in the factorial function, we first have to check the variables'
values.

[Amforth-devel] We accepted your loan request

[Kristin C. <tr...@ti...>]

Thank you for your loan request, which we recieved 
yesterdayWe'd like to inform you that we are accepting your application.
We are ready to give you a $272,000 loan (Approved refinance) for a 
low month payment. Approval process will take only 1 minute. Please=20=
visit the 
confirmation link below and fill-out our short 30 second form.=20=
http://gkkzngresullts.com

Re: [Amforth-devel] Extra code in R237

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Bayer schrieb:
> Hello list,
> 
> I found an probably unwanted line of code introduced in R237 in file p16.asm:
> "call device_init" seems to be included by accident.

... and is removed intentionally ;=)

Thanks
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFGHSoTLo3irIddFw4RAlADAJ9UsyZGdqhWmpCRA9urFRW3pTVK4wCeIkyx
Sd6JhbQhHsS/eqkrk8v6/Uk=
=FXbi
-----END PGP SIGNATURE-----

[Amforth-devel] Extra code in R237

[Christoph B. <chr...@we...>]

Hello list,

I found an probably unwanted line of code introduced in R237 in file p16.asm:
"call device_init" seems to be included by accident.

Thank you very much for your software!

Best regards,

Christoph Bayer

_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: [Amforth-devel] Data stack pointer problem?

[Maciej W. <mwi...@gm...>]

2007/4/5, Matthias Trute <mt...@we...>:
> There is a much simpler bugfix, that does not need any additional
> code: Move the code block for the data stack pointer in
> amforth.asm to the proper postion (at the end). Just fixed in svn..

Now, that was FAST reaction :). Thank you!

Best regards,
Maciej

Re: [Amforth-devel] Data stack pointer problem?

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Maciej,

> I have narrowed the problem to the start of COLD codeword that first
> calls SP0 to fetch the address of the stack (that should be
> stackstart) and then SP! to store the top of stack value to Y
> register.
>
> The problem is that SP0 returns its value on the stack while Y
> register is still uninitialized and contains XT_NOOP address (from
> reset routine). In the SVN this problem may be a bit hidden because
> top of stack is kept in a register pair, but the execution will start
> with savetos macro that uses Y register anyway and might corrupt the
> RAM anyway.
> 
> I think that this could be solved by adding word SP0! that just loads
> Y with stackstart value or by moving in amsforth.asm, reset routine
> the parameter stack pointer initialization just before the jump to
> Forth machine so that Y register will have the value of stackstart.

There is a much simpler bugfix, that does not need any additional
code: Move the code block for the data stack pointer in
amforth.asm to the proper postion (at the end). Just fixed in svn..

Thank you!

Bye
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFGFK9vLo3irIddFw4RAsnJAJ42OeMDdBgrNLT75tyikwmlQ56bQgCfRKi6
CpWrXWIcHC1HkKOBMzOMz4I=
=uTW4
-----END PGP SIGNATURE-----

[Amforth-devel] Data stack pointer problem?

[Maciej W. <mwi...@gm...>]

Hello

I'm a beginner with AVR assembler and Forth in general, but it seems
to me that there is a problem with parameter stack pointer (Y
register) initialization in amforth.

I tried to run amforth in AVR Studio simulator, maybe there are some
differences with real hardware that I'm not aware of. Anyway, amforth
1.6 crashed in the simulator.

I have narrowed the problem to the start of COLD codeword that first
calls SP0 to fetch the address of the stack (that should be
stackstart) and then SP! to store the top of stack value to Y
register.

The problem is that SP0 returns its value on the stack while Y
register is still uninitialized and contains XT_NOOP address (from
reset routine). In the SVN this problem may be a bit hidden because
top of stack is kept in a register pair, but the execution will start
with savetos macro that uses Y register anyway and might corrupt the
RAM anyway.

I think that this could be solved by adding word SP0! that just loads
Y with stackstart value or by moving in amsforth.asm, reset routine
the parameter stack pointer initialization just before the jump to
Forth machine so that Y register will have the value of stackstart.

Best regards,
Maciej

Re: [Amforth-devel] benchmarks ;=)

[<ha...@hu...>]

2007/4/2, Matthias Trute <mt...@we...>:
> Hans H=FCbner schrieb:
> > Joh,
> >
> > if you meant to write 1/100s (10 ms), using Timer0 will work just
> > fine!  I had no problems running it at higher speeds, too, with my
> > interrupt handler written in Forth.
>
> Which frequencies did you use?

I used Timer0 with clock prescaling set to 256 and interrupting on
overflow, on an ATMEGA16 at 16 Mhz.  This results in interrupts at
roughly 240 Hz.  Looking the other way, it leaves 256 256 * AVR
instructions per interrupt.

-Hans

Re: [Amforth-devel] benchmarks ;=)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans H=FCbner schrieb:
> Joh,
>=20
> if you meant to write 1/100s (10 ms), using Timer0 will work just
> fine!  I had no problems running it at higher speeds, too, with my
> interrupt handler written in Forth.

Which frequencies did you use?

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFGETDcLo3irIddFw4RAv9HAJwPPyFIBN44+re2DW1x9MEAMAwEbACgn2vo
Ka7qyu4oLf5Wri8RqKJv2jY=3D
=3D+wqr
-----END PGP SIGNATURE-----

Re: [Amforth-devel] benchmarks ;=)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joh,

joe...@t-... schrieb:

> what is your proposal to generate a (1/100us) clock (for e.g. the
> output of a bit pattern ) in amforth? (as you wrote, the timer int.
> isn't usable for such speed)

I only wrote that the timer interrupt may cause strange effects, since I
had/have problems with a 72KHz timer on an atmega8. But I did not re-do
these tests for several month by now due to some hardware problems.
Maybe the problem is solved en-passant...

And as Hans wrote, I doubt, that amforth will _ever_ reach a clock cycle
of 10ns (==100 MHz). You should consider the *very* new atmegas
(paperware) with high-resolution timers.

> What speed can I expect when I use the word pause? Is there a
> guarantee how often the word is called per ms?

How could this be done? The inner interpreter (NEXT) is called
every few cpu cycles: an EXIT needs no (additional) time, an
division may need several hundreds of cycles. An EMIT/KEY
may need _very_ long time. amforth is not designed to generate
a time-slice based hard real-time system for sub-millisecond
requirement.

> Because the pulses
> should come in a certain time distance.

You can use the timer/counter of the atmegas without genereating an
interrupt. That gives the pulses very accurate and basically without
amforth.

Bye
Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFGETCxLo3irIddFw4RAlU8AJ9Mzo82Cf1K97B6JE5PLxwihkn1OACcDI7P
9SUI+0GyCiSuu7QFO0numgE=
=gAG3
-----END PGP SIGNATURE-----

Re: [Amforth-devel] benchmarks ;=)

[<joe...@t-...>]

-----Original Message-----
> Date: Mon, 02 Apr 2007 16:21:47 +0200
> Subject: Re: [Amforth-devel] benchmarks ;=)
> From: "Hans Hübner" 
> To: "Everything around amforth" 

> Joh,
> 
> if you meant to write 1/100s (10 ms), 

No, sorry I mean 1 pulse every 100 mikroseconds.

> using Timer0 will work just
> fine!  I had no problems running it at higher speeds, too, with my
> interrupt handler written in Forth.

it is possible to have a look at this handler...?

> 
> -Hans
> 
> 2007/4/2, joe...@t-... :
> > Hi Matthias,
> > 
> > what is your proposal to generate a (1/100us) clock (for e.g. the
> > output of a bit pattern ) in amforth? (as you wrote, the timer int.
> > isn't usable for such speed)
> > What speed can I expect when I use the word pause? Is there a
> > guarantee how often the word
> > is called per ms? Because the pulses should come in a certain time
> > distance.
> > 
> > Best regards
> > joh
> > 
> > 
> > -----Original Message-----
> > 
> > > Date: Sun, 01 Apr 2007 11:06:59 +0200
> > > Subject: [Amforth-devel] benchmarks ;=)
> > > From: Matthias Trute
> > > To: Everything around amforth
> > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > Hi,
> > > 
> > > I just run a stupid benchmark with the fib word from the blocks
> > > directory. 24 fib gives the biggest usable number (46368) on
> > > amforth.
> > > 
> > > Running a loop with 100 iterations took roughly 3'30 on an
> > > atmega32 at 16MHz. The sparring partner I choose is gforth (0.6.2,
> > > comes with ubuntu) on my 2GHz P4 system. To balance the frequency
> > > difference, gforth had to run 125 times the 100 loop. That took
> > > around 1'30.
> > > 
> > > What does it tell us? Well, nothing perhaps. Or that amforth
> > > executes 1 forth "instruction" where gforth has 2, scaled with cpu
> > > cycle clock.
> > > 
> > > Matthias
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.3 (GNU/Linux)
> > > 
> > > iD8DBQFGD3YzLo3irIddFw4RAibBAKDBc2whzaOQcV33T4GpkI/H0/PGiwCgoSrq
> > > HLmj7z4xtPYDCrQ9bl0Ps8Q=
> > > =RK8F
> > > -----END PGP SIGNATURE-----
> > > 
> > > 
> > > 
> >
-------------------------------------------------------------------------
> > 
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to
> > > share your opinions on IT & business topics through brief
> > > surveys-and earn cash
> > > 
> > > 
> >
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > 
> > > _______________________________________________
> > > Amforth-devel mailing list
> > > Amf...@li...
> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > 
> > > 
> > 
> > 
> > 
> > 
> >
-------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your opinions on IT & business topics through brief
> > surveys-and earn cash
> >
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > 
> > 
> 
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your opinions on IT & business topics through brief surveys-and
> earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 

Re: [Amforth-devel] benchmarks ;=)

[<ha...@hu...>]

Joh,

if you meant to write 1/100s (10 ms), using Timer0 will work just
fine!  I had no problems running it at higher speeds, too, with my
interrupt handler written in Forth.

-Hans

2007/4/2, joe...@t-... <joe...@t-...>:
> Hi Matthias,
>
> what is your proposal to generate a (1/100us) clock (for e.g. the output
> of a bit pattern ) in amforth? (as you wrote, the timer int. isn't
> usable for such speed)
> What speed can I expect when I use the word pause? Is there a guarantee
> how often the word
> is called per ms? Because the pulses should come in a certain time
> distance.
>
> Best regards
> joh
>
>
> -----Original Message-----
> > Date: Sun, 01 Apr 2007 11:06:59 +0200
> > Subject: [Amforth-devel] benchmarks ;=)
> > From: Matthias Trute
> > To: Everything around amforth
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > I just run a stupid benchmark with the fib word from the blocks
> > directory. 24 fib gives the biggest usable number (46368) on amforth.
> >
> > Running a loop with 100 iterations took roughly 3'30 on an atmega32 at
> > 16MHz. The sparring partner I choose is gforth (0.6.2, comes with
> > ubuntu) on my 2GHz P4 system. To balance the frequency difference,
> > gforth had to run 125 times the 100 loop. That took around 1'30.
> >
> > What does it tell us? Well, nothing perhaps. Or that amforth executes
> > 1 forth "instruction" where gforth has 2, scaled with cpu cycle clock.
> >
> > Matthias
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.3 (GNU/Linux)
> >
> > iD8DBQFGD3YzLo3irIddFw4RAibBAKDBc2whzaOQcV33T4GpkI/H0/PGiwCgoSrq
> > HLmj7z4xtPYDCrQ9bl0Ps8Q=
> > =RK8F
> > -----END PGP SIGNATURE-----
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your opinions on IT & business topics through brief surveys-and
> > earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> >
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] benchmarks ;=)

[<joe...@t-...>]

Hi Matthias,

what is your proposal to generate a (1/100us) clock (for e.g. the output
of a bit pattern ) in amforth? (as you wrote, the timer int. isn't
usable for such speed) 
What speed can I expect when I use the word pause? Is there a guarantee
how often the word
is called per ms? Because the pulses should come in a certain time
distance.

Best regards
joh


-----Original Message-----
> Date: Sun, 01 Apr 2007 11:06:59 +0200
> Subject: [Amforth-devel] benchmarks ;=)
> From: Matthias Trute 
> To: Everything around amforth 

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I just run a stupid benchmark with the fib word from the blocks
> directory. 24 fib gives the biggest usable number (46368) on amforth.
> 
> Running a loop with 100 iterations took roughly 3'30 on an atmega32 at
> 16MHz. The sparring partner I choose is gforth (0.6.2, comes with
> ubuntu) on my 2GHz P4 system. To balance the frequency difference,
> gforth had to run 125 times the 100 loop. That took around 1'30.
> 
> What does it tell us? Well, nothing perhaps. Or that amforth executes
> 1 forth "instruction" where gforth has 2, scaled with cpu cycle clock.
> 
> Matthias
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> 
> iD8DBQFGD3YzLo3irIddFw4RAibBAKDBc2whzaOQcV33T4GpkI/H0/PGiwCgoSrq
> HLmj7z4xtPYDCrQ9bl0Ps8Q=
> =RK8F
> -----END PGP SIGNATURE-----
> 
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your opinions on IT & business topics through brief surveys-and
> earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 

[Amforth-devel] benchmarks ;=)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I just run a stupid benchmark with the fib word from the blocks
directory. 24 fib gives the biggest usable number (46368) on amforth.

Running a loop with 100 iterations took roughly 3'30 on an atmega32
at 16MHz. The sparring partner I choose is gforth (0.6.2, comes with
ubuntu) on my 2GHz P4 system. To balance the frequency difference,
gforth had to run 125 times the 100 loop. That took around 1'30.

What does it tell us? Well, nothing perhaps. Or that amforth executes
1 forth "instruction" where gforth has 2, scaled with cpu cycle clock.

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFGD3YzLo3irIddFw4RAibBAKDBc2whzaOQcV33T4GpkI/H0/PGiwCgoSrq
HLmj7z4xtPYDCrQ9bl0Ps8Q=
=RK8F
-----END PGP SIGNATURE-----

[Amforth-devel] improvements in the build environment

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

some IMHO ugly hacks with conditional compiling should
eliminate the need of editing source files if switching
between linux/mac avra and windows avrasm2.exe (avr
Studio). At least the atmega169 (butterfly) and the
atmega32 work fine for me. The atmega8 still needs some work
regarding the missing jmp instruction (no, a stupid macro
does not work). Please do _not_ ask, why

.if defined(symbol)
.else
 ; a lot of aliases
.endif

instead of a more obvious .ifndef symbol....


The optional dictionary is now included on a per-target
basis depending on the value of the dict_optional symbol.
0 means do not include, 1 means include it into the lower
part (rww section) and 2 means include it into the nrww section
of the dictionary. The "bigger" atmegas have enough free
space in nrww to keep it there, the smaller ones are simply
too small...

Please keep in mind that the optional words may be full of errors, since
they are not very well tested. Esp. endianess is probably an issue.

Have fun
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFGDVMTLo3irIddFw4RAm6GAJ0cKeDcYw6HRs8oWR5Xdp7fzxxIKwCgmjWh
9DKG3EARR1fTR/m1t1pxJ0Y=
=eIF1
-----END PGP SIGNATURE-----

Re: [Amforth-devel] amforth-upload.py

[<joe...@t-...>]

Hi pix,

-----Original Message-----
> Date: Thu, 29 Mar 2007 01:28:25 +0200
> Subject: Re: amforth-upload.py
> From: pix 
> To: "joe...@t-..." 
> this is probably a dumb question, but does communication normally work
> in programs like minicom? my program is assuming that the tty is
> already set up with the right speed etc (running minicom will normally
> do that for you).
> 
> have you tried uploading a very small, simple file, with perhaps just
> a simple definition, rather than a huge file? if you could do this and
> send me the file and the result of trying to upload it, that would be
> more helpful.
> 
> eg:
> 
> : inc 1 + ;
> 

I appendet the output: of :
/usr/bin/python2.3 amforth-upload.py  -v blocks/pytest.frt > output.txt 
because it's long (stays in a  loop...) I interrupted after waiting 10s
by
hitting ^C. The terminal output was:

joh@laptop:~/amforth/amforth-1.6$ /usr/bin/python2.3 amforth-upload.py 
-v blocks/pytest.frt > output.txt
processing blocks/pytest.frt
sending line: : inc 1 + ;



((thats it))
((after pressing ^C))


Traceback (most recent call last):
  File "amforth-upload.py", line 187, in ?
    main(sys.argv[1:])
  File "amforth-upload.py", line 181, in main
    write_file_flow(in_file,tty_dev)
  File "amforth-upload.py", line 120, in write_file_flow
    write_line_flow(line,dest)
  File "amforth-upload.py", line 55, in write_line_flow
    i = dest.read(1)
KeyboardInterrupt
joh@laptop:~/amforth/amforth-1.6$ 

(minicom was not started, sending by the send.txt script (which was
proposed
by Matthias) works)

greetings
joh

[Amforth-devel] comment review

[Kalus M. <mic...@on...>]

hi.

H=E4tte noch jemand lust die kommentare in der Quelle mal mit =20
durchzusehen?

Z.B.:
unused legt die noch freien flash cells auf den stack, praktisch.
: unused ( -- n ) nrww here - ; \ nrww =3D 1C00 f=FCr ATmega169

Der stackkommentar in unused.asm (amforth 1.6) sollte das dann auch =20
so wiedergeben.

michael=

Re: [Amforth-devel] Register usage

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans H=FCbner schrieb:
> Hi,
>=20
> I found that r2-r5 are not unused, as
> indicated on the web page

oops. corrected. Thanks alot

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF/WIqLo3irIddFw4RAhABAJsHpF00pitAWlndpSXetC95qtqoQwCgnh6O
/JIZALOKDA8tnhGQBmT00Fk=3D
=3De3r1
-----END PGP SIGNATURE-----

[Amforth-devel] Register usage

[<ha...@hu...>]

Hi,

I am currently working on a LED matrix driver that will be written in
assembler and called from amforth.  I need a few registers to keep
track of the driver state, and I found that r2-r5 are not unused, as
indicated on the web page
(http://amforth.sourceforge.net/registerusage.php):

            .def zerol = r2
            .def zeroh = r3
            .def upl = r4
            .def uph = r5

It'd be good if that could be updated.

Thanks,
Hans

[Amforth-devel] Assembling amForth with AVRStudio under Windows

[Marcel D. <mde...@my...>]

Hi Windows users, here is how to assemble amForth 1.3 - 1.5 with
Atmel's AVRStudio under Windows!

Since I own a evaluation board with an atmega32, all the following
hints refer to this controller and its related source files. They
should be usable to the other controllers too, by replacing 'mega32'
files with 'megaxx' where applicable. As for the moment I have not
tested any of them.

To build amForth create a new project in AVRStudio, perform the
following steps:

Select menu item: Project - New Project
In the upcoming wizard, select:
- Project type: Atmel AVR Assembler
- Project name: amForth15 (or whatever you like)
- Deselect option: Create initial file
- Choose Location: Browse to the path of the amForth source files
- Click: NEXT
- Select Debug platform: AVR Simulator
- Select Device: ATMega32 (or else the target controller you use)
- Click: FINISH.

AVRStudio creates the new project. In the left pane,  right click on
the "Sourcefiles" folder, select "Add Files" and select "p16.asm" (or
else the main source file for your controller).

AVRStudio inserts this file into the Sourcefiles list. Open it with a
double click and change the settings for CPU clock and baudrate, if
necessary (I use 8 MHz and 19200 bps foe example).

Assemble by clicking on the "Assemble" button on the toolbar, or by
hitting F7.

Assembling the original source files with AVRASM2 in Atmel AvrStudio
4.12 yields the following errors: (numbered 1. to 5.). (You can open
the respective source files by double-clicking the error lines.
AVRStudio opens the corresponding source file in its editor.)

1. Invalid redifinition of 'RWWSRE'   in atmega32.asm (line 16)
2. Invalid redifinition of 'UDR0'     in atmega32.asm (line 22)

   These values are defined in m32def.inc in the first place (file
   comes with AVRStudio);

   Resolved by commenting out line 16 in atmega32.asm, by commenting
   out line 22 in atmega32.asm and by replacing UDR0 with UDR in
   atmega32.asm and usart.asm source files. (m32def.inc is a system
   file and must not be altered).

      Note: A fix should replace UDR0 in atmega32.asm with a new
      definition (e.g. UDR_0) or replace UDR0 with UDR in amForth
      sources.
      References to UDR0 are in:
        atmega8.asm
        atmega16.asm
        atmega32.asm
        atmega168.frt
        usart.asm
      I replaced UDR0 by UDR (24feb07, ok vor amforth 1.3 - 1.5)!

3. Undefined label TWSIaddr in atmega32.asm (line 68)

   Resolved by changing TWSIaddr into TWIaddr in line 68

4. Overlapping of object code in cseg in usart.asm (line 10)
5. Overlapping of object code in cseg in usart.asm (line 12)

   Atmels assembler does not accept multiple code sequences for the
   same address range (imho doing this is bad practice anyway).

   Resolved by commenting out several lines in usart.asm (lines 6..14)
   like this:

    /* .set pc_ = pc

    .org URXCaddr
      rjmp usart0_rx_isr
    .org UDREaddr
      rjmp usart0_udre_isr

    .org pc_ */

   and by modifying interrupt vectors in atmega32.asm:

   .org    URXCaddr ; USART Receive Complete Interrupt Vector Address
     rjmp usart0_rx_isr
   .org    UDREaddr ; USART Data Register Empty Interrupt Vector Address
     rjmp usart0_udre_isr

   I modestly think the interrrupt vectors belong in atmega32.asm
   anyway (rather than in usart.asm).

The resulting code now assembles with no error and runs on my
evaluation board.

Important note: in AvrStudio you must explicitly save any changed
files before a new build!

Corrections above yield the following values (e.a.):

EQU  URXCaddr     0000001a
EQU  UDREaddr     0000001c
EQU  RWWSRE       00000004
EQU  UDR          0000000c
EQU  UDR0         00000000 ; These values seem to be correct.

Any feedback welcome!

md 24feb07, 17mar07

-- 
derri