🚀 go-pugleaf

Mark Morgan Lloyd (mark_tbu@cix.compulink.co.uk) wrote:
>> 
>>        I am using TopSpeed M2 compiler v3.10. I am trying to program
>> Synchronous Modem Card in PC (on DOS).  I have an Interrupt 
>> service routine for the SCC on the card. I have two coroutines: one for
>> implementing BISYNC protocol and one for User Interface. Reading the 
>> TopSpeed manuals, I figure that there are two ways to write ISR's in M2 
>> :

>The first thing that has to be asked is whether you are using coroutines 
>elsewhere in the program (apparently yes), since the priority (i.e. 
>16-bit PIC mask) is held (IIRC) on a per-coroutine basis. If this is 
>happening then you will need to artificially pass the priority between 
>coroutines (which is cheating) or adjust the PIC mask by direct hardware 
>access (which is worse than cheating).

Right.  This is one reason why I don't use TRANSFER/IOTRANSFER
(or, for that matter, module priorities) in my M2 programming.
If you look at the PMOS sources you'll see that the kernel supports
multi-threading by a mechanism that replaces the TRANSFER/IOTRANSFER
mechanism.  I've tried an alternative approach using TRANSFER and
IOTRANSFER; but it's an ugly solution, it's not entirely safe, and
I've also found that it's not very portable.

In the case of TopSpeed, the fact that the priority is held on
a per-coroutine basis, and that the priority is by definition
(with this compiler) equal to the PIC mask, is the largest part
of the problem.  The semantics are, in my opinion, exactly the
wrong way around.  The function of the PIC mask is to control
which interrupts are being locked out.  Typically you want to
lock out interrupts from a certain device at certain times because
of critical section problems within the device driver code.
If you lock them out then you want them to stay locked out
regardless of any thread switching.  Consequently, the PIC mask should
be a global resource rather than a per-thread resource.
The only ways around this are
 (a) avoid using TRANSFER and IOTRANSFER and module priorities, or
 (b) use some tricky work-arounds of the kind Mark mentioned,
     which boil down to attempts to defeat what the compiler has
     done to you; or
 (c) do critical section protection by locking out ALL interrupts
     - but for various reasons this is not always a satisfactory
     solution.

The above-mentioned problem is specific to TopSpeed, because
of the way TopSpeed implements priorities.  But TopSpeed does it
that way because the 80x86 interrupt masking mechanism is not
the same as the PDP-11 mechanism, and the Modula-2 priority
mechanism was really designed for machines like the PDP-11.
It's an especially non-portable feature.

Of the various compilers I've seen, most have some sort of
problem in their support of TRANSFER/IOTRANSFER and module
priorities.  Some implementers get around the problem by not
supporting one or more of these features.  Others try to support
them, and get it wrong.

Frankly, I'd be a lot happier if priorities were deleted from
the M2 standard; it would solve a lot of problems, and give
implementers a better chance of delivering an IOTRANSFER that
actually worked.  But, the way things stand, my current solution
is to avoid using IOTRANSFER and module priorities.

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           file://ee.newcastle.edu.au/pub/www/Moylan.html