Subject: a question about arm-gcc
To: None <port-arm@netbsd.org>
From: Danny Lau <liudengcs@gmail.com>
List: port-arm
Date: 06/06/2006 18:13:06
------=_Part_17019_14749989.1149588786573
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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].
I firstly implement the LCD drawing function on the ADS enviorment, but when
I ports it to gzboot and compiled with arm-gcc, some strange things happen.
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, 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.
The same program has NOT any problems when compiled in the ADS IDE, no
matter I declare the buffer as "char array" or "int array" (of cause
with some algorithmic alteration).
I know this problem is likely concerned with the type of the operands, but
as far as I know, the armv4 architecture could access byte, half-word
and word correctly. I think there must be a solution to avoid the
complexity. Maybe some useful arm-gcc options must be specified I think ,
please help.
Best regards
--danny
------=_Part_17019_14749989.1149588786573
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div>Hi, all</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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].
</div>
<div>
<div> </div>
<div>I firstly implement the LCD drawing function on the ADS enviorment, but when I ports it to gzboot and compiled with arm-gcc, some strange things happen.</div></div>
<div> </div>
<div>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, 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.
</div>
<div> </div>
<div>The same program has NOT any problems when compiled in the ADS IDE, no matter I declare the buffer as "char array" or "int array" (of cause with some algorithmic alteration).</div>
<div> </div>
<div>I know this problem is likely concerned with the type of the operands, but as far as I know, the armv4 architecture could access byte, half-word and word correctly. I think there must be a solution to avoid the complexity. Maybe some useful arm-gcc options must be specified I think ,
</div>
<div> </div>
<div>please help.</div>
<div> </div>
<div>Best regards</div>
<div>--danny </div>
------=_Part_17019_14749989.1149588786573--