2023-07-12 09:12:02 <drakonis    > https://github.com/tgrysztar/fasmg/blob/master/packages/x86-2/test.asm neat
2023-07-12 09:19:30 <drakonis    > fasmg can output the assembler encodings into the source file with iev.alm
2023-07-12 09:23:57 <veltas      > Think I'm alright sticking with listings
2023-07-12 09:24:30 <KipIngram   > It's an interesting "option," though.
2023-07-12 09:25:36 <veltas      > I suppose it lets oldschool people work with something more like their old source
2023-07-12 09:26:11 <veltas      > I've never done machine code directly except very early in Z80 learning, otherwise been content with generating listings and objdumps
2023-07-12 09:26:26 <veltas      > I do look at machine code regularly though
2023-07-12 09:26:46 <drakonis    > https://board.flatassembler.net/topic.php?t=22077
2023-07-12 09:26:58 <KipIngram   > I haven't either - I've always used SOMETHING (even if it was only DEBUG's internal assembler) to "help out."
2023-07-12 09:29:18 <drakonis    > there's also another cool trick in x86-2 which is being able to specify the instruction encodings separately
2023-07-12 09:29:46 <drakonis    > iev.alm is separate from it and can be used normally
2023-07-12 09:35:23 <MrMobius    > I've looked at machine code then turned it back to assembly for MIPS as a comment if each line since there are various things the instruction you wrote could actually be converted to
2023-07-12 09:38:42 <MrMobius    > div for example outputs about 10 instructions including div
2023-07-12 09:40:22 <drakonis    > mips has pseudoinstructions which are basically macros, right?
2023-07-12 09:40:24 <MrMobius    > and you get different instructions not the same instruction with a different mode when you're using relative addressing. this is quite devious compared to x86
2023-07-12 09:40:58 <MrMobius    > it has a couple pseudo instructions for things like loading constants
2023-07-12 09:43:29 <KipIngram   > Surely those aren't actually "considered" instructions, though?  Wouldn't the individual pieces be the "instructions"?
2023-07-12 09:45:45 <MrMobius    > depends on what you mean by instruction. humans and compilers write an "instruction" that turns into one or more instructions executed by the CPU
2023-07-12 09:46:46 <MrMobius    > just like on other architecturea where they have a shift right by one op but nothing for shift left so when you use the shift left instruction it's actually a macro for add without carry
2023-07-12 09:47:25 <MrMobius    > plenty of people have no idea there's not a hardware instruction and the assembler is just reusing something
2023-07-12 09:48:26 <MrMobius    > since x<<1 = x+x
2023-07-12 09:49:05 <KipIngram   > I think of a "machine instruction" as a sequence of operation that are always the same.  Atomic, so to speak, meaning that there aren't any variations available.  I'm not finding good words to describe what I mean here.  :-(
2023-07-12 09:49:14 <KipIngram   > "The lowest level of hardware control"
2023-07-12 09:50:05 <KipIngram   > If something becomes a sequence of actions (and this is still to "vague"), it's a macro.  To me at least.
2023-07-12 09:50:12 <MrMobius    > ya from a hardware point of view you may get multiple instructions (or not) from each line a han writes even though the human thinks they're writing one instruction per line
2023-07-12 09:50:13 <KipIngram   > "too" vague
2023-07-12 09:50:30 <KipIngram   > Ok.  Macros.
2023-07-12 09:50:39 <KipIngram   > Which is fine.  I just draw a distinction.
2023-07-12 09:51:04 <KipIngram   > Here - here's a way to describe it.
2023-07-12 09:51:37 <KipIngram   > I write the line of source.  I wind up with a pattern of bits.  If it's possible for me to hand manipulate those bits and stick something into the middle of them, then that's not an instruction - it's several instructions.
2023-07-12 09:52:09 <KipIngram   > An instruction is a pattern of machien code bits that I can't "insert into" and have it work.
2023-07-12 09:53:03 <MrMobius    > right but generally macros have different names and possibly syntax than an instruction. is instruction FOO still a macro if it produces an instruction also named FOO and also additional instructions depending on the argument? especially considering syntax like FOO $t0, 5($t1)? I would say no. you can't pass 5($t1) to most macros then split that into 5 and $t1 then so something useful
2023-07-12 09:53:10 <KipIngram   > So if my bits are AAABBB - if there exists any CCC such that AAACCCBBB is valid code, then AAABBB is more than one instruction.
2023-07-12 09:53:36 <MrMobius    > right
2023-07-12 09:53:37 <KipIngram   > I always get torn over whether to write macro names in a way that distinguishes them.  More often than not I don't.
2023-07-12 09:54:04 <KipIngram   > i think this is the Forth in me speaking - I like to feel like I'm "extending my assembly language" the same way I extend the dictionary in Forth.
2023-07-12 09:54:39 <KipIngram   > Like I call my macro 'next' and think of it as though it's an instruction.
2023-07-12 09:56:29 <KipIngram   > I have quite a few macros in my latest Forth, which capture operations closer to the Forth architecture than the instructions themselves.  I use them as though they're instructions.
2023-07-12 09:57:27 <KipIngram   > Like so:
2023-07-12 09:57:29 <KipIngram   > https://pastebin.com/nVKSVpjE
2023-07-12 09:57:40 <KipIngram   > getd, incd, next
2023-07-12 09:57:57 <KipIngram   > And I rename the registers to fit the Forth design too.
2023-07-12 09:58:15 <KipIngram   > So much easier to remember those Forthy register names than otherwise.
2023-07-12 09:59:21 <KipIngram   > So I actually paused a few minutes yesterday and considered doing a code threaded design.
2023-07-12 09:59:50 <KipIngram   > The main problem with it, though, is that it undermines my ability to support thread switching the way I'd been planning to.
2023-07-12 10:00:20 <KipIngram   > That thread handling mechanism relies on execution passing through a central "docol" bit of code.
2023-07-12 10:00:47 <KipIngram   > I.e., I'm stuffing it into my "subroutine call' operation.
2023-07-12 11:21:09 <KipIngram   > Regarding thread scheduling, I'm inclined to keep it fairly straightforward.  I'll provide each thread with a core mask, so that I can pin it completely or partially, or whatever.  If a thread just "ticks out," it will remain in whatever core ring it's in.  When it needs to wait for something explicit, though, it'll get moved out of that ring and into the wait ring for that resource.
2023-07-12 11:21:32 <KipIngram   > Then when bringing threads back from resource wait, I'll put them into the most lightly loaded core compatible with their mask.
2023-07-12 11:22:14 <thrig       > assuming a frictionless round robin...
2023-07-12 11:22:55 <KipIngram   > Yeah - I intend to have a "nice" value which will cause "nicer" threads to only take some of their round robin opportunities to run.
2023-07-12 11:23:27 <KipIngram   > nice 0 threads will run true round robin - every time it's there turn.  But I'll be able to have them skip rounds if I want to.
2023-07-12 11:23:53 <KipIngram   > Ugh.
2023-07-12 11:23:56 <KipIngram   > THEIR turn
2023-07-12 11:24:05 <KipIngram   > :-(
2023-07-12 11:24:08 <thrig       > (it's hilarious when load balancers go sideways)
2023-07-12 11:24:24 <KipIngram   > Yeah, I'm sure there are all kinds of subtleties there.
2023-07-12 11:24:35 <KipIngram   > That's why I'm inclined to avoid trying to be too fancy.
2023-07-12 11:24:36 <thrig       > send all traffic to the failed host that's responding really quickly?! can do!!
2023-07-12 11:25:42 <KipIngram   > I could also see having some preference for putting a thread back on the core it was previously on, in case there's still some cache content lying around that it would find useful.
2023-07-12 11:26:50 <KipIngram   > So maybe I only "balance" when I reach some threshold of "unbalanced."
2023-07-12 11:27:38 <KipIngram   > Like, if there's 10 and 11 threads on a pair of candidate cores, but the one with 11 is the one the thread I'm managing now was on before, maybe I ought to put it back there in spite of the other one being more "balanced."
2023-07-12 11:27:53 <KipIngram   > So implement a "kinda sorta balanced" mechanism.
2023-07-12 11:28:33 <KipIngram   > So put it back where it was before, unless that's a "bad idea" for some reason TBD.
2023-07-12 11:31:53 <KipIngram   > The problem with all of this is that I'm tending to think about a situation where I'm actually making all of these decisions, but in the immediate future it's all going to be running on top of pthreads or something.
2023-07-12 11:32:10 <KipIngram   > So really Linux is going to be making a lot of the calls.
2023-07-12 13:54:22 <veltas      > thrig: I read that in Mr Meeseek's voice
2023-07-12 23:26:06 <KipIngram   > It occurs to me I need a new word to refer to a stream of execution which can switch from logical thread to logical thread.  The threads are the things that get switched among, by a single core  via time sharing.
2023-07-12 23:26:35 <KipIngram   > In our system-level storage management system at work we use the word "fiber."  I don't know if that's commonplace or specific to us, but it's a good word.
2023-07-12 23:29:03 <KipIngram   > Well, I just finished the very last available Craig Schaefer novel tonight.
2023-07-12 23:29:25 <KipIngram   > Read most of them via a one month free trial of Amazon Kindle Unlimited.
2023-07-12 23:29:34 <KipIngram   > Which I just cancelled before the month ran out.
2023-07-12 23:29:53 <thrig       > if you eat books you'll get more fiber in your diet