queso is an arm disassembler prioritizing historical accuracy on older versions for emulation and retro computing. There are cli, web, vendorable Golang, and vendorable C versions available, hex string and file inputs, and a ton of customizable options including custom register names, address offsets, and arm versions (ARMv1 - ARMv5TE).

https://github.com/aabalke/queso

https://guacemulator.com/queso

A big thank you to everyone who documents, builds, and provides support!

Hello everyone! For the past few years I've been working on ASM editor (github), an IDE for assembly running completely on the web with many architectures available (x86, mips, risc-v, m68k, z80 and more to come) with a lot of debugging features like step by step execution, undo, memory and registers viewers, breakpoints, observability of what each instruction did and much more!

Recently I've added a feature I had dreamed of adding for a long time, C and C++ compilation! It allows you to write C and C++ code (with a subset of libc available), compile it to assembly to see how each line was compiled, to then execute it with all the debugging tools available in the IDE.

I've also added peripherals like a screen, terminal, keyboard, mouse and file system. All of them can also undo to previous steps.

The IDE is used by my university and a few others to teach low level programming and has a lot of useful tools to teach. I've also published a paper about it in an IEEE conference.

It can be embedded in other websites as part of interactive courses or be used to do exams in schools and universities.

I'd love to get opinions/suggestions/feedback about it, please let me know in the comments!

I am a Java programmer, and as a hobby, I want to learn C with a focus on operating systems—specifically to modify existing open-source operating systems like GNU/Linux or BSD.

However, I understand that before learning C, it is a good idea to learn some assembly language. What is the best way to learn x86_64 assembly?

I took an ARM assembly course that was taught at our university in 2023 and loved it. The course was taught really well. The tooling is just old. You SSH into a department server, assemble, run, and get "Segmentation fault (core dumped)" with no line number and no idea which instruction did it.

I ended up TAing it 2 years later, then head TAing it the following semester. In April I started writing an interpreter and a few weeks later it ran real programs.

The hard part was making everything around the instructions match the real server: printf, scanf, m4 macros, the assembler directives. One of my old profs suggested compiling C programs with gcc on the server and checking the playground prints the same thing. The first run passed 0 programs. Most of that was one bug with branches jumping to the wrong place. Now it matches on basically all of them.

You can step through a program one instruction at a time, forwards or backwards. When it crashes, it points at the instruction that did it. Click any instruction to see its 32 bits split into the fields from the ARM manual. There are lessons, and practice problems checked by running your code.

I'd appreciate it if yall could test it out and lmk what you think!

aarch64-playground.com

I started out writing C for the network processors in backbone routers. A lot of that job was not writing anything: it was reading a listing, watching registers, and working out which instruction was not doing what everyone believed it was doing. I liked it more than was reasonable.

I have built a game that is only that. A fictional load/store ISA, fourteen instructions, six registers, a memory grid, memory-mapped ports with settling time. A program written by someone who is now dead. A full recorded trace, which you can step, breakpoint and rewind, and which exists in its entirety the moment you open the case, so you can read the listing, form a theory and jump straight to the tick that proves it.

The design constraint I set myself was that you never write or change anything. The moment you can edit the program it stops being an investigation and becomes a puzzle box. So every tool is read-only, including the one that lets you re-run the tape against sensor values the machine never actually saw, which is marked off the record so it cannot corrupt what you are proving.

The part I would most like this sub's opinion on is the proof. Naming the faulty line is not enough. You also have to classify the mistake and point at the tick where the harm first shows in machine state. That third clause is where everyone struggles, and I am still not sure whether it is too much to ask or just badly explained.

Free, seven cases, about an hour, no download: https://endpaperdev.itch.io/faultfinder-demo

Steam: https://store.steampowered.com/app/5120330/Faultfinder_Demo/

I'm writing a custom assembler for CHIP-8 and just finished adding support for the DB/.byte directive so I can embed sprites in the ROM and finally get something drawn on the screen. It SHOULD support all OG CHIP-8 instructions, but still a ton of rough edges that I'm ironing out.

This is my first ever C++ project, just like the CHIP-8 emulator was my first ever C (and emudev) project. It's so satisfying to write assembly and have your program spit out a ROM that actually runs in the emulator you wrote.

All code is written by me (a lot of it livestreaming) as evident by the quality, no AI.

Repo: https://github.com/Tackx/c8-ass

Hi! has anyone followed the book learn to program with assembly by Jonathan Bartlett using mac silicon? the book said it can be followed using docker in appendix a, but im wondering if anyone here managed to get through with another way.

https://www.amazon.com/Learn-Program-Assembly-Foundational-Programmers/dp/1484274369

Hey everyone,

I’m releasing a bare-metal 64-bit Intel VT-x Hypervisor template written entirely in pure NASM Assembly (~1,100 lines) using a strict stack-less model.

The purpose of this codebase is to provide a clean, core-only hardware virtualization implementation without relying on any OS kernel or C code.

### 🛠️ What is Currently Configured inside the VMCS & EPT:

* Primary Execution Controls (0x4002): Configured to 0x84006172. Enforces intercept control over CR3 modifications and heavy RDTSC exiting to counter guest timing side-channels.

* MSR Bitmaps Bypass: Bit 28 (Use MSR Bitmaps) is set to 0. This forces a global intercept policy where every RDMSR or WRMSR executed by the Guest triggers a hardware VM-Exit to the Host.

* Secondary Execution Controls (0x401e): Bit 31 activated for full EPT isolation, along with Unrestricted Guest support (Bit 7, allowing 16-bit Real Mode initialization over EPT), and MBEC configurations.

* Exception Bitmap (0x4004): Armed with atomic mask 0x0000404A to trap #DB, #BP, #UD, and #PF (Vector 14). Combined with clearing the Page-Fault Mask field (0x4006), every single Guest page fault intercepts directly to the Host.

* Long Mode Constraints: Enforces architectural boundaries via GDT mapping to ensure no illegal execution drops to 16/32-bit rings, avoiding instant #GP faults.

* Extended Page Table Pointer (EPTP): Configured field 0x0000201A to point directly to the physical EPT PML4 table base with Write-Back caching attributes.

### 🤝 Code Review & Peer Assistance:

To be completely honest, I wanted to release this as a 100% finished project, and I'm a bit sorry the VM-Exit handler isn't fully completed yet. But juggling full-time school, life, and writing a bare-metal hypervisor in pure 64-bit assembly is definitely a challenge.

I decided to release this core template now because I just need your technical assistance to review the code and help me fix any existing bugs, trace potential register mismatches in my vmwrite instructions, and hunt down hidden reserved bits conflicts on the Intel side.

### 🚀 Roadmap:

I'm already starting to write the hypervisor and bootloader for AMD right now, porting this entire setup over to the AMD-V VMCB block architecture. My immediate goal is to keep building the AMD side while getting this Intel core completely stable with the community's corrections and fixes.

Looking forward to your technical feedback, code analysis, and corrections.

GitHub Link: https://github.com/edikoz123-blip/Boot_loader_Assembly

"For detailed architectural breakdowns, hardware edge cases, and code reviews of this project, join the community at https://www.reddit.com/r/ChallengeBareMetalO/ You can always ask questions in the comments there, and I'll be glad to break down the logic!

X86_64 NASM - Linux

I am not looking for code, just resources and advice please. I am new to assembly but I am writing a compiler that generates direct assembly source that is then compiled with NASM. I wrote a function that takes any fixed point value i place in rax and outputs it to stdout. It just loops while converting and fills a buffer that i pass to the write syscall.

I want to do this with any double i store in xmm0. I keep searching the internet to see if there are any guides or advice on doing it but everything i come across is either inline inside of C or declaring C libraries within assembly and I want to do it raw. Ive been reading up on floating point arithmetic and understand the differences between operating on fixed and floating point registers but I am at somewhat of a loss on how to proceed.

This website has been my closest source by far https://faculty.cs.niu.edu/~hutchins/csci640/float.htm

The ordering is getting mixed up in my head though. Would the process be to hardcode a known value in xmm0 and then work backwards from there, learning how to differentiate the sign bits from the exponent bits and the like? At that point though, visually it starts as a decimal number in the source so i am not transcribing it from the 0.4ABC * 16^0 floating point number i need to be able to support, so its just confusing me. The ordering is where i would really like advice please. Then I assume after I am able to turn the float into its integer splits i would just have a repeat of my fixed point print function take those values concatenated together into one buffer , convert and send them to the kernel?

py2ez80!

This is a tool which I think many will find useful. For a long time, calculators like the Ti84+CE have been stuck with a very limited and painfully slow python interpreter. Recently, I finished my tool that fixes this problem, by transpiling python to assembly!

While at first glance you may think the term "transpiler" is incorrect for a project like this, I decided to take a shortcut on the route, and effectively made a Python to C transpiler, like cython. Except here, I made it specifically target the CEdev toolchain, and call it to produce a .8xp program in result. Using plain Cython will be tough since it isn't really optimized.

Although it is very advanced, supporting lists, tuples, many data types, and a lot of programming structure types found in python and converting them to C, I do acknowledge the fact that it is still very limited on its I/O capabilities.

The GitHub repo link is here: https://github.com/Voblit/py2ez80 , and I hope it helps!

:)

BTW: this only works with the ti84+CE or whatever the CEdev toolchain supports...