Cross compiling with inline assembly

I have a C file and an assembly file for a program that I need to compile for both the x86 and m68k processors. Instead of making 2 versions of the assembly file, will it work if I write it inline in the C file and just cross compile for both?

Thanks

Originally Posted by TheEngineer

I have a C file and an assembly file for a program that I need to compile for both the x86 and m68k processors.

The assembly language file that you have targets which chipset - the x86 or the m68k chipset? If another, then specify the chipset it targets.

Originally Posted by TheEngineer

Instead of making 2 versions of the assembly file, will it work if I write it inline in the C file and just cross compile for both?

Nope! because the instruction set for x86 is poles apart from m68k. Also are you using a cross compiler or a native one?
What works tho' is given an x86 assembly file, use a cross assembler to dump an S-record file for uploading to an m68k machine, and vice-versa.

Originally Posted by itCbitC

The assembly language file that you have targets which chipset - the x86 or the m68k chipset? If another, then specify the chipset it targets.

Nope! because the instruction set for x86 is poles apart from m68k. Also are you using a cross compiler or a native one?
What works tho' is given an x86 assembly file, use a cross assembler to dump an S-record file for uploading to an m68k machine, and vice-versa.

The assembly file was written with Green Hills MULTI, and isn't compatible with either the m68k or the x86 through GNU. That is to say it was written for the m68k but has program-specific functions embedded.

What I was hoping to do was re-write this file for the x86 in AT&T assembly then put the functions inline with the main c code and cross compile for the m68k. I realize that the m68k and x86 use different assembly language, but isn't the assembly already compiled into the object file before the s-record is output during cross-compilation?

Originally Posted by TheEngineer

The assembly file was written with Green Hills MULTI, and isn't compatible with either the m68k or the x86 through GNU. That is to say it was written for the m68k but has program-specific functions embedded.

Not sure what the above statement means? Do you mean IDE specific functions?
Can you assemble m68k source in traditional mode so that MULTI IDE doesn't embed any of its own code.
Really can't say unless you specify what "program-specific functions embedded" means.

Originally Posted by TheEngineer

What I was hoping to do was re-write this file for the x86 in AT&T assembly then put the functions inline with the main c code and cross compile for the m68k.

A better solution would be to convert the existing m68k assembly file into C - don't have to worry about cross-compilation.
Now there are two C language files and portability isn't a headache anymore.

Originally Posted by TheEngineer

I realize that the m68k and x86 use different assembly language, but isn't the assembly already compiled into the object file before the s-record is output during cross-compilation?

Nope! it is not. The assembly process stops when the S record file is generated. There is no object module created. This process is used mostly for embedded applications where the host and target systems are different. The S-record file is then uploaded to the target machine thro' either a programmer or a serial interface.

Originally Posted by itCbitC

Not sure what the above statement means? Do you mean IDE specific functions?
Can you assemble m68k source in traditional mode so that MULTI IDE doesn't embed any of its own code.
Really can't say unless you specify what "program-specific functions embedded" means.

A better solution would be to convert the existing m68k assembly file into C - don't have to worry about cross-compilation.
Now there are two C language files and portability isn't a headache anymore.

Nope! it is not. The assembly process stops when the S record file is generated. There is no object module created. This process is used mostly for embedded applications where the host and target systems are different. The S-record file is then uploaded to the target machine thro' either a programmer or a serial interface.

Sorry, I didn't explain that well. MULTI uses some different instructions for its assembly files that aren't used in regular m68k assembly.

Converting to C sounds like it would relieve a lot of the headache. However after searching around it seems like it would be a pretty tough task, especially since I don't know assembly very well (I didn't write these files). Perhaps you could look at the code and see if it's something worthwhile?

In the c code, the function to call the assembly function is:

Code:

void XProcess(Function_ptr XAddr)
{
    if (PrintLevel < 2)
                fprintf(OutputFile, "Execute AP procedure at address %08X\n", XAddr);
    // If valid address then execute
    if ( ValidAddress((UInt32)XAddr, 1) )
                XPrc(XAddr);                                        //Calls assembly function
    else
                ErrorHandler(ErrInvalidAddress, 30, 0, 0, NULL);
}  // End XProcess

This is the assembly function that the c code calls:

Code:

/*   Procedure XPrc (Function_ptr ProcAddress);
*
*	XPrc saves all registers; calls the AP program;
*	and restores the registers.
*/   

	.data
/* Register storage area	*/
RegisterStorage:
	DS.L	15

	.global XPrc
	
XPrc:
	MOVEM.L	%D0/%D1/%D2/%D3/%D4/%D5/%D6/%D7/%A0/%A1/%A2/%A3/%A4/%A5/%A6,RegisterStorage
	LINK    %A6,#-(10)
	

	MOVE.L	8(%A6),%A2

/*	Call AP program at address in A2  */
	JSR	(%A2)

	MOVE.L (%A7)+,%A4
	UNLK	%A6
	
	MOVE.L	(%SP)+,%A0
	ADD	#0x8,%SP
	MOVE.L	%A0,-(%SP)
	MOVEM.L	RegStore,%D0/%D1/%D2/%D3/%D4/%D5/%D6/%D7/%A0/%A1/%A2/%A3/%A4/%A5/%A6
	
	RTS

There's no "program-specific functions embedded" in the code you posted. The only thing that the MULTI IDE software seems to be doing different from a traditional m68k assembler is to put a "%" sign before the registers. Remove the "%" sign everywhere from the assembly language file and the GNU compiler shouldn't complain. Alternatively, replace the function call XPrc(XAddr) with *XAddr, since XAddr is a pointer to function AP and *XAddr is AP and if possible post the code snippet where the AP function is defined.

Originally Posted by itCbitC

There's no "program-specific functions embedded" in the code you posted. The only thing that the MULTI IDE software seems to be doing different from a traditional m68k assembler is to put a "%" sign before the registers. Remove the "%" sign everywhere from the assembly language file and the GNU compiler shouldn't complain. Alternatively, replace the function call XPrc(XAddr) with *XAddr, since XAddr is a pointer to function AP and *XAddr is AP and if possible post the code snippet where the AP function is defined.

That is the m68k version with all the other crap deleted. It seems to cross-compile correctly. What I am trying to get around is rewriting it for the x86 by writing it in C.

Really, all this XPrc does is call the Procedure which is an argument to XPrc. But, before it does that, it needs to save the registers and after it does that it needs to return the registers. When that comment says, "calls the AP Program", its really saying "call the AP Program Procedure pointed to by ProcAddress. Can I do this in C?

Originally Posted by TheEngineer

That is the m68k version with all the other crap deleted. It seems to cross-compile correctly.

Not sure what you mean by the above statement, so do clarify
Does it cross-compile correctly now that you have removed leading % signs from all registers?
For example, "LINK %A6,#-(10)" should read "LINK A6,#-(10)" in a conventional m68k assembler.

Originally Posted by TheEngineer

What I am trying to get around is rewriting it for the x86 by writing it in C.

Shouldn't be a big deal as long as you post the code for the AP function.
Need to know what parameters it takes, variables it modifies etc. etc.

Originally Posted by TheEngineer

Really, all this XPrc does is call the Procedure which is an argument to XPrc. But, before it does that, it needs to save the registers and after it does that it needs to return the registers. When that comment says, "calls the AP Program", its really saying "call the AP Program Procedure pointed to by ProcAddress. Can I do this in C?

Yes! because ProcAddress is a pointer to AP and *ProcAddress is the actual function call in C.
From the posted code it doesn't look like AP takes any parameters, but it would help to see its code.

Originally Posted by itCbitC

Not sure what you mean by the above statement, so do clarify
Does it cross-compile correctly now that you have removed leading % signs from all registers?
For example, "LINK %A6,#-(10)" should read "LINK A6,#-(10)" in a conventional m68k assembler.

It compiles the way it is, with the "%".

Shouldn't be a big deal as long as you post the code for the AP function.
Need to know what parameters it takes, variables it modifies etc. etc.

I can't seem to locate the function, but I know it is from a separate input file. It seems as though I need direct access to the stack and to the registers...So it looks like I either have to write the assembly inline or make a new x86 assembly file. What do you think?

Originally Posted by TheEngineer

It compiles the way it is, with the "%".

Do you mean the GNU C compiler or with the MULTI IDE?

Originally Posted by TheEngineer

I can't seem to locate the function, but I know it is from a separate input file. It seems as though I need direct access to the stack and to the registers...So it looks like I either have to write the assembly inline or make a new x86 assembly file. What do you think?

If you had read my previous post you wouldn't be asking this question.
And yes! you can write this in C w/o the need to code it in x86 assembly.

Code:

void XProcess(Function_ptr XAddr)
{
    if (PrintLevel < 2)
                fprintf(OutputFile, "Execute AP procedure at address %08X\n", XAddr);
    // If valid address then execute
    if ( ValidAddress((UInt32)XAddr, 1) )
                *XAddr;                      // calls the AP routine so no need to call XPrc
                //  XPrc(XAddr);                         
    else
                ErrorHandler(ErrInvalidAddress, 30, 0, 0, NULL);
}  // End XProcess

Use the code above and re-compile the source without the m68k assembly file.
See if you get the same results as when you compiled with the m68k assembly file.

Originally Posted by TheEngineer

It compiles the way it is, with the "%".

Do you mean the GNU C compiler or with the MULTI IDE?

Originally Posted by TheEngineer

I can't seem to locate the function, but I know it is from a separate input file. It seems as though I need direct access to the stack and to the registers...So it looks like I either have to write the assembly inline or make a new x86 assembly file. What do you think?

If you had read my previous post you wouldn't be asking this question.
And yes! you can write this in C w/o the need to code it in x86 assembly.

Code:

void XProcess(Function_ptr XAddr)
{
    if (PrintLevel < 2)
                fprintf(OutputFile, "Execute AP procedure at address %08X\n", XAddr);
    // If valid address then execute
    if ( ValidAddress((UInt32)XAddr, 1) )
                *XAddr;                      // calls the AP routine so no need to call XPrc
                //  XPrc(XAddr);                         
    else
                ErrorHandler(ErrInvalidAddress, 30, 0, 0, NULL);
}  // End XProcess

Use the code above and re-compile the source without the m68k assembly file.
See if you get the same results as when you compiled with the m68k assembly file.