Affix

 view release on metacpan or  search on metacpan

dyncall/doc/manual/callconvs/callconv_mips32.tex  view on Meta::CPAN

\paragraph{Overview}

Multiple revisions of the MIPS Instruction set exist, namely MIPS I, MIPS II, MIPS III, MIPS IV, MIPS32 and MIPS64.
Nowadays, MIPS32 and MIPS64 are the main ones used for 32-bit and 64-bit instruction sets, respectively.\\
Given MIPS processors are often used for embedded devices, several add-on extensions exist for the MIPS family, for example: 

\begin{description}
\item [MIPS-3D] simple floating-point SIMD instructions dedicated to common 3D tasks.
\item [MDMX] (MaDMaX) more extensive integer SIMD instruction set using 64 bit floating-point registers.
\item [MIPS16e] adds compression to the instruction stream to make programs take up less room (allegedly a response to the THUMB instruction set of the ARM architecture).
\item [MIPS MT] multithreading additions to the system similar to HyperThreading.
\end{description}

Unfortunately, there is actually no such thing as "The MIPS Calling Convention". Many possible conventions are used
by many different environments such as \emph{O32}\cite{MIPSo32}, \emph{O64}\cite{MIPSo64}, \emph{N32}\cite{MIPSn32/n64}, \emph{N64}\cite{MIPSn32/n64}, \emph{EABI}\cite{MIPSeabi} and \emph{NUBI}\cite{MIPSnubi}.\\

\paragraph{\product{dyncall} support}

Currently, dyncall supports for MIPS 32-bit architectures the widely-used O32 calling convention (for all four combinations of big/little-endian, and soft/hard-float targets),
as well as EABI (little-endian/hard-float, which is used on the Homebrew SDK for the Playstation Portable). \product{dyncall} currently does not support MIPS16e
(contrary to the like-minded ARM-THUMB, which is supported). Both, calls and callbacks are supported.

dyncall/doc/manual/callconvs/callconv_ppc64.tex  view on Meta::CPAN

Name                & Brief description\\
\hline
{\bf gpr0}          & scratch\\
{\bf gpr1}          & stack pointer\\
{\bf gpr2}          & TOC base ptr (offset table and data for position independent code), scratch\\
{\bf gpr3}          & return value, parameter 0 for integer or pointer, scratch\\
{\bf gpr4-gpr10}    & parameter 1-7 for integer or pointer parameters, scratch\\

{\bf gpr11}         & env pointer if needed, scratch\\
{\bf gpr12}         & used for exception handling and glink code, scratch\\
{\bf gpr13}         & used for system thread ID, preserve\\
{\bf gpr14-31}      & preserve\\
{\bf fpr0}          & scratch\\
{\bf fpr1-fpr4}     & floating point return value, floating point parameter 0-3 (always double precision)\\
{\bf fpr5-fpr13}    & floating point parameters 4-12 (always double precision)\\
{\bf fpr14-fpr31}   & preserve\\
{\bf v0-v1}         & scratch\\
{\bf v2-v13}        & vector parameters\\
{\bf v14-v19}       & scratch\\
{\bf v20-v31}       & preserve\\
{\bf lr}            & link-register, scratch\\

dyncall/doc/manual/manual_epilog.tex  view on Meta::CPAN

meaning no required runtime dependencies and usually only the necessary tools
to build the library as build-time dependencies, like a compiler and assembler,
linker, etc..
The library uses some heap-memory to store the CallVM and uses by default the
platform's \capi{malloc()} and \capi{free()} calls. However, providing custom
\capi{dcAllocMem} and \capi{dcFreeMem} C-preprocessor definitions will override
the default behaviour.
See \shell{dyncall/dyncall\_alloc.h} for details.


\subsection{Multi-threading}

The \product{dyncall} library is thread-safe and reentrant, by means that it
works correctly during execution of multiple threads if, and only if there is
at most a single thread pushing arguments to one CallVM. Since there's no
limitation on the number of created CallVM objects, it is recommended to keep a
copy per thread if mutliple threads make use of \product{dyncall} in parallel.
Invoking the call should always be thread-safe, however, whether the called
function is thread-safe is up to the programmer to verify, of course.

\subsection{Supported types}

Currently, the \product{dyncall} library supports all of ANSI C's integer,
floating point and pointer types as function call arguments and return values.
Additionally, C++'s \capi{bool} and C99's \capi{\_Bool} types are supported
across all supported platforms.
Due to the still rare and often incomplete support of the \capi{long double}
type on various platforms, the latter is currently not officially supported.
Also, \capi{\_Complex} is currently not supported.

dyncall/dynload/dynload.3  view on Meta::CPAN

and
.Fn dlSymsNameFromValue
are used to lookup symbol names using an index or symbol's address, respectively, returning a null pointer on error. The names are returned as they would appear in C source code (mangled if C++, etc.). The address passed to
.Fn dlSymsNameFromValue
must point to a loaded symbol.
.Sh NOTES
.Fn dlLoadLibrary
does handle loading dylibs on macos >= 11.0.1 that aren't on the file system but are provided through the OS' "built-in dynamic linker cache of all system-provided libraries" (to load, use same "path" as one would with dlopen(3)).
.Sh BUGS
.Fn dlGetLibraryPath
is not thread-safe on Darwin (macOS, iOS, ...) and OpenBSD.
.Pp
.Fn dlSymsInit
is not thread-safe on Darwin.
.Pp
.Fn dlGetLibraryPath
will not work on the following platforms when the library in question doesn't have the (default)
.Fn _init
and
.Fn _fini
symbols exported (rare, but possible): Haiku (all versions), OpenBSD < 3.7, NetBSD < 5.1, FreeBSD < 4.8
.Pp
Getting the executable's path by passing NULL in
.Ar pLib

dyncall/test/common/platformInit.c  view on Meta::CPAN

  sceKernelSleepThreadCB();
  return 0;
}

void dcTest_initPlatform()
{
  pspDebugScreenInit();
  pspDebugScreenClear();

  int thid = 0;
  thid = sceKernelCreateThread("update_thread", &CallbackThread, 0x11, 0xFA0, THREAD_ATTR_USER, 0);
  if (thid >= 0)
      sceKernelStartThread(thid, 0, 0);

  sceDisplayWaitVblankStart();
  pspDebugScreenSetXY(0, 0);
}

void dcTest_deInitPlatform()
{
  sceKernelSleepThread();