[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Speed?
From: |
Julian Brown |
Subject: |
Re: [Tinycc-devel] Speed? |
Date: |
Fri, 21 Nov 2003 15:11:03 +0000 |
User-agent: |
Mutt/1.5.4i |
On Fri, Nov 21, 2003 at 08:41:12AM -0500, Thomas Harning Jr. wrote:
> At 03:08 AM 11/21/2003, you wrote:
>
> >But c is declared as "int", not as "unsigned int". This will not give
> >the same result if c is neg.
> Yeah it will, it should output a right arithmetic shift on signed ints and
> doing that preserves sign by extending the highest order bit. Did quite a
> bit of assembly and floating point/integer math by direct gate-based
> hardware design, c, SPARC assembly, so I'm quite sure on that.
> Heh, with studying the SPARC and comparing to intel... sure has LOTS more
> registers to use and a very nice variable passing scheme as opposed to
> stack based. Cant wait til the nex gen Intel comes out to be a good
> consumer CPU..... though that'd mean that this project could probably use
> an overhaul, since generating I386 code would be suboptimal.
>
> For >>= and signed integers, a right arithmetic shift should come
> out. [highest order bit extended into "empty" spots]
> For >>= and unsigned ints, a right logical shift should come
> out. [zeroes extended into "empty" spots]
> For <<= and any.. a left logical shift should come out [there is no such
> left arithmetic shift]. [zeroes extended into "empty" spots]
No. A simple example shows otherwise:
#include <stdio.h>
int main(int argc, char* argv[])
{
int i;
for (i=-5; i<5; i++)
{
printf("i=%d i>>1=%d i/2=%d\n", i, i>>1, i/2);
}
return 0;
}
The difference is in the cases where the result is negative, the
division rounds towards zero, the shift towards minus infinity. It can
be fixed-up in asm using an adc though, I think.
Cheers,
Julian