------=_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>&nbsp;</div>
<div>I am&nbsp;rewiting gzboot to let&nbsp;messages be dumped to the LCD&nbsp;panel rather than&nbsp;the COM port,and&nbsp;the arm--netbsdelf-gcc&nbsp;is generated by command &quot;build.sh -m evbarm tools&quot;.&nbsp;For some reasons,&nbsp;I feel that the compiler cann't output&nbsp;correct binary code.&nbsp;
</div>
<div>&nbsp;</div>
<div>The LCD panel is a 240*320, 16Bpp&nbsp;one. So, a large memory buffer was engaged&nbsp;in as a framebuffer, that is a large continuously &quot;unsigned int&quot; memory array. I declare it as this: unsigned int LCD_BUFFER[320*3][240&lt;&lt;1].
</div>
<div>
<div>&nbsp;</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>&nbsp;</div>
<div>The chip(s3c2410) will&nbsp;raise&nbsp;an &quot;Undefine instruction&quot; exception(run time) when I use &quot;array operator&quot; to iterate the buffer items, like LCD_BUFFER[y][x] = color, and&nbsp;preform well when I use &quot;pointer operator&quot; to get access the items, like *(LCD_BUFFER+y+x) = color; For some other buffer, like strings,&nbsp;the situation is totally reversed.
</div>
<div>&nbsp;</div>
<div>The same program has NOT any problems when compiled in the&nbsp;ADS IDE, no matter I declare the buffer as &quot;char array&quot; or &quot;int array&quot; (of cause with&nbsp;some algorithmic alteration).</div>
<div>&nbsp;</div>
<div>I know this problem is likely concerned with the&nbsp;type of the operands, but as far as I&nbsp;know, the&nbsp;armv4 architecture could access&nbsp;byte,&nbsp;half-word and&nbsp;word correctly.&nbsp;I think there must be a solution to avoid the complexity. Maybe&nbsp;some&nbsp;useful&nbsp;arm-gcc options must be specified&nbsp;I think ,
</div>
<div>&nbsp;</div>
<div>please help.</div>
<div>&nbsp;</div>
<div>Best regards</div>
<div>--danny&nbsp;</div>

------=_Part_17019_14749989.1149588786573--