prof_braino said...
Looks like a bug, since create is defined as leaving the 'created' word's data field on the stack. I will open an issue report for this.
I think the values placed in the array using NNN w, can still be modified, if you want CONSTANT, not variable, I think you need to use literals (litw, litl); but I haven't tried these, since I usually don't.
Thanks for raising the bug report. Regarding constants, well it's still RAM so unless I go through official words (not sure if it's enforced though) I can do whatever I want with this memory
kuroneko said...
Regarding constants, well it's still RAM so unless I go through official words (not sure if it's enforced though) I can do whatever I want with this memory [noparse]:)[/noparse]
Yeah, I always wondered about this. I think there is something different about the way a constant is made when the dictionary is in rom, and /or is a value that is forbidden to change. I saw a case where the 'constant' was processed in fewer instructions than the variable, so they defined 'constants' and used them as variables. Like you said its all ram, and forth, and its you do what ever you you do.
In propforth, there is a long literal (litl) and word literal (litw) as well as constant and wconstant. I think the literals are for assembler, and the constants for forth, and they are supposed to take less memory and/or execute faster than variables. This might of use to caskaz for his LCD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Hi.
I made sine_wave.
But very slow.
Spin is 800msec for 1-cycle.
PropBasic is 16msec.
Assembler is 9msec.
PropForth is 15seconds.
Is this correct? Somewhere wrong?
More detail on caskas's slow loop issue:
We looked at the slow loop issue.
In assembler, looping takes 4 clock cycles.
In propforth, looping takes around 50-60 instructions, about 224 clock cycles due to the nature of the dictionary threading.
Expect propforth to take around 50 times longer than assembler to execute loops.
See speed.f on google code.
We had a question about the 9ms for assembler to do the loops, we got 100ms.
2,097,152 loops * 4 assembler cycles = 8,388,608 total cycles
8,388,608 total cycles / 80 mhz = about .10000 = 100 ms or .1 seconds in assembler
2,097,152 loops in straight assembler should be 100 ms for this many loops (theoretical minimum).
For propforth I calculated:
2,097,152 loops * 224 assembler cycles = 469,762,048 total cycles
469,762,048 total cycles / 80 mhz = about 5.8 seconds (theoretical minimum)
The actual observed execution time is 15 seconds, so the calculations seem reasonable. There's at over 2 million actions on the data stack and the return stack, which could account for the additional time.
Again, this is just the the loops from the code example, without the waitcnt's in the loop body.
So it looks like propforth is working as expected, and the 50 times slower execution of loops is the trade-off for interactive development. In cases where the slower loop execution is unacceptable, the technique would be to optimize everything between do and loop (including the loop body) in assembler.
I didn't write any test programs to do 2 million loops in spin or prop basic, but if the calculations are correct, I would expect the basic to take longer than 16 milliseconds.
I can't understand well your calculation.
Why "Decimal 256 * 8,192 = 2,097,152 loops"?
1-cycle for sin_wave is 8192-point.
I checked 1-cycle's sin_wave time by using osciloscope.
It was approximately 9msec(assembler).
It was approximately 15seconds(prop_forth).
Sorry, I am having trouble understanding your posts. I'm only getting half the details.
Your original post states 100 loops of 2000 loops, the default is hex, converting to decimal is the above. On my rig, just these 200,000(hex) 2,097,152(decimal) loops took 15 seconds. I thought this was your issue. I did not include the body of your loop code as I am trying to determine the forth overhead, as opposed to trying debug or second guess your algorithm. That would come next.
Now that you have clarified that you actually mean 'one cycle of the inner loop takes 15 seconds', I will do different tests.
Running the speed test for 2000 Hes 8,192 decimal do...loops gave the result
1C02F0 total clock cycles
E0 per loop
This is 1,835,760 decimal clock cycles for 8,192 loops;
1,835,760 cycles / 80,000,000 MHz = 0.02294 seconds, which agrees with the observed completion time for this test.
So the forth overhead for looping 8,192 iterations is about 23 ms. (This also makes sense that forth is a bit slower than assembler, assuming that your assembler code does 8192 iterations in 9ms.)
Therefore the remaining 14 seconds taken by your sine wave program must be due to the loop body.
I ran the code you previously posted for sin, and I added "dup ." before "waitcnt"
It is displaying '23F18' as the value being sent to waitcnt.
I notice that 23F18 (h) * 2000 (h) = 47f0 2000 (h) = 1,206,919,168 (d)
This may be a coincidence, but it may be related to your error. Although I don't know the value of the system counter when waitcnt is called, I guess there may be something in the way you are using waitcnt.
In any case, it still looks like propforth is working correctly.
Sorry, I had mistakes.
Maybe I did somthing wrong.
I changed "clkfreq 21f u/ dT L!" to "clkfreq 19B4 u/ dT L!"
1-cycle for sin is 1.2second.
Sin_loop stopped at "clkfreq 19B5 u/ dT L!"
.... mistakes.
I changed "clkfreq 21f u/ dT L!" to "clkfreq 19B4 u/ dT L!" 1-cycle for sin is 1.2 second.
Sin_loop stopped at "clkfreq 19B5 u/ dT L!"
Prop_forth is a little slower than spin.
I have to disagree with your statement that propforth is slower than spin until we know what your code is intended to do and we know that it is functioning correctly. We know that propforth is slower than assembler, and we have a pretty good idea by how much. While it is possible that Spin could be faster than propforth, time for propforth to do this cycle of 8192 loops PLUS your loop body (assuming your assembler, PropBasic, and Spin code used for comparison is all correct) should be closer to 24ms than 12000ms.
The example usage of 'waitcnt' in spin from page 322 in the propeller manual is
waitcnt (50000 + cnt)
Since the previous test showed that propforth does 8192 iterations in 23 ms, I do not believe that your forth code is correct if it takes 1.2 seconds or 12000ms.
It looks like your error is is that you want to wait for a delta, but instead you are waiting for 19b4 to appear on the system clock, which has nothing to do with the current system clock value. If this is true, you are calculating the delta OUTSIDE the loop, and the result is stale; and you probably want your code to do like the spin code
waitcnt (19B4 + cnt)
or in forth
cnt COG@ 19B4 + waitcnt
and you want to do this calculation INSIDE your inner loop body when you call waitcnt
This means that ANY code in ANY language must take AT LEAST 0.6 seconds to do the delay you specify.
If you claim that your code works in assembler and only takes 9ms, then I must conclude you used a delay of only 0.0000010986328125 seconds or less.
[ 9ms / 8192 iterations = 0.0000010986328125 seconds per loop ]
If a delay of 1.1ms works in the assembler, the same delay should work with forth. That delay in the forth code would result in a theoretical absolute minimum execution time of 32ms, actual will be longer.
Of course, I have only seen your forth code, and not your assembler, PropBasic, or Spin code used for testing; and I don't know what LCD you are using and cannot determine what the waitcnt delay is doing in there and whether or not it is used correctly, so I really can't say anything more than "you results don't look right".
kuroneko pointed out that waitcnt in propforth 3.2 behaves differently.
I started checking the waitcnt using the speed.f utility from google code, but I did not see the results I expected. I have to do more testing and talk to Sal, I will update my previous posts accordingly. Hopefully we can start look at it this weekend.
The FAQ http://code.google.com/p/propforth/wiki/PropForthFAQ
now has an explanation of the waitcnt word. Please let me know if this is clear and correct. I have not spent time to determine if this agrees or disagrees with caskas's findings, not enough free time, sorry.
fl
variable buffer 1fc allot
wvariable buff_ptr
wvariable x
avariable y
wvariable tmp
I loaded including "fl" to prop.
Error ocurred "3D00 D88 Out of memory" at "variable buffer 1fc allot".
I did copy/paste words excepting "fl" and no error.
I checked about value(1fc).
"variable buffer 10b allot" is OK.
"variable buffer 10c allot" is"3D00 D88 Out of memory".
fl
variable buffer 1fc allot
wvariable buff_ptr
wvariable x
avariable y
wvariable tmp
I loaded including "fl" to prop.
Error ocurred "3D00 D88 Out of memory" at "variable buffer 1fc allot".
I did copy/paste words excepting "fl" and no error.
I checked about value(1fc).
"variable buffer 10b allot" is OK.
"variable buffer 10c allot" is"3D00 D88 Out of memory".
I do mistake or bug for "fl"?
The pointer that the fl word uses to point at the next unused memory location can get corrupted. After the text is interpreted, the pointer is expected to point back to the beginning of unused memory. Sometimes it does not, and thinks that it ran out of memory.
A stack error, interpretation error, or other error can cause this pointer corruption. I saw this a couple times, but in my case I had done a series of errors. After rebooting the prop it worked fine again.
If you can show me how to reproduce the sequence of event that lead to this, we can enter an issue. Otherwise, the recommendation is to reset the system to a know good state after errors.
I display bmp-image inside SD-card on LCD .
LCD is nokia3300-lcd. it use epson's S1D15G10D for controller.
It has 132pixel X 132pixel and color12bit.
SD-card is ver1.
bmp-image is 130pixel X 130pixel and color24bit.
Load nokia3300_1.f using "Send File from TeraTerm.
Load sd_1.f using "Send File from TeraTerm.
Copy/Paste "variavle buffer 1fc allot" inside inside nokia3300_demo.f to TeraTerm.
and then Copy/Paste from fl to end.
Comments
Yeah, I always wondered about this. I think there is something different about the way a constant is made when the dictionary is in rom, and /or is a value that is forbidden to change. I saw a case where the 'constant' was processed in fewer instructions than the variable, so they defined 'constants' and used them as variables. Like you said its all ram, and forth, and its you do what ever you you do.
In propforth, there is a long literal (litl) and word literal (litw) as well as constant and wconstant. I think the literals are for assembler, and the constants for forth, and they are supposed to take less memory and/or execute faster than variables. This might of use to caskaz for his LCD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
I displayed original font(8 X 16) to LCD.
I used 'c,'.
Thanks.
Very Cool!
If I may ask:
Is it 46 symbols for hiragana only? How much memory did it use? Did it fit in regular memory space or did you use extended EEPROM?
Your solution might be helpful to other folks.
Did you ever get around the slow do...loop? If you could show a code snip, I would like to see it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Only 46 symbols for hiragana.
Basically,it is same as LQ020B8UB02_demo.f.
I use Proto board. Not modified.
Please search for assembler code for sine_wave in this forum.
I think you finf out my post.
More detail on caskas's slow loop issue:
We looked at the slow loop issue.
In assembler, looping takes 4 clock cycles.
In propforth, looping takes around 50-60 instructions, about 224 clock cycles due to the nature of the dictionary threading.
Expect propforth to take around 50 times longer than assembler to execute loops.
See speed.f on google code.
We had a question about the 9ms for assembler to do the loops, we got 100ms.
Hex 100 * 2000 = 200,000 loops is
Decimal 256 * 8,192 = 2,097,152 loops
2,097,152 loops * 4 assembler cycles = 8,388,608 total cycles
8,388,608 total cycles / 80 mhz = about .10000 = 100 ms or .1 seconds in assembler
2,097,152 loops in straight assembler should be 100 ms for this many loops (theoretical minimum).
For propforth I calculated:
2,097,152 loops * 224 assembler cycles = 469,762,048 total cycles
469,762,048 total cycles / 80 mhz = about 5.8 seconds (theoretical minimum)
The actual observed execution time is 15 seconds, so the calculations seem reasonable. There's at over 2 million actions on the data stack and the return stack, which could account for the additional time.
Again, this is just the the loops from the code example, without the waitcnt's in the loop body.
So it looks like propforth is working as expected, and the 50 times slower execution of loops is the trade-off for interactive development. In cases where the slower loop execution is unacceptable, the technique would be to optimize everything between do and loop (including the loop body) in assembler.
I didn't write any test programs to do 2 million loops in spin or prop basic, but if the calculations are correct, I would expect the basic to take longer than 16 milliseconds.
I can't understand well your calculation.
Why "Decimal 256 * 8,192 = 2,097,152 loops"?
1-cycle for sin_wave is 8192-point.
I checked 1-cycle's sin_wave time by using osciloscope.
It was approximately 9msec(assembler).
It was approximately 15seconds(prop_forth).
Sorry, I am having trouble understanding your posts. I'm only getting half the details.
Your original post states 100 loops of 2000 loops, the default is hex, converting to decimal is the above. On my rig, just these 200,000(hex) 2,097,152(decimal) loops took 15 seconds. I thought this was your issue. I did not include the body of your loop code as I am trying to determine the forth overhead, as opposed to trying debug or second guess your algorithm. That would come next.
Now that you have clarified that you actually mean 'one cycle of the inner loop takes 15 seconds', I will do different tests.
I used the speed test routine on the propforth downloads: http://propforth.googlecode.com/files/speed.f
Running the speed test for 2000 Hes 8,192 decimal do...loops gave the result
This is 1,835,760 decimal clock cycles for 8,192 loops;
1,835,760 cycles / 80,000,000 MHz = 0.02294 seconds, which agrees with the observed completion time for this test.
So the forth overhead for looping 8,192 iterations is about 23 ms. (This also makes sense that forth is a bit slower than assembler, assuming that your assembler code does 8192 iterations in 9ms.)
Therefore the remaining 14 seconds taken by your sine wave program must be due to the loop body.
I ran the code you previously posted for sin, and I added "dup ." before "waitcnt"
It is displaying '23F18' as the value being sent to waitcnt.
I notice that 23F18 (h) * 2000 (h) = 47f0 2000 (h) = 1,206,919,168 (d)
1,206,919,168 (d) clock cycles / 80,000,000 hz = 15, or 15 seconds.
This may be a coincidence, but it may be related to your error. Although I don't know the value of the system counter when waitcnt is called, I guess there may be something in the way you are using waitcnt.
In any case, it still looks like propforth is working correctly.
Sorry, I had mistakes.
Maybe I did somthing wrong.
I changed "clkfreq 21f u/ dT L!" to "clkfreq 19B4 u/ dT L!"
1-cycle for sin is 1.2second.
Sin_loop stopped at "clkfreq 19B5 u/ dT L!"
Prop_forth is a little slower than spin.
Thanks.
I have to disagree with your statement that propforth is slower than spin until we know what your code is intended to do and we know that it is functioning correctly. We know that propforth is slower than assembler, and we have a pretty good idea by how much. While it is possible that Spin could be faster than propforth, time for propforth to do this cycle of 8192 loops PLUS your loop body (assuming your assembler, PropBasic, and Spin code used for comparison is all correct) should be closer to 24ms than 12000ms.
The example usage of 'waitcnt' in spin from page 322 in the propeller manual is
Since the previous test showed that propforth does 8192 iterations in 23 ms, I do not believe that your forth code is correct if it takes 1.2 seconds or 12000ms.
It looks like your error is is that you want to wait for a delta, but instead you are waiting for 19b4 to appear on the system clock, which has nothing to do with the current system clock value. If this is true, you are calculating the delta OUTSIDE the loop, and the result is stale; and you probably want your code to do like the spin code or in forth and you want to do this calculation INSIDE your inner loop body when you call waitcnt
Lets look at the delay period sent to waitcnt:
19B4 (h) = 6580 (decimal) cycles delay
6580 / 80,000,000 = 0.00008225 seconds delay
0.00008225 second * 8192 cycles = 0.673792 seconds
This means that ANY code in ANY language must take AT LEAST 0.6 seconds to do the delay you specify.
If you claim that your code works in assembler and only takes 9ms, then I must conclude you used a delay of only 0.0000010986328125 seconds or less.
[ 9ms / 8192 iterations = 0.0000010986328125 seconds per loop ]
If a delay of 1.1ms works in the assembler, the same delay should work with forth. That delay in the forth code would result in a theoretical absolute minimum execution time of 32ms, actual will be longer.
Of course, I have only seen your forth code, and not your assembler, PropBasic, or Spin code used for testing; and I don't know what LCD you are using and cannot determine what the waitcnt delay is doing in there and whether or not it is used correctly, so I really can't say anything more than "you results don't look right".
I think it's correct below. Incorrect?
19B4 (h) = 6580 (decimal)
clkfreq(80000000)/6580 = 12158.054(d)
12158 * 12.5nsec = 0.000151975sec
0.000151975 * 8192 = 1.2449792sec
sin.spin(only PUB main)
PUB main | sine, degree, dT, T, w sine := $e000 ctra := %00110 << 26 + 0 dira[0] := 1 dT := clkfreq/10000 '10770 T := cnt repeat repeat degree from 0 to 8190 ' [0 - 360]degree w := $7ff & degree case degree & $1000 0: '1st or 2nd quadrant case degree & $800 0: frqa := word[sine + (w << 1)] << 15 + $7fffffff '1st quadrant other: frqa := word[$f001 - (w << 1)] << 15 + $7fffffff '2nd quadrant' other: case degree & $800 0: frqa := -(word[sine + (w << 1)] << 15) + $7fffffff '3rd quadrant other: frqa := -(word[$f001 - (w << 1)] << 15) + $7fffffff '4th quadrant waitcnt(T += dT)kuroneko pointed out that waitcnt in propforth 3.2 behaves differently.
I started checking the waitcnt using the speed.f utility from google code, but I did not see the results I expected. I have to do more testing and talk to Sal, I will update my previous posts accordingly. Hopefully we can start look at it this weekend.
The FAQ
http://code.google.com/p/propforth/wiki/PropForthFAQ
now has an explanation of the behavior of the CREATE word. Please let me know if this is sufficient.
The FAQ http://code.google.com/p/propforth/wiki/PropForthFAQ
now has an explanation of the waitcnt word. Please let me know if this is clear and correct. I have not spent time to determine if this agrees or disagrees with caskas's findings, not enough free time, sorry.
The FAQ
http://code.google.com/p/propforth/wiki/PropForthFAQ
now has an explanation of the behavior of the \ comment at the end of a line of code. Please let me know if this is sufficient.
Just a minor thing, the system counter used by waitcnt is called cnt not ctra (which is a per cog resource).
Fixed FAQ, thanks for spotting this.
http://forums.parallax.com/showthread.php?p=936909#post936909
I have question below. I loaded including "fl" to prop.
Error ocurred "3D00 D88 Out of memory" at "variable buffer 1fc allot".
I did copy/paste words excepting "fl" and no error.
I checked about value(1fc).
"variable buffer 10b allot" is OK.
"variable buffer 10c allot" is"3D00 D88 Out of memory".
I do mistake or bug for "fl"?
The pointer that the fl word uses to point at the next unused memory location can get corrupted. After the text is interpreted, the pointer is expected to point back to the beginning of unused memory. Sometimes it does not, and thinks that it ran out of memory.
A stack error, interpretation error, or other error can cause this pointer corruption. I saw this a couple times, but in my case I had done a series of errors. After rebooting the prop it worked fine again.
If you can show me how to reproduce the sequence of event that lead to this, we can enter an issue. Otherwise, the recommendation is to reset the system to a know good state after errors.
Please note: PropForth 3.4 is now the current release as of 2010-Sept-05
http://forums.parallax.com/showthrea...909#post936909
Please use the new thread for discussions.
I use protboard.
Error"Out of memory" always occure below:
Not error below:
I post in here because I use propforth3.2.
I display bmp-image inside SD-card on LCD .
LCD is nokia3300-lcd. it use epson's S1D15G10D for controller.
It has 132pixel X 132pixel and color12bit.
SD-card is ver1.
bmp-image is 130pixel X 130pixel and color24bit.
Load nokia3300_1.f using "Send File from TeraTerm.
Load sd_1.f using "Send File from TeraTerm.
Copy/Paste "variavle buffer 1fc allot" inside inside nokia3300_demo.f to TeraTerm.
and then Copy/Paste from fl to end.
word"nokia3300_demo" on TeraTerm.