Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: LLVM and Forth Date: Wed, 12 Apr 2017 20:04:45 -0700 Organization: None to speak of Lines: 45 Message-ID: References: <21153661-abf5-4958-82c7-e3c442b45cb9@googlegroups.com> <065e774c-c5fb-4e68-9489-00b5357142d6@googlegroups.com> <2017Apr3.145550@mips.complang.tuwien.ac.at> <2017Apr3.190545@mips.complang.tuwien.ac.at> <2017Apr5.170145@mips.complang.tuwien.ac.at> <2017Apr9.165301@mips.complang.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="13360d95e95b581afe8d2d731341601b"; logging-data="15047"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18QaOgooOlUfkOyeWB4rT3f" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:qnnXnIg6wATNva1Vkx3r0dlTTqw= sha1:BytzAzc6DNA2Y8uQrlFYFz3Kf04= Xref: csiph.com comp.lang.c:108095 supercat@casperkitty.com writes: [...] > On a 16-bit system, given something like: > > long mul(int x, int y) { return x*y; } > > it may be faster on some platforms for a compiler to return the > numerically- correct 32-bit result than for it to sign-extend a 16-bit > result, and I would suggest that programmers should not view > numerically-correct results as "astonishing". If what I wanted was a > 16-bit result that was truncated and sign-extended, I would have made > that intention clear via: > > long mul(int x, int y) { return (int)(x*y); } > > The notion that a compiler might use the multiplication to make > assumptions about x and y would never have occurred to me. The notion that casting an expression that's already of type int to type int would have some non-trivial effect would never have occurred to me. An expression of type int yielding a "numerically-correct" result that's outside the range INT_MIN..INT_MAX is certainly something I would find astonishing -- until I realized that the evaluation has undefined behavior. And even if x*y somehow yielded a result outside the range of int, casting that result to int would at best yield an implementation-defined result (even ignoring the fact that the cast logically does nothing). If I wanted a 16-by-16-to-32 bit multiplication function, given 16-bit int and 32-bit long, I wouldn't write either version of your mul function. I'd probably write: long mul(int x, int y) { return (long)x * y; } (Or I might cast both operands just for symmetry, but the other one will be promoted anyway.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"