manual_slop/docs/twitter/2078729662021111958/thread_data.json

{
  "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"
}