2025-06-25 11:04:57 <cleobuline  > forthBot: LOAD ini.fth
2025-06-25 11:04:57 <forthBot    > File ini.fth with moon loaded
2025-06-25 11:05:07 <cleobuline  > forthBot:  QUOTE
2025-06-25 11:05:07 <forthBot    > When we are dead we do not know that we are dead. It is for others that it is difficult. When we are stupid it is the same - Jean Claude Vandamme -
2025-06-25 13:05:07 <forthBot    > Environment for cleobuline inactive, freeing...
2025-06-25 19:37:14 <deadmarshal_> http://www.call-with-current-continuation.org/articles/forth.txt
2025-06-25 19:59:09 <lispmacs[work]> a nice long rant
2025-06-25 20:24:43 <ajhidd      > brilliant \3
2025-06-25 20:36:02 <xentrac     > "true, unveiled access to the machine's resources", if you mean memory and peripherals, anyway
2025-06-25 20:36:07 <xentrac     > not CPU
2025-06-25 20:44:59 <lispmacs[work]> I think forth is fascinating, but I'm still rather confused about what is the forth approach to building modular, reusable software. Per the rant, all "good" forth code is inherently easy to refactor and reuse, but you are still suppose to do everything from scratch by yourself. And you should never think about the future and how your code might need to be used by other projects; but also you need to pick the perfec
2025-06-25 20:45:00 <lispmacs[work]> t set of word names that are elegant, non-conflicting, and easy to understand.
2025-06-25 20:47:35 <lispmacs[work]> programming in forth can be fun, but I found I got quickly tired of reimplementing SPI on every single microcontroller I tried out. Because, I guess, already having an implementation of SPI available would be a violation of the paradigm (?)
2025-06-25 20:47:44 <xentrac     > well, Chuck Moore believes strongly in modularity but not in reusability
2025-06-25 20:47:58 <xentrac     > but most Forth programmers are not as extreme
2025-06-25 20:51:11 <lispmacs[work]> Chuck Moore also said that operating systems are a scam, and we don't need them
2025-06-25 20:51:25 <xentrac     > yeah
2025-06-25 20:51:41 <lispmacs[work]> which is a very interesting statement, but I'm still trying to understand how we get to the place where we don't need that operating system
2025-06-25 20:51:53 <xentrac     > I can definitely sympathize with that point of view.  Dan Ingalls said something similar
2025-06-25 20:52:05 <xentrac     > but I'm using an operating system right now :)
2025-06-25 20:52:28 <xentrac     > I've used computers without an OS plenty of times
2025-06-25 20:52:56 <xentrac     > much of my childhood was in BASIC
2025-06-25 20:53:34 <xentrac     > and I almost never use an OS onAr
2025-06-25 20:53:39 <xentrac     > on Arduinos
2025-06-25 20:54:24 <lispmacs[work]> but all the BASIC implementations were built on a ROM with a system API available, right?
2025-06-25 20:56:11 <xentrac     > no
2025-06-25 20:56:43 <xentrac     > lots of them were the ROM and system API.  others were on microcomputers with just the barest of boot loaders in ROM
2025-06-25 20:57:39 <xentrac     > my H-8 had been upgraded with a boot loader ROM but the standard ROM only contained a front panel monitor program called PAM-8
2025-06-25 20:58:23 <xentrac     > if you wanted to boot BASIC or something else on a stock H-8, you needed to use PAM-8 to key in the bootloader
2025-06-25 20:59:29 <xentrac     > my uncle's Altair had been similarly upgraded with a program ROM, but the stock Altair didn't even have any ROM at all
2025-06-25 21:00:12 <xentrac     > if you wanted a monitor program you could toggle it in on front-panel switches and debug it by single-stepping the processor with the single-step switch
2025-06-25 21:00:45 <xentrac     > it provided the rough equivalent of PAM-8 in hardware without so much as 7-segment decoding
2025-06-25 21:23:15 <veltas      > lispmacs[work]: Chuck Moore ported his code around a lot, I don't think reusing code goes against the rules
2025-06-25 21:23:39 <veltas      > Forth was an evolution of code he was porting around, and one of the early boons was that it was fast to port his environment and code
2025-06-25 21:24:29 <veltas      > I would have guessed your SPI code would be mostly portable, or at least partly portable.  Did you try porting it?
2025-06-25 21:34:31 <crc         > lispmacs[work]: I always viewed it more as getting rid of the OS as a separate layer in the system. In an idealistic world, Forth (or whatever you prefer) is running on the hardware, and is the system you interact with and use. Nothing g
2025-06-25 21:34:49 <crc         > stopping you from dropping down & interacting with the real hardware underneath
2025-06-25 21:36:04 <crc         > (or at least, no layers you can't control/replace easily as needed)
2025-06-25 21:46:20 <veltas      > OS and drivers just abstract the machine to let you write the program, you can go without the OS if the machine is simpler and the application is better understood; otherwise don't
2025-06-25 22:00:36 <lispmacs[work]> so, forth IF AND ONLY IF machine is simple and application is narrowly focused?
2025-06-25 22:21:44 <xentrac     > having a simple machine definitely helps with not needing an operating system
2025-06-25 22:24:29 <xentrac     > I'm not sure about better-understood applications or not
2025-06-25 22:27:10 <xentrac     > I agree that Chuck wanted to be able to port code.  What he didn't want was to generalize it
2025-06-25 22:29:56 <xentrac     > that is, he didn't want to maintain code that wasn't needed for the problem at hand
2025-06-25 22:33:34 <tpbsd       > chuck was very specific about not including code that wasnt needed, no extra code!
2025-06-25 22:34:05 <lispmacs[work]> but, say, with SPI: SPI, from the application developers point of view, is the same regardless of which microcontroller you want to use. You want your microcontroller to send data to some SPI peripheral. Of course, implementation of SPI i/o on the microcontroller is different for every microcontroller
2025-06-25 22:35:01 <xentrac     > yeah.  same with drawing ASCII characters on a terminal, no?
2025-06-25 22:35:02 <tpbsd       > of course, the definition of code thats 'not needed' can vary, for instance 1/2 my Forth code (or more) is used on device self test routines and fo service and may never be used
2025-06-25 22:35:29 <lispmacs[work]> is it some kind of perverse stupidity for a programmer to want to be able to write the same SPI code that works on all his different microcontrollers, without having to implement the SPI microcontroller i/o himself?
2025-06-25 22:35:54 <xentrac     > at-xy emit key cr type . and pictured output are kind of the same on most Forths, right?
2025-06-25 22:36:14 <lispmacs[work]> or just use whatever SPI API was provided by whoever got around to implementing the SPI microcontroller I/O?
2025-06-25 22:36:27 <xentrac     > it sounds like a reasonable thing to want to me
2025-06-25 22:36:57 <lispmacs[work]> mr rant guy seems to be saying that is just letting yourself be "a cog in the wheel" and robbing yourself of the joy of intelligent programming
2025-06-25 22:37:26 <lispmacs[work]> depending on somebodies abstraction, and not doing it all yourself
2025-06-25 22:38:50 <xentrac     > well, sometimes it's simpler to implement your own SPI driver.  but normally I think you'd want the SPI driver on every MCU to use the same API
2025-06-25 22:39:18 <xentrac     > I mean, maybe not always?  But usually
2025-06-25 22:39:37 <tpbsd       > lispmacs[work], if a expert designer for one particular MCU writes handlers for all the peripherals in his MCU then sooner rather than later, he will have code he can reuse forever for that mcu, no need to use anyone elses code ?
2025-06-25 22:40:19 <xentrac     > like, there might be some tradeoffs that just about force you to use an inconvenient API on some microcontroller
2025-06-25 22:41:40 <lispmacs[work]> tpbsd: great, but say that guy is not me: am I breaking with the forth way by choising to use his handler code?
2025-06-25 22:41:58 <ajhidd      > lispmacs[work]: You are very specific about your needs. No bad in using someone else's code. Mr Rant Guy talks about situation that you no longer understand all the layers
2025-06-25 22:42:13 <xentrac     > certainly with Felix's understanding of it, lispmacs[work]
2025-06-25 22:42:55 <tpbsd       > lispmacs[work], not in my observation, no, because the Forth people I know refuse to use anyone elses code, they always write their own
2025-06-25 22:43:23 <xentrac     > maybe we're just hard to get along with :-)
2025-06-25 22:43:55 <tpbsd       > xentrac, I think 'fiercely independent' is a more apt term
2025-06-25 22:45:21 <MrMobius    >  I would lean towards redoing the SPI code every time especially if you're doing interrupts or DMA
2025-06-25 22:45:25 <tpbsd       > lispmacs[work], it's more a driven need than a 'way' in their case. They believe they can do it better, faster more efficient
2025-06-25 22:46:12 <MrMobius    > rather than try to shoehorn a new chip into the API you invented which can't foresee all the mcus you might use someday when some of them have whacker peripherals than others
2025-06-25 22:46:23 <xentrac     > tpbsd: haha
2025-06-25 22:46:24 <tpbsd       > MrMobius, so true
2025-06-25 22:47:19 <xentrac     > MrMobius: maybe there's a reasonable compromise API that can work for many of them.  like 5 block update
2025-06-25 22:47:32 <tpbsd       > and anyway, isnt the mcu 'technical manual' the only API anyone needs ?
2025-06-25 22:47:57 <xentrac     > sometimes software can be useful
2025-06-25 22:48:44 <tpbsd       > xentrac, I'll say it can, the Forth I use was not written by me, I could never write a Forth like it, Im a technician not a programmer
2025-06-25 22:49:23 <tpbsd       > I understand all the hardware that programmers dont, I understand the underlying electronics that they avoid
2025-06-25 22:50:00 <tpbsd       > Mecrisp-Stellaris makes it easy for me to write any code I need for any peripheral, anytime
2025-06-25 22:50:48 <tpbsd       > I dont use anyone elses code because I dont need to, it's as easy as eating apple pie to write my own Forth code for any peripheral
2025-06-25 22:50:56 <xentrac     > a thing I kind of disagree with in the rant is "just shoddily designed by hardware engineers that have decided that the "nice" part of the interface can be done by the software guys.
2025-06-25 22:51:00 <xentrac     > "
2025-06-25 22:52:16 <xentrac     > I think it's often best to optimize the hardware to be efficient and performant
2025-06-25 22:52:34 <xentrac     > even if that adds some complexity to the software
2025-06-25 22:52:50 <xentrac     > that's not shoddiness
2025-06-25 22:53:05 <tpbsd       > xentrac, I disagree with that comment also as software people generally have no idea how difficult it is to make a mcu in 40nm nodes with all the peripherals, now noise, low power, high power, fast, bug free
2025-06-25 22:53:31 <tpbsd       > I think it's amazin that such things are even possible
2025-06-25 22:53:50 <xentrac     > yeah; I was thinking also about things like analog interfaces
2025-06-25 22:54:20 <tpbsd       > even harder, as there are so many combinations, power and heat requirements
2025-06-25 22:54:57 <tpbsd       > analog doesnt shrink, it took a massive effort for STMicro to shrink flash to 40nm from 90nm
2025-06-25 22:55:40 <tpbsd       > their "G" series is all 40nm node, everything else is 90mn
2025-06-25 22:57:23 <xentrac     > yeah
2025-06-25 22:57:34 <tpbsd       > one gets the impression that 90nm is 'huge' now, with all the talk about 2,5 and 7nm, yet my mcu, the STm32F051 while rated at 48MHz (3mA), runs fine at 108Mhz, but does draw 30mA
2025-06-25 22:57:52 <tpbsd       > and it's 90nm
2025-06-25 22:58:20 <xentrac     > as an example you can pretty easily do a low-pass zero-phase filter in software that's, say, 36dB of attentuation per octave
2025-06-25 22:58:45 <xentrac     > you could *try* to do that in analog hardware but you'd almost certainly fail
2025-06-25 22:59:02 <tpbsd       > 90nm made for easy DAC, ADC, comparators etc, peripherals that are all missing in the small nodes
2025-06-25 22:59:25 <xentrac     > you can do it in digital hardware, but if your data rate is low, it's probably better to do it in software
2025-06-25 22:59:35 <xentrac     > 30mA, wow
2025-06-25 22:59:46 <xentrac     > did you have to overvolt it?
2025-06-25 23:00:00 <tpbsd       > xentrac, yeah, a lot of stuff is just easier (or possible) in software rather than hardware
2025-06-25 23:00:30 <xentrac     > *attenuation
2025-06-25 23:00:31 <tpbsd       > no, I ran a test unit for 12 months and at high 46C temps and had no problems
2025-06-25 23:00:35 <xentrac     > nice
2025-06-25 23:00:59 <xentrac     > dunno if you've seen, IHP is doing a shuttle program for 130nm SiGe BiCMOS now
2025-06-25 23:01:00 <tpbsd       > but the flash wont write at 108Mhz, it reads fine tho
2025-06-25 23:01:23 <xentrac     > https://fdl-conference.com/doc/openpdk_5Sep24-FDL_SAndreev.pdf
2025-06-25 23:01:35 <tpbsd       > and as I do all my development in RAM, that was fine also
2025-06-25 23:01:49 <xentrac     > https://www.ihp-microelectronics.com/services/research-and-prototyping-service/mpw-prototyping-service/schedule-price-list is a bit steep
2025-06-25 23:01:55 <xentrac     > but Tiny Tapeout is doing a thing with them
2025-06-25 23:02:28 <xentrac     > this is in a process where their fastest transistors have a 350GHz transition frequency, and they've succeeded in fabbing a 450GHz oscillator
2025-06-25 23:02:53 <xentrac     > hopefully this won't be the last IHP Tiny Tapeout: https://tinytapeout.com/runs/ttihp0p2/
2025-06-25 23:03:22 <xentrac     > uh I guess it wasn't: https://tinytapeout.com/runs/ttihp25a/
2025-06-25 23:04:29 <xentrac     > mostly though it seems to have been "wasted" on digital designs
2025-06-25 23:06:45 <tpbsd       > hopefully SiGe BiCMOS will allow some new tech
2025-06-25 23:07:38 <tpbsd       > they want 60Ghz in home wifi now and need new tech to do that
2025-06-25 23:08:02 <tpbsd       > lol, 60ghz bluetooth in your watch
2025-06-25 23:08:15 <xentrac     > I feel like 350GHz ft is maybe capable of that?
2025-06-25 23:08:28 <xentrac     > I don't know much about RF tho
2025-06-25 23:09:27 <xentrac     > anyway maybe you'd be interested in submitting designs for the next IHP Tiny Tapeout if there is one
2025-06-25 23:10:25 <tpbsd       > me, Im long retired and tho Ive been in RF all my life, it was at the user end with proven tech, not bleeding edge
2025-06-25 23:11:20 <xentrac     > well, I imagine some things are different at 60GHz than at 600MHz, and some things aren't
2025-06-25 23:11:44 <tpbsd       > sure I can do a 40dB attenuator stripline anytime, including the housing and connectors, make it weatherproof etc, but thats all manual skills, no hi tech
2025-06-25 23:12:32 <xentrac     > 883 designs in this second one, jesus
2025-06-25 23:13:00 <tpbsd       > I think it's far to say that even at 2.5Ghz a lot of things that are obvious in their function at 900 Mhz are a mystery at 2.5Ghz and above
2025-06-25 23:13:42 <tpbsd       > hence the well used term "dark magic microwave"
2025-06-25 23:14:00 <xentrac     > well, especially when you make them big enough to see with your eyes
2025-06-25 23:14:19 <xentrac     > but maybe at 130nm 2.4GHz things are simpler than on a PCB
2025-06-25 23:16:41 <tpbsd       > it's all dark voodo magic, take a look at some of the IC decapping sites sometime. At uhf, things are just different
2025-06-25 23:17:15 <tpbsd       > that straight looking piece of silicon may be a transformer even tho there are no turns
2025-06-25 23:17:25 <tpbsd       > that kind of stuff
2025-06-25 23:18:10 <xentrac     > yeah
2025-06-25 23:18:31 <xentrac     > I've been enjoying Ken Shirriff's decapping reverse engineering, but that's almost all digital
2025-06-25 23:19:01 <xentrac     > not all: http://www.righto.com/2015/10/inside-ubiquitous-741-op-amp-circuits.html
2025-06-25 23:23:12 <tpbsd       > yeah, all that stuff is fascinating, tho the 741 ia virtually stoneage tech
2025-06-25 23:23:21 <tpbsd       > it was my first op amp
2025-06-25 23:24:08 <xentrac     > he's targeting beginners, but that's okay, because when it comes to things like op-amp compensation, Booth multipliers, Kogge–Stone lookahead carry, and PLAs, I'm definitely a beginner
2025-06-25 23:24:26 <xentrac     > yeah, it's kind of surprising that people still use the 741 in new designs
2025-06-25 23:25:18 <xentrac     > the LM324 is almost as old and considerably better.  and the LM324B is a drop-in replacement that's better than any other cheap op-amp as far as I can tell
2025-06-25 23:25:36 <xentrac     > except for the crossover delay distortion I guess
2025-06-25 23:27:31 <tpbsd       > agreed, the LM324 is a decent opamp all round
2025-06-25 23:27:42 <tpbsd       > Ive used it forever
2025-06-25 23:28:12 <tpbsd       > these days I use SMT opamps, like the OP* series, fast, rail to rail, low power
2025-06-25 23:28:35 <tpbsd       > this era is a electronics designers paradise
2025-06-25 23:28:46 <xentrac     > OP* is pretty broad :)
2025-06-25 23:29:13 <tpbsd       > I have several models of that series
2025-06-25 23:29:33 <tpbsd       > I even have chopper op amps
2025-06-25 23:30:19 <tpbsd       > luckily I made a big op amp order pre covid before the supply lines were wrecked
2025-06-25 23:30:54 <xentrac     > what did you order?
2025-06-25 23:32:40 <tpbsd       > a lot of different op apps back then
2025-06-25 23:33:19 <tpbsd       > but I dont have my stock list on-line atm as Im still reviewing AI and needed to switch to Linux to do that
2025-06-25 23:33:37 <tpbsd       > so all my ZFS data is off line for a few more days
2025-06-25 23:44:42 <xentrac     > hmm, I think there's zfs-fuse
2025-06-25 23:45:46 <tpbsd       > Linux ZFS abd FreeBSD ZFS are not compatible, it was the first thing I checked
2025-06-25 23:46:09 <tpbsd       > I cant read my FreeBSD ZFS data with Linux
2025-06-25 23:46:40 <xentrac     > aah
2025-06-25 23:46:40 <tpbsd       > Solaris ZFS is probably different again but I havent checked
2025-06-25 23:47:08 <tpbsd       > it's ok, Il building a new FreeBSD NAS and a AI pc atm
2025-06-25 23:47:34 <xentrac     > for llama.cpp or what?
2025-06-25 23:47:35 <tpbsd       > so everything will work together just fine, I have all the parts now
2025-06-25 23:48:29 <tpbsd       > no, I just use ollama.com
2025-06-25 23:48:50 <tpbsd       > Im only a software user really, being a hardware guy
2025-06-25 23:48:50 <xentrac     > I think that uses llama.cpp?
2025-06-25 23:49:05 <tpbsd       > Ive no idea and no desire to find out
2025-06-25 23:49:28 <tpbsd       > ollama is very convenient, it pulls the AI model and runs it
2025-06-25 23:50:55 <tpbsd       > I'm a AI user, not a AI builder
2025-06-25 23:51:52 <tpbsd       > and as someone here remarked, AI is clueless about Forth because it has so little training data for it
2025-06-25 23:52:26 <tpbsd       > the mystery of Forth is therefore preserved in the AI era !
2025-06-25 23:53:04 <tpbsd       > even the new kid on the block 'neovim' editor has no Forth LSP
2025-06-25 23:53:33 <tpbsd       > it has LSP's for every language I've never heard of, but not one for Forth!
2025-06-25 23:53:51 <xentrac     > yeah, also I've found that LLMs are bad at unusual programming languages
2025-06-25 23:54:07 <xentrac     > like, I get a lot of syntax errors in Lisp
2025-06-25 23:54:07 <tpbsd       > ahh
2025-06-25 23:54:25 <xentrac     > it tries to do f(x) instead of (f x) a lot
2025-06-25 23:54:54 <xentrac     > and I get a lot of 0-based indexing errors in Lua (which indexes arrays from 1)
2025-06-25 23:55:00 <tpbsd       > it's so sad that LLM's are only good at all the popular languages, like Python, java etc
2025-06-25 23:55:37 <xentrac     > even unpopular languages work pretty well if they're not syntactically unusual
2025-06-25 23:56:36 <xentrac     > normally the LSP server for a language is provided by the implementation of the language
2025-06-25 23:56:46 <xentrac     > the compiler or whatevr
2025-06-25 23:56:56 <tpbsd       > maybe thats why there isnt a Forth LSP
2025-06-25 23:57:32 <tpbsd       > not that I need one, I just feel left out and all back of the bus without a Forth LSP
2025-06-25 23:57:52 <tpbsd       > I'm the 'poor relative' using Forth
2025-06-25 23:58:35 <xentrac     > in theory you could write an LSP for Mecrisp
2025-06-25 23:58:47 <tpbsd       > but Im making up for it in my own way, Ive developed a embedded Forth system I call plang2 that runs as a neovim plugin
2025-06-25 23:58:57 <xentrac     > oh?
2025-06-25 23:59:11 <tpbsd       > no, I couldnt, I looked at the LSP specs once and ran away screaming