220 40 <509FC7CE.309@gmx.net> article Path: news.gmane.org!not-for-mail From: Jens Maurer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing constexpr char[]'s in asm directives Date: Sun, 11 Nov 2012 16:44:14 +0100 Lines: 64 Approved: news@gmane.org Message-ID: <509FC7CE.309@gmx.net> References: <27482d3f-117d-4913-b1ff-feb6267760f3@isocpp.org> <509DFF12.9060206@gmx.net> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1352648659 7151 80.91.229.3 (11 Nov 2012 15:44:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Nov 2012 15:44:19 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDPMTYGK64JRBUUP76CAKGQEPTKED7Y@isocpp.org Sun Nov 11 16:44:29 2012 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f70.google.com ([74.125.82.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TXZi0-0007b1-MT for gclcip-std-proposals@m.gmane.org; Sun, 11 Nov 2012 16:44:28 +0100 Original-Received: by mail-wg0-f70.google.com with SMTP id dt14sf3885259wgb.9 for ; Sun, 11 Nov 2012 07:44:19 -0800 (PST) Original-Received: by 10.14.213.135 with SMTP id a7mr17610711eep.2.1352648658996; Sun, 11 Nov 2012 07:44:18 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.14.221.73 with SMTP id q49ls3744870eep.7.gmail; Sun, 11 Nov 2012 07:44:18 -0800 (PST) Original-Received: by 10.14.194.71 with SMTP id l47mr54010465een.6.1352648658058; Sun, 11 Nov 2012 07:44:18 -0800 (PST) Original-Received: by 10.14.194.71 with SMTP id l47mr54010456een.6.1352648658014; Sun, 11 Nov 2012 07:44:18 -0800 (PST) Original-Received: from mailout-de.gmx.net (mailout-de.gmx.net. [213.165.64.22]) by mx.google.com with SMTP id i44si6445302eeo.31.2012.11.11.07.44.17; Sun, 11 Nov 2012 07:44:18 -0800 (PST) Received-SPF: pass (google.com: domain of Jens.Maurer@gmx.net designates 213.165.64.22 as permitted sender) client-ip=213.165.64.22; Original-Received: (qmail invoked by alias); 11 Nov 2012 15:44:17 -0000 Original-Received: from dslb-088-072-147-183.pools.arcor-ip.net (EHLO [192.168.2.100]) [88.72.147.183] by mail.gmx.net (mp072) with SMTP; 11 Nov 2012 16:44:17 +0100 X-Authenticated: #5874409 X-Provags-ID: V01U2FsdGVkX1/Ga/94pOrGD1+vmDu5u6rjKFaTzRKgw3XKuMc1gx qZIwKhbT+OEUkO User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 In-Reply-To: X-Y-GMX-Trusted: 0 X-Original-Sender: jens.maurer@gmx.net X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of Jens.Maurer@gmx.net designates 213.165.64.22 as permitted sender) smtp.mail=Jens.Maurer@gmx.net Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40 Archived-At: 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 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 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_1_to_10; > > asm(generate_asm::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 -- .