In news:
[email protected] timestamped Tue, 06 Mar 2007 16:20:27
+0000, Martin Thompson <
[email protected]> posted:
"Colin Paul Gloster <
[email protected]> writes:
> I am unhappy that electronic engineers are very eager to try
> to transfer things which are unsuitable for software to hardware for
> which they are also unsuitable, e.g. C++ and UML.
That sounds like one for the .sig file!"
Thank you, I aim to please!
Prof. Giovanni De Micheli said on April 2nd, 2007 while lecturing: "I
invented HardwareC a few years ago" and after he presented two slides
after that clause he said: "Java is a great language, I like it. It's
cleaner than C/C++, but that's life." He said that C has an advantage
over VHDL because code might initially be targeted to a processor but
be migrated to hardware elsewhere in the system if the attempt on the
processor does not perform well enough.
In contrast to what is quoted above which he used his voice to say, he
showed in writing more than one slide of his promoting the SystemC(R)
approach as being good. E.g. "Processes run concurrently". I asked
whether he had tried to convey that SystemC(R) code genuinely,
literally runs concurrently. He answered that he did mean that
literally, but he admitted that in practice SystemC(R) implementations
do not run concurrently. He clarified that he was convinced that the
SystemC(R) standard was written in terms of concurrency. During a
lunch break I challenged this again (this time by email: see below): I
did not receive a response from him yet but an organizer of the
lecture sent the response below.
Regards,
Colin Paul Gloster
On Mon, 2 Apr 2007, someone wrote with Subject field: "Re:
SystemC(R) concurrency, or lack thereof":
"Dear Colin Paul,
please try to address questions to Prof. De Micheli personally just
after the
lecture or during the break. This will avoid any form of
misunderstanding
without bothering Prof. De Micheli via email. Could you imagine if all
the
students would start sending questions to Prof. De Micheli via email
?
The presence of Prof. De Micheli is a great opportunity for all the
students
attending the course so please try to avoid asking too many questions
during the lecture in order for Professor De Micheli to have the
possibility to
address all the topics he originally planned for the course.
Thanks a lot for your understanding.
Best Regards, [..]
----- Original Message ----- From: "Colin Paul Gloster"
<
[email protected]>
To: <giovanni.demicheli[..]>
Cc: [.. some of the students who had been exposed to propaganda by the
lecturer, and also a carbon copy to the organizer]
Sent: Monday, April 02, 2007 2:05 PM
Subject: SystemC(R) concurrency, or lack thereof
> Dear Professor Giovanni De Micheli,
>
> You said on a number of occassions during one of the lectures today
that
> SystemC(R) multiprogramming is concurrent. I asked you whether you
meant that
> literally, to which you replied that you did literally mean that but
that
> implementations might use interleaved serial code instead of
parallel code but
> that you believed that the SystemC(R) definition is concurrent.
>
> I completely reject your claim that the SystemC(R) library is
defined to be
> concurrent. Please explain to me how I have misinterpreted the
definition of
> the scheduling policy of the SystemC(R) standard's as described in
4.2.1 The
> scheduling algorithm of the standard:
> "The semantics of the scheduling algorithm are defined in the
following
> subclauses.
> [..]
> An implementation may substitute an alternative scheme, provided the
> scheduling
> semantics given here are retained.
> [..]
> 4.2.1.2 Evaluation phase
> From the set of runnable processes, select a process instance and
trigger or
> resume
> its execution. Run the process instance immediately and without
interruption
> up to
> the point where it either returns or calls the function wait.
> Since process instances execute without interruption, only a single
process
> instance
> can be running at any one time, and no other process instance can
execute
> until the
> currently executing process instance has yielded control to the
kernel. A
> process shall
> not pre-empt or interrupt the execution of another process. This is
known as
> co-routine
> semantics or co-operative multitasking.
> [..]
> A process may call the member function request update of a primitive
channel,
> which will cause the member function update of that same primitive
channel to
> be
> called back during the very next update phase.
> Repeat this step until the set of runnable processes is empty, then
go on to
> the
> update phase.
> NOTE 1-The scheduler is not pre-emptive. An application can assume
that a
> method process will execute in its entirety without interruption,
and a thread
> or clocked
> thread process will execute the code between two consecutive calls
to function
> wait
> without interruption.
> [..]
> NOTE 3-An implementation running on a machine that provides hardware
support
> for concurrent processes may permit two or more processes to run
concurrently,
> provided that the behavior appears identical to the co-routine
semantics
> defined in
> this subclause. In other words, the implementation would be obliged
to analyze
> any
> dependencies between processes and constrain their execution to
match the
> co-routine
> semantics."
>
> Thanks,
> Colin Paul Gloster
>
> P.S. Other parts of the lecture were interesting."