Re: Data table usage and general error tracing ?

>>>>> "Chris" == easlab  <[email protected]> writes:

> > OK, more smart optimising .
> 
> No, your comment is wrong: table does not use the TOS and does not
> store the values on the stack. It stores them in RAM, but not on the
> stack.
> 
> > I can't see how to do eg: foobar[1] -> foobar[2]
> 
> You can't. Tables are read-only (even those stored in RAM). It is of
> course possible to write a new word (for example table!) that would do
> that, but I haven't had any need for it yet.

That would be true for normal [non-harvard] architecture.
{Which is what I was expecting and what confused me, and misled my 
mind towards TOS manipulations when I saw that the values were not 
just programed into ROM}. Since it IS ram, I suggest:
table is a vector [one dimensional array] which is compulsorily
  initialised [and simultaneously/automagically 'dimensioned'].
Since RAM table is just part of the global-variables space, there is no
reason why it should be restricted to read-only ?

> > IMO, inductive (by examples) is not a substitute for a proper syntax
> > definition eg. of the 'native' words.
> 
> The proper syntax definition is used in the manual. The example only
> helps people to understand the syntax. I personally do not like
> examples in technical manuals, but I know many people do.

I got nothing but irritation from failing to 'decode' your "substitute"
example, except to note that:
"substitutions new-key + !" seems to contradict your
read-only description.

I suggest editing the manual to show the compulsory ID  eg:
| The following words allow you to create tables: 
|  table <identifier>     ( "name" -- )        Start a RAM table

and Vector1[0] -> vector2[3]  should be possible/easy
  perhaps: Vector1 @ vector2 3 + !

> > I belong to those just wishing to find a better than assembly way of
> > programing pics, and am not prepared to allocate much resources to
> > researching linux nor forth.
> 
> > It may be usefull to now know what '2>' means, but if potential
> > picforth users have to make such research, they will just rather
> > abort.
> 
> As part as your contribution to the PicForth community, you could for
> example add an entry in the PicForth wiki
> (http://wiki.enst.fr/bin/view/Picforth) with what you learned.
> 
Yes, I'm very aware of the dynamics/economics of collaborative
development.  As I hate that I have to waste time 'researching' when 
you could/should provide the answer immediately; why should the 
next picuser(s) 'climb the mountain' when he can just read about my 
experiences and errors ?

Once I recover from the un-needed frustration of having to 'research'
linux facilities, which you could have save me from doing, I would give
a beginner's  experience of graduated test sequences on a mininal
16c84 with just 4 ( LSB ) LEDs on portB, and portA input.

I strongly believe in the successive refinement method.

As previously mentioned I wasted many hours with different versions of
DOSEMU to try to drive the hardware programmer, still with no success.
{each developer expects you to 'get married to' his project - life is too
short}.  And I would want to re-test my graduated test-set before
submitting it.  I haven't got the patience to transport the *.hex files
to a separate DOS box.

> >  What is the current situation - will the 'table facility' be
> > available ?
> 
> It is. I thought the CHANGES file was clear enough:

Then what is the syntax for:
Vector1[0] -> vector2[3]
  or if you insist in pretending RAM is read-only
Vector1[0] -> Reg(6)

> | * Changes since PicForth 0.22
> | 
> |   + "table", "ftable", "eetable", "table>" and "end-table" allow to create
> |     respectively RAM, flash or EEPROM tables.
> | 
> | * Changes since PicForth 0.21
> | 
> |   + The words "table" and "tc:" have been removed as they
> |     were inefficient and useless in their current form.                     
> 
> Since I release PicForth in sequential version numbers, 0.23 is more
> recent than 0.23. The word "table" has disappeared between 0.21 and
> 0.22, and has reappeared in another form between 0.22 and 0.23.

Because EEPROM is read-only, the syntax of eetable would differ.
Sacrifice the symmetry between RAMtable and EEtable to get the nice 
facility of writable arrarys ?

Thanks,

 == Chris Glur.

PS. The/my confusion comes from expectations based on previous
non-Harvard architecture. Now I suggest:
* have RAMvectors writable, with different syntax from
* read-only data Table(s)

Writable RAMvectors would be initialised as present, alternatively
  dimension needs to be specified.
Presumably read-only data Table(s) just initialise the value at program time.

It's difficult to imagine but perhaps you found, as gforth claims, that
there are few use for RAMarrays ?