2026-06-09 01:27:49 <Stalevar    > xentrac, Holtek something
2026-06-09 01:30:58 <Stalevar    > There is an emulator  https://www.reddit.com/r/emulation/comments/18rhhcn/mame_is_starting_to_emulate_a_brick_game_handheld/
2026-06-09 01:31:19 <Stalevar    > and https://github.com/ilyakurdyukov/brickgame-4bit/issues
2026-06-09 01:33:15 <xentrac     > cool
2026-06-09 11:16:32 <veltas      > MrMobius: Did you end up writing that compacting allocator?
2026-06-09 11:51:14 <MrMobius    > veltas: not yet. switched to hardware for a while. a friend has a hot air station so making use of it while I can
2026-06-09 11:56:27 <lofty       > does anybody have any experience/advice to give to someone trying to use (tokenised) forth as a bytecode for a sizecoding competition?
2026-06-09 11:58:56 <MrMobius    > I tried to do a bytecoded forth for the 6502 to save space and failed. you need a lot of code for it to be worth it
2026-06-09 12:00:07 <MrMobius    > I think the bytecode was 2-3x smaller than the equivalent assembly but interpreter was about 1K. assembly is smaller until you hit the 2K mark. ymmv of course
2026-06-09 12:01:17 <lofty       > the competition has two categories: 4 kilobyte file (piping data through an external compressor such as "xz" allowed), and 4 kilobyte ELF (which has to be self-contained)
2026-06-09 12:01:41 <lofty       > (target platform is Linux x86-64)
2026-06-09 12:02:03 <MrMobius    > cool
2026-06-09 12:02:25 <lofty       > (it's specifically a chess program, if you were wondering, rather than a more generic demo competition)
2026-06-09 12:03:50 <MrMobius    > try to reuse as much as you can so you dont have to make new primitives unless absolutely necessary
2026-06-09 12:04:58 <lofty       > I did make a "prototype" of this which involved some moderately cursed compression techniques
2026-06-09 12:05:14 <MrMobius    > and try to compress the look up table if you can so you don't have 64 bit addresses. maybe 16 bit offsets or 12 bit offsets if the decompression code doesnt outweigh the gains
2026-06-09 12:05:59 <MrMobius    > you can run some counts every time you compile and see if some primitives is rarely used and can be eliminated
2026-06-09 12:06:03 <MrMobius    > make trade offs etc
2026-06-09 12:08:39 <lofty       > I actually managed to eliminate the lookup table; each byte is an offset inside the interpreter relative to a base address. if each word has an 8-byte aligned entry point, you get 2^(8+3) = 2KiB of interpreter space to index. I was kind of proud of coming up with that one.
2026-06-09 12:09:07 <lofty       > (which I suppose makes this a form of direct threading?)
2026-06-09 12:13:17 <MrMobius    > nice
2026-06-09 12:14:02 <MrMobius    > hopefully the space savings pays off. you can just use the next tokens space if the word is long since you probably dont need all 256
2026-06-09 12:18:39 <lofty       > admittedly there's a slightly awkward tradeoff here; the compression makes NEXT bigger, so either I jump to a shared NEXT and destroy the branch target buffer, or duplicate NEXT and accept each assembly word takes two bytecode indices
2026-06-09 12:23:00 <MrMobius    > does speed count?
2026-06-09 12:23:35 <lofty       > in as much as there is "sufficiently fast" vs "insufficiently fast" :p
2026-06-09 12:24:51 <lofty       > I am not expecting things to be lightning fast, but I also think if I made forth the performance bottleneck I have designed things badly
2026-06-09 13:33:53 <iv4nshm4k0v > No idea if it would be helpful in this specific case, but with regards to implementing a Forth, I've found "Moving Forth" series by Brad Rodriguez enlightening.
2026-06-09 15:45:54 <veltas      > lofty: As it is allowed to be compressed, writing repetitive asm may be better than actually optimising for uncompressed size
2026-06-09 15:49:27 <veltas      > A tokenised lookup table thing could be short and easy to write.  You will want to profile which words/constants are worth making tokens
2026-06-09 15:50:29 <veltas      > If using 8-bit tokens, if 16-bit then presumably every word can be a token
2026-06-09 15:51:58 <veltas      > Standard forth is not always space-optimised, e.g. it's often less code if words that are frequently preceded by DUP just leave the input on stack
2026-06-09 15:52:29 <veltas      > But that makes code harder to maintain and is generally considered worse style
2026-06-09 15:53:20 <veltas      > Yet things like ?DUP exist and work well
2026-06-09 15:58:02 <veltas      > Put everything in one RWX section
2026-06-09 17:10:59 <KipIngram   > DKordic: That's a nifty device (the time of flight sensor you linked).
2026-06-09 17:11:53 <KipIngram   > veltas: Some operating systems fight you pretty hard against allowing W and X on the same RAM at the same time.
2026-06-09 17:12:25 <KipIngram   > I find it frustrating - it's one of those things where I want to be allowed to do whatever I want.
2026-06-09 17:37:25 <KipIngram   > DKordic: It's only about $15 at Digikey.
2026-06-09 18:12:42 <Stalevar    > I wrote a 160 line long Pascal program. But I'm not sure what to do next, given it seemingly works as expected
2026-06-09 18:39:15 <lofty       > I have been wishing for some kind of "compressor explorer" so I can write two sequences of code and see which compresses better...
2026-06-09 18:40:04 <lofty       > And I've also tried to implicitly increase code self-similarity by assigning specific registers to things
2026-06-09 18:41:16 <lofty       > iv4nshm4k0v: I've read through Moving Forth; the assembly Forth kernel is structured with some of its advice in mind.
2026-06-09 22:12:41 <veltas      > lofty: The only way is to compress both and see what's longer, context matters to the result so I don't recommend analysing more than that
2026-06-09 22:13:08 <veltas      > It's best to understand roughly how the compression works, but it still comes down to profiling things