Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #45811 > unrolled thread

Re: "i = i|0"

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: "i = i|0" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-11 13:55 -0700
    Re: "i = i|0" Ike Naar <ike@iceland.freeshell.org> - 2014-06-11 21:09 +0000
      Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-11 17:37 -0400
        Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 00:56 +0200
          Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 08:19 -0400
            Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 14:45 +0200
              Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 09:25 -0400
                Re: "i = i|0" raltbos@xs4all.nl (Richard Bos) - 2014-06-12 14:50 +0000
                  Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 16:55 +0200
                    Re: "i = i|0" Keith Thompson <kst-u@mib.org> - 2014-06-12 11:28 -0700
                      Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 20:46 +0200
                      Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-12 20:58 +0200
                        Re: "i = i|0" Kaz Kylheku <kaz@kylheku.com> - 2014-06-12 19:20 +0000
                          Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-12 22:13 +0200
                            Re: "i = i|0" Kaz Kylheku <kaz@kylheku.com> - 2014-06-12 21:15 +0000
                              Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-12 23:59 +0200
                                Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-13 01:10 +0200
                                Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-13 01:52 +0200
                                ECMAScript standards (was: "i = i|0") Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-15 12:53 +0200
                                  Re: ECMAScript standards (was: "i = i|0") Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-15 03:59 -0700
                                    Re: ECMAScript standards (was: "i = i|0") gazelle@shell.xmission.com (Kenny McCormack) - 2014-06-15 14:39 +0000
                                      Re: ECMAScript standards BGB <cr88192@hotmail.com> - 2014-06-15 11:41 -0500
                              Re: "i = i|0" Stephen Sprunk <stephen@sprunk.org> - 2014-06-12 17:11 -0500
                                Re: "i = i|0" Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-12 22:40 +0000
                                Re: "i = i|0" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-06-12 22:44 +0000
                                Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-13 01:16 +0200
                                Re: "i = i|0" Thomas Richter <thor@math.tu-berlin.de> - 2014-06-13 19:16 +0200
                                  Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-13 19:21 +0200
                                    Re: "i = i|0" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-13 10:59 -0700
                                  Re: "i = i|0" Tim Streater <timstreater@greenbee.net> - 2014-06-13 18:24 +0100
                                    Re: "i = i|0" Kaz Kylheku <kaz@kylheku.com> - 2014-06-13 21:25 +0000
                Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 17:13 +0200
                  Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 12:17 -0400
                    Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 20:01 +0200
                      Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 16:13 -0400
                      Re: "i = i|0" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-06-12 20:44 +0000
                      Re: "i = i|0" Kaz Kylheku <kaz@kylheku.com> - 2014-06-12 20:59 +0000
                        Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-13 01:22 +0200
                          Re: "i = i|0" Martin Shobe <martin.shobe@yahoo.com> - 2014-06-12 19:48 -0500
                    Re: "i = i|0" John Harris <niam@jghnorth.org.uk.invalid> - 2014-06-13 10:16 +0100
                      Re: "i = i|0" Tim Streater <timstreater@greenbee.net> - 2014-06-13 11:44 +0100
              Re: "i = i|0" "BartC" <bc@freeuk.com> - 2014-06-12 15:06 +0100
                Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 16:54 +0200
            Re: "i = i|0" Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-12 14:11 +0000
              Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 12:20 -0400
        Re: "i = i|0" BGB <cr88192@hotmail.com> - 2014-06-11 22:59 -0500
          Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 08:06 -0400
            Re: "i = i|0" BGB <cr88192@hotmail.com> - 2014-06-12 08:39 -0500

Page 3 of 3 — ← Prev page 1 2 [3]

#45904

In article <laglp9h6q4nv9pqn1ug23i9h9elt38bc7j@4ax.com>, John Harris
<niam@jghnorth.org.uk.invalid> wrote:

> On Thu, 12 Jun 2014 12:17:46 -0400, James Kuyper
> <jameskuyper@verizon.net> wrote:
> 
> >On 06/12/2014 11:13 AM, Thomas 'PointedEars' Lahn wrote:
> 
>   <snip> 
> >> There is no programming language called ‰javascript‰, and from that 
> >> everything else follows.  STFW.
> >
> >I did indeed search the Web.
>   <snip>
> 
> I'm afraid James has dropped into an argument that has been going on
> for several years. The question is how to refer to a variety of
> implementations, some of them trade-marked, in a variety of
> environments : browsers, web servers, etc.
> 
> Some of us want a one-word generic name and think that lower case
> 'javascript' is as good as any. Thomas rejects that idea absolutely,
> often with accompanying abuse.

It *is* as good as any. And the accompanying abuse is, IMO, "usually"
rather than merely "often". Suggested responses to PointyHead vary from
neutral to returning the abuse with interest. One can, of course,
ignore him, but that might confuse newcomers.

Hmmm, perhaps a FAQ entry about his egregious behaviour might be in
order, so newcomers can be quickly warned.

-- 
"Once you adopt the unix paradigm, the variants cease to be a problem - you
bitch, of course, but that's because bitching is fun, unlike M$ OS's, where 
bitching is required to keep your head from exploding." - S Stremler in afc

[toc] | [prev] | [next] | [standalone]

#45852

"Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message
news:2122350.lP4zVSTnZj@PointedEars.de...
> [F'up2 comp.lang.javascript]
>
> James Kuyper wrote in comp.lang.c:

>> but for this particular C expert, the very existence of
>> comp.lang.javascript seems to contradict the most obvious meaning for
>> that

> so), and the newsgroup name is case-insensitive as newsgroup names usually
> go.  (You would not talk about “c” either, would you?)

"c" by itself is ambiguous. "javascript" considerably less so; even without
context, people will know what you were on about (ie. the language formerly
known as Javascript).

>> That doesn't change my main point: the conversion is still required - it
>> can't be optimized away. Or am I wrong about that, too?
>
> The only possible optimization of
>
>  function f(i) {
>    i = i|0;
>    return (i + 1)|0;
>  }
>
> in terms of runtime is
>
>  function f(i) {
>    return ((i|0) + 1)|0;
>  }

If that function is being called as a=f(b), then another optimisation might
be:

 a = b+1;

if the function source is visible at the call-site (especially if being
converted from c source code).

But, how important is that |0 anyway; what would happen if the function was
just:

function f(i) }
  return i+1;
} ?

(I assume that in this language, it is possible to write such a function,
but would anyone actually bother with sticking |0 everywhere? If called with 
an invalid argument, it would still fail wouldn't it?)

-- 
Bartc
 

[toc] | [prev] | [next] | [standalone]

#45855

[F'up2 comp.lang.javascript]

BartC wrote in comp.lang.javascript, comp.lang.c:

> "Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message
> news:2122350.lP4zVSTnZj@PointedEars.de...

It's attribution *line*, _not_ attribution novel.

>> [F'up2 comp.lang.javascript]

Why have you ignored that?  This discussion has nothing to do with C 
(anymore).

>> James Kuyper wrote in comp.lang.c:
>>> but for this particular C expert, the very existence of
>>> comp.lang.javascript seems to contradict the most obvious meaning for
>>> that
>> 
>> so), and the newsgroup name is case-insensitive as newsgroup names
>> usually go.  (You would not talk about “c” either, would you?)
> 
> "c" by itself is ambiguous. "javascript" considerably less so; even
> without context, people will know what you were on about (ie. the language
> formerly known as Javascript).

So those “people” are adopting a new term for a non-existing language that 
is thought to be a successor to some other non-existing language?

(You have no clue what you are talking about.  Visit the ECMAScript Support 
Matrix website to get a minimum one.)
 
>>  function f(i) {
>>    i = i|0;
>>    return (i + 1)|0;
>>  }
>> […]
> 
> If that function is being called as a=f(b), then another optimisation
> might be:
> 
>  a = b+1;
> 
> if the function source is visible at the call-site (especially if being
> converted from c source code).

No, as that would change the semantics considerably.  I also think inlining 
was not what was being asked for here; it is too obvious.
 
> But, how important is that |0 anyway; what would happen if the function
> was just:
> 
> function f(i) }
>   return i+1;
> } ?

Then the value of the “i” parameter would not necessarily be a numeric value 
whose fractional part is zero, neither would be the return value.
 
> (I assume that in this language, it is possible to write such a function,
> but would anyone actually bother with sticking |0 everywhere? If called
> with an invalid argument, it would still fail wouldn't it?)

What is “this language”?

Your questions have been answered before.  Please read more carefully.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#45853

On Thu, 12 Jun 2014 08:19:13 -0400, James Kuyper wrote:

> On 06/11/2014 06:56 PM, Thomas 'PointedEars' Lahn wrote:

>> There is no javascript. [0]

> That comment requires explanation.

The explanation is simple. Lahn resides under a bridge near you eating 
any goats he comes across.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#45864

On 06/12/2014 10:11 AM, Denis McMahon wrote:
> On Thu, 12 Jun 2014 08:19:13 -0400, James Kuyper wrote:
> 
>> On 06/11/2014 06:56 PM, Thomas 'PointedEars' Lahn wrote:
> 
>>> There is no javascript. [0]
> 
>> That comment requires explanation.
> 
> The explanation is simple. Lahn resides under a bridge near you eating 
> any goats he comes across.

That's what I've been starting to think. Except for the "near you" part
- that would worry me.

[toc] | [prev] | [next] | [standalone]

#45835

On 6/11/2014 4:37 PM, James Kuyper wrote:
> On 06/11/2014 05:09 PM, Ike Naar wrote:
>> On 2014-06-11, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>>    When they then call the function with non-integer arguments
>>>    its their fault. (Or they can write a |0 wrapper instead
>>>    of requiring each and every function to do |0 and thereby
>>>    possibly slowing down execution and enlarging code size.)
>>
>> With a decent optimizing compiler, do you think that |0 would
>> slow down execution or enlarge code size?
>
> I'm no JS experts, but so far I haven't seen any responses from those
> who are, so I'll throw in my guesses.
>

no JS expert either...

but, I had been working on writing a VM which can run C and supports JS 
as a target...


but, yeah, "|0" if anything, makes code faster, by offering a useful 
hint (and being trivial to optimize away). besides this, it also helps 
enforce integer semantics.


> It seems reasonable to me that it would - in javascript, |0 doesn't just
> cause the integer value to be unchanged (something a smart compiler
> could drop) - it also (and first) causes conversion to a 32-bit integer
> type, if necessary. The compiler can't be expected to know that such a
> conversion will not, in fact, be necessary. This is a substantial
> difference from the original C code, where such conversions would occur,
> if necessary, in the calling code, where the compiler can be sure. A JS
> compiler would have to generate code to check the type of the argument,
> and code to perform the conversion. The checking part, at least, will
> have to be executed even though the conversion code will not.
>


AFAIK:

the numeric type in JS isn't really all that well-defined (in terms of 
how it is implemented), but is generally implemented, essentially, as a 
64-bit double (nevermind if implementations may use integer-types 
internally when they can get away with it, but this is mostly invisible 
at the JS level).

"|0" basically then effectively means (besides "OR with 0") "truncate 
value range to that of a 32-bit integer", but may indirectly serve as a 
hint to the JS engine that it may safely use a 32-bit integer 
representation internally (it may, but need not necessarily, imply a 
type conversion, depending mostly on the "phase of the moon" and "the 
current feelings of the JS engine at this particular moment in time", 
and need not involve a runtime check, say, if the JS-engine already 
knows that the caller calls this code with an integer value, ...).

different JS engines generally implement numbers internally in different 
ways:
NaN-tagged values (pretty much all numbers are double but NaN encodes 
special cases, such as object-pointers/references);
tagged-reference types (where we have a value and a few tag bits 
indicate what it is, ex: pointer/integer/double/...);
inferred basic types (untagged integer or double values, ...);
...


or such...

[toc] | [prev] | [next] | [standalone]

#45846

On 06/11/2014 11:59 PM, BGB wrote:
> On 6/11/2014 4:37 PM, James Kuyper wrote:
...
>> It seems reasonable to me that it would - in javascript, |0 doesn't just
>> cause the integer value to be unchanged (something a smart compiler
>> could drop) - it also (and first) causes conversion to a 32-bit integer
>> type, if necessary. The compiler can't be expected to know that such a
>> conversion will not, in fact, be necessary. This is a substantial
>> difference from the original C code, where such conversions would occur,
>> if necessary, in the calling code, where the compiler can be sure. A JS
>> compiler would have to generate code to check the type of the argument,
>> and code to perform the conversion. The checking part, at least, will
>> have to be executed even though the conversion code will not.
>>
> 
> 
> AFAIK:
> 
> the numeric type in JS isn't really all that well-defined (in terms of 
> how it is implemented), but is generally implemented, essentially, as a 
> 64-bit double (nevermind if implementations may use integer-types 
> internally when they can get away with it, but this is mostly invisible 
> at the JS level).
> 
> "|0" basically then effectively means (besides "OR with 0") "truncate 
> value range to that of a 32-bit integer", but may indirectly serve as a 
> hint to the JS engine that it may safely use a 32-bit integer 
> representation internally (it may, but need not necessarily, imply a 
> type conversion, depending mostly on the "phase of the moon" and "the 
> current feelings of the JS engine at this particular moment in time", 
> and need not involve a runtime check, say, if the JS-engine already 
> knows that the caller calls this code with an integer value, ...).

With the javascript definition given by the OP, could f() be passed an
argument which is not of numeric type, but which can be converted? Your
argument seems to suggest that the compiler need not worry about
performing such a conversion.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#45851

On 6/12/2014 7:06 AM, James Kuyper wrote:
> On 06/11/2014 11:59 PM, BGB wrote:
>> On 6/11/2014 4:37 PM, James Kuyper wrote:
> ...
>>> It seems reasonable to me that it would - in javascript, |0 doesn't just
>>> cause the integer value to be unchanged (something a smart compiler
>>> could drop) - it also (and first) causes conversion to a 32-bit integer
>>> type, if necessary. The compiler can't be expected to know that such a
>>> conversion will not, in fact, be necessary. This is a substantial
>>> difference from the original C code, where such conversions would occur,
>>> if necessary, in the calling code, where the compiler can be sure. A JS
>>> compiler would have to generate code to check the type of the argument,
>>> and code to perform the conversion. The checking part, at least, will
>>> have to be executed even though the conversion code will not.
>>>
>>
>>
>> AFAIK:
>>
>> the numeric type in JS isn't really all that well-defined (in terms of
>> how it is implemented), but is generally implemented, essentially, as a
>> 64-bit double (nevermind if implementations may use integer-types
>> internally when they can get away with it, but this is mostly invisible
>> at the JS level).
>>
>> "|0" basically then effectively means (besides "OR with 0") "truncate
>> value range to that of a 32-bit integer", but may indirectly serve as a
>> hint to the JS engine that it may safely use a 32-bit integer
>> representation internally (it may, but need not necessarily, imply a
>> type conversion, depending mostly on the "phase of the moon" and "the
>> current feelings of the JS engine at this particular moment in time",
>> and need not involve a runtime check, say, if the JS-engine already
>> knows that the caller calls this code with an integer value, ...).
>
> With the javascript definition given by the OP, could f() be passed an
> argument which is not of numeric type, but which can be converted? Your
> argument seems to suggest that the compiler need not worry about
> performing such a conversion.
>

JS is weird, and if it *is* passed an integer value, often any 
checks/conversions can be optimized away.

internally, a given function might end up compiled into several 
different internal functions:
     one which takes an integer value;
     one which takes a double, and converts it;
     one which blows up (known invalid types);
     one which performs a run-time check;
     ...

then, if the caller passes an integer, it will internally call the 
version which accepts an integer (and thus no checks/conversion needed), 
rather than the version which takes other types.

so, for example:
   function f(i) {
     i = i|0;
     return (i + 1)|0;
   }

could potentially end up as 3-5 different functions internally.

ex, in a C equivalent:
   int f_i(int i) {
     return (i + 1);
   }
   int f_d(double i) {
     int t_i;
     t_i=(int)i;
     return (t_i + 1);
   }
   ...

then:
   f(3);
   f(3.14159);
might become effectively:
   f_i(3);
   f_d(3.14159);

usually, the argument lists the callers make use of will indicate which 
version of a function are generated, so if a function is only ever 
called with a particular combination of argument types, only this 
version will be compiled for.


in less-trivial cases (those involving objects and closures, ...), lots 
of other wackiness may come up though.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web