11:04:57
##forth
<cleobuline>
forthBot: LOAD ini.fth
11:04:57
##forth
<forthBot>
File ini.fth with moon loaded
11:05:07
##forth
<cleobuline>
forthBot: QUOTE
11:05:07
##forth
<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 -
13:05:07
##forth
<forthBot>
Environment for cleobuline inactive, freeing...
19:59:09
##forth
<lispmacs[work]>
a nice long rant
20:24:43
##forth
<ajhidd>
brilliant \3
20:36:02
##forth
<xentrac>
"true, unveiled access to the machine's resources", if you mean memory and peripherals, anyway
20:36:07
##forth
<xentrac>
not CPU
20:44:59
##forth
<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
20:45:00
##forth
<lispmacs[work]>
t set of word names that are elegant, non-conflicting, and easy to understand.
20:47:35
##forth
<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 (?)
20:47:44
##forth
<xentrac>
well, Chuck Moore believes strongly in modularity but not in reusability
20:47:58
##forth
<xentrac>
but most Forth programmers are not as extreme
20:51:11
##forth
<lispmacs[work]>
Chuck Moore also said that operating systems are a scam, and we don't need them
20:51:25
##forth
<xentrac>
yeah
20:51:41
##forth
<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
20:51:53
##forth
<xentrac>
I can definitely sympathize with that point of view. Dan Ingalls said something similar
20:52:05
##forth
<xentrac>
but I'm using an operating system right now :)
20:52:28
##forth
<xentrac>
I've used computers without an OS plenty of times
20:52:56
##forth
<xentrac>
much of my childhood was in BASIC
20:53:34
##forth
<xentrac>
and I almost never use an OS onAr
20:53:39
##forth
<xentrac>
on Arduinos
20:54:24
##forth
<lispmacs[work]>
but all the BASIC implementations were built on a ROM with a system API available, right?
20:56:11
##forth
<xentrac>
no
20:56:43
##forth
<xentrac>
lots of them were the ROM and system API. others were on microcomputers with just the barest of boot loaders in ROM
20:57:39
##forth
<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
20:58:23
##forth
<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
20:59:29
##forth
<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
21:00:12
##forth
<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
21:00:45
##forth
<xentrac>
it provided the rough equivalent of PAM-8 in hardware without so much as 7-segment decoding
21:23:15
##forth
<veltas>
lispmacs[work]: Chuck Moore ported his code around a lot, I don't think reusing code goes against the rules
21:23:39
##forth
<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
21:24:29
##forth
<veltas>
I would have guessed your SPI code would be mostly portable, or at least partly portable. Did you try porting it?
21:34:31
##forth
<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
21:34:49
##forth
<crc>
stopping you from dropping down & interacting with the real hardware underneath
21:36:04
##forth
<crc>
(or at least, no layers you can't control/replace easily as needed)
21:46:20
##forth
<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
22:00:36
##forth
<lispmacs[work]>
so, forth IF AND ONLY IF machine is simple and application is narrowly focused?
22:21:44
##forth
<xentrac>
having a simple machine definitely helps with not needing an operating system
22:24:29
##forth
<xentrac>
I'm not sure about better-understood applications or not
22:27:10
##forth
<xentrac>
I agree that Chuck wanted to be able to port code. What he didn't want was to generalize it
22:29:56
##forth
<xentrac>
that is, he didn't want to maintain code that wasn't needed for the problem at hand
22:33:34
##forth
<tpbsd>
chuck was very specific about not including code that wasnt needed, no extra code!
22:34:05
##forth
<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
22:35:01
##forth
<xentrac>
yeah. same with drawing ASCII characters on a terminal, no?
22:35:02
##forth
<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
22:35:29
##forth
<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?
22:35:54
##forth
<xentrac>
at-xy emit key cr type . and pictured output are kind of the same on most Forths, right?
22:36:14
##forth
<lispmacs[work]>
or just use whatever SPI API was provided by whoever got around to implementing the SPI microcontroller I/O?
22:36:27
##forth
<xentrac>
it sounds like a reasonable thing to want to me
22:36:57
##forth
<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
22:37:26
##forth
<lispmacs[work]>
depending on somebodies abstraction, and not doing it all yourself
22:38:50
##forth
<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
22:39:18
##forth
<xentrac>
I mean, maybe not always? But usually
22:39:37
##forth
<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 ?
22:40:19
##forth
<xentrac>
like, there might be some tradeoffs that just about force you to use an inconvenient API on some microcontroller
22:41:40
##forth
<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?
22:41:58
##forth
<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
22:42:13
##forth
<xentrac>
certainly with Felix's understanding of it, lispmacs[work]
22:42:55
##forth
<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
22:43:23
##forth
<xentrac>
maybe we're just hard to get along with :-)
22:43:55
##forth
<tpbsd>
xentrac, I think 'fiercely independent' is a more apt term
22:45:21
##forth
<MrMobius>
I would lean towards redoing the SPI code every time especially if you're doing interrupts or DMA
22:45:25
##forth
<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
22:46:12
##forth
<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
22:46:23
##forth
<xentrac>
tpbsd: haha
22:46:24
##forth
<tpbsd>
MrMobius, so true
22:47:19
##forth
<xentrac>
MrMobius: maybe there's a reasonable compromise API that can work for many of them. like 5 block update
22:47:32
##forth
<tpbsd>
and anyway, isnt the mcu 'technical manual' the only API anyone needs ?
22:47:57
##forth
<xentrac>
sometimes software can be useful
22:48:44
##forth
<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
22:49:23
##forth
<tpbsd>
I understand all the hardware that programmers dont, I understand the underlying electronics that they avoid
22:50:00
##forth
<tpbsd>
Mecrisp-Stellaris makes it easy for me to write any code I need for any peripheral, anytime
22:50:48
##forth
<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
22:50:56
##forth
<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.
22:51:00
##forth
<xentrac>
"
22:52:16
##forth
<xentrac>
I think it's often best to optimize the hardware to be efficient and performant
22:52:34
##forth
<xentrac>
even if that adds some complexity to the software
22:52:50
##forth
<xentrac>
that's not shoddiness
22:53:05
##forth
<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
22:53:31
##forth
<tpbsd>
I think it's amazin that such things are even possible
22:53:50
##forth
<xentrac>
yeah; I was thinking also about things like analog interfaces
22:54:20
##forth
<tpbsd>
even harder, as there are so many combinations, power and heat requirements
22:54:57
##forth
<tpbsd>
analog doesnt shrink, it took a massive effort for STMicro to shrink flash to 40nm from 90nm
22:55:40
##forth
<tpbsd>
their "G" series is all 40nm node, everything else is 90mn
22:57:23
##forth
<xentrac>
yeah
22:57:34
##forth
<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
22:57:52
##forth
<tpbsd>
and it's 90nm
22:58:20
##forth
<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
22:58:45
##forth
<xentrac>
you could *try* to do that in analog hardware but you'd almost certainly fail
22:59:02
##forth
<tpbsd>
90nm made for easy DAC, ADC, comparators etc, peripherals that are all missing in the small nodes
22:59:25
##forth
<xentrac>
you can do it in digital hardware, but if your data rate is low, it's probably better to do it in software
22:59:35
##forth
<xentrac>
30mA, wow
22:59:46
##forth
<xentrac>
did you have to overvolt it?
23:00:00
##forth
<tpbsd>
xentrac, yeah, a lot of stuff is just easier (or possible) in software rather than hardware
23:00:30
##forth
<xentrac>
*attenuation
23:00:31
##forth
<tpbsd>
no, I ran a test unit for 12 months and at high 46C temps and had no problems
23:00:35
##forth
<xentrac>
nice
23:00:59
##forth
<xentrac>
dunno if you've seen, IHP is doing a shuttle program for 130nm SiGe BiCMOS now
23:01:00
##forth
<tpbsd>
but the flash wont write at 108Mhz, it reads fine tho
23:01:35
##forth
<tpbsd>
and as I do all my development in RAM, that was fine also
23:01:55
##forth
<xentrac>
but Tiny Tapeout is doing a thing with them
23:02:28
##forth
<xentrac>
this is in a process where their fastest transistors have a 350GHz transition frequency, and they've succeeded in fabbing a 450GHz oscillator
23:04:29
##forth
<xentrac>
mostly though it seems to have been "wasted" on digital designs
23:06:45
##forth
<tpbsd>
hopefully SiGe BiCMOS will allow some new tech
23:07:38
##forth
<tpbsd>
they want 60Ghz in home wifi now and need new tech to do that
23:08:02
##forth
<tpbsd>
lol, 60ghz bluetooth in your watch
23:08:15
##forth
<xentrac>
I feel like 350GHz ft is maybe capable of that?
23:08:28
##forth
<xentrac>
I don't know much about RF tho
23:09:27
##forth
<xentrac>
anyway maybe you'd be interested in submitting designs for the next IHP Tiny Tapeout if there is one
23:10:25
##forth
<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
23:11:20
##forth
<xentrac>
well, I imagine some things are different at 60GHz than at 600MHz, and some things aren't
23:11:44
##forth
<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
23:12:32
##forth
<xentrac>
883 designs in this second one, jesus
23:13:00
##forth
<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
23:13:42
##forth
<tpbsd>
hence the well used term "dark magic microwave"
23:14:00
##forth
<xentrac>
well, especially when you make them big enough to see with your eyes
23:14:19
##forth
<xentrac>
but maybe at 130nm 2.4GHz things are simpler than on a PCB
23:16:41
##forth
<tpbsd>
it's all dark voodo magic, take a look at some of the IC decapping sites sometime. At uhf, things are just different
23:17:15
##forth
<tpbsd>
that straight looking piece of silicon may be a transformer even tho there are no turns
23:17:25
##forth
<tpbsd>
that kind of stuff
23:18:10
##forth
<xentrac>
yeah
23:18:31
##forth
<xentrac>
I've been enjoying Ken Shirriff's decapping reverse engineering, but that's almost all digital
23:23:12
##forth
<tpbsd>
yeah, all that stuff is fascinating, tho the 741 ia virtually stoneage tech
23:23:21
##forth
<tpbsd>
it was my first op amp
23:24:08
##forth
<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
23:24:26
##forth
<xentrac>
yeah, it's kind of surprising that people still use the 741 in new designs
23:25:18
##forth
<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
23:25:36
##forth
<xentrac>
except for the crossover delay distortion I guess
23:27:31
##forth
<tpbsd>
agreed, the LM324 is a decent opamp all round
23:27:42
##forth
<tpbsd>
Ive used it forever
23:28:12
##forth
<tpbsd>
these days I use SMT opamps, like the OP* series, fast, rail to rail, low power
23:28:35
##forth
<tpbsd>
this era is a electronics designers paradise
23:28:46
##forth
<xentrac>
OP* is pretty broad :)
23:29:13
##forth
<tpbsd>
I have several models of that series
23:29:33
##forth
<tpbsd>
I even have chopper op amps
23:30:19
##forth
<tpbsd>
luckily I made a big op amp order pre covid before the supply lines were wrecked
23:30:54
##forth
<xentrac>
what did you order?
23:32:40
##forth
<tpbsd>
a lot of different op apps back then
23:33:19
##forth
<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
23:33:37
##forth
<tpbsd>
so all my ZFS data is off line for a few more days
23:44:42
##forth
<xentrac>
hmm, I think there's zfs-fuse
23:45:46
##forth
<tpbsd>
Linux ZFS abd FreeBSD ZFS are not compatible, it was the first thing I checked
23:46:09
##forth
<tpbsd>
I cant read my FreeBSD ZFS data with Linux
23:46:40
##forth
<xentrac>
aah
23:46:40
##forth
<tpbsd>
Solaris ZFS is probably different again but I havent checked
23:47:08
##forth
<tpbsd>
it's ok, Il building a new FreeBSD NAS and a AI pc atm
23:47:34
##forth
<xentrac>
for llama.cpp or what?
23:47:35
##forth
<tpbsd>
so everything will work together just fine, I have all the parts now
23:48:29
##forth
<tpbsd>
no, I just use ollama.com
23:48:50
##forth
<tpbsd>
Im only a software user really, being a hardware guy
23:48:50
##forth
<xentrac>
I think that uses llama.cpp?
23:49:05
##forth
<tpbsd>
Ive no idea and no desire to find out
23:49:28
##forth
<tpbsd>
ollama is very convenient, it pulls the AI model and runs it
23:50:55
##forth
<tpbsd>
I'm a AI user, not a AI builder
23:51:52
##forth
<tpbsd>
and as someone here remarked, AI is clueless about Forth because it has so little training data for it
23:52:26
##forth
<tpbsd>
the mystery of Forth is therefore preserved in the AI era !
23:53:04
##forth
<tpbsd>
even the new kid on the block 'neovim' editor has no Forth LSP
23:53:33
##forth
<tpbsd>
it has LSP's for every language I've never heard of, but not one for Forth!
23:53:51
##forth
<xentrac>
yeah, also I've found that LLMs are bad at unusual programming languages
23:54:07
##forth
<xentrac>
like, I get a lot of syntax errors in Lisp
23:54:07
##forth
<tpbsd>
ahh
23:54:25
##forth
<xentrac>
it tries to do f(x) instead of (f x) a lot
23:54:54
##forth
<xentrac>
and I get a lot of 0-based indexing errors in Lua (which indexes arrays from 1)
23:55:00
##forth
<tpbsd>
it's so sad that LLM's are only good at all the popular languages, like Python, java etc
23:55:37
##forth
<xentrac>
even unpopular languages work pretty well if they're not syntactically unusual
23:56:36
##forth
<xentrac>
normally the LSP server for a language is provided by the implementation of the language
23:56:46
##forth
<xentrac>
the compiler or whatevr
23:56:56
##forth
<tpbsd>
maybe thats why there isnt a Forth LSP
23:57:32
##forth
<tpbsd>
not that I need one, I just feel left out and all back of the bus without a Forth LSP
23:57:52
##forth
<tpbsd>
I'm the 'poor relative' using Forth
23:58:35
##forth
<xentrac>
in theory you could write an LSP for Mecrisp
23:58:47
##forth
<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
23:58:57
##forth
<xentrac>
oh?
23:59:11
##forth
<tpbsd>
no, I couldnt, I looked at the LSP specs once and ran away screaming