On 11/10/2012 02:15 AM, stackmachine@hotmail.com wrote:
> Simple feature: Allow the use of compiletime constant strings in asm directives. That would allow generating asm through template-meta programs. Wouldn't that be damn awesome?

Could you provide an example program that makes use of such a
feature in a non-trivial way, including the generation of
the compile-time constant strings?  In which way would the
portability of that program be improved if the standard
would prescribe the feature you're proposing?

This needs a lot more elaboration before I'm willing
to invest committee time in it.

The current standard doesn't say a lot about "asm" (see section 7.4),
except that its argument must be a string-literal.  And even then,
the entire asm is conditionally-supported, meaning an implementation
can simply refuse an "asm" with an error message (and not implement it).

Jens

--




.

------=_Part_324_26262145.1352646124819
Content-Type: text/plain; charset=ISO-8859-1



Am Samstag, 10. November 2012 08:16:19 UTC+1 schrieb Jens Maurer:
>
> On 11/10/2012 02:15 AM, stackm...@hotmail.com <javascript:> wrote:
> > Simple feature: Allow the use of compiletime constant strings in asm
> directives. That would allow generating asm through template-meta programs.
> Wouldn't that be damn awesome?
>
> Could you provide an example program that makes use of such a
> feature in a non-trivial way, including the generation of
> the compile-time constant strings?  In which way would the
> portability of that program be improved if the standard
> would prescribe the feature you're proposing?
>
The program would not neccessarily be more portable but it would allow (for
example) simple abstractions around common patterns, such as loops,
conditions, or function calls.
Here's a simple example of how this could be used:

typedef function<stdcall, "print_int"> print_int; // assuming that string
literals could be used as template parameters in the future
typedef for_from_to<1, 10, call<print_int>> print_1_to_10;

asm(generate_asm<x86_64, print_1_to_10>::value::c_str);

::value might be some compiletime string type, which itself holds a
constexpr char[] ::c_str.
Now I do admit that this example might not be the best, but it demonstrates
one important aspect of this feature: The programmer does not have to deal
with details, such as calling conventions, as this is handled by the
library that generates the code.


> The current standard doesn't say a lot about "asm" (see section 7.4),
> except that its argument must be a string-literal.  And even then,
> the entire asm is conditionally-supported, meaning an implementation
> can simply refuse an "asm" with an error message (and not implement it).
>
Instead of only allowing string literals, I propose to allow constant
string expressions. This would only require a change to the grammar AFAIK.
(?)

--




------=_Part_324_26262145.1352646124819
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>Am Samstag, 10. November 2012 08:16:19 UTC+1 schrieb Jens Maurer:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On 11/10/2012 02:15 AM, <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"pkN49n5U4rIJ">s=
tackm...@hotmail.com</a> wrote:
<br>&gt; Simple feature: Allow the use of compiletime constant strings in a=
sm directives. That would allow generating asm through template-meta progra=
ms. Wouldn't that be damn awesome?
<br>
<br>Could you provide an example program that makes use of such a
<br>feature in a non-trivial way, including the generation of
<br>the compile-time constant strings? &nbsp;In which way would the
<br>portability of that program be improved if the standard
<br>would prescribe the feature you're proposing?
<br></blockquote><div>The program would not neccessarily be more portable b=
ut it would allow (for example) simple abstractions around common patterns,=
 such as loops, conditions, or function calls.<br>Here's a simple example o=
f how this could be used:<br><br>typedef function&lt;stdcall, "print_int"&g=
t; print_int; // assuming that string literals could be used as template pa=
rameters in the future<br>typedef for_from_to&lt;1, 10, call&lt;print_int&g=
t;&gt; print_1_to_10;<br><br>asm(generate_asm&lt;x86_64, print_1_to_10&gt;:=
:value::c_str);<br><br>::value might be some compiletime string type, which=
 itself holds a constexpr char[] ::c_str.<br>Now I do admit that this examp=
le might not be the best, but it demonstrates one important aspect of this =
feature: The programmer does not have to deal with details, such as calling=
 conventions, as this is handled by the library that generates the code.<br=
></div><div>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Th=
e current standard doesn't say a lot about "asm" (see section 7.4),
<br>except that its argument must be a string-literal. &nbsp;And even then,
<br>the entire asm is conditionally-supported, meaning an implementation
<br>can simply refuse an "asm" with an error message (and not implement it)=
..<br></blockquote><div>Instead of only allowing string literals, I propose =
to allow constant string expressions. This would only require a change to t=
he grammar AFAIK. (?)<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_324_26262145.1352646124819--

.

On 11/11/2012 04:02 PM, stackmachine@hotmail.com wrote:
>
>
> Am Samstag, 10. November 2012 08:16:19 UTC+1 schrieb Jens Maurer:
>
>     On 11/10/2012 02:15 AM, stackm...@hotmail.com <javascript:> wrote:
>     > Simple feature: Allow the use of compiletime constant strings in asm directives. That would allow generating asm through template-meta programs. Wouldn't that be damn awesome?
>
>     Could you provide an example program that makes use of such a
>     feature in a non-trivial way, including the generation of
>     the compile-time constant strings?  In which way would the
>     portability of that program be improved if the standard
>     would prescribe the feature you're proposing?
>
> The program would not neccessarily be more portable but it would allow (for example) simple abstractions around common patterns, such as loops, conditions, or function calls.
> Here's a simple example of how this could be used:
>
> typedef function<stdcall, "print_int"> print_int; // assuming that string literals could be used as template parameters in the future

Here's the first other extension you'll need.

> typedef for_from_to<1, 10, call<print_int>> print_1_to_10;
>
> asm(generate_asm<x86_64, print_1_to_10>::value::c_str);

This example doesn't convince me.  You've got a C++ compiler in your hand, yet
you try to print the numbers from 1 to 10 in semi-handcrafting assembly?

> ::value might be some compiletime string type, which itself holds a constexpr char[] ::c_str.

Please clue me in: How do you do compile-time string concatenation with the
current constexpr feature set?  (Yes, the preprocessor can splice string
literals, but that's not what we're talking about here.)

> Now I do admit that this example might not be the best, but it demonstrates one important aspect of this feature: The programmer does not have to deal with details, such as calling conventions, as this is handled by the library that generates the code.

I occasionally have to write inline assembly myself, for example for SIMD
code.  In my uses, I never call foreign functions from an asm (the compiler
can do that much better, including passing parameters as appropriate).
Instead, ideally, I write one function that consists entirely of an asm
doing one particular operation that is impossible to achieve with plain C++.

>
>     The current standard doesn't say a lot about "asm" (see section 7.4),
>     except that its argument must be a string-literal.  And even then,
>     the entire asm is conditionally-supported, meaning an implementation
>     can simply refuse an "asm" with an error message (and not implement it).
>
> Instead of only allowing string literals, I propose to allow constant string expressions. This would only require a change to the grammar AFAIK. (?)

I understand your proposal.  I have yet to see a non-trivial use that
makes such a change compelling to me.  Just because something can be done
and looks easy at the top level, doesn't mean it should be done.   There
is always some extra maintenance cost down the road, cf. the current core
issues list.

Thanks,
Jens

--




.

------=_Part_143_23834307.1352651374169
Content-Type: text/plain; charset=ISO-8859-1

Am Sonntag, 11. November 2012 16:44:19 UTC+1 schrieb Jens Maurer:
>
> On 11/11/2012 04:02 PM, stackm...@hotmail.com <javascript:> wrote:
> >
> >
> > Am Samstag, 10. November 2012 08:16:19 UTC+1 schrieb Jens Maurer:
> >
> >     On 11/10/2012 02:15 AM, stackm...@hotmail.com <javascript:> wrote:
> >     > Simple feature: Allow the use of compiletime constant strings in
> asm directives. That would allow generating asm through template-meta
> programs. Wouldn't that be damn awesome?
> >
> >     Could you provide an example program that makes use of such a
> >     feature in a non-trivial way, including the generation of
> >     the compile-time constant strings?  In which way would the
> >     portability of that program be improved if the standard
> >     would prescribe the feature you're proposing?
> >
> > The program would not neccessarily be more portable but it would allow
> (for example) simple abstractions around common patterns, such as loops,
> conditions, or function calls.
> > Here's a simple example of how this could be used:
> >
> > typedef function<stdcall, "print_int"> print_int; // assuming that
> string literals could be used as template parameters in the future
>
> Here's the first other extension you'll need.
>
No. It's a nice-to-have feature, but certainly not required.


> > typedef for_from_to<1, 10, call<print_int>> print_1_to_10;
> >
> > asm(generate_asm<x86_64, print_1_to_10>::value::c_str);
>
> This example doesn't convince me.  You've got a C++ compiler in your hand,
> yet
> you try to print the numbers from 1 to 10 in semi-handcrafting assembly?
>
It's an example, used to demonstrate possible usage. It is not supposed to
be useful.


> > ::value might be some compiletime string type, which itself holds a
> constexpr char[] ::c_str.
>
> Please clue me in: How do you do compile-time string concatenation with
> the
> current constexpr feature set?  (Yes, the preprocessor can splice string
> literals, but that's not what we're talking about here.)
>
By using some template magic.
template <char... S>
struct string
{
    constexpr char c_str[] = { S..., 0 };
};

template <typename, typename>
struct concat;

template <char... S1, char... S2>
struct concat<string<S1...>, string<S2...>>
{
    typedef string<S1..., S2...> value;
};

Possible usage:
typedef string<'a', 'b', 'c'> abc;
typedef string<'d', 'e', 'f'> def;
typedef concat<abc, def>::value abcdef;
std::cout << abcdef::c_str;

>     The current standard doesn't say a lot about "asm" (see section 7.4),
> >     except that its argument must be a string-literal.  And even then,
> >     the entire asm is conditionally-supported, meaning an implementation
> >     can simply refuse an "asm" with an error message (and not implement
> it).
> >
> > Instead of only allowing string literals, I propose to allow constant
> string expressions. This would only require a change to the grammar AFAIK.
> (?)
>
> I understand your proposal.  I have yet to see a non-trivial use that
> makes such a change compelling to me.  Just because something can be done
> and looks easy at the top level, doesn't mean it should be done.   There
> is always some extra maintenance cost down the road, cf. the current core
> issues list.
>
Note that I'm not proposing an entirely new feature, compilers already
contain the logic to evaluate constant expressions. Therefore I only
request to lift a restriction that does not seem to have a rationale.
I do admit that I don't have a use case for it, I just think it'd be a cool
thing to have.


--




------=_Part_143_23834307.1352651374169
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Sonntag, 11. November 2012 16:44:19 UTC+1 schrieb Jens Maurer:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On 11/11/2012 04:02 PM, <a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"BfxLsyeKq-IJ">stackm...@=
hotmail.com</a> wrote:
<br>&gt;=20
<br>&gt;=20
<br>&gt; Am Samstag, 10. November 2012 08:16:19 UTC+1 schrieb Jens Maurer:
<br>&gt;=20
<br>&gt; &nbsp; &nbsp; On 11/10/2012 02:15 AM, <a>stackm...@hotmail.com</a>=
 &lt;javascript:&gt; wrote:
<br>&gt; &nbsp; &nbsp; &gt; Simple feature: Allow the use of compiletime co=
nstant strings in asm directives. That would allow generating asm through t=
emplate-meta programs. Wouldn't that be damn awesome?
<br>&gt;=20
<br>&gt; &nbsp; &nbsp; Could you provide an example program that makes use =
of such a
<br>&gt; &nbsp; &nbsp; feature in a non-trivial way, including the generati=
on of
<br>&gt; &nbsp; &nbsp; the compile-time constant strings? &nbsp;In which wa=
y would the
<br>&gt; &nbsp; &nbsp; portability of that program be improved if the stand=
ard
<br>&gt; &nbsp; &nbsp; would prescribe the feature you're proposing?
<br>&gt;=20
<br>&gt; The program would not neccessarily be more portable but it would a=
llow (for example) simple abstractions around common patterns, such as loop=
s, conditions, or function calls.
<br>&gt; Here's a simple example of how this could be used:
<br>&gt;=20
<br>&gt; typedef function&lt;stdcall, "print_int"&gt; print_int; // assumin=
g that string literals could be used as template parameters in the future
<br>
<br>Here's the first other extension you'll need.
<br></blockquote><div>No. It's a nice-to-have feature, but certainly not re=
quired. <br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">&gt; typedef for_from_to&lt;1, 10, call&lt;print_int&gt;&gt; print_1_=
to_10;
<br>&gt;=20
<br>&gt; asm(generate_asm&lt;x86_64, print_1_to_10&gt;::value::c_str);
<br>
<br>This example doesn't convince me. &nbsp;You've got a C++ compiler in yo=
ur hand, yet
<br>you try to print the numbers from 1 to 10 in semi-handcrafting assembly=
?<br></blockquote><div>It's an example, used to demonstrate possible usage.=
 It is not supposed to be useful.<br>&nbsp;</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">&gt; ::value might be some compiletime string type, whic=
h itself holds a constexpr char[] ::c_str.
<br>
<br>Please clue me in: How do you do compile-time string concatenation with=
 the
<br>current constexpr feature set? &nbsp;(Yes, the preprocessor can splice =
string
<br>literals, but that's not what we're talking about here.)
<br></blockquote><div>By using some template magic.<br>template &lt;char...=
 S&gt;<br>struct string<br>{<br>&nbsp;&nbsp;&nbsp; constexpr char c_str[] =
=3D { S..., 0 };<br>};<br><br>template &lt;typename, typename&gt;<br>struct=
 concat;<br><br>template &lt;char... S1, char... S2&gt;<br>struct concat&lt=
;string&lt;S1...&gt;, string&lt;S2...&gt;&gt;<br>{<br>&nbsp;&nbsp;&nbsp; ty=
pedef string&lt;S1..., S2...&gt; value;<br>};<br><br>Possible usage:<br>typ=
edef string&lt;'a', 'b', 'c'&gt; abc;<br>typedef string&lt;'d', 'e', 'f'&gt=
; def;<br>typedef concat&lt;abc, def&gt;::value abcdef;<br>std::cout &lt;&l=
t; abcdef::c_str; <br><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">&gt; &nbsp; &nbsp; The current standard doesn't say a lot about "asm" (se=
e section 7.4),
<br>&gt; &nbsp; &nbsp; except that its argument must be a string-literal. &=
nbsp;And even then,
<br>&gt; &nbsp; &nbsp; the entire asm is conditionally-supported, meaning a=
n implementation
<br>&gt; &nbsp; &nbsp; can simply refuse an "asm" with an error message (an=
d not implement it).
<br>&gt;=20
<br>&gt; Instead of only allowing string literals, I propose to allow const=
ant string expressions. This would only require a change to the grammar AFA=
IK. (?)
<br>
<br>I understand your proposal. &nbsp;I have yet to see a non-trivial use t=
hat
<br>makes such a change compelling to me. &nbsp;Just because something can =
be done
<br>and looks easy at the top level, doesn't mean it should be done. &nbsp;=
 There
<br>is always some extra maintenance cost down the road, cf. the current co=
re
<br>issues list.
<br></blockquote><div>Note that I'm not proposing an entirely new feature, =
compilers already contain the logic to evaluate constant expressions. There=
fore I only request to lift a restriction that does not seem to have a rati=
onale.<br>I do admit that I don't have a use case for it, I just think it'd=
 be a cool thing to have.<br>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_143_23834307.1352651374169--

.

--e89a8ffba8a3809fac04ce3b8fb9
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Nov 11, 2012 at 5:29 PM, <stackmachine@hotmail.com> wrote:

> It's an example, used to demonstrate possible usage. It is not supposed to
> be useful.
>

Does that mean the proposed feature is also not supposed to be useful? If
it is supposed to be useful, why don't you show that to us instead?


> I do admit that I don't have a use case for it, I just think it'd be a
> cool thing to have.
>

You really want to add a feature *without a use case*? To me that sounds
like wasting everyone's time?

Martinho

--




--e89a8ffba8a3809fac04ce3b8fb9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 11, 2012 at 5:29 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:s=
tackmachine@hotmail.com" target=3D"_blank">stackmachine@hotmail.com</a>&gt;=
</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>

<div>It&#39;s an example, used to demonstrate possible usage. It is not sup=
posed to be useful.<br></div></blockquote><div><br>Does that mean the propo=
sed feature is also not supposed to be useful? If it is supposed to be usef=
ul, why don&#39;t you show that to us instead? <br>

</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I do admit that I d=
on&#39;t have a use case for it, I just think it&#39;d be a cool thing to h=
ave.<span class=3D"HOEnZb"><font color=3D"#888888"><br>

</font></span></div></blockquote><div><br>You really want to add a feature =
*without a use case*? To me that sounds like wasting everyone&#39;s time?<b=
r></div></div><br clear=3D"all">Martinho

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8ffba8a3809fac04ce3b8fb9--

.

------=_Part_860_25384611.1352656854744
Content-Type: text/plain; charset=ISO-8859-1



Am Sonntag, 11. November 2012 18:31:55 UTC+1 schrieb R. Martinho Fernandes:
>
> On Sun, Nov 11, 2012 at 5:29 PM, <stackm...@hotmail.com <javascript:>>wrote:
>
>> It's an example, used to demonstrate possible usage. It is not supposed
>> to be useful.
>>
>
> Does that mean the proposed feature is also not supposed to be useful? If
> it is supposed to be useful, why don't you show that to us instead?
>
Someonem might find it useful. Dunno.


> I do admit that I don't have a use case for it, I just think it'd be a
>> cool thing to have.
>>
>
> You really want to add a feature *without a use case*? To me that sounds
> like wasting everyone's time?
>
As I already stated, it's not a new feature.

--




------=_Part_860_25384611.1352656854744
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>Am Sonntag, 11. November 2012 18:31:55 UTC+1 schrieb R. Martinho Fe=
rnandes:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Nov 11, 2012 a=
t 5:29 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"ubvs3_b7YqMJ">stackm...@hotmail.com</a>&gt;</span=
> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>It's an example, used to demonstrate possible usage. It is not suppose=
d to be useful.<br></div></blockquote><div><br>Does that mean the proposed =
feature is also not supposed to be useful? If it is supposed to be useful, =
why don't you show that to us instead? <br></div></div></blockquote><div>So=
meonem might find it useful. Dunno.<br>&nbsp;<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div class=3D"gmail_quote"><div>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div>I do admit that I don't have a us=
e case for it, I just think it'd be a cool thing to have.<span><font color=
=3D"#888888"><br>

</font></span></div></blockquote><div><br>You really want to add a feature =
*without a use case*? To me that sounds like wasting everyone's time?<br></=
div></div></blockquote><div>As I already stated, it's not a new feature.<br=
></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_860_25384611.1352656854744--

.