Multiprocess I/O

Discussion in 'C Programming' started by seimarao, Feb 22, 2014.

  1. seimarao

    Lew Pitcher Guest

    On Tuesday 11 March 2014 17:17, in comp.lang.c, "88888 Dihedral"
    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.
     
    Lew Pitcher, Mar 11, 2014
    #21
    1. Advertisements

  2. seimarao

    James Kuyper Guest

    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.
     
    James Kuyper, Mar 12, 2014
    #22
    1. Advertisements

  3. Don't you get the verilog part derived
    from C ?
     
    88888 Dihedral, Mar 12, 2014
    #23
  4. seimarao

    James Kuyper Guest

    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.
     
    James Kuyper, Mar 12, 2014
    #24
  5. 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.
     
    88888 Dihedral, Mar 12, 2014
    #25
  6. seimarao

    James Kuyper Guest

    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.
     
    James Kuyper, Mar 12, 2014
    #26
  7. 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.
     
    88888 Dihedral, Mar 12, 2014
    #27
  8. seimarao

    James Kuyper Guest

    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.
     
    James Kuyper, Mar 12, 2014
    #28
  9. 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.
     
    Keith Thompson, Mar 12, 2014
    #29
  10. 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
     
    Andreas Perstinger, Mar 12, 2014
    #30
  11. seimarao

    James Kuyper Guest

    On 03/12/2014 05:52 PM, Andreas Perstinger wrote:
    ....
    That seems a plausible explanation; I'll follow that advice.
     
    James Kuyper, Mar 12, 2014
    #31
  12. 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.
     
    88888 Dihedral, Mar 12, 2014
    #32
  13. seimarao

    David Brown Guest

    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
     
    David Brown, Mar 13, 2014
    #33
  14. seimarao

    Kaz Kylheku Guest

    s/88888's/its own/
    s/you/Dihedral 88888/
     
    Kaz Kylheku, Mar 13, 2014
    #34
  15. seimarao

    David Brown Guest

    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.
     
    David Brown, Mar 13, 2014
    #35
  16. seimarao

    BartC Guest

    He's saying that 88888 Dihedral isn't human; it's just software (a 'bot').
     
    BartC, Mar 13, 2014
    #36
  17. seimarao

    James Kuyper Guest

    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.
     
    James Kuyper, Mar 13, 2014
    #37
  18. seimarao

    James Kuyper Guest

    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).
     
    James Kuyper, Mar 13, 2014
    #38
  19. seimarao

    David Brown Guest

    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.)
     
    David Brown, Mar 13, 2014
    #39
  20. seimarao

    Geoff Guest

    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.
     
    Geoff, Mar 13, 2014
    #40
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.