Re: [linuxsh-shmedia-dev] The problem I encountered in pointer

[Richard C. <Ric...@su...>]

* h.z <zh...@ya...> [2003-05-17]:
> 	When I repot a x86 problem ,  I get some segment
> error.  I test the following codes,  it can work at
> x86, but not  sh5.
> 	
> 	/* test.c */
> 
> 	char str[ ]={
> 		'a','b','c'
> 	};
> 
> 	int main(void)
> 	{
> 		char *ptr;
> 		short i;
> 		
> 		ptr=str+1;
> 		i=*(short *) ptr;		/* here error. I can't convert an
> odd pointer to short */
> 	
> 		return 0;
> 	}
> 
> 	The codes are well in x86, but will get segment error
> in sh5.
> 	To coross compile the codes, I use the following
> commands:
> 	
> 	sh64-superh-linux-gnu-gcc -O2 -o  test test.c
> 	
> 	When I port a x86 program to sh5,  what I should pay
> more attention to ? 

The underlying problem is that the SH-5 requires pointers to be aligned
to the size of the corresponding datatype.  (This is true of lots of
other RISC processors also.)  So, for example, pointers of type (short
*) must be 2-byte aligned when you try to dereference them, otherwise
you will get an address error exception.

I expect that in your program, the char array 'str' is placed at an even
address (i.e. 2-byte aligned), therefore 'ptr' is not 2-byte aligned,
therefore you can't dereference it successfully as a (short *).

I believe the x86 has support for dereferencing pointers with arbitrary
alignments (although with a performance penalty if the pointer isn't
correctly aligned), which explains why your example works on x86.

Note that for SH-5, the behaviour I described is true of the 'normal'
multi-byte load/store instructions : ld.w, ldx.w, ld.uw, ldx.uw, ld.l,
ldx.l, ld.q, ldx.q & the equivalent stores.  These are the instructions
which compilers would typically generate.

There are also specialised instructions called ldlo.l, ldhi.l, ldlo.q,
ldhi.q (+ corresponding stores) which can achieve loads and stores to
misaligned multi-byte pointers, at a cost of needing 3 instructions for
a load or 2 for a store, instead of 1 instruction in the aligned case.
Since present-day compilers don't target these intruction (to my
knowledge), you would need to use assembler inserts, intrinsic functions
or hand-coded assembler functions to access them.

Hope that helps!
Richard

-- 
Richard \\\ SuperH Core+Debug Architect /// .. At home ..
  P.    /// ric...@su...  ///  rc...@rc...
Curnow  \\\ http://www.superh.com/    ///  www.rc0.org.uk