Re: [sdcc-devel] BUG in CONST Table access More Info

[<Mic...@t-...>]

I have just build the current cvs version and tryed it with V2.2.1.

"unsigned int" and "int" are still wrong,

"unsigned long" and "long" are O.K.

Michael @ home


----- Original Message -----
From: "Michael Schmitt" <msc...@ba...>
To: <sdc...@li...>
Sent: Friday, May 05, 2000 3:10 PM
Subject: Re: [sdcc-devel] BUG in CONST Table access More Info


> if i use a table like
> const unsigned long table2[4] = { 0x12345678 , 0x23456789 , 0x34567890 ,
> 0x4567890A };
> and modify the printf to
> printf("\n\r %08LX %08LX %08LX
> %08LX",table2[0],table2[1],table2[2],table2[3]);
> then i get
> 12345678 23456789 34567890 4567890A       ULTRA CORRECT !
> and the table is stored in codespace as
> 78 56 34 12 89 67 45 23 ...
> so, what does this mean ?
> in the first example, the 16-bit value is stored with swaped bytes in
> codespace !
> So this is a bug ! and must be located where the table for the codespace
> is located
>
> so, the sun is gone, clouds with rain are coming up, i can hear the
> thunder and see the ligtning, time to go home :-(
>
> Michael
>
>
>
>
> Michael Schmitt schrieb:
> >
> > Here some additional infos.
> >
> > the constante below is stored in code space as 12 34 23 45 34 56 45 67
> >
> > maybe this helps
> >
> > Michael Schmitt schrieb:
> > >
> > > Hi Folks,
> > >
> > > this one made me loose my hairs !
> > >
> > > i was trying to implement an CRC16-CCITT-V41, but i failed for hours.
> > >
> > > const unsigned int table[4] = { 0x1234 , 0x2345 , 0x3456 , 0x4567 };
> > >
> > > main{
> > > printf("\n\r %04X %04X %04X
%04X",table[0],table[1],table[2],table[3]);
> > > }
> > >
> > > i would expect the following output :
> > >
> > > 0x1234 0x2345 0x3456 0x4567
> > >
> > > but all i get is :
> > >
> > > 0x3412 0x4523 0x5634 0x6745
> > >
> > > so high-byte and low-byte are SWAPed !
> > >
> > > if i place such a table into my source, i would expect to read them
back
> > > regardless of big- or smal-endian !
> > > I have tryed my code with BC3.1 and it works, so i guess this is a
bug.
> > > Or do i do something wrong ?
> > > the used SDCC V220 was build on April 12th, so it is not the release
> > > version, but the release version does also show this.
> > >
> > > The sun is shining,
> > > we have 28 degree celsius,
> > > the sky is blue,
> > > have a nice weekend !
> > >
> > > --
> > > Dipl.-Ing. (FH) Michael Schmitt
> > > Baumer Ident GmbH
> > > Entwicklung / Development Department
> > > Hertzstr. 10
> > > D-69469 Weinheim
> > > Deutschland / Germany
> > > Tel. +49 (0) 6201 9957 - 30
> > > Fax. +49 (0) 6201 9957 - 99
> > > E-Mail : msc...@ba...
> > > Web: http://www.baumerident.com
> > >
> > > _______________________________________________
> > > sdcc-devel mailing list
> > > sdc...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel
> >
> > --
> > Dipl.-Ing. (FH) Michael Schmitt
> > Baumer Ident GmbH
> > Entwicklung / Development Department
> > Hertzstr. 10
> > D-69469 Weinheim
> > Deutschland / Germany
> > Tel. +49 (0) 6201 9957 - 30
> > Fax. +49 (0) 6201 9957 - 99
> > E-Mail : msc...@ba...
> > Web: http://www.baumerident.com
> >
> > _______________________________________________
> > sdcc-devel mailing list
> > sdc...@li...
> > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel
>
> --
> Dipl.-Ing. (FH) Michael Schmitt
> Baumer Ident GmbH
> Entwicklung / Development Department
> Hertzstr. 10
> D-69469 Weinheim
> Deutschland / Germany
> Tel. +49 (0) 6201 9957 - 30
> Fax. +49 (0) 6201 9957 - 99
> E-Mail : msc...@ba...
> Web: http://www.baumerident.com
>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> http://lists.sourceforge.net/mailman/listinfo/sdcc-devel