00:00:00 --- log: started forth/20.03.22 00:31:48 Everyone gets to bed as I get on! 00:32:37 not me! 00:32:47 it's only 1830 hrs here 00:33:14 hmm, I wonder if anyone has had this idea before: I write out the stack on every line of code. what if you had a forth that would keep track of that and let you refer to those arguments by name? 00:33:18 and 32,00 C :( 00:33:37 and it was smart enough not to save copies of anything unless you were gonna access it later 00:34:18 MrMobius, I have a 'stack sensitive prompt' that turns red if there is anything on the stack 00:35:03 Nice 00:35:13 it's my equivalent of Zaphod Beeblebrox's 'peril sensitive sunglasses' ;-) 00:35:15 how does that work? 00:35:39 I would consider allowing a 'PS1' style variable to change prompt to current stack 00:35:50 if the stack depth is greater than 0, send out ansi escape sequence for red 00:36:23 less than 1, send ansi escape for black 00:36:53 what if its exactly in the middle? 00:37:00 0.5 ? 00:37:02 ya 00:37:15 then leave as is ;-) 00:38:11 I have decided to do a tokenised forth because I am interested in allowing as much colon definition complexity as possible with the somewhat limited RAM I have 00:38:39 veltas, what system is this? 00:38:44 ZX Spectrum 00:38:44 (sorry if I asked before) 00:39:05 It's okay I wouldn't remember either if you did 00:39:28 ok good ill probably ask you again then 00:39:36 \ designed for a white background with black text, but you can change to suit 00:39:36 : redstack.prompt ( -- ) 00:39:36 begin 00:39:36 depth 0 > if 00:39:36 red ." ok. " black cr \ prompt 00:39:37 else ." ok. " cr 00:39:39 then 00:39:40 query interpret 00:39:42 again 00:39:44 ; 00:39:46 00:39:49 : init.redstack.prompt ['] redstack.prompt hook-quit ! ; 00:39:50 00:39:52 \ init.redstack.prompt quit 00:40:00 I am guessing I am about half done with my forth words and at about 2500 bytes, 256 of which are the token lookup table so that part is not getting bigger 00:40:24 nice 00:40:28 I will definitely try and refactor more when I'm done, I want to see how small I can get it 00:40:56 anyone who forgets that veltas == Z80 needs some memory pills along with their Quinine 00:42:26 tp: depth 0 > if red then ." ok. " black cr 00:42:37 That is what I'd write to give you an idea of how dedicated I am to saving space 00:42:50 Even though it adds a redundant black 00:43:13 veltas, just be direct, my code is crap, it's ok, I'm a technician, I know it's crap 00:43:32 I don't think it's crap 00:43:39 My code is crap I'm a total beginner at Forth 00:43:59 i'll never take offence here at being corrected even hopefuly educated 00:44:20 The last few days I've got a significant amount of useful forth words working in colon definitions and have actually been writing Forth and I am getting practice again finally 00:44:39 tp, youre not writing for speed anyway so you an relax 00:44:57 rdrop-exit spent hours the other day pointing out that my stack comments were crap, afterwards I rewrote all my XML stuff to make them right, and now theyre so much BETTER! 00:45:27 How did they improve? 00:45:39 MrMobius, that's true, but as a Forther Im more and more insulted by my own bad and inefficient code 00:45:52 veltas, I'm glad you asked :) 00:46:13 My whole approach with Forth is to never write with speed and as soon as it matters I'm breaking out the assembly 00:46:28 which sounds perfectly fair 00:46:52 I find Mecrisp-Stellaris Forth about 3x slower than machine code created by C 00:46:58 meh. unlikely that your inefficiency will ever matter 00:47:07 It will on the Spectrum 00:47:11 true 00:47:17 In a game for example 00:47:19 and I find mecrisp-across faster and smaller than machine code created by C 00:47:45 MrMobius, I agree, in my world a 1MHz Z80 is probably way to fast 00:47:49 MrMobius: But I will not prematurely optimise, don't worry. I wait until it gets in the way then profile 00:48:14 but Forth infects all it's practitioners with a love for efficiency imho 00:49:27 so Forth can actually beat C for embedded in every area in my experience 00:49:57 hmm, what are basing on that its faster? 00:50:05 than C 00:50:05 tp: What advice did you get about stack comments? 00:50:09 tests on the same simple code 00:50:31 veltas, my stack comments were terrible, her is a old example 00:51:07 I wonder how Forth will compete with SDCC for Z80, the output of SDCC is not great (not their fault, Z80 does not lend well to C). 00:51:19 : PWR_CR_PLS ( %XXX -- ) 5 lshift PWR_CR ; \ PWR_CR_PLS PVD Level Selection 00:51:31 Forth will definitely beat it for space, which is usually more important in 8-bit code 00:51:47 and a new example 00:52:40 : GPIOC_MODER_MODER8 ( %bb -- x ) 16 lshift GPIOC_MODER ; \ GPIOC_MODER_MODER8, Port x configuration bits 00:53:03 and some more variations 00:53:32 \ NVIC_ICTR (read-only) 00:53:32 : NVIC_ICTR_INTLINESNUM ( %XXXX -- ) 0 lshift NVIC_ICTR bis! ; \ NVIC_ICTR_INTLINESNUM Total number of interrupt lines in groups 00:54:29 oops disregard that last one 00:55:26 \ GPIOC_IDR (read-only) 00:55:27 : GPIOC_IDR_IDR15? ( -- 1|0 ) 15 bit GPIOC_IDR bit@ ; \ GPIOC_IDR_IDR15, Port input data 00:55:54 So what has changed? Is it using 'b' to signify how many bits are being used in the field? 00:56:42 oops again, please ignore that one as well 00:57:01 a lot has changed, using 'b' is one of the simpler ones 00:57:13 Okay tp I will need an explanation on what stuff changed 00:57:28 the main thing that happened is I spent about 24 hrs rewriting my XLST code 00:57:32 Where you not putting result stack items into the comment? 00:57:35 Were* 00:57:57 veltas, thats definitely one of the things I wasnt doing right 00:58:17 the main problem is I dont code this stuff directly 00:58:25 it's all automatically generated 00:58:40 \ GPIOB_IDR (read-only) 00:58:41 : GPIOB_IDR_IDR15? ( -- 1|0 ) 15 bit GPIOB_IDR bit@ ; \ GPIOB_IDR_IDR15 00:58:52 take the above, it's a read-only register 00:59:58 my new code now looks for read-only registers and correctly sets the stack comment and provides the only useful action, 'bit@' which tests the single bit 01:00:17 it also adds "?" to the Word name 01:00:50 bit@ is a test and has only a 1 or 0 output 01:01:28 where a register is readonly but multiple bits the resultant Word is 01:01:47 : GPIOB_PUPDR_PUPDR15 ( %bb -- x ) 30 lshift GPIOB_PUPDR ; \ GPIOB_PUPDR_PUPDR15 01:02:05 oops not read only! 01:02:35 \ TSC_IOG5CR (read-only) 01:02:36 : TSC_IOG5CR_CNT? ( %bbbbbbbbbbbbbb -- x ) TSC_IOG5CR @ ; \ TSC_IOG5CR_CNT, Counter value 01:02:50 it replaces the bit@ with a '@' 01:03:04 there is a lot more but I wont bore anyone 01:03:21 Okay that makes more sense 01:03:37 Ill write it up and get comments from rdrop-exit when he is here next\ 01:03:41 Not bored just confused lol 01:03:45 Hmm 01:03:49 veltas, lol, I cant blame you! 01:04:25 I have 17 virtual desktops open and about 6 projects open and keep pasting data from the wrong projects! 01:04:43 um, make that 47 virtual desktops 01:07:03 so rdrop-exit's efforts getting me to see the error of my ways resulted in BIG improvents for me 01:07:12 nice 01:07:59 I have 3 virtual desktops right now 01:08:05 And like 8 windows 01:08:10 spread between them 01:08:21 Really only one project open 01:08:30 i started with one virtual desktop in 1996 01:08:42 Back then we called it a desktop 01:08:43 but more were added as the years passed by 01:08:54 not on Linux we didnt 01:09:03 KDE? 01:09:29 no, Ive never used kde or gnome, Im a speed freak and HATE any delays 01:09:35 I alos hate bling 01:09:37 good afternoon Forthwrights 01:09:51 rdrop-exit, the ZEN GURU of Forth! 01:10:13 hello Forth Master Technician (tm)! 01:10:16 KDE was pretty fast back in 1998, don't know about 1996 01:10:17 veltas would have been icewm or something really light 01:10:35 veltas I cant remember now 01:10:56 I have never been a big fan of virtual desktops, I only use it in my current window manager because it has no taskbar 01:11:03 Currently using dwm 01:11:46 I like less clutter too, but I apply it to my organisation. Then again, I don't work from home. At work I only usually have about 10 windows and 1 desktop, but I have 2 monitors. 01:12:39 veltas, Ive been using icewm as long as I can remember 01:12:47 my menu is decades old 01:13:28 I have been using tiling window managers based on dwm for at least a decade, only in the last couple years did I actually switch to dwm itself 01:13:38 I like having a short C program act as my window manager 01:14:15 The question is when are we getting a Forth-based window manager? 01:14:37 write one 01:14:40 rdrop-exit, your efforts educating me about the stack comments have paid huge dividends here! 01:14:49 cool tp 01:15:52 rdrop-exit, there are so many I need to write a article, but for now some can nee seen here, as always your criticism is most welcome 01:15:56 https://mecrisp-stellaris-folkdoc.sourceforge.io/touch-sensor.html#forth-code 01:16:42 i had a hard look at my XSLT code and made some really big changes, tidied it up etc 01:18:20 I have shown some older people at work some improvements to their code and how they work, and some of them have learned from it and some have totally ignored it 01:18:54 tp, what is the definition of TSC_CR ? 01:18:58 But I have actually been helpful with it, I didn't just go in and tell them all to use a particular paradigm or whatever, or moan about silly little things, and I have learned from them too. 01:19:02 it's a constant' 01:19:29 : TSC_CR_TSCE ( -- 1 ) 0 bit TSC_CR ; 01:19:46 veltas, rdrop-exit is most tactful, but Im a tech, no one needs to tread carefully around ne 01:19:47 me 01:20:45 One thing I learned (and had reinforced in Forth) was that using more than one integer type is an utter waste of time and money 01:21:05 rdrop-exit, hmm, now you mention it ... 01:21:07 if it's a constant than how does the stack end up with a single entry (i.e., the number 1)/ 01:21:10 ? 01:21:16 rdrop-exit, good point 01:21:35 it's a 'grey area' :) 01:21:41 ;-) 01:22:07 as ' 1 TSC_CR ' still leaves 1 on the stack 01:22:38 it's not until either a bic!, bis! or bit@ is added that the stack is empty 01:23:02 ie "TSC_CR_TSCE bit!" 01:23:19 than TSC_CR can't just be a constant or the result would be ( -- 1 ) 01:23:50 0 bit TSC_CR 01:23:53 -> 0 01:23:56 -> 1 01:24:04 -> 1 01:24:29 hmm 01:24:40 to be clearer I should say... 01:24:46 0 --> 0 01:24:53 bit --> 1 01:25:04 TSC_CR --> 1 01:25:38 if TSC_CR is just a constant then the result is two entries on the stack 01:25:57 ahh! 01:26:03 thats what I didnt see! 01:26:21 so it should be "( -- 1 x ) 01:26:22 ? 01:26:39 bic!, bis! or bit@ take two arguments 01:26:54 yes, or ( -- 1 a ) if TSC_CR is an address constant 01:27:05 ah yes, even better! 01:27:25 at least not so much work will be involved this time 01:27:57 rdrop-exit, Ive made my parser aware of read-only registers which change the commands and stack comments 01:28:21 thats one of the big improvements 01:28:36 rdrop-exit, how is the home quarantine going ? 01:29:08 I'm seeing our local supermarkets stock is reducing rapidly 01:29:15 In your place I would just define a bunch of address constants and a bunch of bitmask constants 01:29:22 I thinl Australia is headded for a massive problem 01:29:59 rdrop-exit, remeber this is all automatic, I dont write any of it apart from the parser rules 01:30:00 I don't think you need all these generated colon definitions 01:30:27 rdrop-exit, aha, they do look unessecary and ugly I agree 01:30:42 and a good coder could easily do away with them 01:30:45 I would do something like this 01:30:52 BUT then no one would understand his code 01:31:03 this method ONLY applies to embedded 01:31:08 $ 1234 constant tsc-cr ( -- a ) 01:31:35 1 bit constant %tsc-cr-tsce ( -- mask ) 01:32:39 why does a constant need a stack comment ? 01:33:29 they don't, it's just a reminder to me of what that tsc-cr is an address and %tsc-cr-tsce is a bitmask 01:33:39 apologies for the spam 01:33:41 $40024000 constant TSC ( Touch sensing controller ) 01:33:41 TSC $0 + constant TSC_CR ( control register ) 01:33:41 TSC $4 + constant TSC_IER ( interrupt enable register ) 01:33:41 TSC $8 + constant TSC_ICR ( interrupt clear register ) 01:33:41 TSC $C + constant TSC_ISR ( interrupt status register ) 01:33:42 TSC $10 + constant TSC_IOHCR ( I/O hysteresis control register ) 01:33:43 TSC $18 + constant TSC_IOASCR ( I/O analog switch control register ) 01:33:45 TSC $20 + constant TSC_IOSCR ( I/O sampling control register ) 01:33:48 TSC $28 + constant TSC_IOCCR ( I/O channel control register ) 01:33:50 TSC $30 + constant TSC_IOGCSR ( I/O group control status register ) 01:33:52 TSC $34 + constant TSC_IOG1CR ( I/O group x counter register ) 01:33:54 TSC $38 + constant TSC_IOG2CR ( I/O group x counter register ) 01:33:56 TSC $3C + constant TSC_IOG3CR ( I/O group x counter register ) 01:33:58 TSC $40 + constant TSC_IOG4CR ( I/O group x counter register ) 01:34:00 TSC $44 + constant TSC_IOG5CR ( I/O group x counter register ) 01:34:02 TSC $48 + constant TSC_IOG6CR ( I/O group x counter register ) 01:34:04 that's the entire TSC peripheral 01:34:16 although since I usually begin the name of bitmasks with a "%" it's already obvious which is a bitmask 01:35:03 ok so those are the registers, that's similar to how I would handle them 01:35:04 rdrop-exit, I think that this is our old 'programmer vs technician' viewpoint 01:35:21 just a sec 01:36:05 to me the TSC is obviously a peripheral. the TSC_CR is obviously a register and the tsc_cr_tsce is a bitfield 01:37:36 here's something similar 01:38:17 in the following example dmr.dmstatus is a register, the rest are bitfield constant 01:38:20 s 01:38:22 constants 01:38:43 I've seen your format already :) 01:39:16 $ 11 constant dmr.dmstatus 01:39:16 \ 31 23 bits hardwired 0 01:39:16 22 bit constant %dmr.dmstatus.impebreak 01:39:16 \ 21 20 bits hardwired 0 01:39:16 19 bit constant %dmr.dmstatus.allhavereset 01:39:18 18 bit constant %dmr.dmstatus.anyhavereset 01:39:21 17 bit constant %dmr.dmstatus.allresumeack 01:39:24 16 bit constant %dmr.dmstatus.anyresumeack 01:39:26 15 bit constant %dmr.dmstatus.allnonexistent 01:39:29 14 bit constant %dmr.dmstatus.anynonexistent 01:39:31 13 bit constant %dmr.dmstatus.allunavail 01:39:34 12 bit constant %dmr.dmstatus.anyunavail 01:39:36 11 bit constant %dmr.dmstatus.allrunning 01:39:39 10 bit constant %dmr.dmstatus.anyrunning 01:39:41 9 bit constant %dmr.dmstatus.allhalted 01:39:44 8 bit constant %dmr.dmstatus.anyhalted 01:39:46 7 bit constant %dmr.dmstatus.authenticated 01:39:48 6 bit constant %dmr.dmstatus.authbusy 01:39:51 5 bit constant %dmr.dmstatus.hasresethaltreq 01:39:53 4 bit constant %dmr.dmstatus.confstrptrvalid 01:39:56 3 0 bits constant %dmr.dmstatus.version 01:40:12 here is additional information regarding my nomenclature, this is a C statement for the TSC 01:40:16 TSC->IOSCR = TSC_IOSCR_G2_IO4; 01:40:54 this is standard C for embedded as used in a STM example circa 2014 01:41:21 yes, your system is well thought out as Id expect 01:41:40 do you have a example for a GD32VF103 register as yet ? 01:42:22 I dont do any JTAG programming so I cant compare to what you have done here 01:43:13 for one thing, every peripheral register has a factory 'description' field in CMSIS-SVD, it's what I append to the last comment section of my words 01:43:15 that's straight out of the RISC-V spec 01:43:25 aha 01:43:45 just a sec, I'll get you the corresponding page 01:44:01 how would you use your system to describe the TSC_IOSCR_G2_IO4 bitfield ? 01:47:11 here's the corresponding page 01:47:13 https://riscv.org/wp-content/plugins/pdf-viewer/stable/web/viewer.html?file=https://content.riscv.org/wp-content/uploads/2019/03/riscv-debug-release.pdf#page=30&zoom=auto,-16,247 01:48:34 rdrop-exit, yep, pretty standard, it's what i'd expect 01:49:00 as I went through the spec, I just typed in what I needed 01:49:08 I understand 01:49:34 so bacically I define a constant for each register 01:49:48 and a define a constant for each bitfield 01:49:49 of course 01:50:02 but that method wouldnt work for me at all 01:50:22 ok 01:50:22 for one, it's not humanly possible to type in all my registers 01:50:29 not for any one person 01:50:43 I only type in what I'm using 01:50:45 it must be fully automatic 01:50:57 I know 01:51:19 Im doing the same, Im only using a STM32F051 ;-) 01:51:39 and it has 33 peripherals and 3300 bitfields 01:52:11 and it's the smallest of the STM32F mcus 01:52:22 some have 20,000 bitfields 01:53:03 none of my stuff includes JTAG specs 01:53:09 or even SWD specs 01:53:24 it's all restricted to peripheral registers 01:53:36 JTAG isn't relevant to the point 01:53:58 well it is because I havent seen a CMSIS-SVD for it 01:54:05 otherwise Id have it 01:54:23 it has nothing to do with JTAG or no JTAG 01:55:30 what was the point again ? 01:56:11 You're focused on generating definitions automatically and for everything which is fine 01:56:30 it's not 'fine' it's *essential* 01:56:58 I type in definitions of registers and bitfields as I need them, while I'm trying to grok them, which is fine too 01:56:59 as you may see when you actually have to start using a actual external device 01:58:46 --- join: dys joined #forth 02:01:31 I will do what I've always done, read the spec of the specific peripheral, encode the registers and bitfields I need, as I'm reading the spec 02:02:38 then of interactively test my understanding 02:05:51 the time I spend typing is inconsequential, it's just something I naturally do as I'm reading a spec, any spec 02:06:05 sure 02:06:28 take ADC0 in a GDVF103 ? 02:06:35 thats one of the many peripherals 02:06:39 it has 02:06:42 21 registers 02:06:42 88 bitfields 02:07:35 not a problem, as I'm reading about those registers and bitfields and trying to grok them, I type 02:08:32 I do the same thing as I read an ISA, I start coding the assembler for that ISA as I read 02:08:42 helps me to grok it 02:08:55 the term 'not a problem' is very easy to type, actually groking 21 registers and 88 bitfields, then making the ADC work is something else :) 02:09:25 and of course, ADC0 requires the cooperation of other peripherals, some much more complex 02:09:29 exactly, the critical path is not typing in constants, it's groking them 02:09:40 no, it's both 02:09:59 as a mistake in either is equally fatal to the device working properly 02:10:22 trust me, I know this from the paon of a thousand cust 02:10:37 and also the pain of a thousand cuts 02:10:53 but there is more 02:11:28 a mistake in the transcribing and understanding of other peripherals will also stop the ADC0 working 02:12:10 and then after 2 years of dilligent fault finding, you discover that the text is wrong, when you look at the CMSIS-SVD 02:12:47 do you know how I know the GDVF103 ADC0 contains 21 registers and 88 bitfields ? 02:12:57 I didnd count them from the doc 02:13:09 Id still be at it if that was the case 02:15:37 I'm not trying to convince you to do things my way, whatever works for you is fine 02:18:09 gotta go, wife wants to watch a video, stay healthy 02:18:14 --- quit: rdrop-exit (Quit: Lost terminal) 02:19:48 no problemo thanks for the stack comment criticism, much appreciated 03:09:19 bm08:49 ● tp: What advice did you get about stack comments? 03:09:47 sorry... 03:12:25 ? 03:12:57 Bunny351, mainly that mine were very incomplete and useless :) 03:13:09 now less incomplete tho! 03:25:54 no, I'm just too stupid to use my irc client correctly... :-) 03:27:48 it's not like theyre trivial to use, unlike Forth stack comments ;-) 03:41:45 --- join: xek joined #forth 03:44:02 I find it hard to decide whether to use stack comments or not. I hate cluttering up my code but sometimes it really helps in involved code to remind me where I am 03:44:47 for colon definitions I always use them, of course. 03:46:43 Bunny351, when it comes to embedded I can't see any alternative to tons of comments tho I only stack comments in colon definitions 03:46:54 + use 03:47:39 there is this massive divide between programmers of Forth and embedded programmers of Forth in my experience 03:48:26 and embedded programming is the closest anyone will ever come to 'write only Forth' imho 03:49:03 my theory is that it's impossible to have short, neat, consice Forth code in embedded 03:50:15 true. I see a lot of high-level forths with weird ideas but would actually love to see the application of low-level, old-school forth code and thinking in everyday programming on traditional systems. 03:51:22 look at the alternative in C ? this looks nice and neat, but without the header file you dont know the details 03:51:25 TSC->IOSCR = TSC_IOSCR_G2_IO4; 03:51:56 --- join: logand joined #forth 03:52:31 the neatness is superficial and may actually hide information 03:52:43 Bunny351, absolutely my opinion also 03:52:54 in the above example it does 03:53:37 and without the header file which is *never* included with examples, especially in PDF's one has only part of the information 03:56:01 here is a article I wrote about the typical C problem I encounter when reviewing C code as adjunct to understanding the configuration of a MCU peripheral: file:///home/tp/projects/programming-languages/forth/mecrisp-stellaris/mecrisp-unofficial-doc/_build/html/touch-sensor.html#stmicro-c-tsc-code-example 03:56:09 oops 03:56:29 https://mecrisp-stellaris-folkdoc.sourceforge.io/touch-sensor.html#stmicro-c-tsc-code-example 03:56:49 below it is my working and newly minted stack comment code 03:57:37 my "Config Words" are all automatically generated from the CMSIS-SVD file for that MCU 04:03:31 indeed. unfortunately documentation nowadays just assumes you use C + an IDE + a bunch of badly documented runtime systems, I guess 04:03:56 and a massive number of really ugly header files 04:04:16 I often wonder if C programmers ever try and read those header files ? 04:04:26 yep. or even autogenerated doxygen-style docs that don't really explain anything 04:04:36 in embedded, the contortions the header files go thru is amazing 04:04:58 automated doc is really useless in my experience 04:05:09 looks pretty, and looks organised but useless 04:05:22 but is cheap to produce... 04:05:35 and 'better than nothing' I guess 04:06:19 it's funny how 'cheap' is used nowadays to justify so may choices 04:07:01 for instance the USA put men on the Moon in 1969, but in 2020 Boeing couldn't even put a capsule in the right orbit 04:07:15 and their excuse ? 'a clock sync problem' 04:07:53 too much complexity and a totally corrupt military industrial complex, but this is probably getting too political... :-) 04:07:57 there are some who believe that men could do more in 1969 than now in 2020 04:08:28 I agree with you, but the complexity aspect is very relevant to Forth I think 04:09:03 todays software is just imploding with complexity and the remedies are only adding more of it 04:09:21 partly it's our own fault: we want to many bells and whistles! :-) 04:09:27 s/to/too/ 04:09:41 my own Forth development environment is quite complex now, but it works with a resident embedded Forth the same way they did 40 years ago 04:10:06 do you meta-compile? 04:10:31 I'm a technician and I use Mecrisp-Stellaris which I didnt (and couldnt) create 04:10:51 so it's not bootstrapped using assembly? 04:10:53 it's written in thumb1 assembly, so no 04:11:02 ah, ok 04:11:11 it's assembled by arm-eabi-none 04:11:47 I've modified small bits of it, but I build devices with forth, I think of myself as a Forth user 04:12:31 I write doc and make my own tooling for Forth, but it's all to enable making things 04:13:49 for example a project I've just now finished a new minor version for is a bootable binary to test 'blue-pill' boards from china to see if they contain a 'fake' mcu 04:14:29 Huh? what's that? 04:14:34 it also tests 'hidden' flash memory in the genuine STM32F103C8 MCU's 04:15:37 the 'blue-pill' board is supposed to contain a STM32F103C8 mcu and many dont, they contain cheaper 'clones' or 'fakes' made in China 04:15:50 ah, I see. 04:16:21 and some of these clones arent 100% compatible with the original, some are in fact better 04:16:58 either way, my diagnostic program helps find out what MCU it is 04:17:26 it's a Forth system, weighs in under 64kB and does a lot of stuff 04:17:58 ID say 99% of the users don't even know (or care) it's a Forth system as it's menu driven 04:18:48 as of today sourceforge has counted 194 downloads of it 04:19:06 the majority are to the USA and Windows users 05:04:12 --- join: dddddd joined #forth 06:23:07 --- quit: logand (Ping timeout: 250 seconds) 06:33:27 --- quit: dave0 (Quit: dave's not here) 06:35:36 --- quit: xek (Ping timeout: 240 seconds) 07:16:21 --- quit: iyzsong (Ping timeout: 246 seconds) 07:37:03 --- join: Zarutian_HTC joined #forth 07:43:00 --- join: logand joined #forth 08:32:01 --- quit: dys (Ping timeout: 256 seconds) 08:48:39 --- quit: jsoft (Ping timeout: 250 seconds) 08:55:36 --- quit: Bunny351 (Ping timeout: 240 seconds) 08:55:55 --- join: Bunny351 joined #forth 09:18:56 --- quit: Zarutian_HTC (Ping timeout: 240 seconds) 09:53:35 --- join: Zarutian_HTC joined #forth 09:54:52 hey guys 10:19:29 h'lo 10:21:43 due to discussion elsewhere it occured to me one could set up an recurring timer that when its interrupt fires, just calls PAUSE 10:22:01 or other such task switching word 10:50:30 doesn't that force all your code to be re-entrant, rather than just code that does a cooperative task switch? 11:04:47 back 11:05:44 it's essentially just preemptive multitasking, and it forces upon you everything it normally does 11:06:18 I did just that in hashforth 11:20:17 --- quit: Mellowlink (Remote host closed the connection) 11:23:34 --- join: Mellowlink joined #forth 11:40:54 remexre: not more than most interrupts do. Critical sections in compareAndStore can momentarily disable interrupts. 11:41:46 this compareAndSwap word is the used for queue or streams between tasks 11:42:10 hm, okay; I'm mainly thinking of the few global structures I have; most of them don't have locks, and instead I rely on "it's unsound to modify this during an interrupt" 11:42:16 that is for inter task communications 12:31:03 --- join: xek joined #forth 12:31:41 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 12:31:48 --- join: Zarutian_HTC joined #forth 12:42:43 --- quit: gravicappa (Ping timeout: 250 seconds) 12:44:42 --- join: mtsd joined #forth 14:27:45 --- quit: Zarutian_HTC (Remote host closed the connection) 14:28:23 --- quit: xek (Ping timeout: 256 seconds) 14:31:12 --- quit: mtsd (Ping timeout: 264 seconds) 14:31:59 --- join: Zarutian_HTC joined #forth 14:32:20 --- join: mtsd joined #forth 14:35:38 --- quit: mtsd (Client Quit) 15:06:49 --- quit: tabemann (Ping timeout: 260 seconds) 15:25:48 --- quit: irsol (Remote host closed the connection) 15:29:49 --- quit: Croran (Ping timeout: 260 seconds) 15:32:02 --- join: irsol joined #forth 15:57:06 --- join: tabemann joined #forth 15:58:45 --- join: Croran joined #forth 17:34:04 --- join: iyzsong joined #forth 17:46:41 --- join: crab39 joined #forth 17:46:53 What's up forthers 17:47:04 How's COVID19 affecting y'all 17:51:41 --- quit: proteus-guy (Ping timeout: 250 seconds) 18:04:04 Is alibaba a good place to purchace electronic components? 18:07:52 back 18:07:55 hey guys 18:08:19 crab39: I personally wouldn't by electronic components from alibaba 18:08:43 like those "blue pill" boards you can get on there often include counterfit chips 18:09:15 as for COVID-19, well, that's led to a certain degree of cabin fever 18:11:18 * tabemann is glad he fixed that damn flash bug in zeptoforth 18:15:34 I want a keyboard with programmable screens on every key 18:16:00 I've had issue with keyboards as an interface for a long time and I think that would make me happy with them 18:19:44 and on COVID, I'd rather cabin fever than still being stuck going to work in an establishment that 3 shifts of 40 people plus office workers are in every day :/ 18:32:39 --- join: Zarutian_HTC| joined #forth 18:32:40 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 18:41:28 in my case my work hasn't told us to not come into work in general, for whatever reason 18:42:48 What's your work though? Like are there a large number of workers there? 18:43:22 these days there's only a few people working there on any given day 18:43:46 a lot of the people already aren't coming in because they have kids and school's been canceled 18:44:53 Right, I think all is well if only a few people are in the building 18:46:38 we're also scattered about in our cubes as well 18:49:17 what's your profession? 18:56:31 --- nick: Zarutian_HTC| -> Zarutian_HTC 19:37:12 --- quit: crab39 (Remote host closed the connection) 19:38:48 --- join: crab16 joined #forth 19:42:33 --- quit: crab16 (Remote host closed the connection) 19:46:39 --- join: clitoris joined #forth 19:46:47 this is crab 19:47:13 --- join: dave0 joined #forth 19:48:16 --- join: boru` joined #forth 19:48:19 --- quit: boru (Disconnected by services) 19:48:22 --- nick: boru` -> boru 19:59:20 Is there a good comprehensive list of forths out there somewhere? 20:18:14 --- join: logand` joined #forth 20:22:02 --- quit: logand (Ping timeout: 250 seconds) 20:41:33 yes 20:41:35 forth.org 20:42:11 clitoris: https://www.concatenative.org/wiki/view/Front%20Page 20:42:19 http://forth.org/ 20:42:22 and so on 20:42:29 and so... forth! 20:42:33 har har har 20:43:18 tabemann, i compiled the stm32f407 version fine, no response on the terminal tho 21:03:05 --- quit: cartwright (Remote host closed the connection) 21:03:39 Kumool wow 21:04:00 Indeed, I can't believe I'm talking to a clitoris 21:04:04 amazing 21:07:11 that concatenative.org is quite good, I'm surprised I haven't seen it before 21:09:45 --- join: cartwright joined #forth 21:21:25 --- quit: dave0 (Quit: dave's not here) 21:27:25 --- quit: _whitelogger (Remote host closed the connection) 21:30:28 --- join: _whitelogger joined #forth 21:56:51 --- join: jsoft joined #forth 22:02:26 --- join: gravicappa joined #forth 22:33:11 Does anyone know of a way to have a recursive function that takes up constant stack space 22:33:16 Or whether it is possible 23:34:11 back on the 25th :) 23:34:14 --- quit: tp (Quit: I'm quitting to find peace with my inner stack !) 23:49:03 --- join: dys joined #forth 23:59:59 --- log: ended forth/20.03.22