Hmm. I see Microsoft has changed the layout of the .vcxproj file since MSVC2012.

In your project file I only found the following related to the assembler files:

  <ItemGroup>
    <None Include="..\..\..\..\Source\ThirdParty\AngelScript\Source\as_callfunc_arm_gcc.S" />
    <MASM Include="..\..\..\..\Source\ThirdParty\AngelScript\Source\as_callfunc_arm_msvc.asm">
      <FileType>Document</FileType>
    </MASM>
    <None Include="..\..\..\..\Source\ThirdParty\AngelScript\Source\as_callfunc_arm_xcode.S" />
    <MASM Include="..\..\..\..\Source\ThirdParty\AngelScript\Source\as_callfunc_x64_msvc_asm.asm">
      <FileType>Document</FileType>
    </MASM>
  </ItemGroup> 

But there is no information on how the files should be built, much less the fact that only the arm version should be included in the ARM build and only the x64 version should be included in the x64 build. Perhaps MSVC2013 stores this information somewhere else?

In the MSVC2012 project file I have it looks like this:

  <ItemGroup>
    <CustomBuild Include="..\..\source\as_callfunc_x64_msvc_asm.asm">
      <FileType>Document</FileType>
      <Command Condition="'$(Configuration)|$(Platform)'=='Release|x64'">ml64.exe /c  /nologo /Fo$(OutDir)as_callfunc_x64_msvc_asm.obj /W3 /Zi /Ta %(RootDir)%(Directory)\%(Filename)%(Extension)</Command>
      <Outputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(OutDir)as_callfunc_x64_msvc_asm.obj;%(Outputs)</Outputs>
      <Command Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">ml64.exe /c  /nologo /Fo$(OutDir)as_callfunc_x64_msvc_asm.obj /W3 /Zi /Ta %(RootDir)%(Directory)\%(Filename)%(Extension)</Command>
      <Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(OutDir)as_callfunc_x64_msvc_asm.obj;%(Outputs)</Outputs>
    </CustomBuild>
  </ItemGroup>

(of course, I don't have a WinRT target in my project yet, so there is no compilation step for the arm assembler file.)

Have you checked that the as_callfunc_arm_msvc.obj is actually generated somewhere when compiling the library? If so, in what directory is it being generated? If it is not generated, check what command MSVC is actually running when getting to the assembler files (the project settings should have an option to visualize the command line).

Hah, I forgot to read my own manual. I had already included instructions on how to compile the as_callfunc_arm_msvc.asm file there.

As far as I can tell armasm is still the tool that should be used to compile the as_callfunc_arm_msvc.arm file for WinRT/Windows Phone, so you need to include a custom build step with the proper command line for that tool.

NiteLordz and I have been exchanging e-mails on this topic. With his help I've been able to update AngelScript to allow it compile and link the library successfully for Windows Phone with ARM CPU. Unfortunately we've hit a roadblock on getting the native calling conventions to work properly.

I've investigated some of the disassemblies from the regression test suite and I can see that the Windows Phone 8 ARM ABI is not the same as what is already implemented in the library. Some of the things I see as different from the current implementation are: the assembler routines in as_callfunc_arm_msvc.asm doesn't guarantee 8 byte alignment on the callstack and the assembler routines are not using the floating point registers when passing or returning float values. There may be other differences too, but only testing will tell.

To get the native calling conventions fully working it would be necessary to adapt the code written for the Linux ARM with hard float ABI to work for MSVC too, and then run the test_features regression tests to make sure everything is working. Unfortunately it is not possible to test the native calling convention code with the Windows Phone emulator that comes with the SDK, so it requires a physical Windows Phone device to do that, which I do not have. So I'm not able to progress any further at the moment.

Is anyone with a Windows Phone 8 and a little skill with assembler (not much is really needed) interested in giving a hand in getting this to work?

Hi cmd.exe,

I would like to take a look at the changes you've done to incorporate them into the official repository. But unfortunately your link doesn't appear to be working.