Lost in C?

LoopyByteloose · 2012-12-21 04:17

I am not really lost in C, but I have found that Tachyon Forth and PropForth really do help with exploring the Propeller. Being interactive, one can actually confirm that cogs are up and running independently of each other. Also, it is a lot easier to tweak motor performance until you have found the right timing. Then you can transfer that info to a C application.

For the Propeller2, I think Forth will be my first choice. And after exploring in Forth, then C.

http://www.forth.org/lost-at-c.html

Heater. · 2012-12-21 05:41

I'm lost in Forth:)

Braino and I have been pondering how to even start on a FFT in Forth for an eternity now. We pretty much concluded that the only way to do it is to throw out all commonly held ideas of good programming practice:)

Perhaps your article will help.

mindrobots · 2012-12-21 05:49

Nice find, Loopy!

Brian will have to add this to his collection.

for an eternity now

I guess since our Mayan calendars have all rolled over successfully, then you're starting on your second eternity! How cool is that???

Heater. · 2012-12-21 06:01

In that article we have this:

[COLOR=#000000][FONT=Times New Roman]: ++ 1 SWAP +! ;         \ Defines the word ++
ALPHA ++                               \ Adds one to the variable ALPHA
[/FONT][/COLOR]

Can you explain how that works, I don't see it fetching the value of ALPHA anywhere, looks more like it's adding one two the address of ALPHA and writing that out somewhere.

Edit: Na, scratch all the above, +! seems to do what we want.

Heater. · 2012-12-21 06:02

Very cool indeed. I'm going to need this second eternity to figure Forth out:)

prof_braino · 2012-12-21 06:18

Heater. wrote: »

I'm lost in Forth:)

Braino and I have been pondering how to even start on a FFT in Forth for an eternity now. We pretty much concluded that the only way to do it is to throw out all commonly held ideas of good programming practice:)

Perhaps your article will help.

Actually, the advice is to start with something easier than an algorithm I don't understand, (some folks have mentioned that FFT is a little involved), that way I could help you and to do some of the simple stuff you need to learn before tackling the complex stuff you want to do. If starting at the finish line, and painfully working your way backward to the beginning, (and back again a couple of times) is good programming practice, then YES you should definitely throw that away. I advise doing it the easy way, as the hard way is proving to be just that.

Since your recursion method has been shown to need a stack that is slightly larger than propforth is configure to accommodate, you should either
a) use a non recursive method using propforth, or
b) ask Peter to make a version of Tachyon configured to has enough room (10 entries of 4 elements of 32 bits each, I believe), plus one, so 41 elements minimum; or
c) reconfigure the propforth kernel to have enough room.

Option A would be easiest, but I imagine you will prefer C since it is almost totally impossible for a new comer, and it will give you evidence that forth is unusable.

So aside from the obvious, yes, I am completely stumped how to proceed.

LoopyByteloose · 2012-12-21 09:58

Oh my..... It seems that Heater is disappointed with Forth on the Propeller. I do have to admit that floating point maths and square roots are not really part of Forth on the Propeller and C has excellent libraries for these things.

Traditionally, Forth has been much better with integer maths and floating point has been done with add-on links. At least that is what I have read. The main attraction I have to is is that it is a great way to work interactively.

Fast Fourier Transforms provide useful and fast tools to microcontrollers that are working with frequency and spectrum analysis. If you really need them, C will provide the best on the Propeller.

It was my intention to just mention that Forth provides a way to poke around and do a lot of discovery in real time. It was never my intention to claim it would replace C.

And I do understand that the stack sizes are limited when compared to Forth on a PC.

LoopyByteloose · 2012-12-21 10:02

Heater. wrote: »
In that article we have this:
[COLOR=#000000][FONT=Times New Roman]: ++ 1 SWAP +! ;         \ Defines the word ++
ALPHA ++                               \ Adds one to the variable ALPHA
[/FONT][/COLOR]
Can you explain how that works, I don't see it fetching the value of ALPHA anywhere, looks more like it's adding one two the address of ALPHA and writing that out somewhere.

Edit: Na, scratch all the above, +! seems to do what we want.

+! is definitely simpler at ++ presumes you already fetched ALPHA's value to the stack, so it presumes there is a fetch instruction within ALPHA.

Heater. · 2012-12-21 16:27

Loopy,

There is no floating point in the FFT that I am trying to implement.

My problems in making this work in Forth go much deeper than that.

RossH · 2012-12-21 19:13

Loopy Byteloose wrote: »

http://www.forth.org/lost-at-c.html

Hi Loopy,

This article starts out with some rather astonishing claims in the first paragraph ...

... Forth, a language that combines the speed, versatility, and compactness of assembly language with the structure and the legibility of C.

This series of claims is fairly easy to refute. Indeed, the article goes on to contradict itself a bit later when it compares Forth to C ...

On the negative side, Forth can be a little slower. In a large program, it may use slightly more code than newer C compilers.

It is actually quite hard to do a comprehensive comparison of Forth with C - as Heater is discovering, the languages are just so different that implementing the same non-trivial algorithm in Forth and C is difficult. But it has been done ... here ... and the results are indeed that Forth programs do tend to be both slower and larger than C. And since C itself is (in general) both slower and larger than assembly language, the claim about Forth being as fast and compact as assembly is obvious nonsense.

Note that I am not criticizing Forth itself - learn it by all means! I would even agree that the Propeller architecture is more suited to Forth than it is to C. Just don't get too excited by the hype sometimes promulgated by adherents of various fringe languages.

Ross.

P.S. As you know, I'm a fan of C, but even I had to laugh at the "legibility" claim! Only a Forth programmer would think that the "legibility of C" was a thing to aspire to!

Dave Hein · 2012-12-21 20:13

The problem with almost any article that compares Forth to another language is that it's written by someone promoting Forth. I haven't come across any articles written by someone that prefers C, Pascal or some other language that compares it to Forth. Because of this, the author will list all the benefits of Forth, but barely mentions any of the drawbacks. It's not impossible to create a Forth version of the FFT, but I wonder if it really worth the effort.

EDIT: If someone really wants to convert the C FFT to Forth I suggest creating global variables for all of the local/global variables used in the C version, and convert it from C to Forth on a line-by-line basis. Once you get this working, then you can move inner loops and other chunks of code into small Forth words that only use stack variables. Eventually you should be able to eliminate most of the global variables that were local variables in the original C code.

D.P · 2012-12-21 21:39

Dave Hein wrote: »

The problem with almost any article that compares Forth to another language is that it's written by someone promoting Forth. I haven't come across any articles written by someone that prefers C, Pascal or some other language that compares it to Forth. Because of this, the author will list all the benefits of Forth, but barely mentions any of the drawbacks. It's not impossible to create a Forth version of the FFT, but I wonder if it really worth the effort.

EDIT: If someone really wants to convert the C FFT to Forth I suggest creating global variables for all of the local/global variables used in the C version, and convert it from C to Forth on a line-by-line basis. Once you get this working, then you can move inner loops and other chunks of code into small Forth words that only use stack variables. Eventually you should be able to eliminate most of the global variables that were local variables in the original C code.

In other words "Get it working then optimize"; just got the nichrome wire glowing 1320F +- 5 degrees for the igniter system on my project. I was able to interactively tune the system from a TACHYON FORTH console. Nice, now I'll condense my debugged\working\sloppy FORTH code into a dictionary word called : IGNITE ( on/off -- ) ..... ;

If I needed "good" FFT on a prop I would be looking for some more silicon I think.

rod1963 · 2012-12-21 23:38

FFT's have been done on 8 bitters for decades, it's not fast but it works. There is no need for additional silicon, any modern 8-16-32bit mcu can easily do it.

If there are problems implementing it, then it's a design flaw with how a particular language was implemented on a particular processor or that the language itself isn't capable of expressing even moderately complex algorithms and data structures without severe mangling.

Peter Jakacki · 2012-12-22 02:14

rod1963 wrote: »

FFT's have been done on 8 bitters for decades, it's not fast but it works. There is no need for additional silicon, any modern 8-16-32bit mcu can easily do it.

If there are problems implementing it, then it's a design flaw with how a particular language was implemented on a particular processor or that the language itself isn't capable of expressing even moderately complex algorithms and data structures without severe mangling.

Wow, what a broad sweeping generalization based on one seldom used aspect of programming microcontrollers. I do agree however that implementing an FFT in Forth looks messy but this type of algorithm is very seldom if ever used on low end control systems. What most control systems require then Forth does well, but it's not magic either and there is the always the stack to contend with which is not normally a problem, except maybe unless you are trying to implement an FFT

Heater. · 2012-12-22 04:38

Perhaps the FFT is a bit heavy duty for a starter project. However the recursive FFT I am propose to start with is actually very simple and short even if it's operation is obscure if you have not done the maths.

Again I have to say, ignore the fact that this is an FFT. I am not looking to use an FFT in Forth. It's just an example of a bunch of calculations and logic typical of any program you might write.

Someone mentioned "good FFT". If it runs and produces the correct results it is "good". I have no delusions about making it fast or handle huge sample sets. It's just an exercise in learning Forth.

Perter Jakacki wrote:

...there is the always the stack to contend with which is not normally a
problem...

Except in Forth.

The stack is not something I ever have to think about much unless I'm working in assembler, even there it's not always necessary, most propeller PASM programs do not use a stack at all.

Forth is a stack based language. But actually using the stack is really hard. There is no easy way to get at the parameters of a word if there are more than two or three of them. There is no easy way to get at data sitting on the stack that a word might want to manipulate. It's so hard in fact that more than one person has suggested giving up any pretense at good programming practice and just use a bunch of global variables.

I think this is the most surprising thing I have learned on my Forth travels so far.

Perter Jakacki wrote:

...except maybe unless you are trying to implement an FFT

The normal FFT doe snot use stack much, it can be done without one. The recursive FFT is a much simpler piece of code and uses only about 40 stack slots for a 1024 point transform, hardly demanding. The fact that Forth is so bad at supporting this recursive approach (see stack issues above) is shocking given that it's stack based approach is often touted as a "good thing".

Still, I'm putting by best foot Forth until this works...

Dave Hein · 2012-12-22 04:52

Loopy Byteloose wrote: »

I am not really lost in C, but I have found that Tachyon Forth and PropForth really do help with exploring the Propeller. Being interactive, one can actually confirm that cogs are up and running independently of each other. Also, it is a lot easier to tweak motor performance until you have found the right timing. Then you can transfer that info to a C application.

For the Propeller2, I think Forth will be my first choice. And after exploring in Forth, then C.

http://www.forth.org/lost-at-c.html

Loopy, I'm curious why you find Forth easier to use than C. Pretty much everything you can do in Forth can be done in C, except for the immediate interpretive commands. But, you can write a C program to peek and poke, and once you've done that I don't see any further advantage that Forth has. With the SimpleIDE you can do compile-and-load quickly an with ease, so there's really not disadvantage to programming that way versus using an intepreter.

Forth really isn't a very good language to develop in. Forth code constantly thrashes around with the stack, which is very inefficient. Compiled C code will keep everything in registers and is more efficient than Forth. Forth interpreters have very little error-checking capability. C compilers have evolved to the point where they will warn you about common programming errors, and it's much easier to write error-free code in C than in Forth. The RPN nature of Forth means that almost everything you want to write in Forth has to be translate from a natural language form to RPN. It's much easier to translate a mathematical formula into C code.

On the Prop, I've programmed in Spin, PASM, PropBasic, C and Forth. Forth would be my last choice for any serious programming task.

LoopyByteloose · 2012-12-22 05:07

@Dave
I find Forth is easier than C because it is interactive. One gets immediate response, sometimes immediate results. With C you have a 'write-compile-load' cycle that is a bit slower.

A second reason is Forth immediately has a terminal up and running for bench work. If I have new components I want to verify, I can explore with Forth in a more direct fashion.

I don't expect Forth to be everything C is, but having an interpreted language with more than mere basic functions does allow people to explore what the Propeller is in a difference fashion.

I am not sure that the absence of error checking is really a serious default. In Forth, you learn that things don't work and just learn to avoid repeating the errors. In C, you get errors and warning messages that are rather cryptic and presume you understand quite of bit of jargon and conceptual information about compilers. The fact that the hardware is so different seems to be better supported by have more than one language solution to confirm what the hardware does.

RPN is not a difficulty for me. I have used RPN calculators for decades and loved the HP-41CX. Arguing that it isn't 'natural language' is rather dubious as no computer language is natural in any real sense.

~~~~~~~~~

I am just trying to say that Forth is a useful and valuable software language for the Propellers. I think the same of C. And I believe that really learning programming requires having some experience with contrasting languages. People that just hang onto one may never see obvious alternatives.

Peter Jakacki · 2012-12-22 05:40

Dave Hein wrote: »

Loopy, I'm curious why you find Forth easier to use than C. Pretty much everything you can do in Forth can be done in C, except for the immediate interpretive commands. But, you can write a C program to peek and poke, and once you've done that I don't see any further advantage that Forth has. With the SimpleIDE you can do compile-and-load quickly an with ease, so there's really not disadvantage to programming that way versus using an intepreter.

Forth really isn't a very good language to develop in. Forth code constantly thrashes around with the stack, which is very inefficient. Compiled C code will keep everything in registers and is more efficient than Forth. Forth interpreters have very little error-checking capability. C compilers have evolved to the point where they will warn you about common programming errors, and it's much easier to write error-free code in C than in Forth. The RPN nature of Forth means that almost everything you want to write in Forth has to be translate from a natural language form to RPN. It's much easier to translate a mathematical formula into C code.

On the Prop, I've programmed in Spin, PASM, PropBasic, C and Forth. Forth would be my last choice for any serious programming task.

I always find it fascinating to see things from the viewpoint of ones who find C easier. A mention was made about the RPN nature of Forth (as if RPN is a bad thing), and that you would have to translate from a natural language to this, however no direct comparison was made with C in this regard although it was touted that it's easier to translate a mathematical formula (not very natural) into C code. Agreed, it's easier to enter a mathematical formula into C which then compiles that into something the machine may understand, usually assembler and but mostly calls to binary blobs of proprietary C libraries. On some processors the machine language is Forth so all that C ends up doing is compiling C source code into Forth code, and so the same can be done with Forth on other processors too. That's one way to look at it.

On the subject of natural language I would not have ever considered C to be anywhere near that mark and yet that odd beast Forth can be tamed to behave very naturally. Of course in the wrong hands it's just as likely to claw your eyes out and become "write-only-code" which unfortunately is also true. But once you tame it, or perhaps it tames you, then things work very nicely. As for peeking and poking, please don't, that makes me cringe, whereas in Forth I can turn all that into natural interactive words like 300 RPM or SLOW SPEED for instance.

When it comes to stack thrashing, I don't believe in thrashing myself, it's not necessary and what's a register but a glorified global variable anyway? Forth has very little error checking because there is no set way that you have to write code, you are not locked into a rigid syntax and rigid types and rigid libraries.

Seriously, Forth is my first choice for serious programming

Now, how do we turn these little sessions we have into something productive? Perhaps we could add a good front-end onto Forth that compiles mathematical formulae into Forth "machine code"? That's a thought.

Dave Hein · 2012-12-22 05:49

Yes, I understand the advantages to an interpretive language. I don't have a problem with RPN either. It makes a lot of sense for calculators. I also prefer HP calculators over other ones that use parentheses. This is because of the limited input/display capability of a calculator. However, when writing expressions on a computer, I much prefer parentheses overn RPN.

People can get by without error checking on small projects, but it's a necessity on large projects where you must interface to code written by other people. I can't imagine writing code for a large project in a language that didn't use data types and error checking. That's one of my big concerns about programming in Spin.

I've spent enough time programming in Forth to know it strengths and weaknesses. I like the ability to define new words, but I don't seem much difference between that and defining functions in other languages. The interactive thing is useful, and I have done similar things in other languages by writing small monitor programs. Most Forth proponents claim that the ability to test code is one of the strengths of Forth. However, I think that practice promotes sloppy programming. I think a more methodical approach is better, especially for large projects. The interactive technique is useful when you don't understand how the system works, and you have to hack at it to learn how it works.

Dave Hein · 2012-12-22 05:57

Peter, there's a very small segment of the programmer population that thinks the same way Chuck Moore thinks, and Forth is the perfect language for them. You are clearly one of those programmers. Most other programmers think in a different way, and Forth is very foreign to them. This larger population of programmers is much more efficient programming in C, C++, Pascal, etc. I think you're are fighting a losing battle trying to convert people to Forth.

Heater. · 2012-12-22 06:31

I think that the RPN thing is probably the least worst feature of Forth that I have found so far. After all writing:

a b + c d + * result :=

Would not much more onerous than writing:

result := (a + b) * (c + d)

and has the benefit of not needing parenthesis or worrying about operator precedence.

Except of course that first version is not Forth in Forth, you have to write:

a @ b @ + c @ d @ + * result !

Which of course is insane.

It's insane because Forth has no variables that you can refer to by name only memory addresses (a, c, d, e) that you can operate on (@ and !)

Except of course having a bunch of global variables is not nice programming practice. There are no local variables and if there were they are frowned on as "bad practice". So those variables can only be on the stack, as far as I am aware, when we come to perform that expression. Say we have the values of a, b, c, d on the stack the expression can evaluated, leaving the result on the stack, like so:

+ 0 2swap + + *

Which of course is insane.

It's insane because now I don't have any names for my data at all and I have to start introducing a bunch of operations on a stack that are not part of my simple problem to begin with.

I must admit that last example is not how a Forther would do it, I leave that as an exercise to the reader, but it illustrates my point.

Conclusion: RPN is not an issue in itself, the way Forth implements it is causing the problems.

Forths interactivity may be nice, but given the speed at which you can do much the same in Spin, just hit F9, it's not much of a gain.

Heater. · 2012-12-22 06:41

Peter,

Agreed, it's easier to enter a mathematical formula into C which then compiles that into something the machine may understand, usually assembler and but mostly
calls to binary blobs of proprietary C libraries.

This is not true, most integer arithmetic in C is compiled into assembler. Complex things may end up calling functions. So what? in Forth you will have words for such things as well.

I don't understand te "binary blobs of proprietary C libraries" thing. Those blobs start out as C source like anything else. There is nothing "proprietary" about the libraries used in GCC, Catalina or many other compilers.

Martin_H · 2012-12-22 07:10

I've written about five programs in Forth, it is interesting, and I may try more things in it in the future. A bubble sort is my most complex program to date which I made generic using execution tokens to allow a parameterized comparison function. That way you could sort either the array or what the cells pointed to based upon that function. It took me about eight hours to get it right, but I had to learn Forth along the way. Worrying about the stack and cells gave me an assembly vibe and I got overwhelmed by it at times.

In assembly a good macro facility is a way to manage complexity and even create local variables. I figure the Forth aficionados must have mastered something similar, but I don't know what it is. As an aside, I ran PropForth in the Gears emulator and it appeared to work, but I couldn't connect a terminal to it to find out!

Update: most C complies will print their assembly output interspersed with the source code. As Heater says, they usually nail the instructions that match the source construct because that is C design center.

4x5n · 2012-12-22 07:16

I have very mixed feelings about forth. I've been using HP (rpn) calculators since the early '80s and have written a lot of programs over the years using the 4 high (plus lastx) stack of the 15C and 41CX that I had. I was introduced to forth ~86 and never warmed up to it.

I look into it every once in a while and always give up on it quickly.

Heater. · 2012-12-22 07:38

Peter Jakacki wrote:

...what's a register but a glorified global variable anyway?

A register is certainly not a global variable. In most high level languages you
never see a register so how could it be?

A global variable may well be stored in some memory space reserved for data as in C. Or it could be on a dynamically allocated heap as in JavaScript. Potentially it could be pushed onto a stack at start up. Global variables are all about scope, visibility, and lifetime of a variables in a program not about how that is implemented by the compiler.

prof_braino · 2012-12-22 07:50

heater, your entire problem is that your inability to program in C when using forth. You have not gotten your head around the different of between C local and global variables versus forth stack location versus memory locations. Nor have you gotten you head around doing simple functions and building them into complex functions in forth, rather than making starting with the most complex you can grasp and call a library.

Forth is not C, the harder you try to force one to be the other, the more trouble you have. I may have mentioned this before, sorry to keep repeating myself.

We must face the fact that certain individuals may find it impossible to work in certain mediums, and some folks may never master some tools.

FredBlais · 2012-12-22 08:10

What I would like to see is a simple interactive Python implementation like this one : http://wiki.python.org/moin/PyMite ported to the Propeller. The memory of Prop 1 is maybe too small though. IMO, much easier to get your head around than Forth.

Dave Hein · 2012-12-22 08:25

Doug, you make a LOT of comments about how people are approaching Forth programming in the wrong way. Have you ever thought that the problem is with Forth and not the programmer? I think it's time for you to step up and write some significant code to prove your point. Let's see an FFT implementation from you in Forth. And please don't say that you can't do it because you don't understand how the FFT works.

I ported lots of code in C where I only had a description of the algorithm, but didn't fully understand how the algorithm work. This is true of almost every CRC/error-correcting code that I've developed in C, and I've written quite a few of them. I've never fully understand the math behind these algorithms, but I've been able to write C code that implements them effficiently.

Forth advocates need to accept the fact that it makes sense to them only because their brains are wired that way. For most of use, our brains are wired differently, and we are more efficient using a compiler that generates efficient code for us. We don't have to worry about stacks and all the bookkeeping that's required to keep track of variables on the stack. Modern C compilers have made programming much more efficient. Unfortunately, the same can't be said for Forth. It's still as primitive as it was when Chuck Moore came up with it.

Duane C. Johnson · 2012-12-22 08:40

Dave Hein wrote: »

Forth advocates need to accept the fact that it makes sense to them only because their brains are wired that way. For most of use, our brains are wired differently, and we are more efficient using a compiler that generates efficient code for us.

Then don't program in forth. Whats the big deal? Get over it!

Duane J

Dave Hein · 2012-12-22 08:46

Duane C. Johnson wrote: »

Then don't program in forth. Whats the big deal? Get over it!

Duane, that's the best advice concerning Forth that I've heard in quite a while. I just find it hard to ignore the outrageous claims made by the Forth advocates, and not comment on them.

4x5n · 2012-12-22 08:50

Duane C. Johnson wrote: »

Then don't program in forth. Whats the big deal? Get over it!

Duane J

I don't :-)

Don't get me wrong I have nothing against forth but it's just not a language for me. For what it's worth neither are cobol or python (nothing against cobol or python either). I have to admit I'm getting tired of the bickering about <insert programming language of your choice> VS <a language you don't care for>.

Can we please stop the language proselytizing. Use whatever language that you like!!

Lost in C?

Comments