amforth-devel

[Amforth] MARKER fixed

[Enoch <ix...@ho...>]

Hello Matthias & All:

MARKER was restoring word-lists in the reverse order. Fixed via a new
REVERSE word which is expected to be useful on its own.

See: http://pastebin.com/iWp7MRmv

Here's the new REVERSE word for those objecting to pastebins :-)

\ ( X1 .. Xn n -- Xn .. X1 n )
: reverse
   >r
   sp@ sp@ r@ cells +			\ ( bot-addr top-addr )
   begin
      over over <			\ bot top cross each other?
   while				\ no
      dup @ >r				\ save top-cell content
      over @ over !			\ replace top-cell
      over r> swap !			\ replace bot-cell
      cell- swap cell+ swap
   repeat
   2drop
   r>
;

Regards, Enoch.

Re: [Amforth] MARKER fixed

[Matthias T. <mt...@we...>]

Hi Enoch,

> Hello Matthias & All:
> 
> MARKER was restoring word-lists in the reverse order.

Sorry for that. 

> Fixed via a new
> REVERSE word which is expected to be useful on its own.

Indeed. See below.

I think that reparing marker this way is only half of the
story. IMHO marker became unmaintainable (at least
for me) so I changed it completely following the idea
from Michael: keep the whole EEPROM instead of
a structured dump of it. The eeprom content got slightly
re-arranged to bundle the to-be-saved data at the 
beginning and a value is used to determine the amount
of this data: (marker)

> 
> See: http://pastebin.com/iWp7MRmv
> 
> Here's the new REVERSE word for those objecting to pastebins :-)

You yourself fell into that trap as well, IIRC ;) Thanks for using email
for this definition. I do not yet understand it, but I'm sure it will work ;)

Matthias

Re: [Amforth] MARKER fixed

[Enoch <ix...@ho...>]

Hello Matthias,

Matthias Trute <mt...@we...> writes:
> I think that reparing marker this way is only half of the
> story. IMHO marker became unmaintainable (at least
> for me) so I changed it completely following the idea
> from Michael: keep the whole EEPROM instead of
> a structured dump of it. The eeprom content got slightly
> re-arranged to bundle the to-be-saved data at the 
> beginning and a value is used to determine the amount
> of this data: (marker)

I would like to note that Michael's approach of backing up "everything"
goes beyond the requirement of the current standard:

------------------------------------------------------------------------
6.2.1850 MARKER
Restore all dictionary allocation and search order pointers to the state
they had just prior to the definition of name. Remove the definition of
name and all subsequent definitions.  Restoration of any structures
still existing that could refer to deleted definitions or deal- located
data space is not necessarily provided.
------------------------------------------------------------------------

Thus, I am conflictied in accepting the new implementation. Need to give
it further thought.

>> See: http://pastebin.com/iWp7MRmv
>> 
>> Here's the new REVERSE word for those objecting to pastebins :-)
>
> You yourself fell into that trap as well, IIRC ;) Thanks for using email

Well, an important forum member expressed a strong dislike to using
"perishable" pastebins. I certainly wanted to please him ;-)

> for this definition. I do not yet understand it, but I'm sure it will work ;)

REVERSE ( X1 .. Xn n -- Xn .. X1 n ) is bound to see good use beyond
that original MARKER bug-fix. Collecting data into the stack inherently
reverses its order... hence, this new and efficient REVERSE
implementation can come handy.

Understanding REVERSE requires some kernel knowledge (specifically, how
the data stack is constructed). There's nothing wrong in that -- we do
here AmForth programming, not Forth stuff for the academia :-)

Regards, Enoch.