View Single Post
Old 29 December 2013, 02:24   #16
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,368
I wrote an example of how an library using the UAE Native Interface could look like:

Code:
#include <string.h>
#include <uae/uni.h>

UNI_DEFINE_LIBRARY(NULL);

UNIAPI void UNICALL hello_world(struct uni *uni) {
    char* data = UNI_POINTER(a1);
    strcpy(data, "Hello, World!");
}
UNIAPI/UNICALL are there to specify C calling convention and dll export, for compilers which need it (=msvc ) UNI_DEFINE_LIBRARY defines a default initialization/version check function with an optional pointer to a user-supplied library initialization routine.

Example C code, Amiga side:

Code:
char data[64];
int library = uni_load_library("hello_world_library");
int function = uni_get_function(library, "hello_world");
uni_call_1(function, UNI_SYNCHRONOUS, &data);
/* data now contains the string "Hello, World!" */
uni_call_1 being a possible convenience function which takes a function, a set of flags, and a single integer parameter which is written to (for example) register a1 - which is referenced by the native code - before invoking the native interface. The library and function are referenced by integers/handles instead of actual addresses. The native interface layer will contain the required mapping between library/function handles and real addresses. This makes it impossible to call native functions which does not exist, and also makes support for 64-bit libraries transparent to the Amiga.

Quote:
Originally Posted by Der Wanderer View Post
I had the idea that lengthy calls could be run in a separate host-thread and the calling AmigaOS task is put to sleep, until the host thread returns.
Yes... that's that Toni said...

Quote:
Originally Posted by Der Wanderer View Post
However, whatever you guys do, keep it simple.
No matter how you look at it, stuff like this is always going to be a bit difficult. You have to be familiar with compilers and build environments on both Amiga and native side (and be able to build dynamic libraries for one or more platforms). And you need to know about byte order, and struct packing/padding if you pass those. But convenient header files and good examples helps a lot... -And I don't see any reason why it would become more difficult than it already is.

Quote:
Originally Posted by Der Wanderer View Post
You could push the idea further and patch OpenLibrary in a way that it can open directly DLL or SO.
Most (all?) operating systems use memory mapped files for dynamically loaded libraries. So the library must exist on the host file system. There is of course nothing which prevents a theoretical native interface from allowing the Amiga to temporarily or permanently copy a dynamic library to the host file system (with security implications of course). There are also other possible approaches for code which does not need to use the host dynamic loader to access other native libraries (did you read my previous post?).

Quote:
Originally Posted by Der Wanderer View Post
Just design it is a way it works for once and for all. If the version number doesn't match, there is anyway not much you can do.
Designing it once and for all "never" works in real life. It is important to be able to add new features without breaking older libraries (but I also think you misunderstood what I meant with the version number in that context. It could be used by a newer library to gracefully support older *UAE versions for example if some feature or functionality is optional).
FrodeSolheim is offline  
 
Page generated in 0.06239 seconds with 9 queries