2026-03-01 03:02:30 There is no cache between internal RAM and the CPU in this chip. However, there is between the CPU and the external memory, and code can execute from there too, so that could necessitate it. 2026-03-01 03:04:47 No documented cache, at least. 2026-03-01 03:06:06 This really isn't the right place to put the instruction - it really ought to go immediately after writing code to RAM. This is just the only inline assembly I have in this program, so it was convenient. 2026-03-01 03:08:02 You know, I hadn't realized until some videos I watched in the last few days that it's now considered taboo to call the period from the fall of the Roman Empire up until the some hundreds of years later (re: European history) "the Dark Ages." Apparently that's politically incorrect now. 2026-03-01 03:13:13 I just commented out that fence.i instruction and rebuilt it. It still works. I'm going to use it as directed, but it doesn't appear to be entirely critical. 2026-03-01 03:14:58 whats the opposite of "The Dark Ages" ? I belive it's "the age of enlightenment" ? 2026-03-01 03:15:23 during this perod of time, Monasteries became the centers of learning, where monks copied classical texts and preserved some knowledge, acting as the only centers of literacy. 2026-03-01 03:15:26 I was taught that the Enlightenment generally followed the Dark Ages. 2026-03-01 03:15:34 Right. 2026-03-01 03:15:50 And the quality of that learning generally degraded, even where it was still pursued. 2026-03-01 03:16:43 it's interesting that some want to minimise the use of the term "Dark Ages", perhaps because in a way, we might be experiencing one right now 2026-03-01 03:17:08 These days the scholars call it "early middle ages." 2026-03-01 03:18:09 I think people just like to find things to attack. 2026-03-01 03:18:39 Gives them an opportunity to strut around online and perform for an audience. 2026-03-01 03:18:41 for instance "the age of enlightenment" welcomed active debate, including new and revolutionary ideas, while a 'Dark Ages' generally ensured that critical thinkers (anyone not part of the mob mindset) was put to death, usually by burning 2026-03-01 03:19:09 Yeah, dogma, and you darn well better not depart from it. 2026-03-01 03:19:35 this age seems to be one of 'tribes' again 2026-03-01 03:19:37 But isn't that a little like what cancel culture is these days? The contemporary from of burning? 2026-03-01 03:20:04 And it may be limited to that only because the people doing it don't hold enough power to literally burn people. 2026-03-01 03:20:05 I think so, I think theyre much alike 2026-03-01 03:20:23 I don't like to think what all these "we're so pure and good" people might get up to if they truly held unlimited power. 2026-03-01 03:20:27 they both hated original thought and sought to destroy it 2026-03-01 03:21:01 these are interesting times for sure 2026-03-01 03:21:17 Yeah - their attitude was "we have a book (or Book) that has all the right answers, so you can't differ." 2026-03-01 03:22:24 Forth users are well aware of the tribal cabals, they encounter anti Forth dogma all the time from people who have no clue about Forth 2026-03-01 03:22:25 Also "Oh, and by the way, we're the only ones who get to interpret it - we'll tell you what it means. Trust us." 2026-03-01 03:22:52 C is like a religion now, including in embedded 2026-03-01 03:23:17 hehe, yeah 'leave the driving to us!' 2026-03-01 03:24:34 While I like C (on the PC) and used to use it to make embedded devices before I 'discovered' Forth in 2014, I now avoid C on embedded totally in my own work 2026-03-01 03:25:05 I personally think that C on embedded is a terrible fit 2026-03-01 03:46:15 Well, at least you CAN do things to the hardware with it. You can't in all languages, like Python for instance. 2026-03-01 03:47:14 Forth is a better fit, though, by a large margin. 2026-03-01 03:48:11 Python is a joke in embedded, it only serves as a lesson in what not to use in embedded 2026-03-01 03:48:43 Yes. 2026-03-01 03:48:50 in my tests, Python (designed for embedded) is 30x slower than Forth on the same hardware 2026-03-01 03:48:58 30x ! 2026-03-01 03:49:13 That fits with my measurements too. 2026-03-01 03:49:42 python is pretty much for the Arduino hobby groups in my opinion 2026-03-01 03:50:05 Im sure it makes a fine 'cat door opener' 2026-03-01 03:51:25 I often end up shaking my head at the things the pythonstas consider advanced ... 'oh look, python on STM32 has DND!" 2026-03-01 03:51:54 have you noticed that Python generally avoids Makefiles ? 2026-03-01 04:00:48 No, I haven't really exposed myself to it at that level. I just use it for certain things that it is handy for. 2026-03-01 04:01:21 It's quite convenient for munging text files around. Preprocessors, postprocessors, etc. 2026-03-01 04:02:07 I'd like to steal some of its string handling bits and "Forth-ize" them. 2026-03-01 04:04:10 Forth has always been poor at string handling, I guess large telescope motors didn't really use strings ;-) 2026-03-01 04:52:45 not to mention that strings are incredibly memory costly, especially in my area of small embedded where 64KB og flash is considered a lot 2026-03-01 07:45:26 I have a vague feeling that parser combinators are a natural fit for Forth and will be easier to implement than in other languages 2026-03-01 11:35:51 tpbsd: What I'd really like to see, along side Forth's magnificent ability to "craft" with code, is an ability to "craft with data." I picture some kind of system for being able to desribe not only what a data structure would look like in RAM, but also what a literal version of such a data item would look like in the input stream. 2026-03-01 11:36:23 This would also be an enhancement, not out of the box. 2026-03-01 11:36:54 This would also be an enhancement, not out of the box. 2026-03-01 11:37:00 Whoops. Sorry. 2026-03-01 11:40:14 KipIngram, way too deep for me :) 2026-03-01 12:10:22 Well, the RAM side of it would just be something akin to C structures. Then I'd just decide how I thought it would be convenient to write down such a data item as a literal string, and then maybe the system would have a set of regular expressions I could add to to check the stream for such items. 2026-03-01 12:10:46 The thing is, it would be a step away from Forth's simple "space delimited words" approach, and that carries disadvantages too. 2026-03-01 12:10:59 It's complexity that I just haven't convinced myself I want to swallow. 2026-03-01 12:15:39 That space-delimited words thing is one of Forth's most core concepts. 2026-03-01 12:16:27 I guess I could duck that issue by not allowing spaces within such literals, but it then already starts to feel more clunky. 2026-03-01 12:23:57 Im just a Forth user, but I have reached that point where I love the challenge stack gymnastics after only 9 years ! 2026-03-01 12:25:27 up until then I thought that the stack was just work that had to be done, now I feel that this is the essence of Forth (my opinion only) 2026-03-01 12:27:05 and I've discovered that understanding the stack ops simplifies understanding other peoples Forth code 2026-03-01 12:27:27 which was a mystery in most cases to me for years 2026-03-01 13:43:00 I agree with you that handling the stack smoothly is a critical part of good Forth coding. 2026-03-01 13:43:39 And is sort of "global" - writing the whole program so that you don't wind up NEEDING to do excessive gymnastics is nice too. 2026-03-01 13:44:33 Of course if you're trying to glue together utilities written by others, you won't always have that luxury, so you find yourself doing more gymnastics. I think it's one of the reasons Chuck advocates writing each application "its own way."