1. ver 4.0 calling convention information ?
- Posted by bernie May 26, 2009
- 838 views
I need to know the following:
Is there more than one TYPE of routine_id returned from Euphoria ?
If so what creates each TYPE and when is it used ?
I need to know the calling conventions and who is responsible for
cleaning the stack for the following routines.
Euphoria call type routine receiving call\\ CALL_FUNC ( std or cdecl call ) ( clean stack for return ? )\\ C_FUNC ( std or cdecl call ) ( clean stack for return ? )\\ CALL ( std or cdecl call ) ( clean stack for return ? )\\
2. Re: ver 4.0 calling convention information ?
- Posted by mattlewis (admin) May 26, 2009
- 801 views
I need to know the following:
Is there more than one TYPE of routine_id returned from Euphoria ?
If so what creates each TYPE and when is it used ?
Are you referring to the fact that the documentation refers to the result of define_c_proc as a routine id? We really need to change that. It isn't a euphoria id at all. A better term would probably be handle, since it's completely opaque to euphoria code.
I need to know the calling conventions and who is responsible for
cleaning the stack for the following routines.
Euphoria call type routine receiving call\\ CALL_FUNC ( std or cdecl call ) ( clean stack for return ? )\\ C_FUNC ( std or cdecl call ) ( clean stack for return ? )\\ CALL ( std or cdecl call ) ( clean stack for return ? )\\
There's no stack to worry about with call_func()/call_proc(). These are basically equivalent to calling a euphoria routine normally. The backend takes care of the call stack. For interpreted code, it's an internal data structure, not the actual machine stack.
With c_func()/c_proc(), if the calling convention is stdcall, then the callee (the routine being called) is responsible for stack cleanup. For cdecl, the caller is responsible.
A call() doesn't really matter, since there are no parameters passed on the stack, there's really no difference between calling conventions, since no one needs to clean up anything.
Matt
3. Re: ver 4.0 calling convention information ?
- Posted by jimcbrown (admin) May 26, 2009
- 861 views
I need to know the following:
Is there more than one TYPE of routine_id returned from Euphoria ?
If so what creates each TYPE and when is it used ?
I need to know the calling conventions and who is responsible for
cleaning the stack for the following routines.
Euphoria call type routine receiving call\\ CALL_FUNC ( std or cdecl call ) ( clean stack for return ? )\\ C_FUNC ( std or cdecl call ) ( clean stack for return ? )\\ CALL ( std or cdecl call ) ( clean stack for return ? )\\
There are two kinds of routine_ids, one returned by routine_id() and used by call_func() and call_proc(), and the other returned by define_c_func() and define_c_proc() and used by c_func() and c_proc().
You shouldn't need to worry about calling conventions here, but if you're curious the calling convention used by call_func() and call_proc() is euphoria specific. (The C backend stores the parameters and return value into special internal values and keeps track as it jumps around the IL code.) c_func() and c_proc() can use either STDCALL or C_DECL, which convention is used depends on a flag that is attached to the routine_id() returned by define_c_func() and define_c_proc() (you can force C_DECL on windows by prepending the function name with a '+').
Finally, you can call call_back() (with a routine_id() routine id) to get an address that is callable by call(). Likewise, you can use define_c_var() in place of either define_c_func() or define_c_proc() to get an address that can then be passed to call().
If using call(), you have to worry about calling convention. call_back() wraps tthe euphoria routine_id() with special code that assumes the C_DECL calling convention.
As to whether or not you need to clean the stack, that depends on STDCALL vs C_DECL. (The euphoria internal calling convention has no stack per-see to speak of that would need cleaning up.)
4. Re: ver 4.0 calling convention information ?
- Posted by bernie May 26, 2009
- 811 views
Thanks MATT and JIM:
If I am INSIDE a EUPHORIA FUNCTION I need to know how
that routine was called ( STD or CDECL ) so I can protect
the STACK condition when I return from a assembler routine
that I am calling from inside of the EUPHORIA FUNCTION.
I keep hearing people say that EUPHORIA NOW uses the standard
calling convention. When EUPHORIA was 3.11 all these things
worked without a problem. ( yes I am using ENTER and LEAVE code. )
Something is different ?
5. Re: ver 4.0 calling convention information ?
- Posted by mattlewis (admin) May 26, 2009
- 813 views
Thanks MATT and JIM:
If I am INSIDE a EUPHORIA FUNCTION I need to know how
that routine was called ( STD or CDECL ) so I can protect
the STACK condition when I return from a assembler routine
that I am calling from inside of the EUPHORIA FUNCTION.
I keep hearing people say that EUPHORIA NOW uses the standard
calling convention. When EUPHORIA was 3.11 all these things
worked without a problem. ( yes I am using ENTER and LEAVE code. )
Something is different ?
I don't understand why you're asking about being inside a euphoria function. It only matters what the assembler routine thinks, so that your call can do the right thing. The only way that knowing the calling convention of a euphoria routine would be in translated code, if you were to inline some assembly that returned from the function. Is that what you're doing?
Nothing has changed with respect to calling conventions. On windows, the default is stdcall, but you can use cdecl. On any other platform, you'll always use cdecl. This has always been the case.
What may be confusing here is that there are some idiosyncrasies regarding Watcom, where it seems to do the right thing regardless. I think that what it does is remember where the stack pointer should be, and restores it after a call returns regardless of the calling convention.
I don't understand what "ENTER and LEAVE" code means. Maybe you could post some non-working code so that we could take a look.
Matt
6. Re: ver 4.0 calling convention information ?
- Posted by bernie May 26, 2009
- 813 views
ENTER & LEAVE are assembler instructions that preserve and
restore the stack and setup a temporary stack frame.
I guess I will have to rethink my ideas and come up with
another way of doing thing or just give up and just support
ver 3.11 with my code.
7. Re: ver 4.0 calling convention information ?
- Posted by jimcbrown (admin) May 26, 2009
- 844 views
Thanks MATT and JIM:
If I am INSIDE a EUPHORIA FUNCTION I need to know how
that routine was called ( STD or CDECL ) so I can protect
the STACK condition when I return from a assembler routine
that I am calling from inside of the EUPHORIA FUNCTION.
I keep hearing people say that EUPHORIA NOW uses the standard
calling convention. When EUPHORIA was 3.11 all these things
worked without a problem. ( yes I am using ENTER and LEAVE code. )
Something is different ?
How are you currently calling the assembler routine, and what calling convention is the assembler routine using?
If you call the assembler routine with call(), then you should not need to change anything. However, if you use c_func() or c_proc() then it may be a different story (in which case I suggest the assembly routine be changed to C_DECL calling convention).
8. Re: ver 4.0 calling convention information ?
- Posted by mattlewis (admin) May 26, 2009
- 881 views
ENTER & LEAVE are assembler instructions that preserve and
restore the stack and setup a temporary stack frame.
Oh, I see. These are directives that the assembler turns into actual instructions to deal with the stack pointer. My understanding of them is that they're for allocating stack space for local storage, not for parameter passing, which is what calling convention is about.
I guess I will have to rethink my ideas and come up with
another way of doing thing or just give up and just support
ver 3.11 with my code.
Without having seen the code in question, I really doubt that calling convention is the problem you're having. Is this a continuation of the previous thread where you were using a register and not restoring it?
Matt
9. Re: ver 4.0 calling convention information ?
- Posted by Critic May 27, 2009
- 859 views
Without having seen the code in question, I really doubt that calling convention is the problem you're having. Is this a continuation of the previous thread where you were using a register and not restoring it?
Probably. Somehow it seems to be very hard to push a register and pop it afterwards. Very funny. See? It's just like I said: The amount of incompetence in this community is amazing and very entertaining.
10. Re: ver 4.0 calling convention information ?
- Posted by jimcbrown (admin) May 27, 2009
- 856 views
Somehow it seems to be very hard to push a register and pop it afterwards.
Machine code programming is very hard.
Very funny. See? It's just like I said: The amount of incompetence in this community is amazing and very entertaining.
In my experience, when bernie thinks he has found a bug in EU, he has usually found a bug in EU.
But what he is asking for in this thread is help with machine code, not EU, so that's digressing. I am suprised to find that you feel such that, "ability of EU coders to ask and answer questions about machine language programming" == "incompetence".
11. Re: ver 4.0 calling convention information ?
- Posted by mattlewis (admin) May 27, 2009
- 911 views
Without having seen the code in question, I really doubt that calling convention is the problem you're having. Is this a continuation of the previous thread where you were using a register and not restoring it?
Probably. Somehow it seems to be very hard to push a register and pop it afterwards. Very funny. See? It's just like I said: The amount of incompetence in this community is amazing and very entertaining.
The feeling is mutual.
Matt
12. Re: ver 4.0 calling convention information ?
- Posted by bernie May 27, 2009
- 842 views
Without having seen the code in question, I really doubt that calling convention is the problem you're having. Is this a continuation of the previous thread where you were using a register and not restoring it?
Probably. Somehow it seems to be very hard to push a register and pop it afterwards. Very funny. See? It's just like I said: The amount of incompetence in this community is amazing and very entertaining.
MR. Critic:
Before you jump in and start insulting and talking about
incompetence. You had better get your facts about the subject.
First of all I was using Assembler before you were born.
I have used assembler on most microprocessors since
Intel's 4004 and many other microprocessor brands.
I learned to use BAL for Main Frames. I've worked with
GE, IBM, CDC equipment.
The problem that Matt is talking about is; I originally
wrote my assembler code to work with version 3.11 code.
In version 4.0 Matt started using the ESI and EDI register
in the new code and that started crashing my code until
he made me aware of the change.
I know that you are a very clever and brilliant programmer
and would have foreseen the change coming but I didn't.
I am dynamically creating assembler and using the created code
inside of Euphoria functions.
This worked in ver 3.11 but I now get exception errors which
I am struggling to resolve my problems not searching for insults.