[ColorForth] temporary memory allocation / kernel

[Mark Slicker <maslicke@xxxxxxxxxxx>]

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