Matthias Trute <mtr...@web.de> writes: > Hi, > >> Indeed, your suggested use of MARKER is what I anticipated but I have to >> agree with you, it would be too difficult/dangerous for an average >> programmer to try. > > I wrote "difficult" not "too difficult" A subtle difference. > >> Hence, let us revisit FORGET. >> I agree with you again that with Flash memory "de-fragmemetation" is >> not an option. However, there is a solution if you agree to modify >> the dictionary structure just a bit. I believe that you are familiar >> with the various "dynamic storage allocation" algorithms (Knuth, Vol >> 1, Fundamental Algorithms, 2.5 Dynamic Storage Allocation). What if >> we introduce one bit for each definition which means "FREE" or >> "IN-USE". FORGET would become: (1) Mark the definition as FREE (2) if >> possible, merge this newly freed Flash space with adjacent Flash free >> definitions. For the purpose of this algorithm the "unused dictionary >> space" would be just another free definition space on our linked >> list. When compiling, we can compile into the largest free >> definition space or choose another strategy. > > That may work. The only problem I have with it is: A colon > definition does not know how much space it needs in advance. > So how do you decide, which fragment do you use with a particular > definition? And what do you do, if such an limit is reached? > >> By the way, I don't agree with Forth-RC1 comment on FORGET which >> says as follows: "This word is obsolescent and is included as a >> concession to existing implementations." > > I have absolutely no problem that FORGET will be forgotten. > >> (2) How else can one implement "Dynamic Software Updating" >> <http://en.wikipedia.org/wiki/Dynamic_Software_Updating>. > > Do you really have non-disruptive software upgrades in mind? > That is so much far beyond the scope of my little toy, that > I even decline any ambitions in this direction.
Matthias, Please don't call your work a toy! Before landing here I even considered a commercial package such as SwiftX for AVR and I found it, IMHO, inferior. Regarding the "forget" question. The simplest approach is to select each new deinition the largest available free space fragement to compile into. If the Forth programmer is well trained he/she factors his/her code into small pieces and reutilization of "forgetten" definitions would be high. Anyway, that's not a high priority issue for me now, it's part of my exploration of my new "ecosystem" :-) Regards, Enoch. > >> As I am not a Forth expert (yet), did any other flash based Forth >> introduce FORGET? > > I assume, most of them do not have word lists and hence do not have > the problems arising from them ;) There are a few members > of this list, that may tell better. > > Matthias > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
