00:00:00 --- log: started forth/20.05.04 00:09:21 --- join: mtsd_ joined #forth 00:10:54 --- quit: mtsd (Ping timeout: 256 seconds) 00:23:29 --- join: mtsd joined #forth 00:25:20 --- quit: mtsd_ (Ping timeout: 260 seconds) 00:27:31 --- quit: mtsd (Client Quit) 00:34:20 --- join: xek joined #forth 00:58:01 tp: I prefer your HPRE comment 00:58:50 Because you actually document it's 0xxx, not just "0000", although I get what they're trying to do 01:01:04 This is similar to how I have defined registers, but I prefer separating 'RNAME_MASK' and 'RNAME' to be the unshifted mask and shifted mask 01:04:00 Your forth is actually similar to how some people I know write C 01:04:46 I don't use structs for direct memory maps of registers myself, only for other stuff 01:05:54 veltas, for some reason structs seem to be very popular in C when dealing with peripheral register bitfields 01:08:09 Structure for the sake of structure maybe 01:08:48 veltas, my naming strategy is that of the cmsis-svd nomenclature, I didnt choose it. My aim was so that readers can go straight from the source to a tech document by searching on the name 01:09:27 Yes that's the way I go too 01:09:35 I don't rename what's in the spec 01:09:43 veltas, the peripheral_register_bitfield strategy is one area that is often a source of misunderstanding 01:10:29 And then they go ahead and have separate macros with a consistent naming scheme to refer to the bitfields, distinct from how the struct works, and I wonder why they bothered with how the struct worked in the first place 01:10:44 many programmers choose to use just "bitfield" as the full name can be unwieldy, but sadly 'bitfield' names are not unique 01:11:24 even register_bitfield names are not unique 01:11:57 so in the end I had to use peripheral_register_bitfield names to avoid names clashing 01:12:52 veltas, what do you think about Keil needing to create every possible bitfield #define with this strategy ? 01:13:42 Well it's not something I have a strong opinion on, I think that I would do this at work, but only for bitfields I was using 01:13:49 But I might factor it a bit more 01:15:22 perhaps as it's a commercial product they feel that they need to value add on top of what CMSIS-SVD offers for free ? 01:15:35 --- join: reepca` joined #forth 01:15:51 --- quit: reepca (Read error: Connection reset by peer) 01:16:54 If they were predefined and available we use them, often I write code where there isn't such a thing because it's typically implemented per-OS in different drivers 01:17:04 I personally think it's a waste of time as 1) they cant account for complex interactions, 2) any engineer doesnt need it 01:17:39 i.e. because I am working outside an OS I have to write a lot of stuff not usually needed 01:18:05 veltas, I think youd need a book of API's and have to learn them to even use those #defines ? 01:18:54 We read specs and #define as and when needed 01:19:12 veltas, you must be using assembly or C I guess ? 01:20:25 veltas, as a Forth user, I don't have and don't need #defines, I don't think I'd want them either 01:20:31 C (assembly typically reserved for initial code to get a C environment ready and where lots of special instructions are needed) 01:20:57 they have to be processed outside of C so thats another level of abstraction ? 01:21:33 Well your words are a little like smart defines, as far as I see. Or maybe they're more like proper C 'bitfields' (the ones with : in a struct member) except properly defined 01:21:47 I like your code over the C there 01:22:28 veltas, I think I write code much as any hardware guy would do, I try to keep it simple but being able to always trace code to hardware is one of my aims 01:23:13 veltas, hmm I like your term 'smar`t defines'! 01:23:18 lol 01:23:20 good 01:23:39 minus the ` of course (worn out keyboard) 01:24:27 You could do almost exactly what you did in C++. But you'd be using a *massive* language requiring far more training so it should never be understated how rich forth is 01:24:33 this has all evolved for me, my initial 2016 efforts were prehistoric in comparison 01:26:21 If you have a specific ABI and compiler then you could use traditional 'bitfields' in C to do what you have, but people avoid them because they're so badly defined in the standard 01:27:13 yes, Ive noticed that bitfields are a source of problems and confusion with hobby embedded C users 01:28:49 Back to writing C and not forth :( 01:28:54 --- quit: WilhelmV1nWeiner (Quit: leaving) 01:28:56 veltas, no I know at least one person has understood my document and can see how I use Forth in embedded and why I have chosen the methods used 01:29:04 no = now 01:29:10 --- join: WilhelmVonWeiner joined #forth 01:29:21 C is a great source of confusion with many people who think it's a "really simple obvious language" and it turns out it has skeletons 01:29:31 veltas, ah yes monday mor`ning for you 01:29:36 Hmmm :( 01:29:43 it's super, super simple 01:29:48 until it's not 01:29:54 --- join: mtsd joined #forth 01:30:14 veltas, heheh, it looks far from simple when I examine those #defines 01:30:44 WilhelmVonWeiner, heh 01:32:11 --- join: merkc0 joined #forth 01:33:54 Structure for the sake of structure maybe ?? I'm not so sure. It seems that C programmers prefer to deal with CELL's, they like to pack up all the bitfields into a CELL rather than deal with the bitfields on their own ? 01:35:55 You often need to make sure the right accesses are being generated by the compiler, if they're defined as 32/64-bit integers in a struct you can be sure changes will generate the correct sized store/move 01:36:12 In Forth the access size is very explicit everywhere so it's not 'hidden' in something like that 01:36:29 In C it tries to hide it... and then every embedded C programmer has to turf it up somehow 01:38:04 veltas, ahh, Ive never thought of it that way 01:41:03 veltas, Ive wondered about this for years! thanks :) 02:41:10 how to define >LINK ? (just need an example from any impl ) https://bernd-paysan.de/screenful.html 02:44:10 merkc0: It depends on implementation, on mine you would need to literally walk through the dictionary headers to find the one that matched (as it is headless). It depends on layout of headers 03:22:03 --- quit: dys (Ping timeout: 272 seconds) 03:57:53 --- join: karswell_ joined #forth 04:05:30 --- join: TCZ joined #forth 04:07:42 --- join: dddddd joined #forth 04:15:19 --- join: dys joined #forth 04:18:48 --- join: rdrop-exit joined #forth 04:19:28 c[] hello Forthians 04:20:32 Hello 04:20:38 :) 04:20:50 hi mtsd 04:21:07 Everything alright? 04:21:48 all good, yourself? 04:22:21 Yes, good here too 04:22:30 clear 04:22:39 Sorry. Wrong window :) 04:22:46 np 04:32:06 dinner's ready, catch you later, stay healthy 04:32:10 --- quit: rdrop-exit (Quit: Lost terminal) 04:32:27 Are there forths that use a hash instead of storing the word? 04:33:12 Like, very old forth would store 3-4 letters and a count, and the 'count' in this case is a bit like a hash (but not a very good one) and that would actually suffice for most longer words because they happen to be different lengths 04:33:31 But you could keep the name field a fixed size by storing a hash (and maybe an initial fixed number of chars) 04:33:57 And that would actually work in many more cases than storing count + fixed length string 05:05:51 --- nick: karswell_ -> karswell 05:46:52 --- join: Zarutian_HTC| joined #forth 05:47:17 --- quit: Zarutian_HTC (Ping timeout: 256 seconds) 05:48:06 --- join: Zarutian_HTC joined #forth 05:48:07 --- quit: Zarutian_HTC| (Read error: Connection reset by peer) 06:04:42 --- quit: mtsd (Quit: mtsd) 06:13:10 --- quit: TCZ (Quit: Leaving) 06:30:09 --- quit: jsoft (Ping timeout: 272 seconds) 06:30:09 --- join: mtsd joined #forth 06:33:02 --- quit: mtsd (Quit: Leaving) 06:34:41 --- join: jsoft joined #forth 06:41:05 --- join: mark4 joined #forth 06:49:47 --- quit: Zarutian_HTC (Ping timeout: 258 seconds) 06:52:57 veltas: I have done that in the past in some of my forths 06:54:36 crc: Any pros/cons? 06:54:42 --- quit: mark4 (Remote host closed the connection) 06:59:23 not really. the lookups can be faster, since calculating a hash is generally faster than comparing strings byte by byte 07:00:16 Does it save much space or not really? 07:00:23 I guess it depends on your average word size 07:00:31 word name size I mean 07:04:21 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 07:31:27 I keep the full name around anyway, so not really for me. It'd save space if discarding the full names 07:32:45 on a unix host, my system uses 5,990 locations for names. This could be reduce to 497 if I discarded the full names. 07:34:01 --- quit: karswell (Remote host closed the connection) 07:34:06 a retro/embedded would likely not keep headers on the target, and if it did, would probably just store a hashed version to save space 07:34:20 --- join: karswell_ joined #forth 07:34:39 (fwiw, my average word names are 8 characters, with the longest being 23) 07:54:32 --- join: Zarutian_HTC joined #forth 08:12:24 --- quit: dys (Ping timeout: 246 seconds) 08:32:47 --- part: naraic_ left #forth 08:44:45 --- join: TCZ joined #forth 08:46:27 --- join: mark4 joined #forth 08:47:29 --- quit: xek (Ping timeout: 256 seconds) 09:24:00 crc: Are your names stored with a whole cell per character in the name? 09:24:04 Or is it optimised? 09:24:14 Because I seem to remember you have big characters in retro 09:24:54 why would you store a whole char in a cell? 09:30:59 Just makes the language more consistent and simpler I'm assuming 09:31:27 And adds possibility of easy UTF-32 support, easier than you'd get elsewhere, although not sure if that's supported 09:32:40 Would make the machine code shorter as well I think ??? Can't remember but I have it in my head byte operations produce longer instructions on x86, should check though really 09:39:16 --- quit: TCZ (Quit: Leaving) 09:47:46 --- quit: gravicappa (Ping timeout: 256 seconds) 09:48:38 --- join: gravicappa joined #forth 10:23:20 aha 10:23:33 i did not even know there was such a thing as utf-32 lol 10:33:27 a bit overkill considering there aren't even symbols for some things in utf16 10:35:55 veltas: yes, one cell per character 10:36:27 mark4: my current misc emulation has only word-level addressing 10:37:02 aha 10:40:37 so either 32-bit or 64-bit word sizes, depending on how the system is built 10:52:14 --- quit: Lord_Nightmare (Quit: ZNC - http://znc.in) 10:55:08 --- join: Lord_Nightmare joined #forth 11:23:49 --- quit: yunfan (Ping timeout: 240 seconds) 11:28:32 --- quit: rprimus (Quit: leaving) 11:43:07 --- quit: reepca` (Read error: Connection reset by peer) 11:45:10 --- join: reepca` joined #forth 11:45:34 --- join: WickedShell joined #forth 11:50:02 --- join: yunfan joined #forth 11:58:20 --- quit: merkc0 (Ping timeout: 260 seconds) 12:11:27 --- quit: jsoft (Ping timeout: 246 seconds) 12:34:09 --- join: xek joined #forth 12:40:41 --- quit: karswell_ (Read error: Connection reset by peer) 13:31:18 --- join: TCZ joined #forth 14:00:34 --- quit: koisoke (Ping timeout: 265 seconds) 14:01:29 --- join: dave0 joined #forth 14:09:34 --- quit: xek (Ping timeout: 256 seconds) 14:18:11 --- quit: gravicappa (Ping timeout: 272 seconds) 14:28:44 --- join: deesix_ joined #forth 14:29:03 --- join: dddddd_ joined #forth 14:31:27 --- quit: deesix (Ping timeout: 246 seconds) 14:31:42 --- quit: dddddd (Ping timeout: 258 seconds) 14:44:12 --- join: koisoke joined #forth 16:00:24 --- quit: TCZ (Quit: Leaving) 18:16:01 --- join: boru` joined #forth 18:16:01 --- quit: boru (Disconnected by services) 18:16:05 --- nick: boru` -> boru 18:30:55 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 18:31:13 --- join: Zarutian_HTC joined #forth 18:36:43 --- join: rdrop-exit joined #forth 18:38:01 good morning Forthwatchers c[] 18:39:56 --- join: iyzsong joined #forth 18:40:49 --- join: cox_ joined #forth 18:41:29 --- quit: mark4 (Remote host closed the connection) 18:46:29 --- quit: cox_ (Remote host closed the connection) 18:46:47 --- join: cox_ joined #forth 18:56:56 --- quit: cox_ (Remote host closed the connection) 18:58:26 --- join: cox_ joined #forth 18:58:56 --- quit: cox_ (Read error: Connection reset by peer) 19:06:21 --- quit: dave0 (Quit: dave's not here) 19:23:25 --- quit: dddddd_ (Ping timeout: 260 seconds) 20:00:21 tp, just took a look at your Forth vs C example 20:00:57 %0000 RCC_CFGR_HPRE bis! \ AHB prescaler: 0xxx: SYSCLK not divided 20:01:20 this line won't actually do anything 20:02:22 unless there's something I'm not groking about your "bis!" word 20:07:21 I'm assuming your BIS! is equivalent to my SET ( mask a -- ) and not a masked store %32! ( x mask a -- ) 20:08:30 Maybe I just haven't had enough c[] yet 20:16:37 rdrop-exit, youre 100% correct, it is utterly redundant! 20:17:19 ok, thanks 20:20:15 that one slipped thru somehow and it's something I do now and again due to brain not fully turned on 20:20:58 If I've understood correctly, your various BIS! lines will only work as intended if you're sure the reset state for those bitfields is all-zeroes, any bitfields that have non-zero presets won't behave 20:21:09 it's innocuous usually, and in this case utterly ineffective anyway 20:22:08 it comes from me reading the datasheet and just configuring the desired value, then using the default "bis!" 20:22:13 that is if my assumption about what your BIS! does is correct 20:22:28 it is 20:22:40 ok, thanks 20:22:51 for the clarification 20:23:34 a more accurate but also un-needed config would be "%1111 RCC_CFGR_HPRE bic! \ AHB prescaler: 0xxx: SYSCLK not divided 20:24:07 as the reset default is RCC_CFGR_HPRE = %0000 anyway 20:24:16 --- quit: proteus-guy (Ping timeout: 240 seconds) 20:24:46 this is an area I'm still working on and tried a few different strategies in the past 20:25:46 rdrop-exit, but I'm trying hard not to invent really complex 'solutions' and that's all Ive come up with so far 20:25:57 --- join: Lord_Nightmare2 joined #forth 20:26:31 I've learnt enough by now to realise a complex solution means I dont understand the problem 20:27:03 --- quit: Lord_Nightmare (Ping timeout: 258 seconds) 20:27:06 'a problem, dimly glimpsed" ... 20:27:07 --- nick: Lord_Nightmare2 -> Lord_Nightmare 20:27:11 :)) 20:27:59 "every complex solution paves the way to understanding the simple solution at the end of the path" 20:30:19 I guess that's another lesson that Forth teaches, that all solutions no matter how wrong *need to be tried* before they can be eliminated from blocking the clear view of the solution ? 20:32:30 as opposed to C (and similar) where one spends time analysing the problem and writing code before actually trying it 20:33:43 here is a anecdote of my work. I spent about a year designing a special jig for partial termination of a specific and widely used connector 20:34:18 I often think I understand something by reading or thinking about it, but I only grok it at the gut level through experimentation 20:34:23 it took that long for my mind to visualise something out of nothing as no such jig exists anywhere 20:34:33 rdrop-exit, 100% agree 20:35:33 so afetr 12 months I finally decided it was time to make the jig, which is fairly involved as it required very accurate hand milling of the metal parts 20:35:54 and lo and behold, my initial idea was a complete fail ... 20:36:02 --- join: jsoft joined #forth 20:36:52 but from that prototype, my second attempt, applying the facts learned from the first was a total success 20:36:54 tp: what was this connector? 20:37:06 Zarutian_HTC, sorry, commercial secret 20:37:45 --- join: proteus-guy joined #forth 20:37:55 some milspec multi feed monstrosity I expect 20:37:58 all I can say was that my jig reduced the time substantially, while also reducing failures to 0% 20:38:16 tp works for Q Branch 20:38:27 hahah, it's a commercial project 20:39:01 is my Aston Martin ready yet? 20:39:08 and because it saves so much time, I can't let anyone know what it is or my competitors would just copy it 20:39:18 oops wrong channel 20:39:22 lol 20:39:54 i relate the story only because it's so similar to the way Forth works in embedded 20:40:14 and no, milspec does not mean military specification as too many peeps belieave. It is basically a connector or some such specified in mils, which is better known as thous or thousands of an inch 20:41:10 it's also a bit like Elon Musks development method "dont spent too much time analysing a new thing to death, build it asap and when it explodes, find out why and iterate" 20:41:41 Zarutian_HTC, hahahah, depends on the country 20:41:59 https://en.wikipedia.org/wiki/United_States_Military_Standard 20:42:32 the build fast and test way is so much faster than analyse to death and take forever to test 20:42:42 or icelandic 'hillbilly' engineering. Rig something up, test it, find out why it failed and rig a better one 20:43:10 I believe that's the fastest and best way 20:43:19 and Forth is like that in embedded 20:44:11 I can have motor coil energised in minutes instead of hours, and my code can be totally throw away 20:44:39 tp: no, it doesnt depend on the country. The milspec confusion arouse from a confused clerk thinking it stands for Military Specification. 20:45:42 MIL-SPEC 20:45:43 Defense Specification 20:45:51 A document that describes the essential technical requirements for military-unique materiel or substantially modified commercial items. MIL-STD-961 covers the content and format for defense specifications. 20:46:19 at least that's what the US thinks of as MIL-SPEC 20:46:37 regardless of the origins 20:47:48 rdrop-exit: MIL-SPEC is a non existant thing. I have asked, personally, an military tech that was stationed here at Keflavík about it and told me it is an clerkical mirrage 20:48:54 Zarutian_HTC, i wonder if he was 'pulling your leg' ? 20:49:14 technicians can be bastards ... 20:49:27 rdrop-exit: many many documents and such only refer to MIL-STD 20:50:33 --- quit: proteus-guy (Ping timeout: 260 seconds) 20:50:52 I once told a very annoying director who was standing over me worried about a breakdown and who kept asking 'whats wrong with it' .... "the phase locked dipthon retarder is broken" 20:51:28 tp: the story goes that a civilian clerk at a military base that handled logistical forms and such over heard two machinists talk 20:51:37 it's common Star Trek technobabble and I though he would have a laugh and go away 20:52:11 instead I was mortified to hear his reply "oh is that serious?" 20:53:10 the guy had no idea what was going on, and that was the last time I allowed anyone to bother me during a important breakdown that I was trying to fix 20:53:15 tp: one of the machinist asked the other about how he got a part up to milspec and the confusion was born in the mind of the clerk 20:54:58 Zarutian_HTC, I see a few scenarios there 20:55:08 and I asked the guy not at his work but at a crowded cafe here in town that we both happened to be at 20:56:45 Zarutian_HTC, I know that mill-spec here in Australia apllies to specs required for military use, for instance the mill-spec temperature range is wider than the commercial one ... 20:57:12 Zarutian_HTC, it has noting to do with millimeters :) 20:57:18 so, what was the cause of the breakdown in that story? 20:57:53 i was in my mid 20's I only remember it because the director had no idea what I said 20:58:30 Zarutian_HTC, diring my life I have repaired, designed and built so much gear, I can only remember the really notable ones 20:59:24 Zarutian_HTC, I had a guy once aske me for a quote to repair something, and when I asked him what it was he was a bit shocked and replied 'you made it for me' 20:59:26 yeah, this mils and millimeter confusion is why mils has been replaced with thou 21:00:07 right, you told me before 21:00:19 Zarutian_HTC, both terms are in use for pcb making afaik, I use then all the time 21:00:33 to me mils=thou 21:01:08 but 'mill-spec' cant be confused with 'mills' to me, perhaps it the language ? 21:02:24 mils are thou but the former has been banished from being used at the electronics tech school, many milling and such workplaces and quite a few design shops 21:03:07 Zarutian_HTC, and fair enough, probably not in America tho ? 21:03:14 --- join: proteus-guy joined #forth 21:03:48 if your country is all METRIC it makes sense until you have to work with a american blueprint in "mils' ? 21:03:50 milspec, only one L and the coiner thought it cute to reuse the s 21:04:08 oops 21:04:26 Zarutian_HTC, you with the Internet spelling police now ? 21:04:58 ;-) 21:05:14 yeb metric but only the pitches of component footprints are in thous 21:06:27 Zarutian_HTC, and thats because the USA uses 'imperial' and they wrote all the semiconductor specs when they invented them 21:06:46 traces from pads, thickness of pcbs all in millimeters or microns if you hate your pcb house 21:07:05 if Iceland had invented transistors they could be measured in 'miliaxehandles' 21:08:18 oh, yes 'imperial' is right. Specially when American, British and Spanish imperial units are not quite the same 21:08:49 Zarutian_HTC, I havent used a pcb house since the 90's, tho the Chinese ones seem very cheap, but with the prospect of war on the horizon, that may cease abruptly ? 21:09:17 tp: nope, the lead pitch and such would be measured in piddlins 21:09:35 Zarutian_HTC, well they invented them very early on, and standards take a while to settle down ? 21:09:45 heheh, 'piddlins' ? 21:10:10 and pons 21:10:14 aha 21:11:35 * tp waits for his 1.5 cubic feet of food shopping to be delivered ... 21:11:43 I have used pcbs manifactured by Chinese, German, Netherland, and Icelandic pcb houses 21:12:42 Ive only used PCB's by australian fabs 21:12:50 the last one is just a side biz of an milling, lathe, and electro plating place 21:13:05 back in the 90's there was no china we were aware of 21:13:51 chinas meteoric rise was unexpected, and I suspect it's fall will be as fast 21:14:07 in a post covid-19 world 21:14:27 crude as hell but I didnt have access to ferrocloride etching at the time and this was needed for a repair yesterday at the time 21:15:41 I expect to see manifacturing of many things move yet again 21:16:28 me too 21:16:45 I have 4 litres of Ferric chloride here atm 21:17:04 for instance, visay an indian firm in origin make excelent passives in both throughhole and surfacemount 21:17:10 they sure do 21:17:38 india is a rising star for sure 21:18:00 they also make 'heat absorbing' SMTs 21:18:02 it replaced a tawanese firm that been the leader for many years 21:18:32 i expect we will also see the reascendence of Tiawan now 21:18:42 they were big once 21:20:13 the thing is, if it was economically viable and not too ackward then many manifacturer would prefer to have their plants on or be ships 21:22:23 because there is one thing that logisticans and top management hate is pointless geopolitical interference 21:23:05 that is, logisticans and top at manifactures 21:33:26 exactly 21:39:40 --- join: merkc0 joined #forth 22:01:44 --- quit: rdrop-exit (Quit: Lost terminal) 22:07:13 --- join: rdrop-exit joined #forth 22:12:49 veltas, quite a few Forths use hashing threads/chains, especially desktop ones with tons of words. Mostly for speeding up dictionary lookup, especially during compilation. 22:17:09 It may be less common with today's fast PCs, but it was quite common before. 22:19:21 It comes with some extra complication when appending to the dictionary, and especially when truncating the dictionary, e.g. FORGET. 22:20:40 too many "especially" :) 22:22:51 lunch is ready, catch you all later, stay healthy! 22:22:57 --- quit: rdrop-exit (Quit: Lost terminal) 22:33:11 --- join: gravicappa joined #forth 23:07:42 --- quit: merkc0 (Ping timeout: 246 seconds) 23:14:38 --- join: merkc0 joined #forth 23:30:50 --- join: mtsd joined #forth 23:37:45 --- quit: mtsd (Quit: Leaving) 23:40:09 --- join: mtsd joined #forth 23:59:59 --- log: ended forth/20.05.04