Re: Is PRI PAR useful for hardware?

[A E Lawrence <adrian.lawrence@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Roger Peel wrote:
> 
> Adrian Lawrence asked :
> >
> > Is PRI PAR useful for hardware?
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > We usually think of PRI PAR as a mechanism for managing a limited software
> > resource - mainly time - on a uniprocessor.
> >
> > But resources are also limited in hardware. In reconfigurable technology,
> > the limited resource is usually space. With partially reconfigurable
> > hardware like the late lamented XC6000 series, the whole point is to
> > dynamically reload sections of a chip with the most urgent task: exactly
> > the function of PRI PAR?
> >
> > This is really thinking out load following comments at WoTUG-22, especially
> > by Barry, to the effect that perhaps PRI PAR is not needed.
> > But I don't understand the alternative proposal: was it based on the idea
> > that priority is attached to events rather than processes? I am not really
> > sure that CSPP does not already attach priority to events.
> 
> The issue does appear to revolve around reconfigurability.

Indeed. And Wayne Luk's group at IC have done a lot of work in this
area.
Using Ruby.

> Barry and I have (so far, at least) concentrated on producing static
> circuits that implement the whole of an occam program.  In this case,
> all of the processes genuinely run in parallel, and PRI PAR has little
> meaning since there is no timesharing of a single processor to
> prioritise. 


> PRI ALT, or a fair ALT, or whatever, is still required to
> deal with incoming communications, and possible starvation in the face
> of high traffic on some channels.  Prioritised channels (or events)
> appear sufficient when everything is truly running in parallel.

I think that we all agree that PRI ALT is absolutely necessary. And
since I think most implementations of ALT, particularly in hardware, are
really PRI ALT, having  a semantics means that we can prove stronger
properties about our circuits. 
 
> When resources run out and reconfiguration is used, a scheduler again
> would have to determine which processes (or fragments thereof) should
> be loaded and run.  This decision might require hints derived from the
> process priority.

With reconfigurable hardware our resource limitations are much more
severe than in a typical software system. Think of floating point stuff
which is still not practical: even dividers are marginal. Of course, we
all know that, but when practical reconfigurable architectures are
re-invented, the need to allocate resources becomes acute.

Anyway, what I was really trying to extract from you or Barry or Andre
(the main advocates?) was some clearer idea of what the alternative to
PRI PAR might be. I thought that it was more general than hardware? 
Wasn't the original concern with real time scheduling in software? With
some idea of dynamic priority: hence my recent note. But perhaps it is
still a vague notion not concrete enough to state clearly? 

My suspicion is that PRI PAR will do the job perhaps in conjunction with
a new primitive along the lines of the CSP interrupt operator. The point
is that we can abort [perhaps I mean suspend] an active process: then it
might be continued in a different branch of a PRI PAR. Since there are
no additional resources required, this ought work with static memory
allocation. And so be compatible with occam. And the CSP(P) semantics
will allow us to design the occam extension properly; and stay with a
well defined mathematical model.

Do we need anything like this? What was the problem that the "priority
on events" debate addressed? Anyone?

Adrian
--
Dr A E Lawrence (from home)