2023-08-05 03:15:06 <next4th     > 
ACTION try to memorize MOD-REG-R/M & MOV today...

2023-08-05 05:13:57 <xelxebar    > next4th: Nice! Strength to you.
2023-08-05 05:15:59 <veltas      > I'm working on a microkernel
2023-08-05 05:16:09 <veltas      > Pretty much written an assembler for it in two blocks
2023-08-05 05:17:08 <next4th     > xelxebar: thanks, may the forth be with us
2023-08-05 05:17:23 <next4th     > veltas: that sounds cool
2023-08-05 05:17:33 <veltas      > The idea is the microkernel is there to allow easy porting, but you can extend and define more for platforms when you have time
2023-08-05 05:18:41 <veltas      > Doing so be cause I was quite impressed by ilo when I rewrote it in x86-64
2023-08-05 05:19:02 <veltas      > because*
2023-08-05 05:21:13 <next4th     > are drivers in a microkernel implemented via syscall or rpc to the kernel instead of direct jump to kernel's functions?
2023-08-05 05:21:40 <veltas      > 'kernel' in Forth refers to the core code words usually
2023-08-05 05:21:54 <veltas      > Or to a 'VM' if you run on a VM
2023-08-05 05:21:57 <veltas      > Here it's more like a VM
2023-08-05 05:22:32 <veltas      > So the drivers would probably just be provided via a special instruction, but in this case the only I/O is via a block file and stdin/stdout
2023-08-05 05:22:52 <veltas      > Because the point of the kernel currently is to cross-compile a platform-specific forth
2023-08-05 05:23:24 <veltas      > I've written my initial implementation in about 200 lines of ANSI C
2023-08-05 05:23:39 <veltas      > But it should be easy to write in assembly for any platform
2023-08-05 05:23:49 <veltas      > There's only 16 ops supported
2023-08-05 05:26:05 <veltas      > lit, call, ret, branch, add, and, not, twice, halve, store, fetch, get, set, drop, pick, rot
2023-08-05 05:26:21 <veltas      > Sorry roll* not rot
2023-08-05 05:26:33 <veltas      > pick and rot take a byte immediate argument for how much they move
2023-08-05 05:26:41 <veltas      > roll*
2023-08-05 05:26:50 <xelxebar    > veltas: Oo. Nifty. Are you actually doing ring separation and stuff? Or does everything live at the same level?
2023-08-05 05:27:08 <veltas      > No it's not a 'kernel' in OS sense, it's a kernel in Forth sense
2023-08-05 05:27:17 <veltas      > But certainly it could be a kernel in OS sense
2023-08-05 05:27:30 <veltas      > Everything 'lives' at the same level, there's no protection
2023-08-05 05:27:49 <veltas      > The aim of this microkernel is portability, to allow you to 'get started' on a new platform as quickly as possible
2023-08-05 05:28:06 <veltas      > Or I would have included things like multiplication or division in my ops :)
2023-08-05 05:29:47 <veltas      > The word kernel just means 'core'. So a Forth kernel is basically the *core* words that are implemented as machine code, or in this case form the ops of a VM that's implemented in machine code
2023-08-05 05:30:05 <veltas      > I've written the VM in C but it can be trivially ported to any platform in assembly
2023-08-05 05:36:20 <veltas      > But Forth *is* an OS really
2023-08-05 05:48:36 <xelxebar    > I see. That makes sense. You're trying to get a nice, tight vocabulary that's both useful for getting running as a user as well as easy for porting.
2023-08-05 09:41:28 <KipIngram   > I'm still liking this F18A-inspired model.  I think there the "kernel" would be an implementation of the "machine instructions" and the little vm that runs them.  Then I'd want the rest of a "small bootstrap system" to be written using those instructions, which would make it portable across all platforms.
2023-08-05 09:50:55 <thrig       > http://www.righto.com/2013/09/intel-x86-documentation-has-more-pages.html
2023-08-05 09:51:21 <KipIngram   > One thing I'm considering is writing a Python emulator for that instruction set, and using that as a development platform for the higher code levels.  As long as I handle endianess and so on right, the result of that ought to be a binary compatible image I could just move over to another platform.
2023-08-05 09:52:28 <KipIngram   > I'm thinking all of my calls and jumps in this approach will be relative, so such an image would be fully relocatable.
2023-08-05 10:03:28 <KipIngram   > So, I finally bit the bullet yesterday and decided to try out one of these "reMarkable" electronic paper gadgets.  Supposedly is just much more like a "real paper" experience than common tablets.  I've been eying that thing for years, but was always put off by the price.  It's come down in price some.  Not a huge amount, but just enough to get it under my pain threshold.
2023-08-05 10:03:54 <KipIngram   > And it has a "100 day  no questions asked refund" policy on it, so I guess if I decide it was a terrible idea I can bail.
2023-08-05 10:04:48 <KipIngram   > It also looks like a really nice way to read pdf type papers and so on, and allows hand annotation while doing that.
2023-08-05 10:06:03 <KipIngram   > I figure there's at least a possibility that I'll totally fall in love with it - it's the sort of thing that might possibly prove to be worth every single penny.
2023-08-05 10:15:24 <KipIngram   > Hmmm.  The python 'keyboard' module looks pretty interesting.
2023-08-05 10:15:34 <KipIngram   > It does require running as root, unfortunately.
2023-08-05 10:15:57 <KipIngram   > Even detects pressing the shift key, which I've found to be a pretty uncommon feature.
2023-08-05 10:21:51 <KipIngram   > A main reason I think an emulator like I described above would be handy is thaT I think the compiler for this F18A instruction set would be somewhat more complicated than typical Forth compilers.
2023-08-05 10:22:24 <KipIngram   > It has to keep up with how much of the current instruction cell you've used, decide whether what's left is enough to do your next instruction or whether you have to move to the next cell, etc.
2023-08-05 10:22:34 <KipIngram   > A fair bit of somewhat delicate logic.
2023-08-05 10:22:49 <KipIngram   > Having a low-pain place to get that worked out would be nice.
2023-08-05 10:27:34 <KipIngram   > And once done, it would be implemented in the virtual instructions, and so it could just be carried anywhere.
2023-08-05 10:43:21 <MrMobius    > maybe put all 3-4 of them on one line?
2023-08-05 10:43:45 <MrMobius    > i have wondered how i would remember which are 4 bit and 3 bit instructions and put them in the right place
2023-08-05 10:44:09 <MrMobius    > unless it just inserts nops or something so you can put whatever instruction you want there
2023-08-05 10:44:35 <MrMobius    > or maybe it's three 5 bit instructions then one 3 bit instruction. dont remember
2023-08-05 11:15:07 <KipIngram   > Oh, I don't want the source layout to matter.
2023-08-05 11:16:16 <KipIngram   > As far as the VM goes, it'll be super simple.  At any given time you have an "instruction word" in a register.  You just repeat this process: 1) mask off the low six bits, 2) shift the instruction word right six bits, and 3) take that masked off value and use it with a jump table to jump to the code for that instruction.
2023-08-05 11:16:19 <KipIngram   > That's it.
2023-08-05 11:16:47 <KipIngram   > Eventually you will get 0b000000 and the code for that will reload the instruction word register.
2023-08-05 11:17:43 <KipIngram   > The instructions are ALL six bits.  You could encode 0b000000, 0b000001, 0b000010, or 0b000011 in those leftover two bits.
2023-08-05 11:18:13 <KipIngram   > So usually you will get five 6-bit opcodes in a cell, but now and then you might be able to get a sixth.  If it just so happens that the next instruction you need is one of those four.
2023-08-05 11:19:27 <KipIngram   > So something like mov rdx, rax; shr rax, 6; and rdx, 0x3F; jump with rdx
2023-08-05 11:20:14 <KipIngram   > Jumps and calls will use the remainder of the 32-bit cell as the offset.  If what's left is enough, you can use the rest of an ongoing cell - if it's not, you have to move to the next cell.
2023-08-05 11:20:41 <KipIngram   > That determination of how to handle jumps and calls (how EXACTLY) is part of that compiler logic I mentioned.
2023-08-05 11:22:02 <KipIngram   > Yes, I do think it would simplify the logic some if you manually kept up with what went in each cell by putting the source for each cell on one line.
2023-08-05 11:22:12 <KipIngram   > But that's just not very appealing to me.
2023-08-05 11:24:10 <KipIngram   > So the vm itself won't know anything about fetching the next instruction word.  That gets handled by the 0x000000 instruction.
2023-08-05 11:24:39 <KipIngram   > It's kind of like how my INTERPRET word has no idea how to "finish" interpreting a line of source - that gets handled by the null word.
2023-08-05 11:24:48 <KipIngram   > Which I've arranged to always eventually execute.
2023-08-05 11:52:40 <KipIngram   > Anyway, *running* the code will be super simple.  It's just constructing it that I think requires a little care.
2023-08-05 13:24:59 <KipIngram   > One neat thing about the design is that negative literals (which just live in whatever part of the instruction word is left above the last / most significant instruction) will keep a proper sign-extended value provided arithmetic right shift is used for those six-bit shifts.
2023-08-05 13:25:28 <KipIngram   > So when a lit instruction is executed, the instruction word will contain the proper 32-bit literal value.
2023-08-05 13:26:06 <KipIngram   > I expect to have two lit instructions - one which takes the residual instruction word as the value and another which does nothing with the remaining instruction word and takes the entire following 32-bit cell as the literal value.
2023-08-05 13:28:01 <KipIngram   > On a desktop system it would probably be useful to have similar variants for the call instruction, to allow coverage of the largest amount of address space.