Home | Notifications | New Note | Local | Federated | Search | Logout
Irenes (many)@ireneista@adhd.irenes.space
You are all dreams and we are happy to know you, as you are nice dreams. We are an asexual autistic trans-feminine plural system with a label collection.
We compromise with legibility only so far as to say the following: Former Technology Director at Internet Safety Labs; ex-Google information privacy expert; looking for work. 🏳️⚧️🍁
Key Fingerprint: E864 BDFA AB55 36FD C905 5195 DBF2 52AF FB26 19FD
Key File: https://irenes.space/irenes.asc
Relevant Information: https://pluralpride.org/playbook/
Blog, Code, Thingamajigs: https://irenes.space/
Joined: 2026-09-08 19:04:18
16 notes, 0 following, 0 followers
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 18:33:32)
apparently some bad person today expressed the opinion women can't write assembly language?
interesting claim.
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 15:55:23)
indentation's working, time to do the line-trailing thing
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 15:10:21)
and then we'd also like to get some of these short ones to appear at the end of the line, after the bytes they reference, rather than on a separate line before the bytes. that would improve readability a lot, but it will require us to do something with the entry length field, which will be some annoying iteration logic.
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 15:09:28)
now we need to play with formatting a bit before it's worth doing more. we need to add metadata entry types for indentation, and the magic comment syntax needs to be augmented with a feature to adjust it
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 15:08:41)
yessss the metadata entries work and they do look exciting!
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 12:44:55)
after that, we'll be ready to actually create the metadata entries, which should look exciting in the hex dump
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 12:44:34)
okay! the alternate for ~ is written, and it correctly saves the comment text and installs the replacement. https://code.irenes.space/evocation/commit/?id=e42c36f0887de2bf2d5471e4eb59f6ad7cb79a21
the next step is to do that output-point tracking we mentioned
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 11:10:38)
for those who want to read the code, it's at https://code.irenes.space/evocation/ ... we're interested in feedback on how approachable it is, the docs are started but not finished ...
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 11:09:32)
so. this is all gonna work. we're excited. we don't really expect anyone followed all those details, but hopefully at least we got the core idea across, the special comment syntax.
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 11:08:56)
however, we're confident now that we understand the shape of those tweaks, and it's really not that bad. for the most part the hex transform just has to get out of their way and let them run, while treating the output they generate the same way it treats other output.
it also needs to modify how the log-load transform deals with comments, but that's easy.
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 11:07:58)
we're going to need to add one more layer of abstraction after we get this working on programs written in our Evocation dialect of assembly, which is what we've been starting with since it's simpler. when we need it to work on full Forth programs, the hex transform will have to do some additional tweaking to the label and log-load transforms, both of which are used as part of Forth compilation.
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 11:06:39)
so, that's the strategy. we think it's going to work. the experiments we did the other day showed us the general shape of all the call sequences the hex transform is going to encounter, and they're surprisingly uniform, not a lot of surprises.
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 11:05:43)
in particular all the actual output happens through a few low-level words such as pack8, which are given an address to write to as parameters.
the work we did earlier today created a trap that's called each time one of those words is, and we can have the trap save the next address after each piece of output. then it'll be available for the ~ replacement to reference.
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 11:04:57)
fortunately, it's not that hard to reconstruct. the compiler does go back and retrace its steps sometimes, re-writing areas of the output it's already done, but that happens in pretty controlled ways that we can deal with specially. for the most part, each major pass it does is filling the buffer up linearly, from beginning to end.
Reply to @ireneista@adhd.irenes.space
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 11:03:53)
anyway, so we need to have a running concept of where in the output buffer the current output point is, which is a concept the compiler keeps track of through means opaque to us.
Irenes (many)@ireneista@adhd.irenes.space (2026-09-08 11:02:05)
there's a specific interface between the transform and the compiler (the compiler is the thing being transformed), which is gradually becoming clearer in our head, and which we do intend to formalize as soon as we can get all the words together. it's not intended to work with any arbitrary thing the compiler might do, only stuff that follows the interface restrictions, so it's not as bad as it sounds.