2023-06-14 01:20:21 <lisbsths    > there is a link between concatenative programming and currying
2023-06-14 01:22:09 <lisbsths    > in both systems you pass an environment from left to right transforming it as you go
2023-06-14 01:23:11 <lisbsths    > with currying you build structure by consing tuples of anonymous type
2023-06-14 01:23:48 <lisbsths    > with forth state is ! and @ from computer memory
2023-06-14 01:39:16 <lisbsths    > I think this is related to making a purely consistent purely reversible forth
2023-06-14 02:15:32 <unjust      > what do you mean by the last bit: purely consistent purely reversible?
2023-06-14 02:32:58 <lisbsths    > mathemaitcal consistency like lean or like coq
2023-06-14 02:33:16 <lisbsths    > reversibility for a quantum computer
2023-06-14 02:33:33 <lisbsths    > maybe also pure immutability
2023-06-14 02:46:28 <unjust      > not familiar with those languages or quantum computing, but i'm interested to see what an implementation that meets the criteria would be like
2023-06-14 02:50:15 <unjust      > would all data consumed and produced be restricted to the data/parameter stack only? no variable/dictionary/heap access allowed? would you be able to compile words at all?
2023-06-14 07:15:33 <KipIngram   > My take on that is that the entire computer state is regarded as the thing evolving, not just the stack.
2023-06-14 07:16:12 <KipIngram   > unjust: In quantum theory all processes of change have a mathematical trait called unitarity.  A key feature of a unitary transformation is that it is reversible - no information is ever destroyed.
2023-06-14 07:17:31 <KipIngram   > So all of the "gates" in a quantum computer are fully reversible operations.  It turns out that in computing theory it's actually the erasure of information that causes you to necessarily consume energy.  In theory reversible processes can be reduced to zero energy consumption (though you do them very very slowly to get there).
2023-06-14 07:18:04 <KipIngram   > This really has nothing to do with the way our current computers consume energy - we're nowhere even close to that "theoretical energy consumption rate."
2023-06-14 07:19:15 <KipIngram   > It's ironic that quantum processes never lose information, and yet when we make a measurement using "basic quantum mechanics" we throw away the prior quantum state and replace it with a new one that's related to the measurement device.
2023-06-14 07:19:23 <KipIngram   > That doesn't seem like "not losing information."
2023-06-14 07:20:26 <KipIngram   > But it turns out that's just an approximation - in the real world that "thrown away" information in fact gets smeared out in the state of the measuring device, you, and the rest of the world.  It's still there - it's just lost in the environment in a way that we can't get it back "practically speaking."
2023-06-14 07:20:48 <KipIngram   > What we're really doing there is treating our little system as quantum but the measurement device as classical.
2023-06-14 07:21:10 <KipIngram   > So tossing aside that information is a "cheat" but one that's very very close to what actually happens.
2023-06-14 07:21:56 <KipIngram   > It's similar to saying that all of the air molecules in the room *do* have specific positions and velocities, but you certainly don't and can't know what they all are.
2023-06-14 07:24:00 <KipIngram   > Basic quantum mechanics really isn't a precise model of "the world" at all - you're deliberately treating most of the world as classical, while paying "quantum attention" to just the one little bit that you're focused on.
2023-06-14 07:25:41 <KipIngram   > People get all mystified about "quantum collapse," as though it's some mystical process.  But think about it - you have this tiny little quantum thing, like an electron or something, and you suddenly interact it with a ginormous measuring device that's big engouh for you to read something off of with your eyes.  Which thing do you THINK is going to win that contest?  It's no surprise at all that the
2023-06-14 07:25:43 <KipIngram   > instrument dominates the next state.
2023-06-14 07:26:10 <KipIngram   > "Collapse" is the process of forcing the little quantum system into compatibility with the big measuring device.
2023-06-14 07:28:33 <KipIngram   > They've held whole conferences on "Quantum theory without observers," but they've never really come up with anything terribly profound.  Basic quantum mechanics pretty much requires an "observer," and you treat the observer as a classical entity.
2023-06-14 07:29:31 <KipIngram   > Sometimes folks talk about "the wave function of the universe," but that's not a very helpful idea because the basic math process of the theory requires that classical / quantum divide somewhere in the picture.
2023-06-14 07:37:12 <KipIngram   > Anyway, if you think about it any Forth word at all could be thought of in the form
2023-06-14 07:37:27 <KipIngram   > system(t+1) = f(system(t))
2023-06-14 07:37:48 <KipIngram   > where system(t) is the whole computer state.
2023-06-14 07:38:26 <KipIngram   > For a lot of words you could restrict that to the stack, but not for all of them.
2023-06-14 07:39:12 <KipIngram   > If you focus only on the stack, then DROP loses information, but if you focus on the whole computer it doesn't - it's just a pointer increment/decrement.
2023-06-14 07:39:48 <KipIngram   > ! loses information regardless though, since it overwrites something.
2023-06-14 07:42:41 <KipIngram   > When a quantum computer runs, you wind up with "garbage" which is the stuff that's no longer of primary interest but holds the information you'd need ot reverse the operations.  Take an AND gate for example - the quantum equivalent has two bits of output - the result of the AND and some "leftovers."  With the result and the leftovers you could "un-AND" and get back your original inputs.
2023-06-14 07:43:19 <KipIngram   > You have to deal with that garbage properly to get the results you want from the computer.
2023-06-14 07:45:33 <KipIngram   > The usual way of running a quantum computer is to put the inputs into a "superposition" of all possible states.  And input possibilities that lead to the same output you'd like to "interfere" with each other, but they won't if they make different garbage - only when you've dealt with that garbage properly will you get the output with the interference you want.
2023-06-14 07:46:09 <KipIngram   > If that sounds fuzzy it's my fault - I don't REALLY know this stuff well enough to actually work with it.  But those ideas are "in there" somewhere.
2023-06-14 07:47:57 <KipIngram   > If you let that garbage slip away then you can't do the right stuff to it to get the answer you want.  And that's why interaction with the environment is so bad in a quantum computer - you lose the ability to work further with the info that slips away.
2023-06-14 08:13:39 <unjust      > thanks for the explanation
2023-06-14 08:50:47 <KipIngram   > Well, wish I could make it a little better.  It's "vaguely on track."
2023-06-14 08:52:34 <KipIngram   > It's always just amused me a little that so much "popular media" stuff on this general domain tries to draw these big sweeping philosophical conclusions about the whole world from this stuff, when actually it's a very "rough" model to start with.  Just not made to talk about "the whole world."
2023-06-14 08:55:07 <drakonis    > i feel like i need an interactive assembler right now
2023-06-14 08:55:26 <drakonis    > fasmg is nice and all that but sometimes i feel like i need some direct feedback
2023-06-14 08:56:34 <drakonis    > asmrepl only does x86-64 so it doesnt really help me out with what i'm currently doing
2023-06-14 08:57:40 <drakonis    > i'm too early in my assembly learning to have an assembler powered by forth
2023-06-14 08:58:44 <KipIngram   > The main puzzle on a Forth-based assembler is just seeing some kind of pattern in the encoding of the instructions.  How easy that would be would depend a lot on the particular instruction set.
2023-06-14 09:00:04 <KipIngram   > It would be neat if there was a site like this one:
2023-06-14 09:00:06 <KipIngram   > https://defuse.ca/online-x86-assembler.htm#disassembly
2023-06-14 09:00:19 <drakonis    > compiler explorer, probably?
2023-06-14 09:00:19 <KipIngram   > that had some kind of a program accessible API.
2023-06-14 09:00:36 <drakonis    > actually, there's an implementation of godbolt on emacs
2023-06-14 09:00:46 <KipIngram   > You could potentially wire such a thing into your Forth, so that it was doing the encoding for you.
2023-06-14 09:00:48 <drakonis    > https://gitlab.com/jgkamat/rmsbolt
2023-06-14 09:00:56 <KipIngram   > Oh, interesting.
2023-06-14 09:01:31 <drakonis    > can disassemble assembly
2023-06-14 09:01:41 <drakonis    > to assembly, rather
2023-06-14 09:02:30 <drakonis    > objdump seems to be the thing
2023-06-14 09:04:26 <drakonis    > "Allows targeting custom compilers - which means disassembly for niche assembly targets, specific commits of compilers, and patched libraries or compilers is possible."
2023-06-14 09:04:28 <KipIngram   > I managed to get a fair subset of x64 encoding sussed out just by staring at it, but it was kind of tedious.
2023-06-14 09:04:35 <drakonis    > aight i'm going to hack this one up to do assembly later today
2023-06-14 09:06:10 <drakonis    > so, godbolt does exactly the same as the site you linked
2023-06-14 09:06:21 <drakonis    > it gives you the encodings
2023-06-14 09:06:54 <KipIngram   > I'll have to take a look.  I'd really prefer to have a self-contained setup, but it's a nice ace to have in a hip pocket.
2023-06-14 09:07:17 <KipIngram   > We're fortunate that we don't really need the WHOLE x64 instruction set.
2023-06-14 09:07:53 <drakonis    > thankfully, but if you need the extensions, they're there.
2023-06-14 09:08:58 <drakonis    > godbolt can be self-hosted, mind you
2023-06-14 09:09:14 <drakonis    > but its a bit heavy
2023-06-14 09:11:03 <drakonis    > https://dogbolt.org/
2023-06-14 09:11:05 <drakonis    > neat
2023-06-14 09:11:11 <drakonis    > there's godbolt but for decompilation
2023-06-14 09:14:49 <KipIngram   > Yeah, if you were trying to do something really fancy you might need the more esoteric stuff.
2023-06-14 09:15:05 <KipIngram   > I usually am thinking primarily about just building a basic Forth system.
2023-06-14 09:15:07 <drakonis    > hmm, one of the godbolt developers expressed some minor interest in supporting forths
2023-06-14 09:15:15 <KipIngram   > :-)
2023-06-14 09:16:47 <drakonis    > i found out when i joined the discord server for it
2023-06-14 09:20:50 <KipIngram   > Give godbolt's extensive capabilities, it's hard to see how it would be anything but heavy.
2023-06-14 09:24:17 <drakonis    > to be fair, its the deployment requirements
2023-06-14 09:25:15 <drakonis    > you need nodejs and typescript and then you have to download the dependencies for each language you want to use
2023-06-14 09:25:25 <drakonis    > then it runs these on containers i believe?
2023-06-14 09:25:40 <drakonis    > hmm, actually, it requires them to be installed locally
2023-06-14 09:26:05 <drakonis    > quite well built however.
2023-06-14 09:26:08 <KipIngram   > Hmmm.
2023-06-14 09:26:10 <Zarutian_iPad> https://www.youtube.com/watch?v=GyV_UG60dD4
2023-06-14 09:26:41 <drakonis    > https://github.com/compiler-explorer/compiler-explorer
2023-06-14 09:30:51 <drakonis    > https://godbolt.org/noscript there is a javascript free version of the website
2023-06-14 09:31:11 <drakonis    > which is nice i suppose, but doesnt change that it is heavy on dependencies
2023-06-14 09:32:49 <unjust      > are you just trying to get something that will spit out machine code for each instruction in assembly that you feed it?
2023-06-14 09:37:28 <unjust      > this requires just objdump, a shell, and some utilities you probably already have: https://termbin.com/ylir
2023-06-14 09:37:33 <drakonis    > yes.
2023-06-14 09:37:41 <drakonis    > that's what kip's been doing with the website he linked earlier
2023-06-14 09:37:59 <drakonis    > the website even quotes the tooling required
2023-06-14 09:38:29 <drakonis    > real cool stuff though
2023-06-14 09:39:27 <unjust      > in terms of those online services, found dogbolt recently - pretty useful if you want to throw a binary at a few decompilers and not have to host them yourself
2023-06-14 09:39:34 <drakonis    > yeh, dogbolt.
2023-06-14 09:40:04 <drakonis    > i didnt know about some of these decompilers
2023-06-14 09:41:00 <drakonis    > https://github.com/decompiler-explorer/decompiler-explorer
2023-06-14 09:41:01 <drakonis    > neato.
2023-06-14 09:41:05 <unjust      > binary ninja seems to give the most sane output for linux x86 elf binaries of that log
2023-06-14 09:41:14 <unjust      > lot*
2023-06-14 09:42:07 <drakonis    > this makes me want a whole assembler toolchain in a single binary with minimal dependencies
2023-06-14 09:42:25 <drakonis    > a hackable toolchain, even.
2023-06-14 09:43:08 <unjust      > i also hate the bloat that comes with most diagnostic tools, or tools in general nowadays
2023-06-14 09:43:47 <thrig       > (someone was complaining that a cli tool would download chromium, spin it up, send a request to it, get a file out, then turn off chromium)
2023-06-14 09:44:20 <unjust      > thrig: what tool was that?
2023-06-14 09:45:46 <thrig       > https://thrig.me/tmp/a-rant.txt
2023-06-14 09:46:04 <drakonis    > fasmg represents a sort of ideal state where everything is macros, and when macros are too slow, it compiles macros to speed it up
2023-06-14 09:46:42 <drakonis    > so you can do preprocessor-like things with it
2023-06-14 09:47:13 <KipIngram   > unjust: Yeah, the modern philosophy is a "everything including the kitchen sink" approach.  Just throw it in - it might come in handy.
2023-06-14 09:47:14 <drakonis    > which allows for writing tooling with only a single binary
2023-06-14 09:47:46 <drakonis    > i forgot the name of the tool that uses chromium for javascript test harnesses
2023-06-14 09:48:29 <drakonis    > obsidian is basically a giant pile of javascript and html on top of a browser engine
2023-06-14 09:49:27 <drakonis    > selenium is what i'm thinking of
2023-06-14 09:49:49 <drakonis    > browser automation software
2023-06-14 09:50:24 <unjust      > selenium is probably the only tool i can think of where spawning a browser from a script for the purpose of retrieving remote data makes sense
2023-06-14 09:50:35 <drakonis    > sure
2023-06-14 09:50:45 <drakonis    > that one i wont complain about
2023-06-14 09:52:00 <unjust      > but having said that, you can definitely scrape tons of stuff with just wget/fetch with sed and/or awk
2023-06-14 09:53:33 <unjust      > no need to parse html+javascript and arbitrary json objects, when there are tokens (arbitrary strings) always present in some fairly fixed relation to the info that you want
2023-06-14 10:18:29 <unjust      > proof of concept: https://raw.githubusercontent.com/jhswartz/search/master/search-youtube
2023-06-14 10:19:08 <thrig       > yt-dlp breaks as they fiddle with the site, though
2023-06-14 10:20:23 <unjust      > this just uses wget + sed + awk, it's been ok for a few years using the same scheme
2023-06-14 10:21:59 <unjust      > example output @ https://raw.githubusercontent.com/jhswartz/search/master/README
2023-06-14 12:52:16 <drakonis    > hmm, setting up compiler explorer was surprisingly easy
2023-06-14 12:54:30 <drakonis    > its pretty much just nodejs plus the compilers you want to use
2023-06-14 12:55:50 <drakonis    > painless to selfhost
2023-06-14 12:57:16 <thrig       > (I recently tossed the last node dependency I had, which also got rid of openssl)
2023-06-14 13:03:50 <drakonis    > unjust: objdump is very useful.
2023-06-14 13:04:02 <drakonis    > tyvm
2023-06-14 13:05:20 <drakonis    > the snipppet you linked is missing just the flag for controlling the syntax output
2023-06-14 13:05:54 <drakonis    > it otherwise defaults to at&t syntax
2023-06-14 13:07:15 <drakonis    > -M intel should do the trick
2023-06-14 13:07:33 <drakonis    > there's also intel-mnemonic
2023-06-14 13:07:57 <drakonis    > doesnt seem to look any different though
2023-06-14 13:40:29 <unjust      > drakonis: ah, i didn't include that because i prefer at&t over intel syntax. glad to hear it worked out though.
2023-06-14 13:40:41 <drakonis    > fair.
2023-06-14 13:41:09 <thrig       > emacs vs vi, at&t vs intel, gnome vs kde, ...
2023-06-14 13:41:43 <drakonis    > i dont exactly have a world of choices with my current assembler with regards to syntax
2023-06-14 13:42:20 <unjust      > not really an issue if you use that with an objdump built for a cross-compilation toolchain though, then you're lumped with whatever the GNU assembler thinks is appropriate for your target arch
2023-06-14 13:46:33 <drakonis    > also, how do you begin writing an assembler anyways?
2023-06-14 13:46:52 <drakonis    > how does one write an assembler in the first place
2023-06-14 13:47:03 <thrig       > ed(1)
2023-06-14 13:47:20 <thrig       > or there's probably compiler (dragon) books about this
2023-06-14 13:47:44 <drakonis    > i'm curious now because fasm's author doesnt exactly take patches unless its for minor changes and anything else discussed in the related forums
2023-06-14 13:50:02 <drakonis    > not feeling sufficiently defiant to do that yet
2023-06-14 13:55:34 <drakonis    > maybe rolling out one with smithforth might be a fun time
2023-06-14 14:02:27 <unjust      > 1. determine the instruction encodings used for the desired target cpu, 2. select or devise an assembly language syntax that appeals to you, 3. determine how instructions formatted according to (2) need to be transformed into the format dictated by (1), 4. write a parser that implements (3)
2023-06-14 14:07:40 <unjust      > then decide if you need features that make the programmer's life more comfortable, like allowing the assembler to keep track of origin and location, or if you want to handle labels and/or generate symbols. maybe you want to implictly calculate offsets for things like branches and references based on labels or absolute numbers when underlying instructions require relative offsets
2023-06-14 14:08:38 <unjust      > maybe you want macros, or maybe you feel the need to implement features that a linker might normally handle
2023-06-14 14:08:40 <KipIngram   > It's pretty easy to calculate branch offsets.  One way or another you save an address on the stack, and then finish up at the other end.
2023-06-14 14:09:07 <KipIngram   > You're either setting an offset for a forward jump or just marking the location for a later back jump to hit.
2023-06-14 14:09:15 <KipIngram   > Forth and it's stack is just lovely for that.
2023-06-14 14:12:48 <drakonis    > yep.
2023-06-14 14:13:02 <drakonis    > so it might be a lot easier if i just do it in a very small forth
2023-06-14 14:13:25 <drakonis    > i want to have macros and linker features
2023-06-14 14:13:32 <drakonis    > begone linker dependencies
2023-06-14 14:17:18 <drakonis    > it seems well documented
2023-06-14 14:18:05 <unjust      > you'll also need some reference material about the binary format you want to output, and some diagnostics to make it easy to verify the output is sane, if you aren't content with just producing raw machine code
2023-06-14 14:18:06 <KipIngram   > Yes, that's exactly what I'm going for.  I don't want any other tool dependencies - I want to be able to operate entirely within my own system.
2023-06-14 14:18:12 <drakonis    > https://www.youtube.com/playlist?list=PLZCIHSjpQ12woLj0sjsnqDH8yVuXwTy3p
2023-06-14 14:18:31 <drakonis    > https://www.youtube.com/playlist?list=PLZCIHSjpQ12wX5m6q4dQNQcmmjq9oF3or
2023-06-14 14:18:41 <KipIngram   > "Linker" stuff - for me that has mostly to do with migrating items between "offset form" and "address form."
2023-06-14 14:19:25 <KipIngram   > Some things need to be addresses, but you don't know 'em until you know where you're putting it in your address space.  So in the disk resident format they get offsets instead, and then get changed to addresses at load time.
2023-06-14 14:20:18 <KipIngram   > You have to invent a way to know where those things are - in my current plan it's "the tables."  Every cell of either table is such a field, and only 2-3 other things need to become addresses - I will handle those with case-specific code.
2023-06-14 14:43:24 <drakonis    > no time like the present.
2023-06-14 14:48:20 <KipIngram   > I think that I want to assemble into blocks in a way that is immediately executable, and then have a word to "squash" that into a final disk resident image.  That means I'd assemble addresses, squash to offsets, and load offsets->addresses.
2023-06-14 15:04:10 <KipIngram   > And, well, of course I want to be able to assemble into my running dictionary too - that last was talking about meta- stuff.
2023-06-14 15:04:55 <KipIngram   > But assembling into the running dictionary and assembling into a target dictionary will be almost the same thing - just different places to deposit the stuff.
2023-06-14 15:21:06 <KipIngram   > I want to be able to assemble a metacompile target into blocks, and then "run it," as its own stand alone system - then saying bye should send me back to the system I launched it from.
2023-06-14 15:21:26 <KipIngram   > I've got the basic mechanics of that already working.
2023-06-14 15:21:51 <KipIngram   > I've made headers and I've assembled code into a block and run it - just have't put the two together yet into a "Forth."
2023-06-14 15:22:29 <KipIngram   > That was a linked list set of headers, though, and now I'm leaning toward this hash-based setup, so some of that will be to re-do.
2023-06-14 17:07:28 <drakonis    > i'm going through this and wow this is a lot of forth words in assembly https://github.com/albertvanderhorst/yourforth/blob/master/yourforth.fas
2023-06-14 17:08:27 <drakonis    > jonesforth is much better at being educational
2023-06-14 17:08:50 <drakonis    > also doesnt have 210 words in assembly
2023-06-14 17:09:07 <MrMobius    > making an assembler is fun. the tough part is recognizing addressing modes and evaluating expressions if it supports algebraic expressions
2023-06-14 17:10:12 <MrMobius    > Forth style assemblers sometimes encode the addressing mode in the instruction name which is a bit cumbersome but works
2023-06-14 17:10:39 <drakonis    > its not too different from at&t syntax, yeah?
2023-06-14 17:13:45 <MrMobius    > You can do something like "mov al, bl" in Intel which is "movb %bl, %al" or something like that in at&t. With forth it might need to be "bl al mov_r8r8"
2023-06-14 17:14:12 <MrMobius    > So extra annoyance for the user to indicate the form of mov in the instruction name
2023-06-14 17:15:56 <MrMobius    > Assuming al and bl push an ID number onto the stack that mov_r8r8 uses to figure out what registers. You could have them push a type ID onto a second stack but then you'd need an extra marker for immediates
2023-06-14 17:20:00 <MrMobius    > For example if al pushes a 5 on the stack and bl pushes a 6 then you don't know how to tell the difference between "mov al, 6", "mov 5, bl" and "mov 5, 6" which is why you need the _r8r8 suffix. You could do something like "5 IMMED al mov" for "mov al, 5" if IMMED pushes a type ID. Either way you're annotating
2023-06-14 17:58:41 <drakonis    > hmm, how would the assembler experience be improved?
2023-06-14 17:59:12 <unjust      > for a specific case? or for assembly in general?
2023-06-14 17:59:26 <drakonis    > in general
2023-06-14 17:59:41 <thrig       > modern assembly is more written for compilers than the meat popsicles
2023-06-14 18:00:35 <drakonis    > like, as previously mentioned, its annoying to append modifiers to word names
2023-06-14 18:01:12 <drakonis    > meat popsicles, heh
2023-06-14 18:01:58 <drakonis    > i was thinking about having a word that does addressing mode calculations
2023-06-14 18:02:17 <unjust      > for an architecture like x86, those modifiers/annotations exist because they are, individually, closer representations of the actual instructions encoded than the mnemonics you see in the popular syntaces
2023-06-14 18:02:36 <drakonis    > i see
2023-06-14 18:03:44 <unjust      > you can abstract that away by implementing a bunch of IF/ELSE or CASE statements that will determine which encoding (so, addressing mode, operand order and operand size) you probably meant
2023-06-14 18:05:43 <drakonis    > it does seem like a serviceable solution
2023-06-14 18:06:20 <unjust      > so that logic would be in whatever you have to parse a MOV instruction ... which might determine whether you actually need MOVB, MOVW (which could be abstracting away MOVW-RR MOVW-RS MOVW-SR MOVW-RM MOVW-MR MOVW-IR MOVW-IM etc.), MOVL and MOVQ
2023-06-14 18:08:39 <unjust      > but as there're groups of instructions that will have more or less the same operand and addressing mode patterns, maybe you only define each case once and use the CREATE / DOES> pattern to generate the actual words for each case. each would get the appropriate opcode value thrown in at creation time.
2023-06-14 18:12:28 <unjust      > in the end, if you're accustomed to using those size and operand annotations included in the mnemonic - you have to ask yourself if it's worth the effort implementing all of the baggage to obtain smarter mnemonics
2023-06-14 18:12:58 <drakonis    > hmm, it is a quite good question
2023-06-14 18:13:29 <drakonis    > perhaps as a toy
2023-06-14 18:16:49 <drakonis    > but it is a bit soon to be doing that
2023-06-14 18:19:18 <unjust      > it could also be useful as more than a toy. if you wanted a word/macro that generated syscalls for linux/x86-86 for example, because you need to pass in the syscall function arguments into a bunch of registers - a lot of that register population is likely to be performed via MOVQ instructions most of the time, and they're always going to have a register destination. although the source operand type can vary, so if you're able to parameterize the sou
2023-06-14 18:21:31 <unjust      > something like ... 47 :I RDI :R MOVQ ... SOME-STRING :M R10 :R MOVQ
2023-06-14 18:22:05 <unjust      > where :M indicates memory/address/pointer (displacement optional?)
2023-06-14 18:25:21 <KipIngram   > drakonis: Someone was performance-inclined.  ;-)
2023-06-14 18:25:39 <drakonis    > ha, me?
2023-06-14 18:25:51 <drakonis    > i want to experiment
2023-06-14 18:26:02 <KipIngram   > MrMobius: I added "mode words."
2023-06-14 18:26:16 <KipIngram   > rax rbx d[] mov
2023-06-14 18:26:39 <KipIngram   > That's "destination indirect," so it's mov [rax], rbx
2023-06-14 18:27:13 <KipIngram   > I have d[] s[] and also d[i] s[i].
2023-06-14 18:27:43 <KipIngram   > mov rax, [rbx+0x08] -> rax rbx 8 s[i] mov
2023-06-14 18:37:43 <KipIngram   > I actually didn't have to use a bunch of conditionals for my assebly subset.
2023-06-14 18:37:54 <KipIngram   > It's more or less just "calculated."
2023-06-14 18:38:26 <KipIngram   > I mean, there are some decisions in the logic, but not anything terribly "overt."
2023-06-14 18:39:05 <KipIngram   > Foremost is the exceptional nature of rsp and r12, and particularly rbp and r13.
2023-06-14 18:39:45 <KipIngram   > Those I just had to "check for" explicitly, because they deviate from the pattern that otherwise holds.