valencia@vger.UUCP (05/09/85)
I've just finished writing a multi-tasking FORTH for the Z-80. Like so many before, I held off on the disk drivers until the system was more or less debugged. Then I came across what ends up being an interesting question in FORTH philosophy: exactly how DOES one do the FORTH memory buffering scheme? If you go back to "original" FORTH, you end up depending on "block", and it gives you back a nice address: your block buffer. Problem is, when you go multi-tasking, you have to start wondering exactly how long it'll be before that buffer is re-used for some other process' buffer. If you use some sort of locking mechanism, you run into the the problem that your software is not compatible with the great majority of FORTH software. Defining BLOCK so that it saves into a user-specified buffer has the same problem, but also demands that some number of 1K blocks are set aside--on a 64K system, how many of those do you REALLY want around? So you poly-forth hackers, what sorts of solutions exist for this? Interested, Andy Valencia
keithd@cadovax.UUCP (Keith Doyle) (05/11/85)
[.........]
I would think the best solution would be to reserve seperate buffers for
each user if you have to maintain compatibility, as all the other solutions
I can think at the moment of have problems. A system that allows you to
dynamically configure the buffer space and assign different numbers of
buffers to each user or process might be useful.
I too, would like to hear any other proposed solution to the multiple
user buffer pool problem posed here.
Keith Doyle
# {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithdtoma@tekchips.UUCP (Tom Almy) (05/13/85)
In article <161@vger.UUCP> valencia@vger.UUCP writes: > > I've just finished writing a multi-tasking FORTH for the Z-80. >Like so many before, I held off on the disk drivers until the system >was more or less debugged. Then I came across what ends up being an >interesting question in FORTH philosophy: exactly how DOES one do the >FORTH memory buffering scheme? [...] > Andy Valencia I have a Z80 multiuser Forth, based on NVSS F83 Forth. This and every other multitasking Forth I have seen (including polyFORTH) will only change tasks when a word PAUSE is executed. All I/O and disk accessing words contain PAUSE, especially in any ready-wait loops. Essentually this means that the address returned by the BLOCK word is valid until the next I/O word. It is the task's responsibility to move any data to a private storage area if it needs to do I/O without possibly loosing the data. The word ">TYPE" is used in the words LIST INDEX, and within the editor to make sure an entire line of a screen gets printed before the buffer gets swapped out. It is defined: : >TYPE SWAP OVER PAD SWAP CMOVE PAD SWAP TYPE ; (it moves the data to PAD before typing). Two block buffers are adequate. If operating under a DOS, such that the block buffers are associated with files, there are additional complications is different tasks can refer to different files. Tom Almy
collinge@uvicctr.UUCP (Doug Collinge) (05/15/85)
How about this: You have N buffers. You have tasks A and B, among others. When you switch from task A to task B you save the buffer mapping table along with the other stuff. Then when you switch back to A you check to make sure that the buffers have the same blocks in them. If they don't you write out the changed ones and read back in the ones that A is expecting. This is horrible if both A and B are making heavy use of the buffers but if A is using them heavily and B not very much then it isn't too bad. And it is compatible. Anyone see problems? -- Doug Collinge School of Music, University of Victoria, PO Box 1700, Victoria, B.C., Canada, V8W 2Y2 decvax!nrl-css!uvicctr!collinge decvax!uw-beaver!uvicctr!collinge ubc-vision!uvicctr!collinge