Re: [Qemu-devel] Re: target-sparc/TODO

[Artyom Tarasenko]

2009/8/22 Robert Reif <address@hidden>:
> Artyom Tarasenko wrote:
>>
>> 2009/8/22 Blue Swirl <address@hidden>:
>>
>>>
>>> On Sat, Aug 22, 2009 at 12:01 AM, Artyom
>>> Tarasenko<address@hidden> wrote:
>>>
>>>>
>>>> 2009/8/21 Blue Swirl <address@hidden>:
>>>>
>>>>>
>>>>> On Fri, Aug 21, 2009 at 3:40 PM, Artyom
>>>>> Tarasenko<address@hidden> wrote:
>>>>>
>>>>>>
>>>>>> 2009/8/21 Artyom Tarasenko <address@hidden>:
>>>>>>
>>>>>>>
>>>>>>> 2009/8/20 Blue Swirl <address@hidden>:
>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Aug 20, 2009 at 12:44 PM, Artyom
>>>>>>>> Tarasenko<address@hidden> wrote:
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Particularly I'm interested if
>>>>>>>>>>>
>>>>>>>>>>> jmp     %l1, %g4, %g0
>>>>>>>>>>>
>>>>>>>>>>> may behave other than on a real hw.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No, if rd is %g0, the current PC will not be written anywhere (not
>>>>>>>>>> by
>>>>>>>>>> real HW either).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The reason I asked is the two following pieces of code work
>>>>>>>>> differently on a real and emulated SS-5. On a real one spacel! does
>>>>>>>>> an
>>>>>>>>> asi write, and spacel@ does an asi read, and under qemu  spacel!
>>>>>>>>> seems
>>>>>>>>> to do nothing, and spacel@ returns its second parameter multiplied
>>>>>>>>> by
>>>>>>>>> 4. Both of them don't even try to call an [unimplemented] asi
>>>>>>>>> operation, I've runned the tests with mmu and asi debug turned on.
>>>>>>>>>
>>>>>>>>> Real SS-5:
>>>>>>>>>
>>>>>>>>> ok 0 0 spacel@ .
>>>>>>>>> Data Access Error
>>>>>>>>> ok 0 20 spacel@ .
>>>>>>>>> 0
>>>>>>>>> ok 12345678 0 20 spacel!
>>>>>>>>> ok 0 20 spacel@ .
>>>>>>>>> 12345678
>>>>>>>>> ok
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> qemu SS-5:
>>>>>>>>>
>>>>>>>>> ok 0 0 spacel@ .
>>>>>>>>> 0
>>>>>>>>> ok 0 20 spacel@ .
>>>>>>>>> 80
>>>>>>>>> ok 12345678 0 20 spacel!
>>>>>>>>> ok 0 20 spacel@ .
>>>>>>>>> 80
>>>>>>>>> ok
>>>>>>>>>
>>>>>>>>> I don't know sparc asm good enogh, but qemu behavior seems to be
>>>>>>>>> logical: in the first case I see no store op, and there are shifts
>>>>>>>>> which would multiply by 4:
>>>>>>>>>
>>>>>>>>> ok see spacel!
>>>>>>>>> code spacel!
>>>>>>>>> ffd26e0c     ld      [%g7], %l2
>>>>>>>>> ffd26e10     add     %g7, 4, %g7
>>>>>>>>> ffd26e14     ld      [%g7], %l0
>>>>>>>>> ffd26e18     add     %g7, 4, %g7
>>>>>>>>> ffd26e1c     sll     %g4, 2, %g4
>>>>>>>>> ffd26e20     call    ffd26e24
>>>>>>>>> ffd26e24     add     %g0, 14, %l1
>>>>>>>>>
>>>>>>>>> ok ffd26e24 dis
>>>>>>>>> ffd26e24     add     %g0, 14, %l1
>>>>>>>>> ffd26e28     add     %o7, %l1, %l1
>>>>>>>>> ffd26e2c     jmp     %l1, %g4, %g0
>>>>>>>>> ffd26e30     ba      ffd26f68
>>>>>>>>> ok
>>>>>>>>>
>>>>>>>>> ok see spacel@
>>>>>>>>> code spacel@
>>>>>>>>> ffd26830     ld      [%g7], %l0
>>>>>>>>> ffd26834     add     %g7, 4, %g7
>>>>>>>>> ffd26838     sll     %g4, 2, %g4
>>>>>>>>> ffd2683c     call    ffd26840
>>>>>>>>> ffd26840     add     %g0, 14, %l1
>>>>>>>>>
>>>>>>>>> ok ffd26840 dis
>>>>>>>>> ffd26840     add     %g0, 14, %l1
>>>>>>>>> ffd26844     add     %o7, %l1, %l1
>>>>>>>>> ffd26848     jmp     %l1, %g4, %g0
>>>>>>>>> ffd2684c     ba      ffd26984
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The code is identical on a real and emulated SS.
>>>>>>>>>
>>>>>>>>> It must be the jump, which jumps differently on a real hw and under
>>>>>>>>> qemu. Do you see from the code where the jump would jump to, or
>>>>>>>>> maybe
>>>>>>>>> you have a suggestion how to check where the jump jumps to on the
>>>>>>>>> real
>>>>>>>>> hw?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The target of the call instruction is also a delay slot instruction
>>>>>>>> for the call itself. Maybe this case is not handled correctly?
>>>>>>>>
>>>>>>>
>>>>>>> Good idea! Don't know how to test it though.
>>>>>>>
>>>>>>> And what about "ba" in the delay slot of "jmp"? Is the correct
>>>>>>> behavior described somewhere? Would jump just be ignored? Whould it
>>>>>>> execute one instruction on jump destination and then branch? Would
>>>>>>> branch be ignored?
>>>>>>>
>>>>>>
>>>>>> Page 55 of The SPARC v8 Architecture Manual
>>>>>> (http://www.sparc.org/standards/V8.pdf) describes this case
>>>>>> explicitly:
>>>>>> cpu should execute one instruction on the jump target and then branch.
>>>>>>  Is it what qemu currently does?
>>>>>>
>>>>>
>>>>> I may be blind, I don't see the description of this case in that page.
>>>>>
>>>>
>>>> I wasn't referring the call case, but jmp+ba case (two last ops in the
>>>> listing above). This DCTI is described on pages marked 55-56 (pages
>>>> 54-54 in a pdf reader). That's the first case in the table 5-12.
>>>>
>>>>
>>>>>
>>>>> Both QEMU and real (Sparc64) hardware exit with return value of 3, so
>>>>> the inc is re-executed. If I add a nop in the call delay slot, the
>>>>> return value is 2.
>>>>>
>>>>
>>>> Can you make a similar test, but with ba in the jmp's delay slot?
>>>>
>>>
>>> Now, we have found a bug!
>>>
>>
>> Looks better now!
>>
>> Probing Memory Bank #0 64 Megabytes of DRAM
>> Probing Memory Bank #1 64 Megabytes of DRAM
>> Probing Memory Bank #2 64 Megabytes of DRAM
>> Probing Memory Bank #3 64 Megabytes of DRAM
>> Probing Memory Bank #4 Data Access Error
>> ok
>>
>> Used to be "Nothing there". What is a bit surprising, is that only 256
>> Mib found when started with -m 512. May be a next bug, this time in
>> ASI.
>>
>> With -m 128 :
>> Probing Memory Bank #0 64 Megabytes of DRAM
>> Probing Memory Bank #1 64 Megabytes of DRAM
>> Probing Memory Bank #2 Nothing there
>> Probing Memory Bank #3 Nothing there
>> Probing Memory Bank #4 Data Access Error
>> ok
>>
>>
>>
>>
>
> Here is a very old patch for the eccmemctl that fixes a bug
> I found while trying to fix the memory probing problem
> that is now fixed.
>
>
> diff --git a/hw/eccmemctl.c b/hw/eccmemctl.c
> index 28519c8..b2bff98 100644
> --- a/hw/eccmemctl.c
> +++ b/hw/eccmemctl.c
> @@ -301,10 +301,11 @@ static void ecc_reset(void *opaque)
>
>     if (s->version == ECC_MCC)
>         s->regs[ECC_MER] &= ECC_MER_REU;
> -    else
> -        s->regs[ECC_MER] &= (ECC_MER_VER | ECC_MER_IMPL | ECC_MER_MRR |
> -                             ECC_MER_DCI);
> -    s->regs[ECC_MDR] = 0x20;
> +    else {
> +        s->regs[ECC_MER] &= (ECC_MER_VER | ECC_MER_IMPL | ECC_MER_DCI);
> +        s->regs[ECC_MER] |= ECC_MER_MRR;
> +    }
> +    s->regs[ECC_MDR] = 0x40;
>     s->regs[ECC_MFSR] = 0;
>     s->regs[ECC_VCR] = 0;
>     s->regs[ECC_MFAR0] = 0x07c00000;
>

The piece of code is still there, but the patch makes no visible
effect on SS-5, 10 and 20:

Probing Memory Bank #0 64 Megabytes of DRAM
...
Probing Memory Bank #3 64 Megabytes of DRAM
Probing Memory Bank #4 Data Access Error
ok

Do you remember, for which machine/OBP was it intended?