[ColorForth] temporary memory allocation / kernel

[Tim Neitz <tim@xxxxx>]

Mark, Tim here.

Thanks for the reply,
Glad I put those disclaimers in there ;-)

As far as the circular stacks go, perhaps I was confused
with one of Mr. Moore's machine forth chips.
I read about it on Jeff Fox's site.

As far as the temporary storage idea, I understood the points
you've made. I agree that such a need often arises.

But I guess I still don't see why that lead to the conclusion
that a word would have to be added to the kernel.

As far as the confusion of for an example the ps/2 mouse and keyboard,
I see that as partly a documentation issue more than weather it's in
kernel or not.

Very nice to hear about the idct part, and wish you success!
Looking forward to seeing it work.

With kind regards,

Tim Neitz

On Thu, 2 May 2002, Mark Slicker wrote:

> 
> 
> On Thu, 2 May 2002, Tim Neitz wrote:
> 
> > Mark, Tim here.
> > 
> > So nice to see others busy with colorforth, and
> > a jpeg decoder sounds really cool.
> >
> 
> It should be interesting. I'm very happy about the idct part, I found
> an 8 point idct approximation that requires only shifts and adds. The
> acuracy is very competitive with floating point, and the
> computational structure is well suited for stack evaluation.
>  
> > I'm an old time forther that has just started using colorforth.
> > 
> > >From what I've read and understand, I have formed the following
> > opinion. Please don't forget that at this point I'm more interested
> > in colorforth than I am experianced in colorforth. I'm hoping to contribute
> > by perhaps stimulating the discussion.
> > 
> > I hope the following points are accurate and relevant.
> > 
> > Mr. Moore is busy trying to get almost everything out of the kernel
> > for almost all uses. This is why the kernel is now as tiny as it is.
> > >From what I understand, there are a number of words in the kernel that
> > Mr. Moore would rather see taken out of the kernel. I have read that
> > as an example the editor and keyboard are also on that list.
> > This has a lot of advantages as far as porting are concerned.
> > As well as other advantages just as significant, but perhaps less
> > obvious.
> >
> 
> I have found many of these would be helpful to have as source. In
> particular, the keyboard, and graphics. If you didn't know, the
> ps/2 keyboard and ps/2 mouse share the same port. I wrote some mouse code
> to a curious effect, moving the mouse would type characters on screen! The
> graphics source is nice if you want to experiment with acceleration. I
> tried programming my card by modifying the kernel, but gave up when I
> encountered problems transfering characters to screen. I think the
> interactive development of forth would help greatly.
> 
> > 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.
> > 
> 
> I believe what should be in the kernel should be dertermined by practice,
> but basically it is the static, unchanging parts of a system. The
> advantage of having something in the kernel is that it can generaly be
> more compact and efficient when implemented in machine code.
> 
> > 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 think I know what you mean, but there are still cases where the ammount
> of memory needed will not be known until runtime. This is unavoidable.
> 
> > 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. 
> > 
> 
> I believe the dictionary space comes after the stacks, so this is not a
> problem. Also the stacks in the pentium colorForth are not circular, at
> least I see no mechanism for wraping the stack.
> 
> > 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.
> > 
> 
> I don't think this is the case. I've seen two versions of Chuck's
> colorForth. Generally, every bit code that is provided is used somewhere.
> 
> 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