On 22 Jan 1995, Johnathan Taylor wrote:
> 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.
That's how I'm working it at the moment, but using the frame int.
> 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.
Each task has its own stack anyway - I just do some copying before and
after the FPC call, in order to use the ROM.
> Could you use custom written rather than rom subroutines to push and pop
> numbers onto the FPC stack...
Already done it.
...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;)
That isn't a problem at the moment - besides, DPL optimises its FPC calls
in such a way that there might very well be things lying on the stack for
ages, waiting to be used. It would be a very un-flexible way of doing
things.
>
> 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?
Yeah, but not safely during FPC execution - Suppose two tasks want to use
some FP at the same time. If we were to try and switch during an FP call
(remember that the ROM is not really designed for this) lots of nasty
system vars etc. need to be stored, updated etc, and I really want to
avoid this kind of thing.
> Anyway I hope at least one of the ideas above gives you an easier way out of
> your dilema:-)
Thanks.
> Regards
> Johnathan.
Steve.
