Add mem.compare, mem.copy, mem.fill32, unsafe_mem.compare #13

Merged
ShatteredMINT merged 9 commits from Mutex/symphony_stdlib:mem_ops into main 2026-09-04 21:55:24 +02:00
Contributor
No description provided.
Mutex added 1 commit 2026-09-02 19:42:46 +02:00
Owner

i think we want to keep actual code outside of stdlib.asm
i propose creating mem.asm

i think we want to keep actual code outside of stdlib.asm i propose creating mem.asm
stdlib.asm Outdated
@@ -26,0 +37,4 @@
; - `<0` if the first segment is less than the second segment.
; - `>0` if the first segment is greater than the second segment.
;
pub fn_memcmp:
Contributor

I am not sure these functions should be in the main asm file - better make a memory.asm file for these.

I am not sure these functions should be in the main asm file - better make a `memory.asm` file for these.
Mutex marked this conversation as resolved
Mutex added 2 commits 2026-09-03 15:10:09 +02:00
Mutex added 1 commit 2026-09-03 15:13:30 +02:00
Mutex changed title from Add `memcmp`, `memcpy`, `memset32`, `unsafe.memcmp` to Add `mem.compare`, `mem.copy`, `mem.fill32`, `unsafe_mem.compare` 2026-09-03 15:17:29 +02:00
Mutex requested review from Micha_i 2026-09-03 15:19:59 +02:00
Owner

Do we want to keep unsafe_mem.asm?

Do we want to keep unsafe_mem.asm?
Author
Contributor

unsafe_mem.asm contains the memcmp version with the "dubious" memory write. I don't think it would hurt to keep it, since it is not included in stdlib.asm, so it doesn't take up any memory unless manually included. It is also perfectly safe to use in most situations, in which it is about ~0.5 cycles faster per byte than mem.compare.

There are (currently) only two scenarios where the memory write could fail/have unintended side effects:

  • The end point of the first memory segment overlaps a specific section of its own code
  • The end point of the first memory segment is within the frame buffer

The primary reason I marked it as "unsafe" is that the side effects in those cases would be rather difficult to trace back to this operation, unless you knew that it temporarily modifies memory.

I did just remember that it has another issue that I planned to fix, but forgot about... Oops

unsafe_mem.asm contains the memcmp version with the "dubious" memory write. I don't think it would hurt to keep it, since it is not included in stdlib.asm, so it doesn't take up any memory unless manually included. It is also perfectly safe to use in *most* situations, in which it is about ~0.5 cycles faster per byte than `mem.compare`. There are (currently) only two scenarios where the memory write could fail/have unintended side effects: - The end point of the first memory segment overlaps a specific section of its own code - The end point of the first memory segment is within the frame buffer The primary reason I marked it as "unsafe" is that the side effects in those cases would be rather difficult to trace back to this operation, unless you knew that it temporarily modifies memory. I did just remember that it has another issue that I planned to fix, but forgot about... Oops
Mutex added 1 commit 2026-09-03 18:39:58 +02:00
Mutex added 3 commits 2026-09-03 21:06:01 +02:00
ShatteredMINT added 1 commit 2026-09-04 21:53:40 +02:00
ShatteredMINT merged commit 50f7040f59 into main 2026-09-04 21:55:24 +02:00
Mutex deleted branch mem_ops 2026-09-05 15:36:50 +02:00
Sign in to join this conversation.
No Reviewers
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: TCShenanigans/symphony_stdlib#13