One comment received:
BTW, I still think there's a need for prioritisation in a
programming language : 1) we don't necessarily always have
processors to spare (though David would love to sell us them), and
2) I'm pretty sure I could dream up examples where it would be
simpler to use one processor and prioritisation than add extra
communication, especially from the point of view of the
programmer. But it's not as urgent as figuring out how to program
hundreds of processors and their interconnect.
I didn't intend to say that priority should not be used in
processors - but that I thought it had no place in the user
interface, being a secondary (implementation) issue where timing
constraints are primary. [Like choosing to put a loop variable in a
register to get a faster loop - not something I want to control
directly.]
For some targets, priority may be a good implementation of a user
request for some timing constraints - but I see the choice being the
job of the compiler, not the programmer. I don't want to specify
either priority or extra communication, just that I want the answer
within a given time - and let the compiler do the work.
A lot of what I do is hard real-time (creating and responding to
electrical signals) and the easy solution is real parallelism using
a new piece of hardware for each requirement (all in the same in
FPGA, not lots of chips). I'm with David May here - just throw lots
of dirt cheap independent, easy to create, easy to prove
algorithms(*) at the problem.
(*) The algorithms can be in traditional CPUs or in logic circuits
with many reasons for choosing one or the other - and XMOS offers an
attractive hybrid alternative.
Barry.
Dr
Barry M Cook
CTO
4Links
Limited, Suite EU2,
Bletchley Park, Sherwood Drive, Milton Keynes, MK3 6EB
Tel:
+44 1908 642001 Fax: +44 1908 363463 E-mail: Barry@xxxxxxxxxxxx
Web: www.4links.co.uk
4Links
Limited is a company registered in England and Wales at
the address
above I Company number 3938960 I VAT GB 609 5299 14
This
e-mail and any attachments are for the intended
addressee(s) only and
may contain confidential and/or privileged material. If
you are not a
named addressee, do not use, retain or disclose such
information.
This e-mail is not guaranteed to be free from viruses
and does not
bind 4Links Limited in any contract or obligation.
Consider
the environment - do you really need to print this
e-mail?
On 2012-10-05 14:19, Barry Cook (4Links) wrote:
Guilty! I said that some good few years ago - although as is the
way with such things I expect others have said it as well.
I'll make a similar remark with regard to PRI PAR ...
It seems to me that we're discussing the wrong thing - PRI PAR is
an instruction as to how something is to be implemented and is not
the real issue.
I suggest that we should be asking how we capture requirement
constraints of the form: "when 'this' happens, do 'that' within
some time".
Given these constraints we should be able to build a tool to find
a solution (or check that our proposed solution will work) ... if
we want a hundred counters to respond in 1ns we'll probably need
logic gates, a bit slower and lots of processors will do it,
slower still and a single processor is OK. An implementation could
allow sharing of hardware and if some things need quicker
attention than others we may use priority/pre-emption/etc. to meet
the constraints in a cost/power efficient way.
Barry.
Dr Barry M Cook
CTO
4Links
Limited, Suite EU2, Bletchley Park,
Sherwood Drive, Milton Keynes, MK3 6EB
Tel:
+44 1908 642001 Fax: +44 1908 363463 E-mail: Barry@xxxxxxxxxxxx
Web: www.4links.co.uk
4Links Limited is a
company registered in England and Wales at the address
above I Company number 3938960 I VAT GB 609 5299 14
This e-mail and any
attachments are for the intended addressee(s) only and
may contain confidential and/or privileged material.
If you are not a named addressee, do not use, retain
or disclose such information. This e-mail is not
guaranteed to be free from viruses and does not bind
4Links Limited in any contract or obligation.
Consider the environment - do you really
need to print this e-mail?
On 2012-10-04 17:51, Ruth Ivimey-Cook wrote:
Eric Verhulst (OLS) wrote:
In
OpenComRTOS the equivalent of PRI PAR and PRI ALT come
together. In my view, they can't be decoupled.
1.
Tasks get a priority (at compile time). System wide
attribute, so independently on which node they have been
mapped. On each node, scheduling is in order of priority
and preemptive.
This made me think: a long time ago, far far away... .no well
anyway a long time ago someone suggested that the real thing
that should have a priority attached to it was the communication
itself: a message. Not the channel, or the task. The issue in
ming, IIRC, was priority inversion. It has always struck me that
this was a good model to go with, though I don't recall ever
seeing it done or even investigated.
Regards
Ruth
--
Software Manager & Engineer
Tel: 01223 414180
Blog: http://www.ivimey.org/blog
LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
|