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 * SUSPEND

1 21 * SetV1 v1, 0x1

3 21 * PshV4 v1

4 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

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.

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

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.

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:

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.

Andreas, there is one problem.

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.