Ah, yes. I forgot that you are not yet using native calling convention.
In this case you can just skip this test. A lot of the tests in the regression test suite haven't been prepared for MAX_PORTABILITY, most are skipped automatically but sometimes I haven't added the skip condition yet.
Compiling angelscript on ppc64
Author
func: void main()
mdle: test
sect: test
line: 4
This second problem is failing on the script statement "assert( b == 1 );", which is translated to the following bytecode sequence:
- 4,5 -0 21 * SUSPEND1 21 * SetV1 v1, 0x13 21 * PshV4 v14 22 * CALLSYS 150 (void assert(bool))You can find this in the debug output file AS_DEBUG/__main.txt right after compiling the script (if the library is compiled with the flag AS_DEBUG defined).Most like the problem is with the bytecode instruction asBC_SetV1 in as_context.cpp, which is not setting the byte in the correct position of the target DWORD. A similar problem would exist with SetV2 as well.
SetV[1,2,4] seem to be fine (regarding this test). The problem is the number being wrong in the bytecode itself.
ppc64 ppc64le
Set 0 [0] at 0x1002e480420[-1] | Set 0x1 [0x1] at 0x1002edf23c0[-1]
Push 0 [0] from 0x1002e480420[-1] | Push 0x1 [0x1] from 0x1002edf23c0[-1]
I saved the generated bytecodes to a file and this is the result:
ppc64 ppc64le
00000000: 0001 0666 6f6f 0400 0000 0400 0302 6100 ...foo........a. | 00000000: 0001 0666 6f6f 0400 0000 0400 0302 6100 ...foo........a.
00000010: 0000 0002 6200 0000 0102 6300 0000 0200 ....b.....c..... | 00000010: 0000 0002 6200 0000 0102 6300 0000 0200 ....b.....c.....
00000020: 0000 0003 6608 6d61 696e 0040 5000 0000 ....f.main.@P... | 00000020: 0000 0003 6608 6d61 696e 0040 5000 0000 ....f.main.@P...
00000030: 0100 0000 4107 3f8e 0100 0301 3d00 3fbd ....A.?.....=.?. | 00000030: 0100 0000 4107 3f8e 0101 0301 3d00 3fbd ....A.?.....=.?.
^ ^
Then the problem is in compiler itself.
There are only 2 places in the code where the compiler emits the instruction asBC_SetV1.
ctx->bc.InstrSHORT_B(asBC_SetV1, (short)offset, ctx->type.byteValue);
ctx->bc.InstrSHORT_B(asBC_SetV1, (short)offset, VALUE_OF_BOOLEAN_TRUE);
I'm guessing the problem is with the first, as ctx->type.byteValue is part of a union, and is thus most likely getting the byteValue from the wrong byte in the larger ctx->type.qwordValue.
In asCCompiler::CompileExpressionValue the union of which ctx->type.bytevalue is part of will be set using the method SetConstantDW, but in the above code the asCCompiler reads the constant directly from the union without taking care of endianess. I would suggest replacing any direct access to the union in the asCExprValue structure with appropriate Get methods that will take care of the endianess.
Author
After a long hiatus, I'm back with some results. The attached changes make the test pass until test_saveload. Note that it's not a patch, it just points out where the "faulty" parts possibly are.
With those changes, I get up to
Failed on line 499 in ../../source/test_saveload.cpp
Failed on line 516 in ../../source/test_saveload.cpp
config (49, 0) : Warning : Cannot register template callback without the actual implementation
Failed on line 611 in ../../source/test_saveload.cpp
and if I comment out the saveload test
Test on line 987 in ../../source/test_compiler.cpp skipped
--- Assert failed ---
func: void ExecuteString()
mdle: (null)
sect: ExecuteString
line: 1
---------------------
Failed on line 1216 in ../../source/test_compiler.cpp
--- Assert failed ---
func: void ExecuteString()
mdle: (null)
sect: ExecuteString
line: 1
---------------------
Failed on line 1237 in ../../source/test_compiler.cpp
Failed on line 1742 in ../../source/test_compiler.cpp
Test on line 1755 in ../../source/test_compiler.cpp skipped
Test on line 1792 in ../../source/test_compiler.cpp skipped
Failed on line 1851 in ../../source/test_compiler.cpp
Failed on line 1857 in ../../source/test_compiler.cpp
Test on line 2059 in ../../source/test_compiler.cpp skipped
Test on line 4564 in ../../source/test_compiler.cpp skipped
Test on line 4827 in ../../source/test_compiler.cpp skipped
--------------------------------------------
One of the tests failed, see details above.
I hope it helps.
Thanks for continuing this work. I was afraid you had given up, and moved on to other tasks. :)
I'll take a closer look at what you have provided now, and see if I can help identify what the next obstacle is.
Author
I was just busy with other stuff and it was hard to find the time to work on Angelscript.
So about the test_compiler.cpp failures, this is what the assembly code looks like:
void ExecuteString()
Temps: 2
Variables:
001: uint ui32
- 1,1 -
0 2 * SUSPEND
VarDecl 0
1 2 * SetV4 v1, 0x0 (i:0, f:0)
- 1,27 -
3 2 * SUSPEND
4 2 * CMPIu v1, -1
6 2 * TZ
7 2 * CpyRtoV4 v2
8 2 * PshV4 v2
9 3 * CALLSYS 19 (void assert(bool))
- 2,3 -
11 2 * SUSPEND
0:
12 2 * RET 0
So the problem is possibly in the SetV4 part when reading a dword from a saved qword. I tried a fix similar to what I did to SetV1, but them I broke test_pow :(
I've checked in the latest changes in revision 2328.
I didn't make the changes quite the same way you had, so please do let me know if something is not working on PPC64.
Author
Andreas, there is one problem.
--- Assert failed ---
func: void main()
mdle: test
sect: test
line: 11
---------------------
Failed on line 118 in ../../source/test_addon_dictionary.cpp
In that line, the assert is " assert( bool(dict['value']) == true ); \n"
In CScriptDictValue::Set we memcpy 'size' bytes to m_valueInt. So this happens:
-> Memcpying 8 bytes from 2a (from an fprintf I added)
But then, on CScriptDictValue::Get,
int size = engine->GetSizeOfPrimitiveType(typeId); // -> equals to 1.
When you memcmp one byte of 'm_valueInt' to 'zero', it does:
m_valueInt (big endian): 0x000000000000002a
zero: 0x0000000000000000
^ first byte
Notice that the first byte is 0 in both, so the comparison to 'zero' will return true.
If you change size to 8, the test passes successfully. However, from my printf I noticed sometimes only 4 bytes are memcpy'ed. That's why in my original patch I replaced this line with:
*(bool*)value = !!m_valueInt;
Using !!m_valueInt didn't work for me on MSVC. In some cases the 4 high bytes of m_valueInt were not initialized, causing the !!m_valueInt to return true even though the value should have been false.
I'll revisit this to see if I can figure out a better solution.
I had made a mistake in the Get function for retrieving a bool when the stored value was an int. To determine the size of the stored value I used typeId rather than m_typeId.
With the fix in revision 2329 it should be working.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
