For now I'm just happy to get the library fully working on PPC.

Later on I, or someone else, can work on getting the on-disk representation of the bytecode endian independent. Actually it would be great if the on-disk representation could be equal for 32bit and 64bit code as well.

I believe you made the right choice with the adjustments that you've made. By doing it this way instead of with shifts and maskings the code should be equally efficient on PPC and hopefully there will not be too much work to get it fully working.

When I get the time (hopefully today) I'll help you with some tests and will hopefully be able to fix at least a couple of the remaining problems.

Thanks for the tips on SVN as well. Unfortunately SourceForge.net doesn't expose the svn:eol-style property so I can't use it. But I'll try to be more careful about the line endings in future check-ins. I'll also see if I can convince the SF.net staff to include it. (Or am I mistaken and this is a setting on the SVN client?)

Regards,
Andreas

svn:eol-style (and all properties) are settings done by the client ON the files.
so, you would do the following (command line) in the angelcode/source directory

svn propset svn:eol-style native *.cpp *.h

And that would set the svn:eol-tyle property to native on all of the source files in the directory. Make sure they are consistently CR-LF on your windows system before committing though. Then when I update my end, the svn client will know that "this is a text file, so when I check it out I'll put just a LF at the end of each line, as that's the unix standard"
This is similar to the -K setting you specified on files in CVS to specify which were binary and which were text. Just done a LOT cleaner.

read the svn book about properties, there's several more including how you set the ignore property on directories (the replacement for .cvsignore from CVS)

http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html

the top half is about how properties work, then under "Special Properties" explains the svn: prefixed properties that the Subversion client itself pays attention to.

Thanks for the explanation. I'll do this a.s.a.p.

I've submitted the changes that you've made so far to the repository.

I also set the svn:eol-style to native on the source files as you suggested.

Still working through the tests..

I have been just disabling some test as I go through and get the simpler ones working.. The following tests are ones that currently aren't working.

TestCaseOp
TestSinlgeton
TestAny
TestInterface
TestScriptStruct
TestScriptString
TestRefArgument
TestSuspend

Currently I am going through TestConversion and fixing instructions as I go. I also had to go through all the tests and remove their private Assert() implementations and make sure they were all using the GENERIC call version of the Assert in utils.cpp.

OK.. for the Conversions I've run into a nice snag that looks like a problem with the building of the instructions.

test_conversion.cpp line 354 (this is after removing the local Assert function)
d = 12.3; engine->ExecuteString(0, "i8 = int8(d);"); if( i8 != 12 ) fail = true;

the generated sequence of byte code (pertenant sequence that is) is.

dTOi 3 2
LDG 6
WRTV1 3

which dTOi correctly converts the double to the integer and stores it in the l_fp

the LDG is correctly pulling the address of the int8 global variable into register1

Now, the choice of WRTV1 is where it all blows up. and I'm not sure how the *correct* way of fixing this is.. Either change the instructions being used OR change the WRTV1 instruction.
This decoding of the DWORD stored in l_fp - 3 (in big endian is 00 00 00 0c and little 0c 00 00 00)

*(asBYTE*)(l_fp - SWORDARG0(l_bc));

is causing the Low memory byte to be sent over to i8 (which in big endian is 00)
where it should be either pulling the full dword and just casting it to an int8 or a different instruction used.

Actually the TestCaseOp is probably working, it is just reporting some errors for an unfinished feature. You can safely ignore these ;)

Can you send me the files you changed or upload a zip to your site? I prefer to receive the whole files, so that I can do a merge with WinMerge. I know I can use the diff output to patch my code, but I prefer to do it using WinMerge so that I can easier study the changes while I apply them.

I've been thinking about the problem you stated. There are two solutions as I can see it:

1) Create a bytecode for conversion from 4 byte int to 1 byte int, and then have the compiler insert this in appropriate places. A conversion from 1 byte to 4 byte would also be needed. Internally AngelScript always treats integers as 4 bytes, so the conversions should probably only be needed when reading and writing bytes to variables. On little endian systems this bytecode can be removed by the optimizer.

2) We can also change WRTV1 (and similar bytecodes) to automatically read the high byte from the stack, instead of the low byte. This would in effect be the same as the option 1 but without an extra byte code. You probably have to do the same for RD1, and also change the way BC_sbTOi and BC_ubTOi works. Obviously the code would be different for these so a preprocessor flag would be needed (I already created the AS_BIG_ENDIAN flag for this purpose).

I'm obviously not sure either of these will work, but testing option 2 shouldn't be too difficult.

You say you fixed TestSwitch. I was wondering what approach you took to fix the byte code CMPu when it is comparing an uint8 with an uint? As it were the comparison cannot be made directly, so I'm guessing you changed the way uint8 is stored on the stack. Am I right?

We need to solve the WRTV1 problem the same way. Or perhaps the way you solved the other has to be changed again.

Also, I fixed the TestSingleton. It is not a problem with the library. The test was just not prepared for AS_MAX_PORTABILITY. You can safely ignore this test as well.

I'm thinking that I need to rethink the way the compiler handles 8bit and 16bit variables so that the bytecode doesn't make any assumptions on the memory layout.

I figure most of the code is working now. Probably the only problem now is the way the virtual machine handles 8bit and 16bit values. What is needed is to properly convert between these types as they are not compatible with 32bit types as they are on little endian CPUs.

I've added several comments in the code that shows what needs to be modified to make this work correctly. You can identify these lines by searching for '// TODO: PPC:'. The comments are in the SVN.

If I get the time this weekend I'll get started on the actual changes. But if you want you can also give it a go. In either case I would appreciate your comments on the planned changes if you get the time to take a look on it.

Regards,
Andreas

I just got back from a camping trip this weekend. I'll update my SVN WC and look through your comments and start implementing and testing the ideas in your posts and see where I get.
I'll try to get a zip of the code up on my site later tonight or tomorrow. (have some other work I have to tend to first tonight that shouldn't take TOO long....)

Thanks for all of your help so far.

I've uploaded my updated code.

http://www.outoforder.cc/downloads/patches/PPCFix2.diff (just the diff from SVN)
http://www.outoforder.cc/downloads/patches/angelscript-2006-10-08.zip (full export from SVN w/ my changes)

I now have tests working down to TestReturn (current one that doesn't work) skipping TestAny, Testinterface, TestScriptStruct, TestScriptString, TestRefArgument, TestSuspend (and several others are not working as they state *I do not work in max portability mode* )

You'll see where I have commented out the tests that do not work in main.cpp

I took #2 option as if you store all variables as 32bit internally then using casts of the DWORD value (instead of casting the pointer to a byte) seems to work.

We shall see if that blows up when arrays start being used:) but things are progressing.

also, can you svn:eol-style native all of the test source code?