00:00:00 --- log: started forth/20.03.17
00:00:19 --- join: dave0 joined #forth
00:24:29 --- join: mtsd joined #forth
00:28:23 --- join: dys joined #forth
00:59:13 --- quit: reepca (Ping timeout: 240 seconds)
01:13:28 --- join: mtsd_ joined #forth
01:16:11 --- quit: mtsd (Ping timeout: 256 seconds)
01:16:51 --- quit: mtsd_ (Client Quit)
01:25:07 --- join: xek joined #forth
02:22:17 --- quit: WickedShell (Remote host closed the connection)
03:06:24 --- quit: _whitelogger (Remote host closed the connection)
03:09:27 --- join: _whitelogger joined #forth
03:48:06 --- quit: Mellowlink (Ping timeout: 240 seconds)
03:50:47 --- join: Mellowlink joined #forth
04:15:43 --- join: iyzsong joined #forth
05:30:46 --- quit: Mellowlink (Ping timeout: 240 seconds)
05:31:06 --- quit: cartwright (Ping timeout: 240 seconds)
05:33:51 --- join: Mellowlink joined #forth
05:40:12 --- join: cartwright joined #forth
06:43:20 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in)
06:43:58 --- quit: dave0 (Quit: dave's not here)
06:45:21 --- join: dddddd joined #forth
06:49:54 --- join: X-Scale` joined #forth
06:50:41 --- quit: X-Scale (Ping timeout: 260 seconds)
06:50:41 --- nick: X-Scale` -> X-Scale
08:18:27 --- quit: jsoft (Ping timeout: 246 seconds)
09:44:33 --- quit: dys (Ping timeout: 246 seconds)
10:20:23 --- join: dys joined #forth
10:22:57 --- quit: actuallybatman (Ping timeout: 256 seconds)
10:49:07 --- join: crab0 joined #forth
11:04:03 --- quit: crab0 (Remote host closed the connection)
11:16:59 --- join: crab1 joined #forth
11:26:57 --- quit: crab1 (Quit: Ping timeout (120 seconds))
12:19:01 --- quit: bluekelp (Ping timeout: 265 seconds)
12:19:38 --- join: bluekelp joined #forth
12:58:36 --- join: WickedShell joined #forth
14:39:36 --- quit: gravicappa (Ping timeout: 264 seconds)
14:47:11 --- quit: xek (Ping timeout: 250 seconds)
14:54:43 --- join: reepca joined #forth
15:20:15 --- join: CORDIC joined #forth
15:20:17 --- quit: DKordic (Read error: Connection reset by peer)
15:37:17 --- quit: tabemann (Read error: Connection reset by peer)
15:37:24 --- join: tabemann_ joined #forth
15:57:03 --- join: absentia joined #forth
15:57:44 <absentia> um.  Is there a *simple* random number generator that works for gforth?  that doesn't require a require random.fs or something?  I use to have a 2 liner -- but it now seems completely borked.
16:00:34 --- part: absentia left #forth
16:07:42 --- quit: tpbsd (Remote host closed the connection)
16:07:53 --- join: tpbsd joined #forth
16:07:53 --- quit: tpbsd (Changing host)
16:07:53 --- join: tpbsd joined #forth
16:16:55 --- join: rdrop-exit joined #forth
16:19:14 <rdrop-exit> abstentia, xorshift RNGs are simple and fast
16:19:24 <rdrop-exit> https://en.wikipedia.org/wiki/Xorshift
16:19:46 <rdrop-exit> here's a Forth example:
16:19:47 <rdrop-exit> https://www.excamera.com/sphinx/article-xorshift.html
16:25:07 --- join: tp___ joined #forth
16:25:07 --- quit: tp___ (Changing host)
16:25:07 --- join: tp___ joined #forth
16:25:08 --- quit: tpbsd (Read error: Connection reset by peer)
16:31:10 --- join: logand joined #forth
16:32:49 <logand> 42 >r r> . crashes pforth but prints 42 in gforth.  why does it crash in pforth?
16:35:10 <tp___> pforth can't handle the answer to everything ?
16:35:20 --- nick: tp___ -> tp
16:35:43 <tp> rdrop-exit, g'day Zen Forth Guru!
16:36:20 <rdrop-exit> hi tp, Forth Master Tech (tm)!
16:36:47 <tp> rdrop-exit, no new coronavirus cases in Australia yesterday
16:37:13 <rdrop-exit> logand, accessing the return stack is usually undefined in interpretation
16:37:46 <rdrop-exit> excellent tp!
16:38:07 <logand> tp: haha
16:38:48 <logand> rdrop-exit: ok, i thought that the other stack was always useable in general
16:39:47 --- join: actuallybatman joined #forth
16:40:06 <tp> logand, on the embedded cortex-m Forth I use (Mecrisp-Stellaris) >rr> r@ are all handled nicely 
16:40:31 <rdrop-exit> tp, outside of a definition?
16:41:09 <tp> i never tried that, I doubt it would work tho
16:41:46 <tp> wrong ... 42 >r r> . 42 ok.
16:43:14 <tp> I never code outside of definitions except where Im testing hardware in real time at the terminal and I have no need for a pseudo local variable at those times
16:43:38 <logand> hmm maybe bug in pforth then?  or how would one find out if something is only ment to be used inside of a definition?  (except crashing)
16:44:16 <logand> tp: interesting
16:44:24 <rdrop-exit> normally compile-only words are indicated in the docs
16:44:24 <tp> if it crashes outside a definition, but not inside, isnt that the answer ?
16:44:58 <rdrop-exit> some Forths will throw an exception or print an error message
16:45:03 <tp> crashing indicates undefined or not implemented ?
16:45:21 <logand> tp: yes it is an answer if i assume it is not a bug
16:45:40 <tp> *everything* bad throws a exception on cortex-m, there is no escape!
16:46:14 <rdrop-exit> tp, I didn't mean a processor exception, I'm talking about a Forth exception
16:46:41 <tp> logand, Im a electronics tech not a programmer, so my Forth usage is that of a user
16:47:34 <tp> rdrop-exit, I always get confused about the differences there, I'm not sure if Mecrisp-Stellaris even has Forth exceptions
16:48:07 <tp> rdrop-exit, Forth exceptions are available as add on Words tho
16:48:34 <tp> perhaps 'forth exceptions' are more of a PC thing than a small embedded thing ?
16:49:23 <logand> tp: what for devices do you build if i can ask?
16:50:03 <tp> stm32 always, mainly stm32f051 (cortex-m0)
16:50:26 <logand> i mean the final product
16:50:34 <tp> logand, mainly as I have a huge stock of them and they do everything I need, hardware wise
16:51:01 <logand> ok, but what does it do and what do use it for, the final product?
16:51:23 <tp> logand, all small custom projects, last one was a wheelchair hand controller to motor drive unit interface
16:52:00 <logand> i see, cool
16:52:13 <tp> logand, I'm relatively new to Forth (2014) and learning proceeds glacially
16:53:12 <logand> glacially because of forth or life?  you must be pretty advanced when you use forth for real projects already
16:53:22 <tp> logand, I have a documentation site at https://mecrisp-stellaris-folkdoc.sourceforge.io/index.html which is really just a collection of notes and projects along my forth journey
16:54:00 <tp> because of a severe lack of mental horsepower and old age (65)
16:54:12 <logand> i always wanted to try forth as it seems very interesting but at the same time mentally daunting
16:54:42 <rdrop-exit> tp, not really, Forth exceptions pretty common since the 90s
16:55:38 <logand> tp: thanks for the link, i'll have a look
16:56:08 <tp> rdrop-exit, when Forth became popular on PC's I'll bet
16:57:03 <tp> logand, I think the old saying 'Forth is easy to learn but difficult to master' has been accurate for me
16:57:22 <rdrop-exit> I don't think it's related, there have been PC forths since the 70s
16:57:26 <tp> logand, but for small embedded it has totally changed how I work
16:57:29 <logand> gforth: 0 0 ! throws invalid memory access, i suppose those are the forth exceptions
16:57:43 <logand> as it does not crash gforth
16:57:48 <rdrop-exit> or I should say Microcomputer Forths
16:58:23 <rdrop-exit> logand, yes
16:58:37 <logand> tp: changed for the better i suppose:-)
16:59:00 <logand> rdrop-exit: there were pc's in the 70s already?
16:59:16 <rdrop-exit> I meant microcomputers
16:59:17 <tp> rdrop-exit, i always associate the term "PC" with the IBM PC which was released in 1981. Before that they were "6800 development system", "rockwell aim65", "cromenco z80", etc
17:00:19 <tp> logand, absolutely for the better or I wouldnt be using Forth now
17:00:53 <rdrop-exit> before the PC there were Apple, Commodore, TRS-80, and various other microcomputer Forth implementations
17:00:54 <tp> logand, Forth has been utterly malleable for me, and FLOSS has allowed me to build whatever I wanted
17:01:24 <logand> i am worried, that after i write something in forth and come back to it after a while, i'll have a hard time to understand what i wrote
17:01:27 <tp> rdrop-exit, good point, I guess my technician outlook is showing again
17:01:44 <tp> logand, unlike Perl ?
17:01:47 <tp> ;-)
17:01:51 <logand> is that a general problem or does it get better with experience?
17:02:06 <logand> tp: i dont write perl:-)
17:02:08 <rdrop-exit> factoring is the key
17:02:17 <logand> rather, unlike lisp, or c
17:03:07 <rdrop-exit> unreadable forth usually comes from insufficient factoring
17:04:01 <logand> yes, that's what i've been telling myself to build up motivation to dive into forth
17:04:16 --- join: tpbsd joined #forth
17:04:25 <tpbsd> logand, Forth is no different to any other language as regards poorly documented code in my opinion
17:04:35 <tp> logand, the 'write only' accusation always levied against Forth is by non Forth users imho
17:04:35 --- quit: tp (Remote host closed the connection)
17:04:47 <rdrop-exit> it's not just a question of documentation
17:05:15 <tpbsd> logand, if youre using Forth on a pc, I recommend you try 'Retro' http://forth.works/book.html#retro-a-modern-pragmatic-forth
17:05:57 <tpbsd> rdrop-exit, thats what programmers always say!
17:06:24 <logand> tpbsd: yes pc, i'll have a look at retro
17:07:04 <rdrop-exit> if you need an explanatory comment *inside* a definition, then you should have factored
17:07:10 <tpbsd> rdrop-exit, I knew a incredibly smart programmer, he was the chief software architect for a massive firm, and he would always say 'good code is self documenting' which I still think is a load of crap
17:08:09 <tpbsd> as a tech still learning forth I heavily comment all my Forth code
17:08:20 <rdrop-exit> there a different levels of documentation, what you're trying to avoid is to have to document within the definitions
17:08:22 <tpbsd> inside and outside of definitions
17:08:35 <tpbsd> I'm not trying to do that at all
17:08:54 --- join: jsoft joined #forth
17:08:56 <rdrop-exit> you should be
17:09:23 <rdrop-exit> for example
17:09:36 <rdrop-exit> : foo ( -- )
17:10:23 <rdrop-exit>  .... \ frobinate the umbilator
17:10:34 <tpbsd> it seems to me that's very common advice from programmers who don't do embedded Forth
17:10:35 <rdrop-exit> should be replaced with
17:10:58 <rdrop-exit> ... umbilator frobinate
17:11:13 <tpbsd> sure, thats fair
17:11:18 <rdrop-exit> has nothing to do with embedded or not embedded
17:11:20 <tpbsd> but what about this case ?
17:11:24 <tpbsd> \ pa12 Open Drain
17:11:24 <tpbsd>  : GPIOA_CRH_MODE12   ( %XX -- ) 16 lshift GPIOA_CRH bis! ;  \ GPIOA_CRH_MODE12    Port n.12 mode bits
17:11:45 <tpbsd> thats a automatically generated Word
17:12:30 <rdrop-exit> there's no comment within the word in you're example, there's a comment about the word
17:12:32 <logand> tpbsd: should be replaced with pa12 open drain :-)
17:12:51 <tpbsd> the comment is automatically taken from the CMSIS 'description' field to help avoiding the need for a massive PDF technical manual to be open on the PC as well
17:13:37 <rdrop-exit> but as I said, I'm talking about comments *inside* definitions
17:13:58 <tpbsd> rdrop-exit, oops, apologies, but I have plenty of those as well
17:14:27 <tpbsd> logand, I have constants for that kind of thing, ie
17:14:43 <tpbsd> OUTPUT GPIOA_CRH_MODE12
17:15:18 <tpbsd> (not strictly true in this example as it's from a cortex-m3 which is a PITA to configure the GPIO's imho)
17:15:48 <logand> ok, why not GPIOA_CRH_MODE12 OUTPUT?
17:16:02 <tpbsd> : pa12-pulse ( -- ) \ Blue Pill PA12 normally HIGH, pulse LOW for 1ms
17:16:03 <tpbsd>    PA12-LOW
17:16:03 <tpbsd>    10 ms.delay	     \ = 1ms (intervals are 0.1ms)
17:16:03 <tpbsd>    PA12-HIGH
17:16:03 <tpbsd>  ;
17:16:13 <tpbsd> that's a example of my comments within a Word
17:16:50 <tpbsd> logand, anything is possible, but OUTPUT GPIOA_CRH_MODE12 is easier and simpler imho
17:16:52 <logand> 10 is that fixed point?
17:17:13 <logand> or somehow different unit?
17:17:26 <tpbsd> logand, no, but Mecrisp-Stellaris has fixed point and I do use it
17:18:07 <tpbsd> logand, the 10 is just a decimal number
17:18:33 <rdrop-exit> that's a cofusing line, why does 10 ms.delay mean 1 ms?
17:19:02 <logand> ok i thought it was something like 10ms delay scaled down by 10
17:19:12 <tpbsd> probably because my comment is old and wrong ?
17:19:21 <logand> ah
17:19:30 <tpbsd> it should read  \ = 10 ms (intervals are 0.1ms)
17:19:47 <tpbsd> but I'm working on this code right now and it's changing a lot
17:20:10 <logand> so it would actually be better without the comment
17:20:15 <tpbsd> the comment is to remind me that the systick is set to 0.1ms 'ticks'
17:20:41 <tpbsd> logand, it would be better like this  \ intervals are 0.1ms
17:20:56 <tpbsd> but again, Im a technician not a programmer
17:21:05 <logand> or define a constant and write it explicitly in the code?
17:21:09 <rdrop-exit> until you change the intervals, then the comment will be wrong again
17:21:58 <logand> 10 ms.delay -> 10 ticks would be better?
17:22:43 <logand> : 1ms 10 ticks ;
17:22:45 --- quit: tpbsd (Remote host closed the connection)
17:22:46 --- join: tp___ joined #forth
17:22:46 --- quit: tp___ (Changing host)
17:22:46 --- join: tp___ joined #forth
17:23:11 <tp___> apologies for the dropouts, I think the Internet has the Corona virus atm
17:23:19 --- nick: tp___ -> tp
17:23:48 <tabemann_> hey guys
17:23:55 <rdrop-exit> hi tabemann
17:23:55 <tp> hey tabemann_ !
17:24:41 <tp> logand, I really recommend Retro, it's well thought out, has it's own Literate Programming solution and compiles on everything Ive tried
17:25:12 <logand> tp: ok, it looks quite different from forth
17:25:31 <tp> logand, retro has persuaded me to try it instead of Perl as a PC 'glue' solution here
17:26:10 <tp> logand, but that's the essence of forth!
17:26:14 <rdrop-exit> 12 pa clear  10 ticks  12 pa set
17:26:24 <logand> ok, i'm thinking about doing some projects in forth instead of c so i'll see how it goes
17:26:50 <tp> logand, even the creator of Forth when asked 'what is Forth replied 'I can't say for sure, but I know it when I see it'
17:27:30 <tp> rdrop-exit, and what does your PA12 config look like ?
17:27:40 <logand> rdrop-exit: that is very readable
17:27:59 <tabemann_> if you're feeling ambitious you can write your own forth, and then you get to make it however you want!
17:28:01 <tp> clear but meaningless by itself
17:28:04 <rdrop-exit> tp, does it matter?
17:28:22 <tp> rdrop-exit, it's absolutely critical
17:28:39 <logand> tp: yeah but he had decades to think about one line, i dont have that much time
17:28:59 <tp> PA12 as default after a reboot is set to 'input', 'floating' mode
17:29:33 <tp> PA12 without prior config wont send any data out
17:29:34 <rdrop-exit> I have no idea what a PA12 is
17:29:53 <tabemann_> all I know is PA12 is some hardware register
17:29:54 <logand> tp: you can give it desired meaning
17:30:28 <tp> thats technician slang for GPIO-A-12 but has been in common use for the last 20 years or more
17:31:15 <tp> PA12 is pronounced "port a pin 12"
17:32:04 <tp> and as all ports are general purpose input output anyway, we abbreviate GPIOA12 to PA12
17:32:11 <rdrop-exit> so why can't your code look similar to that?
17:32:27 <rdrop-exit> a port 12 pin set
17:32:31 <tp> it certainly can with Forth
17:33:13 * tabemann_ is mesmerized by his blinky
17:33:22 --- nick: tabemann_ -> tabemann
17:33:39 <tp> thats the awesome thing about forth, and why every Forth is different, it can be whatever you want it to be :)
17:33:54 <rdrop-exit> you should only have numbers as part of names in special cases
17:34:15 <tp> tabemann is to be congratulated for his 'zeptoforth' blinky milestone especially as he's a programmer nd not a tech like me
17:34:32 <tabemann> you've already congratulated me for that! lol
17:34:42 <rdrop-exit> for example if it's a primitive, e.g. 16@ 32@
17:34:54 <tp> tabemann, I know, now Im telling everyone *else*
17:35:18 <rdrop-exit> kudos tabemann
17:35:38 <logand> good night & thanks for ideas!
17:35:39 <tabemann> one thing I did this morning was factor out my "driver" code from my non-driver code amongst my Forth (rather than kernel) codebase
17:35:43 <tabemann> g'night
17:35:47 <tp> rdrop-exit, but in embedded names and numbers in a single word are the default
17:35:51 <rdrop-exit> good night logand
17:35:57 <tp> tabemann, night-o
17:36:04 <tp> oops
17:36:12 <tabemann> I was saying 'night to logand
17:36:13 <tabemann> lol
17:36:16 <tp> logand, night-o, great speaking, please return!
17:36:16 <tabemann> *g'night
17:37:07 <rdrop-exit> tp, it depends
17:37:15 <tp> rdrop-exit, if you look in the MCU datasheet youll see that register names and numbers are as one, for example 
17:38:09 <rdrop-exit> sure, but the 12th pin of a register is the 12th pin
17:38:14 --- join: dave0 joined #forth
17:38:14 <tp>  RCC_APB1ENR
17:38:18 <rdrop-exit> of a port I mean
17:38:57 <tp> actually the 12 pin is usually bit 13 as pins start at 1 and bits at 0
17:39:03 <tp> theer is never a pin 0
17:39:48 <rdrop-exit> sure, but the 12th pin is the 12th pin\
17:40:31 <tp> rdrop-exit, thats academic, in the real world gpio pins are specified by port and number
17:41:00 <rdrop-exit> so that's how you should specify them in your forth, by port and number, no?
17:41:04 <tp> there may be 180 pins on a mcu
17:41:11 <rdrop-exit> so?
17:41:15 <tp> and I have above
17:41:53 <rdrop-exit> hmm
17:42:03 <rdrop-exit> I think we're talking past each other
17:43:00 <tp> : GPIOA_BSRR_BS0   %1 0 lshift GPIOA_BSRR  ;  \ GPIOA_BSRR_BS0    Set bit 0
17:43:32 <tp> probably, it's very easy to do when one knows littel about software and the other little about hardware :)
17:43:56 <rdrop-exit> 0 bit gpio-bsrr set
17:44:16 <rdrop-exit> 1 bit gpio-bsrr set
17:44:29 <rdrop-exit> 0 bit gpio-bsrr clear
17:44:41 <tp> no because the factory naming convention is CMSIS-SVD and used automatically in my definition
17:45:03 <tp> you have also omitted the actual port
17:45:29 <rdrop-exit> doesn't my code do the same as yours?
17:45:35 <tp> ports number from A to H in some models with sufficient pins
17:46:09 <tp> your code is the same as "go to the shop and buy 10"
17:46:18 <tp> 10 what ?
17:46:45 <rdrop-exit> my code does exactly the same as yours
17:47:08 <tabemann> except you forgot the A
17:47:17 <tp> not only that, but unless your unknown port is configured as a OUTPUT your code will do nothing
17:47:19 <rdrop-exit> ok fine,
17:47:28 <tp> or the B
17:47:31 <tp> :)
17:47:37 <tp> or the H :)
17:48:01 <rdrop-exit> 0 bit a port gpio-bsrr set
17:48:07 <tp> rdrop-exit, this very GPIOX situation drives C coders into conniptions
17:48:59 <rdrop-exit> or if you prefer
17:49:05 <tp> rdrop-exit, now is that port a input or a output ? is it open collector or push-pull ?
17:50:27 <rdrop-exit> look at the docs
17:50:40 <tp> rdrop-exit, does it have a pull-up or a pull-down ?
17:50:40 --- quit: tp (Remote host closed the connection)
17:50:46 --- join: tpbsd joined #forth
17:50:46 --- quit: tpbsd (Changing host)
17:50:46 --- join: tpbsd joined #forth
17:51:15 <tabemann> I assumed you weren't oone to ragequit -lol
17:51:26 <tpbsd> these kind of issues cause C coders to create stuff like this: 
17:51:28 <tpbsd> void gpio_init(){
17:51:29 <tpbsd>  GPIO_InitTypeDef GPIO_InitStructure;
17:51:29 <tpbsd>  RCC_AHBPeriphClockCmd (RCC_AHBPeriph_GPIOC | RCC_AHBPeriph_GPIOA,ENABLE);
17:51:29 <tpbsd>  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
17:51:29 <tpbsd>  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9 | GPIO_Pin_8 ;
17:51:29 <tpbsd>  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
17:51:31 <tpbsd>  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
17:51:34 <tpbsd>  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
17:51:38 <tpbsd>  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
17:51:39 <tpbsd>  GPIO_Init(GPIOC, &GPIO_InitStructure);
17:51:42 <tpbsd> }
17:51:44 <tpbsd> tabemann, no definitely not :)
17:51:52 <tpbsd> I have never lost my temper in the 65 years I remember
17:52:13 <tpbsd> sadly my Internet connection is up and down like a yoyo today
17:53:12 <tpbsd> rdrop-exit, this very issue has been very interesting to me, how to present the hardware configuration of *every* GPIO in a readable and logical manner in Forth
17:53:31 <rdrop-exit> you exploit the regularities
17:53:32 <tpbsd> rdrop-exit, Im still working thru it, since 2014
17:53:56 <tpbsd> rdrop-exit, sure, but there are *so many* regularities
17:54:17 <tpbsd> look at *one* of the C solutions above ?
17:54:26 <rdrop-exit> that's a good thing, many irregularities would be bad
17:54:52 <tabemann> that C solution seems... overengineered
17:54:58 <tpbsd> some of them are dangerous to even look at for me, I have to make sure I dont have a mouthfull of coffee when I read them on my screen ;-)
17:55:23 <rdrop-exit> it's best not to even look at the C solution, it's fairly irrelevant to the Forth solution
17:55:30 <tpbsd> tabemann, every C 'solution' Ive seen has been very overengineered
17:55:49 <tpbsd> rdrop-exit, not so :(
17:56:01 <rdrop-exit> I prefer to study the specs than someone's C code
17:56:23 <tpbsd> rdrop-exit, wait until you actually want to *use* a peripheral and the technical manual is ambiguous ...
17:56:45 <rdrop-exit> oh I'm well aware there are ambiguities
17:56:55 <tpbsd> you know there is a problem because the peripheral isnt doing what you wanted after you read the manual several times
17:57:10 <rdrop-exit> Forth is great for testing the ambiguities
17:57:45 <tpbsd> I *don't* want to go anywhere near C code, but sometimes a person gets desperate after multiple failures 'mistakes were made!'
17:58:12 <KipIngram> https://usercontent.irccloud-cdn.com/file/GjzIReTo/1584486857.JPG
17:58:21 <tpbsd> rdrop-exit, thats so true, but even the near god like realtime testing can;'t help you sometimes
17:59:13 <rdrop-exit> the problem with looking at someone's C solution is that it unduly influences your Forth solution
17:59:38 <tpbsd> KipIngram, nice one :)
17:59:39 <rdrop-exit> the code ends up looking like a translation from C
17:59:43 <tabemann> KipIngram, the paper products aisle was absolutely empty aside from a misplaced roll of aluminum when I went past there today
17:59:52 <tpbsd> rdrop-exit, not in my case, no way
17:59:59 <tabemann> *aluminum foil
18:00:27 <tpbsd> rdrop-exit, the need to look at the C code is *only* to find what super sekret config was needed
18:01:29 <rdrop-exit> C solutions often have combinatorial explosion built-in
18:01:48 <tpbsd> rdrop-exit, here is a actual comparison for you : https://mecrisp-stellaris-folkdoc.sourceforge.io/touch-sensor.html#stmicro-c-tsc-code-example
18:02:04 <rdrop-exit> e.g., defining constants for every combination instead of exploting regularity
18:02:15 <tpbsd> the top code is obviously C, the bottom code is my actual Forth code
18:03:30 <rdrop-exit> 0 lshift ?
18:03:30 <tpbsd> rdrop-exit, in the MCU in question there are 53 peripherals 722 registers and 4833 bitfields and every single one is different
18:03:58 <tpbsd> rdrop-exit, automatically generated code
18:04:53 <rdrop-exit> I understand there are many peripherals and many registers and many bitfields
18:05:13 <rdrop-exit> there are also many exploitable regularities
18:05:15 <tpbsd> and you understand that they are ALL different ?
18:05:57 <rdrop-exit> do you understand that there are regularities, even if they are all different?
18:06:26 <tpbsd> rdrop-exit, your eagle eye spotting the "0 lshift" is a good reminder to me, I need to recode my parse to get rid of those cases
18:06:54 <tpbsd> rdrop-exit, I'm sure I do not do so anywhere near as well as you :)
18:11:41 <rdrop-exit> what is the definition of TSC_CR in your example?
18:12:43 <tpbsd> rdrop-exit, my most recent improvement to my parser has changed all cases where there is only one bit to change from ": RCC_APB2ENR_IOPAEN   %1 2 lshift RCC_APB2ENR bis! ;  \ RCC_APB2ENR_IOPAEN    I/O port A clock enable" to "17 bit RCC_AHBENR \ RCC_AHBENR_IOPAEN, I/O port A clock enable"
18:13:14 <tpbsd> so I'm slowly improving it, but it's all XML parsing via XLST
18:15:14 <tpbsd> there is no "TSC_CR"
18:15:29 <rdrop-exit> : TSC_CR_PGPSC ( %XXX -- )  12 lshift TSC_CR ; 
18:16:02 <tpbsd> oh ok
18:16:15 <tpbsd> the TSC_CR is a peripheral register
18:16:30 <rdrop-exit> what's the definition?
18:16:35 <tpbsd> and the TSC_CR_PGPSC is a bitfield in that register
18:17:14 <rdrop-exit> it must be more than just a number since it consumes an argument
18:17:44 <tpbsd> TSC control register (TSC_CR)
18:17:59 <rdrop-exit> what is the definition?
18:18:04 <tpbsd> thats it
18:18:10 <rdrop-exit> I mean the Forth definition
18:19:05 <tpbsd> $40024000 constant TSC ( Touch sensing controller ) 
18:19:06 <tpbsd> TSC $0 + constant TSC_CR ( control register ) 
18:19:17 <rdrop-exit> cannot be
18:19:35 <tpbsd> sorry about the delays replying it involves looking up the data sheets etc
18:19:44 <rdrop-exit> in you TSC_CR_PGPSC definition TSC_CR consumes the result of the 12 lshift
18:19:47 <tpbsd> it is I assure you
18:19:55 <rdrop-exit> : TSC_CR_PGPSC ( %XXX -- )  12 lshift TSC_CR ;
18:20:23 <rdrop-exit> note the stack picture ( %XXX -- )
18:20:28 <tpbsd> thats a bitfield named "PGPSC" which is a bit in the TSC_CR
18:20:55 <tpbsd> ok, it's actually a group of 3 bits in the TSC_CR
18:21:41 <rdrop-exit> there's something on the stack, it then gets shifted by 12, and then gets consumed by TSC_CR since the ending stack picture has nothing on it "-- )"
18:21:43 <tpbsd> : TSC_CR_PGPSC ( %XXX -- ) 12 lshift TSC_CR ;  \ TSC_CR_PGPSC, pulse generator prescaler
18:22:18 <tpbsd> Bits 14:12 PGPSC[2:0]: Pulse generator prescaler
18:22:18 <tpbsd>                These bits are set and cleared by software.They select the AHB clock divider used to generate
18:22:18 <tpbsd>                the pulse generator clock (PGCLK).
18:22:18 <tpbsd>                   000: fHCLK
18:22:18 <tpbsd>                   001: fHCLK /2
18:22:19 <tpbsd>                   010: fHCLK /4
18:22:21 <tpbsd>                   011: fHCLK /8
18:22:23 <tpbsd>                   100: fHCLK /16
18:22:25 <tpbsd>                   101: fHCLK /32
18:22:27 <tpbsd>                   110: fHCLK /64
18:22:29 <tpbsd>                   111: fHCLK /128
18:22:31 <tpbsd>                Note: These bits must not be modified when an acquisition is ongoing.
18:22:33 <tpbsd>                Note: Some configurations are forbidden. Please refer to the Section 16.3.4: Charge transfer
18:22:37 <tpbsd>                         acquisition sequence for details.
18:22:38 <tpbsd> thats a paste from the technical pdf
18:22:40 <rdrop-exit> you're not getting what I asked
18:22:48 <tpbsd> apologies for the crappy layout
18:23:11 <tpbsd> what specifically are you asking me for ?
18:23:43 <tpbsd> your last comment was not a question
18:23:56 <rdrop-exit> there's something on the stack, it then gets shifted by 12, and then gets consumed by TSC_CR since the ending stack picture has nothing on it "-- )"
18:25:00 <rdrop-exit> you just said TSC_CR was a constant, I said cannot be since it consumes something off the stack
18:25:18 <tpbsd> there is no suitable stack end picture that I can see
18:25:39 <rdrop-exit> ( %XXX -- )
18:25:42 <tpbsd> TSC_CR is a constant'
18:25:52 <tpbsd> TSC_CR_PGPSC is not
18:26:24 <rdrop-exit> that stack picture implies TSC_CR_PGPSC consumes what's on the stack
18:26:45 <rdrop-exit> when it's done there's one less entry on the stack
18:26:57 <tpbsd> TSC_CR_PGPSC is my current solution for configuring bit(s) in a register such as TSC_CR
18:27:02 <tpbsd> yes, it does
18:27:23 <tpbsd> Im quite proud of that stage of my svd2forth evolution
18:27:28 <rdrop-exit> ok so lets walk through it and see if what you're saying is possible
18:27:35 <tpbsd> please do :)
18:27:47 <rdrop-exit> the stack starts with %XXX on it
18:27:54 <tpbsd> I appreciate your laser like Forth focus on this
18:27:59 <tpbsd> correct
18:28:18 <rdrop-exit> 12 lshift shifts it over, so you still have one thing on the stack
18:28:19 <rdrop-exit> then
18:28:31 <rdrop-exit> TSC_CR is constant
18:28:42 <rdrop-exit> so you now have 2 things on the stack
18:29:13 <rdrop-exit> which contradicts your stack picture ( %XXX -- )
18:29:20 <tpbsd> if you read down the page a bit you will see:  \ 1. CONFIGURE TCS With a charge transfer around 2.5 µs
18:29:20 <tpbsd>    %101 TSC_CR_PGPSC bis!  \ a. Select fPGCLK = fHCLK/32. fPGCLK = fHCLK/32, 101: fHCLK /32
18:29:32 <rdrop-exit> it says you have one less thing on the stack at the end
18:30:09 <rdrop-exit> do you see the contradiction I am pointing out?
18:30:24 <tpbsd> not yet, but Im trying
18:31:54 <tpbsd> perhaps the stack ens could be:  "TSC_CR_PGPSC ( %XXX -- TSC_CR)" ?
18:32:05 <tpbsd> stack end
18:32:35 <rdrop-exit> let's take an example, lets say I start with an empty data stack and I type "123 TSC_CR_PGPSC" what is on the stack now?
18:32:58 <tpbsd> it would fail
18:33:08 <rdrop-exit> your stack comment says there should be nothing on the stack
18:33:11 <tpbsd> because it's awaiting a binary 
18:33:20 <tpbsd> of three bits
18:33:41 <rdrop-exit> ok fine, then type "7 TSC_CR_PGPSC"
18:34:45 <rdrop-exit> if I start with an empty stack and type that, your stack comment says I should end up with an empty stack again
18:35:11 <rdrop-exit> ( %XXX -- )
18:35:44 <tpbsd> and you will because 7 will be moved into that bitfield known as PGPSC
18:35:55 <rdrop-exit> can you try it please
18:36:03 <tpbsd> which is a part of TSC_CR
18:36:22 <rdrop-exit> I thought TSC_CR was just a constant, that's what you said
18:36:30 <tpbsd> it is
18:36:40 <tpbsd> all registers are just constants
18:36:45 <rdrop-exit> constants don't consume items off the stack
18:36:59 <rdrop-exit> they push an item onto the stack
18:37:21 <tpbsd> sounds reasonable :)
18:37:32 <rdrop-exit> If I have nothing on the stack, after a constant, I have something on the stack
18:38:03 <rdrop-exit> so how do you end up with nothing ( %XXX -- )<===
18:38:13 <tpbsd> : TSC_CR_PGPSC ( %XXX -- )  12 lshift TSC_CR ; is how
18:39:01 <rdrop-exit> lets say I have 7 on the stack
18:39:05 <rdrop-exit> ---> 7
18:39:06 <tpbsd> there is a Word action missing that is present in the next stage of that configuration
18:39:13 <tpbsd> ok
18:39:35 <rdrop-exit> I then push 12
18:39:42 <tpbsd> ok
18:39:43 <rdrop-exit> ---> 7 12
18:39:46 <tpbsd> sure
18:40:12 <rdrop-exit> I then lshift
18:40:18 <tpbsd> ok
18:40:32 <rdrop-exit> ---> 28672
18:40:38 <tpbsd> yes
18:40:52 <tpbsd> and thats where the second word is used
18:41:05 <rdrop-exit> I then have the constant TSC_CR, for arguments sake, lets say it's 100
18:41:07 <tpbsd> because it contains a 'bis!' action
18:41:18 <rdrop-exit> so it's not a constant then?
18:41:38 <rdrop-exit> what is TSC_CR's definition please
18:41:38 <tpbsd> TSC_CR is certainly a constant
18:41:47 <rdrop-exit> what's it's value
18:42:00 <tpbsd> $40024000 constant TSC ( Touch sensing controller ) 
18:42:00 <tpbsd> TSC $0 + constant TSC_CR ( control register ) 
18:42:10 <tpbsd> same as when you asked last time
18:42:12 <tpbsd> :)
18:42:31 <rdrop-exit> ok so after it gets executed:
18:42:49 <rdrop-exit> ---> 28672 $40024000
18:42:58 <rdrop-exit> that's your stack
18:43:32 <rdrop-exit> it's not empty as ( %XXX -- ) is telling us
18:43:38 <tpbsd> ahh I think I see where youre going
18:44:00 <tpbsd> and youre responsible for that anyway !
18:44:03 <tpbsd> hahahah
18:44:12 <rdrop-exit> grrr :)
18:44:29 <tpbsd> that Word previously had : TSC_CR_PGPSC ( %XXX -- )  12 lshift TSC_CR BIS! ;
18:44:38 <rdrop-exit> aha
18:45:09 <tpbsd> but after you mentioned that the action was better used later, I removed it
18:45:18 <tpbsd> and it's used here 
18:45:40 <tpbsd>  %101 TSC_CR_PGPSC bis!  \ a. Select fPGCLK = fHCLK/32. fPGCLK = fHCLK/32, 101: fHCLK /32
18:46:09 <rdrop-exit> You could do this instead:
18:46:25 <rdrop-exit> %101 PGPSC TSC_CR bis!
18:46:25 <tpbsd> at the time when you mentioned it, my code would have been "%101 TSC_CR_PGPSC" which always worried me anyway
18:46:36 <tpbsd> as it looked incomplete
18:48:03 <tpbsd> it's too bad tabemann is asleep, this info will be very relevant to him 
18:48:37 <rdrop-exit> : PGSPC ( mask -- x ) 12 lshift ;
18:49:29 <tpbsd> I dont like that because it doesnt indicate how many bits in the mask 
18:49:42 <rdrop-exit> ok then
18:49:46 <tpbsd> and whats a "x" ?
18:50:01 <tpbsd> please forgive my ignorance here
18:50:15 <rdrop-exit> : PGSPC ( %xxx --- x ) 12 lshift ;
18:50:48 <rdrop-exit> x just means an a generic something
18:51:03 <tpbsd> : TSC_CR_PGPSC ( %XXX -- )  12 lshift TSC_CR ;
18:51:09 <tpbsd> hmm
18:51:31 <tpbsd> : PGSPC ( %xxx --- x ) 12 lshift ;  is definitely no good
18:51:36 <tpbsd> reason ?
18:51:57 <tpbsd> there may be TWO or more PGSPC and theyre all different
18:52:47 <tpbsd> sadly the CMSIS-SVD was never run thru a program to detect bitfields with the same name
18:52:58 <tpbsd> when STM designed the bitfield names
18:53:16 <rdrop-exit> that's a shame, you can only exploit the regularities that exist
18:53:18 <tpbsd> it would have made my solution a lot easier
18:53:50 <tpbsd> lol, in my first iterations I did assume that all bitfield names were unique
18:54:10 <tpbsd> and that worked fine until I discovered they wern't
18:54:13 <tpbsd> :(
18:54:22 <rdrop-exit> I usually use dot notation in that case
18:54:42 <tpbsd> and if that was the only problem it would have been ok
18:54:48 <rdrop-exit> tsc-cr.pgspc
18:55:33 <rdrop-exit> if its a mask I usually start the name with a percent sign
18:55:42 <rdrop-exit> %tsc-cr.pgspc
18:55:51 <tpbsd> I was tempted to use that strategy
18:56:10 <tpbsd> but it's a matter of viewpoint here
18:56:23 <rdrop-exit> I hate underscores in names, like C uses
18:56:24 <tpbsd> your's is a programmers perstective, mine is a tech
18:56:38 <tpbsd> yeah, I also avoid underscores generally
18:56:58 <tpbsd> you see TSC_CR_PGPSC as a mask, I dont
18:57:05 <rdrop-exit> 0 source  RV32 - CPU Regs - CSRs - D-Mode - csr.dcsr  1|2
18:57:05 <tpbsd> I see it as a bitfield
18:57:05 <rdrop-exit> 1
18:57:05 <rdrop-exit> 2 $ 7b0  constant csr.dcsr
18:57:05 <rdrop-exit> 3
18:57:05 <rdrop-exit> 4   31 28 bits  constant %csr.dcsr.xdebugver
18:57:08 <rdrop-exit> 5 \ 27 16 bits  hardwired 0
18:57:10 <rdrop-exit> 6      15 bit   constant %csr.dcsr.ebreakm
18:57:13 <rdrop-exit> 7 \    14 bit   hardwired 0
18:57:15 <rdrop-exit> 8      13 bit   constant %csr.dcsr.ebreaks
18:57:18 <rdrop-exit> 9      12 bit   constant %csr.dcsr.ebreaku
18:57:20 <rdrop-exit> a      11 bit   constant %csr.dcsr.stepie
18:57:23 <rdrop-exit> b      10 bit   constant %csr.dcsr.stopcount
18:57:25 <rdrop-exit> c       9 bit   constant %csr.dcsr.stoptime
18:57:28 <rdrop-exit> d    8  6 bits  constant %csr.dcsr.cause
18:57:30 <rdrop-exit> e \     5 bit   hardwired 0
18:57:33 <rdrop-exit> 0 source  RV32 - CPU Regs - CSRs - D-Mode - csr.dcsr  2|2
18:57:35 <rdrop-exit> 1
18:57:38 <rdrop-exit> 2       4 bit   constant %csr.dcsr.mprven
18:57:40 <rdrop-exit> 3       3 bit   constant %csr.dcsr.nmip
18:57:43 <rdrop-exit> 4       2 bit   constant %csr.dcsr.step
18:57:45 <rdrop-exit> 5    1  0 bits  constant %csr.dcsr.prv
18:57:51 <rdrop-exit> that's how I define bitfield masks for registers
18:58:40 <rdrop-exit> that's a 32 bit debug control and status register
18:58:43 <tpbsd> it's awesome to see your perspective and method
19:00:07 <rdrop-exit> the source is from a forth screen block, the digits on the extreme left are just the line numbers 0-f
19:00:50 <tpbsd> I note that in this example each bitfield is limited to one bit ?
19:01:00 <rdrop-exit> no look again
19:01:11 <rdrop-exit> 8  6 bits  constant %csr.dcsr.cause
19:01:26 <tpbsd> ahh!
19:01:51 <rdrop-exit> that defines a constant that has bits 8,7,6 set
19:02:00 <tpbsd> so %csr.dcsr.cause uses bits 8,7,6 ?
19:02:05 <rdrop-exit> yes
19:02:29 <rdrop-exit> its value is therefore % 111000000
19:02:45 <rdrop-exit> onlu bits 8..6 are set
19:02:52 <rdrop-exit> * only
19:02:57 <tpbsd> and do you intend to supply these for every MCU you support ?
19:03:52 <tpbsd> GD32VF103Cx 	46 peripherals	1074 registers	7713 bitfields
19:04:06 <rdrop-exit> sure but you don't use all of them
19:04:14 <tpbsd> and the only definitions are in ARM CMSIS-SVD
19:04:21 <tpbsd> ??
19:04:22 <rdrop-exit> I normally just define what I need as I read the spec
19:04:29 <tpbsd> but you may use any ONE of them ?
19:04:59 <rdrop-exit> as I said, I define *what I need* as I read the spec
19:05:26 <tpbsd> well youre a programmer, but I found that hand transcribing from the data sheets to code is fraught with errors, thats why I automated the provess
19:06:02 <tpbsd> and thats what every embedded user of Mecrisp-Stellaris was doing before I designed my svd2forth
19:06:02 <tabemann> back
19:06:10 <tpbsd> welcome back! tabemann 
19:06:26 <rdrop-exit> that's why I use notations that are less error prone, I just type them in as I read them
19:06:40 <tpbsd> it resulted in many different names for the same things and total code incompatibility
19:07:04 <tpbsd> my experience tells me youre painting yourself into a corner
19:07:27 <tpbsd> it's definitely the Forth way to do it tho :)
19:07:33 <rdrop-exit> nope, no matter how you define them, you need to test them before you use them
19:08:22 <tpbsd> I cant help but think that the full meaning of "GD32VF103Cx  46 peripherals 1074 registers 7713 bitfields" hasn't yet fully sunk in for you yet 
19:09:01 <rdrop-exit> but I'll never use all of those, I only ever bother with what I am using
19:09:02 <tpbsd> just a quick test, can you please count out loud from 1 to 7713 for me ?
19:09:17 <tpbsd> and let me know when youve finished ?
19:09:31 <tabemann> : foo 7713 1 do i . loop ;
19:09:33 <tabemann> foo
19:09:35 <tpbsd> you dont have to uae all of them
19:09:36 <tpbsd> hahah
19:09:52 <rdrop-exit> If I need a frombulator, I read the frombulator spec, and type in the constants as I read it
19:10:17 <tpbsd> and fair enough
19:10:33 <tpbsd> tabemann, YOU CHEAT!
19:10:40 <rdrop-exit> I'm so used to doing it that way, it's second nature
19:10:50 <tpbsd> rdrop-exit, I can see that
19:11:11 <rdrop-exit> anything I don't need, I'm not going to bother with
19:11:20 <tpbsd> rdrop-exit, I do see now that my stack picture is incomplete tho :)
19:11:31 <rdrop-exit> cool :)
19:11:45 <tpbsd> rdrop-exit, thanks for taking the time to get that thru my thick techs head 
19:11:45 <tabemann> with zeptoforth I've only used small pieces of the device space, so I've haven't had the need to use the converted SVD file you sent me tp
19:12:04 <tpbsd> tabemann, of course not, it's still early days
19:12:38 <tpbsd> tabemann, wait until you want to build say ... a capacitance touch sensor
19:13:14 <tabemann> right now all I've needed to do is A) set up the processor clock B) set up the USART C) read and write to the flash D) read and write to the USART and E) turn on and off LEDs
19:13:37 <tabemann> *write and erase the flash
19:14:16 <tpbsd> tabemann, youve made a blinky and that requires you do all the config required, so now you have 1) read the tech data and assimilated it, 2) written the code, 3) verified it works by the flashing of the led ... so you have covered all the important aspects
19:14:47 <tabemann> actually I stole the LED driver code from Matthias Koch - lol
19:14:57 <tpbsd> that's ok, not important
19:14:58 <rdrop-exit> here's a JTAG Test Access Point for a RISC-V
19:15:06 <rdrop-exit> 0 source  RV32 - Debug Translator - TAP DRs - tap.dtmcs  2|2
19:15:06 <rdrop-exit> 1
19:15:06 <rdrop-exit> 2 \ 31 18 bits  hardwired 0
19:15:06 <rdrop-exit> 3      17 bit   constant %tap.dtmcs.dmihardreset
19:15:06 <rdrop-exit> 4      16 bit   constant %tap.dtmcs.dmireset
19:15:08 <rdrop-exit> 5 \    15 bit   hardwired 0
19:15:11 <rdrop-exit> 6   14 12 bits  constant %tap.dtmcs.idle
19:15:13 <rdrop-exit> 7   11 10 bits  constant %tap.dtmcs.dmistat
19:15:16 <rdrop-exit> 8    9  4 bits  constant %tap.dtmcs.abits
19:15:18 <rdrop-exit> 9    3  0 bits  constant %tap.dtmcs.version
19:15:21 <rdrop-exit> a
19:15:23 <rdrop-exit> b
19:15:44 <rdrop-exit> or rather that's a TAP data register
19:17:09 <rdrop-exit> (the Debug Translator Module Control and Status Test Access Point data register to be exact)
19:17:40 <rdrop-exit> oops Debug Transport Module, not Translator Module
19:17:59 <tpbsd> rdrop-exit, the reason I didn't use "." as a peripheral.register.bitfield" separator was because I do a LOT of grepping and it's just easier to use a "-" as the separator when searching
19:18:36 <rdrop-exit> Ah, I use my block editor's search 
19:19:14 <tpbsd> personally I prefer the "." as a separator
19:19:19 <tpbsd> it's just neater
19:20:07 <tpbsd> tabemann, what's vitally important is you go thru the process from code to making a led blink
19:20:15 <rdrop-exit> I typed those bitfields as I was reading one of those register bitfield diagrams from the RISC-V spec
19:20:56 <tpbsd> tabemann, then you understand what is needed when you have to configure a peripheral with *hundreds* of bitfields that must be individually configured
19:21:36 <tabemann> even the minimal peripherals I deal with are non-obvious to initialize
19:22:19 <tpbsd> rdrop-exit, and that's fine, I did, as does any Mecrisp-Stellaris user who isnt using my svd2forth but it's very error prone, and time consuming
19:22:27 <tabemann> and really all I'm initialize are the clock, the USART, the flash, and the LEDs
19:22:30 <tpbsd> tabemann, *exactly*
19:23:35 <tpbsd> from experience I can see rdrop-exit wondering why a peripheral isnt doing what he wants. He has to check his code AND his hand typed manual to code config
19:24:51 <tpbsd> while riscv is undoubtedly 'better' than STM32, it's documentation is *utter shit* in comparison to STM
19:25:21 <tpbsd> STM doc looks like it was written by Ghods tech dept after reading the GD32VF103 doc
19:25:33 <rdrop-exit> the time consuming part is testing, the typing I do as I read the spec, I also find typing code and comments as I read helps me grok the spec
19:26:20 <tpbsd> rdrop-exit, I'm convinced that nothing you do is not well thought out first
19:27:20 <tpbsd> rdrop-exit, but the tyranny of configs makes the grocking it all simply beyond everyone
19:28:00 <rdrop-exit> I not only type the bitfields but each shadow comment too:
19:28:02 <rdrop-exit> 0 shadow  RV32 - DMRs - dmr.dmstatus  1|12
19:28:02 <rdrop-exit> 1
19:28:02 <rdrop-exit> 2 dmr.dmstatus
19:28:02 <rdrop-exit> 3  Offset from a DM's base DMI bus address of its dmr.dmstatus
19:28:04 <rdrop-exit> 4  (Debug Module Status) DMR (32-bit, R/O).
19:28:07 <rdrop-exit> 5  This DMR reports status for the overall DM as well as the
19:28:09 <rdrop-exit> 6  currently selected harts, as defined in hasel.
19:28:12 <rdrop-exit> 7
19:28:14 <rdrop-exit> 8 %dmr.dmstatus.impebreak
19:28:17 <rdrop-exit> 9  Bit mask for isolating the dmr.dmstatus impebreak bit (R/O,
19:28:19 <rdrop-exit> a  preset).
19:28:22 <rdrop-exit> b  When the corresponding DMR bit is set it indicates that there
19:28:24 <rdrop-exit> c  is an implicit ebreak instruction at the non-existent word
19:28:25 <tpbsd> there are those that disdain standards such as CMSIS-SVD but I dont think they understand the tyrany of ARM configs either
19:28:27 <rdrop-exit> d  immediately after the Program Buffer.
19:28:30 <rdrop-exit> e
19:29:03 <tpbsd> youre a artisan rdrop-exit !
19:29:54 <tpbsd> in my case it takes 0.1 second to create all the Words for every bitfield in any MCU with a CMSIS-SVD
19:30:08 <tpbsd> some may generate 1MB of text
19:31:10 <tpbsd> sure, my system is far from perfect, but the things that stop my projects working arent due to manufacturer spec errors
19:32:24 <rdrop-exit> I can't grok anything in 0.1s
19:32:26 <tpbsd> theyre the usual problems of not grocking a *complex* peripheral, not realising that some register has a "guard register" and nothing I do will work until that is satisfied, and a million other reasons
19:32:46 <tabemann> back
19:33:03 <tabemann> tp: I'm gonna create a scheduler to use with my multitasker
19:33:22 <tpbsd> nor can I, but my time is spent under`standing the peripheral, not hand writing the registers
19:33:24 <tabemann> where each scheduled "action" is just a word called round robin
19:33:37 <tabemann> with no separate stack
19:33:52 <tabemann> the scheduler can be used with or without the multitasker
19:34:07 <tpbsd> tabemann, mine is even simpler, just task1 ... task2 etc
19:34:29 <rdrop-exit> My strategy is to read the spec and take notes that happen to be usable as code, then to test my assumptions
19:34:35 <tpbsd> with the limited resources of my MCU I have to be careful to conserve them
19:35:11 <tabemann> my motivation is that each task is kinda heavy-weight, and what I'm trying to do is going to result in a bunch of tasks
19:35:12 <tpbsd> rdrop-exit, mine is similar, I just dont have to hand code the memory maps and bitfields
19:35:25 <tpbsd> tabemann, aha, makes sense
19:35:31 <tabemann> whereas most of these don't actually require their own stacks
19:35:45 <tabemann> just a function that is called repeatedly
19:35:58 <tpbsd> same here
19:36:05 <rdrop-exit> If they don't need their own stacks, then they're coroutines rather than tasks
19:36:41 <rdrop-exit> that's the main differentiator between a task and a coroutine
19:36:49 <tpbsd> in my most recent touch sensor, I call the task that activates the peripheral every 100ms, but 10ms after the first task, another one prints the results
19:37:35 <tpbsd> rdrop-exit, thats not suitable for me as the word 'coroutine' is far too long!
19:37:51 <tpbsd> :)
19:38:08 <tpbsd> courotine-1 ... thats exhausting to type!
19:38:14 <rdrop-exit> you don't need a "coroutine" word, just a yield word
19:38:18 <tpbsd> task1 I can handle
19:38:34 <tpbsd> i only have a scheduler, theer is no yield
19:38:42 <tpbsd> it's not a multitasker
19:38:49 <tabemann> a yield requires saving a PC
19:38:57 <tabemann> I don't intend to save a PC
19:39:00 <tpbsd> there is no stack for every task
19:39:14 <tabemann> I intend to just call a function again and again and again
19:39:27 <rdrop-exit> a coroutine yield only requires a primitive that swaps the TOS with the TOR
19:39:53 <tpbsd> it's just a timed sequence, much like Boeings recent failed space capsule uses ...
19:39:56 <rdrop-exit> what Chuck calls EX in Color Forth
19:40:16 <rdrop-exit> TOS <-> TOR
19:41:14 <tabemann> what I am planning on doing in ways is more elaborate than that, because the scheduler also pauses between actions so that the main prompt functions
19:41:19 <rdrop-exit> YIELD is just like PAUSE but for coroutines
19:41:31 <tabemann> (it's meant to be used with the multitasker)
19:42:51 <tabemann> anyway, swapping the TOS and TOR only works when you have two coroutines
19:43:16 <tabemann> whereas I envision having arbitrary numbers of them
19:46:02 <rdrop-exit> you can have as many as you want, but you have to be <Elmer Fudd voice> very very careful
19:46:49 <rdrop-exit> Coroutines are much more delicate to work with than tasks
19:47:20 <rdrop-exit> Since coroutines are sharing the tasks you can only yield at stack neutral points
19:48:07 <rdrop-exit> * sharing the stacks (not tasks)
19:49:07 <rdrop-exit> they're most useful for polling devices intermittently from a mainline
19:53:27 --- join: boru` joined #forth
19:53:31 --- quit: boru (Disconnected by services)
19:53:33 --- nick: boru` -> boru
19:54:28 <rdrop-exit> I'm trying to find the Chuck's page that discusses the instruction, my Google-fu is not up to snuff today
19:56:15 <rdrop-exit> the EX instruction appears also in this Green Arrays flyer:
19:56:17 <rdrop-exit> http://www.greenarraychips.com/home/documents/greg/PB003-110412-F18A.pdf
19:57:08 --- quit: X-Scale (Ping timeout: 240 seconds)
19:58:05 --- join: X-Scale` joined #forth
19:58:28 --- nick: X-Scale` -> X-Scale
20:09:19 <rdrop-exit> Found it! 
20:09:57 <rdrop-exit> scroll down to the opcode 01, the "ex" instruction on this page:
20:10:01 <rdrop-exit> https://colorforth.github.io/inst.htm
20:11:27 <rdrop-exit> My description should have said eexchange the IP with the TOR
20:11:34 <rdrop-exit> IP <--> TOR
20:13:00 <rdrop-exit> brain fart
20:14:12 <rdrop-exit> If you're going to have a subroutine YIELD you might as well also have conditional variants ?YIELD and 0YIELD
20:14:24 <rdrop-exit> as well
20:15:23 <rdrop-exit> yield ()( r: ra -- ip )
20:15:32 <rdrop-exit> 0yield ( x|0 -- )( r: ra -- ra|ip )
20:15:42 <rdrop-exit> ?yield ( x|0 -- )( r: ra -- ip|ra )
20:16:28 <rdrop-exit>  yield Yield to coroutine.
20:16:34 <rdrop-exit> 0yield Yield on zero.
20:16:42 <rdrop-exit> ?yield Yield on non-zero.
20:17:13 <tpbsd> bak, sorry the worlds most awesome daughter phoned me:)
20:17:33 <rdrop-exit> why are my daughters phoning you?
20:17:49 <tpbsd> hahah, I knew that was coming
20:17:58 <rdrop-exit> ;)
20:18:09 <tpbsd> I cant say more because I don't want to shatter any fathers illusions :)
20:18:18 <rdrop-exit> :-p
20:18:50 <tpbsd> I'm pretty sure that you have the worlds 2nd most awesome daughter tho
20:19:14 <rdrop-exit> well I have 2 daughters
20:22:07 <rdrop-exit> tabemann, you might find "Patters of Time-Triggered Embedded Systems" by Michael J. Pont an interesting read, the examples are all 8051 based, but the patterns are more or less generic
20:22:12 --- quit: dys (Ping timeout: 264 seconds)
20:22:36 <rdrop-exit> * Patterns for Time-Triggered Embedded Systems
20:22:43 <tpbsd> I have 2 daughters but only one that I run to the phone if I know it's her 
20:23:15 <dzho> dang
20:23:41 <rdrop-exit> I have 4 kids, boy, girl, boy, girl, and 1 grand-daughter
20:23:57 <tpbsd> I have 6 kids, 4 boys, 2 girls
20:24:10 <tpbsd> and 4 grandkids
20:24:26 <tabemann> back
20:24:35 <rdrop-exit> you're a braver man than I tp
20:24:57 <rdrop-exit> dzho, dang?
20:25:08 <tpbsd> rdrop-exit, your chats are always very instructive, and naturally a massive assistance to my Forth understanding and designs
20:25:09 <tabemann> I have one daughter
20:25:33 <rdrop-exit> thanks tp
20:25:37 <tpbsd> rdrop-exit, I wanted 4, my ex wife wanted lots more and forget to mention it. Shes now had 7
20:26:20 <tpbsd> rdrop-exit, I dont find our chats confrontational at all, and besides, I'm a utterly steady fellow
20:26:28 <tabemann> 1 was enough for me
20:26:47 <tpbsd> my main characteristic is ignorance
20:27:03 <dzho> rdrop-exit: just a big difference is all
20:27:05 <tpbsd> tabemann, perfectly understandable (these days)
20:27:18 <rdrop-exit> Our fifth didn't make it to term, which was not easy for my wife, so we stopped
20:27:28 <tpbsd> that would be very hard
20:27:47 <tpbsd> Ive been luckym, the eldest is 42 and theyre all still in good health
20:28:03 <tpbsd> tho a zillion close shaves
20:28:06 <rdrop-exit> excellent
20:28:18 --- join: logand` joined #forth
20:29:06 <rdrop-exit> bbiab, have to walk the poor dogs on the roof because of quarantine
20:31:39 <tpbsd> I saved the life of my fav daughter once, she was weighed down by a huge backpack as we headed to the airport, she was bound for Thailand or some where (I can't remember) and as we crossed a green pedestrian light in Perth I saw a car coming straight thru the lights without stopping and headed right towards my daughter! I grabbed her backpack and physically threw her out of the path of the car which had just hit the skids but was still moving fast
20:31:44 --- quit: logand (Ping timeout: 250 seconds)
20:32:23 <tpbsd> Ive constantly reminded her of the fact that she owes me her life but she just ignores me !
20:32:40 <tpbsd> haha, 400 laps around the roof ?
20:33:02 <tpbsd> the car would have run her over for sure
20:44:02 <rdrop-exit> back
20:44:28 <rdrop-exit> here's a legal free download of the book I mentioned earlier:
20:44:30 <rdrop-exit> https://www.safetty.net/download/pont_pttes_2001.pdf
20:48:19 <tpbsd> rdrop-exit, awesome! thanks
20:48:28 <tpbsd> I'll definitely be reading that
20:52:23 <rdrop-exit> My pleasure, although I think you already know this stuff inside-out
20:53:30 <tpbsd> probably not, I've never done anything but big loop stuff
20:53:56 <tpbsd> simple stuff
20:56:40 <rdrop-exit> It's an almost 20 year old book, and he uses 8051 in the examples. Parts C, F, and H are the interesting ones.
20:57:45 <rdrop-exit> That's where he covers schedulers.
20:59:12 <tabemann> back
21:00:20 <rdrop-exit> Time-Triggered scheduling is all about minimizing reliance on non-timer based interrupts for safety critical systems.
21:00:33 <tpbsd> ah cool
21:00:59 * tabemann got a blinker working using his new scheduler
21:01:11 <rdrop-exit> kudos tabemann
21:01:57 <rdrop-exit> tabemann, I posted a download link for the book I mentioned earlier
21:02:10 --- join: iyzsong joined #forth
21:02:43 <tpbsd> tho one of the criticisms of the deadly Toyota Camry EMU was it's use of patting the watchdog using the systick hardware timer
21:02:59 <rdrop-exit> eek
21:04:00 <rdrop-exit> Koopman, who wrote the stack machine book, is now an expert in automotive and safety critical embedded systems
21:04:26 <tpbsd> and it was he who wrote that criticism
21:05:18 <tpbsd> it's riveting reading
21:05:47 <rdrop-exit> I have his "Better Embedded System Software Book"
21:06:18 <rdrop-exit> It has good checklists
21:07:11 <tabemann> I really need to get systick working
21:07:22 <tabemann> so I can time things off actual time rather than pause-count
21:07:40 <tabemann> pause-count being a counter that is incremented every time PAUSE is called
21:08:13 <rdrop-exit> that doesn't seem very useful
21:08:55 <tabemann> pause-count isn't actual time obviously, but it's sufficient for things like getting blinkies to work
21:09:18 <tpbsd> https://www.viva64.com/en/b/0439/     Toyota: 81 514 issues in the code
21:10:07 <tpbsd> tabemann, systick is the simplest of all to configure
21:10:33 <rdrop-exit> Lots of duplicates in those issues I assume
21:12:00 <tpbsd> Two engineers started the investigation. Michael Barr and Philip Koopman. It took them 20 months to review 280 000 lines of code and write a 800-page long report. Each.
21:12:00 <tpbsd> The address was kept in secret. The hotel room, where the engineers worked was guarded 24 hours a day - security ensured that nobody was bringing in or taking out any papers. All the phones and internet connections were disabled.
21:12:19 <rdrop-exit> wow
21:13:58 <tpbsd> http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf
21:14:09 <tpbsd> thats what you want
21:16:42 <rdrop-exit> they used recursion in an embedded system, wow
21:18:58 <tpbsd> 2005 Camry L4 has >11,000 global variables
21:21:24 <tpbsd> No bug-tracking system !
21:22:00 <rdrop-exit> globals aren't necessarily a problem, memory is memory
21:22:31 <tabemann> okay, I'm gonna hit the sack
21:22:34 <tabemann> g'night guys
21:22:37 <tpbsd> cya
21:22:46 <rdrop-exit> goodnight tabemann
21:26:27 <rdrop-exit> the core problem seems to be "undetected Task death"
21:26:28 --- quit: dave0 (Quit: dave's not here)
21:26:58 <tpbsd> agree
21:28:07 <rdrop-exit> At Hitachi if you fucked up they'd tranfer you to Hitachi Bento, which was the company that delivered lunches to the employees.
21:28:30 <rdrop-exit> Back when lifetime employment was still a thing
21:48:51 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in)
21:49:14 --- join: iyzsong joined #forth
22:13:59 --- join: logand`` joined #forth
22:18:36 --- quit: logand` (Ping timeout: 264 seconds)
22:33:55 --- quit: dddddd (Ping timeout: 246 seconds)
22:56:31 --- join: gravicappa joined #forth
23:20:20 --- quit: deesix (Ping timeout: 268 seconds)
23:32:05 --- quit: gravicappa (Remote host closed the connection)
23:40:22 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in)
23:40:46 --- join: iyzsong joined #forth
23:59:59 --- log: ended forth/20.03.17