From 7287350071462323496 X-Google-Thread: f78e5,3c316a202087bfac X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!news.glorb.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: "SuperKoko" Newsgroups: comp.std.c++ Subject: Re: Defining undefined, etc., behavior Date: 16 Apr 2006 04:50:05 GMT Organization: http://groups.google.com Lines: 98 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1145089390.385728.241860@v46g2000cwv.googlegroups.com> References: <123m587c3abqge4@corp.supernews.com> <1145040127.209805.222290@i40g2000cwc.googlegroups.com> <444047DE.1070301@erdani.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on ak74.algebra.com X-Spam-Level: *** X-Spam-Status: No, score=3.4 required=5.0 tests=HEADER_SPAM,MISSING_HEADERS, TO_CC_NONE autolearn=disabled version=3.1.1 X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@ucar.edu X-Trace: posting.google.com 1145089398 20200 127.0.0.1 (15 Apr 2006 08:23:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 15 Apr 2006 08:23:18 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.1 (like Gecko),gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: v46g2000cwv.googlegroups.com; posting-host=82.255.248.33; posting-account=vOfC2w0AAABzHsIWnglmMRchI1pVxsvC X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-MIME-Autoconverted: from quoted-printable to 8bit by mulga.cs.mu.OZ.AU id k3F8NeD7004911 X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Xref: g2news1.google.com comp.std.c++:1557 "Andrei Alexandrescu See Website For Email a �crit : > It could be argued that the function call can be faster. Each PUSH will > decrement the stack register. PUSH looks small, but it's not; it entails > a fair amount of microcode, and since we restrict ourselves to 8088, > that microcode will execute slowly, too - only a tad faster than the > equivalent assembly code. Or is it just as slow? I don't remember. > You know, I exactly counted the CPU cycles needed! And, modern compilers have dependencies on push operation, but not the 8088. And, mov [bp - ...],ax is slower than push ( 22 cycles instead of 15 cycles). There is also the problem of accessing the stack with bp... as I said, with a three-parameters function, the compiler needs to save the old bp, install a new bp, mov arguments, and then restore the old bp. IMHO 102 cycles is significantly more than 57 cycles. > In contrast, this other method computes the stack frame of f() > statically, and then writes to the stack without needing to manipulate > sp. As a consequence, there are less RAW dependencies and the potential > for parallelization is superior (a potential not illustrated by the > example at hand). Only on some modern architectures. But, C++ is a general purpose language meant to be portable on many CPU, not only PowerPC and PC. Anyway, I think that, for performance reasons, if the C++ standard specifies all order of evaulation (especially for the order of side effects), optimizing compilers will have compiler switches in order to get the old behaviour. On superscalar CPU, the compiler freedom of order of evaluation of side effects reduces assembly instruction dependencies. And, as soon as references/pointers are used, compilers have much difficulty to make no-alias optimizations. Actually, they are at least allowed to do no-alias optimizations between two sequence points. However I think that there are many implementation-defined behaviour that could be removed. For example, the signedness of char. I would opt for specifying that char is unsigned (even if it will need backward compatibilities switches on some popular compilers), because there are machines that have not a bijection between the values of bits of a signed char, and the value of the signed char. typeinfo.name() should be specified, instead of being unspecified! Remove undefined behaviours of the "lexical conventions" chapter, and replace them by ill-formed programs, and implementation-defined behaviours. To give an example: 2.8 Header names [lex.header] header-name: "q-char-sequence" h-char-sequence: h-char h-char-sequence h-char h-char: any member of the source character set except new-line and > q-char-sequence: q-char q-char-sequence q-char q-char: any member of the source character set except new-line and " 2 If either of the characters ' or \, or either of the character sequences /* or // appears in a q-char-sequence or a h-char-sequence, or the character " appears in a h-char-sequence, the behavior is undefined.7) IMHO, that is really a gratuitous "undefined behaviour". Another example: 3 In translation phase 6 (_lex.phases_), adjacent narrow string literals are concatenated and adjacent wide string literals are concatenated. If a narrow string literal token is adjacent to a wide string literal token, the behavior is undefined. IMHO, it should yield a wide string litteral, or it could also be "ill-formed". --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]