On 4/12/2011 12:32 PM, Matthias Trute wrote: > Am 10.04.2011 22:58, schrieb D Nyberg: >> Long ago, I worked with forth extensively, but haven't for a while, so >> I have forgotten much. Also, that was work for an employer, so I don't >> have copies of what I did back then. So I'll have to reinvent things I >> remember doing. >> >> One of the things I did back then was I made a word called run_command" >> Which compiled a literal string like ." does, but at run time it stuffed >> the string into the command buffer and triggered the outer interpreter. > Amforth does not (yet) provide the word EVALUATE that > is needed to implement your idea verbatim, but > its relativly easy to extend amforth to do what you want by > duplicating the turnkey code and its use in QUIT. I'll have to re-learn these parts of forth, but that's on my list of things to do. >> That let us issue FORGET commands for words that didn't exist yet at >> compile time, > Funny. > >> etc. I've been thinking I'd like to do that again, but >> this time maybe set up an amforth so that on cold boot it copies a >> string (if it exists) from eeprom into the command buffer, then begins >> execution. > What is a cold boot? esp what makes it different from a warm boot? The > atmega provide the reason of the reset in the status register and > amforth copies this information into a register (R10). Your turnkey > code may use that information to distinguish between e.g. a power on > reset or a watchdog reset (details are in the datasheets for the > MCUSR register). Well I'm thinking in traditional mode; cold boot = power up or reset button, warm boot = software triggered, for instance by the ISR character check. >> On warm boot, doesn't copy the string. It could be made even >> a little more fancy, with maybe a few seconds count down before it runs >> the buffer, and read ISR checks any received character for ^C and warm >> boots if it sees one. I think that would make it very easy to develop >> code in the field, set up automatic run if I think it's ready, break in >> if it's not right. (I'd still want to incorporate Karl's eeprom loader, >> or redevelop the same thing, though...) > Do I understand it correctly: whenever a CTRL-C character is received, > the currently executed word should be cancelled and the outer > interpreter is activated? Just like a reset button but with keeping > the stacks intact? Kinda of software interrupts. I was actually thinking even reinitialize the stacks on warm boot; restart everything, except do not copy the string into the command buffer, since corrupted R stack or overflowed D stack could make it crash again. I suppose there might be some debug value in preserving the stacks, but I would have to think hard about side effects of trying to preserve them. Maybe spit out a stack dump to the console, then restart them from scratch? Again, I'd have to think about that.
But my first thought was cold boot = full init plus command string copy, warm boot = full init no command string copy. That would let me interrupt a hung program, or abort the command string before it started, if things were not as perfect as I had hoped. One tool, two uses. ------------------------------------------------------------------------------ Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo _______________________________________________ Amforth-devel mailing list Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
