Re: 2K program memory limitation?

Alex Holden wrote:
> I was reading picforth.fs trying to fathom out how it works, when I came 
> across this bit:
> 
> \ We are not being strict here. At this time, we assume that all the
> \ code fits in 2kwords (11 bits addressing) and that main data fits in
> \ one bank (except special registers).
> 2000 constant code-size
> 
> Does this mean that picforth is only capable of using the first 2K 
> instructions

At that stage in picforth.fs, the radix has been set to hex.
'2000' means 8192 bytes.

The comments in picforth.fs refer to the fact that PICs such as the 
16F88, 16F873[A] etc only have 4096 words of program flash, so someone 
programming to those chips needs to keep an eye on program memory usage, 
while someone using 16F877s etc can blithly use up the full 8k.

I've been using PicForth for over a month, and recommend it wholeheartedly.

I suggest you commit to using PicForth, at least for a while.

Try it with lots of tiny programs, and make a few steps at a time, and 
you'll realise the genius behind PicForth.

For one thing, it has considerable inbuilt intelligence that recognise a 
lot of forth idioms and optimises the generated code to the max. For 
another thing, its bugs are very scarce - it's very possible you won't 
even hit any of them.

And also, with its disassembly output, you'll quickly get a very clear 
grasp of how the Forth code is translated down to machine code, and 
you'll get a feel for how to write the best possible code (ie, knowing 
which forth constructs are faster/smaller/cheaper than others).

Lastly - yes, reading picforth.fs is like putting your brain into a 
blender. A lot of the code is unfathomable (to me anyway, as someone 
with a Python/C background). But I have grasped bits of it, and have 
succeeded in writing some useful and powerful extensions. You don't have 
to understand everything in picforth.fs to get great benefit from the 
language.

-- 
Cheers
David