Want to know the difference

The first one has an extra * in it. The pointer will be "dereferenced", and thus the first line refers to an actual object (a char, a volatile xdata char, to be more precise).

The second lacks the *, and so this object is a pointer-to-char type, not a char.

There are of course the differences in the address calculated, which should be trivial. If these two expressions are part of a macro with a parameter i, then you might run into trouble with the expanded version of "i". In #define macros, it's a good idea always to wrap the parameters in a layer of parenthesis to make sure the precedence is correct.

#define CHIP_REG(i) (*((char *)(BASE + (i))))

Hi Drew Davis,

Thank you for your sincere help.

The first one is a varible.

The second one is a pointer.

Right?

"The first one is a varible.
The second one is a pointer.
Right?"

No, they are both pointers. The difference is that the first one is being dereferenced. This is basic 'C' stuff so you really need to look in your 'C' book to familiarise yourself with the way pointers work.

Thank you.

I will carefully read my book again.

(*((volatile char xdata *)( CHIP_BASE + i)))
((volatile char xdata *)( CHIP_BASE + PTR_BASE + PTR_SIZE * i))

array[i]

&array[i]

array + i

No, they are both pointers.

No, the first one "is" not a pointer --- it only uses one as part of the computation.

It actually is an object of type "volatile char xdata", positioned at an address computed from 'i' and CHIP_BASE. As such, it's equivalent to something like

volatile char xdata chip[] _at_ CHIP_BASE;
/*...*/
chip[i]

"No, the first one "is" not a pointer --- it only uses one as part of the computation."

I'm afraid it *is* a pointer - one that is being dereferenced.

"It actually is an object of type "volatile char xdata","

The only object present in that expression is one of type 'volatile char xdata *'. Dereferencing that pointer object will yield the value of the object being pointed to, if indeed it *is* pointing to an object.

"As such, it's equivalent to something like

volatile char xdata chip[] _at_ CHIP_BASE;
/*...*/
chip[i]"

That is badly wrong.

I'm afraid it *is* a pointer - one that is being dereferenced.

That makes no sense. By your reasoning, a wheel is a Porsche, just because it's part of its construction.

We were talking about the expressions given by the OP. Not parts of them, or how those parts were used, but just the expressions as given. And I'm afraid I must insist that the first of them is not a pointer. The type of that expression as a whole is (volatile char xdata):

(*((volatile char xdata *)( CHIP_BASE + i)))

written as &array[i] by newbies, or just array + i by more experienced people

Ah, an irresistable spot to quibble. I don't think the syntax depends on experience.

I'll write such an expression either way, depending on my needs. I often prefer the former when the rest of the local code deals with array subscripts, for the sake of consistency in syntax, or simply to emphasis the fact that this object is, in fact, an array (and thus somewhere there is a block of contiguous storage allocated, it has a definite size, and so on, rather than being a random address in the middle of nowhere).

The second form tends to show up when I'm actually doing explicit address arithmetic; say, calculating a register offset from the base address of some peripheral. I also find myself using it a lot with a constant in expressions such as (ptrToPacketHeaderStruct + 1) in code that parses messages, as an idiom for "start of stuff past this header". It's cleaner to me than the explicit equivalent (((U8*)ptrToPacketHeaderStruct) + sizeof(PacketHeaderStruct)), but it does rely on the reader remembering that the "+ 1" is not one byte or word, but one sizeof-thing-pointed-to.

"I'm afraid it *is* a pointer - one that is being dereferenced.

That makes no sense. By your reasoning, a wheel is a Porsche, just because it's part of its construction."

It makes perfect sense. The line of code presented shows a pointer being dereferenced.

Your analogy is amusing but irrelevant.

"We were talking about the expressions given by the OP. Not parts of them, or how those parts were used, but just the expressions as given. And I'm afraid I must insist that the first of them is not a pointer. The type of that expression as a whole is (volatile char xdata)"

Really? The OP asked:
"I want to know the differences between the following two definiations:"

Now, does that sound like 'what are the types of these expressions as a whole' to you?

"The thing in the emphasized parentheses is a pointer, but the expression as whole is not."

You're right - it is a *dereferenced* pointer.

Really? The OP asked:
"I want to know the differences between the following two definiations:"

Now, does that sound like 'what are the types of these expressions as a whole' to you?

No, but the overall type most definitely is one of the "differences between the ... definitions" that he did ask about.

The internal structure of both expressions does indeed involve pointers. But by no stretch of the imagination does that imply that "they are both pointers", as you wrote here in your first contribution to this thread. Of the two things covered by that word "they", only one actually is a pointer, the other only contains one. I really hope you don't seriously believe this to be a negligible difference.

"The internal structure of both expressions does indeed involve pointers. But by no stretch of the imagination does that imply that "they are both pointers", as you wrote here in your first contribution to this thread."

Your snippage of context has altered the quote. What I wrote was:

"No, they are both pointers. The difference is that the first one is being dereferenced."

This was in response to the OP's assertion that the first was a variable.

"Of the two things covered by that word "they", only one actually is a pointer, the other only contains one."

Do you disagree that the first one is a dereferenced pointer?

"I really hope you don't seriously believe this to be a negligible difference."

Don't be silly.