AVR Freaks

I absolutely WOULD implement it in forth because that turns your target into your entire development system and application operating system. 

The target forth is tethered to your desktop and the interface between the host and the target is 100% seamless.  You can write code on the host or on the target.  you can run code on the host or on the target.  once the target application has been built you can configure the system to run your application at boot.  The "boot" rom from that point on is basically the operating system for your application code and you have the option to use it as a means of updating your application in the field or not.

The advantages of forth are significant, specially in an embedded system.  First of all you dispense with the entire "Edit, compile, link, debug, repeat" development cycle and replace it with "edit, debug, repeat".  Forth is interactive, you define primitives and immediately test them.  These you use to create higher level definitions which are also immediately tested.  At all stages of development, everything that you have already coded has already been tested.

Secondly, forth is orders of magnitude more space efficient than the equiv C (think 100 times smaller) and when done right can be more space efficient than the equiv assembler for any non trivial application.  THIS makes forth *THE* solution for pretty much any embedded application you can think of.  

The down side?  Almost nobody knows Forth and most people taking their first look at it go screamin for mamma because there are no data types or operator presidences, no built in protections stopping you from doing "stupid" things and... it is entirely RPN.  If you cant think RPN you wont like this language.

for example

: fib 0 1 rot 1 do tuck + loop nip ;

40 fib . xxxxxxx <-- forth prints out the result xxxxx

"oopts thats wrong"

forget fib

: fib 0 1 rot 1+ 1 do tuck + loop nip ;

fixed!

Your problem probably was not the IF statement but the RPN.  Think of it in this way

  do a test somewhere in your code.  The test result is left at the top of the parameter stack

  x 100 <      \ x goes on stack. 100 goes on stack < tests if x is less than 100.

the top of stack now has a "true" or a "false" flag on it.

  if ...... else ..... then

the IF tests the flag and if it is true it does nothing so the code between IF and ELSE is executed.  The "ELSE" is a unconditional jump to the code after the "THEN" statement.

If the flag at the top of the stack is false the IF is a jump to the code immediately following the else statement.

: fudge

  x 100 <

  if

    \ TRUE PART

  else

   \ FALSE PART

  then ;

Forth IS not easy to learn at first, it is very different to more traditional languages and you have to THINK differently.  This is a major stumbling block for a lot of people.  If however you push through you will come to recognize the elegance and simplicity of the language and once you become proficient with it you will develop applications much faster with it than you would with C in most cases (assuming NON trivial applications).

Think of the forth learning curve as being flatline for the first stage of your learning and then it just clicks and goes ballistic.  Your level of understanding of forth from its lowest levels to its highest become totally intuitive and second nature to you. 

With C you learn quickly how to implement extremely bad code.  It then takes years to master.  So the learning curve is steep at first but then goes quickly flatline.  Over the years you learn to recognize not only what code is bad but why it is bad and with experience you tend to not fall into the pitfalls that a beginner would fall into.  x++ + ++x <-- gotta love C lol.

Just about every forth programmer in the world has the ability to create a from scratch forth compiler of their own after maybe a month or 2 (or less) of learning it.  Once you understand how to code in forth you understand how forth works internally down to the lowest levels.  You can not say the same about C.

My sources are extremely neat and tidy because if they are not then they are no better than an unmade bed.  doing "....\xx..." does not impact this.  IF you look at my github you will see sources that are extremely easy to read.  I have had people who do not code asm OR forth tell me that they can read my sources.  I always look for the cleanest way to implement something, if I cannot do that I go for "whatever works".