Optimal Library Language?

[Steam Ranger]

I'm working on a demo. Not pushing the hardware to it's limits, but more so the floppy disks. Anyway, it's not relevant.

I'm making several mini-libraries in my project that I plan to use later. I do my main project in assembly for speed. My libraries are currently in assembly, but I'd like to put them in C.

Firstly, can I make a C function accessible using assembly bsr and moving arguments into registers?

Also, what performance can I expect out of C for rapid repetitive memory access? I'm using gcc 8.

Thanks in advance.

[Karlos]

Do you mean AmigaOS shared libraries or just link time libraries? For the latter, all you need to do is make sure that the C function accepts parameters as you expect them as the compiler will have it's own semantics for that if left to its own devices. Generally C function names end up as an underscore prefixes name for the linker and you should definitely be able to jsr and bsr it. As for performance, that depends. Unless your code is very performance critical the compiler should make a decent job of most things. Obviously there will be stuff you can hand roll better.

In any case, C and assembly language get on well together in my experience.

[phx]

Originally Posted by Steam Ranger

Firstly, can I make a C function accessible using assembly bsr and moving arguments into registers?

Adding to what Karlos said: Make sure that your compiler and your assembler code use the same code-section, otherwise the linker might not allow PC-relative calls like

bsr

. There may be linker options to merge all code sections, though.

The default ABI for most m68k-compilers is passing arguments on the stack, not in registers, where a 32-bit compiler should extend all smaller types to 32 bits, before pushing them. If you want the C compiler to receive register arguments, which is compiler-specific, and stay portable with others at the same time, you may want to consider the SDI-headers on Aminet ( http://aminet.net/package/dev/c/SDI_headers ), which define macros for all common compilers.

Also worth noting is that the m68k-ABI defines d0, d1, a0 and a1 (fp0, fp1 for the FPU) as scratch registers, which a C function may change (same as for AmigaOS library calls). Other registers are guaranteed to keep their previous contents.