I loaded your code as posted, the fl command worked just fine for me, it was 1 copy and paste operation. What are your serial port settings? Did you reboot the prop before the copy & paste?
After the fl command completes, LQ020B8UB02_demo.txt leaves 00003741 on the stack. I didn't look closely yet, but this usually means there is an error in your code.
You could add each definition one by one
fl
: next-definition ... ;
st?
and be sure to check the stack with st? after each new definition, this will show which word has stack problems.
If you are continuously loading this code and not doing a reboot between each unsuccessful test, eventually you will run out of stack space and get an overflow.
You could try rebooting each time a test fails, and fl the code to start clean for the next test. Its very quick, and you know the board is in a good state. If a test failed, you have a good chance that something is not in a good state.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Post Edited (prof_braino) : 7/31/2010 11:54:39 PM GMT
caskaz said...
Hi prof_braino.
I deleted every comments and spaces character in front of words on LQ020B8UB02_demo. I did copy/paste whole file(adding fl).
After I paste on TearTerm, fl displayed on TearTerm while blue LED lit on prot board. Then red LED lit. Words are displayed on Tearterm.
fl C77 chars many word displayed : LQ020 .. .. ; Cog6 ok LQ020
COG6 RESET - last status: MAIN STACK OVERFLOW
Cog6 ok
It shoud load fine because it don't stop loading.
But not work.
I copy/paste LQ020B8UB02_demo with 10-lines step by step. This works fine.
WHY? I don't have idea.
About "How does font-datas define for PropForth?"
Sorry, My question was bad.
for example, PropBasic define font character by using DATA statement. (word for spin)
How does PropForth?
1) you don't have to delete comments and spaces to use the fl command, something else is wrong
2) just because the interpreter accepts the text does not mean your code is correct. If any definition leaves a value on the stack when it should not, there is an error in the code.
3) When you use the fl command, your text is buffered to EEPROM. Your code has a stack error that happens to work from the command line since that how you debugged it, is my guess based on 1 & 2
4) new font will be in a next release. The current plan is to scale down the internal font since the bit maps take so much memory. If you want full kanji we have to wait until extended memory support is ready. If you give some example of the bitmaps we can work them into the plans as possible.
Sorry, I'm going thru the posts in backwards order while watching the kids
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
NOTE
10 base w! / in hex, sets the base to 16 (decimal)
10 base w! / in decimal, sets the base to 16 (decimal)
That looks slightly off (probably suffers from copy/paste). If you're in decimal mode then the last word sequence does effectively nothing.
I posted this in the PropForth 2.7 thread a while back. It displays the current base in decimal. There is also a more verbose word somewhere in this thread.
Hi prof_braino
I think allot is byte.
4c is 76byte.
I don't have idea why 76byte.
variable buffer 3c allot
variable mask
: test mask buffer - . ;
test
4c Cog6 ok
serial port: COM5
baud rate: 57600baud
data: 8bit
parity:none
stop bit:1bit
flow control :none
I did reboot before copy/paste.
I did copy/paste LQo20BBUB02_demo_2.
This file delete every comments and space character in front of word.
(Except for this form, loading fail by "UNDEFINED WORD".)
After "st?" while loading, "ST:"diplayed.
But error occured.
fl
CA1 Cog6 ok
..
word
..
Cog6 ok
st?
ST:
Cog6 ok
..
word
..
Cog6 ok
st?
ST:
Cog6 ok
..
Cog6 ok
LQ020
COG6 RESET - last status: MAIN STACK OVERFLOW
Cg6 ok
caskaz said...
4c is 76byte.
I don't have idea why 76byte.
variable buffer 3c allot
variable mask
: test mask buffer - . ;
test
4c Cog6 ok
That's nothing to worry about. It depends - among other things - on the length of the name of the word. For example, try using verylongwordindeed instead of mask. All you get is the difference of their respective locations in the dictionary which is not necessarily related to their payload(s).
caskaz said...
Hi prof_braino.
I attached TeraTerm_Forth.ini for Teraaterm.
Please check it.
Sorry, all I can say is that it's there, I don't know about any of those settings; If you changed anything from the defaults, change it back to the default.
The only thing that I know about is the serial settings, that what you have listed in the earlier posts look correct.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Default for TeraTerm cannot communicate to proto board.
I changed only below:
serial port: COM5(changed)
baud rate: 57600baud(changed)
data: 8bit(Default)
parity:none(Default)
stop bit:1bit(Default)
flow control :none(Default)
menu's Setup - Terminal item New-line: Receive CR+LF(changed)
caskaz said...
Hi prof_braino
baud rate: 57600baud
data: 8bit
parity:none
stop bit:1bit
flow control :none
I did reboot before copy/paste.
I did copy/paste LQo20BBUB02_demo_2. This file delete every comments and space character in front of word. (Except for this form, loading fail by "UNDEFINED WORD".) After "st?" while loading, "ST:"diplayed. But error occured.
LQ020
COG6 RESET - last status: MAIN STACK OVERFLOW
Cg6 ok
Your serial port settings look ok.
When I load the file as posted, I get no error; no loading fail with "UNDEFINED WORD" message.
if you see an error loading the code, something is incorrectly configured, possibly on your PC.
Is anything changed from defaults in teraterm, does any other program use the com port?
Executing LQ020 causes the cog to reset, so I think there is a problem in LQ020.
Please execute each word one at a time and verify that each consumes the proper number of values, and leaves the proper number of values. Please consider adding the comments for each word on the line before each definition, that's how Sal does it in PropForthPart1.f , it does not cause the the lines to bunch up.
For the time being, try keeping comments on a separate line.
Also, consider making the body of each DO...LOOP into a single word, and debug that word separately.
One of the loops is leaving a value on the stack, and happens enough times to fill the stack's 32 longs.
When I see this in my code, it is always the most complicated word at the very end of the dictionary.
My guess would be
disp_pair
or later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Post Edited (prof_braino) : 8/1/2010 3:18:35 AM GMT
Default for TeraTerm cannot communicate to proto board.
I changed only below:
serial port: COM5(changed)
baud rate: 57600baud(changed)
data: 8bit(Default)
parity:none(Default)
stop bit:1bit(Default)
flow control :none(Default)
menu's Setup - Terminal item New-line: Receive CR+LF(changed)
If it can load words, it must be set up ok.
Is something different about your PC? Are you working on a fairly modern pc? Some of my ancient machines cannot use 57600 reliably. Also if you have an old Mac running newer OS X emulating windows using WINE and rip DVD at the same time, sometimes things have issues. I'm grasping as straws here, I've run out of ideas.
Can you do a screen capture of the loading failure and email it to me? Send me a PM if you want my email.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Doing Copy/pasteLQ020BBUB02_demo step by step, it works fine.
But doing whole code, UNDEFINED WORD occure.
It seems there is not problem.
Doing Copy/paste whole LQo20BBUB02_demo_2 , it load fine.
But error occured. [noparse][[/noparse]COG6 RESET - last status: MAIN STACK OVERFLOW]
Same as lcd_initial.
The initialization words all work with no stack problems, EXCEPT the line with char_start leaves a 0 on the stack from the dup.
If that is a seed for the 200 0 DO ... LOOP, its clearer if you put it on the DO line, don't hide it in the previous line.
0 200 0 DO ....
You DUP before the > and you only DROP if the test is TRUE. Perhaps if you DROP after the THEN?
That's all I can come up with, it getting later here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
I changed LQ020BBUB02_demo ( not LQ020BBUB02_demo_2) below.
Trying many times load, it's ok. And it works fine.
Using "\" with series lines is no good?
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?
e000 wconstant sine_start
f001 wconstant sine_end
variable dT
: sin
0 pinout \ output P0
18000000 ctra COG! \ DUTY-single-end APIN=P0
clkfreq 21f u/ dT L!
dT L@ cnt COG@ +
100 0 do
2000 0 do \ 0 - 360degree
7ff i and 1 lshift
i 1000 and 0= if \ 0 - 180degree or 180 - 360degree
i 800 and 0= if
sine_start + W@ f lshift 7fffffff + frqa COG! \ 0 - 90degree
else
sine_end swap - W@ f lshift 7fffffff + frqa COG! \ 90 - 180degree
then
else
i 800 and 0= if
sine_start + W@ f lshift 7fffffff swap - frqa COG! \ 90 - 270degree
else
sine_end swap - W@ f lshift 7fffffff swap - frqa COG! \ 270 - 360degree
then
then
dT L@ waitcnt
loop
loop
;
caskaz said...
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?
First question: Does 1-cycle mean executing the word 'sin' (100 loops of 2000 loops on the inner loop body), or does it mean 1 execution of the inner loop?
Executing sin on my machine takes 15 seconds also, so I guess you are saying that the Spin routine that does 100 loops of 2000 loops takes 800msec, etc.
So for this example Spin is about 20 times faster than PropForth. Assembler is 1700 times faster. Wow! I won't stop using forth though, I try not to sin much anyway.
Based on your post, if you optimize with assembler, the absolute minimum forth execution time will be greater than 9ms. It should be the 9ms + (forth overhead) ms. The optimized execution time is expected to be less than the spin execution time, based on the spin being general purpose and the optimization being special purpose, but this is just a guess.
1) Overhead of the forth do..loops: 100 loops of 2000 loops of : null ; takes 10 seconds on my machine, which is the majority of the execution time. Clearly you don't want the existing forth do..loop if you need 200,000 iterations in 9ms. Consider optimizing using your assembler looping routine as an example.
2) Loop body execution time: 15 seconds - 10 seconds loop overhead = 5 second for 200,000 executions. Consider optimizing using the techniques described in the texts e.g. Starting Forth and Thinking Forth which can be found on-line.
Conclusion: a) PropForth does not appear to be optimized for running large numbers of do...loops. b) The remain code can be optimized to perform an estimated 200,000 iterations in 9ms.
The forth development 'rule of thumb' is "Get it running quickly using forth, get it to execute fast using assembler". You have it 'running' albeit slowly in forth. Now is the fun of optimizing if you are so inclined. So nothing is wrong 'per se'; optimization (re-factor and/or assembly) has not been completed.
If you make a 'fast loop' (from your assembler routine), we can add it to the code base; also, I will add optimizing do...loop for speed to the request queue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
caskaz said...
Hi pro_braino. I changed LQ020BBUB02_demo ( not LQ020BBUB02_demo_2) below. Trying many times load, it's ok. And it works fine.
Using "\" with series lines is no good?
The whole reason for the fl [noparse][[/noparse]file load] command is no flow control to the prop.
I saw something about having the terminal program wait for each character to echo before send the next character. This would solve the whole issue with pasting test to the propforth interpreter, and eliminate the need for the fl word.
Does anybody know how to set this up in teraterm, or of a terminal program that does this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
I'm amazed a little because sine_wave takes much time for PropForth.
Can I make word using assembler?
I take an interesting in calculation of stack for Forth.
It is fun to think data on stack. I often mistake.
I'm amazed a little because sine_wave takes much time for PropForth.
Can I make word using assembler?
I take an interesting in calculation of stack for Forth.
It is fun to think data on stack. I often mistake.
Me too, but yours is the first post to point this out, maybe there is something we are missing; maybe do...loop itself can be optimized.
caskaz said...
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?
caskaz said...
Hi prof_braino. About "How does font-datas define for PropForth?"
Sorry, My question was bad. for example, PropBasic define font character by using DATA statement. (word for spin)
How does PropForth?
Propforth would use the same method as in assembler, as in the custom font in the 1024x768 HiRes VGA example in the OBEX.
are you trying to get just afew characters, a full ASCII font, or an extended Asian font?
A full ASCII font would take up most of the memory in prop, so on the single prop implementations, the internal font is used. Sal is checking to see if the forth dictionary and a custom font can fit; it does not look like there is enough RAM. We are also looking at what we can do with extended memory, but there are no definite results yet. The C3 is the platform we are looking at.
For serial output, you can output any multi-byte codes you need, and use the font that is active in the host terminal to deal with the actual bit maps.
In the case of an LCD display, if the LCD supports programmable fonts, and the font is pre-loaded, you coud again sent out the byte codes and let the LCD deal with the bit maps.
If you want a full custom font for your LCD project and the LCD does not support programmable fonts, consider having a chip dedicated to the the VGA. There are multi-prop solutions that should be convenient. The Hive is the platform we are looking at
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
caskaz said...
PropForth is impossible to do define font(using DATA statement) like PropBASIC?
Normally you can define (constant) data arrays like this:
create my_array 0 , 1 , 2 , 3 , 42 ,
Executing my_array will put its address on the stack and you can access the members from there. Unfortunately this doesn't seem to work under PropForth. While it has words like l, w, c, cog, the resulting dictionary entry (my_array) doesn't work as expected (for starters it doesn't leave its address on the stack).
caskaz said...
PropForth is impossible to do define font(using DATA statement) like PropBASIC?
Normally you can define (constant) data arrays like this:
createmy_array0,1,2,3,42,</CODE>
Executing my_array will put its address on the stack and you can access the members from there. Unfortunately this doesn't seem to work under PropForth. While it has words like l, w, c, cog, the resulting dictionary entry (my_array) doesn't work as expected (for starters it doesn't leave its address on the stack).
@prof_braino: Any insight in this one?
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.
NNNw,</CODE> 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.
In the meantime, can you use
wvariablemy_array1w,2w,3w,42w,
'my_array20dump
</CODE>
shows that 0 is in the first location as your create definition wanted. You can access the other values by offset same as with the create'd my_array
Sorry, I can't understand well.
PropForth is impossible to do define font(using DATA statement) like PropBASIC?
LCD module don't has fonts.
In case of defining font, external memory needs?
Nothing is 'impossible', but most things 'haven't been done yet'. Nobody has asked to 'define font(using DATA statement) like PropBASIC' before, so this has not been done (yet).
I usually don't define fonts, but memory need can be calculated:
How many characters are in your font?
How big are the bitmap images?
For each character, bits high * bits wide = character bitmap size
bitmap size * number of character = memory need for your font.
Routines to access the font elements can be written in forth, but VGA needs the data very quickly, so these routines are usually written in assembler for speed.
If you have gotten your LCD to display your fonts using PropBasic, then can you just use the PropBasic? If you need to interactively test something, can you use you propbasic program as an example for creating the forth code?
Otherwise, can you give more specific information on what you are doing? I don't know your hardware, your character set, your font size, or your resources available. This information would make it easier to determine possible solutions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Comments
This is another example of how I earned the name ' braino' ... (as in 'brain?' ... 'NO!')
The FAQ has been updated to
NOTE
10 base w! / set base to whatever base it is in; hex, decimal, octal, binary, etc,; i.e. does nothing
set the base to decimal or hex using the kernel words
hex / defined using decimal definition 16 base w!
and
decimal / defined using decimal definition 10 base w!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Post Edited (prof_braino) : 7/31/2010 7:12:18 PM GMT
I loaded your code as posted, the fl command worked just fine for me, it was 1 copy and paste operation. What are your serial port settings? Did you reboot the prop before the copy & paste?
After the fl command completes, LQ020B8UB02_demo.txt leaves 00003741 on the stack. I didn't look closely yet, but this usually means there is an error in your code.
You could add each definition one by one
and be sure to check the stack with st? after each new definition, this will show which word has stack problems.
If you are continuously loading this code and not doing a reboot between each unsuccessful test, eventually you will run out of stack space and get an overflow.
You could try rebooting each time a test fails, and fl the code to start clean for the next test. Its very quick, and you know the board is in a good state. If a test failed, you have a good chance that something is not in a good state.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Post Edited (prof_braino) : 7/31/2010 11:54:39 PM GMT
1) you don't have to delete comments and spaces to use the fl command, something else is wrong
2) just because the interpreter accepts the text does not mean your code is correct. If any definition leaves a value on the stack when it should not, there is an error in the code.
3) When you use the fl command, your text is buffered to EEPROM. Your code has a stack error that happens to work from the command line since that how you debugged it, is my guess based on 1 & 2
4) new font will be in a next release. The current plan is to scale down the internal font since the bit maps take so much memory. If you want full kanji we have to wait until extended memory support is ready. If you give some example of the bitmaps we can work them into the plans as possible.
Sorry, I'm going thru the posts in backwards order while watching the kids
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Not quite, but close ... the 'W's need to be capitalized ....
works just fine
cheers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
www.wulfden.org/TheShoppe/prop/ - Propeller Products
www.wulfden.org/TheShoppe/k107/ - Serial LCD Display Gear
I think allot is byte.
4c is 76byte.
I don't have idea why 76byte.
serial port: COM5
baud rate: 57600baud
data: 8bit
parity:none
stop bit:1bit
flow control :none
I did reboot before copy/paste.
I did copy/paste LQo20BBUB02_demo_2.
This file delete every comments and space character in front of word.
(Except for this form, loading fail by "UNDEFINED WORD".)
After "st?" while loading, "ST:"diplayed.
But error occured.
Post Edited (caskaz) : 8/1/2010 12:46:18 AM GMT
Sorry guys, brain fart again, I was looking at the difference between variable and wvariable.
You are correct allot is bytes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Post Edited (prof_braino) : 8/1/2010 2:52:35 AM GMT
I attached TeraTerm_Forth.ini for Teraaterm.
Please check it.
I think the extra is for the dictionary entry. CFA (code field address) PFA (parameter field address) NFA (name field address)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Sorry, all I can say is that it's there, I don't know about any of those settings; If you changed anything from the defaults, change it back to the default.
The only thing that I know about is the serial settings, that what you have listed in the earlier posts look correct.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Default for TeraTerm cannot communicate to proto board.
I changed only below:
serial port: COM5(changed)
baud rate: 57600baud(changed)
data: 8bit(Default)
parity:none(Default)
stop bit:1bit(Default)
flow control :none(Default)
menu's Setup - Terminal item New-line: Receive CR+LF(changed)
Your serial port settings look ok.
When I load the file as posted, I get no error; no loading fail with "UNDEFINED WORD" message.
if you see an error loading the code, something is incorrectly configured, possibly on your PC.
Is anything changed from defaults in teraterm, does any other program use the com port?
Executing LQ020 causes the cog to reset, so I think there is a problem in LQ020.
Please execute each word one at a time and verify that each consumes the proper number of values, and leaves the proper number of values. Please consider adding the comments for each word on the line before each definition, that's how Sal does it in PropForthPart1.f , it does not cause the the lines to bunch up.
For the time being, try keeping comments on a separate line.
Also, consider making the body of each DO...LOOP into a single word, and debug that word separately.
: DoThis20Times .... ; : OUTERLOOP 20 0 DO DoThis20Times LOOP ;One of the loops is leaving a value on the stack, and happens enough times to fill the stack's 32 longs.
When I see this in my code, it is always the most complicated word at the very end of the dictionary.
My guess would be
or later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Post Edited (prof_braino) : 8/1/2010 3:18:35 AM GMT
If it can load words, it must be set up ok.
Is something different about your PC? Are you working on a fairly modern pc? Some of my ancient machines cannot use 57600 reliably. Also if you have an old Mac running newer OS X emulating windows using WINE and rip DVD at the same time, sometimes things have issues. I'm grasping as straws here, I've run out of ideas.
Can you do a screen capture of the loading failure and email it to me? Send me a PM if you want my email.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Doing Copy/pasteLQ020BBUB02_demo step by step, it works fine.
But doing whole code, UNDEFINED WORD occure.
It seems there is not problem.
Doing Copy/paste whole LQo20BBUB02_demo_2 , it load fine.
But error occured. [noparse][[/noparse]COG6 RESET - last status: MAIN STACK OVERFLOW]
Same as lcd_initial.
I will do your suggestion later.
Thanks.
caskaz
SORRY! Made another mistake.
color_list has comments at the end of each line. This is the problem.
if you put each comment on its own separate line, the "UNDEFINED WORD" error does not appear.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
The initialization words all work with no stack problems, EXCEPT the line with char_start leaves a 0 on the stack from the dup.
If that is a seed for the 200 0 DO ... LOOP, its clearer if you put it on the DO line, don't hide it in the previous line.
0 200 0 DO ....
You DUP before the > and you only DROP if the test is TRUE. Perhaps if you DROP after the THEN?
That's all I can come up with, it getting later here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
I changed LQ020BBUB02_demo ( not LQ020BBUB02_demo_2) below.
Trying many times load, it's ok. And it works fine.
Using "\" with series lines is no good?
: color_list color dup 1f swap W! 2+ dup \ blue <--cr f800 swap W! 2+ dup \ red <--cr f81f swap W! 2+ dup \ magenda <--cr 7e0 swap W! 2+ dup \ green <--cr 7fe swap W! 2+ dup \ cyan <--cr ffe0 swap W! 2+ dup \ yellow <--cr ffff swap W! 2+ dup \ white <--cr a18a swap W! 2+ dup \ brown <--cr fbc0 swap W! 2+ dup \ orange <--cr f998 swap W! \ pink <--cr drop ;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?
e000 wconstant sine_start f001 wconstant sine_end variable dT : sin 0 pinout \ output P0 18000000 ctra COG! \ DUTY-single-end APIN=P0 clkfreq 21f u/ dT L! dT L@ cnt COG@ + 100 0 do 2000 0 do \ 0 - 360degree 7ff i and 1 lshift i 1000 and 0= if \ 0 - 180degree or 180 - 360degree i 800 and 0= if sine_start + W@ f lshift 7fffffff + frqa COG! \ 0 - 90degree else sine_end swap - W@ f lshift 7fffffff + frqa COG! \ 90 - 180degree then else i 800 and 0= if sine_start + W@ f lshift 7fffffff swap - frqa COG! \ 90 - 270degree else sine_end swap - W@ f lshift 7fffffff swap - frqa COG! \ 270 - 360degree then then dT L@ waitcnt loop loop ;First question: Does 1-cycle mean executing the word 'sin' (100 loops of 2000 loops on the inner loop body), or does it mean 1 execution of the inner loop?
Executing sin on my machine takes 15 seconds also, so I guess you are saying that the Spin routine that does 100 loops of 2000 loops takes 800msec, etc.
So for this example Spin is about 20 times faster than PropForth. Assembler is 1700 times faster. Wow! I won't stop using forth though, I try not to sin much anyway.
Based on your post, if you optimize with assembler, the absolute minimum forth execution time will be greater than 9ms. It should be the 9ms + (forth overhead) ms. The optimized execution time is expected to be less than the spin execution time, based on the spin being general purpose and the optimization being special purpose, but this is just a guess.
1) Overhead of the forth do..loops: 100 loops of 2000 loops of : null ; takes 10 seconds on my machine, which is the majority of the execution time. Clearly you don't want the existing forth do..loop if you need 200,000 iterations in 9ms. Consider optimizing using your assembler looping routine as an example.
2) Loop body execution time: 15 seconds - 10 seconds loop overhead = 5 second for 200,000 executions. Consider optimizing using the techniques described in the texts e.g. Starting Forth and Thinking Forth which can be found on-line.
Conclusion: a) PropForth does not appear to be optimized for running large numbers of do...loops. b) The remain code can be optimized to perform an estimated 200,000 iterations in 9ms.
The forth development 'rule of thumb' is "Get it running quickly using forth, get it to execute fast using assembler". You have it 'running' albeit slowly in forth. Now is the fun of optimizing if you are so inclined. So nothing is wrong 'per se'; optimization (re-factor and/or assembly) has not been completed.
If you make a 'fast loop' (from your assembler routine), we can add it to the code base; also, I will add optimizing do...loop for speed to the request queue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
I'm opening a bug report on using / after lines of code, Sal will look at this for the version3.2 patch he is making.
http://code.google.com/p/propforth/issues/list
Issue 9 has been submitted
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Post Edited (prof_braino) : 8/2/2010 7:28:54 PM GMT
I saw something about having the terminal program wait for each character to echo before send the next character. This would solve the whole issue with pasting test to the propforth interpreter, and eliminate the need for the fl word.
Does anybody know how to set this up in teraterm, or of a terminal program that does this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
I'm amazed a little because sine_wave takes much time for PropForth.
Can I make word using assembler?
I take an interesting in calculation of stack for Forth.
It is fun to think data on stack. I often mistake.
Me too, but yours is the first post to point this out, maybe there is something we are missing; maybe do...loop itself can be optimized.
The propforth 2.6 archive has the forth assembler, written in forth
code.google.com/p/propforth/downloads/detail?name=PropForth2.6archive.zip&can=2&q=
This page has the disassembler and debugger
code.google.com/p/propforth/wiki/CogDebuggerDisassembler
You are the first to try it, you will probably have questions and find errors. Please post or PM and I will try to get fix any issues.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
http://code.google.com/p/propforth/issues/list
Issue 10 has been submitted
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Propforth would use the same method as in assembler, as in the custom font in the 1024x768 HiRes VGA example in the OBEX.
are you trying to get just afew characters, a full ASCII font, or an extended Asian font?
A full ASCII font would take up most of the memory in prop, so on the single prop implementations, the internal font is used. Sal is checking to see if the forth dictionary and a custom font can fit; it does not look like there is enough RAM. We are also looking at what we can do with extended memory, but there are no definite results yet. The C3 is the platform we are looking at.
For serial output, you can output any multi-byte codes you need, and use the font that is active in the host terminal to deal with the actual bit maps.
In the case of an LCD display, if the LCD supports programmable fonts, and the font is pre-loaded, you coud again sent out the byte codes and let the LCD deal with the bit maps.
If you want a full custom font for your LCD project and the LCD does not support programmable fonts, consider having a chip dedicated to the the VGA. There are multi-prop solutions that should be convenient. The Hive is the platform we are looking at
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.
Sorry, I can't understand well.
PropForth is impossible to do define font(using DATA statement) like PropBASIC?
LCD module don't has fonts.
In case of defining font, external memory needs?
Executing my_array will put its address on the stack and you can access the members from there. Unfortunately this doesn't seem to work under PropForth. While it has words like l, w, c, cog, the resulting dictionary entry (my_array) doesn't work as expected (for starters it doesn't leave its address on the stack).
@prof_braino: Any insight in this one?
Nothing is 'impossible', but most things 'haven't been done yet'. Nobody has asked to 'define font(using DATA statement) like PropBASIC' before, so this has not been done (yet).
I usually don't define fonts, but memory need can be calculated:
How many characters are in your font?
How big are the bitmap images?
For each character, bits high * bits wide = character bitmap size
bitmap size * number of character = memory need for your font.
Routines to access the font elements can be written in forth, but VGA needs the data very quickly, so these routines are usually written in assembler for speed.
If you have gotten your LCD to display your fonts using PropBasic, then can you just use the PropBasic? If you need to interactively test something, can you use you propbasic program as an example for creating the forth code?
Otherwise, can you give more specific information on what you are doing? I don't know your hardware, your character set, your font size, or your resources available. This information would make it easier to determine possible solutions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even the best needles are not sharp at both ends.