2026-02-12 00:51:05 <rendar_     > i see
2026-02-12 00:52:33 <rendar_     > in my forth i have `def my-hash sha1 end`  to define a word, so if i have `def compute ... my-hash ... end`   compute will compute the sha1 hash of data, but if i do `def my-hash sha256 end`  that redefinition will be in `my-hash` so `compute` will call the new hash function
2026-02-12 00:52:41 <rendar_     > is like having function pointers, or late binding
2026-02-12 00:53:07 <rendar_     > i was thinking to enable this explicitly with a keywurd, e.g. `redef my-hash sha256 end`  to be more clear
2026-02-12 00:53:12 <rendar_     > thoughts on this?
2026-02-12 01:33:48 <KipIngram   > Well, I'm old fashioned here.  I want peak performance, so in my systems once a word is compiled it's compiled.  Bindings happen at compile time and are fixed for good in compiled words.
2026-02-12 01:34:41 <KipIngram   > That's how traditional Forth works, and it's a special class of words with an extra level of indirection that you can re-define after using them.
2026-02-12 02:18:27 <rendar_     > KipIngram: yeah that is the indirect/direct threading?
2026-02-12 02:29:01 <rendar_     > KipIngram: basiclally words can be direct pointers or integers indexes into a pointers vector, right?
2026-02-12 05:51:01 <veltas      > rendar_: Yes
2026-02-12 05:52:03 <veltas      > And it doesn't really allow for what you're doing, in indirect threading you've got a code pointer for each word, but for e.g. colon words it doesn't point to the def, it points to a fixed routine for executing code words
2026-02-12 05:52:18 <veltas      > executing colon words, rather
2026-02-12 05:52:45 <veltas      > So the colon word (list of addresses) has to follow the code pointer
2026-02-12 05:54:00 <veltas      > Likewise with direct threading you get executable code instead of a code pointer, but that executable code will jump to the colon word runtime and relies on the colon word def following that machine code it just jumped from
2026-02-12 05:56:47 <veltas      > You'd need indirect-indirect or indirect-direct threading, where each colon def found the code pointer via an indirect pointer in the word, which can be changed to point elsewhere (instead of changing every pointer to the code pointer in all colon words)
2026-02-12 05:58:21 <veltas      > In Forth you can achieve this by having a word just execute a variable's content, i.e. : my-hash 'my-hash @ execute ;
2026-02-12 05:59:26 <veltas      > Then you can do  ' sha1 'my-hash !  or  ' sha256 'my-hash !  at any time to set the behaviour
2026-02-12 06:01:47 <veltas      > Some newer Forths have "defer", so you can do  defer my-hash  and  ' sha1 is my-hash  ' sha256 is my-hash  etc
2026-02-12 06:04:45 <veltas      > In fact defer is trivial to implement:  : defer create 0 , does> @ execute ;  : is ' >body ! ;
2026-02-12 06:08:05 <veltas      > There's one big advantage of indirect-indirect / indirect-direct threading: it makes redefining stuff at the interpreter much easier
2026-02-12 06:09:05 <veltas      > It's one of Forth's greatest strengths that you can compile and interpret code within its environment, and one of the reasons is the interactivity you get with trying out new code
2026-02-12 06:09:33 <veltas      > It just makes it even easier if a lower-level definition can be replaced when you realise it's wrong
2026-02-12 06:10:14 <veltas      > However it totally breaks Forth's semantics, because it's often relied on that a new def with an existing name doesn't break all use of the old def with same name
2026-02-12 06:10:48 <veltas      > So you're essentially removing scope for names and rewriting all your code every time you write a new def for an old name
2026-02-12 06:14:42 <veltas      > gforth team I think reported that initially they had DEFER do some clever machine code routine to call the desired word, and it would rewrite the machine code when you used IS
2026-02-12 06:15:20 <veltas      > And they found that the performance was dreadful compared to just storing a variable and executing the variable content
2026-02-12 06:17:42 <veltas      > x86 would rather you didn't constantly patch machine code at runtime
2026-02-12 08:37:07 <iv4nshm4k0v > Deferred words still have their uses, much like, say, function pointers in C.
2026-02-12 08:37:07 <iv4nshm4k0v > For an example, Pygmy Forth uses them to choose among four of its EMIT implementations: the default one that uses a BIOS INT $10 call (and won't work with, say, "CTTY AUX"), the one that accesses EGA directly (and won't work with incompatible hardware), and two more that use DOS INT $21 calls (AH $02, and AH $40 to file descriptor 1, both of them unusably slow on 8088/8086.)
2026-02-12 09:13:50 <veltas      > It's slow because the x86 cache logic isn't really optimised for modifying code that's already executing
2026-02-12 09:14:17 <veltas      > Especially as x86 has to emulate pre-cache behaviour
2026-02-12 09:15:08 <veltas      > See on ARM they can just define a memory model that makes sense, and if you modify instructions that have already been cached there are consequences, and there are explicit memory barriers etc to control when synchronisation etc happens
2026-02-12 09:15:17 <veltas      > Because they have that luxury
2026-02-12 09:16:06 <veltas      > But x86 is backwards-compatible to chips that you can render all the transistors for on a normal monitor, well before cache was ever used in a microcomputer
2026-02-12 09:16:51 <veltas      > I'm sure there's a way to do it better on x86 for JIT reasons, but modifying a bit of code while also executing it is pathological
2026-02-12 14:21:34 <cleobuline  > forthBot: LOAD ini.fth
2026-02-12 14:21:34 <forthBot    > File ini.fth with MOON  loaded
2026-02-12 14:21:41 <cleobuline  > forthBot:  MOON
2026-02-12 14:21:41 <forthBot    > Phase de la lune pour Thu February 12 2026
2026-02-12 14:21:41 <forthBot    > 🌘 Croissant descendant La lune s'efface, une nuit calme a venir ! Illumination 22%
2026-02-12 15:53:07 <KipIngram   > tpbsd:  I'm just about ready to make a run at pushing some RISCV machine code over to this chip.  I am going to install the toolchain, so I can get assembly listings to see what I want my code to be, but that chain is oriented primarily toward FLASHING the part, whereas what I want is to send this code over using load_ram.  But the chain can at least get me my code.
2026-02-12 15:53:38 <tpbsd       > KipIngram, exciting times!
2026-02-12 15:54:25 <KipIngram   > What I plan to do is simple - I want to mask interrupts and run a loop that wiggles the led output.  Along side that, I want to run a free-running counter.  Each pass through the loop I will read the counter, take the difference between this value and the last value, and track the maximum and minimum of those differences.  After running that for some long period of time, I'll calculate "max minus
2026-02-12 15:54:26 <KipIngram   > min" and repeatedly "flash it out" on the led.
2026-02-12 15:54:47 <KipIngram   > So if any cycle jitter gets injected, for any reason, it'll spread that window openm.
2026-02-12 15:55:03 <KipIngram   > That feesl pretty certain to me - what do you think?
2026-02-12 15:55:36 <KipIngram   > I'm not sure I own an instrument good enough to do this externally.
2026-02-12 15:56:01 <KipIngram   > I think I'd wind up measuring instrument noise.
2026-02-12 16:00:29 <tpbsd       >  "flash it out" on the led ?
2026-02-12 16:01:21 <KipIngram   > I'm of the understanding now that this "configurable switching matrix" is not involved with GPIO itself.  The GPIO pins are just the GPIO pins - and there's no translation between their software reference and the effect.  Rather, that matrix is to let you switch other peripheral functions, like UART signals and so on, ONTO pins.  To do that you configure the GPIO as an input and map the periperal
2026-02-12 16:01:23 <KipIngram   > on.   which means you can read the GPIO to "spy" on the peripheral.
2026-02-12 16:01:53 <KipIngram   > Yeah - I just meant some protocol on the LED to get that max-min window width to the outside world.  So I don't have to have the UART under my belt yet.
2026-02-12 16:02:17 <KipIngram   > I'd just make up some protocol for delivering the numerical value by some flash pattern.   No idea exactly how I'd do it yet.
2026-02-12 16:02:49 <tpbsd       > thats normal, gpio's have a 'alternate function' mode to select a choice of peripheral connections
2026-02-12 16:03:52 <KipIngram   > Right - but the good news for me here is that I don't have to muck about with that in order to "just do GPIO."
2026-02-12 16:04:16 <KipIngram   > I just have to make the pin an output and start wiggling it.
2026-02-12 16:04:45 <tpbsd       > yeah, the power up defaults usually just set them up as gpio inputs with STM32 at least
2026-02-12 16:04:45 <KipIngram   > And since that pin is know to connect to the LED, there won't be any issue with any prior software (like MicroPython) having some peripheral mapped onto it.
2026-02-12 16:05:19 <KipIngram   > The thing is, this "load_ram" path isn't a well-documented and well-traveled trail.
2026-02-12 16:05:24 <KipIngram   > Most people just flash their code.
2026-02-12 16:06:18 <KipIngram   > But the esptool says point blank in its help output that load_ram involves copying a binary pattern into RAM at some address and transferring control to it, so... for pure bare metal, why not?
2026-02-12 16:06:44 <tpbsd       > with STM32xx ( I don't know ESP32 at all) after power reset all the pin states are known and default. Only running code in the chip can change that other than controlling it via JTAG
2026-02-12 16:08:15 <tpbsd       > sure, it's the same with the STM32xx either boot from ram at some address, or boot from flash. The choice is decided by special 'boot' pins on the chip
2026-02-12 16:08:45 <tpbsd       > theyre hard wired to control the boot choice
2026-02-12 16:09:53 <tpbsd       > oh, so nice, it's 0200 here and the temperature has dropped to 26,6 C  80,0 F
2026-02-12 16:12:55 <KipIngram   > Wow - at 2 am?  Hot days...
2026-02-12 16:13:07 <KipIngram   > Our turn will come in a few months.
2026-02-12 16:13:24 <KipIngram   > We've got afternoons in the 70's F this week, which is pretty wonderful.
2026-02-12 16:14:02 <KipIngram   > Oh, my first Social Security check landed in the bank this morning, so it looks like I'm "all the way retired" now.
2026-02-12 16:14:21 <tpbsd       > KipIngram, awesome!
2026-02-12 16:14:29 <tpbsd       > I retired in 2020
2026-02-12 16:14:51 <tpbsd       > so it's been 5 years of doing projects etc
2026-02-12 16:14:52 <KipIngram   > Yeah, good to see the whole chain working.  Know that I didn't type a digit wrong when I gave them my account and routing numbers.  :-)
2026-02-12 16:15:43 <tpbsd       > yeah, it's great to have the system working well as intended!
2026-02-12 16:16:41 <KipIngram   > Anyway, so I guess my goal for today is to get that toolchain installed.  I've flashed the LED from Python - with that in place I'll flash it from C, start looking at the code it generates, and so on.
2026-02-12 16:16:58 <tpbsd       > I admit, after 6 years I'm very used to this now, it's ny 'new normal'
2026-02-12 16:17:20 <KipIngram   > Apparently there is a "known" and "documented at least unofficially" way to take an elf made by the tool and make it into a bin suitable for load_ram.
2026-02-12 16:17:53 <KipIngram   > I've settled into it pretty quickly.  I dealt with all of my "defining myself through my career" hangups long long ago.
2026-02-12 16:18:18 <KipIngram   > There were times when I think I did define myself that way, but that was back around 2000 when I was doing things like being vice presidents.
2026-02-12 16:18:43 <KipIngram   > I kind of lost that later on, and was bummed over it at first, and then just got over it.  Been over it for a long time before I finally pushed the retirement button.
2026-02-12 16:19:45 <tpbsd       > Ive almost always worked for myself, with a couple of 3 year stints working for big companies, but I got bored easily and moved on looking for new things to do
2026-02-12 16:19:51 <KipIngram   > It helped that I saw pretty quickly that I did NOT want to be any any of those uppity muckity positions at a big corporation like IBM.  Looked like nothing but headaches to me.
2026-02-12 16:20:52 <KipIngram   > I thrived best in small companies, where one person could have more impact on the culture.  I.e., such companies at least CAN adapt their culture around their people.
2026-02-12 16:21:01 <KipIngram   > Big outfit like IBM, the people must conform.
2026-02-12 16:21:08 <KipIngram   > I'm not a good little conformist.  :-|
2026-02-12 16:21:31 <tpbsd       > for 14 years before I retired I built up and ran a speacialist wifi business, which was fun. Mainly designing and shipping prebuilt long distance networks
2026-02-12 16:21:41 <forthBot    > Environment for cleobuline inactive, freeing...
2026-02-12 16:22:07 <KipIngram   > Nice.  I had a business of my own for about five years.  Consulting, mostly in motion control and machine vision.  Optical inspection and things like that.
2026-02-12 16:22:38 <tpbsd       > nice! Wifi is pretty boring, but has it moments
2026-02-12 16:22:46 <KipIngram   > I did okay, but never as well money-wise as I had drawing a salary.  Came a point we decided our kid count required a larger house, so I sucked it up and went and got a paying job again.
2026-02-12 16:23:35 <KipIngram   > Yeah, it did offer variety.  Lots of small stuff inspection, but also one gig that involved inspecting airplane wings for cracks.
2026-02-12 16:23:39 <tpbsd       > I would have preferred designing embedded solutions, but I had to follow the money to make a living, and that at the time was wifi
2026-02-12 16:24:02 <tpbsd       > wow, thats a serious pastime, inspecting wings
2026-02-12 16:24:07 <KipIngram   > Dude that hired me had done all of the big mechanical design but used me several times for motion control smarts, interfacing the vision components, and so on.
2026-02-12 16:24:38 <KipIngram   > He was over in Louisiana, 3-4 hours from me.  I drove over there several times.
2026-02-12 16:24:52 <KipIngram   > Did most of the work at home, though, and drove over to test stuff out  periodically.
2026-02-12 16:24:56 <tpbsd       > in your hot rod ?
2026-02-12 16:25:06 <KipIngram   > No, at the time I didn't have tha tyet.
2026-02-12 16:25:14 <KipIngram   > This was back in like 2003-2004.
2026-02-12 16:26:01 <KipIngram   > Picked up the Cayman in 2011, and the turbo kit in 2013.
2026-02-12 16:26:07 <tpbsd       > ahh
2026-02-12 16:26:41 <KipIngram   > I know I'm going to have to give it up someday, and unless bitcoin explodes or something I won't be able to afford another one.  So I'm just nejoying it while it lasts.  :-)
2026-02-12 16:28:34 <tpbsd       > I flew down to Sydney (about 550 miles) when I bought the Audi, and then drove it back. I also looked at a Honda CRX Del Sol but that one turned out to be a wreck, The Audi was in excellent condition
2026-02-12 16:28:36 <KipIngram   > Really one of the things I appreciate about my career is the variety of stuff I got to do.  I can't say it wasn't interesting.
2026-02-12 16:29:20 <tpbsd       > same here, I consider myself very lucky for the opportunities Ive had
2026-02-12 16:29:36 <KipIngram   > And then given the big financial cherry that IBM came along and dropped on top of it, I can't complain about that either.  I'd already done fairly well, and that just really made it nice.  I can look back at it all now and say "Not bad..." to myself.
2026-02-12 16:29:53 <tpbsd       > sounds like it :)
2026-02-12 16:30:07 <KipIngram   > And I managed to never get "involuntarily dismissed" from a job.
2026-02-12 16:30:16 <tpbsd       > now all you have to do is find some way to control that ESP :)
2026-02-12 16:30:43 <KipIngram   > I'd actually have preferred to stick at IBM another couple of years, but I still look at my departure as voluntary.  I could easily have "bent to their will" and stayed, but just decided I didn't want to.
2026-02-12 16:30:46 <tpbsd       > hahah, same here, tho I 'sacked' a fair few employers for being dull and boring
2026-02-12 16:31:47 <KipIngram   > Yeah, I had to do that some too.  A number of time it was individual - for performance reasons, and then at one place backa round 2001 we had to rounds of layoffs.
2026-02-12 16:31:57 <KipIngram   > First one wasn't so bad - I felt like it was "trimming fat."
2026-02-12 16:32:11 <KipIngram   > But that second round hurt - I said goodby to some perfectly good engineers that time.
2026-02-12 16:32:25 <KipIngram   > goodbye
2026-02-12 16:32:39 <tpbsd       > actually everything was going very well for me until 2019, when the  wifi market in Australia was flooded with cheap wifi and some big players moved in. My orders stopped overnight and I went soon broke, luckily I was saved by retirement
2026-02-12 16:33:24 <KipIngram   > It had to be done, though - that was back when the "internet bubble burst" late summer / early fall 2001.  Our revenues really depended on GROWTH in the semiconductor sector - it was a sort of derivative thing.
2026-02-12 16:33:26 <tpbsd       > but I did support me for 14 years, so Im very happy about that
2026-02-12 16:33:37 <KipIngram   > All it took was for growth to go flat for our revenue to just crater.
2026-02-12 16:33:53 <KipIngram   > We went from $50 million plus in 2000 to $12 million in 2001.
2026-02-12 16:34:20 <KipIngram   > The "engineering programmers" - the little manual desktop things were still selling just as good as ever, but the big automated systems just stopped moving.
2026-02-12 16:34:28 <veltas      > I'm glad you didn't say 'goodby', on top of everything else
2026-02-12 16:34:37 <KipIngram   > Our big customers didn't need "more" - they still had what they'd already bought, and it was enough.
2026-02-12 16:35:10 <veltas      > Prediction for what the RAM market will do at AI burst
2026-02-12 16:35:19 <tpbsd       > of course back in 2019 while I was bemoaning the fact that big companies had moved into my area, I had no idea that Starlink would be a thing. Nowdays Starlink would have had the same effect on my biz
2026-02-12 16:35:29 <KipIngram   > And honestly I think the window was closing on the need for "speciality companies" built around device programming anyway - the chip makers were making them more and more easy to program without any special equipment.
2026-02-12 16:36:41 <tpbsd       > I suspect that if the AI bubble bursts, we wil be flooded with cheap GPU's and ram ?
2026-02-12 16:36:47 <KipIngram   > That company still exists, actually, but it's just a tiny little thing copared to the big splash it made in the late 1990's.
2026-02-12 16:37:07 <KipIngram   > One would hope.  :-)
2026-02-12 16:37:51 <KipIngram   > I think AI is pretty remarkable, but I don't think it's going to ever be what they hype it up to be, simply because accomplishing all those magical things the hype is built around really requires a big data center burning butt-tons of electricity.
2026-02-12 16:38:00 <KipIngram   > People just aren't ever going to have THAT in their pockets.
2026-02-12 16:38:10 <KipIngram   > But they talk about it as though we will.
2026-02-12 16:38:13 <tpbsd       > prior to the wifi bix I worked for a environmental instrumentation company part time for about 3 years, manufacturing heaps of controllers and remote sensors for farming
2026-02-12 16:38:45 <KipIngram   > I had eight jobs in my career, counting my consulting stint.
2026-02-12 16:39:40 <KipIngram   > Data acquisition, railguns and whatnot, device programming, consulting, marine seismic systems, downhole oil tools, land seismic, and flash based data storage.
2026-02-12 16:40:35 <KipIngram   > That first one was with National Instruments, back when it was tiny.  I was ground floor there, and probably could have wound up a big shot with them  if I'd stayed.  A guy almost just like me, who started one day before me, did stay and wound up a VP of Research.
2026-02-12 16:40:36 <tpbsd       > I think AI just isnt sustainable for too much longer and it will crash bigtime. It will always be around for the typical $10 a month online use, but it wont be disruptive in any big way
2026-02-12 16:40:45 <KipIngram   > It won't surprise me.
2026-02-12 16:41:22 <KipIngram   > I think it's "interesting," but just not all it's cracked up to be.
2026-02-12 16:41:27 <KipIngram   > Good for certain things.
2026-02-12 16:41:38 <tpbsd       > yeah, I look back on all the enterprises I was associated with in some way, a few of them became pretty big
2026-02-12 16:41:42 <KipIngram   > Unfortunately, one of them is for spying on us better.
2026-02-12 16:42:12 <tpbsd       > yeah, but steam power for instance was much more profound
2026-02-12 16:42:25 <tpbsd       > or the invention of the valve or the transistor
2026-02-12 16:42:27 <KipIngram   > My other big "miss" was that back in 1986 I had an opportunity to invest in Xilinx.  Passed on it - too risky.  My first wife would never have gone for it.
2026-02-12 16:42:35 <KipIngram   > On hindsight, though...  :-|
2026-02-12 16:42:45 <tpbsd       > they enabled things that changed the world
2026-02-12 16:42:51 <KipIngram   > But, if I'd gotten rich there I'd likely have never met my now wife, so... I wouldn't change it.
2026-02-12 16:43:21 <tpbsd       > yeah :) at our age the memories we have :)
2026-02-12 16:43:39 <tpbsd       > the crossbow, gunpowder
2026-02-12 16:43:47 <KipIngram   > Right - that "Not bad..." I mentioned before is plenty good enough for me.  My kids and grandkids are what it's mostly about now.
2026-02-12 16:43:54 <tpbsd       > AI seems quite tame in comparison now
2026-02-12 16:44:13 <KipIngram   > I just want to take good care of myself so I can enjoy them (and hopefully some great-grandkids) for a long time.
2026-02-12 16:44:42 <KipIngram   > Steam engine.  :-)
2026-02-12 16:44:52 <tpbsd       > initially I was expecting AI to be some incredible superintelligence, but then I learnt that it's just a 'autocomplete on steroids'
2026-02-12 16:45:00 <KipIngram   > Which actually got "first glimpsed" back in the first century AD.
2026-02-12 16:45:11 <KipIngram   > Steam powered Roman Empire, anyone?
2026-02-12 16:45:50 <KipIngram   > Hero of Alexander.  It got written off as a toy.
2026-02-12 16:46:02 <tpbsd       > they were unstopable just with the invention of paved roads!
2026-02-12 16:46:27 <KipIngram   > No doubt.  I saw an article recently where they found some concrete production "in process" when  Vesuvius erupted.
2026-02-12 16:46:34 <KipIngram   > So they got to see all the ingredients and everything.
2026-02-12 16:46:41 <tpbsd       > as it was the Roman Empire lasted for ages then decayed from within, like all empires
2026-02-12 16:46:43 <KipIngram   > Apparently Roman concrete "self-healed" cracks.
2026-02-12 16:46:52 <KipIngram   > Which helps explain why so much of it is stilla round.
2026-02-12 16:47:00 <KipIngram   > We might actually be able to learn from it now that they found that.
2026-02-12 16:47:04 <tpbsd       > yeah, I read that interesting fact also
2026-02-12 16:47:22 <KipIngram   > I think it's awesome.  Those guys were NOT dummies.
2026-02-12 16:47:51 <tpbsd       > no, I think we, who came later are the dummies
2026-02-12 16:48:17 <KipIngram   > Yeah.  Same exact potential - evolution doesn't move that fast.  But so many of us choose to do nothing with it.
2026-02-12 16:48:48 <KipIngram   > Just play with our gadgets and eat and breed, and otherwise just idle through life.
2026-02-12 16:49:09 <KipIngram   > And find things to complain about.
2026-02-12 16:49:21 <tpbsd       > exactly. And why do we assume that evolution is on our side ?
2026-02-12 16:49:55 <KipIngram   > Oh, I don't.  I just meant there hasn't been time for us to be "actually different" from those ancient people.
2026-02-12 16:49:59 <KipIngram   > We're the same animals.
2026-02-12 16:50:14 <tpbsd       > for instance, if we make life so easy that we no longer need a brain, evolution will take our brains from us
2026-02-12 16:50:29 <KipIngram   > I actually think we've largely stymied evolution now - we bend over backward to prevent natural selection from operating within the human population.
2026-02-12 16:50:43 <tpbsd       > yeah, agreed
2026-02-12 16:50:57 <KipIngram   > I don't mean to be judging it - just taking note.
2026-02-12 16:51:36 <KipIngram   > I can't be idle, though.  A day here, a few  hours there, sure.  But by and large if I don't have something engaging my mind I'm not happy.
2026-02-12 16:52:27 <tpbsd       > a brain needs 25% of our energy, evolution doesnt care about science and maths, it only cares about the survival of the species, and sees the 25% energy usage as wasteful if it's not needed to breed
2026-02-12 16:52:28 <KipIngram   > I'm really quite happy about this spurt of activity around the ESP32; it's been quite a while since I've opened the Forth box.
2026-02-12 16:52:46 <KipIngram   > Seriously, at least.
2026-02-12 16:53:26 <tpbsd       > I agree, it will be good for your brain, now youve retired
2026-02-12 16:54:12 <tpbsd       > Forth has been really good for my brain I think, Ive been designing tooling for it since 2014
2026-02-12 16:54:46 <tpbsd       > if youre a tool builder, Forth is the perfect vehicle I think
2026-02-12 17:01:01 <KipIngram   > Couldn't agree more.
2026-02-12 17:01:03 <rendar_     > well my basic idea is that in redefining words, you can change behavior
2026-02-12 17:01:32 <KipIngram   > I don't want to claim it's the "only good thing out there," by any means, but it does offer certain features that I just don't think are found anywhere else.
2026-02-12 17:02:15 <KipIngram   > rendar_: Yeah, I get it.  It's just not the traditional Forth model, and it does bring a (not so awful, depending on how you do it) performance hit.
2026-02-12 17:02:33 <KipIngram   > With good design you can get it down to just one extra memory fetch per word.
2026-02-12 17:02:40 <KipIngram   > Which really isn't THAT bad.
2026-02-12 17:02:58 <KipIngram   > If you want that ability, it's a pretty low price tag.
2026-02-12 17:03:23 <tpbsd       > KipIngram, I agree, Ive found that Forth inspires thinking 'outside the box' and in my case, I was hit by a tidal wave of all kinds of tool ideas
2026-02-12 19:22:24 <veltas      > tpbsd: When did you find Forth?
2026-02-12 19:50:44 <KipIngram   > Well, the dev toolchain is installed and I can run the blink example from there now.  That was pretty easy and polished.
2026-02-12 20:59:37 <veltas      > KipIngram: Which dev toolchain?
2026-02-12 21:33:27 <rendar_     > KipIngram: thing is, my forth is not a low level forth, is a forth ran by a VM written in Rust which has cells high level objects such as strings
2026-02-12 21:54:40 <KipIngram   > veltas: Well, I did two, actually.  One of them is highly GUI driven, and came as an appimage that just set everything up.  It worked pretty much immediately, but unfortunately it doesn't "show you much," and my whole reason for wanting it was to be able to look at generated RISCV code.  It uses documents they call "sketches," where you just fill in two c stubs: a "setup()" stub and a "loop" stub.
2026-02-12 21:54:43 <KipIngram   > Write the code, push a button, and it flashes it over to your chip.  If any intermediate results are available anywhere, I don't know where.
2026-02-12 21:55:49 <amby        > is that arduino ide?
2026-02-12 21:56:08 <KipIngram   > Then I cloned the github rep for the arduino and installed the package for this little board.  That installs a more or less normal c compiler / linker toolchain, but OH MY GOD it's all wrapped in such an unbelievable wad of complexity.  You get this huge directory structure for your project, and I had to use find to search the whole project directory to find the .obj files.
2026-02-12 21:56:25 <KipIngram   > But, I did find them and I can disassemble them, so that does show me RISCV code.
2026-02-12 21:56:47 <KipIngram   > What I've got right now is a C file that blinks my LED and the loop is actually entirely self-contained - no calls to anything.
2026-02-12 21:56:59 <KipIngram   > Well, wait, that's not true.
2026-02-12 21:57:05 <amby        > arduino ide is kinda designed as like. baby's first programming
2026-02-12 21:57:08 <KipIngram   > There are two calls to library routines outside the loop.
2026-02-12 21:57:29 <amby        > it's really not good when you progress beyond blinking leds and printing analog readings over serial
2026-02-12 21:57:31 <KipIngram   > One to reset the GPIO subsystem and one to set direction as output on pin 15.  Then there's a call to write a value to it inside the loop.
2026-02-12 21:57:45 <KipIngram   > So what I need to do now is replace those things with bare metatl code of my own devising.
2026-02-12 21:58:05 <amby        > gpio peripherals are normally pretty easy to work
2026-02-12 21:58:23 <KipIngram   > And then I should have straight relocable binary code that will still work, and I know how to extract those bytes into a .bin file,m and in theory THAT should be usable with esptool load_ram.
2026-02-12 21:58:31 <KipIngram   > That's the plan, at least.
2026-02-12 21:58:49 <amby        > i dont know what esp32's looks like, but avr's is just a direction, output, and input register for each port
2026-02-12 21:58:57 <amby        > each port being 8 pins
2026-02-12 21:59:03 <KipIngram   > Yeah, the hardware description of it all in the technical reference looks clear.
2026-02-12 21:59:10 <KipIngram   > All the addresses are nailed down, etc.
2026-02-12 21:59:18 <KipIngram   > Everything I just described feels within reach to me.
2026-02-12 21:59:50 <KipIngram   > So that's the next goal - to be able to send code over with load_ram to make the LED blink, in which case I will be doing it in a truly pure bare metal way.
2026-02-12 22:00:18 <KipIngram   > And after that I will tackle the UART, still working with load_ram.
2026-02-12 22:00:28 <KipIngram   > That goal will be to just get it echoing what I type at it.
2026-02-12 22:00:35 <amby        > a while ago i made an assembler for avr using forth
2026-02-12 22:00:39 <KipIngram   > And once I have that, I think Forth is just a downhill coast from there.
2026-02-12 22:00:47 <amby        > which basically just spits out raw binaries
2026-02-12 22:00:54 <amby        > that are flashed using avrdude
2026-02-12 22:01:34 <KipIngram   > Yeah - I intend to make everything relocatable, so once I have something working with load_ram I ought to be able to flash it with esptool as well.
2026-02-12 22:01:56 <KipIngram   > I'd just rather develop in RAM instead of endlessly flashing my flash.
2026-02-12 22:01:56 <amby        > can esp32 run code from ram?
2026-02-12 22:02:02 <KipIngram   > Yes.
2026-02-12 22:02:05 <amby        > nice
2026-02-12 22:02:17 <amby        > avr can't, which is one of the annoying things about it
2026-02-12 22:02:34 <KipIngram   > The flash isn't actually in the multi-chip module - it's an off board SPI flash.
2026-02-12 22:02:38 <KipIngram   > Off module, rather.
2026-02-12 22:02:52 <KipIngram   > But the chip does have hardware that makes accessing it transparent.
2026-02-12 22:02:57 <amby        > yeah all the modern microcontrollers need external flash
2026-02-12 22:03:10 <amby        > it's something to do with the fabrication process
2026-02-12 22:03:20 <veltas      > Is the baremetal init code available as source?
2026-02-12 22:03:23 <KipIngram   > That is, you can still just execute from flash - there's a cache between the serial flash and the cpu - the hardware does the read an then the code runs from the cache.
2026-02-12 22:03:31 <KipIngram   > So it's slower than running from RAM.
2026-02-12 22:03:55 <KipIngram   > Probably not - I will need to write it based on studying the tech ref.
2026-02-12 22:03:57 <amby        > the kinda high-density multi-MB flash that modern microcontrollers have needs a different fabrication technique to the cpu and io, so it has to go on a separate chip
2026-02-12 22:04:12 <KipIngram   > Right.
2026-02-12 22:04:13 <amby        > whereas an avr is all on one chip
2026-02-12 22:04:19 <amby        > (and i mean literally all on one chip)
2026-02-12 22:04:35 <amby        > you need almost zero support components for an avr
2026-02-12 22:04:36 <KipIngram   > veltas: But I think initializing the GPIO is pretty simple.
2026-02-12 22:05:03 <KipIngram   > I've only perused the tech ref so far, though - haven't really deep dived any of its pieces.
2026-02-12 22:05:23 <amby        > maybe a filtering cap on the power rails, and maybe an autoreset circuit rigged up to the serial
2026-02-12 22:05:32 <amby        > but you can basically just slap the chip on a board and have it work
2026-02-12 22:05:34 <KipIngram   > The impression I got, though, is that I don't expect any real trouble with anything until I start trying to deal with WiFi and Bluetooth.
2026-02-12 22:05:41 <KipIngram   > I expect that to be semi-nightmarish.
2026-02-12 22:05:57 <KipIngram   > There are some routines in the mask rom to help, though - I have no idea where to find documentation on them yet, though.
2026-02-12 22:06:06 <amby        > bluetooth is bad enough when you have libraries available in a HLL
2026-02-12 22:06:12 <amby        > i cant imagine trying to do it from scratch
2026-02-12 22:06:23 <KipIngram   > Yeah.  Well, I'm retired and have years.
2026-02-12 22:06:38 <amby        > fair
2026-02-12 22:06:45 <KipIngram   > Not thinking about that right now - I just want a Forth working over the UART first.
2026-02-12 22:07:11 <KipIngram   > And when I do start working on the WiFi and Bluetooth, I'll be doing it in Forth in my own development environment.
2026-02-12 22:07:14 <amby        > ive considered a forth for avr but it's not really worth it, because it's harvard
2026-02-12 22:07:28 <KipIngram   > Yeah, that does complicate things.
2026-02-12 22:07:29 <amby        > i should make a forth for pi pico though
2026-02-12 22:07:49 <KipIngram   > I have more experience making Forths than using Forths.
2026-02-12 22:08:02 <amby        > cuz pi pico is surprisingly well equipped
2026-02-12 22:08:10 <amby        > it's got buckets of ram
2026-02-12 22:08:17 <KipIngram   > Up until 3 years ago or so that was fairly extreme - but my last go round I actually wrote quite a bit of Forth code, so finally I can say I've got some experience there too.
2026-02-12 22:09:04 <KipIngram   > This little guy is the same.  ESP32-C6.  It's got 512kB of RAM, and possibly as much as 4MB of flash.
2026-02-12 22:09:27 <KipIngram   > I'm not 100% sure on the flash - it's at least several hundred kB, and maybe a few MB.
2026-02-12 22:09:53 <KipIngram   > But 512kB feels like plenty of RAM for a Forth embedded environment to me.
2026-02-12 22:10:12 <KipIngram   > Especially given how compact I expect my code to be in this upcoming design.
2026-02-12 22:11:28 <amby        > rp2040 has 264k of onboard ram and can address 16M of external flash
2026-02-12 22:11:34 <KipIngram   > veltas: I could probably nose around in the installed tool base and find the obj file that has gpio_reset_pin() in it and disassemble it.
2026-02-12 22:11:46 <KipIngram   > but I think I can suss it out from the doc.
2026-02-12 22:12:02 <amby        > rp2350 has double the ram and can address double the flash (more importantly it can address two separate chips, which means you can give it 16M of external ram too)
2026-02-12 22:12:36 <amby        > and yes 512k will be plenty
2026-02-12 22:13:04 <KipIngram   > amby: This is a $6 gadget with WiFi, Bluetooth, a bunch of A/D, and some digital I/O.  Counter/timers, a bunch of other stuff.
2026-02-12 22:13:20 <KipIngram   > What I have in mind for it is to incorporate it into future  hardware projects as "the brains."
2026-02-12 22:14:02 <KipIngram   > BTW - I do not plan on writing a full-on TCP/IP stack for this.  I want just enough to be able to do a dedicated point-to-point link between the ESP32 and my notebook.
2026-02-12 22:14:26 <KipIngram   > It doesn't need all the fancy error handling and retrying and so on.  Sort of simplest possible "good path" implementation.
2026-02-12 22:14:36 <amby        > the other nice thing about rp2040/rp2350 is the PIO
2026-02-12 22:14:41 <KipIngram   > Even so I expect it to be hard, but I really wouldn't even try to write a truly robust full stack.
2026-02-12 22:14:49 <amby        > basically a bunch of state machines rigged up to gpio pins
2026-02-12 22:14:58 <amby        > so you can implement your own high-speed hardware interfaces
2026-02-12 22:15:13 <amby        > for a simple example you could add a bunch more uarts
2026-02-12 22:15:19 <amby        > or output digital video
2026-02-12 22:15:29 <KipIngram   > That's pretty cool.
2026-02-12 22:15:53 <KipIngram   > If I want that for something I'd likely just slap an FPGA on the main board for that project.
2026-02-12 22:16:03 <KipIngram   > Or a CPLD.
2026-02-12 22:16:14 <amby        > it's certainly not as powerful as an fpga
2026-02-12 22:28:39 <KipIngram   > Ok, I found and disassembled gpio_reset_pin().  It's a hundred-ish instructions long, and some of it is calls to stuff.  And given it's a dissasembled obj there's really no telling what to.  I suspect I'm a lot better off using the technical reference and actually understanding it.
2026-02-12 22:30:39 <KipIngram   > All of this stuff seems to be WAY more complex and involved than it needs to be - lots of unnecessary abstraction.  It just seems to be the way of the world, whereas I'm interested in the most cutthroat, "get it done" approach possible.
2026-02-12 22:31:06 <KipIngram   > I'm still just reeling at how complicated they managed to make a simple compile / link process.  Holy cow.
2026-02-12 22:37:43 <amby        > yeah prebuilt gpio stuff is always really complicated
2026-02-12 22:38:02 <amby        > because in order to go from pin number to register and bit you actually need to do a decent amount of work
2026-02-12 22:38:13 <amby        > but like. you can skip all that by being slightly less lazy ahead of time
2026-02-12 22:52:23 <KipIngram   > Yes, I think a lot of this complexity comes from trying to have one code base support umpteen zillion different parts.  I do not care about that.
2026-02-12 22:53:04 <KipIngram   > At this machine code / low level I want code that works on THIS DEVICE and is as brutally simple and direct as possible.
2026-02-12 22:53:31 <veltas      > Go for it man
2026-02-12 22:53:36 <KipIngram   > The upper portions of this system will be written in Forth, and gien that it will all run on a byte-coded vm it should be TOTALLY portable.
2026-02-12 22:53:48 <KipIngram   > And then in between will be code in Forth, but doing platform specific things.
2026-02-12 22:54:50 <KipIngram   > It'll be the first code-threaded Forth I've ever done, but it's code threading on that vm, not on the bare cpu.
2026-02-12 22:55:10 <KipIngram   > So it will all look like data to the cpu.
2026-02-12 22:55:33 <KipIngram   > Only the vm instructions themselves will be RISCV code.
2026-02-12 22:55:59 <KipIngram   > And I expect all of that to fit in just a few kB.
2026-02-12 23:46:15 <KipIngram   > 4MB - the onboard flash is 4MB.
2026-02-12 23:46:23 <KipIngram   > esptool can tell that.