View Single Post
Old 28 December 2013, 00:40   #9
FS-UAE Developer

FrodeSolheim's Avatar
Join Date: Dec 2011
Location: Førde, Norway
Age: 37
Posts: 3,418
@thellier It would probably be useful to be able to give the native libraries a list of function pointers it can use to call back to UAE. For example by adding function pointers to the struct passed as one parameter, or by giving a struct with pointers to a library initialization call. One such function could be void *get_real_address(uint32_t amiga_address)...

Regarding native code interface, embedded native code, and cross platform concerns:

There is a couple of quite different approaches for native code interfaces:

1. Allow Amiga-code to load/reference a dynamic library installed on the host, look up functions in the library and call them. The advantage here is that you're using the normal dynamic library support in the OS, so the library can further link to other system libraries and do useful stuff (such as calling Win32 functions on Windows, or interfacing with OpenGL on all platforms). But this also requires that a library is provided for all host architectures you want it to work with (i.e. separate libraries for windows-x86, windows-x86-64, linux-x86, linux-x86-64, macosx-x86, macosx-x86-64, etc). This is the native code interface approach currently implemented by WinUAE.

2. Another approach is to bypass the dynamic library support and just load native binary code into executable memory and allow the Amiga to execute it. This could allow a generic "x86 binary" to be loaded, and the same x86 code could work on Windows, Linux, and OS X (and other x86 platforms). It could for example be loaded from a .so file in ELF format. But note that for example x86-64 version of UAE would need separate x86-64 code. As this binary does not use the dynamic linker of the host OS, it will not be able to "easily" use other APIs on the host system. But it could be useful to for example use the host CPU as a kind of CPU accelerator, do heavy calculations, etc.

2a. The x86 (or another CPU architecture) binary blob could then in theory be loaded from Amiga memory. It could also in theory execute directly from emulated Amiga memory, but since we generally want to leave the execute bit off for these memory areas, it would be better to load (copy) the binary blob from Amiga memory to executable host memory before it runs. Of course, this has security implications, and "new Amiga viruses" could suddenly be a lot more scary... (and such a feature could never be enabled by default). It could of course be combined with some simple code signature verification so only code from user-white-listed authors would be loaded through such an interface.

2b. As a variant of 2., one could still allow somewhat easy access to other native libraries and APIs by providing the binary blob with a way to access some functions exported by UAE, such as "open_library", etc. (basically reinventing dynamic library loading, but possibly in a cross-platform way - as far as that is possible).

Approach (1) is by far the simplest and flexible in terms of what it can do But code delivery requires local libraries for all architectures. The other approaches are not especially difficult either, but definitively more work. There are many possibilities (and other approaches not mentioned here), depending on what one wants to achieve

Last edited by FrodeSolheim; 28 December 2013 at 00:50.
FrodeSolheim is offline  
Page generated in 0.17907 seconds with 9 queries