Private
Public Access
4-post x86-64 interpreter work: all 0-6 arg syscalls in 32 bytes, embed interpreter inside words with 3-byte overhead (AD lodsd + FF E0 jmp rax), force lower 32-bit but keep 64-bit, pack interpreted forth words in aligned 8-bytes. Tangent post 4 from @NOTimothyLottes self-replying about custom bytecode + on-load decompression.
1.4 KiB
1.4 KiB
title, author, handle, post_url, post_id, timestamp, post_count, reply_count, repost_count, like_count, view_count
| title | author | handle | post_url | post_id | timestamp | post_count | reply_count | repost_count | like_count | view_count |
|---|---|---|---|---|---|---|---|---|---|---|
| I realized at some point I can have most interpreted forth-style words in an ali | NOTimothyLottes | @NOTimothyLottes | https://x.com/NOTimothyLottes/status/2078349730204078527 | 2078349730204078527 | 2026-07-18 05:22:44 | 4 | 1 | 0 | 5 | 502 |
@NOTimothyLottes — I realized at some point I can have most interpreted forth-style words in an ali
Post 1 (2026-07-18 05:14:06)
All {0-6} argument syscall options in 32-bytes. The plan is to embed the interpreter inside the words with a 3-byte overhead {AD (lodsd), FF E0 (jmp rax)} so levering lots of x86-64 stuff for minimal size
Post 2 (2026-07-18 05:17:08) — reply to Post 1
Everything forced in lower 32-bit, but still building around 64-bit support. Since I'm not using x86-64 CALL/RET I can free up the stack ops strictly for the data stack.
Post 3 (2026-07-18 05:22:44) — reply to Post 2
I realized at some point I can have most interpreted forth-style words in an aligned 8-bytes. So can make a very small interpreter.
Post 4 (2026-07-18 06:01:49) — reply to Post 3
@NOTimothyLottes Even smaller code size possible with custom compression scheme, where you design bytecode not for immediate execution but to be decompressed on load.


