Affix
view release on metacpan or search on metacpan
builder/Affix.pm view on Meta::CPAN
chdir $cwd->stringify;
}
else {
die sprintf 'Failed to download %s: %s!', $response->{url}, $response->{content}
unless $response->{success};
}
}
}
}
sub process_xs {
my ( $source, %opt ) = @_;
die "Can't build xs files under --pureperl-only\n" if $opt{'pureperl-only'};
my $DEBUG = 0;
warn $@ if $@;
my ( undef, @parts ) = splitdir( dirname($source) );
push @parts, my $file_base = basename( $source, '.xs' );
my $archdir = catdir( qw/blib arch auto/, @parts );
my $tempdir = 'temp';
my $c_file = catfile( $tempdir, "$file_base.cxx" );
require ExtUtils::ParseXS;
mkpath( $tempdir, $opt{verbose}, oct '755' );
ExtUtils::ParseXS::process_file(
prototypes => 1,
linenumbers => 1,
'C++' => 1,
filename => $source,
prototypes => 1,
output => $c_file
);
my $version = $opt{meta}->version;
require ExtUtils::CBuilder;
my $builder = ExtUtils::CBuilder->new( config => ( $opt{config}->values_set ) );
builder/Affix.pm view on Meta::CPAN
}
my %modules = map { $_ => catfile( 'blib', $_ ) } find( qr/\.p(?:m|od)$/, 'lib' );
my %scripts = map { $_ => catfile( 'blib', $_ ) } find( qr//, 'script' );
my %shared = map {
$_ => catfile( qw/blib lib auto share dist/, $opt{meta}->name, abs2rel( $_, 'share' ) )
} find( qr//, 'share' );
pm_to_blib( { %modules, %scripts, %shared }, catdir(qw/blib lib auto/) );
make_executable($_) for values %scripts;
mkpath( catdir(qw/blib arch/), $opt{verbose} );
alien(%opt);
process_xs( $_, %opt ) for find( qr/.xs$/, 'lib' );
if ( $opt{install_paths}->install_destination('bindoc') &&
$opt{install_paths}->is_default_installable('bindoc') ) {
manify(
$_,
catfile( 'blib', 'bindoc', man1_pagename($_) ),
$opt{config}->get('man1ext'), \%opt
) for keys %scripts;
}
if ( $opt{install_paths}->install_destination('libdoc') &&
$opt{install_paths}->is_default_installable('libdoc') ) {
dyncall/ChangeLog view on Meta::CPAN
o rbdc: fixed and extended ruby bindings
o shdc: renamed shell binding to shdc and added feature to list shared-objects' symbols
Version 0.7 (2012/01/02)
architecture:
o added subproject: portasm - portable (GNU AS,+Apple and MASM) assembly framework
o added subproject: autovar - predefined macro framework (was dyncall_macros.h)
o added support for Solaris and SunPro compiler for i386, x86_64, sparc and sparc64
o improved auto-detection via preprocessor defines
dyncall:
o uses portasm (GNU,Apple,Microsoft) common sources for x86,x64,ppc32,arm32_arm
o added support for sparc (32-bit) (tested on linux/debian,openbsd,solaris)
o added support for sparc (64-bit) (tested on linux/debian,openbsd,solaris)
o bug fixes for x64/win64 calling convention
o added support for mingw32-w64 on x64
o improved cdecl x86 calling convention: stack always 16 byte aligned
o updated API and initial support for structs (for x86/AMD64)
o initial support for syscalls on x86, added x86 int80h linux/bsd
o added Minix port (stable)
dyncall/ToDo view on Meta::CPAN
--------
- dyncall sparc v7/v8: -xO3 on SunPro segfaults in tests (observed years ago)
- callbacks and use of CC signature characters (only x86 has any support for different CCs for callbacks):
* support for arm (arm/thumb on same platform)
* check if ellipsis support is needed (is there any need for calling back into an ellipse function?)
* check if syscalls support is needed (is there any need for calling back into a syscall?)
- think about using 'inline' for all/most dyncall_api.c functions?
- support for where syscalls originate from on OpenBSD: http://undeadly.org/cgi?action=article;sid=20191202105849
- merge arm32_thumb_{gas/apple} and include thumb support for portasm
- x64 verification: return values are passed via RAX and RDX, and XMM0 and XMM1.
- find big endian arm box (also hardfloat), e.g. cubietruck: http://blog.netbsd.org/tnf/entry/working_arm_multiprocessor_support
- test if armhf/thumb is actually working... pulls in arm mode code in dyncall_callvm.c
- dyncall_call_mips_n32.h and dyncall_call_mips_n64.h are pretty much the same, share code
- support for return values: aggregate return values on non-x64
- support for argument values: aggregates on non-x64, vector types, long double (c89)
* make sure that struct support for ellipsis calls are not forgotten (copy everything by value)
- support for argument values: _Complex (c99)
- support for argument values: Fixed-width integer types (c99) - could be just aliases but would help abstracting it away from library users
- other syscalls
- test MIPS32 eabi big endian (current port works on psp, which is little endian)
- implement MIPS64 N32 (gcc -mabi=n32); both, little and big-endian (looks like NetNBSD on and
dyncall/ToDo view on Meta::CPAN
- support for Minix/arm
- improve ellipsis test:
* test not just with one fixed arg, to also simulate alignment problems
* test return values
* convert from c++ to c, to have it also on plan9, and more portability
dynload:
--------
- investigate issue where if dlGetLibraryPath() is called from within a .so,
passing NULL will return .so name, whereas passing result of
dlLoadLibrary(NULL) returns process' name
- dlGetLibraryPath: dl_iterate_phdr() used on OpenBSD, but not available on version < 3.7
- bug: test/nm crashes on qemu mips linux o32 debian etch
- rename SymsInit to InitSyms and similar for cleanup function to reflect naming
in dyncall
- get rid of Dl_info and friends (_GNU_SOURCE) in dynload/dynload_syms_elf.c
for implementation of dlSymsNameFromValue(..)
- check if PSP can support dynload (missing elf.h, dlfcn.h, etc.); fixup readme if successful
- some functionality like java's System.mapLibraryName('name') might be helpful?
- Failed On Open Solaris 11:
In file included from dynload_syms.c:28:
dyncall/ToDo view on Meta::CPAN
regressions:
------------
- Solaris/gmake build doesn't build dynload and tests anymore (maybe not even dyncallback)
- look over code and fix TODO or @@@ marks
nice to have:
-------------
- update: microsoft visual c++ build files - integrate all test suites in solution file
- consistency: on x64 platforms: make both ABIs available ('win64','sysv') for all x64 OS ports
- microsoft build enhancement: autodetect assembly via C preprocessor (like with .S gcc files)
- test/thunk: some platforms do not allow for allocation of executable code on heap and stack --
currently this test will segfault (handled), maybe we should collect information which platforms allow and which not.
- PSP
- automate ppsspp stuff, seems to print to stdout for callback_suite? but not for call_suite.. (?)
- fix link with dummy versions of the following for test-bins:
void __stack_chk_fail(){}
void __stack_chk_guard(){}
bugs:
-----
dyncall/buildsys/cmake/Modules/UseLATEX.cmake view on Meta::CPAN
# Adds targets that compile <tex_file>. The latex output is placed
# in LATEX_OUTPUT_PATH or CMAKE_CURRENT_BINARY_DIR if the former is
# not set. The latex program is picky about where files are located,
# so all input files are copied from the source directory to the
# output directory. This includes the target tex file, any tex file
# listed with the INPUTS option, the bibliography files listed with
# the BIBFILES option, and any .cls, .bst, and .clo files found in
# the current source directory. Images found in the IMAGE_DIRS
# directories or listed by IMAGES are also copied to the output
# directory and coverted to an appropriate format if necessary. Any
# tex files also listed with the CONFIGURE option are also processed
# with the CMake CONFIGURE_FILE command (with the @ONLY flag. Any
# file listed in CONFIGURE but not the target tex file or listed with
# INPUTS has no effect. DEPENDS can be used to specify generated files
# that are needed to compile the latex target.
#
# The following targets are made:
# dvi: Makes <name>.dvi
# pdf: Makes <name>.pdf using pdflatex.
# safepdf: Makes <name>.pdf using ps2pdf. If using the default
# program arguments, this will ensure all fonts are
dyncall/buildsys/cmake/Modules/UseLATEX.cmake view on Meta::CPAN
FILE(READ ${filename} file_contents)
STRING(REGEX MATCHALL "${regexp}"
${variable} ${file_contents}
)
IF (NOT ${variable})
SET(${variable} "${default}")
ENDIF (NOT ${variable})
ENDMACRO(LATEX_FILE_MATCH)
#############################################################################
# Macros that perform processing during a LaTeX build.
#############################################################################
MACRO(LATEX_MAKEGLOSSARIES)
MESSAGE("**************************** In makeglossaries")
IF (NOT LATEX_TARGET)
MESSAGE(SEND_ERROR "Need to define LATEX_TARGET")
ENDIF (NOT LATEX_TARGET)
IF (NOT MAKEINDEX_COMPILER)
MESSAGE(SEND_ERROR "Need to define MAKEINDEX_COMPILER")
ENDIF (NOT MAKEINDEX_COMPILER)
dyncall/buildsys/cmake/Modules/UseLATEX.cmake view on Meta::CPAN
# If we still need to convert, do it.
IF (do_convert)
LATEX_ADD_CONVERT_COMMAND(${output_dir}/${output_file}
${input_dir}/${input_file} ${output_extension} ${extension}
"${convert_flags}")
SET(${output_files} ${${output_files}} ${output_dir}/${output_file})
ENDIF (do_convert)
ENDIF (is_type)
ENDMACRO(LATEX_CONVERT_IMAGE)
# Adds custom commands to process the given files for dvi and pdf builds.
# Adds the output files to the given variables (does not replace).
MACRO(LATEX_PROCESS_IMAGES dvi_outputs pdf_outputs)
LATEX_GET_OUTPUT_PATH(output_dir)
FOREACH(file ${ARGN})
IF (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/${file}")
GET_FILENAME_COMPONENT(extension "${file}" EXT)
SET(convert_flags)
# Check to see if we need to downsample the image.
LATEX_LIST_CONTAINS(is_raster extension
dyncall/buildsys/vs2005/dyncall/dyncall.vcproj view on Meta::CPAN
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
Optimization="0"
PreprocessorDefinitions="WIN32;_DEBUG;_CONSOLE"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="3"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="4"
/>
<Tool
Name="VCManagedResourceCompilerTool"
dyncall/buildsys/vs2005/dyncall/dyncall.vcproj view on Meta::CPAN
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG;_CONSOLE"
RuntimeLibrary="2"
UsePrecompiledHeader="0"
WarningLevel="3"
Detect64BitPortabilityProblems="true"
DebugInformationFormat="3"
/>
<Tool
Name="VCManagedResourceCompilerTool"
/>
<Tool
dyncall/configure.rc view on Meta::CPAN
if(~ $#CONFIG_ASM 0) {
guess_asm
if(~ $#CONFIG_ASM 0) {
error 'no assembler tool'
}
}
}
# --- process arguments ------------------------------------------------------
fn args {
while(! ~ $#* 0 && ~ $1 -*) {
OPT=$1
shift
switch($OPT) {
case --help -h
usage
#case --target-x86
dyncall/doc/README.Minix view on Meta::CPAN
2) or using build script for gcc (using Makefile.generic):
$ sh buildsys/scripts/batch-build-minix.sh
Minix facts:
------------
- posix make
- ACK (Amsterdam Compiler Kit) compiler for C, Modula-2 and Pascal
using own Assembly format
- ACK Assembler:
if very first character is '#' - C preprocessor is run..
- Minix 32-bit:
- ACK 32-bit compiler: long long is not supported
- Minix 16-bit: not yet reviewed...
dyncall/doc/README.NDS view on Meta::CPAN
Build instructions for DynCall on Nintendo DS
using devkitPro and NMake under Windows
=============================================
To build the library, you have to configure it first.
Since the NDS build uses devkitPro and NMake, assure
to have them in your %PATH%.
To configure the library, call one of the following,
depending if you want to use the processor in ARM or
THUMB mode:
configure.bat /tool-gcc /target-nds-arm
configure.bat /tool-gcc /target-nds-thumb
Note that the /tool-gcc flag is needed, because we're
using devkitARM (via devkitPro) which is based on the
GCC toolchain. The /target-nds-* flags don't imply
this.
dyncall/doc/README.embedded view on Meta::CPAN
----------
During the preparation for the public release of the R package 'rdyncall' I was
looking for a way to get DynCall integrated into an existing Make system such
as offered by R for build R packages.
It was inspired by the make files of Lua which are damn simple and
don't need a configure but a user that knows the target platform name.
The source package can be configured automatically during compilation and
does not require explicit configuration anymore using "*.S" files that
are Assembly files which are preprocessed by the C Preprocessor.
This feature is available by GCC and SunPro compilers.
Limitations
-----------
Mac OS X universal static libraries require to use
'libtool -static -o libname.a obj1.o obj2.o ...' instead of 'ar cru libname.a obj1.o obj2.o'.
We use predefined variables AR and ARFLAGS.
dyncall/doc/manual/Makefile.generic view on Meta::CPAN
# use the multirow package are rendered into .pngs for our html doc, we don't
# need any tex4ht specific version outputing html
cd "${VPATH}" && ( \
:>./multirow.4ht; \
cp $$(dirname $$(which tex4ht))/../share/texmf-dist/tex4ht/base/unix/tex4ht.env ./custom_tex4ht.env; \
sed -E -i '' 's/(Text|Graphics)(AlphaBits)=[1,2,3]([^0-9])/\1\2=4\3/g' custom_tex4ht.env; \
mkdir -p ./html/; \
htlatex manual.tex manual_tex4ht " -cunihtf -e./custom_tex4ht.env -utf8" "-e./custom_tex4ht.env -d./html/"; \
rm ./html/*.css; \
)
# Postprocessing. Inject menu into output html pages. Replace some pieces, etc..
for f in "${VPATH}/html/"*.html; do \
sed -E -i '' $$'s/([[:space:]]class=["\'])lstlisting(["\'])/\\1ttDiv\\2/' "$$f"; \
done
manual.pdf: sources
# run twice for toc on some tex installs
cd "${VPATH}" && for i in 1 2; do pdflatex -output-directory="${PWD}" manual.tex; done
dyncall/doc/manual/callconvs/callconv_arm32.tex view on Meta::CPAN
% WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
% ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
% OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
%
%//////////////////////////////////////////////////////////////////////////////
\subsection{ARM32 Calling Conventions}
\paragraph{Overview}
The ARM32 family of processors is based on the Advanced RISC Machines (ARM)
processor architecture (32 bit RISC).
The word size is 32 bits (and the programming model is LLP64).\\
Basically, this family of microprocessors can be run in 2 major modes:\\
\\
\begin{tabular*}{0.95\textwidth}{2 B}
Mode & Description\\
\hline
{\bf ARM} & 32bit instruction set\\
{\bf THUMB} & compressed instruction set using 16bit wide instruction encoding\\
\end{tabular*}
\\
\\
For more details, take a look at the ARM-THUMB Procedure Call Standard (ATPCS)
dyncall/doc/manual/callconvs/callconv_arm32.tex view on Meta::CPAN
like the ARM Jazelle Technology (direct Java bytecode execution, providing
acceleration for some bytecodes while calling software code for others), etc.,
are not supported by the dyncall library.\\
\subsubsection{ATPCS ARM mode}
\paragraph{Registers and register usage}
In ARM mode, the ARM32 processor has sixteen 32 bit general purpose registers, namely r0-r15:\\
\\
\begin{table}[h]
\begin{tabular*}{0.95\textwidth}{lll}
Name & Alias & Brief description\\
\hline
{\bf r0} & {\bf a1} & parameter 0, scratch, return value\\
{\bf r1} & {\bf a2} & parameter 1, scratch, return value\\
{\bf r2,r3} & {\bf a3,a4} & parameters 2 and 3, scratch\\
{\bf r4-r9} & {\bf v1-v6} & permanent\\
{\bf r10} & {\bf sl} & permanent\\
dyncall/doc/manual/callconvs/callconv_arm32.tex view on Meta::CPAN
\begin{itemize}
\item stack parameter order: right-to-left
\item caller cleans up the stack
\item first four words are passed using r0-r3
\item subsequent parameters are pushed onto the stack (in right to left order, such that the stack pointer points to the first of the remaining parameters)
\item if the callee takes the address of one of the parameters and uses it to address other parameters (e.g. varargs) it has to copy - in its prolog - the first four words to a reserved stack area adjacent to the other parameters on the stack
\item parameters \textless=\ 32 bits are passed as 32 bit words
\item 64 bit parameters are passed as two 32 bit parts (even partly via the register and partly via the stack, although this doesn't seem to be specified in the ATPCS)
\item aggregates (struct, union) are passed by value (after rounding up the size to the nearest multiple of 4), as a sequence of words (splitting across registers and stack is allowed)
\item {\it non-trivial} C++ aggregates (as defined by the language) of any size, are passed indirectly via a pointer to a copy of the aggregate
\item keeping the stack eight-byte aligned can improve memory access performance and is required by LDRD and STRD on ARMv5TE processors which are part of the ARM32 family, so, in order to avoid problems one should always align the stack (tests have s...
\end{itemize}
\paragraph{Return values}
\begin{itemize}
\item return values \textless=\ 32 bits use r0
\item 64 bit return values use r0 and r1
\item for {\it non-trivial} C++ aggregates, the caller allocates space, passes pointer to it to the callee as a hidden first param
(meaning in r0), and callee writes return value to this space; the ptr to the aggregate is returned in r0
\item aggregates (struct, union) \textless=\ 32 bits are returned like an integer (in r0)
dyncall/doc/manual/callconvs/callconv_arm32.tex view on Meta::CPAN
\clearpage
\subsubsection{ATPCS THUMB mode}
\paragraph{Status}
\paragraph{Registers and register usage}
In THUMB mode, the ARM32 processor family supports eight 32 bit general purpose registers r0-r7 and access to high order registers r8-r15:\\
\\
\begin{table}[h]
\begin{tabular*}{0.95\textwidth}{lll}
Name & Alias & Brief description\\
\hline
{\bf r0} & {\bf a1} & parameter 0, scratch, return value\\
{\bf r1} & {\bf a2} & parameter 1, scratch, return value\\
{\bf r2,r3} & {\bf a3,a4} & parameters 2 and 3, scratch\\
{\bf r4-r6} & {\bf v1-v3} & permanent\\
{\bf r7} & {\bf v4} & frame pointer, permanent\\
dyncall/doc/manual/callconvs/callconv_arm32.tex view on Meta::CPAN
\begin{itemize}
\item stack parameter order: right-to-left
\item caller cleans up the stack
\item first four words are passed using r0-r3
\item subsequent parameters are pushed onto the stack (in right to left order, such that the stack pointer points to the first of the remaining parameters)
\item if the callee takes the address of one of the parameters and uses it to address other parameters (e.g. varargs) it has to copy - in its prolog - the first four words to a reserved stack area adjacent to the other parameters on the stack
\item parameters \textless=\ 32 bits are passed as 32 bit words
\item 64 bit parameters are passed as two 32 bit parts (even partly via the register and partly via the stack, although this doesn't seem to be specified in the ATPCS)
\item aggregates (struct, union) are passed by value (after rounding up the size to the nearest multiple of 4), as a sequence of words (splitting across registers and stack is allowed)
\item {\it non-trivial} C++ aggregates (as defined by the language) of any size, are passed indirectly via a pointer to a copy of the aggregate
\item keeping the stack eight-byte aligned can improve memory access performance and is required by LDRD and STRD on ARMv5TE processors which are part of the ARM32 family, so, in order to avoid problems one should always align the stack (tests have s...
\end{itemize}
\paragraph{Return values}
\begin{itemize}
\item return values \textless=\ 32 bits use r0
\item 64 bit return values use r0 and r1
\item for {\it non-trivial} C++ aggregates, the caller allocates space, passes pointer to it to the callee as a hidden first param
(meaning in r0), and callee writes return value to this space; the ptr to the aggregate is returned in r0
\item aggregates (struct, union) \textless=\ 32 bits are returned like an integer (in r0)
dyncall/doc/manual/callconvs/callconv_arm64.tex view on Meta::CPAN
% WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
% ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
% OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
%
%//////////////////////////////////////////////////////////////////////////////
\subsection{ARM64 Calling Conventions}
\paragraph{Overview}
ARMv8 introduced the AArch64 calling convention. ARM64 chips can be run in 64 or 32bit mode, but not by the same process. Interworking is only intra-process.\\
The word size is defined to be 32 bits, a dword 64 bits. Note that this is due to historical reasons (terminology didn't change from ARM32).\\
For more details, take a look at the Procedure Call Standard for the ARM 64-bit Architecture \cite{AAPCS64}.\\
\paragraph{\product{dyncall} support}
The \product{dyncall} library supports the ARM 64-bit AArch64 PCS ABI, as well as Apple's and Microsoft's conventions which are derived from it, for both, calls and callbacks.
\subsubsection{AAPCS64 Calling Convention}
\paragraph{Registers and register usage}
dyncall/doc/manual/callconvs/callconv_mips32.tex view on Meta::CPAN
% OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
%
%//////////////////////////////////////////////////////////////////////////////
\subsection{MIPS32 Calling Conventions}
\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}.\\
dyncall/doc/manual/callconvs/callconv_sparc32.tex view on Meta::CPAN
% WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
% ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
% OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
%
%//////////////////////////////////////////////////////////////////////////////
\subsection{SPARC Calling Conventions}
\paragraph{Overview}
The SPARC family of processors is based on the SPARC instruction set architecture, which comes in basically three revisions,
V7, V8\cite{SPARCV8}\cite{SPARCSysV} and V9\cite{SPARCV9}\cite{SPARCV9SysV}. The former two are 32-bit whereas the latter refers to the 64-bit SPARC architecture (see next chapter).
SPARC uses big endian byte order.\\
The word size is defined to be 32 bits.
\paragraph{\product{dyncall} support}
\product{dyncall} fully supports the SPARC 32-bit instruction set (V7 and V8), for calls and callbacks.
\subsubsection{SPARC (32-bit) Calling Convention}
dyncall/doc/manual/callconvs/callconv_sparc64.tex view on Meta::CPAN
% WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
% ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
% OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
%
%//////////////////////////////////////////////////////////////////////////////
\subsection{SPARC64 Calling Conventions}
\paragraph{Overview}
The SPARC family of processors is based on the SPARC instruction set architecture, which comes in basically three revisions,
V7, V8\cite{SPARCV8}\cite{SPARCSysV}\cite{SPARCCD} and V9\cite{SPARCV9}\cite{SPARCV9SysV}\cite{SPARCCD}. The former two are 32-bit (see previous chapter) whereas the latter refers to the 64-bit SPARC architecture.
SPARC uses big endian byte order, however, V9 supports also little endian byte order, but for data access only, not instruction access.\\
\\
There are two proposals, one from Sun and one from Hal, which disagree on how to handle some aspects of this calling convention.\\
\paragraph{\product{dyncall} support}
\product{dyncall} fully supports the SPARC 64-bit instruction set (V9), for calls and callbacks.
\subsubsection{SPARC (64-bit) Calling Convention}
dyncall/doc/manual/callconvs/callconv_x64.tex view on Meta::CPAN
% x64
% ==================================================
\subsection{x64 Calling Conventions}
\paragraph{Overview}
The x64 (64bit) architecture designed by AMD is based on Intel's x86 (32bit)
architecture, supporting it natively. It is sometimes referred to as x86-64,
AMD64, or, cloned by Intel, EM64T or Intel64.\\
On this processor, a word is defined to be 16 bits in size, a dword 32 bits
and a qword 64 bits. Note that this is due to historical reasons (terminology
didn't change with the introduction of 32 and 64 bit processors).\\
The x64 calling convention for MS Windows \cite{x64Win} differs from the
SystemV x64 calling convention \cite{x64SysV} used by Linux/*BSD/...
Note that this is not the only difference between these operating systems. The
64 bit programming model in use by 64 bit windows is LLP64, meaning that the C
types int and long remain 32 bits in size, whereas long long becomes 64 bits.
Under Linux/*BSD/... it's LP64.\\
\\
Compared to the x86 architecture, the 64 bit versions of the registers are
called rax, rbx, etc.. Furthermore, there are eight new general purpose
registers r8-r15.\\
dyncall/doc/manual/callconvs/callconv_x86.tex view on Meta::CPAN
%//////////////////////////////////////////////////////////////////////////////
% ==================================================
% x86
% ==================================================
\subsection{x86 Calling Conventions}
\paragraph{Overview}
On this processor, a word is defined to be 16 bits in size, a dword 32 bits
and a qword 64 bits.\\
There are numerous different calling conventions on the x86 processor
architecture, like cdecl \cite{x86cdecl}, MS fastcall \cite{x86Winfastcall}, GNU
fastcall \cite{x86GNUfastcall}, Borland fastcall \cite{x86Borlandfastcall}, Watcom
fastcall \cite{x86Watcomfastcall}, Win32 stdcall \cite{x86Winstdcall}, MS thiscall
\cite{x86Winthiscall}, GNU thiscall \cite{x86GNUthiscall}, the pascal calling
convention \cite{x86Pascal} and a cdecl-like version for Plan9 \cite{x86Plan9}
(dubbed plan9call by us), etc.\\
\begin{table}[h]
\begin{tabular*}{0.95\textwidth}{rccccc}
& \# of regs & \# regs to & & cleanup & 64bit args \\
dyncall/doc/manual/manual_build.tex view on Meta::CPAN
\item C++ compiler to build the optional test cases (GCC, Clang, SunPro or Microsoft C/C++ compiler)
\item BSD make, GNU make, Microsoft nmake or mk (on Plan9) as automated build tools
\item Python (optional - for generation of some test cases)
\item Lua (optional - for generation of some test cases)
\item CMake (optional support)
\end{itemize}
\subsection{Supported/tested platforms and build systems}
Building \product{dyncall} is a straightforward two-step process, first configure, then make. The
library should be able to be built with the default operating systems' build tools, so BSD make on
BSD and derived systems, GNU make on GNU and compatible, mk on Plan9, nmake on Windows, etc..
This is a detailed overview of platforms and their build tools that are known to build
\product{dyncall}:\\
\\
\begin{tabular*}{0.75\textwidth}{lll}
\textbf{Platform} & Build Tool(s) & Compiler, SDK \\
\hline
dyncall/doc/manual/manual_dyncall_api.tex view on Meta::CPAN
%
%\paragraph{Types}
%
%\begin{lstlisting}[language=c]
%typedef void DCCallVM; /* abstract handle */
%\end{lstlisting}
%
%\paragraph{Details}
%The \emph{CallVM} is a state machine that manages all aspects of a function
%call from configuration, argument passing up the actual function call on
%the processor.
%
%\subsection{Allocation}
%
%\paragraph{Functions}
%
%\begin{lstlisting}[language=c]
%DCCallVM* dcNewCallVM (DCsize size);
%void dcFree(DCCallVM* vm);
%\end{lstlisting}
%
dyncall/doc/manual/manual_epilog.tex view on Meta::CPAN
\subsection{Embedding}
The \product{dyncall} library strives to have a minimal set of dependencies,
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
dyncall/doc/manual/manual_motivation.tex view on Meta::CPAN
The C programming language and its direct derivatives are limited in the way
function calls are handled. A C compiler regards a function call as a
fully qualified atomic operation. In such a statically typed environment, this
includes the function call's argument arity and type, as well as the
return type.\\
\subsection{Anatomy of machine-level calls}
The process of calling a function on the machine level yields a common pattern:
\begin{enumerate}
\item The target function's calling convention dictates how the stack is
prepared, arguments are passed, results are returned and how to clean up
afterwards.
\item Function call arguments are loaded in registers and on the stack according
to the calling convention that take alignment constraints into account.
\item Control flow transfer from caller to callee.
\item Process return value, if any. Some calling conventions specify that
the caller is responsible for cleaning up the argument stack.
\end{enumerate}
\newpage
%\paragraph{Example}
The following example depicts a C source and the corresponding assembly for the X86 32-bit processor architecture.
\begin{lstlisting}[label=cfuncall,caption=C function call,language=C]
extern void f(int x, double y,float z);
void caller()
{
f(1,2.0,3.0f);
}
\end{lstlisting}
dyncall/doc/manual/manual_motivation.tex view on Meta::CPAN
\begin{comment}
Due to the statically compiled nature of the
language itself, the abstraction to the underlying hardware machine
These languages make an abstraction to the machine in a way, where a function
call is an atomic operation that has to be fully qualified at compilation time.
This library follows the approach to abstract the construction of a function call
and provides a small and clean implementation that is extendable by ports to
compilers, operating-systems and processor architectures.
The library solely uses a small kernel function to perform the actual call and
does not require just-in-time code generation.
General-purpose programming languages such as C\footnote{and derived programming
languages such as C++ and Objective-C} are powerful statically compiled
programming languages that allow to implement low-level tasks. They abstract
the underlying hardware to a degree where one is allowed to write functions
that implement algorithms. At the same time, this
Although C is very powerful and a portable language to implement time-critical
dyncall/doc/manual/manual_tex4ht.cfg view on Meta::CPAN
%% Don't want TOC to be on own page.
%\ConfigureToc{likesubsubsection}{}{~}{}{ }
% Here goes stuff that should be *before* <head>...</head>
% Use it for configurations, no actual output.
\Configure{VERSION}{}
\Configure{DOCTYPE}{\HCode{<!DOCTYPE html>\Hnewline}}
\Configure{HTML}{\HCode{<html>\Hnewline}}{\HCode{\Hnewline</html>}}
\Configure{BODY}{\HCode{\Hnewline<body>\Hnewline<div class="mainDiv">\Hnewline}}{\HCode{\Hnewline</div></body>}} % KEEP the body on it's own line, as it's used as a marker for postprocessing.
% TITLE+ is only on main page, other use section title. Prefix everything, though.
\Configure{TITLE}{\HCode{<title>}dyncall Manual - }{\HCode{</title>}}
\Configure{TITLE+}{Index}
% Clear default header, define our custom one. Using @HEAD will make this be used on all pages generated.
% @@@Ideally, this wouldn't be a copy&paste of the website's header, here. Such
% thing should be done in the website build, and this here a generic header
% (however, style is kinda needed).
\Configure{@HEAD}{}
dyncall/doc/manual/manual_tex4ht.cfg view on Meta::CPAN
{\HCode{<td \ifnum \HMultispan>1 colspan="\HMultispan"\fi >}}
{\HCode{</td>}}
% Remove hr-tags that tex4ht inserts by default in around floats (e.g. tables) and replace them with a background.
% Also remove hr-tags around figures, entirely.
\Configure{float}[]{\HCode{<div class='blockDiv'>}\HtmlParOff}{}{\HCode{</div>}\HtmlParOn}
\ConfigureEnv{figure}{\HCode{}}{\HCode{}}{}{}
% @@@ Did not get that below to work, and don't understand it, either.
% @@@ Default output is ok, so we're simply changing class name in
% @@@ instead of this postprocessing. See Makefile.
%% Listings, so that caption below isn't in same block
%\def\listingLineReset{\newcount\lstlineno}
%\def\listingLine{\advance\lstlineno by 1}
%\ConfigureEnv{lstlisting}{\listingLineReset\Tg<div class="ttDiv">}{\Tg</div>}{}{}
%\Configure{listings}{}{}{}{\ifnum \lstlineno>0 \Tg<br> \fi \listingLine}
% Make listing/table captions nicer.
\Configure{caption}
{\HCode{<div class="blockCaption"><small>}}
{\HCode{<span class="id">}}
dyncall/dyncall/README-Developer.txt view on Meta::CPAN
One assembly front-end *.S source file for all supported architectures:
Usage:
gcc -c dyncall_call.S -o dyncall_call.o
Advantages:
- works fine with universal binary builds (fat binaries), e.g.:
gcc -arch i386 -arch ppc -arch x86_64 -c dyncall_call.S -o dyncall_call.o
Details:
Simplified assembly file compilation via using a gigantic C Preprocessor switch include.
source file "dyncall_call.S" selects the appropriate GAS/Apple assembly file
"dyncall_call_<arch>_<asmtool>.[sS]".
archs so far:
arm32_thumb .s
arm32_arm .s
mips .s
ppc32 .s
dyncall/dyncall/README-Developer.txt view on Meta::CPAN
x86 .S [ uses C macros ]
asmtools:
gas - standard GNU assembler
apple - apple's assembler (based on GNU but is significantly different in syntax)
masm - Microsoft assembler x86 and x64
nasm - Netwide assembler for x86 and x64
NOTE: .S is used for preprocessing assembly files using gcc
.s is used directly with as
advantages:
- one way to build the kernel:
gcc -c dyncall_call.S -o dyncall_call.o
- we can build now universal binaries
dyncall/dyncall/README.txt view on Meta::CPAN
3. Call State Machine
4. Application Programming Interface
5. extension: high-level formatted C API (ellipsis style)
1. Call Kernel
Assembly Implementation:
gcc front-end: dyncall_call.S
uses the C preprocessor
will include the apropriate assembly source
architecture/tool specific sources:
dyncall_call_<ARCH>_<ASMTOOL>.[s|asm]
2. Utilities (memory and static sized vectors)
2.1 Memory Management
dyncall/dyncall/dyncall_call_mips_eabi_gas.s view on Meta::CPAN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/*//////////////////////////////////////////////////////////////////////
dyncall_call_mips_eabi_gas.s
MIPS 32bit family of processors.
2008-01-03
//////////////////////////////////////////////////////////////////////*/
.text
.globl dcCall_mips_eabi
dcCall_mips_eabi:
/* $4 target function */
/* $5 register data */
/* $6 stack size */
dyncall/dyncall/dyncall_call_sparc.s view on Meta::CPAN
/*
Package: dyncall
Library: dyncall
File: dyncall/dyncall_call_sparc.S
Description: Call kernel for sparc processor architecture.
License:
Copyright (c) 2011-2015 Daniel Adler <dadler@uni-goettingen.de>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
dyncall/dyncall/dyncall_callvm_arm32_arm.c view on Meta::CPAN
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/*
dyncall callvm for 32bit ARM32 family of processors
SUPPORTED CALLING CONVENTIONS
armcall
REVISION
2007/12/11 initial
*/
dyncall/dyncall/dyncall_callvm_arm32_arm.h view on Meta::CPAN
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/*
dyncall callvm for 32bit ARM32 family of processors
SUPPORTED CALLING CONVENTIONS
armcall
REVISION
2007/12/11 initial
*/
dyncall/dyncall/dyncall_callvm_arm32_arm_armhf.h view on Meta::CPAN
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/*
dyncall callvm for 32bit ARM32 family of processors
SUPPORTED CALLING CONVENTIONS
armcall
REVISION
2007/12/11 initial
*/
dyncall/dyncall/dyncall_callvm_arm32_thumb.c view on Meta::CPAN
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/*
dyncall callvm for 32bit ARM32 family of processors
SUPPORTED CALLING CONVENTIONS
armthumbcall
REVISION
2007/12/11 initial
*/
( run in 0.623 second using v1.01-cache-2.11-cpan-8d75d55dd25 )