Homesource Forums

Homeworld Source Editing Talk
It is currently Mon Sep 25, 2017 10:55 pm

All times are UTC - 5 hours




Post new topic Reply to topic  [ 17 posts ] 
Author Message
PostPosted: Sun Oct 26, 2008 3:34 pm 
Offline
coder

Joined: Wed Oct 01, 2008 2:55 pm
Posts: 103
Location: Michigan
This function causes memory problems with Macs running on x86 processors...... and obviously was re-written for ppc processors as well as x86_64 processors in the past......

Isnt there a better way to accomplish this task without needing different code for every platform that comes along? I dont really understand what this function does, but the philosophy behind it seems severely broken to me. :(

its seems like the only way to solve the problems I am having will require #ifdefs...


Top
 Profile  
 
PostPosted: Mon Oct 27, 2008 3:04 pm 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Hi.

The joys of ETG.c! How many hours of my life have I spent within that particular file delving the dark magics to be found there.
The pains of frustration are intertwined with the exhilaration of actually understanding what the f*** is going on.

I'm afraid there is no easy way to understand ETG.c and specifically etgFunctionCall, but I'll see if I can point you in the right direction young acolyte. :)

ETG (Effects of the Gods) is a scripting language.
Find a simple ETG file like "r1salvage.ebg" -- You can find it in homeworld.big and have a good, long look.
Take out all the whitespace and then look again for there is an awful lot of whitespace. (It's irrelevant. I hunted for some reason why there was so much. I spent two days trying to divine if there was some hidden meaning, and even now the thought that there is something hidden there haunts me!)

But I digress....

ETG.c takes those instruction and converts them to a series of opcodes, and associated values. (See ETG.c line 255 ( etgParseTable ) and line 436 ( etgFunctionTable ) )
The important ones are the functions.

Notice that for each function, there are a number of inputs, and an output (ETV_Void for no output).

What the programmers did was to find a way to call all the possible functions with arguments from one function.

Can you guess what that function was?

Yes, etgFunctionCall will trick the compiler into effectively calling a function without giving it any arguments.
The upshot is that the OS executes the compiled code as though the arguments were there because you've put them where they need to be.

That's the black magic of the ETG. It is a huge and elegant kludge to allow many functions to be called from one routine without having to match all the function arguments to the compiler. It is overloading to the Nth degree. :)

It is quite a fantastic trick, but to emulate it for the other Operating Systems ABI, you have to re-write the code. This is, unfortunately, why you have to have different blocks.

x86 uses a stack to pass values, which is why it is all pushed onto the stack before the function is called.
x86_64 uses different registers for the first, second, third, etc values and it also depends on if it is a real or a floating point value.
PPC is the same as x86_64 but using different registers.

I think I've rambled on for long enough, but I hope that this is helpful and insightful.

Aunxx.


Top
 Profile  
 
PostPosted: Mon Oct 27, 2008 5:36 pm 
Offline
coder

Joined: Wed Oct 01, 2008 2:55 pm
Posts: 103
Location: Michigan
This clears up a lot of things for me. I will return to the monster and tangle with it again, hopefully I will win at some point, but either way, this seems like a really good reference for future newbs.


Top
 Profile  
 
PostPosted: Sat May 23, 2009 6:40 pm 
Offline

Joined: Tue Oct 10, 2006 2:04 pm
Posts: 73
Location: North germany
Performance considerations aside, wouldn't it be wiser to take an approach of one argument - which should be some kind of list containing different "objects" (similar to the gtype model used in gtk)?
Granted there is some overhead but it seems to me like with the limited developer resources there are, a little performance drain wouldn't be as severe as having to port an obscure technique.

_________________
.: The hardest punishment are the innocent eyes of a child searching for truth :.


Top
 Profile  
 
PostPosted: Sun May 24, 2009 4:48 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Have you looked at the ETG.c code? It's not quite that easy. One of the problems is that depending on what type the argument is it comes from a different location, but the main issue is that as the variables aren't written into the structure with wrappers it would be a lot of work to do this.

What I ended up doing was creating a wrapper function pointer which takes in the effects and other structs and pulls out the values from the correct place and then casts them to the right type before calling the function via a locally declared function pointer of the correct type. This should be quite efficient but the main reason for doing it that way is I can get the C pre-processor to do all the hard work for me :). The code should be CPU agnostic although I've only been able to test it on ARM and x86 32-bit.


Top
 Profile  
 
PostPosted: Mon May 25, 2009 7:38 am 
Offline

Joined: Tue Oct 10, 2006 2:04 pm
Posts: 73
Location: North germany
Sounds awkward - looking at the old etgFunctionCall it looks pretty messy - but since I'm a total noob when it comes to assembler I could be wrong.
I'll try to gain some more understanding as soon as I have some time - probably next week.

_________________
.: The hardest punishment are the innocent eyes of a child searching for truth :.


Top
 Profile  
 
PostPosted: Mon May 25, 2009 5:25 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Feel free :). Out of interest what is it your trying to achieve? Remove the assembly from etgFunctionCall? If so then my work as already done that, ok theirs a lot of casting going on, but that's true for much of the HW code I'm sure.


Top
 Profile  
 
PostPosted: Tue May 26, 2009 12:06 am 
Offline

Joined: Tue Oct 10, 2006 2:04 pm
Posts: 73
Location: North germany
I'm currently working on a port to a new platform and assembler code is the most probable thing that will get me in trouble.

_________________
.: The hardest punishment are the innocent eyes of a child searching for truth :.


Top
 Profile  
 
PostPosted: Tue May 26, 2009 10:27 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Cool, what platform is it?

You should just need to do what I did for ARM, checkout Linux/stuff/configure.ac. I used something like ETG_GENERIC_FUNCTIONCALL as the compile define (you can also force it for platforms that do have the assembly version by using the configure option), this should remove the last piece of assembly from your build ;D.


Top
 Profile  
 
PostPosted: Tue May 26, 2009 10:37 am 
Offline

Joined: Tue Oct 10, 2006 2:04 pm
Posts: 73
Location: North germany
basicmark wrote:
Cool, what platform is it?

It's powerpc-gekko-eabi

basicmark wrote:
You should just need to do what I did for ARM, checkout Linux/stuff/configure.ac. I used something like ETG_GENERIC_FUNCTIONCALL as the compile define (you can also force it for platforms that do have the assembly version by using the configure option), this should remove the last piece of assembly from your build ;D.

I hope so :)

_________________
.: The hardest punishment are the innocent eyes of a child searching for truth :.


Top
 Profile  
 
PostPosted: Tue May 26, 2009 11:47 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Would that be the Wii per-chance :)? I think it would be cool using the Wii-mote to control your ships. In fact I created a plug-in for one of the opensource Wii libraries for Linux for this, but it needs a little bit more work. Maybe once I get HW running on my beagle I'll finish it ;p


Top
 Profile  
 
PostPosted: Sat May 30, 2009 1:58 pm 
Offline

Joined: Tue Oct 10, 2006 2:04 pm
Posts: 73
Location: North germany
basicmark wrote:
this should remove the last piece of assembly from your build ;D.

Take a look at knitransform.c and start crying!

_________________
.: The hardest punishment are the innocent eyes of a child searching for truth :.


Top
 Profile  
 
PostPosted: Sat May 30, 2009 2:49 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
You don't need it :), transform.c has the same functionality. knitransform.c is just optimised for SSE. I'm not at home so don't have the code to hand but somehow I just stubbed out the calls to these functions. Check transform.c and I think you should see #ifdef ARM or if I did it correctly #ifndef x86 or some such.


Top
 Profile  
 
PostPosted: Sat May 30, 2009 2:59 pm 
Offline

Joined: Tue Oct 10, 2006 2:04 pm
Posts: 73
Location: North germany
basicmark wrote:
You don't need it :), transform.c has the same functionality. knitransform.c is just optimised for SSE. I'm not at home so don't have the code to hand but somehow I just stubbed out the calls to these functions. Check transform.c and I think you should see #ifdef ARM or if I did it correctly #ifndef x86 or some such.

Did you submit to trunk?
The Makefile does try to find a StubTransform.c which is nowhere to be located. There is a Transformer.c which also contains lots of assembler - but it seems to compile.

_________________
.: The hardest punishment are the innocent eyes of a child searching for truth :.


Top
 Profile  
 
PostPosted: Sat May 30, 2009 3:52 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Opps did I forget a SVN add :roll: . Will check this when I back home on Monday.


Top
 Profile  
 
PostPosted: Sun May 31, 2009 2:42 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
File added.


Top
 Profile  
 
PostPosted: Sun May 31, 2009 2:44 pm 
Offline

Joined: Tue Oct 10, 2006 2:04 pm
Posts: 73
Location: North germany
basicmark wrote:
File added.

Yeah - saw your checkin - already trying to get it in. Thx.

_________________
.: The hardest punishment are the innocent eyes of a child searching for truth :.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group