Braino,
You can easily check it is correct. It's simple algebraic rearrangement. That's all that happened there.
I know it's correct because I just rearranged the code in my other rapid development environment and it still works. You see it's written in Go, which I think you quite like.
It works at the cost of almost halving the speed. That would seem to be the other side of splitting words up into smaller words and not using locals or global temporaries, you end up doing the same calculations again.
I can go further and factor out the common sub expressions into their own functions:
func twiddle1(w uint32, a int32, b int32) int32 {
return (((a * (wx[w] + wy[w]))) - ((wy[w] * (a + b))))
}
func twiddle2(w uint32, a int32, b int32) int32 {
return (((a * (wx[w] + wy[w]))) + ((wx[w] * (b - a))))
}
At which point our calculation looks like:
tx := bx[fi + bu] - twiddle1 (w, bx[fi + bu + fs], by[fi + bu + fs]) >> 12ty := by[fi + bu] - twiddle2 (w, bx[fi + bu + fs], by[fi + bu + fs]) >> 12
bx[fi + bu] = bx[fi + bu] + twiddle1 (w, bx[fi + bu + fs], by[fi + bu + fs]) >> 12
by[fi + bu] = by[fi + bu] + twiddle2 (w, bx[fi + bu + fs], by[fi + bu + fs]) >> 12
bx[fi + bu + fs] = tx
by[fi + bu + fs] = ty
At this point we have something that looks doable in Forth. Probably want to make more words to factor out those array accesses for bx[fi + bu + fs] etc
However it still looks like it needs some globals, fi, bu, fs, that are being determined by the three nested loops that this sits in. Probably tx and ty as well.
Your advice sounds good:
For sure I will have global arrays bx, by, wy, wx.
And words accessing those arrays.
And words for evaluating sub-expressions, perhaps not as you outlined exactly.
As I say, forget this is an FFT it does not matter. We just have a specification for a calculation that needs implementing. That Go code (or the C or Spin versions) is the pseudo code used in the specification.
Heater, it might be quicker to convert your code to Forth by creating global variables for all the local variables you have in your original code. This way you can directly translate your original code line-by-line to Forth. The first few lines would look something like this:
flightindex @ bufferfly @ + b0 ! \ b0 := flightIndex + butterfly
b0 @ flightSize @ + b1 ! \ b1 := b0 + flightSize
\ ...the butterfly.
b1 @ bx get a ! \ a := bx[b1] // Get X[b1]
b1 @ by get b ! \ b := by[b1]
wIndex @ wx get c ! \ c := wx[wIndex]
wIndex @ wy d ! \ d := wy[wIndex]
c @ d @ + a @ * 4096 / k1 ! \ k1 := (a * (c + d)) >> 12
a @ b @ + d @ * 4096 / k2 ! \ k2 := (d * (a + b)) >> 12
This technique should allow you to get the FFT working in Forth very quickly. You may need to prefix your local variables with "fft_" so they won't conflict with other global variables that you might be using.
Once you get this working you can optimize it for Forth by using DUP, OVER, etc. to keep things on the stack so you can reduce the number of reads and writes to variables.
EDIT: BTW, your approach of breaking the FFT up into small routines is good also. It may be a better way to go since it will probably look more like the final Forth code. Either way is fine.
You are in danger of doing this whole project for me:)
I already thought about taking that approach it's the obvious thing. I was going to use names like "fft.b0".
Then again I like the idea of minimizing the number of globals.
Then again... using the Forth gurus suggestion of splitting the thing down to words for smaller and smaller sub-expressions kills performance as you end up recalculating the same thing over and over.
Then again... I really don't care about performance for this exercise, it's going to be Smile whatever you do. The real Forth gurus bail out and work in assembler as it's easier to write and runs much faster:)
prof_braino, you really need to study other languages.
Thank you for the suggestion. Clearly the past 30 years has not been sufficient.
This allows one to translate algorithms directly into code. It's difficult to do the same thing in Forth.
Don't know what you are talking about here. Unless you mean you have trouble with the postfix notation. That is simply the nature of the tool, just like adjectives after the noun in French or verbs at the end in Japanese. You get the hang of it if you stick with it. But we always translate the algorithm into code, in any language. Its just a question of what you are used to.
However, it won't be very efficient if we do it this way. Other languages have optimizing compilers that will generate efficient assembly, and there is no need to re-organize the code.
It will get easier when you stop fighting the tool. Optimizing comes last, if ever, after the code is working. Don't worry about efficient at this point, a beginner has no basis to for recognizing efficient or optimized until after (s)he has achieved "working". If the algorithm is implemented SIMPLE, the rest starts to take care of itself.
Walk through the algorithm line by line, implement the algorithm using forth words in the simplest possible way you know how, makes sure each line does its function correctly. This should take about the the same time again as reading the algorithm, if you are in the groove. After it works, identify the bottlenecks. Factor out all the local variables if you wish. If there is a clear bottleneck, we can start looking at ways to make it faster. But optimizing is an advanced step, so do this LAST.
We need to get out sea-legs before the ship will sail smoothly.
Welcome to the Forth world. There is no right or wrong way -- only the Forth way. You will be assimilated! I need to watch the Star Trek episode where Picard was able to break away from the Borg. Maybe that will help me figure out how to escape from the Forth world and return back to normal programming.
Heater
You have answered you own question, it's unreadable.
If you have a requirement to manipulate arrays as part of a larger
project you would have to define a catalogue of helper words , so that the project
is reaable and eaeily maintained
Forth CAD and Imaging projects are a classic case. There are few few around.
Heading in the right direction ? You bet, you are looking at forth again
prof_braino, only 30 years. That means you started programming at age 40?
I believe in using the best tools for the job. There are cases where assembly is the best tool, and there are cases where C is the best tool, and there are cases where Spin is the best tool, and there are cases where Forth is the best tool. However, I'm struggling to find applications where Forth is the best tool. The only real application I can see is when a new processor is developed, and Forth is used to bootstrap other development tools.
Based on the following this is how I would proceed. As Dave pointed out, this is not the most efficient way to do it. But we don't care at this point, the first task (particularly for a beginner, is to get some valid forth code that performs that function.
b0 := flightIndex + butterfly
b1 := b0 + flightSize
// ...the butterfly.
a := bx[b1] // Get X[b1]
b := by[b1]
c := wx[wIndex]
d := wy[wIndex]
k1 := (a * (c + d)) >> 12
k2 := (d * (a + b)) >> 12
k3 := (c * (b - a)) >> 12
tx := k1 - k2
ty := k1 + k3
k1 = bx[b0]
k2 = by[b0]
bx[b1] = k1 - tx
by[b1] = k2 - ty
bx[b0] = k1 + tx
by[b0] = k2 + ty
\ 20121210 Braino xlation of heater's FFT snippet to forth
wvariable wIndex \ what does wIndex indexing?
: wIndex@ wIndex W@ ;
: wIndex! wIndex W! ;
wvariable flightIndex \ what does flightIndex indexing?
: flightIndex@ flightIndex W@ ;
: flightIndex! flightIndex W! ;
wvariable butterfly \ what does wIndex indexing?
: butterfly@ butterfly W@ ;
: butterfly! butterfly W! ;
wvariable flightsize \ what does wIndex indexing?
: flightsize@ flightsize W@ ;
: flightsize! flightsize W! ;
wvariable wIndex \ what does wIndex indexing?
: wIndex@ wIndex W@ ;
: wIndex! wIndex W! ;
20 CONSTANT <arraysize>
\ I use $ to designate an address that is used with an offset for an array as opposed to a single variable
wvariable $bx <arraysize> allot
wvariable $by <arraysize> allot
wvariable $wx <arraysize> allot
wvariable $wy <arraysize> allot
\ I put the ! and @ in front for arrays, instead of in back as for single variables
: !bx \ ( value index - ) \ takes a value and an offset, and stores this in the array
$bx + W! ;
: !by \ ( value index - ) \ takes a value and an offset, and stores this in the array
$by + W! ;
: !wx \ ( value index - ) \ takes a value and an offset, and stores this in the array
$wx + W! ;
: !wy \ ( value index - ) \ takes a value and an offset, and stores this in the array
$wy + W! ;
: @bx \ ( index - value ) \ takes a value and an offset, and stores this in the array
$bx + W@ ;
: @by \ ( index - value ) \ takes a value and an offset, and stores this in the array
$by + W@ ;
: @wx \ ( index - value ) \ takes a value and an offset, and stores this in the array
$wx + W@ ;
: @wy \ ( index - value ) \ takes a value and an offset, and stores this in the array
$wy + W@ ;
wvariable b0 \ meaningful name?
wvariable b1 \ meaningful name?
: b0@ \ ( - value)
b0 W@ ;
: b1@ \ ( - value)
b1 W@ ;
: b0! \ ( value - )
b0 W! ;
: b1! \ ( value - )
b1 W! ;
: k1 \ ( - integer ) \ I have no clue what k1 is intended to mean of do, but this is how I would implement what you wrote
\ k1 := (a * (c + d)) >> 12
b1@ @bx \ a
b1@ @by \ b
wIndex@ @wx \ c
wIndex@ @wy \ d
+ \ c + d
b1@ @bx \ a
* \ (c+d) * a
12 rshift \ (a * (c + d)) >> 12
;
: k2 \ ( - integer ) \ I have no clue what k2 is intended to mean of do, but this is how I would implement what you wrote
\ k2 := (d * (a + b)) >> 12
b1@ @bx \ a
b1@ @by \ b
+ \ (a + b )
wIndex@ @wy \ d
* \ (a+b) * d
12 rshift \ (d * (a + b)) >> 12
;
: k3 \ ( - integer ) \ I have no clue what k3 is intended to mean of do, but this is how I would implement what you wrote
\ k3 := (c * (b - a)) >> 12
b1@ @by \ b
b1@ @bx \ a
- \ ( b - a )
wIndex@ @wx \ c
* \ (c * (b - a))
12 rshift \ (c * (b - a)) >> 12
;
: tx \ ( - integer ) tx := k1 - k2
k2 k1 - ;
: ty \ ( - integer ) ty := k1 + k3
k3 k1 + ;
\ There is something weird with k1 and k2 at this point, so I skip that and just do what it wants instead of what it says
\ k1 = bx[b0] <= this is a mistake I bet
\ k2 = by[b0] <= this is a mistake I bet
\ bx[b1] = k1 - tx <- so this becomes
\ by[b1] = k2 - ty <- so this becomes
\ bx[b0] = k1 + tx <- so this becomes
\ by[b0] = k2 + ty <- so this becomes
\ bx[b1] = bx[b0] - tx
\ by[b1] = by[b0] - ty
\ bx[b0] = bx[b0] + tx
\ by[b0] = by[b0] + ty
: bx[b1] \ = bx[b0] - tx
b0@ @bx
tx
-
b1@ !bx
;
: by[b1] \ = by[b0] - ty
b0@ @b0
ty
-
b1@ !by
;
: bx[b0] \ = bx[b0] + tx
b0@ @bx
tx
-
b0@ !bx
;
: by[b0] \ = by[b0] + ty
b0@ @by
ty
+
b0@ !by
;
I would use meaningful names instead of b0 and b1 etc.
After the code works, I would factor out all the single variables as possible
assuming the above worked, you could then factor out the extra definitions if needed. In the case of the FFT, it might be beneficial, since everything gets executed a lot.
Assuming I still did not make any cut and replace errors, and it still works, I could remove the last of the unnecessary definitions and end up with the ulimate forth code to perform this snippet. I wouldn't do that of course, until I have the rest of the code that this snippet belongs to.
We always start with the easy version that has a single function for everything we need to focus on, and when it works reduce it down to the least instructions to get the job done in the time available.
Assuming the original code test out a s working, and I made no copy and replace error, the following would be the minimal forth code to do heater's snippet. I hope the process to get from there to here is n more clear.
Remember to get from the first post to this one I only did the search and replace function, I did not have watch the stack or keep track of anything besides editing after the original version was (would have been) tested as working correctly.
The FFT is working with signed values, so I don't think W@ is going to work unless you do a sign extension. Also 16 bits may not provide enough precision and/or range. Also, this won't run under gForth. The other thing is that I think the ">> 12" is intented to be an efficient alternative to dividing by 4096. If that's the case, then it needs to be an arithmetic shift that copies the sign bit. So you probably need to use "/ 4096" instead of "12 rshift".
I would suggest creating @ and ! words using ": @ L@ ;" and ": ! L! ;" so that the code will run under gForth as well.
Sorry I ddn't test the above. The offsets are for character/byte array cell size, not for word. The offests would have to be times two for word cells i guess.
2*
Could you point me to the full C version you are working on? I could try a first pass at the translation. Somebody else would have to debug it as I don't understand what it does, but I could at least make a start.
The FFT is working with signed values, so I don't think W@ is going to work unless you do a sign extension. Also 16 bits may not provide enough precision and/or range. Also, this won't run under gForth. The other thing is that I think the ">> 12" is intented to be an efficient alternative to dividing by 4096. If that's the case, then it needs to be an arithmetic shift that copies the sign bit. So you probably need to use "/ 4096" instead of "12 rshift".
I would suggest creating @ and ! words using ": @ L@ ;" and ": ! L! ;" so that the code will run under gForth as well.
That could work. Do we have to check alignment in hub memory for the longs?
What would be a good sample dataset for testing? how big is the data going to be? Does it want a stream?
How big would the arrays be, typically? 1024 element? Could we use like 100 elements and process each array in a separate cog?
Could we start with word cells just for kicks, or is that just plain too small? If world is used, could we shift left 16 bits and then shift right 16 + 12 bits?
I don't have my stuff set up so i can't check anything. But this is startign to get fun.
heater, If you could point me to the full program you are working from, I could take a stab at translating the whole thing. Or at least parts of it. I have a box I could put gforth on, I can try that tonight when I get home if you want.
@dave - no, I'm not actually 70, I post silly data when its available to the general public, ever since my bout with identify theft a few years ago. Easy to recognize dates like Pearl Harbor day, St. Swithen's Day, Sadie Hawkins Day, etc give me clue where scammers got the data. Sometime I make my age over 100 or less than 1 and still get hits! It always make me smile to receive mail addressed to Judge Dr. Professor Braino the 3rd, Ph. D, US Coast Guard, Retired (Mrs).
I only give out my real birthday to folks that might buy presents.
It uses floating point, so it's not going to work on any of the Prop forths. Why not? I haven't implement floating point for pfth. For me, it just doesn't seem to be worth the effort to implement floating point in Forth when there are better solutions for it, such as C or Spin.
OK, floating point is out.
The Heater FFT is built to not use floating point because the Prop has none.
That means we are treading new ground here in the Forth FFT world.
I have not given up just yet....
NO, the whole thing is NOT going to look like post 109; If somebody is bothered that having the intermediate definitions they can be cut out, and that would look like post 109
In reality, the code will look more like post 87, where everything is really obvious what its doing. And it will be plenty fast for many purposes. But if you want it faster, smaller, what ever, you have a bunch of options.
You'll see. Its either going to be clear enough, or its not. Its going to be fast enough, or its not. But wait until we have something to look at before you decide its good or bad. You seem to want to jump to "Step 4: Profit!" before defining Step 3.
However, I might have more questions about the C code than you have about forth code. I don't want to hijack you thread. (anymore than I already am).
FLOAT is why not. I hear the prop doesn't do float without extra support. It might run on propforth, but you would have use the software float extension, or use nick's floating point coprocessor support. FLOAT. I don't know much about software float except that I haven't used it on an integer machine..
But, I saw that somebody has an FFT on an arduino, (on hackaday the other day) so it should be possible is Rick is interested.
EDIT - Rick has the 5.3 prerelease, which has the float support in the extensions directory. Not that I would volunteer Rick with out asking or anything.
No, FLOAT is not why not.
For example, feed that into gforth and you get this:
$ gforth temp.fs
in file included from *OS command line*:-1
temp.fs:1: Undefined word
>>>(*<<<
Backtrace:
$B71F9EDC throw
$B7206638 no.extensions
$B71FA054 interpreter-notfound1
Clearly in whatever Forth that is comments are defined differently.
OK let's delete everything until we get to something that looks likes a Forth definition:
~$ gforth temp.fs
in file included from *OS command line*:-1
temp.fs:3: Undefined word
0e 0e 0e 0e >>>FLOCALS|<<< q r s t |
Backtrace:
$B71ECEDC throw
$B71F95F8 no.extensions
$B71EEE10 compiler-notfound1
Ok, we give up at this point. Clearly it's written in a completely different language.
I note that the forth fft that Heater referenced in post #110 actually computes the fht of data, which is then transformed into the fft. This has already been accomplished in PropForth.
I like seeing all these discussions on forth, and what folks think about it.
The arguing is good, it reenforces my ideas about what forth is.
Of course, nobody is required to agree with me, but I look at forth this way.
Every development environment is different, because every person likes things different. One person wants their toolbar on the top, others want on the bottom, and some even want it on the side. Fine, with forth, you can have that, just move a few words around, define a few more, and poof, instant environment that katers to your wants.
This is how I look at forth, no need to conform to anyone else's idea of what your development environment should be, do what you like, and it's uniquely yours.
Of course, when you're writing something for release/production, things are different, but my feeling on forth is that it *can* be all things to all people if people want it to be, where else can you change your entire environment just by adding a word or two to your development language?
I even think an os written entirely in forth would be an awesome os, because it would allow everyone to work exactly the way they want. The whole idea that each computer *must* be the same as every other machine (imo) is just silly, and I blame ms for making this idea stick in so many folk's minds. The first thing most folks do when they get on a new system is to change it to work the way they want, so why the idea that all systems should look and act the same.
I honestly believe that forth *could* be an excellent tool, to increase productivity, especially since you *can* define your own words.
If pasm/spin have a function for doing something, then by all means, create a forth word that uses that capability. There's no reason to make any forth look like any other forth, that's the whole point of forth, no two dictionaries are going to be the same, and that's by design. As folks keep saying, there's no wrong way to do something in forth, there's certainly better ways of doing things, but as long as it works for you, then use it, that's the whole point of forth.
Sure, it's nice to be able to say, this forth conforms to this standard, or that forth can do x y or z, but when it comes down to it, forth is nothing more than a language you can mold to fit your own wants and likes, and what programmer wouldn't be happy with that?
nglordi,
I must emphasize again that the fact that my personal initial Forth challenge is an FFT is nothing to do with wanting a FFT in Forth. It's only a way for me to explore the language and experiment for myself, it could have been anything. As such a ready made solution is cheating:)
However if you have a link to that FHT/FFT I'll for sure want to see it at some point.
Interesting views re: the look and feel of operating systems and IDEs.
At some point an OS has to have some kind of standardization else we are all living on our own islands and progress is going to be even slower than it is now.
I would not bring IDE's into this debate. In my mind a programming language is independent of whatever IDE or just editor and tools you use to work with it. The language is about syntax and semantics not about syntax highlighting, intellisense, menus and buttons. And again the language is independent of it's particular implementation, compiled, interpreted, jited, whatever.
I'm not sure how Forth's allowing one to define words is any different from being able to do the same in pretty much every other language. Surely one could get the OS/IDE customization you speak of in Python another language.
does your PASM FFT code need 32 bits for internal computation?
and is this why you use 32 bit input and output vectors?
Your Inputs are 12 bits only as far as I understand.
so would 16 bit precision be enough saving half of the 2k vector space ?
by just replacing RDlong with RdWord ? and adapting the offsets of course ...
MJB
Comments
You can easily check it is correct. It's simple algebraic rearrangement. That's all that happened there.
I know it's correct because I just rearranged the code in my other rapid development environment and it still works. You see it's written in Go, which I think you quite like.
It works at the cost of almost halving the speed. That would seem to be the other side of splitting words up into smaller words and not using locals or global temporaries, you end up doing the same calculations again.
I can go further and factor out the common sub expressions into their own functions:
func twiddle1(w uint32, a int32, b int32) int32 { return (((a * (wx[w] + wy[w]))) - ((wy[w] * (a + b)))) } func twiddle2(w uint32, a int32, b int32) int32 { return (((a * (wx[w] + wy[w]))) + ((wx[w] * (b - a)))) }At which point our calculation looks like: At this point we have something that looks doable in Forth. Probably want to make more words to factor out those array accesses for bx[fi + bu + fs] etcHowever it still looks like it needs some globals, fi, bu, fs, that are being determined by the three nested loops that this sits in. Probably tx and ty as well.
Your advice sounds good:
For sure I will have global arrays bx, by, wy, wx.
And words accessing those arrays.
And words for evaluating sub-expressions, perhaps not as you outlined exactly.
As I say, forget this is an FFT it does not matter. We just have a specification for a calculation that needs implementing. That Go code (or the C or Spin versions) is the pseudo code used in the specification.
flightindex @ bufferfly @ + b0 ! \ b0 := flightIndex + butterfly b0 @ flightSize @ + b1 ! \ b1 := b0 + flightSize \ ...the butterfly. b1 @ bx get a ! \ a := bx[b1] // Get X[b1] b1 @ by get b ! \ b := by[b1] wIndex @ wx get c ! \ c := wx[wIndex] wIndex @ wy d ! \ d := wy[wIndex] c @ d @ + a @ * 4096 / k1 ! \ k1 := (a * (c + d)) >> 12 a @ b @ + d @ * 4096 / k2 ! \ k2 := (d * (a + b)) >> 12This technique should allow you to get the FFT working in Forth very quickly. You may need to prefix your local variables with "fft_" so they won't conflict with other global variables that you might be using.Once you get this working you can optimize it for Forth by using DUP, OVER, etc. to keep things on the stack so you can reduce the number of reads and writes to variables.
EDIT: BTW, your approach of breaking the FFT up into small routines is good also. It may be a better way to go since it will probably look more like the final Forth code. Either way is fine.
You are in danger of doing this whole project for me:)
I already thought about taking that approach it's the obvious thing. I was going to use names like "fft.b0".
Then again I like the idea of minimizing the number of globals.
Then again... using the Forth gurus suggestion of splitting the thing down to words for smaller and smaller sub-expressions kills performance as you end up recalculating the same thing over and over.
Then again... I really don't care about performance for this exercise, it's going to be Smile whatever you do. The real Forth gurus bail out and work in assembler as it's easier to write and runs much faster:)
Thank you for the suggestion. Clearly the past 30 years has not been sufficient.
Don't know what you are talking about here. Unless you mean you have trouble with the postfix notation. That is simply the nature of the tool, just like adjectives after the noun in French or verbs at the end in Japanese. You get the hang of it if you stick with it. But we always translate the algorithm into code, in any language. Its just a question of what you are used to.
It will get easier when you stop fighting the tool. Optimizing comes last, if ever, after the code is working. Don't worry about efficient at this point, a beginner has no basis to for recognizing efficient or optimized until after (s)he has achieved "working". If the algorithm is implemented SIMPLE, the rest starts to take care of itself.
Walk through the algorithm line by line, implement the algorithm using forth words in the simplest possible way you know how, makes sure each line does its function correctly. This should take about the the same time again as reading the algorithm, if you are in the groove. After it works, identify the bottlenecks. Factor out all the local variables if you wish. If there is a clear bottleneck, we can start looking at ways to make it faster. But optimizing is an advanced step, so do this LAST.
We need to get out sea-legs before the ship will sail smoothly.
You have answered you own question, it's unreadable.
If you have a requirement to manipulate arrays as part of a larger
project you would have to define a catalogue of helper words , so that the project
is reaable and eaeily maintained
Forth CAD and Imaging projects are a classic case. There are few few around.
Heading in the right direction ? You bet, you are looking at forth again
I believe in using the best tools for the job. There are cases where assembly is the best tool, and there are cases where C is the best tool, and there are cases where Spin is the best tool, and there are cases where Forth is the best tool. However, I'm struggling to find applications where Forth is the best tool. The only real application I can see is when a new processor is developed, and Forth is used to bootstrap other development tools.
\ 20121210 Braino xlation of heater's FFT snippet to forth wvariable wIndex \ what does wIndex indexing? : wIndex@ wIndex W@ ; : wIndex! wIndex W! ; wvariable flightIndex \ what does flightIndex indexing? : flightIndex@ flightIndex W@ ; : flightIndex! flightIndex W! ; wvariable butterfly \ what does wIndex indexing? : butterfly@ butterfly W@ ; : butterfly! butterfly W! ; wvariable flightsize \ what does wIndex indexing? : flightsize@ flightsize W@ ; : flightsize! flightsize W! ; wvariable wIndex \ what does wIndex indexing? : wIndex@ wIndex W@ ; : wIndex! wIndex W! ; 20 CONSTANT <arraysize> \ I use $ to designate an address that is used with an offset for an array as opposed to a single variable wvariable $bx <arraysize> allot wvariable $by <arraysize> allot wvariable $wx <arraysize> allot wvariable $wy <arraysize> allot \ I put the ! and @ in front for arrays, instead of in back as for single variables : !bx \ ( value index - ) \ takes a value and an offset, and stores this in the array $bx + W! ; : !by \ ( value index - ) \ takes a value and an offset, and stores this in the array $by + W! ; : !wx \ ( value index - ) \ takes a value and an offset, and stores this in the array $wx + W! ; : !wy \ ( value index - ) \ takes a value and an offset, and stores this in the array $wy + W! ; : @bx \ ( index - value ) \ takes a value and an offset, and stores this in the array $bx + W@ ; : @by \ ( index - value ) \ takes a value and an offset, and stores this in the array $by + W@ ; : @wx \ ( index - value ) \ takes a value and an offset, and stores this in the array $wx + W@ ; : @wy \ ( index - value ) \ takes a value and an offset, and stores this in the array $wy + W@ ; wvariable b0 \ meaningful name? wvariable b1 \ meaningful name? : b0@ \ ( - value) b0 W@ ; : b1@ \ ( - value) b1 W@ ; : b0! \ ( value - ) b0 W! ; : b1! \ ( value - ) b1 W! ; : k1 \ ( - integer ) \ I have no clue what k1 is intended to mean of do, but this is how I would implement what you wrote \ k1 := (a * (c + d)) >> 12 b1@ @bx \ a b1@ @by \ b wIndex@ @wx \ c wIndex@ @wy \ d + \ c + d b1@ @bx \ a * \ (c+d) * a 12 rshift \ (a * (c + d)) >> 12 ; : k2 \ ( - integer ) \ I have no clue what k2 is intended to mean of do, but this is how I would implement what you wrote \ k2 := (d * (a + b)) >> 12 b1@ @bx \ a b1@ @by \ b + \ (a + b ) wIndex@ @wy \ d * \ (a+b) * d 12 rshift \ (d * (a + b)) >> 12 ; : k3 \ ( - integer ) \ I have no clue what k3 is intended to mean of do, but this is how I would implement what you wrote \ k3 := (c * (b - a)) >> 12 b1@ @by \ b b1@ @bx \ a - \ ( b - a ) wIndex@ @wx \ c * \ (c * (b - a)) 12 rshift \ (c * (b - a)) >> 12 ; : tx \ ( - integer ) tx := k1 - k2 k2 k1 - ; : ty \ ( - integer ) ty := k1 + k3 k3 k1 + ; \ There is something weird with k1 and k2 at this point, so I skip that and just do what it wants instead of what it says \ k1 = bx[b0] <= this is a mistake I bet \ k2 = by[b0] <= this is a mistake I bet \ bx[b1] = k1 - tx <- so this becomes \ by[b1] = k2 - ty <- so this becomes \ bx[b0] = k1 + tx <- so this becomes \ by[b0] = k2 + ty <- so this becomes \ bx[b1] = bx[b0] - tx \ by[b1] = by[b0] - ty \ bx[b0] = bx[b0] + tx \ by[b0] = by[b0] + ty : bx[b1] \ = bx[b0] - tx b0@ @bx tx - b1@ !bx ; : by[b1] \ = by[b0] - ty b0@ @b0 ty - b1@ !by ; : bx[b0] \ = bx[b0] + tx b0@ @bx tx - b0@ !bx ; : by[b0] \ = by[b0] + ty b0@ @by ty + b0@ !by ;I would use meaningful names instead of b0 and b1 etc.
After the code works, I would factor out all the single variables as possible
We always start with the easy version that has a single function for everything we need to focus on, and when it works reduce it down to the least instructions to get the job done in the time available.
Assuming the original code test out a s working, and I made no copy and replace error, the following would be the minimal forth code to do heater's snippet. I hope the process to get from there to here is n more clear.
Remember to get from the first post to this one I only did the search and replace function, I did not have watch the stack or keep track of anything besides editing after the original version was (would have been) tested as working correctly.
I would suggest creating @ and ! words using ": @ L@ ;" and ": ! L! ;" so that the code will run under gForth as well.
Could you point me to the full C version you are working on? I could try a first pass at the translation. Somebody else would have to debug it as I don't understand what it does, but I could at least make a start.
That could work. Do we have to check alignment in hub memory for the longs?
What would be a good sample dataset for testing? how big is the data going to be? Does it want a stream?
How big would the arrays be, typically? 1024 element? Could we use like 100 elements and process each array in a separate cog?
Could we start with word cells just for kicks, or is that just plain too small? If world is used, could we shift left 16 bits and then shift right 16 + 12 bits?
I don't have my stuff set up so i can't check anything. But this is startign to get fun.
@dave - no, I'm not actually 70, I post silly data when its available to the general public, ever since my bout with identify theft a few years ago. Easy to recognize dates like Pearl Harbor day, St. Swithen's Day, Sadie Hawkins Day, etc give me clue where scammers got the data. Sometime I make my age over 100 or less than 1 and still get hits! It always make me smile to receive mail addressed to Judge Dr. Professor Braino the 3rd, Ph. D, US Coast Guard, Retired (Mrs).
I only give out my real birthday to folks that might buy presents.
But, seriously, what do you get the guy that ALREADY has Forth?!?!?!
a FIFTH of Jack Daniels...
This whole exercise is based on the code at: http://forums.parallax.com/showthread.php?129972-fft_bench-An-MCU-benchmark-using-a-simple-FFT-algorithm-in-Spin-C-and-..
But now, if you are going to tell me that the Forth equivalent of that is going to look like this: Then this whole project is doomed. It's easier to read the PASM version, which will also be smaller and faster.
This is not what I'm looking for.
Will that run on any Propeller Forth?
If not why not?
The Heater FFT is built to not use floating point because the Prop has none.
That means we are treading new ground here in the Forth FFT world.
I have not given up just yet....
Got it! Thanks!
NO, the whole thing is NOT going to look like post 109; If somebody is bothered that having the intermediate definitions they can be cut out, and that would look like post 109
In reality, the code will look more like post 87, where everything is really obvious what its doing. And it will be plenty fast for many purposes. But if you want it faster, smaller, what ever, you have a bunch of options.
You'll see. Its either going to be clear enough, or its not. Its going to be fast enough, or its not. But wait until we have something to look at before you decide its good or bad. You seem to want to jump to "Step 4: Profit!" before defining Step 3.
However, I might have more questions about the C code than you have about forth code. I don't want to hijack you thread. (anymore than I already am).
FLOAT is why not. I hear the prop doesn't do float without extra support. It might run on propforth, but you would have use the software float extension, or use nick's floating point coprocessor support. FLOAT. I don't know much about software float except that I haven't used it on an integer machine..
But, I saw that somebody has an FFT on an arduino, (on hackaday the other day) so it should be possible is Rick is interested.
EDIT - Rick has the 5.3 prerelease, which has the float support in the extensions directory. Not that I would volunteer Rick with out asking or anything.
For example, feed that into gforth and you get this: Clearly in whatever Forth that is comments are defined differently.
OK let's delete everything until we get to something that looks likes a Forth definition:
~$ gforth temp.fs in file included from *OS command line*:-1 temp.fs:3: Undefined word 0e 0e 0e 0e >>>FLOCALS|<<< q r s t | Backtrace: $B71ECEDC throw $B71F95F8 no.extensions $B71EEE10 compiler-notfound1Ok, we give up at this point. Clearly it's written in a completely different language.NickL
The arguing is good, it reenforces my ideas about what forth is.
Of course, nobody is required to agree with me, but I look at forth this way.
Every development environment is different, because every person likes things different. One person wants their toolbar on the top, others want on the bottom, and some even want it on the side. Fine, with forth, you can have that, just move a few words around, define a few more, and poof, instant environment that katers to your wants.
This is how I look at forth, no need to conform to anyone else's idea of what your development environment should be, do what you like, and it's uniquely yours.
Of course, when you're writing something for release/production, things are different, but my feeling on forth is that it *can* be all things to all people if people want it to be, where else can you change your entire environment just by adding a word or two to your development language?
I even think an os written entirely in forth would be an awesome os, because it would allow everyone to work exactly the way they want. The whole idea that each computer *must* be the same as every other machine (imo) is just silly, and I blame ms for making this idea stick in so many folk's minds. The first thing most folks do when they get on a new system is to change it to work the way they want, so why the idea that all systems should look and act the same.
I honestly believe that forth *could* be an excellent tool, to increase productivity, especially since you *can* define your own words.
If pasm/spin have a function for doing something, then by all means, create a forth word that uses that capability. There's no reason to make any forth look like any other forth, that's the whole point of forth, no two dictionaries are going to be the same, and that's by design. As folks keep saying, there's no wrong way to do something in forth, there's certainly better ways of doing things, but as long as it works for you, then use it, that's the whole point of forth.
Sure, it's nice to be able to say, this forth conforms to this standard, or that forth can do x y or z, but when it comes down to it, forth is nothing more than a language you can mold to fit your own wants and likes, and what programmer wouldn't be happy with that?
I must emphasize again that the fact that my personal initial Forth challenge is an FFT is nothing to do with wanting a FFT in Forth. It's only a way for me to explore the language and experiment for myself, it could have been anything. As such a ready made solution is cheating:)
However if you have a link to that FHT/FFT I'll for sure want to see it at some point.
Interesting views re: the look and feel of operating systems and IDEs.
At some point an OS has to have some kind of standardization else we are all living on our own islands and progress is going to be even slower than it is now.
I would not bring IDE's into this debate. In my mind a programming language is independent of whatever IDE or just editor and tools you use to work with it. The language is about syntax and semantics not about syntax highlighting, intellisense, menus and buttons. And again the language is independent of it's particular implementation, compiled, interpreted, jited, whatever.
I'm not sure how Forth's allowing one to define words is any different from being able to do the same in pretty much every other language. Surely one could get the OS/IDE customization you speak of in Python another language.
does your PASM FFT code need 32 bits for internal computation?
and is this why you use 32 bit input and output vectors?
Your Inputs are 12 bits only as far as I understand.
so would 16 bit precision be enough saving half of the 2k vector space ?
by just replacing RDlong with RdWord ? and adapting the offsets of course ...
MJB