------=_Part_9808_20012472.1149663240705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thank you above two for your advices.

 I think the declaration of the LCD_BUFFER does not really care in this
case. Please let me have a short explanation. The panel engaged in is a
240*320 pixels and 16Bpp LCD panel, 16Bpp(16 Bit per pixel) means that a
pixel is representated by a half-word variable. So for the data-bus length
and the storage space, I use one "uint32" to representate two pixels. The
meaning of the expression "240>>1" is to get how many double-pixels in a
single lcd line, and "320*3" is for how many rows the virtual buffer is.
Finally, as I had said I had implemented this function in the ADS1.2, and it
runs well.

Another example for this problem is that the internel library function
sys/lib/libsa/sub_prf.c:kprintn() is also raise an error when I add my
own code into the gzboot. I had to trace the machine code, and I find that
the problem is also concered with data buffer, this time it is a character
string: *p++ = "1234567890abcdef"[ul % base]; in that lib function. The MCU
cann't get correct byte-data and raise an Undefine instruction error. That's
very confused me because I doesn't modify any library code, but when I merge
my own code into the gzboot, this error arised!

Please help me! I have no idea about this abnormal error, that's beyond my
knowledge scope.

in 6/7/06, Toru Nishimura <locore64@alkyltechnology.com> wrote:

> Danny Lau said;
>
> > a large continuously "unsigned int"
> > memory array. I declare it as this: unsigned int
> LCD_BUFFER[320*3][240<<1].
>
> As already pointed, it's rather obscure programming practice; easy to make
> mistake(s) for both human being and machine.  It seems 240*320@16bpp does
> not make any match.  Better to pursue simpler constructs to do the same
> thing.
>
> Have you tried to omit GCC optimization flag (-O?) for that file in
> question if
> exists?  -O flag triggers code optimizer to use aggressively "smart
> instructions"
> or "insn reorder and collapse to save time and space."  This often means
> to
> bring processor dependent extension out of stock which is less commonly
> used.
> If compiler misunderstands the nature of target CPU, optimization ends up
> with
> incorrect instruction.
>
> Toru Nishimura/ALKYL Technology
>

------=_Part_9808_20012472.1149663240705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Thank you above two for your advices.</div>
<div>&nbsp;</div>
<div>&nbsp;I think the declaration of the LCD_BUFFER does not really care in this case. Please let me have a short explanation. The panel engaged in is a 240*320 pixels and 16Bpp LCD panel, 16Bpp(16 Bit per pixel) means that a pixel is representated by a half-word variable. So for the data-bus length and the storage space, I use&nbsp;one &quot;uint32&quot;&nbsp;to representate&nbsp;two pixels. The meaning of the expression&nbsp;&quot;240&gt;&gt;1&quot; is to get how many double-pixels in a single lcd line, and &quot;320*3&quot; is for how&nbsp;many rows&nbsp;the virtual buffer is. 
</div>
<div>Finally, as I had said I had implemented this function&nbsp;in the ADS1.2, and it runs well. </div>
<div>&nbsp;</div>
<div>Another example for this problem is that the internel&nbsp;library function sys/lib/libsa/sub_prf.c:kprintn()&nbsp;is also raise an error when I add&nbsp;my own&nbsp;code into the gzboot. I had to trace the machine code, and I find that the problem is also concered with data buffer, this time it is a character string: *p++ = &quot;1234567890abcdef&quot;[ul % base]; in that lib function. The&nbsp;MCU cann't get correct byte-data and raise an Undefine instruction error. That's very confused me because I doesn't modify any library code, but&nbsp;when I&nbsp;merge my own code into the gzboot, this&nbsp;error arised!&nbsp;
</div>
<div>&nbsp;</div>
<div>Please help me! I have no idea about this abnormal error, that's beyond my knowledge scope.<br>&nbsp;</div><span class="gmail_quote"></span>
<div><span class="gmail_quote">in 6/7/06, <b class="gmail_sendername">Toru Nishimura</b> &lt;<a href="mailto:locore64@alkyltechnology.com">locore64@alkyltechnology.com</a>&gt; wrote:</span></div>
<div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Danny Lau said;<br><br>&gt; a large continuously &quot;unsigned int&quot;<br>&gt; memory array. I declare it as this: unsigned int LCD_BUFFER[320*3][240&lt;&lt;1].
<br><br>As already pointed, it's rather obscure programming practice; easy to make<br>mistake(s) for both human being and machine.&nbsp;&nbsp;It seems 240*320@16bpp does<br>not make any match.&nbsp;&nbsp;Better to pursue simpler constructs to do the same thing.
<br><br>Have you tried to omit GCC optimization flag (-O?) for that file in question if<br>exists?&nbsp;&nbsp;-O flag triggers code optimizer to use aggressively &quot;smart instructions&quot;<br>or &quot;insn reorder and collapse to save time and space.&quot;&nbsp;&nbsp;This often means to
<br>bring processor dependent extension out of stock which is less commonly used.<br>If compiler misunderstands the nature of target CPU, optimization ends up with<br>incorrect instruction.<br><br>Toru Nishimura/ALKYL Technology
<br></blockquote></div><br>

------=_Part_9808_20012472.1149663240705--