spir wrote:
On Fri, 03 Dec 2010 17:49:47 -0500
"Steven Schveighoffer" wrote:
just that i + i generates different instructions than ui + ui where int
i; uint ui;
Not really important, because I'm currently interested in cast only.
Thank you.
That is odd, I would think that i+i generates the
On Fri, 03 Dec 2010 17:49:47 -0500
"Steven Schveighoffer" wrote:
> > just that i + i generates different instructions than ui + ui where int
> > i; uint ui;
> >
> > Not really important, because I'm currently interested in cast only.
> >
> > Thank you.
>
> That is odd, I would think that i+i g
On Fri, 03 Dec 2010 16:53:04 -0500, Michal Minich
wrote:
On Fri, 03 Dec 2010 16:44:42 -0500, Steven Schveighoffer wrote:
On Fri, 03 Dec 2010 16:34:51 -0500, Michal Minich
wrote:
What is performance overhead for casting value of type int to uint and
in the opposite direction. What happen
On Fri, 03 Dec 2010 16:44:42 -0500, Steven Schveighoffer wrote:
> On Fri, 03 Dec 2010 16:34:51 -0500, Michal Minich
> wrote:
>
>> What is performance overhead for casting value of type int to uint and
>> in the opposite direction. What happen when I cast int to int or uint
>> to uint
>
> Nothin
On Fri, 03 Dec 2010 16:34:51 -0500, Michal Minich
wrote:
What is performance overhead for casting value of type int to uint and in
the opposite direction. What happen when I cast int to int or uint to
uint
Nothing, there is no performance, type is strictly a compile-time concept.
(for t
What is performance overhead for casting value of type int to uint and in
the opposite direction. What happen when I cast int to int or uint to uint
(for the simplicity in generic code). I suppose there is no difference,
and it is in fact no-op for processor - it depends only on
interpretation.
