[PicForth] Documentation Suggestion

[David McNab]

easlab at absamail.co.za wrote:
> David McNab wrote:
>> It'd help me (and others) enormously if there were more 
>>comments in [picforth.fs]

> Is it appropriate/necessary to dig into the inards of PicForth > 
>    gforth > C > assemble > registers > transistors > silicon  > ....?

Point 1 - Forth traditionally blurs the boundaries between OS, compiler, 
language, libraries, application. Forth is not about strict APIs, it's 
about extensibility and customisation. If one prefers strict APIs, 
there's always BASIC.

Point 2 - There's a pile of things I've achieved, that would not have 
been possible without me delving into picforth.fs. To name a few:
  - double/triple/quadruple constants
  - customised string words lcd" and tty", for writing strings to
    lcd and serial port respectively
  - compact jump table
  - compact table-driven finite state machine
  - enumerated constants
  - forward gotos for assembler
  - efficient 24-bit integer math
  - workaround to picforth code page switching bugs (otherwise fatal)
  - compact tables that can cross 256-byte boundaries
  - mapping tables (like python 'dict' or java 'mapping')
  - stack audit diagnostics
  - custom 'main' for making code bootloader-ready

Tinkering with compiler internals is totally in the spirit of Forth. 
Otherwise, a purported Forth implementation is just an ugly limited 
postfix-based language.

Without studying picforth.fs, and looking a little bit underneath the 
'official API', I wouldn't have achieved any of these things, which 
would have completely ruled out PicForth.

The official PicForth API is good, but it falls way short of solving the 
innumerable practical issues that arise with PIC development.

As it is, I'm finding PicForth to be a development platform that's 
actually viable for real microcontroller development projects. What I've 
built so far is faster, and about 300 bytes smaller, than the equivalent 
code which I ported over from C.

What I'm saying is that things would be easier if picforth.fs were a 
little more (or preferably a lot more) transparent.

> 
> Perhaps it's more economic/labour-effective to just 'test and
> provide feedback' to the previous level maintainer ?
> 
> == Chris Glur.
> 
> PS. reading your web-page: it's significant that after substantial
> investigation of other possibilities you've decided to use PicForth
> for your development.
> 
> _______________________________________________
> PicForth mailing list
> PicForth at lists.rfc1149.net
> http://lists.rfc1149.net/mailman/listinfo/picforth
> 
> 

-- 
Cheers
David