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"
To: 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."