asm-polycall is the Assembly binding for Polycall, distributed through PyPI as source files. It is not a Python library: pip install asm-polycall places the binding's files (commit 106361362daa) inside the package. python -m asm_polycall path prints where they are and python -m asm_polycall extract DIR copies them out; build and use them as described below.

asm-polycall

GNU-assembler binding for the Polycall core, published as the npm source package asm-polycall.

src/asm_polycall.S is a set of tail-call shims over the core's binding ABI v1 (<polycall.h>, docs/BINDING_ABI.md in the core repository; requires polycall >= 1.1.0). Each shim leaves the caller's arguments where the platform C ABI put them and jumps to the real symbol; the two run_config shims additionally load the run constant into the second-argument register. No parsing, sockets or runtime logic live here.

C-callable API (include/asm_polycall.h)

Statuses, caller-owned buffers and handle rules are exactly the core's (POLYCALL_OK = 0, negative POLYCALL_E_*; nothing to free).

#include <asm_polycall.h>

if (asm_polycall_abi_version() != POLYCALL_FFI_ABI_VERSION) { /* refuse */ }
int status = asm_polycall_run_config("asm-polycallrc");
if (status != POLYCALL_OK) {
    char detail[512];
    asm_polycall_last_error(detail, sizeof detail);
    fprintf(stderr, "%s: %s\n", asm_polycall_strerror(status), detail);
}

Assembly callers use the same symbols with the platform C calling convention (leading underscore on Mach-O and 32-bit Windows).

Targets

make cross-check assembles every target with clang. Windows on ARM64 has its own COFF branch (the ELF-only .type/.size directives previously used there do not assemble for COFF). MSVC's cl/ml64 cannot assemble GNU .S files: on Windows build with MinGW gcc or clang. The resulting objects call the plain C ABI, so they also work against the MSVC build of the core (polycall.dll, linked through its polycall.lib).

Cross targets build with the target's compiler and a core built for it:

make CC=aarch64-linux-gnu-gcc PKG_CONFIG_PATH=<aarch64 prefix>/lib/pkgconfig \
     BUILD_DIR=build-aarch64 build-aarch64/asm_polycall_real_test
LD_LIBRARY_PATH=<aarch64 prefix>/lib sh tests/run-real.sh \
     qemu-aarch64 -L /usr/aarch64-linux-gnu build-aarch64/asm_polycall_real_test .

Build and test

The core is located with pkg-config:

export PKG_CONFIG_PATH=/opt/polycall/lib/pkgconfig LD_LIBRARY_PATH=/opt/polycall/lib
make             # lib/libasm_polycall.a
make test        # real-core test + interop with the polycall CLI
make test-loader # loader behaviour: no library, 1.0 library, ABI mismatch
make example     # examples/basic.c
make verify-dry  # thin-adapter audit

Windows, from an MSYS2 UCRT64 shell with an installed MinGW build of the core: set PKG_CONFIG_PATH=<prefix>/lib/pkgconfig and put <prefix>/bin (libpolycall.dll, polycall.exe) on PATH, then make test.

make test runs tests/run-real.sh, which starts polycall peer serve, polycall start and polycall daemon start (ephemeral ports, private state directory) and then the C test of every shim; it exits 77 (SKIP), never success, without the CLI or when any check was skipped. See tests/TESTS.md.

Loading the library

The shims link the core at build time, so the platform loader checks the library first: with no library the program does not start (Linux: exit 127, libpolycall.so.1: cannot open shared object file; Windows: STATUS_DLL_NOT_FOUND), and a 1.0 library without the ABI v1 symbols is refused (Linux: exit 127, undefined symbol: polycall_...; Windows: STATUS_ENTRYPOINT_NOT_FOUND). A library reporting another binding ABI is the caller's to refuse: compare asm_polycall_abi_version() with POLYCALL_FFI_ABI_VERSION first (see the example above). make test-loader checks all four cases.

npm source package

npm install asm-polycall

The CommonJS entry point only exposes absolute paths (assembly, publicHeader, makefile, config, manifest); it does not load libpolycall. The package is not yet published.

Author

Nnamdi Michael Okpala — okpalan@protonmail.com. MIT licensed, see LICENSE.