.string stores the ASCII values wrong

Anirudh Sharma said:

arr             .string "Hello World\0"
Although it should be stored as "Hello World" however it is storing as "eHll ooWlr\d"

It is storing it as "Hello World". However, in hexadecimal view, the values are presented with the high-byte first, while in memory the low-byte is stored first.

So the word "0x6548" is stored in memory as 0x48 0x65 = 'H', 'e'

However, the "\0" at the end is stored literally as '\' and '0', not as 0x00 byte. :)
(the assembler automatically puts a 0x00 delimiter after a string anyway)

Order is in the eyes of the beholder.

When the Disasembly says:

f822:    6548   ...

It means location f822 has the byte 48 and the next location has 65. These 2 bytes form a big-endian word 6548

Jens-Michael Gross said:

...

However, the "\0" at the end is stored literally as '\' and '0', not as 0x00 byte. :)
(the assembler automatically puts a 0x00 delimiter after a string anyway)

old_cow_yellow said:

Did it?

Look at the posted memory dump. IT ends with 0x5c, 0x30, 0x00 =  '\', '0', 0

Well, teh trailing zero could be due to padding, But why should it pad with 0 and not 0xff?

The question I have is, does it always pad or only when what follows is an instruction and needs to be aligned to even address. The memory dump cannot answer that.

There is such a thing called null terminate string. In that case, the 0 is not a padding, but an essential part of the null terminated string. Again, I cannot tell if that is the case or not. 

0xFF is often used as padding. 0 is also often used as padding. I do not know the reason why 0 not 0xff. Nor why 0xff not 0.

old_cow_yellow said:

0xFF is often used as padding. 0 is also often used as padding. I do not know the reason why 0 not 0xff. Nor why 0xff not 0.

I do. Padding is usually done by just moving the address counter to the next aligned address. So the padded cell is untouched. And untouched flash cells are 0xff. If it is set to 0x00, it must have been intentionally set to this value.
Of course it is possible that for some unknown reason the assembler fills padded areas with 0x00, but I can't think of any reason for this.

However, this can be tested easily. :)