Running c code from Amos

[Emufr3ak]

I'm a member from the Demogroup void. We have a challenge. Our
coders use Amos, C and assembler. We want to make demos together but nobody wants to change its language preference. So I told myself that it has to be possible to merge code from all those three languages into one executable. On the lowest level everything is machine code after all.

After some research I discovered that Amos has commands to embedd binary files. With the method PLIST a binary can be loaded into memory. This code can get executed using the Call method. There is a caveat however. Amos only loads the first hunk. All others are ignored. I'm using gcc and do a crosscompile for the c code. I do not have full control over the hunks there. How can I workaround this?

[Cowcat]

We use vlink to manipulate objects before link time (to embed 68k code with gcc ppc code, for example). Phx knows about hunks.

Other than that, cut paste hex code from output object to be read as an array.....

[phx]

Originally Posted by Emufr3ak

After some research I discovered that Amos has commands to embedd binary files. With the method PLIST a binary can be loaded into memory. This code can get executed using the Call method. There is a caveat however. Amos only loads the first hunk.

Ok... so PLIST doesn't load a binary but the first hunk from an executable file or object file? That's an important difference, because then I assume it will also process the relocations for you.

do a crosscompile for the c code. I do not have full control over the hunks there. How can I workaround this?

Usually a C compiler (and linker) can be convinced to create a minimum of two sections (using small-code and small-data model), but a single section is difficult with common tools.

Cowcat already mentioned vlink, which might be the solution here. I have some options for merging code sections, all data and bss sections for small-data, and merging all sections of the same type. Adding another option for merging all sections was a matter of 5 minutes.

Tomorrow's vlink snapshot at http://sun.hasenbraten.de/vlink/index.php?view=source can do that with the new -mall option.

I don't know if your C developers have the knowledge to replace the GNU-linker with vlink to generate an executable. But vlink also works directly on executables and can convert them (while emitting some warnings). For example:

vlink -bamigahunk -mall -o newexe oldexe

.

Or does PLIST need an object file? I have no experience with Amos at all. Is there even an Amos compiler which can create object files from your Amos source?

[Emufr3ak]

Thanks so much for this phx! This vlink version should make this a piece of cake. Will let you know how it goes.

[Emufr3ak]

Didn't touch AMOS for decades myself. :-)

I'd say PLOAD needs an executable. Thats what the Manual says.

The PLOAD command reserves a memory bank and loads some machine code into it from disc. Specify thefilename that contains the machine code file on disc, followed by the number of a new memory bank to be reservedfor the program. If the bank number is negative, the number will be multiplied by -1, and the bank will be allocatedusing Chip memory.Once machine code is loaded in this way, it is installed as a permanent memory bank, so whenever the currentprogram is saved, the machine code is stored too. Also note that the machine code file can be saved onto disc as astandard ".Abk" file, then loaded directly into AMOS Professional Basic. After PLOAD has performed its work, the memory bank can be executed immediately!

I do not think that its possible to create an object file with Amos compiler. But this way it should not be neccesary. If I understand it correctly I can just compile it and the binary will be embedded in it.

[phx]

Originally Posted by Emufr3ak

After PLOAD has performed its work, the memory bank can be executed immediately!

Ok. So you need a real executable. But can you pass parameters to it or start it multiple times? Otherwise its usefulness would be quite limited.

[Emufr3ak]

You can also load a executable inside a Procedure. Amos procedures do accept parameters. Same rules apply otherwise as for PLOAD.

New version of vlink works fine. It gives me a working executable with only one section. Amos Integration dies not work yet. Have to find out why.

[Emufr3ak]

It looks like Amos doesnt to relocation. This makes it hard to use for my purpose. I'd need to write everything PC relative. Which is difficult to do in C for a bigger chunk of code.

[robinsonb5]

Originally Posted by Emufr3ak

It looks like Amos doesnt to relocation. This makes it hard to use for my purpose. I'd need to write everything PC relative. Which is difficult to do in C for a bigger chunk of code.

A long time ago I solved a similar problem by writing an AMOSPro extension which could load code modules (using LoadSeg() so with full relocation). My modules contained a header which the extension used to locate variables and procedures. I released the extension here: http://aminet.net/package/dev/amos/GameSupport a long time ago - if you think it might help with your project I'll see if I can find an example code module, too.

[Emufr3ak]

This sounds interesting! I've seen the loadseg function. My issue is that we need this
for an intro. Which means we are limited to one file. So we'd need to "run loadseg" for
a block in memory instead of a file. Not sure this would be possible.

[robinsonb5]

Originally Posted by Emufr3ak

This sounds interesting! I've seen the loadseg function. My issue is that we need this
for an intro. Which means we are limited to one file. So we'd need to "run loadseg" for
a block in memory instead of a file. Not sure this would be possible.

Yeah that does make things a lot trickier. If the OS is still alive, one brute-force, ugly method might be to save the executable back out to RAM: and LoadSeg() it from there.


What's the problem with PC-relative code from C, though? Which compiler are you using?

[Emufr3ak]

I'm using gcc. Found some compile options like fpic, fpie and mpcrel. Either they don't do anything or cause compiler or linker errors.

[Emufr3ak]

Basically what I need is something like this http://www.whdload.de/docs/autodoc.h...sload_Relocate

[robinsonb5]

Originally Posted by Emufr3ak

I'm using gcc. Found some compile options like fpic, fpie and mpcrel. Either they don't do anything or cause compiler or linker errors.

I've just tried -mpcrel with m68k-elf-gcc and it does indeed seem to generate PC-relative code. What errors are you seeing with that option?



What exactly are you trying to do within the C code? Any OS calls? Are you linking with or without startup code / std C library? Are you using a linkscript?

[Emufr3ak]

Compilation with mpcrel works. The result isn't what I need unfortunately. First instruction is 4E F9 00 00 00 06 (jmp $6). Without relocation this jumps to address 06 and of course crashes.

[Toni Wilen]

One solution (or a hack) would be to add small routine at the beginning of executable that does the relocation in-place.

I used this method to create pfs3aio "custom" version that is made for crappy HD controllers that expect no relocations in RDB embedded filesystems. It is basically original executable embedded in another executable.

[robinsonb5]

Originally Posted by Emufr3ak

Compilation with mpcrel works. The result isn't what I need unfortunately. First instruction is 4E F9 00 00 00 06 (jmp $6). Without relocation this jumps to address 06 and of course crashes.

But where does that jmp $6 come from? Is that from your code, or is it startup / library code? If the latter, have you tried linking without startup / c library?

[Emufr3ak]

Hi Tony. Thanks for the hint. Found the source on https://github.com/tonioni/pfs3aio. Where in the source would I find the code I'm interested in?

[Toni Wilen]

It is not part of pfs3aio. But it is extremely simple: (pfs3aio is normal executable, must only have 1 hunk)

start
	move.l 4.w,a6
	jsr -$0084(a6)
	lea DriverStart+$1c(pc),a0
	move.l (a0)+,d0 ;hunk size
	move.l a0,a1
	addq.l #2,d0
	lsl.l #2,d0
	add.l d0,a0
	move.l a1,d1
	tst.l (a0)
	bmi.s relocend
	moveq #-1,d0
	move.l d0,(a0)+
reloc
	move.l (a0)+,d0	
	beq.s relocend
	add.l d1,0(a1,d0.l)
	bra.s reloc
	cmp.w #36,20(a6)
	bcs.s relocend
	jsr -$27c(a6)
relocend
	jsr -$008a(a6)
	jmp (a1)

DriverStart
	incbin "l:pfs3aio/pfs3aio"
DriverEnd

end

[Emufr3ak]

Thanks Tony. I think this code should make it straight forward for me to write my own relocation routine.