[Mono-dev] mono on PPC - casting issue
mjam.mono at gmail.com
Tue Oct 11 19:40:59 UTC 2016
Thanks for your responses.
I have to learn PPC instruction set now.
Intel MIR Code:
PPC MIR Code:
Please notice Line 53 of 'PPC MIR Code' is different from Line 26 of 'Intel
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.
On Mon, Oct 10, 2016 at 2:17 PM, Taloth Saldono <talothsaldono at gmail.com>
> 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
> 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)
> On Mon, Oct 10, 2016 at 10:32 PM, M Jam <mjam.mono at gmail.com> wrote:
>> Hi Taloth,
>> Sorry, I have overlooked this message by mistake. Thanks for your
>> 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.
>> 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);
>> 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
>> M Jam
>> On Fri, Sep 16, 2016 at 3:21 PM, Taloth Saldono <talothsaldono at gmail.com>
>>> 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. (
>>> The Jitter for PPC is here: https://github.com/mono/
>>> 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.
>>> On Fri, Sep 16, 2016 at 11:45 PM, M Jam <mjam.mono at gmail.com> 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
>>>> 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.
>>>> M Jam
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at lists.dot.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list