Enoch,
> I understand that Mikael ("FlashForth") represents "the competition" but
> his point, in my opinion, cannot be ignored.
I did not ignore his opinion. I was a little surprised that he
uses the amforth mailing list to place an advertisement for his
system, but its ok.
> 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...
I absolutely dislike a "savesystem" or whatever these words are
called. Regardless of how many systems utilize them in one way or
another. I'm not a mainstream opportunist, see my reluctance to
unified memory models... I'll think about caches but don't expect
a quick solution. Ideally it will be a loadable module, that people
that fear of ghosts may use ;)
IMHO (!!) there is a plethora of things that could be done for the
benefit of both amforth and flashforth. Lowlevel system internals is
not.
Matthias
------------------------------------------------------------------------------
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
