On (20 Jan 95) [EMAIL PROTECTED] wrote... > Date: Fri, 20 Jan 1995 19:09:16 +0000 (GMT) > From: Steve Taylor <[EMAIL PROTECTED]>
> I've got this problem. (No, not that problem) That's alright then;-) > I might just have been working on this new WIMP-style OS when I hit a bit > of a problem with the FPC. In this hypothetical system, the individual > applications are time-sliced using the frame interrupt, which also > triggers key scanning etc. > These applications each have their own FP stack (like the ROM uses), and > can execute FP instructions using RST 28 commands like with the ROM. Now, > I implemented this by copying each ap's FPC stack onto the ROM's, > executing a copy of the instructions, and copying the resulting stack > contents back. My problem arose when a DPL application wanted to run a > background routine. > DPL-compiled aps use the FPC nearly all the time, meaning that the ROM is > nearly always paged in, and the mode 1 interrupts never reach Driver. So > no other programs get processor time, the pointer never seems to move and > so on. I thought about vectoring the interrupts back into Driver, but the > time-slice problem remains: I couldn't safely switch to another > application for fear of what was happening to the original FPC stack. > The only feasible solution was to write my own FPC. Help! Hi Steve! Weeeell I assume that it's common pratice in a time-sharing enviroment that one shares the apps cpu time NOT the OS support functions... The FPC from the RST 28 to the End-of op code are ONE system function albeit a potentially very long one! So it is CORRECT to NOT task-switch whilst exectuting an FPC sequence A problem *could* occour if the FPC USR function was used but that's a another problem... In my unix-like system, which only has the single application entry point, I'll use the LINE interupt to increment tasks-ticks and it simply switches OFF the line interupt on entry to the OS and restores it again on exit back to the task. One 'sure-fire' way around you're problem (appart from re-writing the FPC to include multi-tasker hooks) is to swap the entire FPC stack and position with each task so each task gets it's own stack and position on context-switch. Could you use custom written rather than rom subroutines to push and pop numbers onto the FPC stack and incorprate code to disable a context switch and a seperate function to re-enable the context-switching After the entire FP operation was complete... Or you could store initial FP stack parameters on initial switching in a task and defer the next context switch until the FP stack is returned to its entry size, obviously this means that a context switch could be delayed a long time if the FPC work isn't neat and tidy leaving the stack properly balanced but it should prevent one task from using another tasks data(I think;) Oh can't you re-direct the frame interupt to driver whilst the roms paged in using FRAMIV at 5AE2H to allow you to maintain control in driver? Anyway I hope at least one of the ideas above gives you an easier way out of your dilema:-) Regards Johnathan. ... Just when you think it's hopelessly broken, it works. -- |Fidonet: Johnathan Taylor 2:2501/307.9 |Internet: [EMAIL PROTECTED] | | Standard disclaimer: The views of this user are strictly his own.
