Re: Conflicting Priorities in occam

[Adrian Lawrence <adrian.lawrence@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

 Continuing this plot to fill Peter's mail box before he gets back tomorrow...
 Reviewing our barrage of messages, I noticed:-
 
 B.M. Cook writes:
> 
> >If I understand what Barry is saying here, there is some distinction between
> > PRI ALT and PRI PAR which is not modelled in CSPP.
 
> I'm just saying that if 2 or more channels are ready to send data when an
> ALT is started, then PRI ALT chooses one of the channels on the basis of its
> own local ordering - irrespective of any priority that may, or may not,
> have been given to the outputting processes.  This, effectively, assigns
> priorities to the channels.
 
 But I claim that it ought not to respect only its local ordering, at least
 not in hard semantics. After all, the inspection of the channels is exactly
 examining its environment -- enquiring what the processes at the other ends
 of those channels require. That is needed for hard priority.
 But may be too expensive to implement in software.
 
 I think, but haven't checked formally, that if *both* PRI PAR and PRI ALT
 just react according to their own local priorities, then in a sequential
 implementation that gives the non-determinism of soft priority.
 That only works for a sequential implementation: the non-determinism 
 arises from the ignorance of which arbitrates first. A truely parallel
 implementation of that algorithm would surely give hard priority.
 Which is interesting. To obtain a hardware implementation of soft priority
 would probably mean building a bias into the central arbitrator, yielding
 a deterministic circuit.
 
 Notice that again I claim that there is no distinction between PRI PAR
 and PRI ALT here.
 
 Anyway, I think that we have aired the issues and thrown up a whole new
 March of hares. But my original simple question remains: how should we
 define occam? I still claim that the existing Reference Manual is ambiguous
 and someone ought to do something about it. *If* we are now the Guardians
 of occam, and we now have the formal tools to do the job, does it fall to
 us? If not us, then whom?
 
 Adrian
-- 
A E Lawrence, MA., DPhil.  	adrian.lawrence@xxxxxxxxxxxxxx
MicroProcessor Unit, 13, Banbury Road, Oxford. OX2 6NN. UK.                
Voice: (+44)-1865-273274,  Fax: (+44)-1865-273275