I did all this with mono-sgen -v -v hello.exe disassmble of ppc http://pastebin.com/tzwF7pvz
disassmble of Intel http://pastebin.com/vwnpp3Cq Looks like the real PPC instruction that is being used to convert from float to int is 'fctiwz'. I see only one occurrence of 'fctiwz'. Is there a way to do inline disassembly like 'objdump -S'? On intel disassembly, I see reference to cvttsd2si twice which is a good thing. Thanks, Mukund J On Tue, Oct 11, 2016 at 12:40 PM, M Jam <[email protected]> wrote: > > Thanks for your responses. > I have to learn PPC instruction set now. > > code > http://pastebin.com/wRgB1JuU > > Intel MIR Code: > http://pastebin.com/bcbbe9mk > > PPC MIR Code: > http://pastebin.com/gNnrtAtk > > > Please notice Line 53 of 'PPC MIR Code' is different from Line 26 of > 'Intel MIR Code'. > > Looks like in mono, the jit flow is this: IL -> IR -> machine code. > emit_float_to_int -> is called when the JIT does IR -> machine code. Right? > If so, is there a know good practice to pause execution @ this level? > > As per the documentation, I see a lot of other places this can happen > - marshalling, call conventions, trampoline. > Any thought on these areas being suspects. > > M Jam > > > > > > On Mon, Oct 10, 2016 at 2:17 PM, Taloth Saldono <[email protected]> > wrote: > >> Hey M Jam, >> >> I'm an app developer and our users tend to try run our software on any >> device imaginable. (Yes, ppl asked if they could run it on Nvidia Shield... >> 3 days after it came out) >> We first ran into the issue when some users over at synocommunity tried >> to port the app to synology devices based on QorIQ. It was crashing >> constantly (iirc, time and date calculations were messed up). After some >> dummy test apps (with inexplicable results) I finally had the user run >> those regression tests and, voila, a lightbulb went on. >> However, I never fixed actually it. I neither had access to a device, >> time nor the inclination to dive into a mono port for that platform. I >> basically dumped a message about it in the synocommunity thread explaining >> the issue, and emphasized that any dev attempting to fix it would need a >> little bit of know-how and a couple of weekends. >> >> As for the cpu datasheet, basically yes, to find out which instructions >> can be used for the cast. So you can lookup the exact instructions that >> `emit_float_to_int` generates and see if they're valid. Possibly you can >> come up with an alternative set of instructions that succeeds on your >> device. >> Based on what you said, you should check the unsigned instructions in the >> datasheet against the `emit_float_to_int` method, you can see it uses >> CLRLDI/RLDICL for unsigned and EXTSW for signed. >> >> If CLRLDI/RLDICL isn't valid for your CPU, then OP_ZEXT_I4 likely gets >> processed incorrectly as well. >> Just an educated guess, I haven't actually checked what the rldicl and >> extsw instructions do exactly. You'll have to start pulling that thread and >> see where it leads. >> >> Lemme know how it goes. (btw. Welcome down the rabbit hole) >> >> Taloth >> >> >> >> On Mon, Oct 10, 2016 at 10:32 PM, M Jam <[email protected]> wrote: >> >>> Hi Taloth, >>> >>> Sorry, I have overlooked this message by mistake. Thanks for your >>> response. >>> >>> The is the exact issue we have. We don't have this issue for real PPC 64 >>> QorIQ processors i.e. T1040 >>> But we have this issue on P1020 processors which is 32-bit processors. >>> >>> I did the regression tests and this is what they look like. >>> http://pastebin.com/5RjxxDdY >>> >>> When you ran into this issue, how did you work around? Did you end up >>> finding a fix? >>> >>> I did try and put a break point at OP_FCONV_TO_I4 in mini-ppc.c and it >>> was never getting hit. It could as well be my GDB. not sure. >>> >>> I am new to mono project. The documentations is wild and big for me to >>> go though. Even then I tried and I am little clueless on >>> how this whole things is tied together. So, not sure how to debug this. >>> >>> Anyways, I see 2 cases being handled. >>> Thought I am not sure if this is real code that's >>> A type case of unit does NOT work while typecast of int works fine. >>> >>> The switch case >>> case OP_FCONV_TO_I4: >>> <<<<< this is one that's fine. >>> case OP_FCONV_TO_I: >>> code = emit_float_to_int (cfg, code, ins->dreg, >>> ins->sreg1, 4, TRUE); >>> break; >>> case OP_FCONV_TO_U4: >>> <<<<<< this is the one that fails >>> case OP_FCONV_TO_U: >>> code = emit_float_to_int (cfg, code, ins->dreg, >>> ins->sreg1, 4, FALSE); >>> >>> > But I recommend you get those regression tests compiled first, and >>> then lookup your CPU datasheet to find out what instruction set it supports. >>> You mean, what instruction set it supported to convert from FLOAT to >>> UNIT? >>> >>> Thanks, >>> M Jam >>> >>> On Fri, Sep 16, 2016 at 3:21 PM, Taloth Saldono <[email protected] >>> > wrote: >>> >>>> Hey M Jam, >>>> >>>> I'm not involved in PPC or mono development at all, but I've seen a >>>> similar case over 2 years ago, that was on a Qoriq-based Synology NAS. For >>>> that device it was that the mono jitter emitted powerpc extended 64-bit >>>> instructions which were unsupported by that specific CPU. But of course I >>>> don't know if it's related to your issue, also, there have been changes to >>>> the ppc jitter since then. >>>> >>>> Running the mono basic regression tests was particularly telling, you >>>> could see all the specific cases going wrong. ( >>>> https://github.com/mono/mono/blob/mono-3.10.0-branch/mono/m >>>> ini/Makefile.am.in#L438-L458) >>>> >>>> The Jitter for PPC is here: https://github.com/mono/ >>>> mono/blob/mono-3.10.0-branch/mono/mini/mini-ppc.c >>>> search for OP_FCONV_TO_I4. >>>> But I recommend you get those regression tests compiled first, and then >>>> lookup your CPU datasheet to find out what instruction set it supports. >>>> >>>> Cheers, >>>> >>>> Taloth >>>> >>>> >>>> On Fri, Sep 16, 2016 at 11:45 PM, M Jam <[email protected]> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying to get mono working on ppc. >>>>> Apparently, on one else is using it. even debian. >>>>> >>>>> I did a lot of debugging and finally at a point where I know the >>>>> problem is in mono runtime. >>>>> The even generated the CIL code on both x86 and ppc and compared them. >>>>> They are exactly identical. >>>>> >>>>> problem area is as simple as this: >>>>> >>>>> int x = (int) 2.0 >>>>> If I print x, I get 0. >>>>> >>>>> other broken things: Also math.ceiling() is broken and may be more >>>>> are broken. >>>>> >>>>> >>>>> At this point, I am not sure what is the best route to debug other >>>>> than disassembling the code for which I need some preparation as I don't >>>>> has 'as' and 'ld' on my ppc platform. >>>>> I need to build them. >>>>> >>>>> In the mean time, if anyone has an advice on debugging this issue, I >>>>> highly appreciate it. >>>>> >>>>> Also, lastly CIL code between a cast of int and uint is >>>>> < IL_0015: conv.i4 >>>>> --- >>>>> > IL_0015: conv.u4 >>>>> >>>>> Where is it in the JIT this code gets handled. >>>>> >>>>> Thanks, >>>>> M Jam >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mono-devel-list mailing list >>>>> [email protected] >>>>> http://lists.dot.net/mailman/listinfo/mono-devel-list >>>>> >>>>> >>>> >>> >> >
_______________________________________________ Mono-devel-list mailing list [email protected] http://lists.dot.net/mailman/listinfo/mono-devel-list
