C/C++ for hardware (from "Re: Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded Ada?")")

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

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