Yes, it seems that most Forth words change the depth of the stack. Some of the words that don't change the stack depth are defined as colon words, and the stack would be shuffled a few times before they complete execution. So a stack in hub RAM might be just as efficient as one in cog RAM, unless the stacks are extremely small.
OK - so I'll give it a try.
yesterday evening I was so frustrated, I wanted to give up.
but after a good sleep today I made some progress
so my contest entry is a - very basic - PWM voltage or current controller.
Components are:
TACHYON + Peters PWM-module
Forth/PASM extension module for Tachyon to do simple Sigma Delta ADC
very very simple controller
HW setup:
PPDB
R-C to filter PWM
R-C-R sigma-delta ADC circuit
poti to put a load on the gernerated voltage, which will be compensated by the control loop
in addition I have an example code showing how to implement a Tachyon parser extension
to handle a legacy command language within FORTH.
all is contained in the zip file.
Maybe this could be extended to a 12 channel current controller for automotive solenoids, I was asked for.
There is a saying: " a dwarf standing on the shoulders of a giant may see farther than a giant himself"
while standing on Peters shoulders - my legs are to short to see father than him - but I see much much more based on his Tachyon.
so again thanks a lot for sharing.
best is using a compare tool like beyond compare to view the changes to TACHYON V2.1.spin
Preliminary Entry - Single Digit Tachyon Propeller Clock
I wanted to get this in because it's now afternoon on the 4th and since the wife and kid are just getting home, my time is no longer mine! The code and documentation will be cleaned up and polished but it may be after the deadline.
I saw a single digit clock in someone's Christmas catalog a few weeks back and thought it would be an interesting project for some future time. Then Peter's contest came along and all of a sudden, the future is NOW!! I was unable to get the large digit and case I wanted to use, so I fell back on my trusty old Propeller Professional Development Board. Since I hadn't really done a project in Tachyon, I thought I'd make the switch. It was a good switch!!
The hardware is pretty simple: a Propeller board, a RTC (DS1302 in this example) and a 16 segment LED (you could do it with a 7 segment LED also).
The software is built on top of Tachyon Forth with the EXTEND.fth extensions and is currently split between 2 files:
1) ds1302a.txt - this file contains all the words and constants needed to write and read the time and date registers of the DS1302 RTC chip. There are words to do basic I/O (DS1302! and DS1302@) and then words to set and get the various registers plus BCD to decimal and decimal to BCD words.
2) singleclock.txt - this file contains the remainder of the application. Words to drive the LED segments and make the needed numbers and characters and then the clock words to display the time. Words need to be added to set the time from the push buttons. The time currently needs to be set through the console. At this point, the application does not self-start. The files need to be packaged up to lolad as TACHYON modules and the CLOCKSET word needs to be set as the start word.
I should be further along with this but a day was spent fighting with the Ds1302 and how and WHEN to ENABLE and DISABLE the cip select pin. Once I figured that out, things went quickly today but unfortunately, it was about 3PM today when the clock started working.
The LED code went very quickly and the progress of the words through the file is pretty much how they were developed as I started lighting the segments and then figured out whic segments I needed for each character. The LED session was a good example of Forth rapid development while working with the hardware in a bottom up fashion.
Anyway, that's what I got for now. Consider it an incomplete entry or a non-entry, either way. I'll keep plugging away at it and order an LED and a case at some point. I guess I could even put a temperature sensor in there and have a single digit time and temperature display.
Good luck to everyone!!
Thanks for the challenge/contest, Peter!!
...and a special thank-you for TACHYON, it was fun to get into using it with a real project in mind!
I'm not sure I'm eligible for this contest as this is an extention to my entry in the last contest. Clearly my forth code, while it worked, didn't have a nice terminal interface.
So what I have now is essentially a reasonably easy to build GUI for the TeraTerm Terminal all written in PropForth 5.00. The project is still based on a: Dual Axis Solar Tracker using LED Sun Sensors and an All N-Chanel MOSFET Dual H-Bridge.
This GUI constantly loops looking for key codes from the terminal to process functions. It displays parameters on the terminal using essentially the Professors ESC codes and many numeric formatting words I have written.
The H-Bridge hardware is the same as I described earlier.However, the forthware to operate it is completely different.
1. The 4 High side drivers are connected to the outputs of the NCOs running at 10KHz. This is controlled by presetting the pins low. Control is accomplished by switching the direction between in and out.
2. the 4 Low side drivers are conventional by directly driving the MOSFETs from the Prop.
I have run this from 12V but see no reason it can't be much higher.
All software development was done at 5V from the USB port.
Here is a link to my project. Look in message #1. Tiny-PropForth-GUI
I will keep updating the software as needed.
Yes, it seems that most Forth words change the depth of the stack. Some of the words that don't change the stack depth are defined as colon words, and the stack would be shuffled a few times before they complete execution. So a stack in hub RAM might be just as efficient as one in cog RAM, unless the stacks are extremely small.
Forth words change the depth of the stack, but usually only affect the top most element at any given moment. That's why its fast.
"Shuffling" the stack is very expensive, that's why words that affect other than the top one or two elements are usually avoided, unless we don;t have to care about speed or efficiency.
If one does a lot of popping and pushing (to get at values buried deeper in the stack) it is a sign that the program might need to be refactored. If its slow and cumbersome, its probably just plain wrong. Refactoring can usually get the elements in the order that are used and needed, and it speeds up and gets easier. You have to plan a little, but its worth solving the puzzle.
Doug, I think you miss the point. The technique that Tachyon uses will need to recopy the entire stack for any word that increases or decreases the depth of the stack. If you execute DROP in Tachyon it will shift every value toward the top of the stack. In the case of Tachyon, it will do this even if there was only one item on the stack. That is, it shuffles all the cog memory locations that are used for the stack, even if they don't contain valid data.
Maybe your not familiar with how Tachyon implements its stacks. You may want to take a look at the source code.
Doug, I think you miss the point. The technique that Tachyon uses will need to recopy the entire stack for any word that increases or decreases the depth of the stack. If you execute DROP in Tachyon it will shift every value toward the top of the stack. In the case of Tachyon, it will do this even if there was only one item on the stack. That is, it shuffles all the cog memory locations that are used for the stack, even if they don't contain valid data.
Maybe your not familiar with how Tachyon implements its stacks. You may want to take a look at the source code.
Yes, this is what it has to do and that is why there are special words such as SHROUT etc that do not push or pop the stack. However the stack is implemented in cog memory and so it is very fast when compared to hub memory so there really is not much difference in execution time when pushing and popping but all other operations are free to directly access the stack knowing that the parameters are in a fixed location which is important as the P1's instruction set does not have indexing natively supported. Twelve MOV instructions execute in 600ns. Here's some timing tests:
#1000000 0 NEWCNT DO LOOP .LAP 600,012us ok
#1000000 0 NEWCNT DO DROP LOOP .LAP 1,600ms ok
#1000000 0 NEWCNT DO 0 LOOP .LAP 1,800ms ok
So an empty loop + instruction fetch takes 600ns, that's good but we want to know so we can subtract this figure for the other tests. There is the stack pop which we can do without crashing anything (that's a plus) and this ends up taking 1us per pop which includes the instruction fetch as well, so that's pretty good. The push operation is done using a fast constant instruction so it takes 1.2us including the bytecode fetch which once again is pretty good. The PUSH and POPs are the most inefficient instructions, if you can call 1.2us worst case "inefficient"
I realized (at 3am) that I should not include the BCD>DEC and DEC>BCD words inside my GET and SET words. It limits their functionality and forces their input/output to be a certain way at least for testing. They will be removed when I get back to my desk.
The GET/SET names are also cumbersome for the time primitives. Maybe just HOURS! and HOURS@ for example would make them more Forthish, or something else...I'll have to play more with those the make things tighter. I should look at your RTC words to see if there's a common point they can share things (I was trying to do mine in a "clean room" environment for starters).
Well it definitely is well and truly past the 4th now so thanks to all who have had the courage to give it a go and submit an entry and so Forth! I will sift the thread for the entries (I should have specified that the project files should also be zipped) and post a list of the entries back here and on the challenge page. From there I will evaluate each one and post the results within 7 days. It's exciting to see the creative juices flowing Forth and I hope everyone had some fun at the same time (of course, Forth is fun).
Don't be shy about updating your code in the meantime but don't just edit your old post, try and make a new one or at least announce a change. I hate all those competitions where that last bit of polishing would have made all the difference but the "rules" don't allow it. Sure, we have rules here, the rule is "have fun".
I think that given the rather short notice for this competition that the response has been excellent and so after this I will gear up for the next challenge in 2013 on the 4th of April. That gives you almost 5 months to look at what you can do and I think I will up the stakes with the prizes too. This may include P2 boards which may hopefully be available by then (we can always be hopeful).
Doug, I think you miss the point. The technique that Tachyon uses will need to recopy the entire stack for any word that increases or decreases the depth of the stack. If you execute DROP in Tachyon it will shift every value toward the top of the stack. In the case of Tachyon, it will do this even if there was only one item on the stack. That is, it shuffles all the cog memory locations that are used for the stack, even if they don't contain valid data.
Maybe your not familiar with how Tachyon implements its stacks. You may want to take a look at the source code.
Sorry, I was just talking about forth in general om response to David Betz post. You are right I would have to look at this source carefully before this makes sense, as it appears to be not the way that forth usually does it. Even so, if its "very fast on the prop", to fiddle with the stack by moving all the locations, intuitively it would be faster if the locations didn't move. But it is kind of cool that it works so well.
I think that given the rather short notice for this competition that the response has been excellent and so after this I will gear up for the next challenge in 2013 on the 4th of April. That gives you almost 5 months to look at what you can do and I think I will up the stakes with the prizes too. This may include P2 boards which may hopefully be available by then (we can always be hopeful).
I'll have to start thinking about this. I've had a print of the BYTE Magazine Forth issue cover hanging on my wall for a zillion years but really haven't gotten around to typing more than a few lines of code at a Forth interpreter. I keep meaning to get to it and have a handful of books on Forth to help out but maybe this competition will push me over the edge. As you say, at least this one has a long lead time. Thanks for running these Peter! It's fun to see what people submit even when I don't have time to enter myself.
to make it a little more clear here a schema how the current controller could be used to
adjustably limit the average current for a magnetic actuator.
The ADC-Input and ADC-Feedback pins are for the Sigma-Delta ADC.
Of course building this on the PPDB is not exactly the right way for 80MHz counter signals ...
Idealy this should be made in SMD-layout with the smd-prop casing.
Unfortunately the PBoE, which has sigma delta circuit has it tied to the microphone and not accessible to the user.
Sorry, I was just talking about forth in general om response to David Betz post. You are right I would have to look at this source carefully before this makes sense, as it appears to be not the way that forth usually does it. Even so, if its "very fast on the prop", to fiddle with the stack by moving all the locations, intuitively it would be faster if the locations didn't move. But it is kind of cool that it works so well.
Peter is our resident Forth iconoclast. If something has a typical way of being done, he is going to find yet another way to do it -- just to keep us all busy.
@MJB
A good night's sleep has a way of cleaning up Forth code. I have used that trick several times.
So an empty loop + instruction fetch takes 600ns, that's good but we want to know so we can subtract this figure for the other tests. There is the stack pop which we can do without crashing anything (that's a plus) and this ends up taking 1us per pop which includes the instruction fetch as well, so that's pretty good. The push operation is done using a fast constant instruction so it takes 1.2us including the bytecode fetch which once again is pretty good. The PUSH and POPs are the most inefficient instructions, if you can call 1.2us worst case "inefficient"
Peter, you're using my "inefficient" comment out of context. I said it was inefficient for implementing large stacks. For the small stacks used in Tachyon it is quite efficient. For many Forth applications there is really no need to have a stack greater than 10 entries, so I think the tradeoff you use for Tachyon is reasonable. There are cases where a deeper stack is needed, such as for recursion and large programs that have many embedded loops or a large calling depth.
I was curious how pfth compares to Tachyon, so I ran your benchmarks under pfth. The empty "do loop" is very slow compared to Tachyon. pfth takes 39.4us per loop. About 66 times slower. pfth implements DO and LOOP as fairly large COLON words, which makes it slow. Maybe I need to implement those as primitive kernel words.
The loop "do 0 drop loop" takes 41.0us per loop. Subtracting 39.4us yields 1.6us for the "0 drop" pair. This isn't too bad compared to the 1.2us time in Tachyon.
I'll have to start thinking about this. I've had a print of the BYTE Magazine Forth issue cover hanging on my wall for a zillion years but really haven't gotten around to typing more than a few lines of code at a Forth interpreter. I keep meaning to get to it and have a handful of books on Forth to help out but maybe this competition will push me over the edge. As you say, at least this one has a long lead time. Thanks for running these Peter! It's fun to see what people submit even when I don't have time to enter myself.
Speaking of Byte ... some generous soul, obviously a glutton for punishment, at ATARI AGE, took it upon himself to scan, page by page, every issue of Byte on which he could get his hands. One mirror is located at http://malus.exotica.org.uk/~buzz/byte/pdf/.
I downloaded the Byte Forth Issue, August 1980, and then uploaded to my Forth Resources directory. Warning, it is a collection of images of 308 pages in PDF form, not your typical easily searchable PDF. The file is 212 MB.
Speaking of Byte ... some generous soul, obviously a glutton for punishment, at ATARI AGE, took it upon himself to scan, page by page, every issue of Byte on which he could get his hands. zone mirror is located at http://malus.exotica.org.uk/~buzz/byte/pdf/.
I downloaded the Byte Forth Issue, August 1980, and then uploaded to my Forth Resources directory. Warning, it is a collection of images of 308 pages in PDF form, not your typical easily searchable PDF. The file is 212 MB.
Thanks but I still have a paper copy of the Forth issue of BYTE! :-)
It's one of the few issues that I kept which also includes the Smalltalk and Lisp issues. I guess I'm a language geek!
Speaking of Byte ... some generous soul, obviously a glutton for punishment, at ATARI AGE, took it upon himself to scan, page by page, every issue of Byte on which he could get his hands. zone mirror is located at http://malus.exotica.org.uk/~buzz/byte/pdf/.
I downloaded the Byte Forth Issue, August 1980, and then uploaded to my Forth Resources directory. Warning, it is a collection of images of 308 pages in PDF form, not your typical easily searchable PDF. The file is 212 MB.
Thanks, Brian!!
I used to have boxes filled with BYTEs (from issue one until it lost its charm), then some fool threw them out for some reason......some days, I regret being a fool!
Speaking of Byte ... some generous soul, obviously a glutton for punishment, at ATARI AGE, took it upon himself to scan, page by page, every issue of Byte on which he could get his hands. One mirror is located at http://malus.exotica.org.uk/~buzz/byte/pdf/
Anyone have scans of "Kilobaud"?
"Dr. Dobbs Journal", which is still published, has their old issues available online.
I bet none of the code in that "holy grail" article runs on any Forth we have been discussing on these threads:)
I think you would lose that bet. There are some very simple examples that will run on most Forth implementations. However, there are some words in Moore's article that aren't supported by some of the Forths on the Prop, such as DOES>. Of course, pfth implements it.
I think you would lose that bet. There are some very simple examples that will run on most Forth implementations. However, there are some words in Moore's article that aren't supported by some of the Forths on the Prop, such as DOES>. Of course, pfth implements it.
Dave!!! You were my secret weapon. Now he won't bet anything. You scared him away.
BTW, PropForth is suddenly making sense to me !!! And my blood pressure is also going down. Dec 8th will be my 65th birthday. I thought I'd never see 40 or 50.
Heater wants to provide another Forth contest with a prize.
Ah, wait a minute, not really, but let's see where we go with this.
What would you be willing to bet? Be careful now....
Firstly it is my observation so far that this language called Forth around here comes in many different flavors and none of them is able to run another's code. I am told that is the "Forth way".
Now, despite the fact that I used to read BYTE magazine back in the day I don't recall the Forth article but I assume it contains some example Forth code. Given that all Forths are different I assume this code is not usable on any current Forth for the Propeller.
So the challenge is can any of the Propeller Forths run that code as publish in the BYTE magazine article?
What would I be willing to bet?
Given that the currency around here is source code I will offer as a prize a parallelized version of a Fast Fourier Transform using nothing but Spin and PASM and buildable with the Prop Tool. A task which I have not pulled off myself yet.
Comments
yesterday evening I was so frustrated, I wanted to give up.
but after a good sleep today I made some progress
so my contest entry is a - very basic - PWM voltage or current controller.
Components are:
- TACHYON + Peters PWM-module
- Forth/PASM extension module for Tachyon to do simple Sigma Delta ADC
- very very simple controller
HW setup:- PPDB
- R-C to filter PWM
- R-C-R sigma-delta ADC circuit
- poti to put a load on the gernerated voltage, which will be compensated by the control loop
in addition I have an example code showing how to implement a Tachyon parser extensionto handle a legacy command language within FORTH.
all is contained in the zip file.
Maybe this could be extended to a 12 channel current controller for automotive solenoids, I was asked for.
There is a saying: " a dwarf standing on the shoulders of a giant may see farther than a giant himself"
while standing on Peters shoulders - my legs are to short to see father than him - but I see much much more based on his Tachyon.
so again thanks a lot for sharing.
best is using a compare tool like beyond compare to view the changes to TACHYON V2.1.spin
I wanted to get this in because it's now afternoon on the 4th and since the wife and kid are just getting home, my time is no longer mine! The code and documentation will be cleaned up and polished but it may be after the deadline.
I saw a single digit clock in someone's Christmas catalog a few weeks back and thought it would be an interesting project for some future time. Then Peter's contest came along and all of a sudden, the future is NOW!! I was unable to get the large digit and case I wanted to use, so I fell back on my trusty old Propeller Professional Development Board. Since I hadn't really done a project in Tachyon, I thought I'd make the switch. It was a good switch!!
The hardware is pretty simple: a Propeller board, a RTC (DS1302 in this example) and a 16 segment LED (you could do it with a 7 segment LED also).
The software is built on top of Tachyon Forth with the EXTEND.fth extensions and is currently split between 2 files:
1) ds1302a.txt - this file contains all the words and constants needed to write and read the time and date registers of the DS1302 RTC chip. There are words to do basic I/O (DS1302! and DS1302@) and then words to set and get the various registers plus BCD to decimal and decimal to BCD words.
2) singleclock.txt - this file contains the remainder of the application. Words to drive the LED segments and make the needed numbers and characters and then the clock words to display the time. Words need to be added to set the time from the push buttons. The time currently needs to be set through the console. At this point, the application does not self-start. The files need to be packaged up to lolad as TACHYON modules and the CLOCKSET word needs to be set as the start word.
I should be further along with this but a day was spent fighting with the Ds1302 and how and WHEN to ENABLE and DISABLE the cip select pin. Once I figured that out, things went quickly today but unfortunately, it was about 3PM today when the clock started working.
The LED code went very quickly and the progress of the words through the file is pretty much how they were developed as I started lighting the segments and then figured out whic segments I needed for each character. The LED session was a good example of Forth rapid development while working with the hardware in a bottom up fashion.
Anyway, that's what I got for now. Consider it an incomplete entry or a non-entry, either way. I'll keep plugging away at it and order an LED and a case at some point. I guess I could even put a temperature sensor in there and have a single digit time and temperature display.
Good luck to everyone!!
Thanks for the challenge/contest, Peter!!
...and a special thank-you for TACHYON, it was fun to get into using it with a real project in mind!
I'm not sure I'm eligible for this contest as this is an extention to my entry in the last contest. Clearly my forth code, while it worked, didn't have a nice terminal interface.
So what I have now is essentially a reasonably easy to build GUI for the TeraTerm Terminal all written in PropForth 5.00. The project is still based on a:
Dual Axis Solar Tracker using LED Sun Sensors and an All N-Chanel MOSFET Dual H-Bridge.
This GUI constantly loops looking for key codes from the terminal to process functions. It displays parameters on the terminal using essentially the Professors ESC codes and many numeric formatting words I have written.
The H-Bridge hardware is the same as I described earlier.However, the forthware to operate it is completely different.
1. The 4 High side drivers are connected to the outputs of the NCOs running at 10KHz. This is controlled by presetting the pins low. Control is accomplished by switching the direction between in and out.
2. the 4 Low side drivers are conventional by directly driving the MOSFETs from the Prop.
I have run this from 12V but see no reason it can't be much higher.
All software development was done at 5V from the USB port.
Here is a link to my project. Look in message #1.
Tiny-PropForth-GUI
I will keep updating the software as needed.
Have fun guys.
Duane J
Could this be made to run using say a 5volt battery pack?
This is a real winner! I would like to use it for the school as a project for the H-bridge and GUI units.
I have to try this over xmas, and put my professional development board to good use again. Very nice!
This is really cool too! What will you control with this, anything in particular or is this something you like to have handy?
I wonder if all these projects can be built on one PDB?
Forth words change the depth of the stack, but usually only affect the top most element at any given moment. That's why its fast.
"Shuffling" the stack is very expensive, that's why words that affect other than the top one or two elements are usually avoided, unless we don;t have to care about speed or efficiency.
If one does a lot of popping and pushing (to get at values buried deeper in the stack) it is a sign that the program might need to be refactored. If its slow and cumbersome, its probably just plain wrong. Refactoring can usually get the elements in the order that are used and needed, and it speeds up and gets easier. You have to plan a little, but its worth solving the puzzle.
Maybe your not familiar with how Tachyon implements its stacks. You may want to take a look at the source code.
I'm back, there's 5.5 hours left until the deadline would you believe? Check the time in Midway.
Yes, this is what it has to do and that is why there are special words such as SHROUT etc that do not push or pop the stack. However the stack is implemented in cog memory and so it is very fast when compared to hub memory so there really is not much difference in execution time when pushing and popping but all other operations are free to directly access the stack knowing that the parameters are in a fixed location which is important as the P1's instruction set does not have indexing natively supported. Twelve MOV instructions execute in 600ns. Here's some timing tests:
#1000000 0 NEWCNT DO LOOP .LAP 600,012us ok
#1000000 0 NEWCNT DO DROP LOOP .LAP 1,600ms ok
#1000000 0 NEWCNT DO 0 LOOP .LAP 1,800ms ok
So an empty loop + instruction fetch takes 600ns, that's good but we want to know so we can subtract this figure for the other tests. There is the stack pop which we can do without crashing anything (that's a plus) and this ends up taking 1us per pop which includes the instruction fetch as well, so that's pretty good. The push operation is done using a fast constant instruction so it takes 1.2us including the bytecode fetch which once again is pretty good. The PUSH and POPs are the most inefficient instructions, if you can call 1.2us worst case "inefficient"
EDIT: just looking through the entries, these challenges are fun!
I have just added a link in the top post to the challenge page with more information.
I realized (at 3am) that I should not include the BCD>DEC and DEC>BCD words inside my GET and SET words. It limits their functionality and forces their input/output to be a certain way at least for testing. They will be removed when I get back to my desk.
The GET/SET names are also cumbersome for the time primitives. Maybe just HOURS! and HOURS@ for example would make them more Forthish, or something else...I'll have to play more with those the make things tighter. I should look at your RTC words to see if there's a common point they can share things (I was trying to do mine in a "clean room" environment for starters).
Don't be shy about updating your code in the meantime but don't just edit your old post, try and make a new one or at least announce a change. I hate all those competitions where that last bit of polishing would have made all the difference but the "rules" don't allow it. Sure, we have rules here, the rule is "have fun".
I think that given the rather short notice for this competition that the response has been excellent and so after this I will gear up for the next challenge in 2013 on the 4th of April. That gives you almost 5 months to look at what you can do and I think I will up the stakes with the prizes too. This may include P2 boards which may hopefully be available by then (we can always be hopeful).
Sorry, I was just talking about forth in general om response to David Betz post. You are right I would have to look at this source carefully before this makes sense, as it appears to be not the way that forth usually does it. Even so, if its "very fast on the prop", to fiddle with the stack by moving all the locations, intuitively it would be faster if the locations didn't move. But it is kind of cool that it works so well.
I'll have to start thinking about this. I've had a print of the BYTE Magazine Forth issue cover hanging on my wall for a zillion years but really haven't gotten around to typing more than a few lines of code at a Forth interpreter. I keep meaning to get to it and have a handful of books on Forth to help out but maybe this competition will push me over the edge. As you say, at least this one has a long lead time. Thanks for running these Peter! It's fun to see what people submit even when I don't have time to enter myself.
adjustably limit the average current for a magnetic actuator.
The ADC-Input and ADC-Feedback pins are for the Sigma-Delta ADC.
Of course building this on the PPDB is not exactly the right way for 80MHz counter signals ...
Idealy this should be made in SMD-layout with the smd-prop casing.
Unfortunately the PBoE, which has sigma delta circuit has it tied to the microphone and not accessible to the user.
Peter is our resident Forth iconoclast. If something has a typical way of being done, he is going to find yet another way to do it -- just to keep us all busy.
@MJB
A good night's sleep has a way of cleaning up Forth code. I have used that trick several times.
I was curious how pfth compares to Tachyon, so I ran your benchmarks under pfth. The empty "do loop" is very slow compared to Tachyon. pfth takes 39.4us per loop. About 66 times slower. pfth implements DO and LOOP as fairly large COLON words, which makes it slow. Maybe I need to implement those as primitive kernel words.
The loop "do 0 drop loop" takes 41.0us per loop. Subtracting 39.4us yields 1.6us for the "0 drop" pair. This isn't too bad compared to the 1.2us time in Tachyon.
Speaking of Byte ... some generous soul, obviously a glutton for punishment, at ATARI AGE, took it upon himself to scan, page by page, every issue of Byte on which he could get his hands. One mirror is located at http://malus.exotica.org.uk/~buzz/byte/pdf/.
I downloaded the Byte Forth Issue, August 1980, and then uploaded to my Forth Resources directory. Warning, it is a collection of images of 308 pages in PDF form, not your typical easily searchable PDF. The file is 212 MB.
Thanks but I still have a paper copy of the Forth issue of BYTE! :-)
It's one of the few issues that I kept which also includes the Smalltalk and Lisp issues. I guess I'm a language geek!
Thanks, Brian!!
I used to have boxes filled with BYTEs (from issue one until it lost its charm), then some fool threw them out for some reason......some days, I regret being a fool!
@ Heater
What would you be willing to bet? Becareful now....
There may not be may of use, but we are mean and lean bunch that love to prove a nay sayer wrong.
"Dr. Dobbs Journal", which is still published, has their old issues available online.
Duane J
Dave!!! You were my secret weapon. Now he won't bet anything. You scared him away.
BTW, PropForth is suddenly making sense to me !!! And my blood pressure is also going down. Dec 8th will be my 65th birthday. I thought I'd never see 40 or 50.
Now, despite the fact that I used to read BYTE magazine back in the day I don't recall the Forth article but I assume it contains some example Forth code. Given that all Forths are different I assume this code is not usable on any current Forth for the Propeller.
So the challenge is can any of the Propeller Forths run that code as publish in the BYTE magazine article?
What would I be willing to bet?
Given that the currency around here is source code I will offer as a prize a parallelized version of a Fast Fourier Transform using nothing but Spin and PASM and buildable with the Prop Tool. A task which I have not pulled off myself yet.
OK. Gloves off...
The challenge as stated is:
Which includes ALL of it:)