x86-64 assembler embedded in Python

The PyTorch MacOS build with NNPack is failing with: section __TEXT/__const address out of range for architecture x86_64

When upgrading the Xcode to latest 13.3.1, we see this behavior. The difference between Xcode 13.2.1 and 13.3 is that there are more boundary checks to prevent OOB reads.

The conv1x1.yp.o object file has malformed load commands: $ size -mlx conv1x1.py.o Segment __TEXT: 0x36f (vmaddr 0x0 fileoff 288) Section (__TEXT, __text): 0x2ef (addr 0x0 offset 288) Section (__TEXT, __const): 0x80 (addr 0x300 offset 1088) total 0x36f total 0x36f __const section starts at 0x300, and ends at 0x380, which exceeds the __TEXT segment size (0x36f). There is manually generated object file using the third_party/NNPACK/src/x86_64-fma/blas/conv1x1.py script. Can we regenerate the object file with the latest Xcode to make sure this bug is fixed and there is no OOB access.

I have a question: Say I am developing an application in C/C++ and part of the code I develop in assembly, If I use peachpy to write this assembly code, How am I going to debug this assembly code?

In visual studio while using yasm assebler this was possible. Is similar kind of thing can be done in PeachPy?

How PeachPy is different from using intrinsics? ThankYou

I noticed that x86_64/__init__.py exposes registers from registers.py for easier access, but not rsp. Is there a specific reason for this, or just an oversight? I'll be happy to submit a fix PR if applicable

The IDIV instruction puts its result in the AX register. The problem I have is that I can't figure out how to prevent GeneralPurposeRegister64 from allocating AX, so my pseudoregisters end up overwriting the input and result.

How do I prevent pseudoregisters from allocating AX?

https://golang.org/pkg/builtin/#uintptr

It seems to be this can map directly to uintptr_t ?

diff --git a/peachpy/x86_64/function.py b/peachpy/x86_64/function.py
index f4614d6..00c81b9 100644
--- a/peachpy/x86_64/function.py
+++ b/peachpy/x86_64/function.py
@@ -130,6 +130,8 @@ class Function:
                 return "boolean"
             elif c_type.is_size_integer:
                 return "int" if c_type.is_signed_integer else "uint"
+            elif c_type.is_pointer_integer:
+                return "uintptr"
             elif c_type.is_signed_integer:
                 return {
                     1: "int8",

My rationale for wanting this is to make it easier to have slices and structs as arguments.

A slice header ( https://golang.org/pkg/reflect/#SliceHeader ) can be simulated by having three arguments,

s = Argument(ptr(uintptr_t))
s_len = Argument(int64_t)
s_cap = Argument(int64_t)

(I know the documentation says to use ptrdiff_t to get Go's int, but that really makes the code confusing... In my code I'm using int64 explicitly because I know I'm on 64-bit platform.)

However, due to the lack of mapping for uintptr, this fails when trying to generate the commented function header -- I have to put an explicit integer type for s.

Similarly if I want to pass a pointer to a struct, using uintptr_t seems the only sane option.

Following on from #60, consider the following simple program. It moves a value into a general purpose register and subsequently returns that value. In the meantime, it explicitly uses rax. My expectation is that the liveness analysis should determine that rax is in use and therefore the GeneralPurposeRegister64 register r should not choose rax for the allocation.

input_ptr = Argument(ptr())

with Function("foo", (input_ptr,), int64_t)  as function:
    name = LOAD.ARGUMENT(r15, input_ptr)

    r = GeneralPurposeRegister64()
    MOV(r, 1234)
    MOV(rax, 4567)
    MOV([r15], rax)
    RETURN(r)

The resulting code I get:

// Generated by PeachPy 0.2.0 from f.py


// func foo(input_ptr uintptr) int64
TEXT ·foo(SB),4,$0-16
	MOVQ input_ptr+0(FP), R15
	MOVQ $1234, AX
	MOVQ $4567, AX
	MOVQ AX, 0(R15)
	MOVQ AX, ret+8(FP)
	RET

I have instrumented the liveness analysis code over at my instrument branch. The output of that instrumentation is as follows.

'LOAD.ARGUMENT r15, void* input_ptr' in_mask {}; out_mask {15: 15}
'MOV gp64-vreg<1>, 1234' in_mask {}; out_mask {-1: 15}
'MOV rax, 4567' in_mask {}; out_mask {0: 15}
'MOV [r15], rax' in_mask {0: 15, 15: 15}; out_mask {}
'RETURN gp64-vreg<1>' in_mask {-1: 15}; out_mask {}
analyze_availability -> defaultdict(<class 'int'>, {0: 15, -1: 15, 15: 15})
Consider block [0, 5)
analyze_liveness [0, 5) {}
live_registers_list() masks: defaultdict(<class 'int'>, {})
live_registers_list [0, 5) -> [defaultdict(<class 'int'>, {-1: 15}), defaultdict(<class 'int'>, {0: 15, -1: 15, 15: 15}), defaultdict(<class 'int'>, {-1: 15, 15: 15}), defaultdict(<class 'int'>, {15: 15}), defaultdict(<class 'int'>, {})]
_analize availability: LOAD.ARGUMENT r15, void* input_ptr -> live_registers: defaultdict(<class 'int'>, {})
_analize availability: MOV gp64-vreg<1>, 1234 -> live_registers: defaultdict(<class 'int'>, {15: 15})
_analize availability: MOV rax, 4567 -> live_registers: defaultdict(<class 'int'>, {-1: 15, 15: 15})
_analize availability: MOV [r15], rax -> live_registers: defaultdict(<class 'int'>, {0: 15, -1: 15, 15: 15})
_analize availability: RETURN gp64-vreg<1> -> live_registers: defaultdict(<class 'int'>, {-1: 15})
_analize (conflicts)  'LOAD.ARGUMENT r15, void* input_ptr' inp: set(); out: {r15}; unalloc: []; live: defaultdict(<class 'int'>, {})
_analize (conflicts)  'MOV gp64-vreg<1>, 1234' inp: set(); out: {gp64-vreg<1>}; unalloc: []; live: defaultdict(<class 'int'>, {15: 15})
_analize (conflicts)  'MOV rax, 4567' inp: set(); out: {rax}; unalloc: [gp64-vreg<1>]; live: defaultdict(<class 'int'>, {-1: 15, 15: 15})
    gp64-vreg<1>::conflict_internal_ids: [-1, 15]
      Conflicts for virtual 1 are now {1: {-1, 15}}
_analize (conflicts)  'MOV [r15], rax' inp: {r15, rax}; out: set(); unalloc: []; live: defaultdict(<class 'int'>, {0: 15, -1: 15, 15: 15})
_analize (conflicts)  'RETURN gp64-vreg<1>' inp: {gp64-vreg<1>}; out: set(); unalloc: [gp64-vreg<1>]; live: defaultdict(<class 'int'>, {-1: 15})
    gp64-vreg<1>::conflict_internal_ids: [-1]
      Conflicts for virtual 1 are now {1: {-1, 15}}
Function._bind_registers gp64-vreg<1> to None
Function._bind_registers gp64-vreg<1> to None
RegisterAllocator._bind_register: Allocate virtual 1 to physical 0
RegisterAllocator._bind_register: Considered conflicts {-1, 15}
	LOAD.ARGUMENT r15, void* input_ptr
	MOV rax, 1234
	MOV rax, 4567
	MOV [r15], rax
	STORE.RESULT rax
	RET

I note that the list of conflicts does not change if I change the register I move 4567 into. If I do MOV(rbx, 4567) instead, I still get Conflicts for virtual 1 are now {1: {-1, 15}}. I don't quite understand the representations and intent of the register allocation code well enough to diagnose why this is, but I would expect that the conflict list depends on which register is named, but that does not seem to be the case.

This patch makes setuptools a dependency. This is needed to make setup.py automatically make the Opcodes module available at setup time.

Opcodes is made into a setup-time dependency, and if the module is installed with python setup.py build or python setup.py develop or pip install PeachPy or pip install --editable PeachPy, then the python setup.py generate command is run automatically.

This patch depends on https://github.com/Maratyszcza/Opcodes/pull/5 because of the way setuptools handles setup-time dependencies. They are not installed proper, but made available as an .egg file. Opcodes, before Maratyszcza/Opcodes#5, tries to read the XML descriptions by opening a file relative to __file__, which is not a thing which can be read with open(). Instead, it has to use pkg_resources to do so.

With these two PRs merged, it should be possible to pip install git+https://github.com/Maratyszcza/PeachPy. We could also then discuss making it easy to package up and upload to PyPi.

Example:

x86_64\abi.py Line 134:

    elif osname == "Windows" and machine == "AMD64" and pointer_size == 8:
        return microsoft_x64_abi

But when I get here on my Windows 8.1 64 bit, running Python35 (32 bit Python35 BTW.. probably should install 64 bit) it skips this abi, because my pointer_size = 4, not 8.

..not sure if running a 32 bit Python on a 64 bit machine is even something you want to deal with.

I didn't mean to install 32 bit Python, and will correct in a bit - let me know if you want me to flog PeachPy in this environment a bit more before I correct and I will.

I have this simple code:

import peachpy
import peachpy.x86_64

x = peachpy.Argument(peachpy.int64_t)

with peachpy.x86_64.Function("Add4", (x,), peachpy.int64_t) as asm_function:
    peachpy.x86_64.LOAD.ARGUMENT(peachpy.x86_64.rax, x)
    peachpy.x86_64.ADD(peachpy.x86_64.rax, 4)
    peachpy.x86_64.RETURN(peachpy.x86_64.rax)

abi = peachpy.x86_64.abi.detect()
encoded_function = asm_function.finalize(abi).encode()
python_function = encoded_function.load()

# The JIT call
print(python_function(-100))

When I run this code, I get this error:

Traceback (most recent call last):
  File "C:/Users/Oround/Desktop/Tests.py", line 2, in <module>
    import peachpy.x86_64
ImportError: No module named x86_64

Why am I getting this error? Is there something I could do to fix it?

Get this error -> python -m peachpy.x86_64 -mabi=sysv -mimage-format=elf -o matmul.o matmul-opt.py /usr/bin/python: No module named avx; 'peachpy.x86_64' is a package and cannot be directly executed

Also running make gives this -> user@ne:~/Downloads/PeachPy-master/examples/make$ make python -m peachpy.x86_64 -MMD -MF matmul-opt.d -o matmul-opt.o matmul-opt.py /usr/bin/python: No module named avx; 'peachpy.x86_64' is a package and cannot be directly executed Makefile:12: recipe for target 'matmul-opt.o' failed make: *** [matmul-opt.o] Error 1

This is on ubuntu wily with built in Python 2.7.10.

The generator outputs an error for functions with signed/unsigned_int argument. Here's the last few lines of the error:

File "/Library/Python/2.7/site-packages/peachpy/x86_64/function.py", line 987, in __init__
    self.go_signature = function.go_signature
  File "/Library/Python/2.7/site-packages/peachpy/x86_64/function.py", line 158, in go_signature
    go_argument_types = list(map(c_to_go_type, map(operator.attrgetter("ctype"), self.arguments)))
  File "/Library/Python/2.7/site-packages/peachpy/x86_64/function.py", line 149, in c_to_go_type
    }[ctype.size]
KeyError: None

It also outputs an error when the return type is signed/unsigned_int. Right now I'm substituting int64_t/uint64_t for signed/unsigned_int and just change the function signature to use int/uint since int and uint type in go is actually represented as 64-bit in amd64 as stated here. It would also be nice if Go's uintptr can also be supported.

Hi, this improves the Windows compatibility of PeachPy. In particular, it fixes #121. The problem was under Windows the default encoding for open() is cp1252 instead of utf-8. So by always using utf-8 for the TextWriter it is now possible to generate Go asm under Windows.

The second commit deals with the problems described in PR #43. Under Windows it is not possible to unlink an open file. With this the writers close the file before attempting to unlink it. Just like @bawr described in his last comment but apparently never did.

Closes #121, closes #43

% pytest tests/arm/test_arm.py

================================== test session starts ==================================
platform darwin -- Python 3.10.6, pytest-7.1.3, pluggy-1.0.0
rootdir: /Users/cclauss/Python/itinerant_futurizer/PeachPy
collected 1 item

tests/arm/test_arm.py F                                                           [100%]

======================================= FAILURES ========================================
____________________________________ TestARM.runTest ____________________________________

self = <tests.arm.test_arm.TestARM testMethod=runTest>

    def runTest(self):

        # Implement function void add_1(const uint32_t *src, uint32_t *dst, size_t length)
        source_arg = Argument(ptr(const_uint32_t))
        destination_arg = Argument(ptr(uint32_t))
        length_arg = Argument(size_t)

        # This optimized kernel will target Intel Nehalem processors. Any instructions which are not
        # supported on Intel Nehalem (e.g. AVX instructions) will generate an error. If you don't have
        # a particular target in mind, use "Unknown"
>       with Function("add_1", (source_arg, destination_arg, length_arg), abi=ABI.GnuEABIHF, report_generation=False) as add_function:
E       NameError: name 'ABI' is not defined

tests/arm/test_arm.py:17: NameError
================================ short test summary info ================================
FAILED tests/arm/test_arm.py::TestARM::runTest - NameError: name 'ABI' is not defined
=================================== 1 failed in 0.03s ===================================

Test results: https://github.com/cclauss/PeachPy/actions

% pip install --editable . % pytest --ignore=tests/arm/test_arm.py

============================= test session starts ==============================
platform linux -- Python 3.10.7, pytest-7.1.3, pluggy-1.0.0
rootdir: /home/runner/work/PeachPy/PeachPy
collected 1309 items

tests/test_elf.py .                                                      [  0%]
tests/test_literal.py ...........                                        [  0%]
tests/x86_64/test_analysis.py ...                                        [  1%]
tests/x86_64/test_function.py ........                                   [  1%]
tests/x86_64/test_golang.py ...                                          [  1%]
tests/x86_64/test_labels.py .......                                      [  2%]
tests/x86_64/test_load.py .                                              [  2%]
tests/x86_64/test_register_allocation.py ......                          [  3%]
tests/x86_64/test_register_constraints.py ..............                 [  4%]
tests/x86_64/test_relocation.py ............                             [  5%]
tests/x86_64/test_return.py ...................                          [  6%]
tests/x86_64/encoding/test_amd.py ...................................... [  9%]
..............................................                           [ 12%]
tests/x86_64/encoding/test_avx.py ...................................... [ 15%]
........................................................................ [ 21%]
........................................................................ [ 26%]
........................................................................ [ 32%]
........................................................................ [ 37%]
........................................................................ [ 43%]
........................................................................ [ 48%]
...........................................................              [ 53%]
tests/x86_64/encoding/test_crypto.py .......................             [ 55%]
tests/x86_64/encoding/test_fma.py ...................................... [ 57%]
..........................................                               [ 61%]
tests/x86_64/encoding/test_generic.py .................................. [ 63%]
........................................................................ [ 69%]
........................................................................ [ 74%]
...........................                                              [ 76%]
tests/x86_64/encoding/test_imm.py ..                                     [ 77%]
tests/x86_64/encoding/test_mask.py ..................................... [ 79%]
..............                                                           [ 80%]
tests/x86_64/encoding/test_mmxsse.py ................................... [ 83%]
........................................................................ [ 89%]
........................................................................ [ 94%]
.......................................................................  [100%]

============================= 1309 passed in 6.40s =============================

Hi im getting the error:

TypeError: <class 'main.LP_INPUT'> is not a C type

if I need to pass a pointer to a struct. I have successfully defined the struct and it also works if I call the function from user32 dll. But I can not get it working with peachpy.

Please check the attached screenshot. Would be insane if someone can figure that out.

Best t

After running go generate and trying to build the example using the main branch of PeachPy, I get the following error:

.\dot_product_amd64.s:11:6: invalid UTF-8 encoding
.\dot_product_amd64.s:11:6: invalid UTF-8 encoding
.\dot_product_amd64.s:11: expected '(', found DotProduct
asm: assembly of .\dot_product_amd64.s failed

After some investigation, using asm code from other examples, and a hex editor, it turns out that editing TEXT ·DotProduct(SB),4,$0-28 to TEXT ·DotProduct(SB),4,$0-28 solves the issue.

i.e.: the byte c2 seems to be missing before the function name declaration? But it doesn't show by default in an editor.

I'm new to go ASM and I have no idea of what is going on here.

I'm using go1.18.2 windows/amd64

Error: "Invalid operand types: PUSH r32"

From the source code:

class PUSH(Instruction):
    """Push Value Onto the Stack"""

    def __init__(self, *args, **kwargs):
        """Supported forms:

            * PUSH(imm32)
            * PUSH(r16/m16)
            * PUSH(r64/m64)
        """

Is it intended that PUSH(r32/m32) is missing? Same for POP