From ST2975@SIUCVMB.SIU.EDU Thu Nov 26 15:58:13 1992 Received: from calvin.sfasu.edu by umaxc.weeg.uiowa.edu (5.61.jnf/920629) on Thu, 26 Nov 92 15:58:11 -0600 id AA20722 with SMTP Received: from SIUCVMB.SIU.EDU by calvin.sfasu.EDU with SMTP (5.59/25-eef) id AA26223; Thu, 26 Nov 92 15:51:05 CST Return-Path: Message-Id: <9211262151.AA26223@calvin.sfasu.EDU> Received: from SIUCVMB.SIU.EDU by SIUCVMB.SIU.EDU (IBM VM SMTP V2R1) with BSMTP id 5773; Thu, 26 Nov 92 15:49:38 CST Date: Thu, 26 Nov 92 15:30:09 CST From: ST2975@SIUCVMB.SIU.EDU To: hyperc-l@calvin.sfasu.edu Subject: Re:pseudo-code interpreter Status: R One of my favorite books is _Operating Systems Design: the XINU Approach_ which was recommended in the hyperc docs as something to look at. It describes a system built around irqs, the vbl for instance, and processes as opposed to linear programs and the feasibility of running processes in the background, like printing a file, copying files etc. It uses a mixture of assembly and C code, assembly being low level modules and C code being upper level modules. At the cpu level, if an irq should occur and irqs are allowed, the cpu finishes its currrent instruction before initiating an interrupt sequence. The irq handler has the responsibility of saving any registers and restoring any registers on entry and completion of an irq task. At the cp-interpreter level, an irq can interrupt any pseudo-instruction anywhere in its execution. So currently, any irq handler must be written in assembly, leaving the C engine zero page registers alone. If an irq handler were C code for example, it's obvious that the C engine registers would be trashed on return from the interrupt. I've been convinced by Todd Whitesel that I should leave the cp-interpreter as it is, and write an assembly module that can be used by any programmer who would like to write irq stuff in C that would save and restore the C engine zero page registers. I believe that it would be safe to store the registers on the C stack and restore them from there. Andy W.