See patch
Created attachment 46214 [details] The patch It was a hard task, but i think it's working now. Because i couldn't find any valuable information about the calling conventions an WinCE, i've done this via a kind of reverse engineering :-/ Since run-javascriptcore-tests isn't woking, i only wan't some feedback if this patch looks sane. I'll post a comment when i've run all the tests to ensure that i doesn't introduce a regression.
Comment on attachment 46214 [details] The patch I don't think it's right to be detecting wince based on the compiler, isn't there a PLATFORM(WINCE) ?
(In reply to comment #2) > I don't think it's right to be detecting wince based on the compiler, isn't > there a PLATFORM(WINCE) ? Yes, but all other ifdefs are COMPILER(XY) too. So the other COMPILER(MSVC) should be changed to OS(WIN)? But anyway, can you give me feedback about my implementation? Does it look sane?
Created attachment 47424 [details] The patch changed COMPILER(MSVC) to OS(WINCE)
Patch seems OK for me. However, the patch supports only JSvalue32. We plan to enable JSValue32_64 support for ARM (as 75% voted for it). The NATIVE call support for this mode started from line 252 in the very same file (JITOpcodes.cpp). Could you add WinCE support for this mode as well?
Created attachment 49128 [details] The patch (added JSVALUE32_64) Sorry for the long delay. It was like reverse engineering again.
> Sorry for the long delay. > It was like reverse engineering again. GCC is no better. The patch looks good to me. (but I am not a reviewer)
Comment on attachment 49128 [details] The patch (added JSVALUE32_64) Looks non-harmful. rs=me.
Comment on attachment 49128 [details] The patch (added JSVALUE32_64) Clearing flags on attachment: 49128 Committed r55615: <http://trac.webkit.org/changeset/55615>
All reviewed patches have been landed. Closing bug.