2022-12-23 00:15:50 <KipIngram   > It looks like when I fire up my Forth and check the return stack "at idle," it has used 15 return stack cells.
2022-12-23 00:16:57 <decay       > you don't preallocate?
2022-12-23 00:17:09 <KipIngram   > When I do rp@ rp0 @ - I get one cell.  So it looks like that's where I "start from" when I run stuff I write.
2022-12-23 00:17:19 <KipIngram   > Well, sure, there's a block allocated for the return stack.
2022-12-23 00:17:23 <decay       > ah.
2022-12-23 00:17:27 <KipIngram   > I'm just looking at how many have been written to.
2022-12-23 00:17:33 <KipIngram   > They're initially zero.
2022-12-23 00:17:35 <decay       > makes sense.
2022-12-23 00:35:32 <KipIngram   > I just had an interesting bug.
2022-12-23 00:36:22 <KipIngram   > Somehow in my editing of things I'd managed to delete the x from the 0x100 I was passing into EXPECT as the length of the tib.
2022-12-23 00:36:38 <KipIngram   > So in the assembly source I'd written 0100 as that constant.
2022-12-23 00:37:19 <KipIngram   > Anyway, the effect was that it would work fine until my typed line was 10 chars long, and then the cursor jumped around on the screen.
2022-12-23 00:37:46 <KipIngram   > I don't understand the full chain of cause and effect yet.
2022-12-23 00:39:15 <KipIngram   > It's odd, because the tib itself was of proper length - it was just the length CALLOUT to expect that was different somehow.
2022-12-23 00:39:35 <KipIngram   > I don't really see how 10 comes into it at all.
2022-12-23 00:41:07 <decay       > I might.
2022-12-23 00:41:21 <decay       > octal?
2022-12-23 00:43:00 <KipIngram   > I thought of that, but 0100 would then be 64, right?
2022-12-23 00:43:15 <KipIngram   > So it should have worked up to 64 long and then just stopped letting me type.
2022-12-23 00:43:23 <KipIngram   > Shouldn't have moved the cursor to another line.
2022-12-23 00:43:48 <decay       > eh, yeah.
2022-12-23 00:44:05 <decay       > it's up to how NASM parses 0100.
2022-12-23 00:44:38 <KipIngram   > Yeah.  Guess I can check that... stand by.
2022-12-23 00:46:29 <KipIngram   > Well, looks like it takes it as decimal 100.   THAT EXPLAINS NOTHING.
2022-12-23 00:47:15 <decay       > any calculations that involve that constant?
2022-12-23 00:47:21 <KipIngram   > It's a 264 byte buffer.
2022-12-23 00:47:34 <KipIngram   > No, it was hard coded there as a number - wasn't a symbolic constant.
2022-12-23 00:48:27 <decay       > where is that 0100 being used.
2022-12-23 00:50:32 <KipIngram   > It's getting passed into EXPECT as the max allowed length of the line I type for regular text input.
2022-12-23 00:50:58 <decay       > what's the code behind EXPECT.
2022-12-23 00:52:08 <KipIngram   > Well, just some code I wrote.  It's fairly extensive.
2022-12-23 00:52:19 <KipIngram   > Doesn't make a lot of sense to try to post it here.
2022-12-23 00:52:56 <KipIngram   > I'll scratch my head over it some more.  It's strange - it's hard for me to see how putting that x back in could have made that behavior go away.
2022-12-23 00:53:56 <KipIngram   > Ok, no - that's not the issue at all.
2022-12-23 00:54:05 <KipIngram   > I took it back out and the behavior didn't return.
2022-12-23 00:54:07 <KipIngram   > Very odd.
2022-12-23 00:59:21 <KipIngram   > So trying to keep two top values from the stack complicates getting the stack to do everything quite a lot.  Much easier to make it work if I only cache the top item.  But if they're not BOTH cached, then I'm not sure it buys any performance to cache either of them.
2022-12-23 03:37:10 <veltas      > Can ChatGPT write maintainable Forth code though?
2022-12-23 03:37:14 <veltas      > (Can anyone?)
2022-12-23 03:55:50 <veltas      > KipIngram: What happens when you write like 200 chars into buffer?
2022-12-23 03:55:54 <veltas      > Maybe there's a bug in your code
2022-12-23 03:56:12 <veltas      > I mean, there is if it fails to write more than 10 chars when you have length 100 buffer
2022-12-23 07:36:18 <razetime    > ChatGPT doesn't write functional code most of the time. IT looks impressive because people retry a hundred times to find a cool/funny/functional result.
2022-12-23 07:36:49 <razetime    > it's a nice toy to spend hours fiddling with.
2022-12-23 07:42:43 <f-a         > we had one example in #haskell-it
2022-12-23 07:42:53 <f-a         > it made some glaring errors on typechecking
2022-12-23 07:43:43 <f-a         > I wonder what the mechamism is, as there are online typecheckers
2022-12-23 08:57:07 <crc         > veltas: how do you define maintainable?
2022-12-23 08:57:26 <veltas      > I think there are different strains of maintainability
2022-12-23 08:58:14 <veltas      > To me maintainable means other people or yourself can pick it up and work with it, adapt it to sensible new requirements, without unnecessary extra difficulty/work
2022-12-23 08:58:36 <veltas      > And I think to be fair to Forth, that shouldn't include cost of "learning forth"
2022-12-23 08:58:47 <veltas      > And the same for retro
2022-12-23 08:59:42 <veltas      > I would say that maintainable code is code that's generally simpler, less unexpected, reduces the impact of unfamiliarity etc
2022-12-23 09:00:12 <veltas      > Factorised in a way to allow easier changing or adding new requirements, but this is much more contextual
2022-12-23 10:22:08 <KipIngram   > veltas: Well, I'd seen this behavior before, a few days ago.  I think it came in when I was trying to change the thing a few weeks ago in response to something we were talking about here, as a test.  Later I "took those changes out," but I may have missed one.
2022-12-23 10:22:22 <KipIngram   > So what may have happened was that I just accidently ran that binary.
2022-12-23 10:22:34 <KipIngram   > Because as soon as I re-assembled last night it was gone.
2022-12-23 10:23:15 <KipIngram   > Anyway, NOW I can pass it any N I want, and it will let me type up to N-1 characters with no misbehavior, and then won't let me type anymore (it forces room for a null at the end).
2022-12-23 10:24:07 <KipIngram   > So if I pass 200 in it lets me type 199 characters.  After that I can moe the cursor around and I can backspace characters away, anywhere within the string, and THEN I can type more.
2022-12-23 10:24:14 <KipIngram   > Now it seems to be working perfectly.
2022-12-23 10:25:22 <KipIngram   > I don't think the original problem had anything to do with that 0x100 -> 0100 because when I took the x back out and tried again the problem didn't come back.
2022-12-23 10:25:41 <KipIngram   > I just misinterpreted when I put the x in and it "fixed it".
2022-12-23 10:25:49 <KipIngram   > I think what FIXED it was making a new binary.
2022-12-23 10:26:42 <KipIngram   > I "fixed" it the first time, a couple of weeks ago after I'd been diddling with the source, by getting one version back (pre those changes) from my version control.
2022-12-23 10:28:18 <KipIngram   > None of which means I don't have a bug in my code, but I can't see one now.
2022-12-23 10:28:56 <KipIngram   > That EXPECT stuff wound up being one of the most involved parts of this system - I really should spend some time seeing if I can simplify it.
2022-12-23 10:29:22 <KipIngram   > It's exactly the part, though, that I mentioned re-writing the other day when we were talking about having too many items on the stack.
2022-12-23 10:34:15 <KipIngram   > veltas: I think your definition of "maintainable" is pretty good.  Nice common sense definition.
2022-12-23 10:35:39 <KipIngram   > I would add that the criterion should be based on the person doing the maintenance being reasonably skilled.  I don't think it's fair to try to demand that "anyone vaguely familiar with the language" be able to readily maintain the code.
2022-12-23 10:35:53 <KipIngram   > I think there's an enormous range of quality among programmers.
2022-12-23 10:36:34 <thrig       > or knows of the particular software, even if you do know the language
2022-12-23 10:41:27 <Zarutian_iPad> KipIngram: plus the time they actually get to mantain the software
2022-12-23 10:43:28 <KipIngram   > Yeah, definitely.  Work takes time; sometimes executives think they can just change that by demanding it, which is kind of irrational.
2022-12-23 10:43:56 <thrig       > "but you can multitask"
2022-12-23 10:44:33 <KipIngram   > Oh, we all know how that game goes.  The people who wind up getting the kudos are the ones who will give up all of their personal time in response to such situations.
2022-12-23 10:44:48 <KipIngram   > That's what "multitask" means in that context.
2022-12-23 10:45:22 <thrig       > the web guy at the public university on the public university salary was unimpressed with the request to multitask
2022-12-23 10:45:54 <Zarutian_iPad> or do like one guy I know, bill the hours to a project the boss does nor know of or control. or just bill it to “admin”
2022-12-23 10:46:09 <KipIngram   > Well, if *everyone* is unimpressed, then the problem might eventually resolve itself.  But usually there's someone willing to have no life, somewhere in the organization.
2022-12-23 10:46:27 <KipIngram   > Right - the same issue applies to budgeting for sure.
2022-12-23 10:46:31 <thrig       > unions or regulations might help there
2022-12-23 10:47:18 <Zarutian_iPad> and if you want to get rid of said boss, make it look like he is embezzling via that project
2022-12-23 10:47:25 <KipIngram   > :-)
2022-12-23 10:48:01 <KipIngram   > thrig: The problem there is that sometimes those regulations run to excess; it's pretty hard to find the right balance.
2022-12-23 10:48:18 <KipIngram   > Sometimes you get regulations limiting the width of paintbrush painters can use, to force lower productivity.
2022-12-23 10:48:33 <KipIngram   > My only point being that sometimes that technique goes too far and becomes abusive itself.
2022-12-23 10:48:56 <KipIngram   > Or becomes violent.
2022-12-23 10:49:05 <thrig       > in theory that's what public debate among an educated populace would help resolve
2022-12-23 10:49:13 <KipIngram   > But no system is perfect, I guess.
2022-12-23 10:49:20 <Zarutian_iPad> “educated”
2022-12-23 10:49:31 <KipIngram   > In theory.  But you need that educated populace first.
2022-12-23 10:49:41 <KipIngram   > I don't see one around me these days.
2022-12-23 10:49:46 <eris[m]     > education is a fun word
2022-12-23 10:50:21 <eris[m]     > did you know the first schooling system was modelled on the alchemical process?
2022-12-23 10:50:30 <eris[m]     > progressive refinement of a resource
2022-12-23 10:50:32 <KipIngram   > No, I did not - that sounds fun.
2022-12-23 10:51:12 <KipIngram   > I think the problem, in a lot of domains, is that people focus only on the end result, and whether it's good for them or not, without applying any values / principles to the means being employed.
2022-12-23 10:51:28 <KipIngram   > Some things are wrong, even if they're good for you; some things are right, even if they aren't.
2022-12-23 10:51:29 <eris[m]     > one of my favourite philosophers likened education to commodity production
2022-12-23 10:52:13 <eris[m]     > he was highly involved in liberation theology in south america and part of his goal was to identify and establish a better structure than schooling
2022-12-23 10:52:14 <thrig       > the Prussian education model (which you may have experience with) was to turn out good workers
2022-12-23 10:52:27 <KipIngram   > Sometimes it's you that needs to change - maybe the skills you have just no longer offer value to the economy.
2022-12-23 10:52:46 <KipIngram   > Imposing rules on the economy to let you make out ok anyway probably isn't a good thing.
2022-12-23 10:53:07 <eris[m]     > he noted that education pits oppressed people against themselves
2022-12-23 10:53:40 <KipIngram   > I suppose.  Our system is based on competition.
2022-12-23 10:54:08 <eris[m]     > of course, trying to help a post colonial continent, you don't want that sort of competition
2022-12-23 10:54:40 <eris[m]     > education quickly becomes a self reinforcing system
2022-12-23 10:54:47 <eris[m]     > it acts as a barrier to entry
2022-12-23 10:55:33 <KipIngram   > And I'm not saying we should never do those things.  I kind of worry that we're going to automate away most of our economy's jobs, and that's going to cause trouble.  It directly undermines the current "mechanism" of how we distribute wealth to our people.  Something will have to give.
2022-12-23 10:55:36 <eris[m]     > those who could afford education were granted greater privileges and thus greater ability to afford it, creating a rapidly increasing gap
2022-12-23 10:55:48 <KipIngram   > We either need to have rules to prevent that from happening, or change how we distribute the wealth.
2022-12-23 10:56:51 <eris[m]     > the guy im talking about is quite interesting because he's utterly unconcerned with economics, but rather social organisation
2022-12-23 10:57:10 <KipIngram   > Oh, I think both things are important.
2022-12-23 10:57:15 <KipIngram   > What's this guy's name?
2022-12-23 10:57:46 <eris[m]     > ivan illich
2022-12-23 10:58:08 <eris[m]     > wrote 'unschooling society', 'tools for conviviality' and 'medical nemesis'
2022-12-23 10:58:13 <eris[m]     > i reccomend the middle one
2022-12-23 10:58:13 <KipIngram   > I think he's right to point out the need for focus in that direction - it's easy to gauge how well the economy is working purely in terms of how many resources it produces.  But it also has a second purpose, and that's working out how those resources get shared.
2022-12-23 10:58:21 <KipIngram   > If you break either one of those things, it's broken.
2022-12-23 10:58:36 <KipIngram   > I will take a look.
2022-12-23 10:58:58 <eris[m]     > there's a pdf available online
2022-12-23 10:59:22 <thrig       > sharing won't happen if the looters do not want it to
2022-12-23 10:59:33 <KipIngram   > I don't think any economic system can solve "all of the problems."  I think capitalism is great for achieving the resource production goal, but it leaves "holes" that people can fall into.
2022-12-23 10:59:57 <Zarutian_iPad> this must be more USA centric problems that I am too much of an outsider to get
2022-12-23 11:00:08 <KipIngram   > It could be.
2022-12-23 11:00:35 <eris[m]     > i'm in the UK :)
2022-12-23 11:00:41 <KipIngram   > These days I believe that we should have a *reasonable* system to keep people from falling into utter poverty.
2022-12-23 11:00:55 <eris[m]     > wealth disparity is a strong force even with the UK's social protections
2022-12-23 11:01:01 <KipIngram   > I don't think any attempt to "equalize everything" can work - that will break the resource production function.
2022-12-23 11:01:06 <Zarutian_iPad> take for example unions. In most sane contries they are not company spefic but industry spefic
2022-12-23 11:01:19 <KipIngram   > But some redistribution, to keep the world humane to people, seems right to me.
2022-12-23 11:01:45 <KipIngram   > At least some of our unions work that way.
2022-12-23 11:02:01 <KipIngram   > Like we've got United Auto Workers, which is auto industry wide.
2022-12-23 11:02:14 <KipIngram   > The Teamsters, which has to do with transport.
2022-12-23 11:02:33 <KipIngram   > One problem we've had here is that the unions have sometimes gotteen infested by organized crime.
2022-12-23 11:02:36 <Zarutian_iPad> I though Teamsters were just generic union
2022-12-23 11:02:57 <KipIngram   > I may be wrong, but I thought they were truck drivers and other cargo transport related people.
2022-12-23 11:03:27 <KipIngram   > I only know about them because they were one of the ones that at times had some crime influence.
2022-12-23 11:03:33 <KipIngram   > Or at least allegedly did.
2022-12-23 11:04:03 <eris[m]     > KipIngram: did you know one organised crime ring has a union for it's members? google 'the police' :D
2022-12-23 11:04:07 <KipIngram   > But organized crime will stick its fingers anywhere money moves around.
2022-12-23 11:04:18 <KipIngram   > lmao...
2022-12-23 11:04:39 <eris[m]     > police unions do a great deal to help officers avoid accountability for crime
2022-12-23 11:04:49 <KipIngram   > There's a book on the history of US organized crime, called "Five Families."  Some of it is pretty fascinating.
2022-12-23 11:04:58 <KipIngram   > I was impressed by the "breadth" of their activities.
2022-12-23 11:05:14 <eris[m]     > sex, drugs, rock and roll?
2022-12-23 11:05:14 <KipIngram   > And frankly with how hard some them seemed to work.
2022-12-23 11:05:35 <KipIngram   > EVERYTHING, almost.  Hot dog sales at Coney Island - even little stuff like that.
2022-12-23 11:05:40 <Zarutian_iPad> eris: which is quite stupid of them as there are lets say extra legal means of recurse against such officers
2022-12-23 11:05:52 <KipIngram   > Literally anywhere there's money, they'd look for a way to get into.
2022-12-23 11:05:57 <eris[m]     > aye
2022-12-23 11:06:16 <eris[m]     > the internet age has boosted the power of the public, to a degree
2022-12-23 11:07:25 <KipIngram   > Illich looks interesting.
2022-12-23 11:10:29 <KipIngram   > Oh, by the way, Chuck recommends against using, or for that matter even having, DEPTH.
2022-12-23 11:10:38 <eris[m]     > aye
2022-12-23 11:10:41 <KipIngram   > Partly that tied to his "never have much on the stack" philosophy.
2022-12-23 11:10:53 <KipIngram   > And his circular stacks further negate its relevance.
2022-12-23 11:11:09 <KipIngram   > What's on the stack is what you know is on the stack, end of story.
2022-12-23 11:11:19 <eris[m]     > i wonder if theres another unexplored avenue of forth
2022-12-23 11:11:44 <KipIngram   > I'm pretty sure I am going to use the circular stack idea.
2022-12-23 11:12:03 <KipIngram   > And these block RAMs come in fairly good size chunks - probably more than is useful for a stack.
2022-12-23 11:12:41 <KipIngram   > So what I think I'll do is allocate a block ram for a stack, and it will represent some number of stacks.  The pointer into the block ram will have its least significant bits behave as a circular counter.
2022-12-23 11:13:08 <KipIngram   > So, set the pointer to choose one of the stacks, and then just go; anything you do will just rotate you around in that one.  The upper bits will never change unless you change them.
2022-12-23 11:13:20 <KipIngram   > So power of two size stacks.
2022-12-23 11:13:32 <KipIngram   > I lean toward 32 right now.
2022-12-23 11:13:53 <KipIngram   > Since I found last night that my existing system's return stack seems to be right around 16.
2022-12-23 11:14:07 <KipIngram   > Max used.
2022-12-23 11:14:39 <KipIngram   > The SIMPLEST way to make such a stack is to cache nothing in registers - just move the pointer and let the top two items be "addressed" via the two ports.
2022-12-23 11:15:08 <KipIngram   > And each instruction could apply a small offset to the pointer, as well as command it to increment or decrement at the end of the instruction.
2022-12-23 11:15:47 <KipIngram   > Having registers to cache the top item or the top two items complicates the design a fair bit, but would be faster.  I can't tell quite yet whether that "faster" actually pays off or not.
2022-12-23 11:16:30 <thrig       > 16 hours of developer time for 16 nanoseconds of runtime
2022-12-23 11:16:43 <KipIngram   > :-)
2022-12-23 11:17:02 <thrig       > maybe that day trading really needs those 16 nanoseconds, who knows?
2022-12-23 11:17:09 <KipIngram   > Well, there is that fixed limit on clock speed.  I may find that even without the cached TOS I can fit within that.
2022-12-23 11:17:18 <KipIngram   > If so, then I shouldn't complexify it.
2022-12-23 11:18:11 <KipIngram   > Oh, those guys CLAIM they need everything.
2022-12-23 11:18:21 <KipIngram   > I have no basis for disagreeing with them.
2022-12-23 11:18:27 <eris[m]     > 'it adds up'
2022-12-23 11:18:34 <KipIngram   > Though I don't know that I've ever heard anyone fret over nanoseconds.
2022-12-23 11:18:47 <thrig       > day traders...
2022-12-23 11:19:08 <KipIngram   > Well, I'm sure I've heard them talk about milliseconds, and maybe I've heard of microseconds.
2022-12-23 11:21:52 <joe9        > sorry, just logged in. Can aynone paste the back log for the nano seconds stuff? it is an interesting topic.
2022-12-23 11:22:09 <eris[m]     > kip: I think the conditional returns style that you used a lot more than me is possibly part of another direction of forth
2022-12-23 11:22:34 <eris[m]     > how did you make it so that fallthrough could happen between words? i forgot
2022-12-23 11:22:51 <eris[m]     > oh wait
2022-12-23 11:22:55 <eris[m]     > no, i remember
2022-12-23 11:24:02 <eris[m]     > https://arogozhnikov.github.io/2022/11/29/delimiter-comes-first.html this could apply to forth
2022-12-23 11:54:08 <KipIngram   > eris: I've thoroughly enjoyed those conditional returns.  They "feel right" to me - feel natural.
2022-12-23 11:54:58 <eris[m]     > mhm
2022-12-23 11:55:07 <KipIngram   > And the way I do loops obviates the need to specify a jump target in the source.  A jump offset still gets *compiled*, but it's determined automatically.
2022-12-23 11:55:36 <KipIngram   > In the hardware version, I intend to eliminate even that - the hardware will recognize those points and keep them in an internal stack.
2022-12-23 11:56:11 <MrMobius    > Will you have subtract or leave it out like the previous ones?
2022-12-23 11:56:23 <KipIngram   > I have it in right now.
2022-12-23 11:56:51 <KipIngram   > But, it's purely optional.
2022-12-23 11:57:45 <KipIngram   > Anyway, the way this hardware will work out, the code will contain literal data, and it will contain call targets.  But otherwise only opcodes.
2022-12-23 11:58:30 <KipIngram   > I'd make a decision about - after I see how much logic it adds to the ALU, I guess.
2022-12-23 11:58:51 <KipIngram   > And I had "room for it" in that 16-count of TOS next values.
2022-12-23 11:59:36 <KipIngram   > You know, one thing about the standard appraoch to ALUs bugs me a little.  Usually you calculate everything - every function of the top to stack items, and the instruction just "selects one."
2022-12-23 11:59:54 <KipIngram   > But that's clealry wassteful of power.  I'll be throwing away around 15/16 of the work the ALU does each cycle.
2022-12-23 12:00:44 <KipIngram   > Although, some things will be shared, I guess; like xor can come out of the middle of +.
2022-12-23 12:01:01 <KipIngram   > There will probably be a couple other instances like that.
2022-12-23 12:01:40 <KipIngram   > But in any case, that design does a lot of work it never uses.
2022-12-23 12:07:06 <MrMobius    > KipIngram: you could check out the Saturn processor in HP calculators. It's register based and oriented toward decimal floating point but it was designed for an OS with a lot of Forth like qualities. Might be good inspiration
2022-12-23 12:09:11 <MrMobius    > OS is written in SysRPL which is threaded addresses and stack based
2022-12-23 12:44:36 <KipIngram   > Oh, that is a good idea.  I have felt at times like "raiding the HP41 instruction set."
2022-12-23 12:44:46 <KipIngram   > store/recall arithmetic, etc.
2022-12-23 12:45:06 <KipIngram   > The HP instruction set offers easy access (swap, recall, store) to the entire four element stack.
2022-12-23 12:45:37 <KipIngram   > And also can use any stack item as an indirect RAM address.
2022-12-23 12:46:09 <KipIngram   > It also had instructions for "decrement and skip is equal" and " increment and skip if greater" operations.
2022-12-23 12:46:27 <KipIngram   > So, a slightly different conditional mechanism, in addition to conditional jumps.
2022-12-23 12:47:07 <KipIngram   > But studying the architecture in a more general way definitely might give me ideas.
2022-12-23 12:49:57 <KipIngram   > I think the return stack and the loopback stack can be parallel stacks, run by the same stack pointer.  We all know what the return stack holds.
2022-12-23 12:50:22 <KipIngram   > The loopback stack will hold the fist instruction address of the word *being executed now*, so that a "me" word can jump back there.
2022-12-23 12:50:47 <KipIngram   > Then the :. word will allow overwriting that value with the "IP now," so I can jump back to the middle of a definition if I want to.
2022-12-23 12:51:27 <KipIngram   > But in any case, the two stacks actually push and pop together, and it would be "correct" for them to double pop at the same time too - otherwise I couldn't double return "over" a me loop.  If they use the same pointer I can.
2022-12-23 12:51:43 <KipIngram   > So I think they're the same kind of stack; just with a difference in the data they store.
2022-12-23 12:52:40 <KipIngram   > So, return stack stores "where we can from"; loop stack stores "where we went to."
2022-12-23 12:53:08 <KipIngram   > But calls always push both of them, and returns always pop both of them.
2022-12-23 12:53:33 <KipIngram   > So it's almost like that's not a new stack - it's just an "enhanced return stack."
2022-12-23 12:57:44 <KipIngram   > The "frame" and "exception" features will each require small hidden stacks.  All the programmer knows about those is that if they open a frame of either type, the previous one is remembered "somehow."
2022-12-23 12:58:15 <KipIngram   > But now that I'm thinking about it, those may wind up using the return stack pointer too.
2022-12-23 12:59:15 <KipIngram   > Historically I save those values when necessary *on the return stack*.  But I'd decided to use separate small stacks here to keep me from needing to push a bunch things onto the return stack on a single cycle.
2022-12-23 12:59:32 <KipIngram   > I realize now that splitting them out like that raises some potential issues.
2022-12-23 12:59:57 <KipIngram   > So it may turn out they need to be "tied to" the return stack as well.
2022-12-23 13:01:15 <KipIngram   > Like if I use |} to "leap out" of a deep call stack, like I do in FIND, there might have been frames opened by the words in between - those all need to get discarded.
2022-12-23 13:02:38 <KipIngram   > I think it was a misstep to consider making them separate stacks - I don't think there actually IS a push / pop conflict here.
2022-12-23 13:03:14 <KipIngram   > If I'm running the { instruction, then I am NOT doing a a call, or a return, or a >r or a r> or anything else that involves the return stack.  So it is perfectly well avaialble to receive the prior frame pointer.
2022-12-23 13:03:39 <KipIngram   > I should stop calling it "frame," since I'm no longer planning to index into the data stack.
2022-12-23 13:03:52 <KipIngram   > What it really does is just "remember the current data stack pointer."
2022-12-23 13:04:14 <KipIngram   > But really all { will do will be to push SP onto the return stack.
2022-12-23 13:04:29 <KipIngram   > sp@ >r
2022-12-23 13:04:45 <KipIngram   > and } just does r> sp!
2022-12-23 13:05:15 <KipIngram   > And here we see how having stack items cached in registers becomes a complication - if I do that, then those registers have to be reloaded when I do sp!
2022-12-23 13:05:38 <KipIngram   > But if I'm not caching, then sp! just does TOS->SP and that's the end of it.
2022-12-23 13:06:21 <KipIngram   > So }, without data stack indexing, is just sp! from the return stack.
2022-12-23 13:06:49 <KipIngram   > And { is just sp@ to the return stack.
2022-12-23 13:07:24 <KipIngram   > Ah, that really means I don't need sp@, sp!, rp@, rp! at all.
2022-12-23 13:07:43 <KipIngram   > I have { and }.  So if I need to sp!, I can just >r }
2022-12-23 13:08:04 <KipIngram   > And that's better than the other way around, because sp! isn't used very often, but } will be used more often.
2022-12-23 13:10:59 <KipIngram   > {| will save an "exception pointer" register to the return stack, and load the current RP into that register.  |} reverses that - just pops return stack into that exception pointer.  In that case it's necessary to have a register in order to be able to undo it regardelss of what has happened to the return stack in between.
2022-12-23 13:11:27 <thrig       > some pointers are more exceptional than others?
2022-12-23 13:11:40 <KipIngram   > "Exception" isn't the best word, really.
2022-12-23 13:12:30 <KipIngram   > The way I use it in FIND is that a {| in FIND itself marks that definition level.  There is also a |} in FIND that will eventually get executed if the search fails.
2022-12-23 13:12:45 <thrig       > OTHERWISE
2022-12-23 13:13:01 <KipIngram   > But if the search succeeds, and I know that like four or five levels deeper in the call tree, I can execute a |} down there, and then when I encounter a return it returns me FROM FIND, basically.
2022-12-23 13:13:18 <KipIngram   > So it's how I bypass all the middle definitions when the search has been successful
2022-12-23 13:13:19 <vms14       > KipIngram: I've made a rudimentary debugger
2022-12-23 13:13:20 <vms14       > xD
2022-12-23 13:13:39 <KipIngram   > It's faster, and it also simplifies all those middle definitions by making them not even have to deal with success.
2022-12-23 13:13:49 <vms14       > it's not a call to a repl like last time, but a function that reads from stdin and has some options
2022-12-23 13:13:51 <KipIngram   > They are "written to fail," so to speak.
2022-12-23 13:13:57 <vms14       > next break run and eval
2022-12-23 13:14:01 <KipIngram   > Neat.
2022-12-23 13:14:17 <vms14       > you can set a breakpoint into a word, it will stop there, or call next to execute one by one
2022-12-23 13:14:28 <vms14       > it's a bit rudimentary, but I hope it helps me
2022-12-23 13:14:32 <KipIngram   > In theory that's the "minimum necessary."  Just stop what you're doing and give the user an opportunity to look at things.
2022-12-23 13:14:44 <KipIngram   > Then you might add all kinds of bells and whistles to make it "easier" to look at things.
2022-12-23 13:14:55 <KipIngram   > But you CAN look at everything with @ if you want to.  :-)
2022-12-23 13:14:58 <vms14       > I find a bit hard to write any non trivial program, so I wanted something
2022-12-23 13:15:19 <vms14       > even the snake game was giving me troubles xD
2022-12-23 13:15:39 <vms14       > and crc I choose to follow your approach of not having packages
2022-12-23 13:15:40 <thrig       > AST. Very Dangerous. You go first.
2022-12-23 13:16:11 <vms14       > now "immediate" words can be aware of each other without having to hardcode them
2022-12-23 13:16:27 <KipIngram   > What do you mean by "aware of each other"?
2022-12-23 13:16:37 <vms14       > there's no compiling time, but words that read from the source code can choose to evaluate code they read
2022-12-23 13:16:57 <vms14       > KipIngram: for example : and [
2022-12-23 13:16:57 <KipIngram   > BTW, vms14, my recent reading implies that IMMEDIATE leads to cross-compile complications.
2022-12-23 13:17:12 <vms14       > : needs to be aware of " and [
2022-12-23 13:17:15 <vms14       > [ builds a list
2022-12-23 13:17:16 <KipIngram   > A smoother way is to avoid trying to have a single bit of code that "interprets or compiles."
2022-12-23 13:17:30 <KipIngram   > Have an interpret word, and a compile word, and move back and forth between them, instead.
2022-12-23 13:17:38 <vms14       > if : finds a [ executes it and pushes that list as the contents of a word
2022-12-23 13:17:42 <KipIngram   > Apparently that makes the cross compile task more straightforward.
2022-12-23 13:17:44 <vms14       > same for "
2022-12-23 13:17:52 <KipIngram   > That's just word of mouth right now, though - I haven't actually explored it.
2022-12-23 13:18:27 <KipIngram   > In the other way, [ would just exit the compile loop, returning you to the interpret loop.
2022-12-23 13:18:29 <vms14       > I had to hardcode every one of those words because having packages meant I have to traverse all the packages for every word so I know if they are immediate
2022-12-23 13:18:32 <KipIngram   > ] starts the compile loop.
2022-12-23 13:18:43 <vms14       > there's no compiling time :/
2022-12-23 13:18:57 <vms14       > only execution time, and read time is when words read from the code
2022-12-23 13:19:14 <KipIngram   > And the compile loop has a different order of word search - it first searches a "compiler word list."
2022-12-23 13:19:34 <vms14       > but still there's a hash with immediate words, so the reading words can use that hash to check if a word is an "immediate" one
2022-12-23 13:19:40 <KipIngram   > So one wouldn't have thought of this until after inventing the idea of word lists.
2022-12-23 13:19:50 <KipIngram   > Which may be how we wound up with a merged loop in the first place.
2022-12-23 13:20:05 <KipIngram   > Also, at the time it was all invented Chuck probably wasn't thinking about cross-compile.
2022-12-23 13:20:41 <vms14       > I have to learn forth some day so I can steal more concepts from it
2022-12-23 13:20:43 <KipIngram   > A hash?
2022-12-23 13:20:49 <vms14       > for now my lang has nothing to do with forth
2022-12-23 13:20:58 <KipIngram   > Does that mean immediate words are forced to have a name that yields the right kind of hash?  Surely not?
2022-12-23 13:21:10 <vms14       > KipIngram: a hash with names of "immediate" words and the number of values they return
2022-12-23 13:21:17 <Zarutian_iPad> vms14: do like I did, port eForth to some fantasy computer
2022-12-23 13:21:31 <vms14       > for example : has a 0 as does not return nothing
2022-12-23 13:21:40 <KipIngram   > Ok, so a TABLE of immediate word info, that you index with a hash.
2022-12-23 13:21:44 <thrig       > wasn't eforth ported from a fantasy cpu?
2022-12-23 13:22:01 <vms14       > [ quotes everything by default, but can look at that hash to see if a word is "immediate"
2022-12-23 13:22:24 <KipIngram   > Yes, ok.
2022-12-23 13:22:28 <vms14       > if it is, it will know how many items that word returns, so it will execute and take that number of items
2022-12-23 13:22:46 <vms14       > still I'd like some sort of nested colon words like you have
2022-12-23 13:22:50 <KipIngram   > Well, I think the whole hash thing is nifty, but just be aware that you're probably using a bunch of memory to do it.  The idea wouldn't carry over well to a small micro.
2022-12-23 13:22:58 <KipIngram   > With low RAM resources.
2022-12-23 13:23:03 <vms14       > for now if [ or : find another : they just execute it and that's all
2022-12-23 13:23:09 <Zarutian_iPad> thrig: might be but I do recall the e meant education as in educating someone on how forth works just by reading the assembly (which used a few simple macros btw)
2022-12-23 13:23:31 <vms14       > also I have troubles with [ as it's a read time operation and I usually want to delay the insertion of items
2022-12-23 13:23:55 <KipIngram   > Your hash table is sparse by definition, since no word that is NOT immediate will find anything there, and yet those words do make indices.
2022-12-23 13:23:59 <vms14       > I can make another word that just executes the elements, also put directives
2022-12-23 13:24:09 <thrig       > \ This project derives from a simulator for a [CPU written in VHDL][], designed
2022-12-23 13:24:14 <KipIngram   > So all of the table entries that correspond to non-immediate words are empty.
2022-12-23 13:24:15 <vms14       > KipIngram: immediate words in my lang are actually kind of a joke
2022-12-23 13:24:40 <vms14       > they're just words that read on the code and do something that should be done at read time
2022-12-23 13:25:10 <vms14       > for example [ builds a list, it needs to be executed from : or also [ to build the list and push it into the contents
2022-12-23 13:25:17 <vms14       > : word [ 1 2 3 ] ;
2022-12-23 13:25:29 <vms14       > now word will push that list when executed
2022-12-23 13:25:45 <vms14       > the problem is the [ 1 2 3 ] list is being built even before word is defined
2022-12-23 13:26:09 <Zarutian_iPad> thrig: sure, but I found the assembler quite readable (read the x86 assembler) and ported it into js (just using it as an assembler though)
2022-12-23 13:26:23 <vms14       > I can have another word for building lists that does not read from the code
2022-12-23 13:27:06 <vms14       > but I'd like to have something to defer execution of those kind of words
2022-12-23 13:28:10 <vms14       > the lang is getting less crappy with every iteration :D
2022-12-23 13:28:24 <vms14       > still sucks a lot, but at least now I have some sort of debugger xD
2022-12-23 13:28:39 <vms14       > I hope is actually useful and serves me to understand what is wrong in my code
2022-12-23 13:29:05 <vms14       > but that read time stuff is something I want to improve
2022-12-23 13:29:20 <vms14       > mainly to delay execution those words or something alike
2022-12-23 13:30:26 <vms14       > still the debugger won't iterate on words like do.times and any loop
2022-12-23 13:30:48 <vms14       > it will just execute them, but can't be hooked inside the loop
2022-12-23 13:31:42 <vms14       > well maybe if I just call the debugger inside the loop it's fine enough
2022-12-23 13:31:46 <vms14       > xD
2022-12-23 13:32:19 <vms14       > ah nope, it needs to read the source code, and inside the loop the code is being read already
2022-12-23 13:33:33 <vms14       > KipIngram: what fancy stuff has a debugger
2022-12-23 13:33:41 <vms14       > more than printing values and stuff
2022-12-23 13:35:01 <vms14       > I can't come back to something I've already executed, and I can't stop a loop, I should try to provide those two features
2022-12-23 13:35:51 <vms14       > for a loop I could trigger the repl in every iteration, but the code of a loop is not available
2022-12-23 13:42:32 <vms14       > brb
2022-12-23 13:56:06 <KipIngram   > Well, I think the way I should go on this is to just implement the stacks without top item register caching.  That's easy and simple.  And it will work - just perhaps not at the fastest possible clock rate.  Then I can look at what I get and see if it seems important to me to do better.
2022-12-23 13:57:40 <KipIngram   > And I like this "small circular stack record" with some number of such records in the block RAM.
2022-12-23 13:59:31 <KipIngram   > I'll go with 32 for both data and return stacks.
2022-12-23 13:59:52 <MrMobius    > KipIngram: looking at the HP-41 is a good idea. the Saturn processor I mentioned is the successor used in the HP-28 and HP-48 and i a lot more advanced
2022-12-23 14:00:02 <KipIngram   > Oh, I did the same depth check on my data stack that I did for the return stack last night, on the x86 Forth; looks like it has  used 18 stack cells.
2022-12-23 14:00:22 <KipIngram   > Yeah, I will check out all of them and see how it evolved.
2022-12-23 14:00:32 <KipIngram   > The 41 just happens to be the one I was most familiar with.
2022-12-23 14:00:44 <KipIngram   > I later owned a 42S that I really liked, from a software perspective.
2022-12-23 14:00:50 <KipIngram   > It had native support for complex arithmetic.
2022-12-23 14:01:19 <KipIngram   > But the mechanical implementation wasn't as nice - they had a better LCD screen, but had moved to cheaper, more "chicklet style" keys.
2022-12-23 14:01:29 <KipIngram   > Couldn't ever use it as FAST as I could the 41.
2022-12-23 14:01:55 <KipIngram   > And I didn't get it until after college, so I never had as much opportunity to really suck the marrow out of it like I did on the 41.
2022-12-23 14:02:28 <KipIngram   > My wife used (in college, and still uses) an HP48.  A G in college; these days an X.
2022-12-23 14:02:38 <KipIngram   > That one will draw graphs and stuff.
2022-12-23 14:02:57 <MrMobius    > the 48GXs are worth a lot now
2022-12-23 14:03:21 <KipIngram   > None of them are particularly cheap - they're all kind of "collectors items."
2022-12-23 14:03:30 <MrMobius    > I got a 48G on craigslist for $20 and have a 50G which is a 49G running in emulation
2022-12-23 14:03:37 <KipIngram   > I've looked at 41's on ebay from time to time, but never felt like spending that much.
2022-12-23 14:04:11 <KipIngram   > Every time I'm tempted, I remind myself that I don't really USE a calculator anymore.  Not really - not in any serious way.
2022-12-23 14:04:27 <KipIngram   > My 42S emulator on my phone is really more than enough to cover my present needs.
2022-12-23 14:04:40 <KipIngram   > It's neat - it looks JUST LIKE the 42S.
2022-12-23 14:04:59 <KipIngram   > Gives me a little "taste of my past."
2022-12-23 14:05:13 <KipIngram   > I've got a 41 emulator on there too, but I usually use the 42.
2022-12-23 14:05:17 <MrMobius    > I dont use my calculators very much which is why I havent gotten one of the modern DM-42s
2022-12-23 14:05:52 <MrMobius    > meh, I stay away from all the emulators. the killer feature of those calculators is the programming which is atrocious in any form on a smart hone
2022-12-23 14:06:35 <MrMobius    > they make a DM-41 too btw if you ever change your mind about the HP-41 :P
2022-12-23 15:06:18 <KipIngram   > Ugh, that DM41 has a landscape layout.
2022-12-23 15:06:28 <KipIngram   > DM42S looks interesting, though.
2022-12-23 15:06:38 <KipIngram   > I haven't had any trouble programming the emulator, actually.
2022-12-23 15:06:45 <KipIngram   > But that's exactly the feature I don't use anymore.
2022-12-23 15:06:55 <KipIngram   > I just use it for small arithmetic jobs.
2022-12-23 15:07:11 <KipIngram   > Oh, there's a 41X.
2022-12-23 15:08:02 <KipIngram   > I'm betting they don't use the keystroke style of the original 41, though, and that was where it really shone.
2022-12-23 15:08:20 <KipIngram   > I could hold it in my left hand and "touch type" on it with my right hand, and I was FAST.
2022-12-23 15:14:56 <KipIngram   > I like it that it shows two stack items instead of one.
2022-12-23 15:15:14 <KipIngram   > The 41 showed one; the 42S showed more, and I liked it then too.
2022-12-23 15:15:17 <thrig       > handy when you want to know what * will act on
2022-12-23 15:15:46 <KipIngram   > Geez - that's nice.
2022-12-23 15:15:51 <KipIngram   > https://www.swissmicros.com/product/dm41x
2022-12-23 15:16:42 <KipIngram   > Wow, the DM42S give 34 decimal digits of precision.
2022-12-23 15:16:45 <KipIngram   > Man.
2022-12-23 15:17:15 <KipIngram   > Those are both awfully nice.
2022-12-23 15:17:19 <thrig       > handy if you need to hit the right atom somewhere past the pluto orbit
2022-12-23 15:17:58 <KipIngram   > Exactly!
2022-12-23 15:18:37 <KipIngram   > The most recent calculator I bought is an after-market modified one.  It's based on an HP financial calculator, but it's been reprogrammed, and the keys relabeled, to yield a high end scientific functionality.
2022-12-23 15:18:44 <KipIngram   > I'll have to go look at it to get the number right.
2022-12-23 15:18:52 <thrig       > https://www.jpl.nasa.gov/edu/news/2016/3/16/how-many-decimals-of-pi-do-we-really-need/
2022-12-23 15:19:54 <KipIngram   > WP-34S.
2022-12-23 15:20:15 <KipIngram   > https://commerce.hpcalc.org/34s.php
2022-12-23 15:20:48 <KipIngram   > thrig: Yeah, at some point "number of digits" just becomes a vanity thing.
2022-12-23 15:21:57 <KipIngram   > I wasn't aware of those Swiss Micro products.  I may have to get a 41X at some point, just for nostalgia's sake.
2022-12-23 15:22:55 <KipIngram   > There's a book, by a guy named Ball, called "Algorithms for RPN Calculators."  Has a particular emphasis on astronomy and spherical geometry / trigonometry.  I learned a lot from it back in the day.
2022-12-23 15:25:39 <KipIngram   > Oh, Hmmm.  |} instruction will be a little tricky, I think.  {| will save the exception pointer on the return stack (easy) and save current RP in the exception pointer (easy).
2022-12-23 15:26:15 <KipIngram   > But |} should restore the return stack pointer from the exception pointer, and then pop the old exception pointer value from the return stack.
2022-12-23 15:26:35 <KipIngram   > Those two things don't work in parallel, and they won't be possible to do in a single cycle.
2022-12-23 15:27:54 <KipIngram   > That's what initially led me to consider a small dedicated internal stack.  If that exists, then {| will push exception pointer to that stack and copy return stack pointer to exception pointer.  Then |} will move exception p oitner to return stack pointer and pop the old value back out of the internal stack.
2022-12-23 15:27:59 <KipIngram   > Those are easy to do in one cycle.
2022-12-23 15:28:44 <KipIngram   > I think that'll be the way to do that one.
2022-12-23 15:29:35 <KipIngram   > I can't think of a time I'd ever want to "double return" out of a {| ... |} and thus never execute the |}.
2022-12-23 15:33:23 <KipIngram   > Hmmm.  I don't see the "alpha" key on the DM41X.
2022-12-23 15:33:57 <KipIngram   > And the "User" control.
2022-12-23 15:34:16 <KipIngram   > Those were on little momentary toggle switches right under the LCD on the 41CV.
2022-12-23 15:35:03 <KipIngram   > Oh,  it has an entirely different key layout.
2022-12-23 15:38:48 <KipIngram   > Well, "noticeably" different.
2022-12-23 15:41:21 <KipIngram   > But... do I want it $250 bad?  Especially after just dropping almost $300 on that FPGA board.
2022-12-23 15:42:06 <KipIngram   > So, how fast is DDR RAM on computers these days?
2022-12-23 15:44:07 <KipIngram   > So when they give the speed of a DDR stick as, say, 4800 MHz, does that mean you get a full width read every cycle at that rate?
2022-12-23 15:44:33 <KipIngram   > That seems not right - that would be 200 ps.
2022-12-23 15:46:17 <KipIngram   > Ok - I saw an article that implies 10-20 ns, and I assume that's a burst rate.
2022-12-23 15:49:44 <KipIngram   > In any case, it's slower than a cycle in this FPGA may come in at.
2022-12-23 15:53:14 <KipIngram   > Oh.  Hmmmm.  If I don't cache at least TOS in a register, then I have no way of getting a RESULT out of { ... } and {| ... |} blocks.  Both of those restore the RAM stack to some earlier state, but I rely on TOS being in a register and unaffected by that.
2022-12-23 15:54:12 <KipIngram   > I guess that's ok, though - it would be trying to restore TOS on a big change like that that caused the complications in the first place.
2022-12-23 15:56:15 <MrMobius    > KipIngram: DM42 runs Free42 which is actually not an emulator but a remake from scratch in C that is absolutely identical
2022-12-23 15:56:35 <KipIngram   > I saw that.  That's actually what my phone app is.
2022-12-23 15:56:41 <KipIngram   > At least it's called Free42.
2022-12-23 15:56:51 <MrMobius    > Makes it easy to modify like showing 4 levels of stack and other neat stuff
2022-12-23 15:57:01 <KipIngram   > Right.
2022-12-23 15:57:16 <MrMobius    > DM41X emulates the Rom as I understand it. Dunno about the other one
2022-12-23 15:57:20 <KipIngram   > If I buy one of those it will probably be the 41X.
2022-12-23 15:57:30 <MrMobius    > Nice!
2022-12-23 15:57:36 <KipIngram   > That's the one I really "knew."
2022-12-23 15:58:07 <MrMobius    > I already had a 48 when I got interested so nostalgia for me to relive with 41/42. They are awesome machines though
2022-12-23 15:58:21 <MrMobius    > *so NO nostalagia
2022-12-23 15:58:53 <MrMobius    > Anyway, the point being that it does have the exact same programming model as the old ones if that matters
2022-12-23 16:00:08 <KipIngram   > No, not really.  I think my 41CV emulator is actually an emulator.  It will do that unofficial "synthetic programming" stuff that the calculator would do.
2022-12-23 16:23:28 <KipIngram   > Why does the DM41X blurb say "32 Mbit EXTERNAL flash"?
2022-12-23 16:23:35 <KipIngram   > What does it mean there by "external"?
2022-12-23 16:34:19 <KipIngram   > Wow - that thing runs on a single 2032 coin cell and will run on it for three years.  On battery power it runs at 24 MHz.
2022-12-23 16:34:40 <KipIngram   > That's good calibration for my thinking about that "pocket stylus gadget" I was mentioning the other day.
2022-12-23 16:35:17 <KipIngram   > The DM41X screen isn't *horribly* different from one I might use for that.  Though I might want a full color display, and it has to be a touch screen.
2022-12-23 16:35:32 <KipIngram   > But if it would run even, say, a month on a coin cell, that would be spectacular.
2022-12-23 17:15:53 <KipIngram   > You know, I don't quite see the logic of not having a - instruction.  You need that circuitry anyway, to do < and other comparisons.
2022-12-23 17:16:15 <KipIngram   > Even if you can "do everything" some other way, it would wind up being a major performance hit.
2022-12-23 17:25:56 <decay       > fwiw KipIngram my core system doesn't have any arithmetic.
2022-12-23 17:26:16 <eris[m]     > Why?
2022-12-23 17:26:18 <decay       > but it does have a bitwise deque.
2022-12-23 17:26:26 <decay       > eris[m]: fun.
2022-12-23 17:26:38 <KipIngram   > So are = != your only "tests"?
2022-12-23 17:26:46 <eris[m]     > hm
2022-12-23 17:26:47 <eris[m]     > fair
2022-12-23 17:26:58 <decay       > there are a pair of looping opcodes.
2022-12-23 17:28:19 <KipIngram   > How do you decide to terminate a loop?
2022-12-23 17:28:46 <decay       > [ tests the bit at the head of the deque. if it's 0, it jumps to the matching ] and resumes one opcode past it. if it's 1, it just advances one opcode past it.
2022-12-23 17:28:49 <KipIngram   > Also, the FPGA I'm looking at has special logic in about a third of the logic slices to facilitate fast carry propagation.
2022-12-23 17:28:59 <KipIngram   > It would seem a shame not to captialize on that.
2022-12-23 17:29:35 <KipIngram   > Ok.  So you'd have to build up arithmetic if you wanted it.
2022-12-23 17:29:42 <decay       > yep.
2022-12-23 17:29:52 <MrMobius    > decay, sounds like brain f*ck
2022-12-23 17:29:57 <decay       > yep!
2022-12-23 17:30:01 <KipIngram   > Well, if I did that I'd definitely not be using that carry logic.
2022-12-23 17:30:17 <decay       > (there are arithmetic opcodes in the extended instruction set.)
2022-12-23 17:30:42 <MrMobius    > KipIngram: external flash as in on the PCB but not in the MCU. Dunno about that one but DM42 can store files on external flash and execute code from it too
2022-12-23 17:30:57 <KipIngram   > Ok, that was my best guess as well.
2022-12-23 17:31:26 <KipIngram   > It said in the docs that memory-wise it's equivalent to the original HP-41CX plus two extended memory modules.
2022-12-23 17:31:28 <MrMobius    > XIP is what it's called in case you're curious. Rpi pico for example is external mem only
2022-12-23 17:31:57 <MrMobius    > for data/program I mean
2022-12-23 17:32:36 <KipIngram   > I'm unsure at the moment how I might handle external RAM with this FPGA.  I need to learn more about exactly how contemporary ram devices work.  I wouldn't want to slow the FPGA down while it waited for RAM.
2022-12-23 17:33:49 <MrMobius    > I only know about through hole SRAM. 55ns for 512k. Down to 10ns for smaller like 32k. In sure you can do better with smd or dram
2022-12-23 17:34:54 <KipIngram   > I also need to study that carry logic more, because it's not clear to me yet how fast it is.  Supposedly faster than I'd get if I built it myself, but I have no details.
2022-12-23 17:35:45 <KipIngram   > Give a cell width (32 or 64), I need to work out how long it will take to get the carry effect "all the way home."  I might end up having to do Chuck's trick of running some nops ahead of the + or - instruction to give it time to settle.
2022-12-23 17:36:20 <KipIngram   > Sounded like in the F21 he did that to varying degrees, depending on his knowledge about the numbers being dealt with.
2022-12-23 17:36:59 <KipIngram   > One nop would get you some of the bits - if you knew there were no higher carries you could stop then.  If you didn't know, you used more nops.
2022-12-23 17:40:43 <KipIngram   > The clock beginning each instruction cycle will clock the new values into the stack address regs (one for each port).  So then you'd get a clock-to-output delay before the RAM was properly addressed.  Then you'd get a RAM delay before you had the proper values at the ALU inputs.
2022-12-23 17:41:48 <KipIngram   > For implied 0 argument operations, I'll need to be able to mask one ALU input to zero.  That implies an additional LUT delay.  Then there's the ALU itself, which may just be one LUT layer.
2022-12-23 17:41:57 <KipIngram   > Those last two lut layers maybe mergeable.
2022-12-23 17:42:23 <KipIngram   > Then there's 2-3 lut layers to boil those 32-64 bits of result down to "condition flags."
2022-12-23 17:42:42 <KipIngram   > And THAT is what the instruction (conditional ones) will actually use to make decisions about what to do.
2022-12-23 17:43:55 <KipIngram   > And I still have no clue about routing delays.
2022-12-23 17:44:23 <KipIngram   > My bet is that it can vary a fair bit, depending on the complexity and "obtuseness" of one's particular design.
2022-12-23 17:44:39 <KipIngram   > So I may not really get good info on that until I've got a design mostly built and analyzed.
2022-12-23 19:40:29 <decay       > trying to come up with a design for a bitwise queue that doesn't involve storing four/five cells.
2022-12-23 19:42:43 <KipIngram   > "Bitwise queue" - you mean you want to shift out bits one at a time?
2022-12-23 19:43:13 <decay       > mhm.
2022-12-23 19:43:20 <KipIngram   > How big is it?
2022-12-23 19:43:27 <decay       > dynamically resizable.
2022-12-23 19:43:38 <decay       > or rather, it has a preconfigured length.
2022-12-23 19:44:24 <decay       > I need two cursors that store the current cell that each cursor is on, as well as each bit within the cell.
2022-12-23 19:44:29 <KipIngram   > Ok.  So usually a queue needs a read pointer and a write pointer.  If those were each 32 bits you could keep 'em in one cell, and that would accommodate 512 MiB of bits, right?
2022-12-23 19:45:47 <decay       > no platform supports bit addressing, so I need to store the cell and the bit, else each access is a modulo, and I can't guarantee that sizes are a power of two.
2022-12-23 19:46:08 <eris[m]     > store the pointer as an offset and the bit in the upper bytes
2022-12-23 19:46:14 <KipIngram   > Right - you'd let the index index a BIT, but you'd have to calculate from that index a cell index and a mask and a shift count.
2022-12-23 19:46:33 <decay       > hm.
2022-12-23 19:46:59 <decay       > for the index that'd be a division.
2022-12-23 19:47:10 <decay       > but if cell sizes are all powers of two, that could work.
2022-12-23 19:47:12 <eris[m]     > you only need 3 bits to store the offset
2022-12-23 19:47:17 <eris[m]     > uh, the bit
2022-12-23 19:47:20 <KipIngram   > The to write it, you find cell index and mask for the write pointer, and or the bit in.  To read you'd use the read pointer and mask the right bit out.
2022-12-23 19:47:32 <KipIngram   > And just increment your bit pointers as needed.
2022-12-23 19:48:19 <eris[m]     > tset
2022-12-23 19:48:50 <decay       > eris[m]: I could support up to 256-bit words.
2022-12-23 19:49:05 <eris[m]     > have a 29bit offset from the start of the array, store the bit being indexed in the top 3
2022-12-23 19:49:05 <decay       > 'cuz, I guess, why not.
2022-12-23 19:49:33 <eris[m]     > thats  2 ^ 29=536870912 addressable units
2022-12-23 19:49:39 <eris[m]     > well no
2022-12-23 19:49:43 <eris[m]     > 536870912  bytes
2022-12-23 19:51:29 <decay       > you'd still need a division in the general case if your words aren't powers of two.
2022-12-23 19:51:40 <eris[m]     > would you?
2022-12-23 19:51:47 <eris[m]     > why not address by bytes
2022-12-23 19:51:58 <decay       > index = bit / the size of a word.
2022-12-23 19:52:10 <eris[m]     > im saying store a byte offset and then a bit offset into the byte
2022-12-23 19:52:17 <decay       > why use bytes?
2022-12-23 19:52:35 <eris[m]     > because that's your underlying addressing mechanism
2022-12-23 19:52:42 <decay       > larger word sizes mean shorter common code paths.
2022-12-23 19:53:10 <eris[m]     > you'd have a pointer like this:
2022-12-23 19:53:25 <eris[m]     > 101 <- offset into the selected byte
2022-12-23 19:53:38 <decay       > like if your backing is an array of 64-bit words you'd spend more time shifting the same word and incrementing a bit pointer than you would checking to see if you're moving between bytes.
2022-12-23 19:54:35 <eris[m]     > 10101111011111000010001100010 <- offset into the byte array
2022-12-23 19:54:53 <eris[m]     > aidk
2022-12-23 19:57:51 <KipIngram   > eris: I was assuming 64-bit cells, so you'd need 6.
2022-12-23 19:58:11 <decay       > this is still assuming you're storing two values. you just pack them together in a single cell.
2022-12-23 19:59:04 <KipIngram   > 6 least significant bits would select a bit in a cell; then you'd shift the upper bits down to address the cell.
2022-12-23 19:59:18 <KipIngram   > Right - two 32-bit addrs in one cell.
2022-12-23 20:00:03 <KipIngram   > And I agree with decay - I'd just do the calculation every time instead of trying to "hold the current cell."
2022-12-23 20:00:14 <decay       > that's a time/space tradeoff though.
2022-12-23 20:00:20 <decay       > computing it every time means a division.
2022-12-23 20:00:34 <KipIngram   > No, just shifts.
2022-12-23 20:00:42 <KipIngram   > Since you've got a power of 2 bits in each cell.
2022-12-23 20:00:47 <decay       > that's assuming your words are a power of 2.
2022-12-23 20:00:57 <eris[m]     > .
2022-12-23 20:01:03 <eris[m]     > why arent your words a power of two
2022-12-23 20:01:08 <KipIngram   > Well, yeah - I guess if you have one of Chuck's funky processors it might not be.
2022-12-23 20:01:22 <decay       > eris[m]: you're in #forth where 18 bit words are a thing. :P
2022-12-23 20:01:26 <eris[m]     > they are
2022-12-23 20:01:34 <KipIngram   > On some processor...
2022-12-23 20:01:39 <eris[m]     > are they relevant on 8bit byte processors
2022-12-23 20:01:42 <KipIngram   > MuP21?
2022-12-23 20:02:05 <KipIngram   > Or was that one that Novix chip?
2022-12-23 20:03:00 <KipIngram   > Anwyay, yeah, if I was on a non-power-of-two cellsize, I might reconsider the "hold a cell and work through it" approach.
2022-12-23 20:03:36 <KipIngram   > Then you'd have an in progress read cell, an in progress write cell, AND the read and write cell addresses, so you are getting on up to five-ish.
2022-12-23 20:04:13 <decay       > yeah..
2022-12-23 20:04:47 <KipIngram   > You may not be aware, but if you need to constantly divide by the same constant number, you can achieve that with a multiplication.
2022-12-23 20:04:52 <KipIngram   > It's in Hacker's Delight.
2022-12-23 20:05:02 <KipIngram   > And that's usually much faster on most processors.
2022-12-23 20:05:16 <KipIngram   > You figure out that magic number to multiply by in advance.
2022-12-23 20:05:16 <decay       > yeah.
2022-12-23 20:06:12 <KipIngram   > I haven't had that book out in a while - I should peruse it again.
2022-12-23 20:06:19 <KipIngram   > Just to refresh my memory of what's in it.
2022-12-23 21:18:10 <MrMobius    > If you don't mind cheating, you can just use godbolt to see the magic number for a given constant
2022-12-23 21:22:46 <KipIngram   > I don't think that's cheating.  :-)
2022-12-23 21:22:52 <KipIngram   > How do you do that, exactly?
2022-12-23 21:23:15 <KipIngram   > Oh, does the compiler make that transformation for you?
2022-12-23 21:23:22 <KipIngram   > Use multiplication when you put in division?
2022-12-23 21:24:35 <KipIngram   > Holy cow, it sure does, doesn't it?
2022-12-23 21:25:33 <decay       > yep.
2022-12-23 21:29:35 <KipIngram   > That is neat - nice trick.
2022-12-23 21:30:07 <KipIngram   > Oh, man, I could use that to print out those constants from all of the h files, couldn't i?
2022-12-23 21:30:14 <KipIngram   > Like those termios magic numbers?
2022-12-23 21:30:26 <KipIngram   > I always wrote my own little program to print them out.
2022-12-23 21:33:56 <KipIngram   > Well, wait.  I'm not seeing it do it now.  I first put floats in my test program, but I think what it was doing was just multiplying by the reciprocal.
2022-12-23 21:34:17 <KipIngram   > Isn't this something that works with ints?  Now that I switched things to ints, it's using idiv.
2022-12-23 21:42:46 <KipIngram   > or rather just div
2022-12-23 21:43:03 <MrMobius    > KipIngram: I have done this trick for several things including termino constant :D
2022-12-23 21:43:39 <MrMobius    > KipIngram: did you put -O2 in the options?
2022-12-23 21:43:51 <MrMobius    > *termio
2022-12-23 21:44:01 <KipIngram   > No, let me try that.
2022-12-23 21:44:17 <decay       > I really wonder how I want to bootstrap this. I already have a working interpreter in Python with bitwise I/O.
2022-12-23 21:44:50 <thrig       > (gdb) l                           Abort trap (core dumped)
2022-12-23 21:44:56 <KipIngram   > That got it.
2022-12-23 21:45:14 <KipIngram   > Heh - that is cool.
2022-12-23 22:11:49 <KipIngram   > This is neat:
2022-12-23 22:11:51 <KipIngram   > https://github.com/stnolting/neorv32-verilog
2022-12-23 22:12:33 <KipIngram   > It's RISC-V processor that will go into a fairly light FPGA, including the one that I was first interested in the other day but couldn't get the design software for to run.
2022-12-23 22:12:58 <KipIngram   > That makes me think that if that will fit in that device, a Forth processor probably would to.
2022-12-23 22:13:28 <decay       > the J1 is fairly light I think.
2022-12-23 22:13:35 <KipIngram   > That was when I was looking at the iCE40 UltraPlus.
2022-12-23 22:13:46 <KipIngram   > Yeah, it is - I was looking at it the other day.
2022-12-23 22:16:01 <KipIngram   > This one's got 5280 LUTs in it, so that's probably enough.
2022-12-23 22:16:23 <KipIngram   > The Xilinx part on my board has a lot, LOT more than that.
2022-12-23 22:16:40 <KipIngram   > But it's a $150 part, whereas the iCE40 is under $10.
2022-12-23 22:21:12 <decay       > 5280 LUTs should be fine enough.
2022-12-23 22:44:21 <KipIngram   > Wow - it says in the data on the iCE40 that a typical current draw for common applications is 1-10 mA.
2022-12-23 22:44:24 <KipIngram   > So say 10.
2022-12-23 22:44:41 <KipIngram   > That means a 3000 mAH cell would run it for 300 hours.
2022-12-23 22:47:25 <KipIngram   > That seems to indicate that it would be the display that took most of the power.
2022-12-23 22:47:51 <KipIngram   > I've also thought about trying to do something with an e-ink display.
2022-12-23 22:50:04 <KipIngram   > I looked up power consumption for a 4.2" eInk display; it was 10 mW.
2022-12-23 23:00:02 <KipIngram   > A 3.5" TFT display on Amazon for $20 has 150 mA current consumption.  So that same cell would run it for 20 hours.  That's adequate - that would allow all-day use and overnight re-charge.
2022-12-23 23:25:07 <KipIngram   > Hey, an Ohio congressman has introduced a bill that would outlaw private restrictions on amateur radio operators installing antennas and so on on their properties.
2022-12-23 23:25:23 <KipIngram   > I really hope that passes - I'd like to be able to just thumb my nose at my HOA.
2022-12-23 23:29:26 <thrig       > "we don't have a problem with the antenna, it just needs to be painted blue to match the others"
2022-12-23 23:31:29 <KipIngram   > :-)
2022-12-23 23:31:52 <KipIngram   > It probably won't pass.  But I'm writing to my Congress critters to ask them to support it.
2022-12-23 23:32:18 <thrig       > someone won some law thing out East recently
2022-12-23 23:33:04 <KipIngram   > I think we talked about this a little last week.  I don't "fundamentally" object to HOAs, in toto.  I just think they've gone way too far.
2022-12-23 23:33:39 <KipIngram   > At the same time, I'd be hard pressed to give you any kind of rational "criterion" for what's too far and what's not.
2022-12-23 23:33:45 <KipIngram   > It's a very slippery slope.
2022-12-23 23:33:50 <thrig       > https://news.ycombinator.com/item?id=33992984
2022-12-23 23:41:21 <KipIngram   > That is FANTASTIC.
2022-12-23 23:41:38 <KipIngram   > It's behind a paywall, but I found it somewhere else using the article title.
2022-12-23 23:41:48 <KipIngram   > There is hope for sanity after all.
2022-12-23 23:41:55 <KipIngram   > https://dnyuz.com/2022/12/15/they-fought-the-lawn-and-the-lawns-done/
2022-12-23 23:42:02 <KipIngram   > That's the non-paywall link.
2022-12-23 23:43:46 <KipIngram   > Ok, so NOT caching at least the data stack TOS doesn't look like an option.  The idea would have been to use the two RAM ports to address TOS and NOS, and that would flow into the ALU.
2022-12-23 23:44:51 <KipIngram   > Well, maybe it actually is, if I'm clever.  But the problem is that you also need to WRITE the operation results into the new TOS.  And you only have one set of data lines on that port - you can't both read and write, the way you can a register.
2022-12-23 23:45:33 <KipIngram   > So unless I can latch the input data somehow (which I might be able to do with the low phase of the clock), I can't get at the data lines for the new data.
2022-12-23 23:46:51 <KipIngram   > But maybe that can be done - maybe I can read the data out during the first half cycle, and then the clock will go low and close a latch, locking it into the ALU input, but switch the data lines over to the ALU output and get ready for a write on the next rising edge of the clock.