docs(twitter): add 2078729662021111958 corpus (NOTimothyLottes 64KiB aligned jump-window + @noop_dev exchange)

11-post thread. Root: 4-byte overhead interpreter with 64KiB aligned window of directly-jumpable words (write to ax doesn't change other 48 bits), cuts source size in half. Tangent with @noop_dev covering cold-cache misses, runtime-macroassembler idea, 4K Atari 2600 emu precedent. End: GPU code generation for AMD where 8+ bitfields in an opcode means the simple interpreter won't work.
2026-07-26 21:36:15 -04:00
parent f603a7bf69
commit 186a71321a
3 changed files with 245 additions and 0 deletions
@@ -0,0 +1,61 @@
+---
+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
+
+![Media 1](./media/2078728600912630031_1.png)
+
+## 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 …
@@ -0,0 +1,184 @@
+{
+  "root_post_id": "2078729662021111958",
+  "posts": [
+    {
+      "post_id": "2078728600912630031",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "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",
+      "timestamp": "2026-07-19 06:28:14",
+      "media_urls": [
+        "https://pbs.twimg.com/media/HNkf6ntX0AA8d1M?format=png&name=orig"
+      ],
+      "reply_to_id": null,
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 4,
+        "repost_count": 1,
+        "like_count": 14,
+        "view_count": 1564
+      }
+    },
+    {
+      "post_id": "2078729020900823089",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "It's interesting because it cuts interpreted source size in half. Ie a stream of 16-bit offsets instead of 32-bit addresses.",
+      "timestamp": "2026-07-19 06:29:54",
+      "media_urls": [],
+      "reply_to_id": "2078728600912630031",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 2,
+        "view_count": 586
+      }
+    },
+    {
+      "post_id": "2078729662021111958",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "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.",
+      "timestamp": "2026-07-19 06:32:27",
+      "media_urls": [],
+      "reply_to_id": "2078729020900823089",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 3,
+        "view_count": 509
+      }
+    },
+    {
+      "post_id": "2078763409403683061",
+      "author": "Boris Chuprin",
+      "handle": "noop_dev",
+      "text": "@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.",
+      "timestamp": "2026-07-19 08:46:33",
+      "media_urls": [],
+      "reply_to_id": "2078729662021111958",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 0,
+        "view_count": 28
+      }
+    },
+    {
+      "post_id": "2078851948543910353",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "@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",
+      "timestamp": "2026-07-19 14:38:22",
+      "media_urls": [],
+      "reply_to_id": "2078763409403683061",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 1,
+        "view_count": 60
+      }
+    },
+    {
+      "post_id": "2078853226967781591",
+      "author": "Boris Chuprin",
+      "handle": "noop_dev",
+      "text": "@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..",
+      "timestamp": "2026-07-19 14:43:27",
+      "media_urls": [],
+      "reply_to_id": "2078851948543910353",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 2,
+        "repost_count": 0,
+        "like_count": 0,
+        "view_count": 59
+      }
+    },
+    {
+      "post_id": "2078856306811691388",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "@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.",
+      "timestamp": "2026-07-19 14:55:41",
+      "media_urls": [],
+      "reply_to_id": "2078853226967781591",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 2,
+        "view_count": 82
+      }
+    },
+    {
+      "post_id": "2078858446409978111",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "@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.",
+      "timestamp": "2026-07-19 15:04:11",
+      "media_urls": [],
+      "reply_to_id": "2078856306811691388",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 2,
+        "view_count": 81
+      }
+    },
+    {
+      "post_id": "2078860015323038149",
+      "author": "Boris Chuprin",
+      "handle": "noop_dev",
+      "text": "@NOTimothyLottes Not sure I can understand how cold cache matters for a linear transformation of a relatively small # of bytes.",
+      "timestamp": "2026-07-19 15:10:25",
+      "media_urls": [],
+      "reply_to_id": "2078858446409978111",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 0,
+        "view_count": 30
+      }
+    },
+    {
+      "post_id": "2078861504284074431",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "@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.",
+      "timestamp": "2026-07-19 15:16:20",
+      "media_urls": [],
+      "reply_to_id": "2078860015323038149",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 0,
+        "view_count": 207
+      }
+    },
+    {
+      "post_id": "2078862606517895324",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "@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 …",
+      "timestamp": "2026-07-19 15:20:43",
+      "media_urls": [],
+      "reply_to_id": "2078861504284074431",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 0,
+        "repost_count": 0,
+        "like_count": 2,
+        "view_count": 208
+      }
+    }
+  ],
+  "source_url": "https://x.com/NOTimothyLottes/status/2078729662021111958"
+}