After spend two days, I fix the issue below: I misunderstood v4int_l instruction, so cause this issue.
At present, I met mf (memory fence), I guess, we can just skip it, but I am not quite sure, welcome any ideas, suggestions and completions for it. And I almost re-constructed the code (it doesn't change quite much), if suitable, I shall try to send patches to upstream for reviewing. Welcome any ideas, suggestions and completions for it. Thanks. On 5/2/15 12:09, Chen Gang wrote: > Hello all: > > At present, I met an issue (I guess, it should be my code bug), I am > analyzing it which may spend quite a few time resources (checking and > reconstructing the code is helpful for analyzing this issue): > > - It is about invalid memory access for ld operation. The related > tilegx code is "ld r48, r12", the related x86_64 code is > "mov (%rbx),%rbx". > > - The related invalid address is 0x128020 which is near (but a little > upper) tilegx rsp. > > - I have ways for analyzing it: we have the related libc source code, > and the working flow is not quite complex. But it really needs to > spend me quite a few time resources on it. > > At present, for me, I plan to send the reconstructed code to upstream > within 2 days, and continue analyzing (so that other members can also > have a check), but I am not quite sure whether it is suitable. > > Welcome any ideas, suggestions and completions. > > Thanks. > > On 5/2/15 10:42, Chen Gang wrote: >> >> >> On 4/29/15 21:32, Chen Gang wrote: >>> On 4/29/15 05:43, Peter Maydell wrote: >>>> On 28 April 2015 at 22:32, Chen Gang <xili_gchen_5...@hotmail.com> wrote: >>>>> The related information for cmpexch instruction: >>>>> >>>>> Description >>>>> >>>>> Compare the 8-byte contents of the CmpValue SPR with the 8-byte >>>>> value in memory at the address held in the first source register. If >>>>> the values are not equal, then no memory operation is performed. If >>>>> the values are equal, the 8-byte quantity from the second source >>>>> register is written into memory at the address held in the first >>>>> source register. In either case, the result of the instruc- tion is >>>>> the value read from memory. The compare and write to memory are >>>>> atomic and thus can be used for synchronization purposes. This >>>>> instruction only operates for addresses aligned to a 8-byte boundary. >>>>> Unaligned memory access causes an Unaligned Data Reference interrupt. >>>> >>>> I suggest you look at how existing CPUs handle this kind of >>>> atomic operation. >>>> >> >> I finished cmpexch(), referenced to store_exclusive() in arm and alpha. >> Hope what I have done is correct (I guess, it should be). >> >> - Save information about cmpexch (add additional variable in CPUState). >> >> - Generate an exception for it. >> >> - Process the related exception in main.c with start/end_exclusive() >> just like what alpha or arm has done. >> >> >> Thanks. >> >>> OK, thanks. >>> >> >> >>>> I also suggest you stop adding implementations of *new* instructions >>>> and concentrate on getting a basic set into shape for inclusion. >>>> The more stuff you keep adding the bigger your patchset is going >>>> to get and the harder it is going to get to review. >>>> >> >> Reconstruction the code is really very useful, cmp*, shl?add*, V?int_?. >> That will not only simplify reading, but also speed up coding. >> >> Thank you for your valuable suggestions again. >> >>> >>> For me, current code is not quite much, and really easy enough. At >>> present I am still going smoothly (the issues are mainly about >>> understanding new instructions which I shall meet). >>> >>> I still want to reach "display hello world" successfully (it does not >>> seem quite difficult to me), then reconstruct current code, and send >>> patch to upstream. >>> >>> But sorry, it seems I can not finish it within this month (and I shall >>> try to finish within next month). >>> >>> >>> Thanks. >>> >> > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed