Problems with migrating from small memory model to large memory model in C55x Compiler

Q3. You must not cast the pointer to "int" in large memory model, because "int" is not big enough to hold the value of the pointer 0x8000.  "unsigned int" happens to be big enough for that particular value, but in general you should use "unsigned long" if you must cast a large memory model pointer to an integer type.

DARAM said:

Q2.what exactly is difference between small and large(as far i know small memory model adress length is 16bit where as large it is 23),is the code size limited or restricted in small memory model ? (some one said its 64KB restricted) ?

I'm not sure what you're asking here.  In small model, the total usable memory size is 16 bits, or 64KB.  In large model, you can use the entire memory space of 23 bits, or 8MB, but an individual object (e.g. an array) may only be 64KB.  In huge memory model, objects may be of any size, not to exceed 8MB.

Archaeologist said:

Q2.what exactly is difference between small and large(as far i know small memory model adress length is 16bit where as large it is 23),is the code size limited or restricted in small memory model ? (some one said its 64KB restricted) ?

I'm not sure what you're asking here.  In small model, the total usable memory size is 16 bits, or 64KB.  In large model, you can use the entire memory space of 23 bits, or 8MB, but an individual object (e.g. an array) may only be 64KB.  In huge memory model, objects may be of any size, not to exceed 8MB.

[/quote]

here is one more issue with memory model migration but i feel this is a bug with compiler observe the figure below

in above figure the ptr holds the address of 0x 0001 F01C which has value one but the 32bit adress is dereferencing  some other garbage value rather than the value 1 which is present in actual position

what i suspect is the pointer de-referencing actually should happen to 0x1 F01C by ignoring the starting 3zeros more over the memory 0x0001 F01C is out of memory limit but how come it is getting a memory location

all this problems are coming as i have shifted to large memory model from small memory model :(

here is my linker.cmd file if u think there will be any issues with it  

-stack 0x5000 /*Primary Stack Size 20KBytes*/
-sysstack 0x2000 /*Secondary Stack Size 8KBytes*/
-heap 0x6000 /*Run time Heap memory 16KBytes*/
-c /* Use C linking conventions: auto-init vars at runtime */
-u _Reset /* Force load of reset interrupt handler */
MEMORY
{
/*Unified Program and Data Space*/
PAGE 0:
MMRS (RWIX) : origin = 0x000000, length = 0x0000C0 /*Memory Mapped Register - Reserved Memory*/
DARAM0 (RWIX): origin = 0x0000C0, length = 0X00FF40 /*64KBytes-MMRS*/
SARAM0 (RWIX): origin = 0x010000, length = 0x010000 /* 64KB */
SARAM1 (RWIX): origin = 0x020000, length = 0x020000 /* 128KB */
SARAM2 (RWIX): origin = 0x040000, length = 0x00FE00 /* 64KB */
VECS (RWIX): origin = 0x04FE00, length = 0x000200 /* 512B */
PDROM (RIX): origin = 0xFE0000, length = 0x010000 /* 64KB */

}
SECTIONS
{
.text: >> SARAM1|SARAM2|SARAM0 /*CODE*/

/* Both stacks must be on same physical memory page */
.stack > DARAM0 /* Primary system stack */
.sysstack > DARAM0 /* Secondary system stack */

.data >> DARAM0|SARAM0|SARAM1 /* Initialized vars */
.bss >> DARAM0|SARAM0|SARAM1 /* Global & static vars */
.const >> DARAM0|SARAM0|SARAM1 /* Constant data */
.sysmem > DARAM0|SARAM0|SARAM1 /* Dynamic memory (malloc) */
.switch > SARAM2 /* Switch statement tables */
.cinit > SARAM2 /* Auto-initialization tables */
.pinit > SARAM2 /* Initialization fn tables */
.cio > SARAM2 /* C I/O buffers */
.args > SARAM2 /* Arguments to main() */
.vectors: > VECS /*Interrrupt Vectors*/
.bootmem: > DARAM0
.myheap: > SARAM0
}

I do not see a bug here.  Assuming spx_int32_t really is a 32-bit type, you are performing a 32-bit read of the memory location 0x01F01C, which contains the 32-bit value 0x00010000, which is 65536, as reported by the expression window.  Don't forget that C5500 is a big-endian machine.