array index type of signed int

Hi,

Not realy an answer but a question, doesn't the line 'array[0] _at 0x7600' generate a compiler error (invalid dimension size)? and should instead be 'array[0x0100] _at 0x7600'

But as regards your question, what you have written is what i would expect and to me suggests that keil are treating the index as signed even though you have declared/cast it as unsigned.

Mark.

What exactly are you trying to achieve here?

Is this some competition to use as many bizarre tricks in one go as possible?!

* Arrays of size zero
* negative array indexes (ie, attempting to access elements before the start of the array)
* using a negative index, but then casting it to signed and relying on it coming out as positive 255!

If you want to access X:0x76FF, why don't you just do it?

Or, if you want an index of 255, why don't you just do it - instead of obfuscating it with a cast of -1 ?!

I think the compiler might feel entitled to behave a little oddly in the face of such tactics!

oops, sorry,
there is an error in the sample code:
the first line has to be

unsigned int array[ 256] _at_ 0x7600

"Are there other known problems with typecasting? I'm afraid, there are some other typecasts in my sourcecode."

But why are you casting -1 when what you really want is 255?
Why can't you just write 255?!

I want to create a circular buffer with size of 256 (0-255)integers. The output is LIFO. In my case, the index-counter is decremented. The type of the index counter is unsigned char (0-255). There is no problem when i first decrement the index and then read/write the array. But when i put the result of the calculation (index - 1)

array[(unsigned char)( index - 1)] //THIS IS AN EXAMPLE

"The output is LIFO."

Surely, that's a stack - not a circular buffer?

"Surely, that's a stack - not a circular buffer?"
It's a mixture of both, but please, don't misinterprete the use of this code. To get the problem, you don't need to know what is the use of the code. I don't want to discuss about storage technics.

There's definitely something odd going on here. Take a look at this:

   int xdata array[256] _at_ 0x7600; //xdata
   unsigned char index = 0;
   unsigned char idx;

   idx=(unsigned char)(index - 1);
   printf("%p\n", &array[(unsigned char)(index - 1)]); //x:75FE
   printf("%p\n", &array[idx]); //x:75FE
   printf("%p\n", array+(unsigned char)(index - 1)); //x:77FE
   printf("%p\n", array+idx);   //x:75FE

Sorry, ingore my previous post. It's full of typos. This is hopefully correct:

   int xdata array[256] _at_ 0x7600; //xdata
   unsigned char index = 0;
   unsigned char idx;

   idx=(unsigned char)(index - 1);
   printf("%p\n", &array[(unsigned char)(index - 1)]); //x:75FE
   printf("%p\n", &array[idx]); //x:77FE
   printf("%p\n", array+(unsigned char)(index - 1)); //x:75FE
   printf("%p\n", array+idx);   //x:77FE

Stefan,
did you compile with c51v750a ? BTW, the software-versions which are displayed in the uV2 are:
C-Compiler C51.exe v7.50
Assembler A51.exe v7.10
Linker BL51.exe v5.12
Librarian LIB51.exe v4.24

I'm sure i've updated to C51v750a.

I will compile the example code with an older version and post the result here.

"did you compile with c51v750a ?"

No, C51 v7.01.

"No, C51 v7.01."

ok, then i don't need test it with my older version V7.04

I will contact Keil for informations, thanks.

"I will contact Keil for informations, thanks."

Please post the result when you get one.

Today i received a mail from Keil:

Mr. Schneebauer wrote:

"prinzipiell haben Sie Recht, daß es sich hier um einen Fehler handelt.
Normalerweise versucht der Compiler das '-1' in die Konstanten zu
verpacken um das Programm besser zu optimieren. Wir haben diesen Fehler
nun auch behoben. Da Änderungen an zentralen Funktionen gemacht wurden,
muß dieser Compiler noch ausführlich getestet werden bevor wir ihn
ausliefern können."


Basicly, what he writes is:
Yes, its a bug. The bug is fixed and the new compiler-version will be tested.

Stefan, thank you for verifying this problem.