[PicForth] Re: Installation, test, refine & BIG picture.

[easlab at absamail.co.za]

J.C. Wren wrote:-
>     I'm playing with the timer 1 registers, and can't figure out how to 
> express something correctly.  Let's say you're running at 19.6608Mhz.  
> At that speed, there are 49152 ($c000) counts in a 10 millisecond 
> interval.  The counter counts up, so you load the TMR1H and TMR1L 
> registers with the negated value, which would be 16384 ($4000).  I'd 
> like to put this as a constant at the top, so '$c000 constant 
> tmr1Reload'.  In the handler code, I want to change modes (correct term, 
> please?) so that rather than taking the constant and AND'ing it with $ff 
> or / 8 at run time, it's done at compile time.  I know (I think) this 
> needs to be handled outside of the PicForth compilation because PicForth 
> doesn't understand 16 bit values of any kind.

Does your paragraph reduce to "I want the compiler to be 'smarter' " ?
I was amazed how 'smart' it was.
This no doubt because much of the 'research' of the gforth software could
just be 'taken over'.
Let's no lose sight of the expressed intention and history of picforth.
Your project must be VERY progressed if such optimisations are your
concern ?
Have you tested substantial 'operations' and constructs ?
Which pic have you used ?
I think we should have a 'graduated test-set' for beginners -- also to
help build some forth fluency, incrementally.
When I left off I was unsuccessfully investigating the use of arrays.

> Yea, it runs fine under 0.5.0.  I created a patch for the Gentoo emerge 
> that basically deleted the emacs junk, and filed a bug report on Gentoo 
> Bugzilla.

It's difficult enough to have the necessary knowledge for this list:
1. hardware,
2. minimum of linux
3. minimum of forth
4. special features of picforth,
so lets NOT 'dilute' ourselves with Gentoo, Bugzilla and emacs.
'Information hiding' is a key, proven method of handling complexity.

> >What programmer do/will you use ?
> >My programmer is DOS based, so I tried to use dosemu, instead of
> >having to transfer data to a dos-box.  [one wants a rapid turn around,
> >to make many small steps towards the goal].  Dosemu is a bit of
> >a 'can of worms' and I couldn't get it to drive the par-port.
> >  
> >
> I use the ICD2 under Windows for another project.  I share a directory 
> on the Windows box out to the Linux box.  I do all the development under 
> Linux, copy the hex file to the mounted Windows directory, spin around 
> to the laptop, import the hex file, and program the board.  It's an 
> extra step, but last time I checked there was no support for the ICD2 
> under Linux.  And it would just be too much trouble to move it between 
> the two boxes.

Yes, it's important to be able to have a rapid turn-around-time for each
iteration.

> What is your project?  (or did I overlook where you already defined it?)

I was looking into a 5 key serial 'mouse' input-device.

>     I've added a couple words to the dictionary.  I've done some testing 
> on them, but I don't know if they meet the "approved" methods or not.  I 
> also added the bit definitions for the sspcon2 register in the 16F877.  
> I don't know if all the parts have that or not.
> 
>     Included is the diff file against 0.31, generated with 'diff -u 
> picforth.fs picforth.new'
> 
>     Feedback would be appreciated.
> 
>     --jc
> 
> --- picforth.fs 2004-06-25 00:22:16.295092007 -0400
> +++ picforth.new        2004-06-25 00:07:13.067416538 -0400
> @@ -742,6 +742,17 @@
>    1 sspcon bit sspm1
>    0 sspcon bit sspm0
> 
> --- snip ---

Well I'm not a linux enthusiast, and have never used 'diff' files and cvs,
and in principle I don't browse or suck-it-and-see. 
So I'd want a description of what the contribution attempts to acheive.
Before I contribute by testing and feeding-back.
It's very simple: the designer would need a fraction of the time to just give
the basic documentation, compared to the time that I'd have to spend
'discovering' the documentation.   It's elementary economics: maximum 
results from minimum effort for the COMBINED team.

Thanks,

 == Chris Glur.