2026-06-11 00:54:30 <xentrac     > I don't like find because it uses counted strings.  counted strings were a mistake except as a storage format for normal strings
2026-06-11 13:02:14 <Stalevar    > Mystery
2026-06-11 13:03:09 <Stalevar    > Why the CPU, even 8080 has rot bitwise operator, like shr but lower bits are put into upper part, but you can't do it from HLL and you have to invent complex expression?
2026-06-11 13:03:41 <Stalevar    > Though Forth probably has it, or you can pull the CPU instruction into word level relatively easily
2026-06-11 13:22:05 <veltas      > Stalevar: In C for example I'd say it's because C wasn't designed as a low-level language, and shifts are sufficient for most logical bitwise tasks for systems programming
2026-06-11 13:23:22 <veltas      > In my own experience I've found rotate is useful for hashing, division, and to speed up certain kinds of shifts on 8-bit CPUs
2026-06-11 13:24:44 <veltas      > e.g. shifting an 8-bit value 6 times left is slower than rotating right twice and AND'ing with C0
2026-06-11 13:25:23 <Stalevar    > veltas, it's strange, that two instructions would be faster than one
2026-06-11 13:25:43 <lofty       > well, it's not one instruction, it's six
2026-06-11 13:25:46 <veltas      > On Z80 shifting left 6 times is 6 instructions
2026-06-11 13:27:05 <veltas      > As for why it's not standardised in Forth (although it's certainly provided by many Forths), I would guess because it's not a portable word because it relies on the cell size and byte size
2026-06-11 13:27:07 <Stalevar    > Ah, I guess I mistook it with x86, where you could do SHR 5 or something?
2026-06-11 13:27:12 <veltas      > That's right
2026-06-11 13:27:27 <veltas      > Although on x86 CPUs sometimes larger immediate shifts take longer
2026-06-11 13:28:27 <veltas      > E.g. I think on older CPUs you'd be able to do up to 3 shifts in one cycle assuming the pipeline didn't stall
2026-06-11 13:29:01 <Stalevar    > ral and rar on 8080 rotate it through carry bit seems
2026-06-11 13:30:41 <veltas      > RLC A copies to carry and also LSB
2026-06-11 13:31:20 <veltas      > I mean RLC?
2026-06-11 13:31:37 <Stalevar    > Wait so you don't have >> << in 8080 at all, only rotates?
2026-06-11 13:32:24 <Stalevar    > Though rotate can be ANDed with a mask to get SHL / SHR
2026-06-11 13:32:39 <Stalevar    > But you can't do the other way
2026-06-11 13:33:37 <lofty       > (I find it interesting to learn about such architectures, even though they're way before my time.)
2026-06-11 13:34:12 <Stalevar    > I was pondering a school test problem #16, namely STDIN: sequence of natural number; STDOUT: amount of numbers which when in HEX have 3 digits and ends with C
2026-06-11 13:34:32 <veltas      > In PowerPC for example there's no shift instruction, only rotates with optional masks
2026-06-11 13:34:39 <Stalevar    > if (!((num & 0xFFFFF00F) ^ 0xC) && (num & 0xF00)) ++count;
2026-06-11 13:34:44 <veltas      > So essentially you can do a shift
2026-06-11 13:35:02 <veltas      > And also I think maybe you can do indexed accesses with the index shifted 0-2 bits maybe
2026-06-11 13:35:48 <lofty       > (I think the least Forth-friendly CPU would probably be the Itanium.)
2026-06-11 13:35:52 <veltas      > I guess also you could clear carry bit before doing a rotate
2026-06-11 13:36:01 <veltas      > You may be right about that lofty
2026-06-11 13:36:39 <veltas      > Clearing carry first is probably faster than and'ing for 1-2(?) shifts
2026-06-11 13:36:46 <veltas      > Maybe just 1 shift
2026-06-11 13:36:52 <veltas      > On Z80 anyway
2026-06-11 13:37:48 <veltas      > Assembly programming is addictive, I can't explain why
2026-06-11 13:38:09 <veltas      > It feels like you're really talking to the CPU, even though that's a total illusion on modern CPUs
2026-06-11 13:39:39 <lofty       > (if not the Itanium, then the Mill. but I don't think we'll ever see a Mill CPU.)
2026-06-11 13:42:20 <lofty       > But yes, I am enjoying writing a Forth as an excuse to learn x86-64 assembly. I'm familiar with MIPS and RISC-V, but I admit I got a bit scared off by the complexity of x86-64.
2026-06-11 13:50:11 <veltas      > Anything you can share yet?
2026-06-11 13:50:50 <veltas      > I wish x86-64 was a bit more approachable, but that's what a succesful product looks like unfortunately, years of backwards compatibility and moat building
2026-06-11 13:52:58 <veltas      > Was same with 32-bit too, much harder than 16-bit.  And protected mode is harder than 8086.
2026-06-11 13:53:14 <veltas      > PAE harder than non-PAE
2026-06-11 13:53:45 <veltas      > And I think that whole stack still needs initialising on the latest processors before you get to 64-bit mode, including e.g. PAE
2026-06-11 14:06:26 <lofty       > <veltas> Anything you can share yet? <-- as in, my source? I can share that :p
2026-06-11 14:06:44 <lofty       > I'm not doing a Forth kernel, if that's what you're thinking :p
2026-06-11 14:10:01 <lofty       > https://forge.lightcrystal.systems/lofty/sixtyforth <-- I suggest cloning it and browsing locally; while my friend is generously hosting the repo on my behalf, I have to say I disagree with her colour theme :p
2026-06-11 14:11:26 <lofty       > But the interpreter doesn't yet work, so right now it's a bunch of Forth words in assembly
2026-06-11 14:14:35 <Stalevar    > veltas, usermode i386 isn't too hard?
2026-06-11 14:14:57 <Stalevar    > Flat model even easier than shuffling segments to access 1M of address space on i8086
2026-06-11 14:15:28 <Stalevar    > Though you can just use .com format and all segment registers being the same
2026-06-11 14:17:33 <KipIngram   > DKordic: Well, I still think Linux is the best we've got, but yeah, I often get annoyed at the restrictions it puts on us in the name of security.  We call these "personal" computers, but the operating systems we can get for them all seem oriented toward multi-user computers in a non-trustworthy environment.
2026-06-11 14:18:31 <KipIngram   > What I'd like is an OS that puts firm security walls between me and the networked world, but lets me - sitting at my own physical keyboard - do ANYTHING WHATSOEVER.  If I shoot myself in the foot that's my problem.
2026-06-11 14:35:27 <veltas      > Thanks lofty I'll check it out afte rwork
2026-06-11 14:39:58 <veltas      > Stalevar: Segment registers are still there in 32-bit but I think usually set to zero
2026-06-11 14:40:52 <Stalevar    > veltas, AFAIR they are used for some fiddling on kernel level
2026-06-11 14:41:26 <Stalevar    > Anyway you don't use them in usermode linux or bsd program
2026-06-11 14:47:13 <veltas      > FS is used to access thread-local storage
2026-06-11 14:48:06 <veltas      > They are used to control access permissions at the kernel level but in practice always with a base address of 0
2026-06-11 15:06:55 <Stalevar    > There are also rings 1 and 2 but they only use 0 and 3 ?
2026-06-11 15:07:41 <Stalevar    > And instead of using those rings they added ring(-1) for SMM and ring(-2) for IntelME / AMD PSP
2026-06-11 15:07:55 <Stalevar    > Though latter isn't quite ring it's separate CPU core
2026-06-11 15:11:11 <veltas      > Not sure 'ring' is official terminology anyway
2026-06-11 16:46:07 <veltas      > FS - Fred's Storage (DON'T TOUCH!!)
2026-06-11 16:46:17 <veltas      > That's how Intel document it anyway
2026-06-11 19:38:03 <lofty       > I have no idea how forth code should be formatted so I am going to do this in a way that seems nice and I'm sure I will be told how to do it properly :p
2026-06-11 20:55:04 <xentrac     > lofty: I've found the F-83 source base to be educational on this point
2026-06-11 20:55:42 <lofty       > https://gist.github.com/Ravenslofty/92c4908a7d6e8eff6a62a71e04a74913 <-- incredibly basic, I know. (yes, I am reinventing "begin-structure"/"end-structure" because I do not have them implemented yet)
2026-06-11 20:56:10 <lofty       > I am using whitespace in lieu of brackets >.>
2026-06-11 21:00:55 <veltas      > That's actually very idiomatic for Forth
2026-06-11 21:01:08 <DKordic     > KipIngram: ""Of what use is a computer that can not modify it's own program!?"" in IIRC ep. 114 ""The LGP-30: A Forgotten Machine"" (https://adventofcomputing.com/).  The real scientist behind the Story of Mel.
2026-06-11 21:01:12 <DKordic     > ""The Problem With Open Hardware"" (youtu.be/YLn4vnfchaE?si=w2giWDmm3Hxi1W_5&t=322)
2026-06-11 21:31:45 <veltas      > lofty: Your kernel's looking good
2026-06-11 21:31:52 <veltas      > Not a fan of named registers though, personally
2026-06-11 21:32:11 <veltas      > Like `TOS = rbx` etc
2026-06-11 21:32:38 <lofty       > I can understand that point of view, but I feel I would lose track of the "internal ABI" purpose of each register without it.
2026-06-11 21:33:14 <veltas      > I think that's an imagined fear but I'm not you
2026-06-11 21:33:26 <lofty       > it's not an imagined fear :p
2026-06-11 21:34:00 <veltas      > My fear would be using rbx and TOS in one word and forgetting they're one reg
2026-06-11 21:34:32 <lofty       > if I was a sufficiently confident assembly programmer I likely would not be using forth for the logic ^^;;
2026-06-11 21:35:05 <veltas      > Did you read Brad Rodriguez's Moving Forth articles?
2026-06-11 21:35:26 <lofty       > I did, yes. you can see the register names are taken almost directly from it
2026-06-11 21:36:22 <veltas      > Yeah I thought so
2026-06-11 21:39:36 <veltas      > Is any of this running yet?
2026-06-11 21:41:38 <lofty       > so, there's "kernel.s" and "interpreter.s"; "kernel.s" can run code when it gets tokenised and included, but honestly the development experience of that is hell, which is why "interpreter.s" is not a static ELF but instead a dynamic ELF that can be linked and includes symbols
2026-06-11 21:42:05 <lofty       > "kernel.s" will get rewritten once "interpreter.s" can run code
2026-06-11 21:43:27 <lofty       > using a tokeniser to compile code and bundle it inside a kernel with no dictionary is not "the forth way", however size constraints mean I have to forgo programmability :p
2026-06-11 21:44:57 <lofty       > I am very much looking forward to getting this running :p
2026-06-11 21:45:17 <veltas      > Yeah Forth is compact but the interpreter isn't exactly useful to many apps
2026-06-11 21:45:42 <veltas      > Although we do use the interpreter and abuse it and write DSL-style stuff but I'm guessing that's not relevant to what you're going to make
2026-06-11 21:46:43 <lofty       > I have considered doing a slightly-cursed thing of naming the protocol handler QUIT so that the kernel jumps to whatever relevant interface payload it needs to
2026-06-11 21:47:25 <lofty       > the Universal Chess Interface is not very amicable to the Forth way of doing things :p
2026-06-11 21:52:47 <veltas      > I think that's quite normal too
2026-06-11 21:53:18 <veltas      > It's not cursed, I think you just keep figuring out Forth and assuming it's wrong because it's too hacky
2026-06-11 21:54:07 <veltas      > Forth is the art of pointless hackiness
2026-06-11 21:54:55 <veltas      > Likewise it being non-standard is actually quite standard, most Forths aren't standard and have hacks to accomodate the author's purposes
2026-06-11 21:55:39 <veltas      > Hi f87
2026-06-11 21:57:06 <lofty       > hi f87 :p
2026-06-11 22:01:59 <f87         > hi!
2026-06-11 22:29:04 <f87         > what's the forth 2012 way to shove something a string and get back a cell-sized number?
2026-06-11 22:29:25 <f87         > >number seems to work on double-cell integers i think?
2026-06-11 22:32:27 <f87         > i guess i'm more used to implementing NUMBER as ( c-addr u -- u )
2026-06-11 22:36:42 <lofty       > I mean, you can ">number 2drop drop"? /j
2026-06-11 22:37:49 <lofty       > or I guess it's ~technically~ more accurate to do ">number 2drop d>s" because forth 2012 does not guarantee two's complement
2026-06-11 22:44:46 <veltas      > The latest draft guarantees two's complement
2026-06-11 22:44:57 <veltas      > And D>S can cause ambiguous behaviour if it's out of range
2026-06-11 22:45:01 <veltas      > So DROP is probably safer
2026-06-11 22:46:27 <veltas      > f87:  : NUMBER ( c-addr u -- u )  0. 2SWAP >NUMBER 2DROP DROP ;
2026-06-11 22:46:42 <veltas      > Stole it from lofty, don't tell them
2026-06-11 22:46:55 <lofty       > (hey, you got my pronouns right)
2026-06-11 22:47:09 <veltas      > Sorry
2026-06-11 22:47:20 <lofty       > I mean that sincerely
2026-06-11 22:47:29 <lofty       > I am too used to being "him"'d >.>
2026-06-11 22:50:55 <f87         > haha, i guess you indirectly answered my question with "there isn't a forth 2012 word for it" :p
2026-06-11 22:51:03 <f87         > and i'm too lazy to implement >NUMBER
2026-06-11 22:51:12 <lofty       > time for ">snumber" I guess
2026-06-11 22:51:20 <veltas      > Are you writing a Forth then?
2026-06-11 22:51:31 <f87         > yes!
2026-06-11 22:51:34 <lofty       > did you notice the commits on my repo were by an "87"?
2026-06-11 22:52:54 <lofty       > we're working on this together; I mentioned the channel and presumably f87 decided to join :p
2026-06-11 22:52:59 <veltas      > Oh
2026-06-11 22:53:21 <veltas      > I thought "87" on commits was some kind of git configuration issue
2026-06-11 22:53:44 <veltas      > Could use reference implementation https://forth-standard.org/standard/core/toNUMBER?hideDiff#reply-1499
2026-06-11 22:54:17 <lofty       > there's a lot going on in the reference implementation for bootstrapping purposes, I think
2026-06-11 22:54:30 <veltas      > The standard uses double numbers a lot because classic Forths needed them, so the standard is probably not that relevant to people who hate redundant difficult code
2026-06-11 22:55:06 <veltas      > It made more sense for my ZX Spectrum Forth because there a double number is 32-bit, which is a good size for most serious calculations
2026-06-11 22:55:16 <f87         > that makes sense
2026-06-11 22:55:31 <veltas      > Rather than on modern systems where it's 128-bit which is really pointless
2026-06-11 22:56:01 <veltas      > It wouldn't be crazy to just replace all double numbers with single numbers for your Forth
2026-06-11 23:36:24 <xentrac     > unless you're implementing the Ethereum VM :-)
2026-06-11 23:50:20 <veltas      > Why does leaving a tab with google open burn my lap now?
2026-06-11 23:50:25 <veltas      > Is this a world cup thing?
2026-06-11 23:53:27 <xentrac     > maybe the JS profiler can tell you