Skip to content

purego: improve support of 'arm' architecture - #488

Closed
xakep666 wants to merge 1 commit into
ebitengine:mainfrom
xakep666:arm-softfloat
Closed

purego: improve support of 'arm' architecture#488
xakep666 wants to merge 1 commit into
ebitengine:mainfrom
xakep666:arm-softfloat

Conversation

@xakep666

@xakep666 xakep666 commented Aug 3, 2026

Copy link
Copy Markdown

What issue is this addressing?

Closes #489 (improper alignment)
Closes #490 (soft-float)

What type of issue is this addressing?

Fixes bugs and add feature.

What this PR does | solves

This PR improves support of 'arm' architecture stated as 'Tier 2' in README.

  • Properly handle 64-bit integers:
    1. Obey 8-byte alignment on stack and even-register placement required by AAPCS. Exact points:

    C.3 If the argument requires double-word alignment (8-byte), the NCRN is rounded up to the next even register number.
    C.7 If the argument required double-word alignment (8-byte), then the NSAA is rounded up to the next double-word address.

    1. Use two registers (R0, R1) to make function return value. This will work for '386' architecture too.
  • Support for soft-float ABI:
    1. Pull runtime variable 'goarmsoftfp' to detect if soft-float ABI is used.
    2. Assembly trampolines skips load/store to FP registers if soft-float is detected. This was implemented in exactly same way how it's done in Go runtime.
    3. Apply integer passing rules for float arguments/return values.
  • Run tests for GOARM=5 (no FPU) in test workflow and add some arm-specific test cases.

Possible concerns: a way soft-float ABI usage is detected. I've decided to import a variable from 'runtime' package via //go:linkname in a specific way to ensure that &purego.runtime_goarmsoftfp == &runtime.goarmsoftfp. Last one has //go:linkname too because it's widely used across assembly routines.

Verification:

  • Added test running for with soft-float ABI to test workflow and added specific test cases.
  • Verified on real ARMv5TE CPU (Marvell Kirkwood, no FPU) by @Hirador (co-author of commit, pin-pointed some places to fix).

* Properly handle 64-bit integers:
  1. Obey 8-byte alignment on stack and even-register placement required by AAPCS.
  2. Use two registers (R0, R1) to make function return value. This will work for '386' architecture too.
* Support for soft-float ABI:
  1. Pull runtime variable 'goarmsoftfp' to detect if soft-float ABI is used.
  2. Assembly trampolines skips load/store to FP registers if soft-float is detected. This was implemented in exactly same way how it's done in Go runtime.
  3. Apply integer passing rules for float arguments/return values.
* Run tests for GOARM=5 (no FPU) in test workflow and add some arm-specific test cases.

Co-authored-by: Hirador <63920290+Hirador@users.noreply.github.com>
@hajimehoshi

Copy link
Copy Markdown
Member

Didn't create an issue. Will do if necessary.

Create an issue first please.

@xakep666

xakep666 commented Aug 3, 2026

Copy link
Copy Markdown
Author

Create an issue first please.

Done. One issue for improper argument alignment and one for soft-float support.

@hajimehoshi

Copy link
Copy Markdown
Member

Thanks.

This PR fixes the two issues at the same time, but can we split the changes?

@xakep666

xakep666 commented Aug 3, 2026

Copy link
Copy Markdown
Author

It is possible. However it's tested together. I've started with soft-float support (found because of SIGILLs) but then found alignment problem.

@hajimehoshi

Copy link
Copy Markdown
Member

It is possible. However it's tested together. I've started with soft-float support (found because of SIGILLs) but then found alignment problem.

Then let's do one by one. Make a separate PR. Thanks,

@xakep666 xakep666 closed this Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

All function/callback calls triggers SIGILL on ARMv5 cpus without FPU 64-bit arguments and return values are not fully supported on 32-bit ARM

2 participants