2023-01-08 10:51:51 <KipIngram   > Looks like you have both local and global labels in WP34S code.  And each key on the keyboard has a "row/column" code that corresponds to some particular local label (labels comprised of two numeric digits fall into the local category).
2023-01-08 10:52:35 <KipIngram   > So that means that each program (code in END statement separated sections) can use such labels appropriately to assign arbitrary code to each key - you can then run that by hitting XEQ <key>.
2023-01-08 10:53:10 <KipIngram   > That's kind of neat - you can organize things so that you say "GTO <global label>" and that instantly assigns a new set of functionality to all your 'XEQ <key>' strokes.
2023-01-08 10:53:34 <KipIngram   > I don't reall things working quite like that in the HP-41 (though it's been a while).
2023-01-08 10:54:00 <KipIngram   > You could "assign" labels to keys, but I don't think you could easily switch the whole keyboard over to a different behavior in such an easy way.
2023-01-08 10:55:51 <KipIngram   > I think I'm going to undertake writing a set of astronomy-related programs for one or another of these calculators I've got.  Really just for fun - to "refamiliarize" myself with doing this sort of thing.  Maybe I WOULD use a calculator more often if I was as familiar with making such tools as I was with my 41.
2023-01-08 10:56:20 <KipIngram   > Truth be told I'm just horribly out of practice, and that probably ENCOURAGES me to turn away from calculators when I've got some problem to solve.
2023-01-08 10:57:16 <MrMobius    > KipIngram: heh ya. calculators are amazing but I think the heyday ended 10+ years ago
2023-01-08 10:58:05 <KipIngram   > Yeah, I know - I've felt that way for longer than that.
2023-01-08 10:58:07 <MrMobius    > at one of the calculator conferences a guy who has written several calculator emulators and done other amazing stuff said "Python" when we all went around saying what calculator we use. he has a point
2023-01-08 10:58:24 <KipIngram   > I'd be doing this mostly for nostalgia sake, likely.
2023-01-08 10:58:39 <KipIngram   > Also, there are four functions on the WP34S keyboard that appear in two places.
2023-01-08 10:58:52 <KipIngram   > Sum-plus, 1/x, y^x, and sqrt.
2023-01-08 10:59:25 <MrMobius    > do you know how much ram the chip in the WP34S has?
2023-01-08 10:59:34 <KipIngram   > They appear in "dedicated spots" around the keyboard, but they also appear as "super functions" of the keys that have primary labels A B C D.
2023-01-08 11:00:02 <KipIngram   > it's easy to use the A-D keys for those, on first instict, because it's easier to see those labels - the printing is bigger an dthey stand out better.
2023-01-08 11:00:17 <MrMobius    > seems like they put a lot of thought into it
2023-01-08 11:00:19 <KipIngram   > But if you're in a program that has an A-D label, those keys will then do that instead.
2023-01-08 11:00:34 <KipIngram   > So I probably ought to discipline myself to use the other keys for those functions.
2023-01-08 11:00:53 <KipIngram   > Absolutely re: Python.
2023-01-08 11:01:12 <KipIngram   > There's just no doubt that our computers have become our "best go to" devices for things.
2023-01-08 11:01:18 <KipIngram   > I mean... just look at them.
2023-01-08 11:01:25 <KipIngram   > They can do so much more, so much faster.
2023-01-08 11:02:15 <KipIngram   > Well, I'm probably going to wind up using the WP34S emulator on my phone.  Just because my phone will be with me more, and it's a lot easier to read the brightly lit keyboard.
2023-01-08 11:02:25 <KipIngram   > I can just see the labels better, with my 60 year old eyes.
2023-01-08 11:02:41 <KipIngram   > Also my WP34S units are both fairly old, and keystroke reliability isn't perfect.
2023-01-08 11:02:48 <KipIngram   > Which is a shame, but it's how it is.
2023-01-08 11:03:16 <KipIngram   > I think that emulator is a true emulator, using the real WP34S firmware, though, so it has the same memory limitations.
2023-01-08 11:03:24 <KipIngram   > I've got the manual open now lemme see if I can find that.
2023-01-08 11:03:28 <KipIngram   > It's not anything "huge."
2023-01-08 11:03:43 <KipIngram   > But it's certainly more than my HP-41CV had, and I did a hell of a lot with it.
2023-01-08 11:06:21 <KipIngram   > Looks like 6kB of RAM, of which 2kB is battery backed.
2023-01-08 11:06:47 <KipIngram   > You can get at most nine-hundred something program steps, and that would be with minimum registers allocated.
2023-01-08 11:07:09 <KipIngram   > Registers can go up to something over a hundred.
2023-01-08 11:07:26 <KipIngram   > You can allocate it back and forth between data storage and program steps.
2023-01-08 11:07:35 <KipIngram   > In other words, it seems pathetic compared to what we're used to.
2023-01-08 11:07:46 <KipIngram   > But as I said, it turns out you can do a lot if you set the right goals.
2023-01-08 11:09:11 <KipIngram   > I wrote a program for my 41 that let me look at circuit diagram (R's, L's, C's', sinusoidal sources); I could do on-the-fly calculations using the visible component values; here and there as I did so I'd hit buttons that stored things in a big complex matrix.
2023-01-08 11:09:33 <KipIngram   > I could get the network matrix equation for the circuit stored without having to use any scratch paper; it was fairly low labor.
2023-01-08 11:13:14 <KipIngram   > Then I could hit a "solve" button and it would solve for all of the complex voltages and currents.
2023-01-08 11:13:34 <KipIngram   > And that was on a calculator that had no native complex arithmetic support - I wrote that all in myself.
2023-01-08 11:13:51 <KipIngram   > It did a standard Gaussian elimination with partial pivoting on that big matrix.
2023-01-08 11:14:03 <KipIngram   > So it would cut through circuit problems pretty cleanly.
2023-01-08 11:14:22 <KipIngram   > Also wrote a "Smith chart emulator" that made s hort work of transmission line problems.
2023-01-08 11:14:46 <KipIngram   > Part of the trick, I think, is to avoid "shooting too high."
2023-01-08 11:14:54 <KipIngram   > The thing is not a computer - it's not going to rival a computer.
2023-01-08 11:15:08 <KipIngram   > But if the problem is within its reach, it can be set up in very effective ways.
2023-01-08 11:15:44 <KipIngram   > I may wind up writing some of these little things on several different calculators - just to see which one I think has the "cleanest" operation.
2023-01-08 11:16:04 <KipIngram   > They have small difference sin how they work; it'll be interesting to see which of those things seem to "have impact" and which don't.
2023-01-08 11:21:10 <KipIngram   > Youu know, the way I ought to describe this "loopback" capability of my processor is to state that each called definition has one local label at its disposal.  That label is initialized to the beginning of the definition, when the def is called, but can be changed to "current IP" by the :. instruction.
2023-01-08 11:21:16 <KipIngram   > That's the only jump target you can have.
2023-01-08 11:21:39 <KipIngram   > The processor automatically handles allocating space for that label on call and de-allocating it on return.
2023-01-08 11:22:00 <KipIngram   > It's sort of an "automated local variable" that is a pointer to code.
2023-01-08 11:22:14 <KipIngram   > It's where the "me" intructions take you.
2023-01-08 11:22:51 <KipIngram   > And that's where the "no nested loops" limitation (unless they share the same jump target) comes from.
2023-01-08 11:24:01 <KipIngram   > If I wanted flag bits or anything like that I could handle them the same way; in that case I'd probably have the callee's flags initialized to the caller's flags on call.
2023-01-08 11:24:25 <KipIngram   > That would function a bit like bash environment variables.
2023-01-08 11:24:38 <KipIngram   > Child processes get a copy, but changes they make are discarded when they end.
2023-01-08 11:24:56 <KipIngram   > So it would be a one-way communication link.
2023-01-08 11:25:52 <KipIngram   > One weakness of the way I'm designing this is that the RAM associated with all those things is spent - whether it's used or not.  It's permanently allocated for that functionality, in order to give me the ability to access it in parallel with other stuff going on.
2023-01-08 11:26:59 <KipIngram   > I don't need to store flag type things that way, though; such conditions are determined and used in the same instruction, so that can never get interrupted.
2023-01-08 11:28:38 <KipIngram   > Ah - WP34S does conditional tests by giving you program steps to evaluate the various conditions; if the condition is false the next program step is skipped.
2023-01-08 11:29:17 <KipIngram   > So any instruction can be made conditional by calling out a "condition prefix," so to speak.
2023-01-08 11:29:54 <KipIngram   > That would be easy to implement in Forth.
2023-01-08 11:30:24 <KipIngram   > I could do that in the processor too, but then I would have to think about what might happen if an interrupt occurs in between the condition check and the next instruction.
2023-01-08 11:31:19 <KipIngram   > And also making that work when the next step was a definition call would be additional to implementing it for next step = opcode.
2023-01-08 11:32:21 <KipIngram   > I'm a little bummed thinking about how much space I might waste switching back and forth between definition calls and native instruction executions.
2023-01-08 11:32:54 <KipIngram   > I guess on average I'll waste half of each opcode cell.
2023-01-08 11:33:41 <KipIngram   > I was wondering yesterday if perhaps there's a better way to blend that stuff.
2023-01-08 11:34:06 <KipIngram   > Think I'll give that some thought today.
2023-01-08 11:53:11 <KipIngram   > Seems like what would be nice would be to peel content out of RAM in a "streaming" sort of way, and as you pick through it, you might find six-bit opcodes, or you might find jump/call specifiers, which could be a) of various sizse, depending on how far you need to jump or call, and b) absolute or relative.
2023-01-08 11:53:56 <KipIngram   > The absolute addressing would get you at your "core words," in low RAM, with short fields.  The relative addressing would get you at "words near you" that are related to the job you're trying to do now.
2023-01-08 11:54:11 <KipIngram   > Put all that together, and you ought to wind up with "near compact as possible" code.
2023-01-08 11:54:49 <KipIngram   > It's the sort of thing that would be slow, or at least slow-ish, if implemented on a regular processor, but with hardware flexibility available could be made really fast.
2023-01-08 11:58:22 <KipIngram   > So the code stream would have variable size fields; you'd need field width specifiers.  That number could specify a number of opcodes coming up, or it could specify a width (somehow) of an upcoming address field.  Lot of ways to twist that around.
2023-01-08 11:59:24 <KipIngram   > I could still have a maximum number of opcodes that could appear in one chunk, and I'd still service interrupts on chunk boundaries.
2023-01-08 15:43:15 <vms14       > I'll never have something near to a real forth I guess :/
2023-01-08 15:43:41 <vms14       > I wanted to learn assembly, targeted the z80 as I wanted to end with some game boy development
2023-01-08 15:44:14 <vms14       > I was reading "programming the z80" book and some gb docs and tutorials
2023-01-08 15:44:22 <vms14       > now I'm making another release in js
2023-01-08 15:44:26 <vms14       > 
ACTION cries

2023-01-08 15:45:06 <vms14       > haha I was thinking I want to make a clone of the vampire survivors on the gameboy
2023-01-08 15:45:38 <vms14       > but watching all the clones already existing in android I just wanted to make one in js
2023-01-08 15:46:34 <vms14       > although interesting, targeting the game boy makes no sense
2023-01-08 15:46:53 <vms14       > just an excuse to play with assembly and make a not so forth on it
2023-01-08 15:47:29 <vms14       > already exists one btw
2023-01-08 15:47:30 <vms14       > http://gbforth.org/
2023-01-08 15:48:59 <vms14       > but it's not an interpreter, so it won't work as it should
2023-01-08 15:49:11 <vms14       > http://gbforth.org/meta.html
2023-01-08 15:52:18 <MrMobius    > vms14: could you make the game in assembly? might be a good goal to get to before doing it in forth
2023-01-08 15:52:35 <MrMobius    > not to totally make the game in assembly but to get to the point where you could
2023-01-08 15:52:55 <vms14       > yeah, I was thinking to first try the game in asm in order to not start the "forth" implementation with no idea
2023-01-08 15:53:15 <vms14       > and also it would make it easier later when doing it with that lang
2023-01-08 15:53:21 <vms14       > but meh
2023-01-08 15:53:34 <vms14       > logic says use js
2023-01-08 15:55:09 <vms14       > the gameboy has some advantages, mainly I always wanted to learn asm, it has emulators on almost all platforms, and it's a "console" which resembles a hardware api for making games
2023-01-08 15:55:49 <vms14       > js also has "emulators" on almsot all platforms, and it's likely they'll be installed
2023-01-08 15:56:24 <vms14       > and has no those memory or hardware limitations the gb has
2023-01-08 15:57:27 <vms14       > well I don't want to enumerate the advantages of choosing js instead, but there are several
2023-01-08 15:57:56 <vms14       > I'm not a huge js fan anyways, I even dislike web dev, but logic always tries to put me there
2023-01-08 15:58:51 <vms14       > the money the web moves, the users, the ease of sharing a link and have your app running on the random visitors without having to install
2023-01-08 15:59:00 <vms14       > also even the ability to be installed xd
2023-01-08 16:02:16 <Zarutian_iPad> installed? you mean a Progressive Web Application?
2023-01-08 16:05:50 <MrMobius    > vms14: how about a Z80 calculator?
2023-01-08 16:07:35 <vms14       > Zarutian_iPad: yeah
2023-01-08 16:08:00 <vms14       > MrMobius: nah, the only interesting thing is to make a forth-like
2023-01-08 16:08:14 <vms14       > and then maybe make a calculator with it :D
2023-01-08 16:10:47 <veltas      > I don't think I read any Z80 programming books before writing Z80
2023-01-08 16:11:12 <MrMobius    > vms14: I mean make your forth like on the calculator not make a calculator
2023-01-08 16:11:16 <veltas      > I just read the Z80 manual and some guides on doing multiplication and division
2023-01-08 16:11:40 <veltas      > And I occasionally read other people's code to discover I was doing stupid things, or cool hacks
2023-01-08 16:11:48 <vms14       > veltas: I likee to read books when I want to start learning X thing
2023-01-08 16:12:02 <vms14       > but the book was super boring as it just focused on math
2023-01-08 16:12:14 <veltas      > I do too, but Z80 was something I didn't need a book for
2023-01-08 16:12:22 <veltas      > And frankly if I don't need it you probably don't either
2023-01-08 16:12:38 <vms14       > I tend to both read books and some tutorials posts and even youtube videos when I get bored
2023-01-08 16:12:45 <veltas      > I'm trying to encourage, not brag
2023-01-08 16:12:57 <vms14       > nah, the encouragement has gone anyways
2023-01-08 16:13:21 <vms14       > if I end learning asm, won't be for the z80
2023-01-08 16:13:23 <veltas      > But anyway, in my opinion a JavaScript game is a worthy venture
2023-01-08 16:13:35 <veltas      > If you want to reach the most people that's the best way to go
2023-01-08 16:13:36 <KipIngram   > vms14: Man, never say never.
2023-01-08 16:13:41 <vms14       > the z80 was only to end in the game boy
2023-01-08 16:13:54 <KipIngram   > Just say "not yet."
2023-01-08 16:13:58 <vms14       > but to make a game I'll just make an abomination on js
2023-01-08 16:14:48 <vms14       > KipIngram: I mean, the only reason that made me end in the z80 was the gameboy
2023-01-08 16:14:50 <veltas      > I find it quite healthy to write abominably in my free time :)
2023-01-08 16:15:03 <vms14       > if I end learning asm, it won't be for this reason anymore, I guess
2023-01-08 16:15:30 <vms14       > I'd even go to mips rather than the z80 xD
2023-01-08 16:15:47 <veltas      > I only learned Z80 to use with ZX Spectrum
2023-01-08 16:15:49 <vms14       > I'm curious of why some people seem to love it so much
2023-01-08 16:15:56 <veltas      > I started with BASIC and wanted to go faster
2023-01-08 16:16:11 <veltas      > I wanted to see what was possible on that old platform, turns out a LOT
2023-01-08 16:16:16 <veltas      > A lot more than people might expect
2023-01-08 16:16:29 <vms14       > well with asm, you can do almost whatever you want
2023-01-08 16:16:34 <vms14       > with basic... xD
2023-01-08 16:17:05 <veltas      > It's quite impressive what you can do with BASIC
2023-01-08 16:17:07 <vms14       > microsoft wanted to put basic everywhere
2023-01-08 16:17:23 <veltas      > The Sinclair BASIC was especially restrictive
2023-01-08 16:17:30 <veltas      > and slow
2023-01-08 16:18:17 <veltas      > Someone I know who retired recently made £1000 selling some software that fit in one line of ZX81(?) BASIC to a company
2023-01-08 16:18:53 <veltas      > Although I think it contained assembly
2023-01-08 16:18:59 <veltas      > Can't remember what it did
2023-01-08 16:19:19 <veltas      > But that was one of the first things he did before becoming a proper software engineer
2023-01-08 16:19:29 <KipIngram   > Man, why couldn't I find those gigs when  I consulted?
2023-01-08 16:19:29 <veltas      > Writing assembly, and then Forth at MPE Forth for a while
2023-01-08 16:19:56 <veltas      > He thought Forth was fantastic after writing so much assembly
2023-01-08 16:20:06 <veltas      > And he said he remembered really struggling to 'get' C after Forth
2023-01-08 16:20:49 <veltas      > He gave me his copy of Starting Forth (2nd edition) before retiring
2023-01-08 16:21:11 <vms14       > haha it's likely assembly gives less headaches than C
2023-01-08 16:22:25 <vms14       > I liked C a lot when I started with programming, specially because it forced me to learn more than other high level languages
2023-01-08 16:22:34 <vms14       > also I felt freedom there
2023-01-08 16:22:49 <vms14       > for me this feeling is important :D
2023-01-08 16:23:14 <vms14       > but today, I don't like C as I liked it before and I try to avoid it as much as I can
2023-01-08 16:23:25 <vms14       > writing some lines of C makes me cry
2023-01-08 16:23:31 <veltas      > Why do you dislike it now
2023-01-08 16:23:49 <vms14       > don't really dislike it, but it's not as fun as I thought
2023-01-08 16:23:57 <vms14       > it's mainly a pain in the ass
2023-01-08 16:24:06 <veltas      > An example?
2023-01-08 16:24:21 <veltas      > I'm not here to call you out, just interested in what you don't like about it
2023-01-08 16:24:21 <vms14       > for example my shitty lang implementation
2023-01-08 16:24:33 <vms14       > I want a stack able to get any type
2023-01-08 16:24:43 <vms14       > I have several options, which I dislike
2023-01-08 16:24:58 <vms14       > void * stack; so I use malloc for even an integer
2023-01-08 16:25:19 <vms14       > unions, so the stack cell is like the largest data type
2023-01-08 16:25:36 <vms14       > and what I done, to mantain multiple stacks and a type stack XD
2023-01-08 16:25:48 <vms14       > for words you have two options
2023-01-08 16:25:55 <veltas      > My advice, pick reasonable implementation assumptions
2023-01-08 16:26:10 <vms14       > function pointers or labels as values (the computed goto) only available as a gcc exception
2023-01-08 16:26:10 <veltas      > i.e. "I am supporting GCC + modern 32-bit/64-bit arch's"
2023-01-08 16:26:50 <vms14       > the thing is, I didn't enjoy that process
2023-01-08 16:27:14 <vms14       > and I wasn't sure why I really wanted to have a C implementation
2023-01-08 16:27:27 <veltas      > Because it's portable probably
2023-01-08 16:27:35 <vms14       > the only thing I miss from C is Xlib and I can get what I want with ffi
2023-01-08 16:27:42 <vms14       > veltas: I was using perl xD
2023-01-08 16:28:00 <vms14       > but no, the only reason would be efficiency or libraries
2023-01-08 16:28:48 <veltas      > In C instead of computed goto I would probably use return call optimisation
2023-01-08 16:29:04 <veltas      > Because it works reliably in sane compilers with basic optimisation turned on
2023-01-08 16:31:28 <vms14       > I can't explain it properly, but I do not enjoy C as I did when I started
2023-01-08 16:31:39 <vms14       > nor I see it like a "good" language
2023-01-08 16:31:50 <vms14       > maybe random people comments affected me :D
2023-01-08 16:32:17 <vms14       > but it's mainly I got used to not have to die with problems like C imposes
2023-01-08 16:32:22 <veltas      > The internet's language lawyerism about C is what ruins it
2023-01-08 16:32:52 <vms14       > and to suffer those restrictions, just to have a speed I do not really know if I want, meh
2023-01-08 16:33:03 <veltas      > What restrictions?
2023-01-08 16:33:07 <vms14       > assembly at least has a point, as I always wanted to learn it
2023-01-08 16:34:04 <vms14       > well not really restrictions, as you can make your way
2023-01-08 16:34:21 <veltas      > Having to think about memory?
2023-01-08 16:34:27 <veltas      > Static typing?
2023-01-08 16:34:37 <vms14       > say... it misses abstractions I got used to have
2023-01-08 16:34:41 <veltas      > I mean those are valid complaints about it, and why I love scripting
2023-01-08 16:34:59 <vms14       > still C is not a bad lang
2023-01-08 16:35:14 <vms14       > js is a bad lang
2023-01-08 16:35:15 <vms14       > XD
2023-01-08 16:35:22 <veltas      > I like JS too
2023-01-08 16:35:29 <veltas      > They all have their place
2023-01-08 16:35:37 <vms14       > I don't like js, but don't dislike it either
2023-01-08 16:35:49 <veltas      > I prefer simpler languages because I've seen how people abuse more powerful features
2023-01-08 16:36:06 <vms14       > also it has much more performance than what I'd expect
2023-01-08 16:36:07 <veltas      > Programmers always find excuses to do stuff the hard way, or the more complicated way
2023-01-08 16:36:34 <veltas      > JS is the #1 programming language
2023-01-08 16:37:01 <vms14       > XD
2023-01-08 16:37:43 <veltas      > Also I don't use the new JS features, I tend to stick to what's supported by older internet explorer
2023-01-08 16:37:49 <vms14       > could be seen as that, the world is being moved by the web, and on top of the web there is js
2023-01-08 16:38:10 <veltas      > Because I want the widest reach, and there's people out there stuck using old devices in third world countries I'd rather talk to than poseur 'web devs'
2023-01-08 16:38:20 <KipIngram   > C just has more... "rules" than Forth.
2023-01-08 16:38:27 <KipIngram   > Moving parts that have to work together.
2023-01-08 16:38:39 <KipIngram   > Forth is nice and "one thing at a time."
2023-01-08 16:38:43 <veltas      > C is more restricted than Forth yeah
2023-01-08 16:38:54 <veltas      > And more expressive
2023-01-08 16:39:02 <veltas      > in some ways
2023-01-08 16:40:28 <KipIngram   > vms14: you could keep void *'s on the stack, and have stack entries point to things.  Then you could have pools for each data type, and a stack cell could point into any of them.
2023-01-08 16:40:44 <KipIngram   > Or maybe the stack cell is a void * pointer and a "type code."
2023-01-08 16:41:11 <vms14       > no :/
2023-01-08 16:41:20 <vms14       > well it's the best option of what I had
2023-01-08 16:41:28 <vms14       > and I think I choose the worst one
2023-01-08 16:42:47 <vms14       > I even have the code
2023-01-08 16:42:48 <vms14       > xD
2023-01-08 16:43:08 <vms14       > https://termbin.com/zdin
2023-01-08 16:43:19 <vms14       > I dislike a lot the use of those macros
2023-01-08 16:43:34 <vms14       > but all stacks used the same code
2023-01-08 16:44:07 <KipIngram   > It's how I'm going to do it, except not with C.
2023-01-08 16:44:26 <KipIngram   > Stack cells will have an address field and a type field.
2023-01-08 16:44:47 <KipIngram   > Except for integers, which will be stored directly on the stack.
2023-01-08 16:45:17 <KipIngram   > To allow for the type field, I'll give up the extreme positive and negative integer values.
2023-01-08 16:45:17 <vms14       > I had a stack for ints, another for floats, another for strings and another for void * which would be any other stuff
2023-01-08 16:45:18 <vms14       > XD
2023-01-08 16:45:23 <vms14       > and a type stack
2023-01-08 16:45:24 <KipIngram   > However many bits I need for the type.
2023-01-08 16:45:40 <KipIngram   > And both all zero bits and all one bits will be "type integer."
2023-01-08 16:45:59 <vms14       > also they grow automagically, and they won't even exist unless you put an element there
2023-01-08 16:46:00 <KipIngram   > So within that range, normal Forth words will continue to "work" for "typed integers."
2023-01-08 16:46:53 <KipIngram   > the problem with a separate type stack, which I've al so considered, is that you have to maintain it, which means native Forth words (which are ignorant of this system) will get your stacks out of sync.
2023-01-08 16:46:56 <vms14       > but then linked lists to impleent arrays, choose between pointers or computed goto for words, etc
2023-01-08 16:47:10 <KipIngram   > I'm going to use ropes for arrays.
2023-01-08 16:47:18 <KipIngram   > So small arrays will just be... an array.
2023-01-08 16:47:37 <KipIngram   > Larger ones will spread across rope cell groups.
2023-01-08 16:47:40 <vms14       > I have the feeling it's easier to do it in asm
2023-01-08 16:47:49 <KipIngram   > I tend to agree.
2023-01-08 16:47:56 <KipIngram   > But maybe more laborious.
2023-01-08 16:48:05 <vms14       > but feels more correct there
2023-01-08 16:48:17 <vms14       > I can't really talk, but I have that feeling
2023-01-08 16:48:29 <thrig       > hilarity happens when the FPU gets out of sync with the rest of the system
2023-01-08 16:48:31 <KipIngram   > Anyway, I've tried the C-based Forth path, exploiting that gcc pointer to label feature to get it to "work real."
2023-01-08 16:48:39 <KipIngram   > That worked fine, but it was horribly ugly.
2023-01-08 16:52:50 <KipIngram   > I'll provide Forth words for incrementing through entries of an array - they'll know how and when to use the ropes data structure to get from one cell group to the next.  And will work on arrays of any type.
2023-01-08 16:53:30 <vms14       > I'm fine with scripting languages and a not-so-forth abomination btw
2023-01-08 16:53:51 <KipIngram   > But if I *know* that I'm working with a small array that fits in one ropes page, then I can do things in the usual "arrays in Forth" way; within that one ropes page it'll look like a completely normal array or string or whatever.
2023-01-08 16:54:00 <vms14       > https://termbin.com/moz0x  this is almost the core
2023-01-08 16:54:17 <KipIngram   > It's been a while since I thought through all that, but I have notes around here somewhere.
2023-01-08 16:54:22 <vms14       > 124 lines and some functions shouldn't even exist xd
2023-01-08 16:54:25 <MrMobius    > vms14: +1 for learning MIPS :D
2023-01-08 16:54:36 <vms14       > MrMobius: what's so good of mips?
2023-01-08 16:54:59 <MrMobius    > vms14: I like programming in it after doing 8 and 16 bit assembly. it feels luxurious
2023-01-08 16:55:13 <vms14       > I have curiousity as I see some people quite happy with mips
2023-01-08 16:55:27 <vms14       > I like the fact it has a lot of registers
2023-01-08 16:55:27 <MrMobius    > ya for learning it seems popular
2023-01-08 16:55:49 <vms14       > MrMobius: I saw some stuff for learning operaating system devs using mips assembly
2023-01-08 16:55:59 <vms14       > idk the name, but it was even used in university
2023-01-08 16:56:19 <MrMobius    > neat. I got debian linux running on a mips VM a few weeks ago
2023-01-08 16:57:57 <vms14       > MrMobius: http://www.os161.org/documentation/sys161/
2023-01-08 16:58:50 <MrMobius    > cool!
2023-01-08 16:59:38 <KipIngram   > vms14: Agree with MrMobius's learning +1.
2023-01-08 16:59:56 <KipIngram   > I've thought for a while that you're benefiting from this stuff you're doing.  Stretching your thinking.
2023-01-08 17:00:22 <KipIngram   > Oh, I misread that - he was talking about MIPS specifically.
2023-01-08 17:00:26 <KipIngram   > Well, that too.  :-)
2023-01-08 17:01:12 <MrMobius    > hehe
2023-01-08 17:01:41 <veltas      > I would have used a union stack
2023-01-08 17:01:45 <veltas      > vms14
2023-01-08 17:02:05 <vms14       > yeah, union and void * stack are the two options that seem more logical
2023-01-08 17:02:15 <vms14       > I chose the worse one :D
2023-01-08 17:02:32 <thrig       > pikachu! I buffer overflow you!
2023-01-08 17:02:33 <vms14       > but I dislike the union cell being as large as the largest element
2023-01-08 17:02:55 <vms14       > and the void * forces me to even malloc an integer, which is sad
2023-01-08 17:03:03 <veltas      > Also your macro magic would be better served with just structs
2023-01-08 17:03:06 <KipIngram   > That seems really problematic to me, because you might want some VERY LARGE item types.
2023-01-08 17:03:10 <thrig       > maybe one of these years Nintendo will write secure code...
2023-01-08 17:03:14 <KipIngram   > Seems like it would be really wasteful of stack space.
2023-01-08 17:03:38 <KipIngram   > Pointers into pools of various types avoids that.
2023-01-08 17:03:44 <vms14       > yeah, it worries me, but really it shouldn't
2023-01-08 17:03:48 <veltas      > What stack space?
2023-01-08 17:03:56 <veltas      > Don't need to put the 'stack' on the C 'stack'
2023-01-08 17:04:07 <veltas      > It can go anywhere really
2023-01-08 17:04:31 <veltas      > Going to read to my wife, have a good night everyone
2023-01-08 17:04:45 <MrMobius    > dont some languages use the highest but to encode integer or pointer?
2023-01-08 17:05:09 <MrMobius    > so you have to settle for a smaller integer range but dont lose memory malloc'ing it for one int
2023-01-08 17:05:23 <MrMobius    > *highest bit
2023-01-08 17:05:47 <vms14       > gn veltas :D
2023-01-08 17:06:08 <vms14       > 
ACTION wonders what veltas will read to his wife

2023-01-08 17:06:49 <vms14       > Data Algorithms: Part 1
2023-01-08 17:07:01 <vms14       > or once upon a time...
2023-01-08 17:11:37 <vms14       > nice part of the js implementation is I don't even have to provide a way for async code
2023-01-08 17:13:05 <KipIngram   > veltas: I meant the language stack - not the C stack.
2023-01-08 17:13:10 <KipIngram   > Sorry - should have clarified.
2023-01-08 19:09:32 <vms14       > KipIngram: what do you do when you want temporary bindings?
2023-01-08 19:10:24 <vms14       > I'm not going to have variables as words can be variables themselves, but I want something that lets me have temporary bindings
2023-01-08 19:11:02 <vms14       > I was usually taking a list of names and checking if those words already existed, to save their values and overwrite them temporarily, execute code and restore those words later
2023-01-08 19:11:17 <vms14       > but it turns to be super expensive so I have to find another way
2023-01-08 19:12:01 <vms14       > I would end having autoreset variables in colon words if I don't find anything better
2023-01-08 19:12:23 <vms14       > which means a hash/js object with variables that gets reset for every colon word call xD
2023-01-08 20:36:24 <vms14       > 
ACTION sets utf8 on his machine

2023-01-08 20:36:32 <vms14       > also me: ฅ/ᐠ. ̫ .ᐟ\ฅ
2023-01-08 20:36:52 <vms14       > (the only reason to have utf8)
2023-01-08 21:22:14 <KipIngram   > vms14: Not sure exactly what you  mean, but I've had two methods for "temporary name creation."  For me, this is a Forth word definition that I want to have around in the dictionary forever, but I only intend to USE for the compilation of certain words.  Once those words are compiled, I don't need the NAMES of those "helper words" in the dictionary anymore.
2023-01-08 21:22:18 <KipIngram   > I've done it two ways.
2023-01-08 21:22:42 <KipIngram   > In one system, I used a dynamically allocated RAM page to store those portions of the definition only needed temporarily.
2023-01-08 21:23:11 <KipIngram   > When I no longer needed compiler access to those names, I unlinked them from the dictionary linked list and de-allocated the page.
2023-01-08 21:23:47 <KipIngram   > On my most recent system, I don't use a dynamic page.  I go ahead and put the access data in the dictionary just as I always do, but still "unlink" the words when I'm done using them.
2023-01-08 21:24:08 <KipIngram   > In the first case I recovered RAM no longer used - in the second case I don't, but I don't need a dynamic memory manager either.
2023-01-08 21:24:25 <KipIngram   > Don't k now if this is what you mean at all, but it's the closest I've got.
2023-01-08 21:25:24 <KipIngram   > If I want a word to be of this type, I define it with .: instead of :
2023-01-08 21:25:43 <KipIngram   > And I have a word .wipe that will get rid of all .: defined words from the linked list.
2023-01-08 21:26:18 <KipIngram   > I use this HEAVILY - usually my more sophisticated words are highly factored, and the names of those lower level words don't need to stick around.
2023-01-08 21:26:36 <KipIngram   > When defining NUMBER for instance, I wrote 24 definitions.
2023-01-08 21:26:50 <KipIngram   > Only one of them, NUMBER itself, is retained in the dictionary long term.