1. ver 4.0 calling convention information ?

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 ? )\\   

new topic     » topic index » view message » categorize

2. Re: ver 4.0 calling convention information ?

bernie said...

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.

bernie said...

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: ver 4.0 calling convention information ?

bernie said...

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.)

new topic     » goto parent     » topic index » view message » categorize

4. Re: ver 4.0 calling convention information ?

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 ?

new topic     » goto parent     » topic index » view message » categorize

5. Re: ver 4.0 calling convention information ?

bernie said...

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

new topic     » goto parent     » topic index » view message » categorize

6. Re: ver 4.0 calling convention information ?

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.

new topic     » goto parent     » topic index » view message » categorize

7. Re: ver 4.0 calling convention information ?

bernie said...

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).

new topic     » goto parent     » topic index » view message » categorize

8. Re: ver 4.0 calling convention information ?

bernie said...

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.

bernie said...

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

new topic     » goto parent     » topic index » view message » categorize

9. Re: ver 4.0 calling convention information ?

mattlewis said...

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.

new topic     » goto parent     » topic index » view message » categorize

10. Re: ver 4.0 calling convention information ?

Critic said...

Somehow it seems to be very hard to push a register and pop it afterwards.

Machine code programming is very hard.

Critic said...

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".

new topic     » goto parent     » topic index » view message » categorize

11. Re: ver 4.0 calling convention information ?

Critic said...
mattlewis said...

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

new topic     » goto parent     » topic index » view message » categorize

12. Re: ver 4.0 calling convention information ?

Critic said...
mattlewis said...

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.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu