[PicForth] PicForth 1.0 issues

[David McNab]

Hi,

I've just ditched gforth0.5 and picforth0.31, and am in the process of 
upgrading to gforth-0.62/picforth-1.0.

A number of issues with the overall package, and what I'm experiencing 
in the upgrade process.

1) 'Make' failure

   Compiles dcc2.hex ok, fails when creating disassembly, with:
      *** No rule to make target `dcc2.disasm', needed by `all'.  Stop.

2) Omissions

   The directories 'fdasm' and 'bootloading' are not present in the 1.0
   tarball.

3) Impact of host-native 'call'

   In target mode, all host words are hidden by default, so 'call' in
   assembler mode works fine.

   However, 'call' in meta-space words (eg, words which generate code)
   invokes gforth's 'call', not picforth's CALL which generates a
   PIC CALL instruction. I note the workaround word 'tgt-call', which
   bypasses the problem. But this is not mentioned in the manual, or in
   the CHANGES file. A quick mention in the manual would save dramas
   for power-users.

4) Gforth 0.6.2 weirdness

   I have an immediate meta word (called dbg") which does a '$22 parse'
   to get a string, then generates some target code within whatever
   target word definition it appears in.

   I invoke this word inside a target word, followed by other words on
   the same line. For example:

      target
      : someword
          ...
          state @ event @ dbg" a debug message" drop drop
          ...
      ;

   dbg", as an immediate meta word, eats the string, then generates
   some pic instructions inside someword. After dbg" finishes running,
   we should be back in target mode by the time the gforth lexer reaches
   the first 'drop'.

   With picforth-0.31/gforth-0.5, this is exactly what happens, the code
   compiles/runs fine.

   But with picforth-1.0/gforth-0.6.2, it appears that when dbg" finishes
   running, we're still in meta mode for some weird reason. When gforth
   reaches the 'drop', it executes that immediately, which impacts the
   compile time host stack. However, when gforth reaches the start of the
   next line, it's happily back in target mode, so the 'drop drop'
   generates target-code within someword to dump 2 cells off the PIC
   stack.

   Workaround is to have no more words on a line after a
   'dbg" some string"' statement. Perhaps this also applies with any
   meta word I create and reference inside a target word def.

   The presence of this issue is worrying, and reduces my
   confidence in picforth-1.0/gforth-0.6.2. I don't feel fully safe
   to implement meta words and trust they'll work as expected.

   I'm not hardcore with forth, I'm just a mere medium-level PicForth
   power-user, so I don't know where to start with trying to debug this,
   whether this is an issue with gforth itself, or with any changes
   that have happened with picforth in the 0.31-1.0 transition.

Anyway, I've gone on long enough here. All else seems ok FWICT, but I'll 
report any more issues I come across.

-- 
Cheers
David