00:00:00 --- log: started forth/20.02.01
00:14:14 --- join: dys joined #forth
00:39:25 --- quit: _whitelogger (Remote host closed the connection)
00:42:28 --- join: _whitelogger joined #forth
01:40:45 --- quit: forthnutter (Quit: forthnutter)
02:19:35 --- join: f-a joined #forth
04:07:00 --- quit: jn__ (Ping timeout: 252 seconds)
04:29:40 --- quit: jsoft (Ping timeout: 268 seconds)
04:32:35 --- quit: f-a (Quit: leaving)
05:54:06 --- join: dddddd joined #forth
06:04:01 --- quit: ryke (Ping timeout: 240 seconds)
06:06:46 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in)
06:29:48 --- quit: ovf ()
06:31:21 --- join: ovf joined #forth
06:57:19 --- quit: djinni (Quit: Leaving)
07:27:23 --- join: djinni joined #forth
07:47:07 --- quit: tabemann (Ping timeout: 248 seconds)
07:59:53 --- join: jn__ joined #forth
08:11:08 --- quit: proteusguy (Remote host closed the connection)
08:20:59 --- quit: rann ()
08:21:34 --- join: rann joined #forth
08:34:31 --- quit: dave0 (Quit: dave's not here)
09:42:17 --- join: ryke joined #forth
11:45:41 --- quit: ryke (Ping timeout: 260 seconds)
12:35:37 --- join: ryke joined #forth
12:55:08 --- join: Croran joined #forth
13:07:53 --- quit: Croran (Remote host closed the connection)
13:13:44 --- quit: gravicappa (Ping timeout: 265 seconds)
13:59:36 --- join: jsoft joined #forth
14:10:09 --- quit: jedb (Remote host closed the connection)
14:10:26 --- join: jedb joined #forth
14:33:37 --- join: tabemann joined #forth
14:57:25 --- quit: _whitelogger (Remote host closed the connection)
15:00:27 --- join: _whitelogger joined #forth
15:38:43 <tabemann> question
15:39:36 <tabemann> does anyone have any recommendations on how to implement CREATE and <BUILD / DOES> in a native code forth?
15:39:36 --- join: crab1 joined #forth
15:39:55 <tabemann> okay, for crab1, who just entered:
15:39:58 <tabemann> does anyone have any recommendations on how to implement CREATE and <BUILD / DOES> in a native code forth?
15:40:09 <crab1> wym by native code
15:40:33 <tabemann> like it compiles to actual processor instructions
15:41:42 <siraben> Anyone know of a formal semantics for a subset of Forth? I'm working through http://concrete-semantics.org/ and there's some pretty interesting stack machine compilation going on in the later chapters.
15:42:05 <siraben> This is pretty good; https://pdfs.semanticscholar.org/43cd/c0f52701e022b506b5819d6a3c4fea12c001.pdf
15:42:13 <siraben> "Forth Semantics for Compiler Verification"
15:43:56 <tabemann> to me at least, there's a reason even Haskell doesn't have formal semantics
15:44:16 <siraben> tabemann: Yes, but the core language, System F Omega, does.
15:44:32 <siraben> Also Haskell is enormously complex at this point to do a formal semantics.
15:44:45 <tabemann> yeah
15:44:58 <crab1> Haskell is too much
15:45:19 <tabemann> the problem I see with forth is that it has direct arbitrary access to memory
15:45:25 <siraben> Given Forth's simplicity, it would be a good way to learn about grounding a small language's semantics, IMO.
15:45:44 <siraben> crab1:  Could you elaborate?
15:45:52 <siraben> tabemann: Right, and self-modifying code as well.
15:46:00 <tabemann> exactly
15:46:38 <siraben> (there is research on SMC, but that's way beyond a toy stack language I'm trying to practice formal semantics on)
15:46:43 <siraben> research on SMC semantics*
15:46:51 <siraben> http://flint.cs.yale.edu/flint/publications/smc.pdf
15:47:34 <siraben> tabemann:  Then a small core has to be kept, w/out SMC or direct access to memory.
15:47:49 <siraben> Stack operations, WHILE, IF, various looping operators.
15:48:04 <siraben> Return stack too, perhaps.
15:48:21 <crab1> Haskell is too much: the language is complicated, there's too much to know and keep track of when using it, I think
15:50:03 <siraben> crab1: I think the language is actually pretty small. The ecosystem and libraries are huge, yes, but recently seeing a small self-hosting compiler with a C runtime has changed my mind; https://github.com/blynn/compiler
15:50:54 <siraben> Certainly, the variuos language extensions added over the years have added complexity enormously.
15:51:02 <siraben> s/variuos/various
15:51:06 <crab1> Also I like that forth programs can be self modifying and allow memory manipulation to occur freely, it shouldn't be terribly hard to ensure a word does not modify the program or do bad with memory
15:52:16 <siraben> crab1:  Right, seems like it's just a matter of seeing if an arbitrary write happens for that word.
15:52:24 <crab1> siraben: I would argue that becoming a regular haskeller requires you to be involved in the ecosystem, like the ecosystem and the language are inseperable
15:52:52 <crab1> also I need to stop participating in multiple tracks of conversation at once, it's weird
15:53:21 <siraben> crab1: Yeah, to transition to using a language do things, ecosystem is a must, and I agree that it's pretty wild out there.
15:54:03 <siraben> Sort of fun, we'll see what comes out of it all, decades from now.
15:54:24 <crab1> I do like functional though, I just think I need a different language for it
15:54:49 <siraben> Thanks for the inputs crab1, tabemann, I've got to go.
15:55:08 <crab1> toodleoo
16:03:20 --- join: X-Scale` joined #forth
16:05:51 --- quit: X-Scale (Ping timeout: 260 seconds)
16:05:51 --- nick: X-Scale` -> X-Scale
16:10:53 <crab1> tabemann: how you make CREATE and DOES> will depend on some design decisions like threading technique and all but CREATE has to make a word's header and code field from its name and link it to the dictionary then I think before DOES> and (DOES>) you should look at ;CODE and (;CODE).
16:11:30 <crab1> https://www.bradrodriguez.com/papers/moving3.htm may be helpful
16:22:56 <tabemann> back
16:23:39 <tabemann> I'm implementing CREATE separately from <BUILD / DOES>
16:24:07 <tabemann> so I can have a simpler implementation of CREATE
16:29:14 <crab1> I don't know how you would do it without implementing them separately
16:33:36 <crab1> but yeah create just makes a header something like | 4 NAME link |
17:14:15 --- quit: tabemann (Ping timeout: 265 seconds)
17:59:52 --- quit: ryke (Ping timeout: 265 seconds)
18:39:17 --- join: iyzsong joined #forth
18:51:10 --- join: boru` joined #forth
18:51:14 --- quit: boru (Disconnected by services)
18:51:16 --- nick: boru` -> boru
18:58:12 <jsoft> tp, Hey so whats your synopsis on stm32l0's vs other mecrisp capable low power uC offerings?
20:18:23 --- join: rdrop-exit joined #forth
20:29:57 <rdrop-exit> c[] good afternoon Forthwrights
20:30:41 <tp> afternoon oh unwell Zen Forth Guru living in the shadow of the volcano!
20:31:06 <rdrop-exit> my life is one big adventure ;-)
20:31:20 <rdrop-exit> hello Master Forth Technician (tm)
20:31:37 <tp> sounds like it!
20:32:47 <tp> rdrop-exit, as youre the local risc-v guru, in your readings did you see only JTAG, was there any mention of SWD ?
20:33:30 <rdrop-exit> Isn't SWD ARM specific?
20:33:51 <tp> yes
20:34:06 <tp> at least I believe so
20:34:12 <rdrop-exit> Basically in the RISC-V spec they have a thing called the DMI (Debug Module Interface)
20:34:27 <rdrop-exit> which in theory doesn't have to be JTAG
20:34:37 <tp> rdrop-exit, have you read the debug specs for cortex-m ?
20:34:52 <rdrop-exit> but for the moment the only DMI that's spec'd is a JTAG DMI
20:35:05 <rdrop-exit> no, I have not
20:35:24 <rdrop-exit> I didn't delve into ARM, decided to focus on RISC-V
20:35:26 <tp> darn, youre the one person who could help me if he had!
20:36:10 <rdrop-exit> You're having problems with SWD?
20:36:11 <tp> it's more fun deducing alone, but Ive been deducing all day and so far ... nada
20:36:19 <tp> no, Im designing as usual
20:36:52 <tp> i want to read a dbg register, and I can, problem is that it's all 0's
20:37:14 <tp> I know it had ID  data (from the specs)
20:38:33 <tp> I've phoned 'psychic friends' and they 'feel' that the register is unhappy talking to me directly and I must first please a register it knows
20:41:27 <rdrop-exit> Are you using a debugger to read the debug register via SWD?
20:42:30 <rdrop-exit> I know nothing about ARM but I would assume the CPU has to be in debug mode before you can access it.
20:42:54 <tp> do you ever get tired of being right ?
20:43:10 <tp> i can read the register in debug mode via SWD/JTAG
20:43:44 <tp> but I cant from within the MCU, however the doc is a bot ambiguous there
20:44:22 <tp> and I quote " The STM32F10xxx MCUs integrate an MCU ID code. This ID identifies the ST MCU part-
20:44:23 <tp>         number and the die revision. It is part of the DBG_MCU component and is mapped on the
20:44:23 <tp>         external PPB bus (see Section 31.16). This code is accessible using the JTAG debug port
20:44:23 <tp>         (four to five pins) or the SW debug port (two pins) or by the user software."
20:44:48 <tp> *or by the user software* is the ambiguous part
20:46:01 <rdrop-exit> In RISC-V there are a *few* debug registers that are also accessible in other CPU modes, but they are the exception.
20:48:17 <tp> is there a MCU ID code ?
20:48:37 --- join: gravicappa joined #forth
20:48:44 <rdrop-exit> yes
20:49:10 <rdrop-exit> It's a Machine Mode CSR
20:49:10 <tp> is it only accessable in dbug mode ?
20:49:15 <rdrop-exit> No
20:49:34 <tp> and that makes sense, why limit a device ID to debug mode only ?
20:49:42 <rdrop-exit> 0 shadow  RV32 - CSRs - M-Mode - Machine IDs & csr.misa
20:49:42 <rdrop-exit> 1
20:49:42 <rdrop-exit> 2 csr.mvendorid CSR# of 32-bit Machine Vendor ID CSR (R/O).
20:49:42 <rdrop-exit> 3
20:49:42 <rdrop-exit> 4   csr.marchid CSR# of MXLEN-bit Machine Architecture ID CSR (R/O).
20:49:44 <rdrop-exit> 5
20:49:46 <rdrop-exit> 6    csr.mimpid CSR# of MXLEN-bit Machine Implementation ID CSR (R/O).
20:49:49 <rdrop-exit> 7
20:49:51 <tp> there are valid reasons for a user program wanting to know it
20:49:51 <rdrop-exit> 8   csr.mhartid CSR# of MXLEN-bit Hart ID CSR (R/O).
20:49:54 <rdrop-exit> 9
20:49:56 <rdrop-exit> a      csr.misa CSR# of MXLEN-bit Machine ISA and extensions CSR
20:49:59 <rdrop-exit> b           (WARL).
20:50:11 <tp> yeah, makes sense
20:50:20 <rdrop-exit> That's my shadow block for it
20:50:48 <rdrop-exit> It's accessible in Machine Mode, but not in Supervisor Mode or User Mode
20:51:09 <rdrop-exit> (and in Debug Mode too of course)
20:51:27 <tp> i posted a question in a popular forum about it but also added "replies from those with actual experience on this exact matter appreciated"
20:51:34 <rdrop-exit> :))
20:52:05 <tp> trying to stop the usual idiots dumping sections of the manual as a reply
20:52:44 <rdrop-exit> I would assume on the ARM it would be similarly limited, is the program running in ARM's "machine mode" or whatever they call it?
20:53:02 <tp> ar`m doesnt have modes like that as afaik
20:53:08 <tp> rather cortex-m
20:53:35 <tp> I think it only has debug and normal mode
20:53:57 <tp> and I can read the registers in debug, no problem
20:54:25 <tp> but I want to be able to read them in user mode. they are listed in the CMSIS-SVD so should be available
20:54:41 <tp> and they are, but the contents are not (so far)
20:54:51 <rdrop-exit> that's also the case in small RISC-V, they only have D-Mode and M-Mode, while the bigger chips also have a S-Mode and U-Mode
20:55:27 <rdrop-exit> (for running OS's and VMs and such)
20:56:23 <rdrop-exit> Which Cortex-M in particular are you using
20:57:49 <tp> in this case STM32F103C8
20:58:03 <tp> which is a STM32F1xx class cortex-m3
20:58:47 <rdrop-exit> thanks, taking a look
20:59:13 <tp> I guess youre finding (as I am) that googling will produce millions of hits all the same providing a C user asks it ?
20:59:34 <rdrop-exit> I usually go to the specs
20:59:36 <tp> but outside the usual boring and obvous C user questions ... nothing
21:00:10 <tp> Ive grepped the device specs and thats the only info Ive come up with
21:00:32 <tp> the info is probably in another more specific ARM doc
21:00:43 <tp> .. maybe
21:00:51 <rdrop-exit> "The Cortex-M3 processor supports two operating modes, Thread and Handler and two levels of access for the code, privileged and unprivileged"
21:02:04 <rdrop-exit> Maybe this priveleged/unpriveleged stuff is the analagous ARM concept
21:02:32 --- quit: reepca (Read error: Connection reset by peer)
21:03:40 <tp> eww
21:04:03 <rdrop-exit> "Code can execute as privileged or unprivileged. Unprivileged execution limits or excludes access to some resources. Privileged execution has access to all resources. Handler mode is always privileged. Thread mode can be privileged or unprivileged."
21:04:12 <tp> Ive been conveniently ignorant using Forth on this chip
21:04:48 <rdrop-exit> Perhaps your Forth hides too many of the details
21:04:56 <tp> and perhaps I'm in 'unprivileged' is what youre thinking ?
21:05:02 <rdrop-exit> yes
21:05:33 <tp> I've had no problems until now
21:05:48 <rdrop-exit> The above quote is from section 3.2.3 of the 
21:06:00 <tp> usually a register that hides the data belongs to a peripheral that is not enabled 
21:06:04 <rdrop-exit> CortexTM-M3
21:06:05 <rdrop-exit> Revision r2p0 Technical Reference Manual
21:06:39 <tp> but debug sounds like the province of the privileged 
21:07:19 <tp> Ill do a grep on "privileged"
21:07:45 <rdrop-exit> I would assume the *few* debug registers that may be accessible to a program would be limited to the most privileged mode
21:07:59 <tp> yes, I think youre right
21:08:30 --- join: reepca joined #forth
21:08:46 <rdrop-exit> I'm jst shooting in the dark of course
21:08:51 <rdrop-exit> *just
21:10:55 <tp> it's all we have
21:11:21 <tp> "priv" is mentioned only 3 times in the entire tech manual and none refer to this issue
21:11:46 <tp> it does refer to deep debug stuff
21:11:51 <tp> as you expected
21:12:26 <tp>  there is nothing relating on how to read these registers from inside the mcu
21:12:42 <tp> I'm desperate now ... ill have to email Matthias!
21:12:58 <rdrop-exit> that may be covered in a separate Cortex-M3 debug spec
21:13:25 <rdrop-exit> At least that's how it is with RISC-V
21:14:08 <tp> I think youre right, but it's odd. generally if thats the case there is *nothing* in the stm tech data or the SVD
21:14:45 <tp> the fact that these two registers are in the SVD and mentioned in the STMN tech doc normally indicates it's within their province and not arm
21:15:54 <tp> still there is a ton of docs, bound to be some ommisions and crossovers
21:21:22 <rdrop-exit> A Machine ID register though, isn't normally a debug register, it should just require that you be in the most priveledged CPU mode right above degug mode, (what RISC-V calls Machine Mode)
21:21:54 <rdrop-exit> So you shouldn't have to delve into the debug specs for it
21:22:27 <tp> hell ..
21:22:39 <tp> I just quit out of debug mode and guess what ?
21:23:00 <tp> DBG_IDCODE. 
21:23:00 <tp> DBG_IDCODE  $20036410 
21:23:00 <tp> 3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
21:23:00 <tp> 1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0 
21:23:00 <tp> 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0 0 1 0 0 0 0 0 1 0 0 0 0
21:23:14 <rdrop-exit> voila
21:24:07 <tp> and after a hard reset ...
21:24:10 <tp> DBG_IDCODE. 
21:24:10 <tp> DBG_IDCODE  $00000000 
21:24:10 <tp> 3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
21:24:10 <tp> 1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0 
21:24:10 <tp> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
21:24:28 <tp> at least I know that something makes this possible
21:24:37 <tp> and it has to do with dbg mode
21:25:46 <rdrop-exit> Can you use your debugger to tell you if your Forth program is running in "privileged" mode?
21:26:34 <tp> the Forth program wasnt running as the program was halted before I rudely pulled the jtag plug
21:26:56 <tp> but thats a great idea
21:28:11 <tp> !
21:28:29 <tp> soon as I hook up the jtag and run openocd I can read the register from forth!
21:28:44 <tp> i just halted it before as SOP
21:30:57 <rdrop-exit> heh
21:31:09 <tp> so the truth is out there !
21:31:15 <tp> ... somewhere
21:31:47 <rdrop-exit> I'm happy I won't need openocd, doens't seem trustworthy
21:31:50 <tp> I guess I just need to read *every* register before I attach the jtag and grep it
21:32:24 <tp> and Im actually planning to make a binary to do just that for another reason anyway!
21:32:54 <tp> I mean difference it against a non jtag one
21:33:12 <tp> all my XML stuff is still paying off
21:33:22 <tp> check this out, try not to throw up
21:33:29 <rdrop-exit> ok
21:33:47 <tp> <?xml version='1.0' encoding='UTF-8'?>
21:33:47 <tp> <device xs:noNamespaceSchemaLocation='STM32F103_DIAGNOSTICS_V2.0.xsd'> 
21:33:47 <tp>  <markings>
21:33:47 <tp>    <STM32F103C6>0 </STM32F103C6>
21:33:47 <tp>    <STM32F103C8>0 </STM32F103C8>
21:33:48 <tp>    <STM32F103CB>0 </STM32F103CB>
21:33:50 <tp>    <CKS32F103C8T6>0 </CKS32F103C8T6>
21:33:52 <tp>    <GD32F103C8T6>0 </GD32F103C8T6>
21:33:56 <tp>    <other>0 </other>
21:33:58 <tp>  </markings>
21:34:00 <tp>  <flash>
21:34:02 <tp>    <size-register>$FFFF0040 </size-register>
21:34:04 <tp>    <calculated-size>65536 </calculated-size>
21:34:06 <tp>    <second-64kB-block>0 </second-64kB-block>
21:34:08 <tp>  <flash>
21:34:10 <tp>  <uid31:0>
21:34:12 <tp>    <hex>$066FFF53 </hex>
21:34:14 <tp>    <ascii>.o.S</ascii>
21:34:16 <tp>  </uid31:0>
21:34:18 <tp>  <uid63:32>
21:34:20 <tp>    <hex>$55507150 </hex>
21:34:22 <tp>    <ascii>UPqP</ascii>
21:34:26 <tp>  </uid63:32>
21:34:28 <tp>  <uid95:64>
21:34:30 <tp>    <hex>$87042957 </hex>
21:34:32 <tp>    <ascii>..)W</ascii>
21:34:34 <tp>  </uid95:64-hex>
21:34:36 <tp> </device>
21:34:38 <tp> thats straight out of the chip running my new Forth diags prog
21:35:07 <rdrop-exit> damn, where did I put that barf bag? ;-)
21:35:12 <tp> i decided to create a 'record' option which generates the XML
21:35:22 <tp> I did warn you ;-)
21:35:45 <rdrop-exit> tether tether tether
21:36:11 <rdrop-exit> (cough cough)
21:36:23 <rdrop-exit> :)
21:36:29 <rdrop-exit> better now
21:36:29 <tp> nah, Ive had 88 downloads of my V1 diags binary and it's all windows mainly arduino users
21:37:46 <rdrop-exit> cool
21:38:37 <rdrop-exit> I'm glad you convinced me to go RISC-V instead of ARM
21:42:28 <tp> it will be a freezing day in hell whan I manage to convince you of anything!
21:43:36 <tp> hey I've a suggestion song for your daughter, it might suit her style, but it could make her infamous and hated by the left for 1000 years tho ...
21:43:42 <rdrop-exit> You're insights were whatr put me over the edge :)
21:44:01 <rdrop-exit> ok
21:44:19 <tp> "garryowen" along with the flutes etc
21:44:42 <tp> she could do the original irish version to be a bit safer ?
21:45:00 <rdrop-exit> not familiar, will mention it to her when we next skype
21:45:43 <tp> this is the chorus in the Amer`ican version
21:45:46 <tp>  Our hearts so stout have got us fame
21:45:46 <tp> For soon t'is from whence we came;
21:45:46 <tp> Where'er we go they dread the name,
21:45:46 <tp> Of GarrOwen in Glory.
21:45:58 <tp> think Custer
21:46:10 <rdrop-exit> she recorded an original song which I quite liked, but she hasn't put it on youtube
21:46:31 <tp> one has to be very careful thesedays
21:47:08 <rdrop-exit> singing is just a hobby for her, her real job is acting
21:47:19 <tp> wow
21:47:26 <tp> well her` singing is awesome!
21:47:42 <rdrop-exit> thanks, I'll share that with her!
21:47:43 <tp> she makes Nancy S sound like a old tired fishwife
21:50:12 <rdrop-exit> she also dances pretty well, she won on the local TV dance contest, similar to dancing with the stars
21:50:46 <rdrop-exit> (that was like 10 years ago)
21:51:40 <rdrop-exit> I'll see if it's on youtube
21:51:59 <rdrop-exit> yup, low-res though
21:52:01 <rdrop-exit> https://youtu.be/0msBa3sSJqE
21:53:13 <tp> https://www.youtube.com/watch?v=4m7RPjQxjmA
21:53:20 <tp> thats the one I saw today
21:53:44 <rdrop-exit> I remember that movie
21:53:56 <tp> i never saw it
21:54:01 <tp> is that errol flynn ?
21:54:04 <rdrop-exit> yes
21:54:10 <tp> tasmanian
21:54:37 <rdrop-exit> cool
21:55:25 <tp> the irish version is much longer and not about war
21:55:30 <tp> and it's the original
21:56:16 <tp> but think what a stir that tune would be on utube sung by your daughter and advertised as 'GarryOwen' ?
21:56:28 <tp> then again utube might demonetise her :(
21:56:38 <rdrop-exit> heh
21:57:09 <tp> well I think the risc-v is a good way to go, it could be massive one day
21:57:31 <tp> right now the doc sucks and the current die has a few errors
21:57:38 <tp> but that can all be fixed
21:57:49 <tp> and I do have a Forth running nicely on it
21:58:39 <tp> here is one gd32vf103 issue, there is no single command to reset all the registers to defaults
21:58:47 <tp> unlike cortex-m
21:59:01 <tp> the doc claims there is, but it's wrong
21:59:54 <tp> and it's wrong because that part of the doc is a paste from the GD32F103 which is a cortex-m with cloned STM peripherals
22:00:40 <tp> so thats something to beware, it looks like the GD32VF103 manual started life as a GD32F103 manual with the differences edited
22:02:14 <rdrop-exit> that particular RISC-V implementation seems oriented to ARM developpers
22:03:04 <tp> i dont believe thats the reason it exists
22:03:33 <tp> the STM32F103 has been cloned in China
22:04:03 <tp> and millions of counterfeit STM32F103C8's now exist, but inside theyre a clone
22:06:12 <rdrop-exit> the ARM (counterfeit or real) ecosystem
22:06:44 <tp> thats the reason for my 'diagnostics' binary
22:07:01 <tp> it attempts to discover if the chip is real or cloned
22:07:30 <rdrop-exit> cool
22:08:20 <tp> well V1 did
22:08:31 <tp> V2 is mainly after the facts ... jack
22:09:03 <tp> and the XML output is for posterity, so anyone can analyse the user feedback
22:11:32 <rdrop-exit> FTDI's sample code sucks
22:12:03 <tp> you said
22:12:24 <tp> but it's a good choice
22:12:24 <rdrop-exit> But their MPSSE engine is cool
22:12:33 <tp> FTDI is probably the market leader ?
22:12:42 <rdrop-exit> yes
22:12:52 <rdrop-exit> (at least I think so)
22:12:53 <tp> ugly as they are
22:14:43 <rdrop-exit> I wish the internals were documented, I hate using 3rd party libraries
22:15:20 <rdrop-exit> the open source alternatives don't inspire confidence
22:15:29 <rdrop-exit> though
22:16:16 <tp> theyre all reverse engineered I guess ?
22:16:33 <tp> so how much confidence can you have ?
22:16:45 <rdrop-exit> right
22:18:03 <rdrop-exit> plus doing a deep dive into USB would give me ulcers
22:18:58 <tp> yeah, tho we do have a couple of working Forth examples
22:19:22 <tp> for a usb-serial bridge that is
22:19:36 <tp> it's not as bad as I thought but TONS of config
22:23:29 <rdrop-exit> Tons of options make my nose bleed, I like to pin things down
22:24:38 <tp> yeah, Ive been afraid of USB for years
22:29:00 <rdrop-exit> What I would like to eventually do is replace their library with my own code for going from the USB driver to their synchronous serial bridging thingie (MPSSE)
22:29:32 <tp> but youre doing more than that ? youre goung from usb to JTAG ?
22:29:57 <tp> ahh that is MPSSE ?
22:31:55 <rdrop-exit> MPSSE is a feature of their USB chip that receives commands and outputs synchronous serial signals.
22:34:33 <rdrop-exit> Dealing with JTAG requires configuring the MPSSE output pins and clock, then
22:34:59 <rdrop-exit> sending sequences through it to make the JTAG TAP controller on the other end dance to your tune.
22:35:10 <tp> i like it!
22:35:33 <tp> I may harass you for information later in the year if we are still alive
22:35:39 <rdrop-exit> :)
22:36:45 <tp> Im assuming your volcano has decided not to to eradicate all life in Philippines today ?
22:37:08 <rdrop-exit> although you still have to know what you need to send that JTAG TAP controller for it to in turn make stuff on the target board dance.
22:37:09 <tp> perhaps tomorrow ?
22:37:23 <tp> i do know a lot of that
22:37:50 <tp> it actually seems fairly straightforward
22:38:36 <tp> hahah, I'm about to make one of the longest Words I'll ever make
22:38:55 <rdrop-exit> at some level yes, but there's ton's of detail work
22:39:14 <tp> ever seen a Word 466 lines long ?
22:39:56 <tp> i'll bet there are some who think that's too long ?
22:39:59 <tp> hahahahah
22:40:00 <rdrop-exit> no, impossible
22:40:27 <tp> no it's not :)
22:40:36 <tp> I already have some far longer
22:40:39 <rdrop-exit> are you just comma-ing in 466 lines of data, this is not code right?
22:40:55 <tp> it's code all right
22:41:26 <rdrop-exit> like if you do CREATE STUFF 123 , 234 , ... and on and on... that's fine
22:42:12 <tp> i already have one Word 1541 lines long
22:42:20 <tp> here is a sample
22:42:20 <rdrop-exit> You mean a colon definition like : humonguous ( -- ) ... 466 lines ... ; ?
22:42:29 <tp> no
22:42:39 <tp> seperate short lines
22:43:13 <tp> oops. ok, Im weong
22:43:17 <tp> wrong even
22:43:26 <tp> it's a file length
22:44:06 <tp> inside the file are words that are like this
22:44:09 <tp> ( USB  -  Universal serial bus full-speed device  interface )
22:44:09 <tp> $40005C00 constant USB_EP0R ( endpoint 0 register ) 
22:44:09 <tp> $40005C04 constant USB_EP1R ( endpoint 1 register ) 
22:44:09 <tp> $40005C08 constant USB_EP2R ( endpoint 2 register ) 
22:44:09 <tp> $40005C0C constant USB_EP3R ( endpoint 3 register ) 
22:44:09 <tp> $40005C10 constant USB_EP4R ( endpoint 4 register ) 
22:44:11 <tp> $40005C14 constant USB_EP5R ( endpoint 5 register ) 
22:44:13 <tp> $40005C18 constant USB_EP6R ( endpoint 6 register ) 
22:44:15 <tp> $40005C1C constant USB_EP7R ( endpoint 7 register ) 
22:44:17 <tp> $40005C40 constant USB_CNTR ( control register ) 
22:44:19 <tp> $40005C44 constant USB_ISTR ( interrupt status register ) 
22:44:21 <tp> $40005C48 constant USB_FNR ( frame number register ) 
22:44:23 <tp> $40005C4C constant USB_DADDR ( device address ) 
22:44:27 <tp> $40005C50 constant USB_BTABLE ( Buffer table address ) 
22:44:29 <tp> : USB_EP0R. ." USB_EP0R (read-write) $" USB_EP0R @ hex. USB_EP0R 1b. ;
22:44:29 <rdrop-exit> that's fine
22:44:31 <tp> : USB_EP1R. ." USB_EP1R (read-write) $" USB_EP1R @ hex. USB_EP1R 1b. ;
22:44:33 <tp> : USB_EP2R. ." USB_EP2R (read-write) $" USB_EP2R @ hex. USB_EP2R 1b. ;
22:44:35 <tp> : USB_EP3R. ." USB_EP3R (read-write) $" USB_EP3R @ hex. USB_EP3R 1b. ;
22:44:37 <tp> : USB_EP4R. ." USB_EP4R (read-write) $" USB_EP4R @ hex. USB_EP4R 1b. ;
22:44:39 <tp> : USB_EP5R. ." USB_EP5R (read-write) $" USB_EP5R @ hex. USB_EP5R 1b. ;
22:44:41 <tp> : USB_EP6R. ." USB_EP6R (read-write) $" USB_EP6R @ hex. USB_EP6R 1b. ;
22:44:43 <tp> : USB_EP7R. ." USB_EP7R (read-write) $" USB_EP7R @ hex. USB_EP7R 1b. ;
22:44:45 <tp> : USB_CNTR. ." USB_CNTR (read-write) $" USB_CNTR @ hex. USB_CNTR 1b. ;
22:44:47 <tp> : USB_ISTR. ." USB_ISTR (read-write) $" USB_ISTR @ hex. USB_ISTR 1b. ;
22:44:49 <tp> : USB_FNR. ." USB_FNR (read-only) $" USB_FNR @ hex. USB_FNR 1b. ;
22:44:51 <tp> : USB_DADDR. ." USB_DADDR (read-write) $" USB_DADDR @ hex. USB_DADDR 1b. ;
22:44:53 <tp> : USB_BTABLE. ." USB_BTABLE (read-write) $" USB_BTABLE @ hex. USB_BTABLE 1b. ;
22:44:57 <tp> : USB.
22:44:59 <tp> USB_EP0R.
22:45:01 <tp> USB_EP1R.
22:45:03 <tp> USB_EP2R.
22:45:05 <tp> USB_EP3R.
22:45:07 <tp> USB_EP4R.
22:45:09 <tp> USB_EP5R.
22:45:11 <tp> USB_EP6R.
22:45:13 <tp> USB_EP7R.
22:45:15 <tp> USB_CNTR.
22:45:17 <tp> USB_ISTR.
22:45:19 <tp> USB_FNR.
22:45:21 <tp> USB_DADDR.
22:45:23 <tp> USB_BTABLE.
22:45:27 <tp> ;
22:45:29 <tp> about 33 Words like that for a STM32F103
22:45:33 <tp> but the new word needs to read and print 466 registers
22:46:00 <tp> and as it's autogenerated from a massive XML file, it will probably be 466 lines long
22:46:08 <tp> something like this 
22:46:18 <rdrop-exit> That doesn't seem like a good idea
22:46:32 <tp> $40005C00 @ hex.
22:46:41 <tp> but 466 of them
22:46:59 <tp> why ?
22:47:45 <rdrop-exit> when you get a combinitorial explosion of words, you shoud refactor to make words that work in phrases.
22:47:52 <rdrop-exit> * should
22:48:23 <tp> this is just a complete register contents dump
22:48:30 <tp> i dont see a easier way
22:48:48 <rdrop-exit> a dump should be a loop
22:49:24 <tp> the addresses arent a contiguous sequence, they come from a XML file
22:49:50 <tp> they jump around all over the place, and ONE wrong address will cause a exception
22:50:15 <tp> this is all about hardware, not coding style
22:50:50 <tp> thos it's nice to have efficient coding style
22:50:58 <tp> but it's also autogenerated
22:51:14 <tp> Ill ask the XML parser to please be efficient with the code ?
22:51:20 <tp> ;)
22:51:20 <rdrop-exit> well you're sourcing them from XML not hardware per se
22:52:42 <rdrop-exit> just a sec looking over what you posted
22:53:02 <tp> I'm sourcing the addresses from XML
22:53:11 <tp> and generating the Forth Words
22:53:21 <tp> with a XML parser
22:53:38 <rdrop-exit> Where does the XML originate?
22:54:04 <tp> from STM in this case, and it conforms to the ARM CMSIS-SVD XML format
22:54:51 <rdrop-exit> ah, ARM-specific stuff
22:54:55 <tp> https://mecrisp-stellaris-folkdoc.sourceforge.io/register-generator.html#svd2forth
22:54:58 <tp> yeah
22:55:17 <tp> tho I now have some Ti MCU XML files in the same format
22:55:59 <tp> it seems the RUST people love converting proprietary MCU definition files into CMSIS-SVD
22:56:04 <tp> files
22:56:29 <tp> I even have a CMSIS-SVD for the GD32VF103
22:56:41 <tp> compliments of the RUST folks
22:56:57 <tp> thats how Ive been able to have Words for every register
22:57:27 <rdrop-exit> Constants for every register is fine
22:57:56 <rdrop-exit> but a combinatorial explosion of colon definitions is not IMO
22:59:06 <tp> I think of it as a "flatulence of colon definitions" myself
23:00:01 <rdrop-exit> whenever I'm tempted to do a combinatorial explosion of colon definitions, I try to see if I can make words that work in phrases instead.
23:00:29 <rdrop-exit> IIRC Thinking Forth covers this
23:01:00 <rdrop-exit> In fact this is why CREATE and VARIABLE words are now non-standard
23:01:42 <tp> I could break it up into register groups, thats the finest grain I can do wordwise
23:03:16 <rdrop-exit> As long as there aren't many exceptions to the regularity, a combinatorial explosion can usually be reduced to words that work in phrases
23:04:14 <tp> there will be a lot of exceptions, remember the addresses come from a xml file
23:04:39 <tp> the cool thing here is I can try the simple way and see what happens
23:04:58 <tp> all I want is a file of all the register contents in a MCU
23:05:30 <rdrop-exit> also a combinatorial explosion of words takes up much more dictiory space than the phrasal approach
23:06:05 <tp> all 466 of them
23:06:17 <tp> as long as it fits in 128Kb I'm good
23:06:40 <rdrop-exit> doesn't impact me as much since I keep headers on the PC side of a tether, but if you're doing resident Forth it will impact you more
23:06:48 <tp> if it doesnt then I'll have to look at other choices, but I already know it will easily fit
23:07:22 <rdrop-exit> it can also slow down your dictionary lookup
23:07:52 <tp> I then write a script so the progran works with gnu screen and is saved into a correctly titled log with any extraneous crap removed
23:08:12 <tp> the only porpose it to get a register dump
23:08:31 <tp> I'm not going to need any thing else from it
23:09:17 <tp> then I post it on my website and others with counterfeit chips use it to produce dumps which they then email to me
23:09:51 <tp> i then run diffs against my genuine chip :)
23:10:27 <tp> plus I also use it for my most recent problem, what did enabling the DBG do to my chip ?
23:10:38 <tp> see if I can find it that way
23:11:01 <tp> detective tp is on the job!
23:11:23 <rdrop-exit> elementary my dear watson
23:11:50 <tp> as long as I get my dump, which I know I will, job done!
23:12:39 <tp> the public binary release will also have the working USB driver installed 
23:13:02 <rdrop-exit> right if it's just throw away then it doesn't really matter if it's well factored or not
23:13:03 <tp> so the good arduino folks can use their PC to easily get the data
23:13:07 <tp> yeah
23:13:13 <tp> it's very limited use
23:13:30 <tp> but it will be neat, Im very anti ugly Forth code!
23:13:43 <rdrop-exit> a great public service, helping arduino users take dumps
23:13:57 <tp> the good arduino folks wont even know it's forth, they just see a menu
23:13:59 <tp> hahaha
23:14:04 <rdrop-exit> ;)
23:14:08 <tp> it's a shitty job but someone has to do it
23:15:18 <rdrop-exit> I use awk for all my thro-away text processing needs
23:16:26 <tp> in this case it would be the right tool for the wrong job :)
23:16:48 <rdrop-exit> If I had to deal with XML, I would flatten it out then feed it to an awk script
23:17:11 <tp> the data is xml, a xml parser creates a Forth word(s) including the data which is then run on the MCU
23:17:35 <tp> well, youre a programmer, I'm not worthy to do that kind of thing
23:18:05 <rdrop-exit> what do those generated Forth words output?
23:18:21 <rdrop-exit> I mean what format do they output?
23:18:39 <tp> but honestly, flattening out XML and then hydrating it with AWK could get you banned from programming ever again
23:18:55 <tp> they output the contents of every register in the MCU
23:19:02 <rdrop-exit> as what?
23:19:07 <rdrop-exit> XML again?
23:19:36 <tp> yeah, probably
23:19:45 <tp> but maybe not
23:19:46 <rdrop-exit> probably?
23:19:49 <rdrop-exit> ah
23:20:04 <tp> I only need the register address and the data on each ine
23:20:06 <tp> line
23:20:16 <tp> then I can simply difference the files
23:20:21 <rdrop-exit> much better
23:20:25 <tp> to find changes
23:20:50 <tp> only one data item, so xml would be wasted I think
23:21:52 <tp> probably "register-address,hex. cr " per line of output
23:22:00 <rdrop-exit> XML on the input side is being imposed upon you by the vendors, but there's no need to impose it again on yourself downstream
23:22:39 <tp> I'm a XML fan, it's no imposition for me
23:23:06 <tp> take my V2 diags output, thats XML because there are a number of items
23:23:49 <tp> and it's that way so I can easily build a XML to sqlite or postgress DB parser
23:24:03 <tp> or maybe comma delimited for a spreadsheet
23:25:15 <rdrop-exit> Hey whatever turns you on. Personnaly the first thing I'd do with a XML file is un-XML-ize it somehow.
23:25:41 <tp> haha, XML is universally hated, but not by me
23:25:49 <tp> I learnt to love XML
23:26:24 <tp> I guess I'm immune from programming language hate as Im not a programmer :) 
23:26:32 --- join: dave0 joined #forth
23:26:44 --- join: X-Scale` joined #forth
23:27:12 <rdrop-exit> Hey who am I to question your fetishes
23:27:37 --- quit: X-Scale (Ping timeout: 240 seconds)
23:27:38 --- nick: X-Scale` -> X-Scale
23:27:43 <tp> when I first announced I was designing my SVD2FORTH program vomit rained down on me from the lofty heights of my programmer friends
23:27:47 <tp> lol
23:28:00 <tp> they universally loathed XML
23:28:43 <tp> but I was too dumb to know I shouldnt use it, and eventually I fell in love with XML and we eloped to Vegas and got married
23:29:05 <rdrop-exit> and there was much rejoycing
23:29:32 <tp> no, everyone who saw the bride threw up, bikies threatened to beat me up, my mum slapped me
23:29:56 <rdrop-exit> no more Mr. nice guy
23:30:10 <rdrop-exit> no more Mr. clean
23:30:38 <tp> no Im still a nice guy, but Mrs XML and I dont go outside a lot
23:31:34 <tp> then to add insult to injury I got my self a Forth mistress!
23:31:49 <tp> now I was *really* unpopular
23:32:12 <tp> XML and Forth got along famously
23:34:20 <rdrop-exit> it takes all kinds
23:35:23 <tp> it do
23:35:44 <tp> i mean there is some real perversion going on out there
23:36:10 <rdrop-exit> lucky for you nobody reads this IRC's log
23:36:14 <tp> take Linux, C and VisualStudio from microsoft, disgusting!
23:36:52 <tp> yeah, only 42 Forth users in the world might read this
23:37:32 <tp> if this was a Arduino IRC channel there would be 7000 regular members and 100,000 lurkers
23:37:53 <rdrop-exit> wow, really?
23:37:59 <tp> probably
23:38:14 <rdrop-exit> I'll just hide here, thanks
23:38:15 <tp> if Arduino users used IRC
23:38:28 <tp> but they dont, it's all forums for them
23:38:40 <tp> millions of them
23:38:52 <tp> (arduinoistas)
23:39:28 <rdrop-exit> 8-O
23:40:34 <tp> watching a Arduino ATMEL Mega8 user trying to use Arduino on a STM32F is like watching a 4 year old child wander onto a 12 lane superhighway
23:40:47 <tp> very messy
23:47:11 <rdrop-exit> bbiab
23:47:56 <tp> no problemo
23:59:59 --- log: ended forth/20.02.01