Re: [Amforth] Simulation of AVR with Amforth in simavr? (And: Unnescessary multiple writes to EEPROM?)

[Mikael N. <mik...@pp...>]

Hi Wojtek,
Just to inform you that FlashForth buffers the DPs and LATEST in ram 
during compilation.
This lessens the wear on the EEPROM and makes the compilation go faster !

BR Mikael

On 11/20/2013 12:31 AM, wzab wrote:
> Sorry, I've sent my message from another address, not registered to the
> list. Therefore I resend it from the proper one - Wojtek
>
> On 14.11.2013 19:48, Matthias Trute wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>>
>>> What's absolutely strange to me, is that definition of single word
>>> causes eeprom cells 2 and 3 to be rewritten 8 times (?!).
>> I just committed a change that should not write anything
>> to the EEPROM if nothing will change. In your example the
>> address 2 should not be rewritten over and over again with
>> the same number. Its not that well tested however, feedback
>> would be very welcome.
>>
>>
>> Matthias
> Hi,
>
> I have checked the last trunk version (r1470), and it seems, that number
> of writes to the EEPROM is slightly reduced.
> However still the value at address 0x0002 is incremented after any
> single word is added to the FLASH.
> Only the higher word ad 0x0003 is not written unnecessarily.
> Wouldn't it be reasonable to update the whole word at 0x0002,0x0003 only
> after the whole compilation of a new word is finished?
>
> Yet more EEPROM friendly would be the solution (which I shortly
> described in the initial post in this thread), where the  EE_DP
> and EE_FORTHWORDLIST are not located in the EEPROM, but in the RAM.
> Of course in this case their correct values should be calculated when
> AVR is booted.
> It could be done by scanning the FLASH, but in this case the list
> of compiled words should be a doubly-linked list (as the begining of the
> list only could be stored in the FLASH or EEPROM, and the list should be
> traversable in both directions - from the begining, when the FLASH is
> scanned after RESET, and from the end, when the word is looked up).
>
> So decreased wear of the FLASH would come at price of increased FLASH
> consumption for each word (additional pointer to the NEXT word should be
> added). If this pointer was located at the end of the compiled word, and
> value 0xffff denoted the last word, then it could be conveniently
> updated when the next word is compiled).
>
> I don't know is the above idea reasonable at all?