currently contemplating Uint9Array (yep, 9)

· · Web · 1 · 0 · 0

@neauoire i'm not sure if ternary is more or less weird than what i'm doing! i'm thinking that each byte in my vm will have a flag bit of whether or not it is a label definition, used to determine where labels/functions start and end when bytes are added or removed at runtime as an alternative to the block-rewriting based approach you suggested earlier. not sure which one will end up leaving more empty space!

@scout you probably don't need a bit for that, just an opening and a closing one. In uxntal, for example, I use the unused 0x40 and 0x60 to indicate the beginning of a data block. Using a bit for that would use soo much space.

@neauoire the problem i'm running into is that i want to use labels to refer to arbitrary data too, so reserving specific bytes would make certain bytes off-limits for data... (i thought about using some kind of escape sequence for those bytes, but then the size of the data and its representation would differ, which seems even more confusing)

@scout Oh, well in that case, what you could do, is use a specific file format.

Imagine like, when you assemble your binary file, right. You also generate a symbols file, that has a series of labels and addresses. You could just cat these 2 files with each other, so your binary specification would be like here is data, and here are the symbols for this file.

@scout it wouldn't use any precious opcode space that way :)

@neauoire unfortunately i'm trying to avoid needing an assembler, too, i'd like to be able to modify the bytecode at runtime! i want that smalltalk fast-feedback-loop experience (:

@scout smalltalk is everything but fast tho, it's extremely slow.

@neauoire oh i just mean cutting down the time between editing code and seeing your changes in the system by keeping the application state and not needing to recompile/reassemble, i don't think my language will run very fast either. being able to edit code while otherwise keeping the same state is very nice for game programming especially, when the game state you're trying to test can take a long time to get back to

@scout have you thought about making save-states? like exporting the emulator memory, and loading it back instead of always restarting from the boot screen? Most emulators can do that.

It might be a more practical approach than using 9 bits words, maybe. ;)

@neauoire that would work too, but it feels more complex to me than just making programs 12.5% bigger! the whole rest of my VM will be pretty silly about space too so i think it's ok - the move opcode takes three whole null-terminated variable name strings as its operands hehe. i'm really throwing memory under the bus to hopefully help improve readability/maintainability of binary code

@neauoire i'm sort of thinking about "i found this executable written 10 years ago and i can tell how it works and hack and reuse it" as a potentially interesting angle of a permacomputing-friendly language, even if its programs are not as energy or memory efficient

@scout @neauoire Wouldn't a base like collapseOS achieve the same goal without the performance penalty? It's already pretty hackable and can be used to hack on itself. That's pretty much its entire goal actually.

@scout well it's a lovely idea nonetheless, I think you should pursue it :) Making binaries understandable in the future is a pretty interesting problem.

@scout @neauoire I made a toy VM with somewhat similar goals (directly editable bytecode), but I used an approach somewhat closer to BASIC. Not fast or powerful, but very very simple.

Hmm, I should probably migrate it over to SourceHut.

Sign in to participate in the conversation

Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.