> Is this behaviour really useful for anything? Is there
> anything in plan9 code that relies on this behaviour in a
> critical way? I suspect this rule can be changed without
> impacting plan 9 code much (which as a rule is of much higher
> quality than most open source code) and we already know
>
>but c89 rules do seem a bit more sensible to me as they avoid surprises
have you read the rules?
On Fri, 23 Apr 2010 18:34:56 EDT erik quanstrom
wrote:
> > On Fri, Apr 23, 2010 at 1:08 PM, Bakul Shah wro
> te:
> >
> > >
> > > If so, I consider it a bug; particularly as there is no
> > > overflow involved anywhere.
> > >
> > >
> >
> > r1 2147482110 r2 -1537
>
> on arm the difference is i
> On Fri, Apr 23, 2010 at 1:08 PM, Bakul Shah wrote:
>
> >
> > If so, I consider it a bug; particularly as there is no
> > overflow involved anywhere.
> >
> >
>
> r1 2147482110 r2 -1537
on arm the difference is interesting. the first
/ is translated:
main+0x20 0x1040MOVW(R4
> On Fri, Apr 23, 2010 at 1:08 PM, Bakul Shah wrote:
>
> >
> > If so, I consider it a bug; particularly as there is no
> > overflow involved anywhere.
> >
> >
>
> r1 2147482110 r2 -1537
that's be 0 for 2. the expected answer is 1543.
same answer on arm.
acid: (1234 - 4321)/2\D
-1543
- erik
On Fri, Apr 23, 2010 at 1:08 PM, Bakul Shah wrote:
>
> If so, I consider it a bug; particularly as there is no
> overflow involved anywhere.
>
>
r1 2147482110 r2 -1537
ron
On Fri, 23 Apr 2010 19:53:24 BST C H Forsyth wrote:
> >As per C89 in this case the unsigned char value should be
> >promoted to a *signed* int value. The sum will be of type
> >signed int and so the division will do the right thing. In
> >kencc case it seems the sum has type unsigned int for som
On Fri, Apr 23, 2010 at 07:53:24PM +0100, C H Forsyth wrote:
>
> on 19 April, I wrote:
> >notably the compiler doesn't implement the value-preserving rules for
> >comparisons. ...
> >instead the compiler implements the older unsigned-preserving rule
It's a chance I was working with a software as
>As per C89 in this case the unsigned char value should be
>promoted to a *signed* int value. The sum will be of type
>signed int and so the division will do the right thing. In
>kencc case it seems the sum has type unsigned int for some
>reason and further, the signed divisor (2) is promoted to a
On Thu, Apr 22, 2010 at 03:49:11PM -0700, Bakul Shah wrote:
> On Thu, 22 Apr 2010 23:15:51 +0200 tlaro...@polynum.com wrote:
> > This is: signed long + signed long + unsigned char.
>
> > Do you mean that there is first promotion :
> >
> > 1) unsigned char is promoted to unsigned int (A6.1).
On Thu, 22 Apr 2010 23:15:51 +0200 tlaro...@polynum.com wrote:
> This is: signed long + signed long + unsigned char.
> Do you mean that there is first promotion :
>
> 1) unsigned char is promoted to unsigned int (A6.1).
As per C89 in this case the unsigned char value should be
promoted to
On Thu, Apr 22, 2010 at 11:15:51PM +0200, tlaro...@polynum.com wrote:
>
> I get:
>
> gcc: -201
> ken-cc: 2147483447 (2^31 - 201)
>
> This is: signed long + signed long + unsigned char.
>
> Do you mean that there is first promotion :
>
> 1) unsigned char is promoted to unsigned int (A6.1)
Bingo! see below...
On Thu, Apr 22, 2010 at 01:07:40PM -0700, Bakul Shah wrote:
> On Thu, 22 Apr 2010 21:32:36 +0200 tlaro...@polynum.com wrote:
> > On Thu, Apr 22, 2010 at 03:08:40PM -0400, ge...@plan9.bell-labs.com wrote:
> > > What type is `smallnumber'?
> >
> > typedef unsigned char smallnum
On Thu, 22 Apr 2010 21:32:36 +0200 tlaro...@polynum.com wrote:
> On Thu, Apr 22, 2010 at 03:08:40PM -0400, ge...@plan9.bell-labs.com wrote:
> > What type is `smallnumber'?
>
> typedef unsigned char smallnumber;
Aha!
> translated from Pascal:
>
> small_number=0..63;
IIRC in
On Thu, Apr 22, 2010 at 03:08:40PM -0400, ge...@plan9.bell-labs.com wrote:
> What type is `smallnumber'?
typedef unsigned char smallnumber;
translated from Pascal:
small_number=0..63;
--
Thierry Laronde
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE9
What type is `smallnumber'?
Oups, I sent the version with the modifications applied (enrolling).
Here is the vanilla version (with reformating):
void
makemoves( scaled xx0 , scaled xx1 , scaled xx2 , scaled xx3 ,
scaled yy0 , scaled yy1 , scaled yy2 , scaled yy3 ,
smallnumber xicorr , smallnumber etacorr )
On Thu, Apr 22, 2010 at 10:03:58AM -0700, Bakul Shah wrote:
>
> What is the type of x1 and x2? Can you show an actual C code
> fragment? Don't worry about it being complete. Just the half()
All are "integer" (in WEB -> Pascal ->)
#define integer long
The half() macro is only this:
#define hal
On Thu, 22 Apr 2010 17:29:53 +0200 tlaro...@polynum.com wrote:
> Data:
> Under NetBSD/gcc, I have the following values:
>
> before: x1:=5440, x2:=-5843, x3:=78909
> after: x1:=5440, x2:=-201, x3:=18166, r:=6827 t:=30232
>
> Under Plan9/gcc, I have the following values:
>
> bef
So I have finally narrow down and compare the calculus under
NetBSD/i386/gcc and Plan9/i386/ken-cc. And this has nothing to do with
div versus shift...
ken-cc is at fault here and it seems deep; it has apparently to deal
with registerization.
Data:
Under NetBSD/gcc, I have the following values:
20 matches
Mail list logo
