On Tue, 5 Jul 2000, Eduardo Horvath wrote:
>
>On Wed, 5 Jul 2000, Michael Adda wrote:
>
> > On Tue, 4 Jul 2000, Eduardo Horvath wrote:
> > >
> > I am currently examining ctlreg.h but already I've seem to find an
> > anomaly. I am not sure that it have any implication on the kernel, 
>though.
> > I've taken the 32 bit variant of the macro ldda and altered it a bit.
> > I did it in order to examine register usage in the produced assembler 
>code.
> > ... text removed ...
> > Can you validate the phenomenon described above ?
>
>Hmm.  Interesting.  I'll need to look into this.
>
>ldd and ldda are deprecated on sparcv9.  Apparently, in addition to
>possible performance issues, ldda does not properly load data using
>little-endian accesses on UltraSPARC I and II processors; the endiannes in
>each register of the pair is reversed, but the data between the two
>registers is not swapped.  And AFAIK ldda is never used in sparc64
>kernels.  Therefore I think it makes sense to remove ldda completely.
>
First, I've updated my sources and found out that on 2000/06/24, you
(Eduardo) marked with #ifdef 0 all the macros.
I did notice the problem, however. It seem that _loc_hi, as well as
_pstate are declared as long long, which explains the produced
assembler code. I think that the code at line 1114 in file ctrlreg.h, which 
is :
        register long long _lda_v, _loc_hi, _pstate; \
should be changed into :
        register long long _lda_v;      \
	  register long _loc_hi, _pstate; \
Or even better, using _lda_v_hi and _lda_v_low, changing the function to
/* load 64-bit int from alternate address space */
static __inline__ u_int64_t
ldda(paddr_t loc, int asi)
{
        register long _lda_v_hi, _loc_hi, _lda_v_lo;


        _loc_hi = (((u_int64_t)loc)>>32);
        if (PHYS_ASI(asi)) {
        /* _lda_v_hi is used temporarily for pstate */
                __asm __volatile("wr %4,%%g0,%%asi; rdpr %%pstate,%1;"
" andn %2,0x1f,%0; rdpr %%pstate,%1; stxa %%g0,[%0] %5; wrpr %1,8,%%pstate;"
" sllx %3,32,%0; or %0,%2,%0; membar #Sync; ldda [%0]%%asi,%0; srlx 
%0,32,%1;"
" srl %0,0,%0; wrpr %1,0,%%pstate; andn %2,0x1f,%1; membar #Sync;"
" stxa %%g0,[%1] %5; membar #Sync" :
                                 "=&r" (_lda_v_lo), "=&r" (_lda_v_hi) :
                                 "r" ((unsigned long)(loc)), "r" (_loc_hi),
                                 "r" (asi), "n" (ASI_DCACHE_TAG));
        } else {
                __asm __volatile("wr %4,%%g0,%%asi; sllx %3,32,%0; "
" or %0,%2,%0; ldda [%0]%%asi,%0; srlx %0,32,%1; srl %0,0,%0;" :
                                 "=&r" (_lda_v_lo) , "=&r" (_lda_v_hi) :
                                 "r" ((unsigned long)(loc)), "r" (_loc_hi), 
"r" (asi));
        }
   	  return ((((int64_t)_lda_v_hi)<<32)|_lda_v_lo);
}
which is similar to the approach used in ldxa.

> > One more question. Is there any documentation about the reasons led
> > to using DCACHE_BUG in ctlreg.h (force flushing of the D$ line) ?
> > Is it a processor bug or something bogus is the netbsd kernel ?
>
>This is an interesting issue which finally seems to have been documented
>in the errata section of the UltraSPARC IIi manual.  The data cache
>uses virtual addresses but does not have any address space information in
>the tags, and apparently it will operate on MMU bypass accesses and use
>the physical address of the accesss, so if you use one of the bypass ASIs
>and there is a data cache hit you will get data from the data cache
>instead of the physical cache.  Conversly, the data cache may also cache
>writes using bypass ASIs.  Hence it is necessary to flush the cache line
>before and after all MMU bypass accesses.
>
Thanks. It is indeed documented in the manual.
I need to pay more attention to errata sections.

>Eduardo Horvath
>

Michael Adda


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com