3.3 KiB
← Back to Twitter thread index
title: "The aim of course, keep the stuff that doesn't need to go fast optimized instead" author: "NOTimothyLottes" handle: "@NOTimothyLottes" post_url: "https://x.com/NOTimothyLottes/status/2078729662021111958" post_id: "2078729662021111958" timestamp: "2026-07-19 06:32:27" post_count: 11 reply_count: 1 repost_count: 0 like_count: 3 view_count: 509
@NOTimothyLottes — The aim of course, keep the stuff that doesn't need to go fast optimized instead
Post 1 (2026-07-19 06:28:14)
Probably shouldn't consider this -BUT- apparently writing to ax doesn't change the other 48-bits. So one could do a 4-byte overhead interpreter with a 64KiB aligned window of directly jumpable words like this below. [rsi]=addresses to jump to. You'd pay the false dependency stall
Post 2 (2026-07-19 06:29:54) — reply to Post 1
It's interesting because it cuts interpreted source size in half. Ie a stream of 16-bit offsets instead of 32-bit addresses.
Post 3 (2026-07-19 06:32:27) — reply to Post 2
The aim of course, keep the stuff that doesn't need to go fast optimized instead for low complexity and low size (aka interpreted forth), and keep the stuff that needs to go fast, at peak, assembly. Hits 2 extremes well.
Post 4 (2026-07-19 08:46:33) — reply to Post 3
@NOTimothyLottes These instrs are anything but fast and if you want both "fast" and compact you run a separate decoding pass where you expand custom bytecode into target instructions that suck less.
Post 5 (2026-07-19 14:38:22) — reply to Post 4
@noop_dev Basic truth: if the program is tiny and dependency free (ie intrinsically not just glue for libraries) it’s probably already fast even if the machine isn’t. And for the things that need perf there is always assembly
Post 6 (2026-07-19 14:43:27) — reply to Post 5
@NOTimothyLottes Anyway, I am trying you to sell the idea of bytecode-driven macroassembler that expands "macros" on load. Like I did with 4K atari 2600 emu ~20 years ago.. some demosceners I knew also adopted the idea..
Post 7 (2026-07-19 14:55:41) — reply to Post 6
@noop_dev Many of my other systems had been such that interpreted source generates raw code then executes the code (all at once after code is fully processed). Effectively forth as a macro language and instruction generator, runtime assembler.
Post 8 (2026-07-19 15:04:11) — reply to Post 7
@noop_dev But for cold cache stuff it’s easy to burn more time in binary generation than it would cost to do simple interpreter.
Post 9 (2026-07-19 15:10:25) — reply to Post 8
@NOTimothyLottes Not sure I can understand how cold cache matters for a linear transformation of a relatively small # of bytes.
Post 10 (2026-07-19 15:16:20) — reply to Post 9
@noop_dev If it’s a byte that indexes into say a fixed size physical instruction, yeah it’s just a decompression of source code, sure easy to do fast. Im talking more the multi-branch miss per instruction stuff.
Post 11 (2026-07-19 15:20:43) — reply to Post 10
@noop_dev Meaning “mov edi,[rax-0x32]” could be generated from 4 symbol lookups (2 for regs, one for offset, one for instruction). Also my intent here is for GPU code generation for AMD GPUs where youd have sometimes 8+ bitfields in an opcode. So the simple stuff won’t work there …