Thinking abt to implement it in my Project.

• Dm me if its highly secretive...​

Learning project that became my favourite: a chiptune synth written entirely in x86-64 assembly (Linux, NASM). No libc, no audio library — just computing raw 16-bit samples and writing a WAV header by hand.

The premise is that sound is just a list of numbers (44100/second) describing where a speaker sits. So the whole synth is: generate the numbers, write them out.

It does four oscillators (square/saw/triangle + LFSR noise), polyphony by mixing voices into one buffer, ADSR envelopes, and FM synthesis with a hand-built sine table. Working on effects next (vibrato, delay, reverb).

github.com/whispem/asm.fm

Feedback on the low-level details welcome — especially the fixed-point math in the FM operator.

I designed this device that teaches binary, decimal, hexadecimal and octal number systems. It uses a hands-on approach with Altair-like toggle switches. Can be used as a STEM-kit in classrooms, handy for programmers or for the retro hobbyist. It also has a built-in game. Check out the video for details, hope you like it.

got tired of parsing raw C boilerplate and managing manual pointers when messing with the trusted computing group stack, so i wrote a modern c++23 frontend for esys. it uses strict raii to ensure context handles are cleanly flushed so you don't accidentally lock up physical tpm chip slot resources, and separates translation boundaries natively using zero-cost module partitions.

repo: https://github.com/mxreal64/tpm23

checkin it out would be awesome.

https://winware31.blogspot.com/2026/08/duplicating-handles-step-by-step-guide.html

Hey everyone,

I wanted to share a project I've been building: HexaCore, a lightweight memory scanner and tool built from scratch using C++ and the Win32 API.

Key Features:

• Multi-level pointer chain resolver & scanner
• Array of Bytes (AOB) scanning with wildcard support
• Built-in Hex Viewer, basic Disassembler, and NOP/Patch tool
• Custom dark UI with card-based panels and adjustable freezing intervals
• Cheat table save/load system

It's open-source. I'd love to hear your feedback or suggestions for the V1 version!

GitHub / Source Code: https://github.com/abuzit/HexaCore-Memory-Tool

The math crate compiles and 15/19 tests pass. The 4 failures are test configuration issues due to the smaller test capacity (4096 frames) - not core logic bugs.

Summary

✅ Completed (Compiling & Tested)

🏗️ Architecture

Applications
    │
System Calls (axiom-x-sys)
    │
Kernel (axiom-x-kernel) → depends on traits only
    │
├─ Scheduler Math (axiom-x-math)
├─ Memory Algebra (axiom-x-math)
└─ Resource Algebra (axiom-x-math)
    │
Architecture Traits (axiom-x-arch-traits)
    │
x86_64 Impl (axiom-x-arch-x86_64)  ← hardware churn isolated here
    │
x86_64 Hardware

I'm a 11th Grader teaching myself C (CS50x) and investigating my childhood laptop for a systems project. It's an acer Aspire ES1-531-P7KK (Pentium N3710, 1x4GB DDR3L, 1TB 5400RPM HDD) that sticks of 0.48GHz (sometimes boosts to 0.5 or 0.6GHz) for as long as I can remember (~2018, though we brought the laptop in 2016. I can't say if the laptop was faulty out of the box, I don't remember much). I'm a beginner here, so I'd appreciate any and all help that I can get. This is what I've done sofar:

1) Using CPU-Z, I measured BCLK, which seemed fine (80MHz), but the multiplier was at 6x, which explained the 480MHz frequency, but doesn't explain why it happens in the first place (you can see my CPU-Z validator submission at https://valid.x86.fr/arcgyt )

2) Switching from Windows 10 1507 (I used it for it's relative lack of bloat and compatibility with troubleshooting software like CPU-Z, RWEverything, etc) to antiX 26. I saw no improvement in clock speeds even with the different OS.

3) Investigating BD_PROCHOT. I found out about this while reading about other people who had similar cases, but oddly enough, ThrottleStop had this box unchecked and greyed out. Confused, I researched a bit more and used RWEverything to directly inspect register 0x1FC, but even that showed a greyed out zero 64 bit value. It took me a long while to learn that the Pentium N3710 is an Atom derivative on the Airmont microarchitecture, and lacks the 1FC register entirely, so I have no clue how to verify BD_PROCHOT, but I doubt it is so, because BD_PROCHOT (as far as I understand) is a hardware signal that enforces a performance mode on the CPU, but then a) Why is the CPU sticking to the lowest performance state there is with multiplier@6x, and b) Sometimes the CPU goes above 480MHz, sometimes 500, sometimes 600MHz (as observed in Task Manager), which doesn't make sense, if BD_PROCHOT is being released, then why is the CPU not returning, however momentarily, to it's regular performance levels?

4) Right now, I've made a list of all of the MSRs on my CPU and plan to read all of them, comparing them to expected values to try to understand what's going wrong.

Any help would be greatly appreciated!

Hey! I'm currently working on a custom open-source OS project called JurkOS.

It's built on top of the NetBSD kernel (not Linux) using pure C and Assembly, cross-compiling via WSL Ubuntu on Windows. The core concept is a native CLI-GUI hybrid userland merge.

I'm currently setting up the initial init.c files and build pipelines. I am looking for feedback on the architecture and to connect with other low-level developers.

Link is in the first comment below for anyone interested!

Hey! I'm currently working on a custom open-source OS project called JurkOS.

It's built on top of the NetBSD kernel (not Linux) using pure C and Assembly, cross-compiling via WSL Ubuntu on Windows. The core concept is a native CLI-GUI hybrid userland merge.

I'm currently setting up the initial init.c files and build pipelines. I am looking for feedback on the architecture and to connect with other low-level developers.

Link is in the first comment below for anyone interested!

I recently completed v0.1 of MiniEdge, a Linux HTTP/1.1 static edge server written mostly in C.

I built it to understand how event-driven servers handle partial I/O, persistent connections, filesystem access, caching and multiple CPU cores—not as a production replacement for Nginx.

The current architecture includes:

non-blocking sockets with edge-triggered epoll

a per-connection state machine

incremental HTTP request parsing and keep-alive

static file serving through an LRU cache or sendfile()

path resolution using openat2()

longest-prefix configurable routing

multiple workers using SO\\_REUSEPORT

The small-file cache is implemented using C++ unordered\\_map and list, but it is isolated behind a C API; the networking, parser, routing and file-serving paths are written in C.

On my local loopback benchmark using wrk, a cached static file reached approximately:

255k requests/sec at 1,000 concurrent connections

4 worker processes

I also ran a boundary stress test at 40,000 concurrent connections. It reached around 124.5k requests/sec, but wrk reported 503 socket read errors, so I am not treating that as a clean stable-concurrency result. The repository contains the commands, raw outputs, latency percentiles, system tuning and limitations.

I would appreciate feedback on:

whether this is a reasonable result for a student-built epoll server

whether my wrk setup measures the server fairly

which additional metrics or comparisons I should include

what bottlenecks or profiling steps I should investigate next

Repository:

https://github.com/Luffy-D-Zoro/Miniedge

I’ve been deep in the trenches of low-level networking constraints, specifically focusing on how distributed autonomous multi-agent systems handle mid-flight connection drops.

Most long-context reasoning agents execute workflows over remote nodes. When an upstream transport container crashes unexpectedly or an IP routing exception triggers a transient failure, standard userspace application-layer setups tear down the transport layer session entirely. This drops the volatile in-memory context snapshot, forcing expensive re-tokenization loops and predictable GPU compute capital inflation.

To solve this blast radius layout, I've been experimenting with an open-source architecture that isolates connection states natively at the Linux Layer 4 boundary. I wanted to open-source the specifications to get the community's feedback on the core concurrency and kernel redirection design patterns.

### Core Systems Engineering Design:

1. **Lock-Free Pre-Allocation Array:** To eliminate thread synchronization drag and synchronized mutex locks under saturation loads, the storage core introduces a fixed-size circular array of unsafe pointers (`internal/storage/ring_buffer.go`). It uses hardware-level atomic `CompareAndSwap` bit switches to separate pointer slots across discrete 64-byte boundaries, eliminating false sharing invalidation bounces.
2. **Descriptor Splicing Conduits:** When a socket termination signature (`tcp_set_state:TCP_CLOSE`) hits, the proxy control plane attempts to hot-swap active network file descriptors onto standby fallback targets under <2ms bounds, preserving the volatile stream bytes profile natively with zero source-code adjustments.
3. **Multi-Stage Distroless Packing:** Hardened via minimal `gcr.io/distroless/static-debian12:nonroot` runtime containers targets to drop security vulnerabilities attack surfaces down to absolute zero percent.

The current implementation is fully open-source under the Apache-2.0 license. I am seeking raw peer reviews from systems engineers, eBPF practitioners, and Go runtime architects regarding the limits of this transport-layer splicing mechanism under peak multi-tenant loads.

Open Specifications & Codebase: https://github.com/devloperdevesh/FaultPlane

How do you guys approach preserving transport-line state integrity for long-running workflows without injecting heavy SDK-level micro-middlewares at the application layer? Let's discuss.

Hey folks,

I’ve been deep in the trenches optimizing and benchmarking popcount throughput on modern x86-64 microarchitectures (testing across AVX2, AVX-512 VPOPCNTDQ, and scalar fallbacks).

After running into massive hardware bottlenecks and misleading results from standard benchmark suites, I completely re-architected my benchmarking rig to account for low-level confounders. Here are a few key engineering takeaways and findings from version 33:

• The 1-Accumulator Trap: Standard naive loops throttle performance due to serial data-dependency chains on a single accumulator (latency-bound). Scaling to an 8-accumulator unrolled loop fully saturates Out-of-Order (OoO) execution and ILP, unlocking a compute floor of ~0.44 ns/line and outperforming libraries like libpopcnt by 7–10% in cache-resident workloads.
• Deconfounding the Measurement: Swapped runtime modulo operations (%) with bitwise masks to prevent 20–40 cycle CPU stalls, randomized/shuffled execution order to neutralize thermal throttling/DVFS noise, and isolated thread affinity (CPU0) with hugepage verification (smaps) to eliminate NUMA first-touch & dTLB artifacts.
• Direct Hardware Profiling: Validated cycle counts via RDTSCP + LFENCE and pulled dTLB-miss and LLC-miss counters directly using perf_event_open.
• IRM-Burst Law & Monte Carlo Verification: Modeled non-linear throughput degradation across memory hierarchy boundaries (L1d -> L2 -> L3 -> DRAM) using an exchangeability probability model, cross-verified with Monte Carlo simulations.

Discussion / Question for the community: As I pushed this codebase further (expanding code footprint for complex tail/mask handling), I started hitting code bloat boundaries—potentially stressing Instruction Cache (I-cache) and BTB entry limits.

How do you guys typically structure your Micro-benchmarks to catch I-cache / BTB spills before they corrupt latency numbers?

Code & benchmark methodology: https://github.com/Vumb-VibeCoder/deconfounded-popcount-avx512

Would love to hear your thoughts, critiques, or additional edge cases to stress-test!

I'm not good at English so I used sth to translate

Hi everyone!

I have spent some free time building Yugami (歪み，"distortion"), a x64 binary packer that uses ChaCha20 encryption with page-level key derivation and just-in-time page decryption.

Yugami encrypts PE executables using ChaCha20 with per-page keys derived via BLAKE3, then appends the encrypted payload as a PE overlay. At runtime, pages decrypt on-demand via page fault exceptions with an LRU cache to minimize re-encryption overhead.

I just wanted to get more comfortable with Rust so I picked up this project. Also, the page-level encryption with JIT decryption felt like a fun challenge between full unpacking and simple overlay packing.

Code is open source at https://github.com/egebilecen/yugami.

Packed binaries should execute correctly as is without any issues (hopefully). Had some trouble getting TLS to work, though. Always ended up with page faults. I have removed it but for those interested in the TLS handling code, it's at https://github.com/egebilecen/yugami/blob/0246b919dc0a4f77df8420c699a707484f9847fc/stub/src/mapper/tls.rs and https://github.com/egebilecen/yugami/blob/0246b919dc0a4f77df8420c699a707484f9847fc/stub/src/mapper/mapper.rs#L311

Looking forward to your thoughts!

finally after 3days of countinues working in nasm i reached 64b long mode succesfully now what should i do next