gnupic: Re: [gnupic] Re: PIC18F47J53
Subject:
Re: [gnupic] Re: PIC18F47J53
From:
Luis de Arquer ####@####.####
Date:
17 Aug 2013 18:23:11 -0000
Message-Id: <CAD_DGvm7UD03NpmkVM_t4TcbcM8wKoM5DZ2R4LDvxEVq3U5REw@mail.gmail.com>
Bob,
On Sat, Aug 17, 2013 at 6:40 PM, Bob Jacobsen ####@####.#### wrote:
>
> Decimal 208 is the integer 0x00D0. In C, int is a signed type.
>
> C does down-conversion by truncation. If you then convert that 208 to a byte type, it's 0xD0, which is a _negative_ number.
>
> When j is an int, the comparison is signed, so c is sign-extended to an int and will immediately be less than j, hence fall through.
>
> Moral: If you want unsigned counters, tell C to use unsigned types.
>
I think you are right in the moral, and it's a good point. It doesn't
look right to mix signed and unsigned counters.
However, in this case, it doesn't make a difference. Reason is I
defined 'byte' as:
typedef unsigned char byte;
When c is extended to int, it is not sign-extended. I have tried it on
gcc, which should (?) be the same:
#include <stdio.h>
typedef unsigned int byte;
int main()
{
byte c = 0xD0;
int a = (int) c;
printf("Sign extending c gives 0x%08X\n", a);
return 0;
}
********************
Output:
Sign extending c gives 0x000000D0
**************************
I haven't had enough time to make all the tests that I want, but it
has to be the XINST bit in the config words. I thought the only
difference it made was to add a few instructions to the instruction
set, but it also adds *indexed addressing mode*. So, every time I was
accessing ACCESS banked memory lower than 0x60 (as I bet are the
registers r0x0n), what it was actually doing is this (from pic
datasheet):
the file address of the
instruction is not interpreted as the lower byte of an
address (used with the BSR in Direct Addressing) or as
an 8-bit address in the Access Bank. Instead, the value
is interpreted as an offset value to an Address Pointer
specified by FSR2. The offset and the contents of
FSR2 are added to obtain the target address of the
operation.
Setting XINST=OFF seems to fix everything, including the "random
clock" issue I had.
Has anyone used extended instruction set before? Maybe it is not
supported in gputils? Could this be a bug in gplink, in sdcc, or in my
code?
Regards,
Luis
