2023-12-01 00:01:09 <PoppaVic    > KipIngram, review the gforth stack-frame words.
2023-12-01 00:02:06 <KipIngram   > What are they called?
2023-12-01 00:02:50 <PoppaVic    > stack frame words ;-)
2023-12-01 00:03:15 <KipIngram   > The main reason I introduced the first sort of stack frame was to allow me to index into the stack in a nicely controlled way.  But it wound up having a fringe benefit even if I don't need to do that - it guarantees getting the stack clean, even if I have multiple paths that leave differeing amounts of stuff on the stack.
2023-12-01 00:04:02 <KipIngram   > I don't get any easy response when I Google gforth stack frame words.
2023-12-01 00:04:21 <KipIngram   > The second type was to let me "leap out" of a deep nesting of calls.
2023-12-01 00:05:15 <KipIngram   > Like in FIND - I'm way down in a triply nested loop when I achieve 'success' and find the word I'm looking for.  {| and |} give me a way to jump all the way back out in one go, which makes it so those words in the middle don't have to know how to deal with "success."
2023-12-01 00:05:39 <KipIngram   > They're just written as though the search will fail every time.
2023-12-01 00:06:07 <PoppaVic    > KipIngram, https://dl.acm.org/doi/pdf/10.1145/378911.378917 best link so far
2023-12-01 00:06:26 <KipIngram   > Thanks.
2023-12-01 00:07:07 <PoppaVic    > https://dl.forth.com:8443/jfar/vol3/no1/article3.pdf
2023-12-01 00:07:20 <KipIngram   > That looks slightly similar to mine, except I save the old frame pointer on the return stack rather than the data stack.
2023-12-01 00:08:03 <KipIngram   > I guess some things there are only so many ways to do.
2023-12-01 00:08:29 <PoppaVic    > yeah, yer working in one or another space - even if you allocate a THRID space (like float)
2023-12-01 00:08:37 <PoppaVic    > third, two
2023-12-01 00:08:50 <KipIngram   > I originally tried to do without a frame pointer and just index off of the stack pointer, but that gets confusing because it's constantly changing, which makes the index of the various items change too.
2023-12-01 00:09:18 <KipIngram   > Much easier to keep up with what's going on if you have a fixed reference frame.
2023-12-01 00:09:22 <PoppaVic    > I am fine with forth swap-shit 75% or more of the time, but the stackframe stuff is sometimes about the ONLY path to sanity
2023-12-01 00:10:20 <KipIngram   > My worst situation was QUERY.  EXPECT already had several items on the stack that I needed to get at more or less at the same time, and QUERY made it worse by adding in a command history list to keep up with too.
2023-12-01 00:10:31 <PoppaVic    > (and yeah, I dislike dribbling variables around when a frame makes more sense)
2023-12-01 00:10:40 <PoppaVic    > hah! yeah
2023-12-01 00:10:46 <KipIngram   > At some points in there there were six things to juggle around, and the normal noodling words just don't know what to do with that.
2023-12-01 00:11:05 <PoppaVic    > right, that's when ARG1 ARG2... make sense
2023-12-01 00:11:45 <KipIngram   > We had a talk here one day about turning the whole system inside out, with a GUI style event loop, and that would altogether change how the text input of the system worked - it did seem like that would clean things up quite a lot.
2023-12-01 00:11:50 <PoppaVic    > KipIngram, I suspect the best approach, btw, is a small stackframe voc, too. Keeps it the hell out of the way, otherwise
2023-12-01 00:11:59 <KipIngram   > Because in the context of a GUI, text fields on screen need to have some global state associated with them.
2023-12-01 00:12:07 <KipIngram   > So the amount of stuff to keep on stack was reduced.
2023-12-01 00:12:16 <KipIngram   > But I haven't actually done a system that way yet.
2023-12-01 00:12:37 <PoppaVic    > sounds moot: what happens when you "redirect" source or sink?
2023-12-01 00:12:58 <KipIngram   > Don't know - haven't done that yet either.  But it's part of what I want in this next one.
2023-12-01 00:13:05 <PoppaVic    > ok
2023-12-01 00:13:29 <PoppaVic    > well, then yer in need of handles/streams for i/o. - rather than raw bit/byte
2023-12-01 00:13:43 <KipIngram   > Yes - streams/devices.
2023-12-01 00:13:54 <KipIngram   > stdin/stdout/stderr.
2023-12-01 00:14:37 <KipIngram   > "The system" will just process stdin to stdout, but that might wind up coming from / going to all kinds of places.
2023-12-01 00:14:45 <PoppaVic    > Mind you, C (and nix) always pissed me off: certain things you NEED to do are only available on the handle/FILE* you ain't using.
2023-12-01 00:15:24 <PoppaVic    > I never really accepoted that idiocy: since the underlying code HAD to be the same
2023-12-01 00:16:18 <PoppaVic    > (and then there are the linux raw syscalls that "are not portable" - and remain necessary.
2023-12-01 00:16:31 <KipIngram   > We were just talking about that (the "everything is a file" thing in Linux) earlier today.
2023-12-01 00:17:07 <KipIngram   > Yeah, try porting syscalls between MacOS and Linux.  That's kind of a nightmare.
2023-12-01 00:17:40 <KipIngram   > Especially if you're not using C, because you need those magic numbers in the C .h files.
2023-12-01 00:29:54 <PoppaVic    > I always felt that the integer ID (handle) was great for portability, but then they hid shit inside and in-support-of FILE* - and it just pissed me off.. Almost nothing user-side needs to see inside a FILE struct, so just write the goddamned operators and be done, sheesh
2023-12-01 00:30:39 <PoppaVic    > ..andother linux syscall/irritation was the "char ready" or "bytes available" shit.
2023-12-01 00:31:21 <KipIngram   > Yeah, I think seek, read, write mostly covers your bases.
2023-12-01 00:38:03 <KipIngram   > Well, and open/close.
2023-12-01 00:46:08 <PoppaVic    > KipIngram, you need MORE - check those syscalls for the ready/available stuff, for the crap we need to convert handle to FILE* and FILE* to handle to do.. It's just damned silly.
2023-12-01 01:00:02 <KipIngram   > Well, one thing I want is to be able to start a disk operation in a non-blocking way, and then have a follow-on call I make later that will block if the data still isn't ready.  That way I at least have a chance to do other work while the disk is cranking.
2023-12-01 03:44:02 <PoppaVic    > Man, don't y'all ever shut up?
2023-12-01 03:56:14 <zelgomer    > no
2023-12-01 04:08:11 <PoppaVic    > oh, wow - something other than join/leave was listed.. opps. Missed it.
2023-12-01 04:11:49 <MrMobius    > PoppaVic: feel free to monologue
2023-12-01 04:11:59 <MrMobius    > someone may comment after they wake up
2023-12-01 04:12:54 <PoppaVic    > Nah.. That's as bad as Standup.. hell, next someone will do the Vagina Moaninglog and then everyone will head-explode ala' Kingsmen
2023-12-01 04:13:25 <PoppaVic    > ..Back to back to Falling Skies
2023-12-01 04:55:53 <KipIngram   > Kingsman was good.
2023-12-01 04:56:14 <KipIngram   > I went in not expecting too much and was pleasantly surprised.
2023-12-01 04:56:29 <KipIngram   > Manners.  Maketh.  The man.  :-)
2023-12-01 04:59:09 <PoppaVic    > yup.. and 'splodin' heads ;-P
2023-12-01 04:59:55 <PoppaVic    > ..in fruity-rainbow colors ;-)
2023-12-01 05:03:44 <zelgomer    > f redcoats
2023-12-01 13:35:40 <veltas      > I'm quite happy using FILE*
2023-12-01 13:36:22 <veltas      > I wish they added a type for file handles in C to make them a bit more type-safe, like HANDLE* or something, doesn't need to actually point at anything would just improve type safety
2023-12-01 13:37:23 <veltas      > There was a convention at one point in C for opaque structs to be typedef'd as an ALLCAPS name, hence FILE, the point of FILE is you can't see in the struct and it might not even be a struct at all, it's just a handle in a sense itself
2023-12-01 13:37:33 <veltas      > I quite like this method of encapsulation in C and use it often
2023-12-01 13:38:05 <veltas      > Makes ABI's more stable too
2023-12-01 13:38:48 <veltas      > I'm not 100% sure what PoppaVic was trying to say about this but just opining
2023-12-01 13:40:32 <veltas      > I wish the standard exposed the virtualisation features of FILE that are present in many standard libraries. Most standard libraries allow giving custom callbacks for read/write/seek and this is how they e.g. implement snprintf()
2023-12-01 13:41:41 <veltas      > Instead to achieve this portably you need to add another level of abstraction on top yourself
2023-12-01 14:35:00 <KipIngram   > Oh, I hadn't realized that all-caps in a type implied "opaque."  That's interesting to know.
2023-12-01 14:36:51 <KipIngram   > Yeah, I like that callback idea.  That's the kind of thing I was trying to get above re: BLOCK; instead of returning an address, maybe it returns an XT and then you later call that to get the address.  That one might block or might not - depending on whether the data's resident yet or not.
2023-12-01 14:37:19 <KipIngram   > In that case, though, there's an overt block number, so it could also be implemented as just a pair of words.
2023-12-01 14:37:32 <KipIngram   > You'd give the block # to both of them.
2023-12-01 15:00:27 <veltas      > KipIngram: The all-caps for opaque thing is very old now, most people don't do that anymore. You still see it in some places.
2023-12-01 15:02:57 <veltas      > I complained to microsoft that they had listed tmpfile() as 'unsafe' and deprecated it, even though there's nothing unsafe about it in principle and it's a C standard library function.
2023-12-01 15:03:07 <veltas      > They're saying you should use s_tmpfile() instead in their docs
2023-12-01 15:03:29 <veltas      > But s_tmpfile() isn't more safe in its interface, it's just *consistent* with the safer IO functions appendix
2023-12-01 15:04:01 <veltas      > And by saying tmpfile() is unsafe and deprecated they're just creating unnecessary work for people
2023-12-01 15:04:05 <veltas      > But no dice
2023-12-01 15:04:55 <veltas      > The implementation MS have is actually not very good, but that's a defect in their implementation. The solution is to improve the implementation, not mark a standard library function as unsafe
2023-12-01 15:05:19 <veltas      > It's hard enough writing portable C code already, don't need MS deprecating standard functions that aren't deprecated in the standard
2023-12-01 15:07:53 <veltas      > A loooong time ago MS apparently exposed which file was created by tmpfile(), and it's always in C:\ so has permissions problems, and has a relatively short set of possible names and suffers from ocassional collisions which it just reports as an error.
2023-12-01 15:08:08 <veltas      > And this is now probably necessary for backwards compaibility on some sad programs
2023-12-01 15:08:20 <veltas      > But I say just fix it in the new redist...
2023-12-01 15:08:50 <veltas      > And people think Forth is hard!
2023-12-01 15:44:01 <hello-operator> KipIngram: just noticed that the 16 instructions you mentioned yesterday didn't include any comparision operators, how are you planning on implementing them?
2023-12-01 15:51:32 <KipIngram   > Conditional return and conditional recursion words.
2023-12-01 15:51:58 <KipIngram   > In my current system I have a massive matrix of them; I generated the assembly source for those with a python script.
2023-12-01 15:52:34 <KipIngram   > All six comparison cases, < <= = != >= >, then with and without default 0 argument, and also where appropriate signed and unsigned cases.
2023-12-01 15:52:55 <KipIngram   > And finally I have versions of all of them that consume all arguments, and versions that will leave the deepest argument present for re-use.
2023-12-01 15:53:05 <KipIngram   > That winds up being over a hundred primitives.  :-|
2023-12-01 15:53:33 <KipIngram   > I have an easy to remember convention for their names, so no real "memorization" was required to use them.
2023-12-01 15:54:50 <KipIngram   > In addition to building those around "return" and "recurse," i can also do "double return," which discards a return address from the return stack before conditionally returning.
2023-12-01 15:55:07 <KipIngram   > So yeah - I have those bases well and truly covered.
2023-12-01 15:55:33 <KipIngram   > I do everything that way - I don't even have IF THEN, BEGIN AGAIN, DO LOOP, etc.
2023-12-01 15:56:36 <KipIngram   > I won't have instruction space for so many in this new system, so I'll have to give thought to exactly how I want to bundle things.
2023-12-01 15:56:57 <KipIngram   > Or, rather, which ones to make primitive instructions and which ones to implement as higher level words.
2023-12-01 16:02:03 <KipIngram   > Just as an example, you might see .u<=;; which would do an unsigned <= comparison of the top two items and if satisfied do a double return.  because of the . prefix it would drop only the top argument and would keep the second one.
2023-12-01 16:02:22 <KipIngram   > That . prefix isn't a "compiler" thing; it's not supported algorithmically.  It's purely a naming convention.
2023-12-01 16:03:30 <KipIngram   > I use a fair variety of them - at some point I should probably scan all the source I've written and identify which ones I hardly ever use.
2023-12-01 16:03:38 <veltas      > : +< ( n1+ n2+ -- n1<n2? )   -  [ -1 1 RSHIFT ] LITERAL  AND 0<> ;   \ compare two positive numbers
2023-12-01 16:03:50 <KipIngram   > The most commonly used one, I think, is 0=; or 0!=;
2023-12-01 16:03:54 <veltas      > This word is part of how I would compare numbers without comparison operators if I had to do that
2023-12-01 16:04:24 <KipIngram   > That's nifty.
2023-12-01 16:04:30 <veltas      > The next step is compare top bit of two numbers, and then if they're equal compare the lower bits with that
2023-12-01 16:04:53 <veltas      > I leave the definition of U< and < to reader as an exercise
2023-12-01 16:05:33 <KipIngram   > :-)
2023-12-01 16:06:00 <veltas      > Oh look it's time for my first advent of code
2023-12-01 16:06:09 <KipIngram   > I am going to need to give thought to EXACTLY what to do this next go round.  I can't have the luxurious "all primitive" approach I took before.
2023-12-01 16:06:30 <veltas      > That's up to you
2023-12-01 16:14:45 <veltas      > Lovely, another boring parsing exercise to trip up the forthers on day 1
2023-12-01 16:17:32 <KipIngram   > Well, all I meant is that this time I can't have an arbitrary number of lowest level operations.  I guess i'll still have "primitives" written directly in vm instructions, and can have as many of those as I like.  But the vm instruction set itself will be "limited."
2023-12-01 16:18:16 <KipIngram   > In a code threaded system, though, there's a bit less distinction between "primitive" and "definition."  A primitive is just a word that makes no calls.
2023-12-01 16:18:41 <KipIngram   > And a definition one that only makes calls.  In code threading we can get anywhere in between too, so it's a spectrum now.
2023-12-01 16:20:32 <thrig       > zx spectrum is back, baby!
2023-12-01 16:21:11 <KipIngram   > Oh, it's up for sale again?
2023-12-01 16:21:37 <KipIngram   > The main computer from the past I'm a little sorry I missed out on was the Amiga.
2023-12-01 16:21:58 <thrig       > well you said it was a spectrum...
2023-12-01 16:22:06 <KipIngram   > OH.
2023-12-01 16:22:14 <KipIngram   > Ha - I didn't catch on those were related.
2023-12-01 16:22:17 <KipIngram   > Gotcha.
2023-12-01 16:33:01 <veltas      > Parsing thing is re advent of code
2023-12-01 16:36:30 <hello-operator> Ah that makes sense, is there any reason for doing it that way though?
2023-12-01 16:37:47 <PoppaVic    > YEah, the Amiga was really supposed to be a radical improvement.. That disappeared.
2023-12-01 16:45:23 <veltas      > hello-operator: What's that regarding?
2023-12-01 16:56:22 <hello-operator> In regards to the conditional returns replacing the normal primitives
2023-12-01 16:57:51 <veltas      > KipIngram: ^
2023-12-01 16:58:25 <hello-operator> Yeah, my bad, should've prefixed my comment :/
2023-12-01 16:58:47 <veltas      > No harm done
2023-12-01 17:04:02 <KipIngram   > hello-operator: Well, it is just "a way" of doing it - I've kept it because I like it.  I'm convinced that it's caused me to writer shorter, easier (for me at least) to understand definitions.
2023-12-01 17:04:35 <KipIngram   > It's easier for me to look back at old code and recover what's going on, etc.  That could be entirely a personal ideosyncracy of mine, though.
2023-12-01 17:04:46 <KipIngram   > I just like it a whole lot better.
2023-12-01 17:05:26 <KipIngram   > I could make some performance arguments.  By combining the comaprison and the control transfer into a single primitive, I get the job done with less work, etc.
2023-12-01 17:05:55 <KipIngram   > But those are fairly minor performance advantages.
2023-12-01 17:09:20 <KipIngram   > That's certainly the case with the recursion words.  With the conditional return words, I may be gaining in the way I just noted but I'm also swallowing the overhead of an extra call/return, so it may go either way.
2023-12-01 17:09:56 <KipIngram   > For example, instead of : foo  ... IF <CODE> THEN ... ; I'd have something like
2023-12-01 17:10:12 <KipIngram   > : bar  0=; <CODE> ;
2023-12-01 17:10:19 <KipIngram   > : foo ... bar ... ;
2023-12-01 17:11:02 <KipIngram   > But you see how short that made my definitions.
2023-12-01 17:11:34 <KipIngram   > I always claim that it "encourages more factoring."
2023-12-01 17:11:47 <KipIngram   > which is supposedly good.
2023-12-01 17:17:06 <hello-operator> "Because I want to" is always a good reason!
2023-12-01 17:19:25 <KipIngram   > I also like it that the conditional return instructions involve no "offset" in the code.  In fact, next go round I'm planning steps to make the conditional recursion words also not use offsets.
2023-12-01 17:19:43 <veltas      > It's an interesting approach, no doubt
2023-12-01 17:21:36 <hello-operator> That does make sense, I sometimes wish for different ways of handling conditionals. Isn't that similar in ways to what colorForth did/does?
2023-12-01 17:21:56 <hello-operator> Or at least not using IF...THEN
2023-12-01 17:22:05 <hello-operator> To each their own I guess
2023-12-01 17:23:29 <KipIngram   > I don't know that colorforth had conditional returns.
2023-12-01 17:24:02 <KipIngram   > I'm not terribly familiar with it, though.  Not at all to say that I "invented' the idea, but I did think of it without seeing it described anywhere, and I'd read through most of Chuck's stuff.
2023-12-01 17:24:22 <veltas      > Supposedly advent of code day 1 part 2 is hard, so that will be fun getting filtered on day 1, I've not seen it yet
2023-12-01 17:24:44 <veltas      > Although based on comments I wonder if it isn't actually that hard if you're not trying to use regex
2023-12-01 17:24:53 <KipIngram   > I may have read something about him not using THEN, but that memory is very vague.
2023-12-01 17:25:05 <veltas      > Sounds like regex has been shooting people in the foot as it classicly does
2023-12-01 17:25:25 <veltas      > Jokes on them because forth doesn't have regex
2023-12-01 17:25:30 <KipIngram   > Regex is such a broad thing.
2023-12-01 17:26:01 <KipIngram   > In its earliest incarnation it was quite efficient, but then they started adding things to it that opened the door to pathological cases with terrible performance.
2023-12-01 17:26:21 <KipIngram   > There's a very good paper about all that...
2023-12-01 17:26:35 <GeDaMo      > https://swtch.com/~rsc/regexp/regexp1.html
2023-12-01 17:26:55 <GeDaMo      > "Regular Expression Matching Can Be Simple And Fast (but is slow in Java, Perl, PHP, Python, Ruby, ...)"
2023-12-01 17:27:27 <KipIngram   > https://swtch.com/~rsc/regexp/regexp1.html
2023-12-01 17:27:36 <GeDaMo      > I'm sure I saw something about conditional returns and conditional calls a long time ago
2023-12-01 17:27:40 <KipIngram   > Oh, you beat me.
2023-12-01 17:27:42 <KipIngram   > :-)
2023-12-01 17:27:55 <KipIngram   > i wouldn't doubt it for a second.
2023-12-01 17:28:03 <veltas      > The shooting in foot is partly just when the problem stops being a regular language, or easy to express as a classic regex
2023-12-01 17:28:13 <KipIngram   > I thought about conditional calls too, but decided the returns were enough.
2023-12-01 17:31:42 <GeDaMo      > https://www.researchgate.net/publication/220828932_A_parsing_machine_for_PEGs
2023-12-01 17:34:59 <veltas      > Classic regex's converted to DFA's are faster than packrat in practice I would guess
2023-12-01 17:35:03 <thrig       > "Enable JavaScript and cookies to continue"
2023-12-01 17:35:18 <veltas      > I wonder if there's any stats on that
2023-12-01 17:35:34 <GeDaMo      > Apparently the 8085 processor had conditional call and return
2023-12-01 17:35:59 <veltas      > Z80 too I think(?)
2023-12-01 17:36:33 <KipIngram   > http://z80-heaven.wikidot.com/instructions-set:call
2023-12-01 17:37:00 <KipIngram   > That's a nice feature.
2023-12-01 17:37:23 <veltas      > Not nice enough to poach for x86
2023-12-01 17:38:13 <Zarutian_iPad> what about IBM 390 condition code system?
2023-12-01 17:39:10 <Zarutian_iPad> there is a four way branch instruction that takes the four next cells as the branch destinations
2023-12-01 17:39:16 <KipIngram   > I'm just not familiar with most of the old IBM systems.  I looked into them some, but that was back around college time.
2023-12-01 17:39:53 <KipIngram   > That sounds pretty powerful.
2023-12-01 17:40:38 <KipIngram   > That's something that would integrate nicely with my planned "near" call feature, where a near call can be a normal instruction-sized field.
2023-12-01 17:40:43 <veltas      > I'd guess the old mainframes are probably more elegant than the micros
2023-12-01 17:41:27 <thrig       > they had a somewhat larger budget for more transitors or whatnot
2023-12-01 17:42:13 <KipIngram   > CASE  <option> <option> <option> <option>
2023-12-01 17:42:28 <KipIngram   > And yet they had FAR fewer transistors than modern micros.
2023-12-01 17:42:41 <KipIngram   > If a mainframe could do it then, a micro could do it now.
2023-12-01 17:44:19 <veltas      > I wonder if the mainframe FORTRAN 1 was written for is reflected in old FORTRAN code
2023-12-01 17:45:14 <veltas      > I mean the old FORTRAN syntax
2023-12-01 17:45:57 <veltas      > Like how the conditional statement worked with three line numbers for negative/zero/positive or whatever it was
2023-12-01 17:50:07 <GeDaMo      > No reason you couldn't do that in Forth, just use xts instead of line numbers
2023-12-01 17:54:59 <KipIngram   > Sure.
2023-12-01 17:55:27 <KipIngram   > These "near" calls are deliberately designed to look like instructions, so I could do it with "opcodes."
2023-12-01 17:56:12 <KipIngram   > I tend to write a lot of short definitions, so my "main" word is very likely to be calling stuff relatively nearby.
2023-12-01 17:56:30 <KipIngram   > The hope here is that the facility will have enough range to capture "most" of that.
2023-12-01 17:57:18 <KipIngram   > And if not I have a relatively standard call instruction too, that expects an offset to follow it.
2023-12-01 17:57:25 <KipIngram   > That one will be able to reach anywhere.
2023-12-01 18:00:42 <veltas      > I'm convinced DFA regex algorithms are faster and use less memory than packrat PEG parsing
2023-12-01 18:00:59 <veltas      > DFA regex is totally linear, every character advances the state machine, it never goes backwards
2023-12-01 18:01:44 <veltas      > packrat PEG parsing has to go back sometimes, it's just limited to some linear factor of the input because of dynamic programming
2023-12-01 18:02:04 <KipIngram   > Right.  That's the sort of thing that link GeDaMo and I gave above discusses.
2023-12-01 18:03:11 <veltas      > But the memoization in that ideal case means the memory requirements for packrat are linear against input size, so can't parse massive files either without losing that linear time guarantee or running out of RAM
2023-12-01 18:03:35 <veltas      > The memory requirements of DFA regex is limited based on the regex itself, the input size doesn't impact it
2023-12-01 18:04:42 <veltas      > KipIngram: I don't know if you're familiar with PEG's, they're not regex's
2023-12-01 18:05:24 <veltas      > They're a greedy simplification of regex's which work well for some things, and have smaller implementation sizes than regex libraries
2023-12-01 18:06:49 <veltas      > This is what bothers me about automatic memoisation, it's hard to demonstrate that in all cases you don't start garbage collecting, and then all the magic escapes from the bag
2023-12-01 18:13:36 <KipIngram   > Yeah, that does seem to be a potential issue that  you'd have to be on guard for.
2023-12-01 18:13:47 <KipIngram   > Since memoization has a resource requirement.
2023-12-01 18:14:43 <KipIngram   > So I had a chat yesterday with PoppaVic, and I think that instead of using the last 16 bytes of each disk block as "administrative data" I may gather all the adminstrative data for each 256-block cluster of blocks into a single block.
2023-12-01 18:14:51 <KipIngram   > Then the data blocks will be pure data.
2023-12-01 18:15:01 <veltas      > I seem to remember recommending the same approach
2023-12-01 18:15:12 <KipIngram   > But I'll still know precisely where the admin data is for a block.
2023-12-01 18:15:13 <veltas      > And this is how filesystems work in practice too I think
2023-12-01 18:15:28 <KipIngram   > Oh, did you?  I'm sorry - I failed to see that.  Well, thank you - I think it's an improvement.
2023-12-01 18:15:36 <veltas      > A while ago
2023-12-01 18:15:39 <veltas      > Not recently
2023-12-01 18:16:02 <KipIngram   > I must not have really registered it, though, because I think if I did I'd have seized on the idea at that time.
2023-12-01 18:32:44 <veltas      > I now see part 2 of day 1 AoC23 and I don't really understand why this is hard with regex, I think maybe people just don't know regex
2023-12-01 18:33:02 <veltas      > It seems 'harder' than usual but still essentially trivial, just more work than usual for day 1
2023-12-01 18:33:48 <veltas      > Maybe people are scratching heads trying to come up with 'neatest' solutions only or something?
2023-12-01 18:41:16 <veltas      > Oh I think I see what the issue is maybe(?)
2023-12-01 18:42:04 <veltas      > That whole thing about "I'll use regex's" "now I have two problems" is true in my opinion, regardless of the bad performance of some implementations
2023-12-01 18:53:00 <KipIngram   > One thing it's easy for me to have slip my mind is the need for vm instructions for accessing "system registers."  Things like sp@ sp! / rp@ rp!; in my case I also have my frame pointer, my "longjmp" pointer, etc.
2023-12-01 18:53:43 <KipIngram   > What I'm leaning toward is a single pair of instructions, maybe sys@ / sys! that take either a stack parameter or a follow-on instruction slot to tell them which register I'm interested in.
2023-12-01 18:54:11 <KipIngram   > Oh, also the task register, the register pointing to the vm jump table, etc.
2023-12-01 18:54:15 <veltas      > Token forth is better than VM forth IMO
2023-12-01 18:54:16 <Zarutian_iPad> or you could have those registers memory mapped?
2023-12-01 18:54:31 <KipIngram   > Sure, I could, but that would be much less performant.
2023-12-01 18:54:38 <veltas      > No (?)
2023-12-01 18:54:45 <KipIngram   > veltas: not sure what you would mean by the difference in those?
2023-12-01 18:54:52 <KipIngram   > I may be using terminology incorrectly.
2023-12-01 18:55:01 <veltas      > In a token forth you can run native code, in a vm forth you're limited to what VM provides
2023-12-01 18:55:11 <KipIngram   > I see this as a vm that is implemented in a token-threading sort of way.
2023-12-01 18:55:33 <KipIngram   > I.e., the instructions are tokens.
2023-12-01 18:55:41 <veltas      > With a token forth you'd just add words for accessing those registers, no need to worry about lack of a VM 'instruction'
2023-12-01 18:55:49 <veltas      > They just wouldn't be a token
2023-12-01 18:56:28 <KipIngram   > Well, sure, but one of my goals here is to have a clear division between the vm and the system - I want "the system" to be fully implemented in vm instructions.
2023-12-01 18:56:36 <KipIngram   > So anything I do there has to be "vm support" for.
2023-12-01 18:56:56 <KipIngram   > Yes, I could write a processor instruction primitive to do those things, but I'd be "cheating" to some extent.
2023-12-01 18:57:08 <KipIngram   > I see benefits either way.
2023-12-01 18:57:21 <KipIngram   > And you may be right.
2023-12-01 18:57:53 <veltas      > Even a broken clock is right twice a day
2023-12-01 18:58:14 <KipIngram   > :-)
2023-12-01 18:58:39 <veltas      > A VM using its own instructions is really more of a STC threaded forth that happens to look a bit like a tokenised forth
2023-12-01 18:59:01 <KipIngram   > The benefit of making vm instructions availaable for that is that I'm then more pure in my system implementation (pure vm, that is).  The down side is that they consume instruction set space and too much of that makes the instructions larger.
2023-12-01 18:59:30 <KipIngram   > Yeah - the "system level" of this will very much be a code-threaded Forth.
2023-12-01 18:59:49 <KipIngram   > Making it the first one of those I've ever written.
2023-12-01 18:59:55 <Zarutian_iPad> I mentioned instruction set mode being part of the program status word the other day
2023-12-01 19:00:15 <KipIngram   > Yes, you did - I'm more likely to capture that by being able to change the pointer designating the jump table.
2023-12-01 19:00:33 <KipIngram   > Though your idea of having a mode bit that would get restored on subroutine return - I do like that.
2023-12-01 19:01:00 <KipIngram   > I like the idea that it could easily change back and forth across call levels.
2023-12-01 19:02:00 <KipIngram   > So I'm still rolling all of those possibilities around in my head.
2023-12-01 19:02:16 <veltas      > To memory map the registers in a VM forth you might have a couple 'hot' registers that are using real registers and dump those / restore those to their mapped locations every time you run a store/fetch instruction unconditionally
2023-12-01 19:02:23 <veltas      > That might be faster than having them in RAM always
2023-12-01 19:02:40 <veltas      > Or having a conditional on the store/fetch based on address to branch for registers
2023-12-01 19:03:41 <KipIngram   > The other thing I'm still undecided on is exactly how to approach cell/half/word/byte addressing.  There are like eight memory access words in the F18A isntruction set - if I multiply that by access size variants that gets to be a lot of instructions.
2023-12-01 19:04:12 <KipIngram   > Chuck just didn't bother with sub-cell access; he left it to the programmer to mask and shift and so on as needed.
2023-12-01 19:04:41 <KipIngram   > But that simplified his HARDWARE too - I really hate to have the processor able to do those accesses and not support it somehow.
2023-12-01 19:05:44 <veltas      > I think you should seriously consider a token forth
2023-12-01 19:05:44 <KipIngram   > At the moment, I've "mostly" decided to go from 6 bit instructions to 7 to support this near jump/call stuff.  If I'm not careful all of the above considerations will have me thinking about going from 7 to 8.
2023-12-01 19:05:58 <veltas      > It probably does everything you want and is just easier to write etc, you're constraining yourself with the VM idea
2023-12-01 19:06:01 <KipIngram   > which may wind up being the right move, but I don't want to take that step lightly.
2023-12-01 19:06:14 <veltas      > Yeah it's a big deal
2023-12-01 19:06:57 <KipIngram   > With 7 bits, then the "leftover" after four full slots is four bits - that's 16 instructions that could live in that last slot.  I think I'd find that I was fairly often able to use that slot.
2023-12-01 19:07:12 <KipIngram   > So I won't "always" get five instructions per cell, but I often might.
2023-12-01 19:07:30 <KipIngram   > A 15-20 percent code density increase is nothing to just thoughtlessly give away.
2023-12-01 19:08:29 <KipIngram   > And if "rep" (unext0 is one of those 16 (and it would be) then that's four-instruction microloops instead of three instructions.
2023-12-01 19:08:49 <KipIngram   > (unext)
2023-12-01 19:10:35 <KipIngram   > That was where 6-bit instructions were oh so nice - I'd have made sure rep was one of the instructions that would fit in that last two-bit slot, and that would have allowed five instruction micro-loops.
2023-12-01 19:12:10 <KipIngram   > That seventh instruction bit, though, allows those near call and near jump facilities, and I'm quite sure that will save more space than it consumes.
2023-12-01 19:12:28 <KipIngram   > Given my own personal coding style.
2023-12-01 19:31:51 <veltas      > 7th bit adventists
2023-12-01 19:41:35 <KipIngram   > :-)
2023-12-01 19:42:01 <thrig       > 2nd page orthodox
2023-12-01 19:42:54 <KipIngram   > Too good, guys.
2023-12-01 19:43:07 <KipIngram   > It must be Friday and we're all in a good mood.
2023-12-01 19:43:16 <Riviera     > no u
2023-12-01 19:43:50 <thrig       > punning is nominal operation mode here
2023-12-01 20:06:30 <veltas      > KipIngram: Gallows humour, actually
2023-12-01 20:07:27 <veltas      > I've had quite a diabolical day and I'm still working at 7pm so puns are getting me through
2023-12-01 20:07:48 <veltas      > Looking forward to passing out trying to finish advent of code day 1 tonight
2023-12-01 20:11:22 <KipIngram   > Yeah, it is getting on late for you.
2023-12-01 20:11:28 <KipIngram   > Just wrapped up lunch here.
2023-12-01 20:11:56 <KipIngram   > I've got some tests finishing in a few hours and I need to start a bunch more after them, so I'll probably run late.
2023-12-01 20:12:21 <KipIngram   > My wife just left town to take her mother in law to visit her brother, so I've gotta clatter around here on my own all weekend.
2023-12-01 20:13:44 <veltas      > Aww that sucks
2023-12-01 20:14:17 <veltas      > This weekend I've got to set up a WordPress instance for someone (I have no idea at all how long that will take, I'm hoping a few hours ....)
2023-12-01 20:14:23 <veltas      > And then do more stuff if I have time
2023-12-01 20:15:07 <veltas      > So busy, but at least I'm with my wife
2023-12-01 20:16:22 <veltas      > Anyone here know web stuff, what am I in for with wordpress?
2023-12-01 20:16:55 <thrig       > exploits. don't install plugins.
2023-12-01 20:19:00 <veltas      > Sounds legit
2023-12-01 20:19:15 <veltas      > I'll tell my wife that because she's doing all the front-end stuff
2023-12-01 20:58:28 <veltas      > 64-bit time is great
2023-12-01 20:59:09 <thrig       > coming soon in 2038, 1901
2023-12-01 21:00:24 <veltas      > I can just shut my brain off
2023-12-01 21:00:47 <veltas      > Not my problem, have fun when my 1ms timer stops working in 500 centuries
2023-12-01 21:01:52 <thrig       > some cisco routers used to derp (and may still do?) when a 32-bit counter rolls around. just long enough for someone to forget where that switch was
2023-12-01 22:13:53 <hello-operator> Question to the channel: I've implemented a fair few Forths myself, but never the local wordset, does any one have a guide / simple to understand Forth code and implementation on how it is best done?
2023-12-01 22:14:20 <hello-operator> I don't necessarily want to *use* the local wordset, it is just something that is missing from my Forths.
2023-12-01 22:23:46 <veltas      > Have you seen the example implementations of the words in https://forth-standard.org/standard/locals ?
2023-12-01 22:24:44 <veltas      > There's also https://github.com/earl/gforth-mirror/blob/master/compat/anslocal.fs which implements nicer local syntax from the old standard LOCALS| word
2023-12-01 22:24:57 <veltas      > Or, rather, using (LOCAL)
2023-12-01 22:25:09 <veltas      > hello-operator: ^
2023-12-01 22:25:31 <veltas      > I'd look at gforth because that's probably a decent implementation
2023-12-01 22:27:33 <veltas      > This one is unnecessarily advanced https://github.com/earl/gforth-mirror/blob/master/glocals.fs
2023-12-01 22:28:09 <veltas      > Also some forths will actually allocate registers that aren't already assigned for the first few locals
2023-12-01 22:31:16 <veltas      > Could look at what SwiftForth does in the demo as well
2023-12-01 22:32:12 <hello-operator> veltas: Cheers! I haven't. That's a lot to look at an exactly what I wanted
2023-12-01 22:33:18 <veltas      > I hope it's useful
2023-12-01 22:34:03 <veltas      > Yeah I don't use locals, they feel too heavy, but I do think it's worth implementing them
2023-12-01 22:34:15 <veltas      > And then you can write untyped RPN C code
2023-12-01 22:34:45 <veltas      > Just as a proof of concept it's cool but it just doesn't feel like forth
2023-12-01 22:37:21 <KipIngram   > I occasionally think about locals, but I also wind up deciding they're too much cost for Forth.
2023-12-01 23:02:38 <zelgomer    > that's more or less how i feel about dating
2023-12-01 23:02:55 <veltas      > lol
2023-12-01 23:04:13 <KipIngram   > :-)
2023-12-01 23:04:43 <KipIngram   > Good grief, the year or so I was "unattached" after my first marriage I spent WAY too much money chasing women.
2023-12-01 23:05:14 <KipIngram   > 1995.  That was a crazy year.
2023-12-01 23:05:34 <zelgomer    > i remember 1995. good year. dark forces came out for DOS
2023-12-01 23:06:31 <KipIngram   > Yeah, my divorce was final Dec. 22, 1994 and I met my current wife Jan. 8, 1996.
2023-12-01 23:09:26 <KipIngram   > So 1995 was more or less wall to wall fun.  I was 32, and that turned out to be almost the ideal age to be single.
2023-12-01 23:09:58 <KipIngram   > All those women in there mid-30's that were getting desperate to land a man.  I was perfectly happy to let them make a run at me.
2023-12-01 23:10:01 <zelgomer    > 1994 was a good year, too. super metroid came out for SNES
2023-12-01 23:10:50 <zelgomer    > idr what came out in 1996 but probably something good. 1997 was dark forces ii: jedi knight
2023-12-01 23:10:52 <KipIngram   > And my moral defense is that the next year my wife did land me - I was "landable."  Just took that long for the right one to come along.
2023-12-01 23:24:21 <veltas      > Breath! https://github.com/Veltas/aoc23/blob/main/1-2.4th
2023-12-01 23:24:46 <veltas      > Wasn't filtered on day 1, will go out window tomorrow because I've got too much to do
2023-12-01 23:24:56 <veltas      > But I'm happy to get first day done :)
2023-12-01 23:50:27 <zelgomer    > oh of course! quake came out in 96, how could i forget
2023-12-01 23:56:06 <gordonjcp   > 1995 I was moving between backwards and forwards a couple of degrees east and west, down south about 56°N, between shacking up with my then-girlfriend and helping my mate's dad build a house
2023-12-01 23:56:32 <gordonjcp   > '96 I moved back up north, got into Linux, and started developing web apps
2023-12-01 23:59:17 <veltas      > Is anyone else attempting advent of code this year?