Menu
▾
▴
amforth-devel — Development discussion and user support
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(6) |
Mar
(41) |
Apr
(23) |
May
(11) |
Jun
(2) |
Jul
|
Aug
|
Sep
(9) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2008 |
Jan
(6) |
Feb
(1) |
Mar
(23) |
Apr
(18) |
May
(21) |
Jun
(13) |
Jul
(34) |
Aug
(5) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(4) |
| 2009 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(10) |
May
(1) |
Jun
(11) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
(13) |
| 2010 |
Jan
(10) |
Feb
(4) |
Mar
(28) |
Apr
(3) |
May
(38) |
Jun
(22) |
Jul
(92) |
Aug
(154) |
Sep
(218) |
Oct
(45) |
Nov
(20) |
Dec
(1) |
| 2011 |
Jan
(33) |
Feb
(15) |
Mar
(32) |
Apr
(33) |
May
(48) |
Jun
(35) |
Jul
(7) |
Aug
|
Sep
(11) |
Oct
(5) |
Nov
|
Dec
(7) |
| 2012 |
Jan
(56) |
Feb
(11) |
Mar
(6) |
Apr
|
May
(128) |
Jun
(59) |
Jul
(21) |
Aug
(16) |
Sep
(24) |
Oct
(39) |
Nov
(12) |
Dec
(12) |
| 2013 |
Jan
(14) |
Feb
(61) |
Mar
(97) |
Apr
(46) |
May
(13) |
Jun
(23) |
Jul
(12) |
Aug
(25) |
Sep
(9) |
Oct
(81) |
Nov
(73) |
Dec
(45) |
| 2014 |
Jan
(36) |
Feb
(57) |
Mar
(20) |
Apr
(41) |
May
(43) |
Jun
(11) |
Jul
(14) |
Aug
(32) |
Sep
(9) |
Oct
(27) |
Nov
(21) |
Dec
(6) |
| 2015 |
Jan
(14) |
Feb
(23) |
Mar
(1) |
Apr
(19) |
May
(40) |
Jun
(11) |
Jul
(1) |
Aug
(2) |
Sep
(14) |
Oct
(10) |
Nov
(9) |
Dec
(13) |
| 2016 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
|
May
(4) |
Jun
(13) |
Jul
(8) |
Aug
(3) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(7) |
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(9) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(3) |
Jul
(6) |
Aug
|
Sep
(2) |
Oct
(54) |
Nov
(47) |
Dec
(53) |
| 2019 |
Jan
(23) |
Feb
(24) |
Mar
(19) |
Apr
(15) |
May
(5) |
Jun
(34) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(7) |
Apr
(7) |
May
(5) |
Jun
(15) |
Jul
(22) |
Aug
(28) |
Sep
(13) |
Oct
(9) |
Nov
(17) |
Dec
(13) |
| 2021 |
Jan
(5) |
Feb
(1) |
Mar
(1) |
Apr
(9) |
May
(21) |
Jun
(9) |
Jul
|
Aug
(6) |
Sep
(16) |
Oct
|
Nov
(1) |
Dec
(6) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(21) |
Oct
(5) |
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: <vo...@vo...> - 2010-08-29 18:09:42
|
Hello, I've copied the template directory and get weird errors form the words source files. I'm using amforth 3.9. Can anyone give me a comment to work with amforth and how to compile it for ATmega32a? Regards, HUE \a |
|
From: pito <pi...@vo...> - 2010-08-29 18:01:10
|
The test cases are designed specifically to se how it handles large and small numbers. The cases 1-3 are the same as 4-6, the later have only minus sign with those 10000 numbers. All the results shall be by design the integer number 31415 (visualised by "10000 x Pi" - as we do not have float format yet). The Pi is simply multiplied or/and divided by large numbers (as we do not have float input yet, it is done by several multiplication/division by 10000). The results are: > test1 31415 ok > test2 31415 ok > test3 |significand| > 16777215 Here the sign is chabged only: > test4 |significand| > 16777215 > test5 31438 ok > test6 |significand| > 16777215 > My current understanding is the division is cousing issues. The lost of significant figures shall not be the case - see the test 1: tmp = pi / (10000^5) pi = tmp * 10000^6 (correct result 31415). The test 2: tmp = pi / 10000 / 10000 pi = tmp * 10000^3 (correct result 31415). Te test 3: tmp = pi / 10000 / 10000 /10000 pi = tmp * 10000^4 (error). The test4-6 are same as the above one, but with minus sign at 10000. So the result shall be 31415 (when ignoring the sign). As you may see from previous test the f/ is sensitive to signs of the operands and gives unpecise results - see for example test5 result. Pito. ----- PŮVODNÍ ZPRÁVA ----- Od: "Leon N Maurer" <leo...@gm...> Komu: amf...@li... Předmět: Re: [Amforth-devel] Float testing - small/large numbers Datum: 29.8.2010 - 19:17:31 > I don't have my device handy so I can't test your > code. Could you be a little > more clear about which ones failed, what the > results are supposed to be, and > what the results actually are? (When you write > "the result shall be -31415", > is that what it's supposed to be, what it actualy > is, or something else?) > > It looks like you're dividing and then multiplying > by very large powers of 10. > I wouldn't be surprised if you loose some > significant figures by doing this. > -Leon > > ------------------------------------------------------------------------------ > > Sell apps to millions through the Intel(R) > Atom(Tm) Developer Program > Be part of this innovative community and reach > millions of netbook users > worldwide. Take advantage of special opportunities > to increase revenue and > speed time-to-market. Join now, and jumpstart your > future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: pito <pi...@vo...> - 2010-08-29 17:38:37
|
Leon, no it is not about the rounding, the bug was in my source: 1 s>f 100(0)<<<<here]]] s>f f/ fconstant _1000th. Of course, I do not expect decimal places..(:-)). Pito ----- PŮVODNÍ ZPRÁVA ----- Od: "Leon N Maurer" <leo...@gm...> Komu: amf...@li... Předmět: Re: [Amforth-devel] Some useful Float Constants Datum: 29.8.2010 - 19:19:49 > Is the bug that it returns 13951 but the > calculator returns > 13951.906691388013? That should be expected > because f>s truncates the > fractional part -- it doesn't round. > -Leon > > >Sunday 29 August 2010 > >From: "pito" <pi...@vo...> > >Subject: Re: Some useful Float Constants > > 1 bug (_thousand) removed: > > ... > > > Ex1: > > > _pi _e _ln2 _sqrt2half 10000 s>f _third f* f* > > > f* f* f* f>s . > > > > > > 13951 ok > > > > > .s > > > > ok > > Calc: 13951.906691388013 > > Pito > > ------------------------------------------------------------------------------ > > Sell apps to millions through the Intel(R) > Atom(Tm) Developer Program > Be part of this innovative community and reach > millions of netbook users > worldwide. Take advantage of special opportunities > to increase revenue and > speed time-to-market. Join now, and jumpstart your > future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Leon N M. <leo...@gm...> - 2010-08-29 17:19:57
|
Is the bug that it returns 13951 but the calculator returns 13951.906691388013? That should be expected because f>s truncates the fractional part -- it doesn't round. -Leon >Sunday 29 August 2010 >From: "pito" <pi...@vo...> >Subject: Re: Some useful Float Constants > 1 bug (_thousand) removed: ... > Ex1: > > _pi _e _ln2 _sqrt2half 10000 s>f _third f* f* f* f* f* f>s . > > 13951 ok > > > .s > > ok > Calc: 13951.906691388013 > Pito |
|
From: Leon N M. <leo...@gm...> - 2010-08-29 17:17:40
|
I don't have my device handy so I can't test your code. Could you be a little more clear about which ones failed, what the results are supposed to be, and what the results actually are? (When you write "the result shall be -31415", is that what it's supposed to be, what it actualy is, or something else?) It looks like you're dividing and then multiplying by very large powers of 10. I wouldn't be surprised if you loose some significant figures by doing this. -Leon |
|
From: pito <pi...@vo...> - 2010-08-29 16:32:54
|
Leon, simple testing of the floats f*, f/. Some cases results are in error. It seems division is sensitive. Not sure about the result's sign, however the result shall be 31415 in all cases. ------------------- \ test1 float small and large numbers \ needs float constant _pi marker _testfloat_ : test1 10000 s>f fdup fdup fdup fdup fdup f* f* f* f* f* _pi fswap f/ 10000 s>f fdup fdup fdup fdup fdup fdup f* f* f* f* f* f* f* f>s . ( the result shall be 31415 ) ; : test2 _pi 10000 s>f f/ 10000 s>f f/ 10000 s>f fdup fdup f* f* f* f>s . ( the result shall be 31415 ) ; : test3 _pi 10000 s>f f/ 10000 s>f f/ 10000 s>f f/ 10000 s>f fdup fdup fdup f* f* f* f* f>s . ( the result shall be 31415 ) ; : test4 -10000 s>f fdup fdup fdup fdup fdup f* f* f* f* f* _pi fswap f/ 10000 s>f fdup fdup fdup fdup fdup fdup f* f* f* f* f* f* f* f>s . ( the result shall be 31415 ) ; : test5 _pi -10000 s>f f/ 10000 s>f f/ -10000 s>f fdup fdup f* f* f* f>s . ( the result shall be 31415 ) ; : test6 _pi -10000 s>f f/ 10000 s>f f/ 10000 s>f f/ -10000 s>f fdup fdup fdup f* f* f* f* f>s . ( the result shall be -31415 ) ; ------------ Pito |
|
From: pito <pi...@vo...> - 2010-08-29 14:10:04
|
1 bug (_thousand) removed: marker _floatconstants_ \ some float constants 355 s>f 113 s>f f/ fconstant _pi 355 s>f 226 s>f f/ fconstant _pi_half 355 s>f 452 s>f f/ fconstant _pi_quarter 8119 s>f 5741 s>f f/ fconstant _sqrt2 5741 s>f 8119 s>f f/ fconstant _sqrt2half 13755 s>f 7953 s>f f/ fconstant _sqrt3 27379 s>f 8658 s>f f/ fconstant _sqrt10 25946 s>f 9545 s>f f/ fconstant _e 4319 s>f 6231 s>f f/ fconstant _ln2 5225 s>f 4756 s>f f/ fconstant _ln3 12381 s>f 5377 s>f f/ fconstant _ln10 2718 s>f 9029 s>f f/ fconstant _log2 1074 s>f 2251 s>f f/ fconstant _log3 10691 s>f 462 s>f f/ fconstant _e**pi 26120 s>f 1163 s>f f/ fconstant _pi**e 1 s>f 2 s>f f/ fconstant _half 1 s>f 3 s>f f/ fconstant _third 1 s>f 10 s>f f/ fconstant _10th 1 s>f 100 s>f f/ fconstant _100th 1 s>f 1000 s>f f/ fconstant _1000th 5 s>f 127 s>f f/ fconstant _mm2inch Ex1: > _pi _e _ln2 _sqrt2half 10000 s>f _third f* f* f* f* f* f>s . 13951 ok > .s ok Calc: 13951.906691388013 Pito ----- PŮVODNÍ ZPRÁVA ----- Od: "pito" <pi...@vo...> Komu: pi...@vo..., leo...@gm..., amf...@li... Předmět: Some useful Float Constants Datum: 29.8.2010 - 15:07:46 > Hi, here are some useful constants for Leon's > float lib. > Precision ~10^-8 or better. Pito > > ____________________ > > marker _floatconstants_ > > \ some float constants > > 355 s>f 113 s>f f/ fconstant _pi > > 355 s>f 226 s>f f/ fconstant _pi_half > > 355 s>f 452 s>f f/ fconstant _pi_quarter > > 8119 s>f 5741 s>f f/ fconstant _sqrt2 > > 5741 s>f 8119 s>f f/ fconstant _sqrt2half > > 13755 s>f 7953 s>f f/ fconstant _sqrt3 > > 27379 s>f 8658 s>f f/ fconstant _sqrt10 > > 25946 s>f 9545 s>f f/ fconstant _e > > 4319 s>f 6231 s>f f/ fconstant _ln2 > > 5225 s>f 4756 s>f f/ fconstant _ln3 > > 12381 s>f 5377 s>f f/ fconstant _ln10 > > 2718 s>f 9029 s>f f/ fconstant _log2 > > 1074 s>f 2251 s>f f/ fconstant _log3 > > 10691 s>f 462 s>f f/ fconstant _e**pi > > 26120 s>f 1163 s>f f/ fconstant _pi**e > > 1 s>f 2 s>f f/ fconstant _half > > 1 s>f 3 s>f f/ fconstant _third > > 1 s>f 10 s>f f/ fconstant _10th > > 1 s>f 100 s>f f/ fconstant _100th > > 1 s>f 100 s>f f/ fconstant _1000th > > 5 s>f 127 s>f f/ fconstant _mm2inch > > ______________________________ > > Ex: > > 1000 s>f _mm2inch f* f>s . > 39 ok > > 10000 s>f _mm2inch f* f>s . > 393 ok > > 100 s>f fdup f* _pi f* f>s . > 31415 ok > > > |
|
From: pito <pi...@vo...> - 2010-08-29 13:07:53
|
Hi, here are some useful constants for Leon's float lib. Precision ~10^-8 or better. Pito ____________________ marker _floatconstants_ \ some float constants 355 s>f 113 s>f f/ fconstant _pi 355 s>f 226 s>f f/ fconstant _pi_half 355 s>f 452 s>f f/ fconstant _pi_quarter 8119 s>f 5741 s>f f/ fconstant _sqrt2 5741 s>f 8119 s>f f/ fconstant _sqrt2half 13755 s>f 7953 s>f f/ fconstant _sqrt3 27379 s>f 8658 s>f f/ fconstant _sqrt10 25946 s>f 9545 s>f f/ fconstant _e 4319 s>f 6231 s>f f/ fconstant _ln2 5225 s>f 4756 s>f f/ fconstant _ln3 12381 s>f 5377 s>f f/ fconstant _ln10 2718 s>f 9029 s>f f/ fconstant _log2 1074 s>f 2251 s>f f/ fconstant _log3 10691 s>f 462 s>f f/ fconstant _e**pi 26120 s>f 1163 s>f f/ fconstant _pi**e 1 s>f 2 s>f f/ fconstant _half 1 s>f 3 s>f f/ fconstant _third 1 s>f 10 s>f f/ fconstant _10th 1 s>f 100 s>f f/ fconstant _100th 1 s>f 100 s>f f/ fconstant _1000th 5 s>f 127 s>f f/ fconstant _mm2inch ______________________________ Ex: > 1000 s>f _mm2inch f* f>s . 39 ok > 10000 s>f _mm2inch f* f>s . 393 ok > 100 s>f fdup f* _pi f* f>s . 31415 ok > |
|
From: pito <pi...@vo...> - 2010-08-29 09:24:39
|
Some more test cases: > -1 s>f 30000 s>f f/ 10000 s>f f* 30000 s>f f* f>s . -10009 ok > -1 s>f 30000 s>f f/ -10000 s>f f* 30000 s>f f* f>s . 10004 ok > -1 s>f -30000 s>f f/ -10000 s>f f* 30000 s>f f* f>s . -10004 ok > -1 s>f -30000 s>f f/ -10000 s>f f* -30000 s>f f* f>s . 10003 ok > 1 s>f 30000 s>f f/ 10000 s>f f* -30000 s>f f* f>s . -10000 ok > -1 s>f -30000 s>f f/ -10000 s>f f* -30000 s>f f* f>s . 10003 ok > -1 s>f 30000 s>f f/ 10000 s>f f* -30000 s>f f* f>s . 10008 ok > P. ----- PŮVODNÍ ZPRÁVA ----- Od: "pito" <pi...@vo...> Komu: leo...@gm..., amf...@li... Předmět: Re: [Amforth-devel] f* and f/ Datum: 29.8.2010 - 11:09:03 > Leon, I've found out finally I am desperate to > test the fractions > and the float so I did: > > 1 s>f 30000 s>f f/ 10000 s>f f* 30000 s>f f* f>s > > . > > 9999 ok > > > Great! Thanks! > PS: as the float source is for me a rocket science > let me ask you a > naive question - when ready the single precision - > is an enhancement > to double a significant rework (in the future)? > Pito > > > ----- PŮVODNÍ ZPRÁVA ----- > Od: "Leon Nathaniel Maurer" > <leo...@gm...> > Komu: amf...@li... > Předmět: [Amforth-devel] f* and f/ > Datum: 29.8.2010 - 5:11:39 > > > It looks like they're good to go: > > > > > 70 s>f -8 s>f f/ 100 s>f f* f>s . > > -875 ok > > > > I'll try to get some better input and output > > functions worked out this week. > > -Leon > > > > ------------------------------------------------------------------------------ > > > > > > Sell apps to millions through the Intel(R) > > Atom(Tm) Developer Program > > Be part of this innovative community and reach > > millions of netbook users > > worldwide. Take advantage of special > > opportunities > > > to increase revenue and > > speed time-to-market. Join now, and jumpstart > > your > > > future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Amforth-devel mailing list > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > ------------------------------------------------------------------------------ > > Sell apps to millions through the Intel(R) > Atom(Tm) Developer Program > Be part of this innovative community and reach > millions of netbook users > worldwide. Take advantage of special opportunities > to increase revenue and > speed time-to-market. Join now, and jumpstart your > future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: pito <pi...@vo...> - 2010-08-29 09:09:15
|
Leon, I've found out finally I am desperate to test the fractions and the float so I did: > 1 s>f 30000 s>f f/ 10000 s>f f* 30000 s>f f* f>s . 9999 ok > Great! Thanks! PS: as the float source is for me a rocket science let me ask you a naive question - when ready the single precision - is an enhancement to double a significant rework (in the future)? Pito ----- PŮVODNÍ ZPRÁVA ----- Od: "Leon Nathaniel Maurer" <leo...@gm...> Komu: amf...@li... Předmět: [Amforth-devel] f* and f/ Datum: 29.8.2010 - 5:11:39 > It looks like they're good to go: > > > 70 s>f -8 s>f f/ 100 s>f f* f>s . > -875 ok > > I'll try to get some better input and output > functions worked out this week. > -Leon > > ------------------------------------------------------------------------------ > > Sell apps to millions through the Intel(R) > Atom(Tm) Developer Program > Be part of this innovative community and reach > millions of netbook users > worldwide. Take advantage of special opportunities > to increase revenue and > speed time-to-market. Join now, and jumpstart your > future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Leon N. M. <leo...@gm...> - 2010-08-29 03:11:45
|
It looks like they're good to go: > 70 s>f -8 s>f f/ 100 s>f f* f>s . -875 ok I'll try to get some better input and output functions worked out this week. -Leon |
|
From: pito <pi...@vo...> - 2010-08-29 00:31:30
|
Marcin, MY BIG THANKS!! I simply thought the RAM ends at 0x4000.. So 0x40af = 16559 what is aproximately the magic number 16557 !!! Thanks again and sorry for my spaming the list.. Good night, Pito. ----- PŮVODNÍ ZPRÁVA ----- Od: "Marcin Cieslak" <sa...@sa...> Komu: "pito" <pi...@vo...> Předmět: Re: [Amforth-devel] .s on 1284p Datum: 29.8.2010 - 2:16:44 > On Sun, 29 Aug 2010, pito wrote: > > > Marcin, when I do .s I see an address higher > > then 16383 (16557). So > > > it is an indication for me something must be > > wrong there. Matthias > > > sent the .s definition, from what I can see is > > he prints out the > > > address (of RAM - I do assume - when talking > > data stack), and as I > > > have shown the number is 16557.. So outside the > > RAM space. Maybe I > > > am mistaken.. Just explain to me plz.. Assembly > > listing of what, > > > please? P. > > Please see m1264Pdef.inc file in your AVRASM > directory: > > ---8<------------------------------ > .equ SRAM_START = 0x0100 > .equ SRAM_SIZE = 16384 > .equ RAMEND = 0x40ff > .equ XRAMEND = 0x0000 > ---8<------------------------------ > > RAM begins at $0100 and ends at $40ff. > > So you have in your listing: > > 00002a ff 40 .dw rstackstart ; USER_RP^M > 00002c af 40 .dw stackstart ; USER_SP0^M > 00002e af 40 .dw stackstart ; USER_SP^M > > Your return stack starts at $40ff and grows down > and your data stack starts at $40af and grows > down. > > Most ATmegas have stack at $0100, but some AVR > CPUs have it at $0040, $0060 or $0200. > > My ATmega164P has RAM from $0100 until $08ff, > so my rstack starts at $08ff and my data stack > grows down from $08af. > > Hope it helps! > > --Marcin |
|
From: Marcin C. <sa...@sa...> - 2010-08-29 00:16:52
|
On Sun, 29 Aug 2010, pito wrote: > Marcin, when I do .s I see an address higher then 16383 (16557). So > it is an indication for me something must be wrong there. Matthias > sent the .s definition, from what I can see is he prints out the > address (of RAM - I do assume - when talking data stack), and as I > have shown the number is 16557.. So outside the RAM space. Maybe I > am mistaken.. Just explain to me plz.. Assembly listing of what, > please? P. Please see m1264Pdef.inc file in your AVRASM directory: ---8<------------------------------ .equ SRAM_START = 0x0100 .equ SRAM_SIZE = 16384 .equ RAMEND = 0x40ff .equ XRAMEND = 0x0000 ---8<------------------------------ RAM begins at $0100 and ends at $40ff. So you have in your listing: 00002a ff 40 .dw rstackstart ; USER_RP^M 00002c af 40 .dw stackstart ; USER_SP0^M 00002e af 40 .dw stackstart ; USER_SP^M Your return stack starts at $40ff and grows down and your data stack starts at $40af and grows down. Most ATmegas have stack at $0100, but some AVR CPUs have it at $0040, $0060 or $0200. My ATmega164P has RAM from $0100 until $08ff, so my rstack starts at $08ff and my data stack grows down from $08af. Hope it helps! --Marcin |
|
From: pito <pi...@vo...> - 2010-08-28 23:58:04
|
Marcin, the .lst I've sent you (zip) produces this: > ver amforth 4.0 ATmega1284P ok > 123 ok > .s 0 16557 123 ok >456 ok > .s 0 16555 456 1 16557 123 ok > Pito. ----- PŮVODNÍ ZPRÁVA ----- Od: "Marcin Cieslak" <sa...@sa...> Komu: "pito" <pi...@vo...> Předmět: Re: [Amforth-devel] .s on 1284p Datum: 29.8.2010 - 1:45:40 > On Sun, 29 Aug 2010, pito wrote: > > > I hope you are asking for this .lst (:-)). The > > whole .lst is 280k. > > > Can you gzip it and publish somewhere? Or mail me > privately. > > --Marcin |
|
From: Marcin C. <sa...@sa...> - 2010-08-28 23:45:48
|
On Sun, 29 Aug 2010, pito wrote: > I hope you are asking for this .lst (:-)). The whole .lst is 280k. Can you gzip it and publish somewhere? Or mail me privately. --Marcin |
|
From: pito <pi...@vo...> - 2010-08-28 23:43:36
|
Marcin, here is the .s part of the .lst of amforth for 1284p: .include "words/dot-s.asm" ; R( -- ) ; stack dump VE_DOTS: 000888 ff02 .dw $ff02 000889 732e .db ".s" 00088a 0881 .dw VE_HEAD .set VE_HEAD = VE_DOTS XT_DOTS: 00088b f00a .dw DO_COLON PFA_DOTS: 00088c f2a1 .dw XT_SP_FETCH 00088d 05db .dw XT_DEPTH 00088e f255 .dw XT_1MINUS 00088f f153 .dw XT_ZERO 000890 f2c4 .dw XT_DOQDO 000891 089f .dw PFA_DOTS2 PFA_DOTS1: 000892 f0c2 .dw XT_DUP 000893 f2da .dw XT_I 000894 f0c2 .dw XT_DUP 000895 0884 .dw XT_UDOT 000896 f22b .dw XT_2STAR 000897 f1bc .dw XT_PLUS 000898 f0c2 .dw XT_DUP 000899 0884 .dw XT_UDOT 00089a f09a .dw XT_FETCH 00089b 0884 .dw XT_UDOT 00089c 0344 .dw XT_CR 00089d f2e2 .dw XT_DOLOOP 00089e 0892 .dw PFA_DOTS1 PFA_DOTS2: 00089f f0ea .dw XT_DROP 0008a0 f048 .dw XT_EXIT I hope you are asking for this .lst (:-)). The whole .lst is 280k. Pito. ----- PŮVODNÍ ZPRÁVA ----- Od: "Marcin Cieslak" <sa...@sa...> Komu: "Everything around amforth" <amf...@li...> Předmět: Re: [Amforth-devel] .s on 1284p Datum: 28.8.2010 - 22:30:10 > On Sat, 28 Aug 2010, pito wrote: > > > Matthias, > > something is telling me that the adress (the > > 16557)cannot be higher > > > than > > 16384. P. > > Do you have an assembly .lst listing or can > produce one? > > --Marcin |
|
From: Marcin C. <sa...@sa...> - 2010-08-28 23:40:52
|
On Sun, 29 Aug 2010, pito wrote: > Marcin, when I do .s I see an address higher then 16383 (16557). So > it is an indication for me something must be wrong there. Matthias > sent the .s definition, from what I can see is he prints out the > address (of RAM - I do assume - when talking data stack), and as I > have shown the number is 16557.. So outside the RAM space. Maybe I > am mistaken.. Just explain to me plz.. Assembly listing of what, > please? P. When you run assembler (avra, avrasm2), please specify an option: -l listfilename Makefiles and antfiles supplied by amforth usually have this option enabled, so you might already have a "<imagename>.lst" file already. This is so-called assembly listing. --Marcin |
|
From: pito <pi...@vo...> - 2010-08-28 23:20:01
|
Marcin, when I do .s I see an address higher then 16383 (16557). So it is an indication for me something must be wrong there. Matthias sent the .s definition, from what I can see is he prints out the address (of RAM - I do assume - when talking data stack), and as I have shown the number is 16557.. So outside the RAM space. Maybe I am mistaken.. Just explain to me plz.. Assembly listing of what, please? P. ----- PŮVODNÍ ZPRÁVA ----- Od: "Marcin Cieslak" <sa...@sa...> Komu: "Everything around amforth" <amf...@li...> Předmět: Re: [Amforth-devel] .s on 1284p Datum: 28.8.2010 - 22:30:10 > On Sat, 28 Aug 2010, pito wrote: > > > Matthias, > > something is telling me that the adress (the > > 16557)cannot be higher > > > than > > 16384. P. > > Do you have an assembly .lst listing or can > produce one? > > --Marcin > |
|
From: Marcin C. <sa...@sa...> - 2010-08-28 20:30:21
|
On Sat, 28 Aug 2010, pito wrote: > Matthias, > something is telling me that the adress (the 16557)cannot be higher > than > 16384. P. Do you have an assembly .lst listing or can produce one? --Marcin |
|
From: pito <pi...@vo...> - 2010-08-28 19:30:54
|
Matthias, something is telling me that the adress (the 16557)cannot be higher than 16384. P. ----- PŮVODNÍ ZPRÁVA ----- Od: "Matthias Trute" <mt...@we...> Komu: "Everything around amforth" <amf...@li...> Předmět: Re: [Amforth-devel] .s on 1284p Datum: 28.8.2010 - 14:41:15 > Pito, > > > it is not stack address, but the 16557 does not > > fit somehow...p. > > > current implementation is like > > : .s > sp@ depth 1- 0 ?do > dup i > dup u. ( gives the "index" ) > 2* + dup u. ( prints the address ) > @ u. ( prints the current content ) > cr > loop > drop > ; > > (just reverse-coded manually from dot-s.asm) > > Matthias > > > > ------------------------------------------------------------------------------ > > Sell apps to millions through the Intel(R) > Atom(Tm) Developer Program > Be part of this innovative community and reach > millions of netbook users > worldwide. Take advantage of special opportunities > to increase revenue and > speed time-to-market. Join now, and jumpstart your > future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: <an...@ki...> - 2010-08-28 14:17:58
|
I saw this on thingiverse and thought of you.... http://www.thingiverse.com/thing:3901 |
|
From: Matthias T. <mt...@we...> - 2010-08-28 12:41:25
|
Pito,
> it is not stack address, but the 16557 does not fit somehow...p.
current implementation is like
: .s
sp@ depth 1- 0 ?do
dup i
dup u. ( gives the "index" )
2* + dup u. ( prints the address )
@ u. ( prints the current content )
cr
loop
drop
;
(just reverse-coded manually from dot-s.asm)
Matthias
|
|
From: pito <pi...@vo...> - 2010-08-28 08:43:26
|
it is not stack address, but the 16557 does not fit somehow...p. ----- PŮVODNÍ ZPRÁVA ----- Od: "pito" <pi...@vo...> Komu: amf...@li... Předmět: [Amforth-devel] .s on 1284p Datum: 27.8.2010 - 23:52:16 > Hi, > is this stack address correct (decimal)? > > > .s > ok > > 123 > ok > > .s > 0 16557 123 > ok > > 456 > ok > > .s > 0 16555 456 > 1 16557 123 > ok > > > p. > > > ------------------------------------------------------------------------------ > > Sell apps to millions through the Intel(R) > Atom(Tm) Developer Program > Be part of this innovative community and reach > millions of netbook users > worldwide. Take advantage of special opportunities > to increase revenue and > speed time-to-market. Join now, and jumpstart your > future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: pito <pi...@vo...> - 2010-08-28 07:16:49
|
Crystal 25MHZ (comm 19k2): > ver amforth 4.0 ATmega1284P ok > primes 10 iterations. 6412 primes found, ok > Sieve: size 32000, 10 iterations in 50sec = 5.0sec/iter, @25MHz P. ----- PŮVODNÍ ZPRÁVA ----- Od: "pito" <pi...@vo...> Komu: pi...@vo..., an...@ki..., amf...@li... Předmět: Re: [Amforth-devel] 1284p compilation Datum: 28.8.2010 - 9:08:14 > Crystal 22MHZ (comm 19k2): > > ver > amforth 4.0 ATmega1284P ok > > primes > > 10 iterations. > 6412 primes found, ok > > > Sieve: size 32000, 10 iterations in 57sec = > 5.7sec/iter, @22MHz > P. > > ----- PŮVODNÍ ZPRÁVA ----- > Od: "pito" <pi...@vo...> > Komu: pi...@vo..., an...@ki..., > amf...@li... > Předmět: Re: [Amforth-devel] 1284p compilation > Datum: 28.8.2010 - 8:56:56 > > > Now I've changed the fuses to: > > l=F7 h=D9 e=FF (full swing osc., slow rising) > > crystal = 20MHz (comm at 19k2 as the usart > > settings routine is quite > > intolerant as you know..): > > > ver > > amforth 4.0 ATmega1284P ok > > > primes > > > > 1 iterations. > > 6412 primes found, ok > > > > > Sieve: size 32000, 1 iteration done in 6sek > > @20MHz. > > Pito. > > > > ----- PŮVODNÍ ZPRÁVA ----- > > Od: "pito" <pi...@vo...> > > Komu: an...@ki..., > > amf...@li... > > Předmět: Re: [Amforth-devel] 1284p compilation > > Datum: 28.8.2010 - 8:19:06 > > > > > 11.05920 MHz. I may do experiments with > > > overclocking today.. Pito > > > > > > ----- PŮVODNÍ ZPRÁVA ----- > > > Od: an...@ki... > > > Komu: amf...@li... > > > Předmět: Re: [Amforth-devel] 1284p compilation > > > Datum: 28.8.2010 - 1:03:51 > > > > > > > OH something I forgot to ask. What crystal > > > > frequency are you running it > > > > at ?? > > > > > > > > Cheers > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > Sell apps to millions through the > > > > > > > Intel(R) > > > > > > > > > Atom(Tm) Developer Program > > > Be part of this innovative community and reach > > > millions of netbook users > > > worldwide. Take advantage of special > > > opportunities > > > > to increase revenue and > > > speed time-to-market. Join now, and jumpstart > > > your > > > > future. > > > http://p.sf.net/sfu/intel-atom-d2d > > > _______________________________________________ > > > > > Amforth-devel mailing list > > > Amf...@li... > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > > > > |
|
From: pito <pi...@vo...> - 2010-08-28 07:08:23
|
Crystal 22MHZ (comm 19k2): > ver amforth 4.0 ATmega1284P ok > primes 10 iterations. 6412 primes found, ok > Sieve: size 32000, 10 iterations in 57sec = 5.7sec/iter, @22MHz P. ----- PŮVODNÍ ZPRÁVA ----- Od: "pito" <pi...@vo...> Komu: pi...@vo..., an...@ki..., amf...@li... Předmět: Re: [Amforth-devel] 1284p compilation Datum: 28.8.2010 - 8:56:56 > Now I've changed the fuses to: > l=F7 h=D9 e=FF (full swing osc., slow rising) > crystal = 20MHz (comm at 19k2 as the usart > settings routine is quite > intolerant as you know..): > > ver > amforth 4.0 ATmega1284P ok > > primes > > 1 iterations. > 6412 primes found, ok > > > Sieve: size 32000, 1 iteration done in 6sek > @20MHz. > Pito. > > ----- PŮVODNÍ ZPRÁVA ----- > Od: "pito" <pi...@vo...> > Komu: an...@ki..., > amf...@li... > Předmět: Re: [Amforth-devel] 1284p compilation > Datum: 28.8.2010 - 8:19:06 > > > 11.05920 MHz. I may do experiments with > > overclocking today.. Pito > > > > ----- PŮVODNÍ ZPRÁVA ----- > > Od: an...@ki... > > Komu: amf...@li... > > Předmět: Re: [Amforth-devel] 1284p compilation > > Datum: 28.8.2010 - 1:03:51 > > > > > OH something I forgot to ask. What crystal > > > frequency are you running it > > > at ?? > > > > > > Cheers > > > > > > > > ------------------------------------------------------------------------------ > > > > > > Sell apps to millions through the Intel(R) > > Atom(Tm) Developer Program > > Be part of this innovative community and reach > > millions of netbook users > > worldwide. Take advantage of special > > opportunities > > > to increase revenue and > > speed time-to-market. Join now, and jumpstart > > your > > > future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Amforth-devel mailing list > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > |
8 messages has been excluded from this view by a project administrator.
