Multiprocess I/O

[Lew Pitcher]

On Tuesday 11 March 2014 17:17, in comp.lang.c, "88888 Dihedral"

OK, lets be practical to consider
a memory loacation which can be
modified by more than one writer
indepently and the value of the
memory location stored will be used
by several readers from time to time
to perform updates of other computations in a system.


One will conclude that the ASYN and SYN rules for I/O RW operations must
be established first before designing a true working digital system.

And one would be incorrect in those conclusions. Unless, of course, you
restrict your definition of a "true working digital system" to /only/ be
those systems that require "ASYN and SYN rules for I/O RW operations" in
order to work.

Look at the actual history of computing devices and digital systems, and see
what actually happened.

In the earliest digital systems, there was never "more than one writer", and
even paired writer/reader systems (like, in later systems, serial devices),
write/read synchronization was either not an issue (yes, risking lost data)
or was handled with an explicit synchronization mechanism.

Programs were architected, written, and run standalone, on the bare metal.
There was no "multi-programming", so there was never multiple independent
execution threads competing for the same data space.

Those multiprogramming techniques, and the co-ordinating mechanisms that
enabled them, followed long afterwards.

 

[James Kuyper]

OK, lets be practical to consider
a memory loacation which can be
modified by more than one writer
indepently and the value of the
memory location stored will be used
by several readers from time to time
to perform updates of other computations in a system.


One will conclude that the ASYN and SYN rules for I/O RW operations must
be established first before designing a true working digital system.

Perhaps, by taking a sufficiently restricted view of what constitutes a
"true working digital system". Your conclusion implies that any system
where there can never be more than one writer in existence at a time,
doesn't qualify - but single process systems can have fully conforming
implementations of C running on them. Personally, I find it rather odd
that you would exclude such systems from being "true working digital
systems" - they are certainly working, and can be digital, and are
systems, so I suppose it's the "true" part that they don't qualify for.

I'm curious. I've been arguing that the C standard DOES not address
multi-processing systems. You've been arguing that it MUST address
multi-processing. Are you willing at least, to acknowledge that even
though, in your opinion, it should deal with multi-processing, in
reality it does not? If you're not willing to acknowledge that, please
cite the sections of the standard that do deal with multi-processing.

 

[88888 Dihedral]

Perhaps, by taking a sufficiently restricted view of what constitutes a

"true working digital system". Your conclusion implies that any system

where there can never be more than one writer in existence at a time,

doesn't qualify - but single process systems can have fully conforming

implementations of C running on them. Personally, I find it rather odd

that you would exclude such systems from being "true working digital

systems" - they are certainly working, and can be digital, and are

systems, so I suppose it's the "true" part that they don't qualify for.



I'm curious. I've been arguing that the C standard DOES not address

multi-processing systems. You've been arguing that it MUST address

multi-processing. Are you willing at least, to acknowledge that even

though, in your opinion, it should deal with multi-processing, in

reality it does not? If you're not willing to acknowledge that, please

cite the sections of the standard that do deal with multi-processing.

Don't you get the verilog part derived
from C ?

 

[James Kuyper]

....
Don't you get the verilog part derived
from C ?

No, the C standard doesn't cross-reference Verilog (aka IEEE 1364). Why
did you think that it does? Did you even bother to look? Please don't
bother to answer until you're either willing to concede my point, or
you've actually looked at the C standard and will identify in your
response a specific clause that you think actually deals with the
question of how multiple processes should interact with each other.

 

[88888 Dihedral]

No, the C standard doesn't cross-reference Verilog (aka IEEE 1364). Why

Did you check the developemnt of
register based languages?

There were system C and verilog
HDLs and the event-driven commercial software simulators in the 199X for the both.

 

[James Kuyper]

Did you check the developemnt of
register based languages?

Is there any particular reason why I should have? Every computer
language I've ever used has been implemented on machines with registers,
so I guess in that sense they all can be register-based. However,
implementation of C doesn't require registers; as far as I know, that's
equally true of all of the other high-level languages I've ever used -
only the lowest-level languages actually require registers. If you think
that the "register" keyword in C implies otherwise, please re-read the
description of the meaning of that keyword before attempting such an
argument.

Even the single-process systems I've used had registers, so what is the
relevance of registers to the question of whether or not the C standard
deals with multi-process issues?

There were system C and verilog
HDLs and the event-driven commercial software simulators in the 199X for the both.

Does that in some way provide evidence that the C standard does address
multi-process issues? Those might be multi-process systems (though I
don't see how that necessarily follows from what you've told me about
them) - but that would only prove that C can be implemented on such
systems, which is perfectly obvious. Anyone who develops an
implementation of C on such a system must deal with those issues in some
fashion - but that's no evidence that the C standard itself addresses
those issues.

I'm taking your failure to identify any clause in the C standard that
addresses such issues as an implicit admission that you don't know of
any. This is consistent with my claim that there are, in fact, no such
clauses. You can, if you wish, continue believing that there must be
such clauses, even though you don't know which ones they are. There's
certainly nothing I can do to stop you from believing such nonsense. But
there doesn't seem to be anything further to discuss with you about that
nonsense.

 

[88888 Dihedral]

Is there any particular reason why I should have? Every computer

language I've ever used has been implemented on machines with registers,

so I guess in that sense they all can be register-based. However,

implementation of C doesn't require registers; as far as I know, that's

equally true of all of the other high-level languages I've ever used -

only the lowest-level languages actually require registers. If you think

that the "register" keyword in C implies otherwise, please re-read the

description of the meaning of that keyword before attempting such an

argument.



Even the single-process systems I've used had registers, so what is the

relevance of registers to the question of whether or not the C standard

deals with multi-process issues?







Does that in some way provide evidence that the C standard does address

multi-process issues? Those might be multi-process systems (though I

don't see how that necessarily follows from what you've told me about

them) - but that would only prove that C can be implemented on such

systems, which is perfectly obvious. Anyone who develops an

implementation of C on such a system must deal with those issues in some

fashion - but that's no evidence that the C standard itself addresses

those issues.



I'm taking your failure to identify any clause in the C standard that

addresses such issues as an implicit admission that you don't know of

any. This is consistent with my claim that there are, in fact, no such

clauses. You can, if you wish, continue believing that there must be

such clauses, even though you don't know which ones they are. There's

certainly nothing I can do to stop you from believing such nonsense. But

there doesn't seem to be anything further to discuss with you about that

nonsense.

Kind of boring to deal with programmers
who can't use C to simulate non-trivial co-routine tasks in the desired budgets of HW and SW.

 

[James Kuyper]

On 03/12/2014 05:07 PM, 88888 Dihedral wrote:
....

Kind of boring to deal with programmers
who can't use C to simulate non-trivial co-routine tasks in the desired budgets of HW and SW.

If you think that describes me, I'm not going to bother proving you
wrong. But if talking with me bores you, that's only fair. Your every
response to any of my messages has been a non-sequitur, which frustrates
me at least as strongly as I bore you.

 

[Keith Thompson]

Kind of boring to deal with programmers who can't use C to simulate
non-trivial co-routine tasks in the desired budgets of HW and SW.

Rather than posting messages consisting of single vague sentences or
rhetorical questions, try writing something coherent that explains just
what you're talking about. Or don't.

 

[Andreas Perstinger]

[trying to communicate with 88888 Dihedral]

If you think that describes me, I'm not going to bother proving you
wrong. But if talking with me bores you, that's only fair. Your
every response to any of my messages has been a non-sequitur, which
frustrates me at least as strongly as I bore you.

In another newsgroup (comp.lang.python) the regulars came to the
conclusion that "88888 Dihedral" is some kind of bot that posts
incoherent messages and thus simply ignore him/her/it(?).

Bye, Andreas

 

[James Kuyper]

On 03/12/2014 05:52 PM, Andreas Perstinger wrote:
....

In another newsgroup (comp.lang.python) the regulars came to the
conclusion that "88888 Dihedral" is some kind of bot that posts
incoherent messages and thus simply ignore him/her/it(?).

That seems a plausible explanation; I'll follow that advice.

 

[88888 Dihedral]

On 03/12/2014 05:07 PM, 88888 Dihedral wrote:

...




If you think that describes me, I'm not going to bother proving you

wrong. But if talking with me bores you, that's only fair. Your every

response to any of my messages has been a non-sequitur, which frustrates

me at least as strongly as I bore you.

Judding from your replies above,
I might figure out how you could handle
the problems of solving the multi-process I/O problems by using the language C.

I am sure that's not solved by
the C language standards
explicitly.

 

[David Brown]

Is there any particular reason why I should have? Every computer
language I've ever used has been implemented on machines with registers,
so I guess in that sense they all can be register-based. However,
implementation of C doesn't require registers; as far as I know, that's
equally true of all of the other high-level languages I've ever used -
only the lowest-level languages actually require registers. If you think
that the "register" keyword in C implies otherwise, please re-read the
description of the meaning of that keyword before attempting such an
argument.

Even the single-process systems I've used had registers, so what is the
relevance of registers to the question of whether or not the C standard
deals with multi-process issues?


Does that in some way provide evidence that the C standard does address
multi-process issues? Those might be multi-process systems (though I
don't see how that necessarily follows from what you've told me about
them) - but that would only prove that C can be implemented on such
systems, which is perfectly obvious. Anyone who develops an
implementation of C on such a system must deal with those issues in some
fashion - but that's no evidence that the C standard itself addresses
those issues.

I'm taking your failure to identify any clause in the C standard that
addresses such issues as an implicit admission that you don't know of
any. This is consistent with my claim that there are, in fact, no such
clauses. You can, if you wish, continue believing that there must be
such clauses, even though you don't know which ones they are. There's
certainly nothing I can do to stop you from believing such nonsense. But
there doesn't seem to be anything further to discuss with you about that
nonsense.

88888's posts are mostly incomprehensible, with all sorts of ideas
jumbled up. But I'm guessing you don't know much about hardware
description languages, so allow me to give you a couple of points that
might help you understand the background for some of 88888's comments.

Hardware description languages - HDL's - are used for the design and
simulation of integrated circuits, ASICs and FPGAs. They typically
cover both synthesisable code (i.e., stuff that can be made into chips
or put on an FPGA) and purely simulation code (stuff to check that the
synthesisable part is correct in simulations). A key part of the
synthesisable part is in a style called "register transfer level" - the
digital logic consists mainly of a sea of registers which are connected
to each other by combinational logic and common clocks. The code that
describes this logic is RTL.

The two most commonly used HDL's are Verilog and VHDL. Of these,
Verilog is often considered to be "a bit like C" and VHDL is "a bit like
Ada". This is because Verilog uses brackets, and emphasises simpler
types and shorter code, while VHDL emphasises greater use of types,
explicit conversions, and has a more verbose syntax. So it is Verilog
that is vaguely inspired by C, not the other way round.

Hope that helps,

David

 

[Kaz Kylheku]

88888's posts are mostly incomprehensible, with all sorts of ideas
jumbled up. But I'm guessing you don't know much about hardware
description languages, so allow me to give you a couple of points that
might help you understand the background for some of 88888's comments.

s/88888's/its own/
s/you/Dihedral 88888/

 

[David Brown]

s/88888's/its own/
s/you/Dihedral 88888/

You've lost me. I can't parse that in any way that makes sense - "it's
own posts are mostly incomprehensible" ?

I haven't tried to guess what 88888 might or might not know. But I am
making a guess about what James is unfamiliar with (not even someone of
his experience knows /everything/), in the hope of reducing the mixups
and confusions here as he patiently tries to understand 88888's posts.

 

[BartC]

You've lost me. I can't parse that in any way that makes sense - "it's
own posts are mostly incomprehensible" ?

He's saying that 88888 Dihedral isn't human; it's just software (a 'bot').

 

[James Kuyper]

On 03/13/2014 05:16 AM, David Brown wrote:
....

88888's posts are mostly incomprehensible, with all sorts of ideas
jumbled up. ...

I've done a quick google groups review of all of my previous
"communications" with 88888. He could very well be a bot, but if so, he
is a context-sensitive one. His responses do seem to have some
connection to the messages they are supposedly in response to. It's a
very tenuous connection, inadequate for rational conversation, but it's
greater than I'd expect from pure randomness.

... But I'm guessing you don't know much about hardware
description languages, so allow me to give you a couple of points that
might help you understand the background for some of 88888's comments.

Hardware description languages - HDL's - are used for the design and
simulation of integrated circuits, ASICs and FPGAs. They typically
cover both synthesisable code (i.e., stuff that can be made into chips
or put on an FPGA) and purely simulation code (stuff to check that the
synthesisable part is correct in simulations). A key part of the
synthesisable part is in a style called "register transfer level" - the
digital logic consists mainly of a sea of registers which are connected
to each other by combinational logic and common clocks. The code that
describes this logic is RTL.

The two most commonly used HDL's are Verilog and VHDL. Of these,
Verilog is often considered to be "a bit like C" and VHDL is "a bit like
Ada". This is because Verilog uses brackets, and emphasises simpler
types and shorter code, while VHDL emphasises greater use of types,
explicit conversions, and has a more verbose syntax. So it is Verilog
that is vaguely inspired by C, not the other way round.

You're right - I know very little about HDLs, nothing more than what I
could glean from Wikipedia's article on Verilog. I did not examine that
article closely enough to be able to answer the following question, but
perhaps you might be able to: 88888 Dihedral's mentions of Verilog might
seem to be vaguely relevant, if the fact that Verilog was used to
describe a system was sufficient to ensure that said system is a
multi-process system.

This seems implausible to me; as I understand it, whether or not a
system is a multi-process system is an issue determined by the operating
system, not the hardware, though the hardware does affect how easy or
difficult it might be to implement multi-processing, and of course,
especially for small systems, the OS might be hard-wired into the system.

However, if the scope of Verilog does include the features that make a
system a multi-processing one, I find it implausible that it would be
incapable of describing a system that only allows one process at a time.

 

[James Kuyper]

He's saying that 88888 Dihedral isn't human; it's just software (a 'bot').

If that's what he was saying, it's a poor way of making that point - if
88888 Dihedral is a bot, then 88888 Dihedral is still the name of that
bot (or at least, one of it's names).

 

[David Brown]

On 03/13/2014 05:16 AM, David Brown wrote:
...

I've done a quick google groups review of all of my previous
"communications" with 88888. He could very well be a bot, but if so, he
is a context-sensitive one. His responses do seem to have some
connection to the messages they are supposedly in response to. It's a
very tenuous connection, inadequate for rational conversation, but it's
greater than I'd expect from pure randomness.


You're right - I know very little about HDLs, nothing more than what I
could glean from Wikipedia's article on Verilog. I did not examine that
article closely enough to be able to answer the following question, but
perhaps you might be able to: 88888 Dihedral's mentions of Verilog might
seem to be vaguely relevant, if the fact that Verilog was used to
describe a system was sufficient to ensure that said system is a
multi-process system.

This seems implausible to me; as I understand it, whether or not a
system is a multi-process system is an issue determined by the operating
system, not the hardware, though the hardware does affect how easy or
difficult it might be to implement multi-processing, and of course,
especially for small systems, the OS might be hard-wired into the system.

However, if the scope of Verilog does include the features that make a
system a multi-processing one, I find it implausible that it would be
incapable of describing a system that only allows one process at a time.

Whether "multi-process" is a hardware or OS issue depends on what you
mean by "process". If you mean it as in "unix process", then it is an
OS issue - but in Verilog a piece of sequential logic is also referred
to as a "process", and that is clearly a hardware issue. So almost any
logic design in Verilog more complex than a simple traffic lights
example will be multi-process - different parts of your chip (or FPGA
design) are doing different things at the same time.


(FPGA logic design is great fun if you need a new hobby, and can give an
insight into what is happening inside a cpu.)

 

[Geoff]

On 03/12/2014 05:52 PM, Andreas Perstinger wrote:
...

That seems a plausible explanation; I'll follow that advice.

He's not a bot.

From the syntax of his English language I'd say he Asian, probably
Chinese, without strong English language skills so his posts are short
and terse. He has background in hardware design, probably electronics
engineering and mathematics.

What I think he means to say is that while C isn't a multiprocessing
language, the problems of multiprocessing are addressable in C even if
it's outside the scope of the C standard. These multiprocessing issues
were addressed and solved in existing C-like HDLs.

He is clearly correct, since the many multiprocess operating systems
exist, programmed in C, that solve the problems of resource management
and scheduling even though the C standard provides no specifications
for it.