Comments for C++Next

Comment on “Elements of Programming” Chapter 3: Associative Operations by David Rothlisberger

David Rothlisberger — Sun, 05 Sep 2010 06:48:49 +0000

Reading this summary reminded me strongly of “Structure and Interpretation of Computer Programs” (see http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-11.html#%_sec_1.2.4, particularly exercises 1.16 and 1.19). Fun!

I’m glad to see this study group hasn’t died down (I keep meaning to buy Elements of Programming and catching up).

Comment on Expressive C++: Introduction by litb

litb — Fri, 03 Sep 2010 13:48:16 +0000

I'm looking forward to the next installment of your articles. I always wanted to check into boost.proto, but never had time and motivation to do so.

This now is an interesting series I hope, so finally maybe I'm going to be proto-typed! Ahaha

Comment on Expressive C++: Introduction by Vasilis Vasaitis

Vasilis Vasaitis — Thu, 02 Sep 2010 12:02:31 +0000

Great article, thanks!

Comment on Expressive C++: Introduction by Eric Niebler

Eric Niebler — Wed, 01 Sep 2010 17:13:59 +0000

I read the link, but I still don't see the need to build an opcode sequence at runtime. When you have something of the form:

this->block =
    asm[
        add_[eax, imm32(var)],
        ...
    ];

then the opcodes (e.g. add_) are known at compile time. If you assign the block to a block variable, then the block can be stored in type-erased form, but the code associated with the block itself is generated entirely at compile time. (BTW, when you say "opcode" do you really mean the code needs to be interpreted at runtime, or are you going for portable inline assembly? The former is easy, the latter depends on the ability of the compiler to inline functions with inline asm blocks, as I've said.)

Hopefully, this will all be more clear once I publish future articles. In fact, if I could understand your requirements a bit, this might make a really interesting example for an article. Do you have code that already does what you want? Could you publish it?

Comment on Expressive C++: Introduction by LPR

LPR — Wed, 01 Sep 2010 15:23:52 +0000

Sorry, I’m just not seeing it.

Link for definition of “Basic block”: http://en.wikipedia.org/wiki/Basic_block

It is the basic block which defines a unit of execution. Basic blocks are built at runtime from the input opcode sequence. What you describe would be better suited to a simple fetch/decode/execute loop.

Comment on Expressive C++: Introduction by Eric Niebler

Eric Niebler — Wed, 01 Sep 2010 00:30:27 +0000

AFAICT, the opcodes don't need to be composed at runtime. They can be composed at compile time. Proto can do that by composing the larger asm block out of function (object)s with inline asm. That's no problem. The only question is whether such a composite can be inlined by the compiler leaving only the inline asm and none of the function calls. That's the part I don't know. It would be pretty easy to test that, though.

Comment on Expressive C++: Introduction by LPR

LPR — Wed, 01 Sep 2010 00:23:05 +0000

The main thing to consider is that an arbitrary sequence of opcodes must composed, at runtime, to form the basic block. If each translated opcode is a function, then the basic block becomes a sequence of function pointers, one pointer per opcode. I’m not sure how any compiler could then guarantee that a basic block would form a single unit of execution as is the case when a basic block is nothing more than a sequence of raw bytes (machine code).

Comment on Expressive C++: Introduction by Eric Niebler

Eric Niebler — Tue, 31 Aug 2010 22:12:20 +0000

And I’ll admit I know nothing about inline assembly and how it interacts with function inlining. If a function with inline asm can’t be inlined, then Proto won’t be able to help. But I honestly don’t know.

Comment on Expressive C++: Introduction by LPR

LPR — Tue, 31 Aug 2010 21:40:34 +0000

As you can see, I don’t know anything about Proto. Anyway, the idea was that eval would return (but not execute) a block of x86 machine code.

Comment on Expressive C++: Introduction by Eric Niebler

Eric Niebler — Tue, 31 Aug 2010 21:23:04 +0000

Well, you wouldn't want the invocation to eval and the assignment to asm be in different statements. Something like this might work:

this->block =
    asm[
        add_[eax, imm32(var)],
        ...
    ]();

Multiple asm statements within the asm block would be comma-separated. I don't know what this->block is or the assignment to it is for, though.