r/Assembly_language

Code examples: https://coppiq.com/cerium1.0

This technically isn't a real Assembly language since it isn't made for a low-level target, but I hope it's close enough to be relevant. It's heavily based on arm32 with a lot of high-level features from Scratch.
Some main differences:
- Registers and memory are Scratch variables, meaning they can be treated as either strings or numbers.
- No bitwise operators
- Data can be pushed directly to the stack. In any other case however, the data would need to be loaded into a register first.
- It has special branch instructions that push the stack and frame pointers automatically.
- The bytecode the project actually reads is string-based and not raw bytes. Scratch can't read raw data.
- It has special math blocks (pow, sqr, sin, cos, tan) and blocks for string manipulation (letter of, substring, make uppercase, make lowercase, length of, concatenate).
- Only branch instructions can run conditionally.

The code is assembled into a single string that gets unpacked and read as individual instructions by the OS after running execve(). (Example on image 5)

It runs on top of an OS simulator I've named Cerium, which it communicates with through syscalls. The Cerium part of it also handles virtual memory and inter-process communication. The language itself is called Spryte, with the current version being named Blueberry Spryte.

The language supports .text, .data, and .rodata segments that are always loaded into separate memory pages when starting a program.

The virtual memory has ASLR also. Program data is always accessed relatively using the stack or the "adr rx, label" psuedo-instruction, which expands into "add rx, pc, label index - instruction index".

Strings can be stored as one Scratch variable or individual characters, which is specified by using the .string or .chars directives. Individual items of memory can also be reserved with the .items directive.

Here's an example of the assembled code "echo.s":

@*--spryte-bluby0Ⓢ1.0.0Ⓢ0Ⓢ0=0Ⓢ!074Ⓢ!001Ⓢ!021Ⓢ"48d"39d1Ⓢ!0a1Ⓢ(1a8%0414Ⓢ)119a'?0 Ⓢ!11d')0dd1Ⓢ)0aa1Ⓢ%06-13Ⓢ?0␤Ⓢ!11d')0dd1Ⓢ!071Ⓢ!000Ⓢ'

"ex_fork.s":

@*--spryte-bluby0Ⓢ1.0.0Ⓢ0Ⓢ0=0;1=86Ⓢ!072Ⓢ'(000Ⓢ!074Ⓢ!001Ⓢ!021Ⓢ%0243Ⓢ!0735Ⓢ!00-1Ⓢ!01-1Ⓢ'!07500Ⓢ!001Ⓢ'!074Ⓢ!001Ⓢ)01f100Ⓢ'!0720Ⓢ'#30f96Ⓢ!074Ⓢ!001Ⓢ)01f90Ⓢ')01f86Ⓢ'!07500Ⓢ!001Ⓢ'%0629Ⓢ!07500Ⓢ!002Ⓢ'!074Ⓢ!001Ⓢ)01f65Ⓢ'!0720Ⓢ'#30f62Ⓢ!074Ⓢ!001Ⓢ)01f56Ⓢ')01f52Ⓢ'!071Ⓢ!000Ⓢ'ⓈHello from child ␛[30m␛[47mpid ⓈⓈHello from parent ␛[30m␛[42mpid ⓈⓈ␛[39m␛[49m␤Ⓢ

The outputted file is structured as follows:

1. Magic Number @*--spryte-bluby
2. Internal Version Number 0Ⓢ
3. Readable Version Number 1.0.0Ⓢ
4. Entry Point 0Ⓢ
5. Segment Table 0=0;1=86Ⓢ
6. .text !072Ⓢ'(000Ⓢ!074Ⓢ!001Ⓢ...
7. .data (optional) Hello from child ␛[30m␛[47m...

This is actually the second version of this project. The original (Strawberry Spryte) was completely different and based on the 6502 architecture with syscalls weirdly mixed in. The last image is a screenshot of the joke program "sl" written in it. (original file is at https://pastebin.com/T6vJiR85)

The Scratch project is very unfinished so I won't be sharing it yet, sorry.

This is a project made partially to teach myself so I apologise if the code is a bit amateurish or messy. I can promise that nothing here was written with AI though.

Hello, made a app to assist in estimating materials for foundations. 100% offline and completely free. Find it here.

hello is this code acctually able to work for the operating system im developing in x86?

im new to ts language

Pasé un semestre aprendiendo Assembly para el PIC18F4455 y cometí casi todos los errores que se pueden cometer. Esto es lo que realmente marcó la diferencia, por si le sirve a alguien.

1. El datasheet no es opcional Perdí semanas tratando de armar el conocimiento de tutoriales dispersos (Foros del 2010 con pic16). El datasheet del PIC18F4455 tiene todo: el set de instrucciones, los mapas de registros, los diagramas de timing. Cuando me comprometí a leerlo en lugar de buscarle la vuelta, las cosas empezaron a tener sentido.

2. El cambio de modelo mental es lo difícil Venía de Python y JavaScript, donde uno declara qué quiere que pase. Assembly te obliga a describir cómo, paso a paso, sin nada oculto. Por ejemplo, "suma dos números" se convierte en: carga el primer valor en W, carga el segundo en un registro, ejecuta ADDWF, decide dónde va el resultado.

3. La IA como explicador, no como escritor de código Usé Claude para preguntar cosas como "explícame qué hace SUBLW con una analogía" o "por qué SUBWF calcula f - W y no W - f". Genuinamente útil para conceptos.

4. Los comentarios y la estructura me salvaron en cada revisión Cada archivo tiene una cabecera (nombre, fecha, descripción) y comentarios en cada línea no obvia. Suena básico, pero cuando vuelves a tu propio código dos semanas después en Assembly, no vas a recordar qué estabas haciendo.

5. Dale una marca personal a tu código Suena raro pero funcionó: le agregué una firma en ASCII art a cada archivo (le puse un conejito playboy jajaja). Hizo que cada programa se sintiera como algo que yo escribí, no solo una tarea. Ese cambio psicológico me hizo sentir que cada código era una f****g obra de arte.

Escribí todas mis notas aquí, por si alguien le interesan, los codigos pronto los subiré a mi github: 

https://soymariopineda.github.io/blog/posts/notaspic.html

No linking, no API mess like on Linux,
Simply compile directly to tiny .EXE file.

The same thing on Linux/X11 would cost 15KB ( with dynamic linker ) instead 2560 bytes.

After 250 lines, it can fill terminal window with specific color/character at exact resolution 🤷‍♂️

** made my own event system to only redraw when needed, much preferable to dirty-draw what change.

I just want to compare what it take to fill/draw buffer on TUI correctly, compare to other methods like X11/Wayland/GLX or pure fb0.

And it successfully draw on booting x86-64 machine with a tinyconfig-like linux kernel 6.9 (~861KB) after Limine bootloader.

Hi! This GIF shows my Intel 4004 / MCS-4 prototype workflow (QuadBasic -> 4004 ASM -> run with visible CPU/bus state). I’d love feedback from retrocomputing folks on what tiny demo to show next (LCD, LED bar, switches, or printer).