Re: LLVM and Forth

From	Keith Thompson <kst-u@mib.org>
Newsgroups	comp.lang.c
Subject	Re: LLVM and Forth
Date	2017-04-12 20:04 -0700
Organization	None to speak of
Message-ID	<lnlgr5uhwy.fsf@kst-u.example.com> (permalink)
References	(10 earlier) <2017Apr9.165301@mips.complang.tuwien.ac.at> <xuAGA.661090$nT1.467590@fx44.am4> <a92c6f37-e327-412a-8923-11ccfee76d54@googlegroups.com> <bQyHA.1006772$Pm3.858411@fx42.am4> <d3b64bc0-40c8-4f54-9381-387da6e6d7f4@googlegroups.com>

Show all headers | View raw

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  <http://www.ghoti.net/~kst>
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"

Back to comp.lang.c | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 00:38 +0000
  Re: LLVM and Forth James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:46 -0400
    Re: LLVM and Forth Robert Wessel <robertwessel2@yahoo.com> - 2017-04-09 22:27 -0500
    Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 12:36 +0000
      Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 14:09 +0100
    Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 13:07 +0000
      Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 16:18 +0100
      Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-10 11:51 -0400
        Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-12 21:32 +0000
          Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-12 18:29 -0400
          Re: LLVM and Forth supercat@casperkitty.com - 2017-04-12 15:34 -0700
            Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-12 23:41 +0000
          Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-13 02:55 +0200
  Re: LLVM and Forth supercat@casperkitty.com - 2017-04-10 15:12 -0700
    Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-12 23:34 +0000
      Re: LLVM and Forth supercat@casperkitty.com - 2017-04-12 17:25 -0700
        Re: LLVM and Forth Keith Thompson <kst-u@mib.org> - 2017-04-12 20:04 -0700

csiph-web