[PicForth] Festive code generation bug

[easlab at absamail.co.za]

First-off thanks to Sam, David & Alex for contributing their labour.

David McNab wrote:
> > I've seen similar myself, but my patience kinda ran out.
> > PicForth is truly a gem, but alas its flaws can be subtle, deadly and 
> > unpredictable,
> 
Alex Holden wrote:
> I have to say I feel the same way. When Picforth version 1.0 was 
> released I (wrongly) thought that meant it was fairly bug-free, and 
> decided to try it out on a quite large project, thinking it would 
> probably be quicker than writing it in assembly as I usually do. But 
> tracking down PicForth bugs has taken me so long that I'm sure I would 
> have finished well before now if I'd used assembly. But I've got so far 
> (about 90% done, although I've run out of flash space and am having to 
> go back and rewrite stuff to make it smaller) that I'm stuck with 
> PicForth for a bit longer just to get this project done.
> 
My projects are always '90% done'  ;-)

> I'm not saying that PicForth isn't an impressive achievement given the 
> limitations of the PIC architecture, but I do think that the 1.0 version 
> number was premature and misleading.
> 
Well no.  It was perfect/optimum in the broadest sense; it was:
  well documented,
  ample for  testing minimum system, of I/O to a few lines,
  the collaborative structure was put in place which [eventually],
     allowed active contributers to contribute.

I.e. it was launched into the public domain at a stage where it could 
fly well enough the attract contributors.  I'd say at the 'optimum' stage.

> As an aside, in this case the hardware was already built around a 
> PIC16F876, but I've recently decided that in the future I'm going to be 
> moving away from PICs altogether except for very small projects (12C509 
> type stuff). There are better architectures available now such as Texas 
> Instruments' 16 bit RISC MSP430 series, or for a few dollars more you 
> can even get a 60Mhz 32 bit ARM with lots of flash and RAM (Philips' 
> LPC2000 series), both of which are well supported by gcc and several 
> third party commercial compilers (including MPE and SwiftX).

'Task-handlers & floating point arithmentic' in the context of pics, seem 
to be getting absurd.   You get superb bicycles, but no bicycle should be 
'adapted' to function as a 50 passenger bus.

Surely 32 bit ARM is a completely different class to any pic ?
I guess a 32 bit ARM is not appropriate for a throw-away consumer
device like a motor-vehicle-combination-lock, which is where the
pics shine ?

OTOH errors in fundamental stuff like nested IFs should have been
sorted out long before some of the inappropriately fancy tricks
apparently contrived.

== Chris Glur.