Subject: Re: a question about arm-gcc
To: Danny Lau <liudengcs@gmail.com>
From: Adam Nohejl <adam@lokisw.com>
List: port-arm
Date: 06/06/2006 20:24:38
2006/06/06 v 12:13, Danny Lau:
> Hi, all
>
> I am rewiting gzboot to let messages be dumped to the LCD panel  
> rather than the COM port,and the arm--netbsdelf-gcc is generated by  
> command "build.sh -m evbarm tools". For some reasons, I feel that  
> the compiler cann't output correct binary code.
>
> The LCD panel is a 240*320, 16Bpp one. So, a large memory buffer  
> was engaged in as a framebuffer, that is a large continuously  
> "unsigned int" memory array. I declare it as this: unsigned int  
> LCD_BUFFER[320*3][240<<1].

If you really mean "[240>>1]" by "[240<<1]" (according to your last  
message), this will allocate (320*3) * (240/2) = 960 arrays  
containing 120 elements of type int. This probably isn't what you  
want (see below).

> The chip(s3c2410) will raise an "Undefine instruction" exception 
> (run time) when I use "array operator" to iterate the buffer items,  
> like LCD_BUFFER[y][x] = color,

The inner array has only 120 elements, therefore x has to be less  
than 120.

> and preform well when I use "pointer operator" to get access the  
> items, like *(LCD_BUFFER+y+x) = color; For some other buffer, like  
> strings, the situation is totally reversed.

This works only if you define LCD_BUFFER as a contiguous one- 
dimensional array.

The way you work with arrays seems a bit odd to me, but I don't  
really understand the framebuffer stuff, so I hope I got it right.

-- 
Adam