[no subject]

I expect what will remain in the kernel will be very hardware specific,
and only of intrest for porting reason's. In this case on a Pentium because
of the low cost, not the correctness of design. This kernel corrects for
things being done "wrong" in the silicon (although a bit strongly stated).
It ignores the silicon that's not needed, and extends the missing important
constructs as efficiently as can be done to form a virtual machine.
I believe his idea is that actually the silicon plus or minus should contain
and be the kernel, almost everything else is prefered in high level forth.

RAM is inexpensive, wasting it is not good. But using the RAM less
efficiently for only data storage, is much less of a problem than wasting
memory with program code in that memory. Memory management can be
done sometimes best at edit time.

I'm also concerned with the behavior at the point of resource
exhaustion. Perhaps this is part of why colorforth has the circular
stack concept. From what I understand it avoids and minimizes the damages
from what was previously a collision between as an example the dictionary
and the data stack. This approach would be welcoming the same disadvatages
of the non circular stack based forth's allowing the dictionary due to data
length to say overwrite the stack. Realizing that when the resources are
exhausted things are going to get ugly, but damage control probably starts
by considering this behavior. 

As I often also need temporary space for valid reason's
I'm very intrested to get other input, and hope your mail spawns many replies.

I at this time I have no solution, but think that if it should be in the
kernel it probably is in the kernel. The solution hopefully lays elsewhere.

Hoping to have helped.

With kind regards,

Tim Neitz.


On Wed, 1 May 2002, Mark Slicker wrote:

> 
> 
> On Sun, 28 Apr 2002, Charles Shattuck wrote:
> 
> > I don't know about elegant, but a practical way might be to figure out
> > what blocks are free and just use them explicitly. If the spirit of
> > colorForth is extreme simplicity then a mark stack sounds like overkill
> > to me. If you need an extra stack to keep track of memory allocations
> > maybe you should rethink your original problem instead and find a
> > simpler solution.
> > 
> 
> I think what I'm doing is appropriate, however I'm open to sugestions. I'm
> writing a jpeg decoder, and I've found jpeg requires some tables to be
> generated, and additional space for one mcu (minimum coded unit). This
> data is only needed during the decoding process, after which it can be
> discarded. Also, I should note the ammount of temporary space may vary
> depending on the particular image.
> 
> I could certainly calculate the maximum ammount of space required
> designate this many blocks for my algorithm, however I think this runs
> counter to the design of colorForth. colorForth already has heap, which
> is the dictionary space. If you notice, when you load a program, all the
> tables and word defintions needed are compiled to the dictionary
> space. This sugests to me using dictionary space for temporary space as
> well. As an added bonus, you can use the comma operators aleady
> defined. These provide an elegant method for sequential writes to
> memory. Although I haven't written the colorForth code yet, I imagine
> these will simplify my algorithm greatly. The only problem remaining is to
> reset the dictionary pointer (free the memory). I think Chuck's method
> will work fine, although unfortunately, I think it requires adding a new
> word to the kernel (to set h), creating an incompatible colorForth.
> 
> Mark
> 
> ------------------------
> 
> To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
> unsubscribe ColorForth
> as the first and only line within the message body
> Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
> Main ColorForth site   -   http://www.colorforth.com
> 
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe ColorForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main ColorForth site   -   http://www.colorforth.com