Re: PicForth 1.0 issues

>>>>> "David" == David McNab <[email protected]> writes:

David> 1) 'Make' failure

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

How can it compile dcc2.hex? I thought dcc2.fs was not in the
distribution. It's now added.

David> 2) Omissions

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

Ooops, a glitch in the building process omitted subdirectories. This
is now fixed.

David> 3) Impact of host-native 'call'

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

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

In fact, I may prefer to even hide gforth's call with PicForth
one. What do you think about it? I suppose you don't yourself use
gforth's call as it was not present in 0.5.x.

I've included such a patch in PicForth 1.0.1.

David> 4) Gforth 0.6.2 weirdness

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

I'm very dubious about this one. If you look at generator.fs, you will
see something like you describe:

: +verbose option-verbose bit-set lcd-second c"   Manual  mode  " lcd-print ;

Even defining a lcd-print in host mode doesn't cause a problem.

Could you produce the smallest example that exhibits this problem?
This way, once it is fixed, it will enter the regression suite, that I
included by the way in PicForth 1.0.1.

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

If you have non-proprietary code that you are willing to submit as a
regression test, do not hesitate. Alternatively, you can add it
yourself locally. Just dump your code in PicForth's directory, add it
to the PROGS target in the Makefile, and add expected .hex and .disasm
files in tests/expected directory.

Thanks a lot for your feedback David! I'll publish 1.0.1 and 0.34
immediately with those fixes.

  Sam

PS/ I will be leaving for Amsterdam in a few hours and will be back on
    Monday, so don't be surprised if I don't answer immediately
-- 
Samuel Tardieu -- [email protected] -- http://www.rfc1149.net/sam