<div dir="ltr"><div>Yes, I agree. The new language is what C++ should be, a parallel language,<br></div><div>and in my opinion what it will inevitably become with hardware evolution.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 28, 2018 at 6:45 PM Oleg Smolsky <<a href="mailto:oleg@cohesity.com">oleg@cohesity.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>Ed, it sounds like you have an idea for a new language with a new
      execution model and a special object representation. I was merely
      trying to point out that these ideas have little to do with what
      C++ compilers do today. <br>
    </p>
    <p>Oleg.<br>
    </p>
    <div class="m_-5137570790430840880moz-cite-prefix">On 2018-11-28 15:28, Edward Givelberg
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>Oleg,</div>
        <div><br>
        </div>
        <div>May be I am misunderstanding what you're saying... <br>
        </div>
        <div>
          <div>Since I am proposing a different framework for execution,</div>
        </div>
        <div>the architecture which has an abstract machine <br>
        </div>
        <div>and a memory model will have to change. <br>
        </div>
        <div>Since I'd like to have remote objects,</div>
        <div>which are native to C++, unlike the existing objects, which
          are all local,</div>
        <div>I am proposing this IOR layer. Access to objects will have
          to change.</div>
        <div>An object access will not longer be a memory access, unless
          some</div>
        <div>compiler optimization determines that the object is local.</div>
        <div>
          <div>So this probably means that it requires changes to the
            LLVM IR?</div>
          <div>As I said, I don't know enough about the current LLVM
            architecture</div>
          <div>to make a detailed plan, but I think it is an interesting
            problem.<br>
          </div>
        </div>
        <div><br>
        </div>
        <div>Ed<br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Wed, Nov 28, 2018 at 5:42 PM Oleg Smolsky <<a href="mailto:oleg@cohesity.com" target="_blank">oleg@cohesity.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On
          2018-11-28 13:14, Edward Givelberg via cfe-dev wrote:<br>
          ><br>
          > [...]<br>
          > Naively, it seems to me that LLVM is a sequential VM, so
          perhaps its <br>
          > architecture needs be extended.<br>
          > I am proposing an intermediate representation which
          encodes object <br>
          > operations,<br>
          > let's call it IOR. IOR is translated to interconnect
          hardware <br>
          > instructions, as well as LLVM's IR.<br>
          > I am proposing a dedicated back end to generate code for
          the <br>
          > interconnect fabric.<br>
          <br>
          Edward, it sounds to me like you are trying to reinvent
          Smalltalk. Its <br>
          core is really about message passing and perhaps people have
          made <br>
          attempts to make it parallel already.<br>
          <br>
          On a more serious and specific note, I think you are ignoring
          the <br>
          "abstract C machine" on which both C and C++ languages are
          built. <br>
          Fundamentally, objects are laid out in memory (let's ignore
          the stack <br>
          for now) and are built off primitive and user-defined types.
          These types <br>
          are known (and stable) throughout the compilation process of a
          single <br>
          program and so are the offsets of various fields that comprise
          the <br>
          objects. All these objects (and often their sub-objects) can
          be read and <br>
          written anywhere in a single-threaded program. Multi-threaded
          programs <br>
          must be data-race-free, but essentially follow the same model.<br>
          <br>
          The point I am trying to make is that the whole model is built
          on memory <br>
          accesses that are eventually lowered to the ISA. There is no
          rigid <br>
          protocol for invoking a member function or reading a member
          variable - <br>
          things just happen in the program's address space. And then
          there is <br>
          code optimizer. The memory accesses (expressed via LLVM IR,
          for example) <br>
          go through various techniques that reduce and eliminate
          pointless <br>
          work... at which point you have the target's ISA and
          absolutely no <br>
          notion of a "method" or "object" (as a well-formed program
          cannot tell <br>
          that the code has been re-arranged, reduced, reordered etc).<br>
          <br>
          I suggest that you take a look at <a href="https://godbolt.org" rel="noreferrer" target="_blank">https://godbolt.org</a> and see what
          the <br>
          compiler emits with -O3 for a few short class/function
          templates as well <br>
          as normal procedural code.<br>
          <br>
          Oleg.<br>
          <br>
        </blockquote>
      </div>
    </blockquote>
  </div>

</blockquote></div>