Dear Matthias,
I understand that Mikael ("FlashForth") represents "the competition" but
his point, in my opinion, cannot be ignored. All those frequently
changing variables from amforth-eprom.inc should not stay just EEPROM
based:
EE_DP: ; Dictionary Pointer
EE_HERE: ; Memory Allocation
EE_EDP: ; EEProm Memory Allocation
I intend to fix that in my amforth-shadow git but I prefer that you
would take the lead.
The solution is simple, XT_DP, XT_HERE and XT_EDP should be RAM
variables that are initialized from the EEPROM on cold start. A new
immediate word, let's say "eesy" (EEPROM sync), would do the RAM to EE
sync. To be on the safe side let tools/amforth-shell.py issue this
"eesy" for us automatically before exit...
Sincerely, Enoch.
Enoch <i...@hotmail.com> writes:
> Mikael Nordman <mikael.nord...@pp1.inet.fi>
> writes:
>
>> 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
>
> Hello Mikael & All:
>
> I agree, AmForth should follow suit.
> The change seems trivial, a simple rewrite of words/dp.asm, etc.
>
> I like the recent interest in simavr as a standard devel platform.
> Can it be used to benchmark, say, AmForth vs. FlashForth?
>
> Thanks, Enoch.
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
