Re: [Tinycc-devel] Speed?

[Julian Brown]

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