Hello,

I had mistakenly posted this to a different forum.  

I am putting together an application that needs to use code written in LE C/C++ and Metal C.  

I am trying to understand how to call one from the other.
Right now, I have a Metal C program that issues ATTACHes for 3 different LE C modules.  It appears to work OK, at least in my little test programs.   

We have some application specific services that are provided by Metal C functions.  If I want to call a non "main" Metal C function (that does  not issue any requests that require LE and so does not need an LE environement) from an LE C/C++ program, do I need to provide my own prolog/epilog code - perhaps something similar to the CEEENTRY and CEETERM macros?  

I have not seen any documentation that specifically addresses Metal C and LE C  communication.

I think the problems have to do with the following
(1)  By default, LE C does not build an OS style parmlist -- it uses C style.

(2) By default, LE C code will branch to x'10' from the address of the called function.

(3) By default, non main Metal C programs expect the forward pointer in the caller's DSA to point to the NAB (next available byte).  The  Metal C function sets its DSA (R13) to that value.  However, LE C programs do not set the forward pointer to the NAB.

I believe I can get by problems 1 and 2 by creating the prototype for the called Metal C function with 'extern "OS"'.   However, that leaves me with problem 3.

To address that, one thought I had was to do the following in the LE C code

(1) malloc an area for use by the called Metal C function

(2) Use an __asm(" mvc 8(4,13),%[metalDSA] \n"  (where metalDSA will be the address of the malloc'd area.  This will update the forward pointer  to point to the malloc'd area  immediately before the call to the Metal C module.  It seems a bit klugey though...

 

Thank you for any info,
Nancy Kilroy

I'd offer a different way to solve the problem:

Put the functional parts of the non-main functions into #include files.  Then #include those files into separate modules, one that's metal c "compliant" and one that is LE C "compliant."  Call the right one based on the environment you are coming from, the compiler will (should?) do the right thing regarding the linkage from metal c -> metal c and LE c -> LE c, no?

Hello,

I had mistakenly posted this to a different forum.  

I am putting together an application that needs to use code written in LE C/C++ and Metal C.  

I am trying to understand how to call one from the other.
Right now, I have a Metal C program that issues ATTACHes for 3 different LE C modules.  It appears to work OK, at least in my little test programs.   

We have some application specific services that are provided by Metal C functions.  If I want to call a non "main" Metal C function (that does  not issue any requests that require LE and so does not need an LE environement) from an LE C/C++ program, do I need to provide my own prolog/epilog code - perhaps something similar to the CEEENTRY and CEETERM macros?  

I have not seen any documentation that specifically addresses Metal C and LE C  communication.

I think the problems have to do with the following
(1)  By default, LE C does not build an OS style parmlist -- it uses C style.

(2) By default, LE C code will branch to x'10' from the address of the called function.

(3) By default, non main Metal C programs expect the forward pointer in the caller's DSA to point to the NAB (next available byte).  The  Metal C function sets its DSA (R13) to that value.  However, LE C programs do not set the forward pointer to the NAB.

I believe I can get by problems 1 and 2 by creating the prototype for the called Metal C function with 'extern "OS"'.   However, that leaves me with problem 3.

To address that, one thought I had was to do the following in the LE C code

(1) malloc an area for use by the called Metal C function

(2) Use an __asm(" mvc 8(4,13),%[metalDSA] \n"  (where metalDSA will be the address of the malloc'd area.  This will update the forward pointer  to point to the malloc'd area  immediately before the call to the Metal C module.  It seems a bit klugey though...

 

Thank you for any info,
Nancy Kilroy

Hey Scott!

Great idea! Thank you.

I always said that you are wicked smaht! :)

I'd offer a different way to solve the problem:

Put the functional parts of the non-main functions into #include files.  Then #include those files into separate modules, one that's metal c "compliant" and one that is LE C "compliant."  Call the right one based on the environment you are coming from, the compiler will (should?) do the right thing regarding the linkage from metal c -> metal c and LE c -> LE c, no?

Hello,

I had mistakenly posted this to a different forum.  

I am putting together an application that needs to use code written in LE C/C++ and Metal C.  

I am trying to understand how to call one from the other.
Right now, I have a Metal C program that issues ATTACHes for 3 different LE C modules.  It appears to work OK, at least in my little test programs.   

We have some application specific services that are provided by Metal C functions.  If I want to call a non "main" Metal C function (that does  not issue any requests that require LE and so does not need an LE environement) from an LE C/C++ program, do I need to provide my own prolog/epilog code - perhaps something similar to the CEEENTRY and CEETERM macros?  

I have not seen any documentation that specifically addresses Metal C and LE C  communication.

I think the problems have to do with the following
(1)  By default, LE C does not build an OS style parmlist -- it uses C style.

(2) By default, LE C code will branch to x'10' from the address of the called function.

(3) By default, non main Metal C programs expect the forward pointer in the caller's DSA to point to the NAB (next available byte).  The  Metal C function sets its DSA (R13) to that value.  However, LE C programs do not set the forward pointer to the NAB.

I believe I can get by problems 1 and 2 by creating the prototype for the called Metal C function with 'extern "OS"'.   However, that leaves me with problem 3.

To address that, one thought I had was to do the following in the LE C code

(1) malloc an area for use by the called Metal C function

(2) Use an __asm(" mvc 8(4,13),%[metalDSA] \n"  (where metalDSA will be the address of the malloc'd area.  This will update the forward pointer  to point to the malloc'd area  immediately before the call to the Metal C module.  It seems a bit klugey though...

 

Thank you for any info,
Nancy Kilroy