Got past TestReturn. now up to TestSwitch. The fix for TestReturn is in asCDataType::GetSizeInMemoryBytes(). a Bool is not one byte in size but rather 4. (at least on the PPC) and so when the return value of "1" (or true) is set under the assumption of a byte it fails to pass the !returned as apparently !16777216 is not false, only !1. (this is the same issue I had when the Assert calls were pointing to a CDECL implementation of ASSERT and thus returned a pointer instead of 1 in the bool value)

I've updated my site w/ the latest patches.

http://www.outoforder.cc/downloads/patches/
PPCfix3.diff is the difference from current trunk to my changes
angelscript-2006-10-09.zip is the entire local WC.

Every test is working in AS_MAX_PORTABILITY except for the _switch2() function and the uint8 problem.

all instructions seem to be working fine except for the INCi8 which assumes an 8bit variable where as w/ the case of the switch you are using a 32bit var on the l_fp being treated as an 8bit. And I can not just change the INCi8 to assume it's a 32bit (and cast it) as if a real native 8bit variable were to be incremented it would not work. correct me if I'm wrong, however. As a nice simple fix would be

case BC_INCi8:
((char)(**(asDWORD**)&register1))++

thus treating it as a word and only casting as a char, so it would increment correctly in both environments.

Right now I'm at a standstill until we figure how to resolve these byte conversions. I may try making some more tests to test other crazy scenarios.

Oh, BTW. All my changes work perfectly on my linux x86 box in AS_MAX_PORTABILITY mode. (have not tested regular mode).

I've applied and submitted your latest changes to the SVN. [Edit]Posted this while you posted your third set of changes so they are not yet included.[/Edit]

There were a couple of errors though:

 	case BC_INCi:-		++(*(int*)(size_t)register1);+		++(*(int*)(size_t*)& register1); 		l_bc++; 		break;  	case BC_DECi:-		--(*(int*)(size_t)register1);+		--(*(int*)(size_t*)& register1); 		l_bc++; 		break;

You forgot to dereference the pointer before casting to (int*) in these two changes. But you probably already noticed that.

I added a couple of new asserts in the asCreateScriptEngine() function so that we can validate the assumptions taken in the library code. If what you're saying, that sizeof(bool) is 4 then the assert will fail, which means that I'll have to adopt the code for this.

I'll include your third set of changes tomorrow, when I get a bit more time. I already downloaded the files, in case you wish to clean up your disk.

The problem with _switch2() can only be solved with the proper conversion of the 8bit value to 32bit before comparison. Which means that I'll have to implement the changes that I planned out before.

In either case it feels very good that the library is now working on PPC as well. (At least if you're careful when mixing variables of different sizes. [wink])

A big thank you for your efforts with this port. I'll add your name to the list of contributors. [smile]

Regards,
Andreas

PS. I also need to verify that all these changes haven't broken the 64bit support. But hopefully it should only have caused a few compiler warnings.

Quote: Original post by WitchLord
There were a couple of errors though:

 	case BC_INCi:-		++(*(int*)(size_t)register1);+		++(*(int*)(size_t*)& register1); 		l_bc++; 		break;  	case BC_DECi:-		--(*(int*)(size_t)register1);+		--(*(int*)(size_t*)& register1); 		l_bc++; 		break;

You forgot to dereference the pointer before casting to (int*) in these two changes. But you probably already noticed that.

I noticed that already and it's fixed in the last update you have.

Quote: Original post by WitchLord
I added a couple of new asserts in the asCreateScriptEngine() function so that we can validate the assumptions taken in the library code. If what you're saying, that sizeof(bool) is 4 then the assert will fail, which means that I'll have to adopt the code for this.

PPC has a 4 byte bool (no clue why but it does), thus it fails the assert.
hmm.. excerpt from the Apple manual

Quote:
A long double is 16 bytes on both architectures, but only 80 bits are significant in long double data types on Intel-based Macintosh computers.

A bool data type is a single byte on an x86 system, but four bytes on a PowerPC architecture. This size difference can cause alignment problems. You should use fixed-size data types to avoid alignment problems. (The bool data type is not the Carbon Boolean type, which is a fixed size of 1 byte.)

And you can't rely on the fact that the PPC has a 4 byte bool either.. AS there is a compiler option to turn it into a one byte bool. However the likelyhood of that setting being enabled is very rare as it can introduce binary compatability problems with other libraries.

Oh and an interesting bit of random information from the Apple manual

Quote:
The terms big-endian and little-endian come from Jonathan Swift’s eighteenth-century satire Gulliver’s Travels. The subjects of the empire of Blefuscu were divided into two factions: those who ate eggs starting from the big end and those who ate eggs starting from the little end.

I've updated the SVN with your latest changes. And also made the size of bool configurable, so that it is now correct on MacOSX with PPC. I also ran some tests on a couple of different systems (thanks to SourceForge.net's compile farm).

Windows x86 with MSVC  -- all tests passedLinux AMD64 with gnuc  -- all tests passedLinux PPC with gnuc    -- test_conversion and test_switch failed, the rest passed

I didn't have time to check out exactly why the test_conversion failed. But it is likely due to the mix of datatypes, which still needs to be fixed. In test_switch it is the _switch2 that fails, much as you reported.

Did test_conversion work for you, or did you comment out some part of it?

When I get the time I'll implement the proper conversion between types of different sizes so that this too will work on PPC (and other big-endian CPUs).

Regards,
Andreas

Quote: Original post by WitchLord
I've updated the SVN with your latest changes. And also made the size of bool configurable, so that it is now correct on MacOSX with PPC. I also ran some tests on a couple of different systems (thanks to SourceForge.net's compile farm).

Windows x86 with MSVC  -- all tests passedLinux AMD64 with gnuc  -- all tests passedLinux PPC with gnuc    -- test_conversion and test_switch failed, the rest passed

I didn't have time to check out exactly why the test_conversion failed. But it is likely due to the mix of datatypes, which still needs to be fixed. In test_switch it is the _switch2 that fails, much as you reported.

Did test_conversion work for you, or did you comment out some part of it?

Yes, test_conversion worked for me without any changes.. hmm. I'll have to log into the compile farm myself and test it.

I guess the next step for me is to disable the MAX PORTABILITY option and try and get native calling working..

I've checked in some new code with new improvements (at least I think they are). I got the switch2 test to work properly now, as I've implemented proper conversion between types of different sizes.

I haven't finished the changes needed to literal constants however, so any tests involving 8bit or 16bit literals are likely to break at the moment. I've added a new set of TODO: PPC: for these changes however, if anyone is interested in taking a look at it.

Soon everything should be working smoothly even on PPC. :D (native calling conventions will be a bit longer)

Regards,
Andreas

Sweet.. I'll update my copy and test out the new changes. I'm still chuging away at the Native calling code, getting a feel for the differences in assembly between x86 and PPC and I think I have the problems with the existing implementation nailed down and am working through re-implementing it. I should have a patch for that soon.

Do you have access to Linux on a PPC machine? I'm guessing the assembly routines have to be different for Linux and Mac OS X, at least slightly, due to different ABIs.

Anyway, I'm happy you have the patience to really look into this. It's really appreciated.

Regards,
Andreas