00:00:00 --- log: started forth/20.05.07 00:05:21 --- join: merkc1 joined #forth 00:19:08 --- quit: WickedShell (Remote host closed the connection) 00:29:38 crest, https://mecrisp-stellaris-folkdoc.sourceforge.io/patches.html#stm32f103-patch 00:34:10 --- quit: mtsd (Ping timeout: 272 seconds) 00:43:53 --- quit: merkc1 (Quit: Leaving) 00:56:49 --- quit: jimt[m] (*.net *.split) 00:56:49 --- quit: guan (*.net *.split) 01:01:46 --- join: jimt[m] joined #forth 01:01:47 --- join: guan joined #forth 01:05:31 --- join: xek joined #forth 01:12:58 --- quit: reepca (Remote host closed the connection) 01:13:10 --- join: reepca joined #forth 02:14:07 --- join: mtsd joined #forth 02:40:11 --- quit: jimt[m] (Quit: killed) 02:40:31 --- quit: siraben (Quit: killed) 02:45:36 whoo hoo XSLT is awesome! 02:49:28 XSLT? 02:54:45 --- join: siraben joined #forth 03:03:00 --- quit: cheater (Ping timeout: 272 seconds) 03:07:26 --- join: jimt[m] joined #forth 03:20:46 --- join: TCZ joined #forth 03:44:10 --- join: iyzsong joined #forth 03:49:45 --- quit: mtsd (Quit: Leaving) 03:53:32 --- join: mtsd joined #forth 03:54:25 --- quit: boru (Read error: Connection reset by peer) 03:59:42 --- join: boru joined #forth 04:29:13 --- join: jsoft joined #forth 05:07:44 --- quit: crab1 (Remote host closed the connection) 05:13:59 --- quit: iyzsong (Ping timeout: 260 seconds) 05:49:58 --- quit: mtsd (Remote host closed the connection) 06:26:11 --- join: dddddd joined #forth 06:44:39 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 07:07:44 --- quit: TCZ (Quit: Leaving) 07:27:37 --- join: Zarutian_HTC joined #forth 07:36:04 --- join: antaoiseach joined #forth 07:39:19 hi all 08:04:57 --- part: antaoiseach left #forth 08:10:49 --- quit: reepca (Read error: Connection reset by peer) 08:11:18 --- join: reepca joined #forth 08:48:07 --- join: TCZ joined #forth 09:37:05 --- quit: reepca (Ping timeout: 258 seconds) 09:45:19 --- join: cheater joined #forth 09:54:22 --- join: reepca joined #forth 10:13:52 --- quit: TCZ (Quit: Leaving) 10:39:36 --- join: WickedShell joined #forth 13:05:19 When you find yourself needing more than 3 or so things on stack do you tend to start using return stack first, variables, or something more creative? 13:20:43 I don't directly use the return stack much 13:20:58 It would depend on the problem at hand 13:22:23 I *prefer* to not use variables as they are slow, but will if they make the code cleaner, or if for a one off thing I'm not keeping around 13:23:38 crc: Do you avoid ROLL and PICK (or equiv)? 13:25:35 I don't use PICK or ROLL at all. I have a `reorder` word that can do complex restructuring that's used very sparingly. 13:26:26 --- join: dave0 joined #forth 13:27:01 http://forth.works/examples/ANS-PICK-ROLL.retro.html would be an implementation of pick and roll for my system 13:28:06 http://forth.works/examples/retro-extend.retro.html has an example using reorder (see the `unpack` word) 13:33:04 Nice 13:34:19 Hmmm I think if I did that I would encode the reordering in the current BASE, e.g. 1234 4321 reorder 13:35:14 Or just require decimal that might work better 13:40:12 reorder isn't fast, but makes some things a lot cleaner :) 13:41:17 Yes, PICK and ROLL aren't lightspeed either, even when you have an easily addressible stack 13:41:38 I guess I need to PICK the right tool for the job, right? ;) 13:42:40 I'll let myself out 13:45:41 crc: Certainly my number version wasn't an attempt to speed anything up, it was me thinking about how to do it on a forth with less succinct strings than retro 13:58:22 --- join: TCZ joined #forth 14:15:48 you can also just use global variables. I think its worth it if theres just no other way 14:16:36 ahem, "local variables" in forth terminology which are variables visible at all times by all words that exist for the life of the program 14:29:17 MrMobius: hmm.. some forths do have local words and variables in a sense (the sub word stuff iirc) 14:54:16 --- quit: gravicappa (Ping timeout: 260 seconds) 14:59:54 --- quit: TCZ (Quit: Leaving) 15:00:20 --- join: TCZ joined #forth 15:04:41 --- quit: xek (Ping timeout: 260 seconds) 15:26:23 --- quit: jsoft (Ping timeout: 264 seconds) 15:44:52 --- join: jsoft joined #forth 16:06:08 --- quit: TCZ (Quit: Leaving) 17:06:54 hey guys 17:08:09 hi tabemann 17:08:46 hey tabemann, Zarutian_HTC, MrMobius, veltas, crc 17:12:15 hi tp 17:13:33 I've been making my Forth word transforms smarter and producing better output 17:14:07 XSLT is working very hard to make embedded Forth easier to use ;-) 17:15:20 here is a sample 17:15:22 \ RTC_TSTR (read-only) Reset:0x00000000 17:15:22 : RTC_TSTR_PM? ( -- 1|0 ) 22 bit RTC_TSTR bit@ ; \ RTC_TSTR_PM, AM/PM notation 17:16:39 in this case it knows because bit 22 is read-only, the appropriate action is to test it 17:17:13 these are just templates btw, they are pasted and modified if needed 17:18:06 it also appends the "?" to the definition name 17:19:00 in the following case it does the same, but it's not known if the bit is r/w,r/o,or r/w 17:19:05 \ RTC_ISR () Reset:0x00000007 17:19:05 : RTC_ISR_ALRAWF? ( -- 1|0 ) 0 bit RTC_ISR bit@ ; \ RTC_ISR_ALRAWF, Alarm A write flag 17:19:54 so it determines that the bit is r/o because of the word "flag" in the description field 17:24:20 nice 17:24:41 * crc still dislikes xml though :) 17:28:43 crc, everyone does but Ive learned that it's very capable, even xslt-1 17:29:10 crc, I do love the embedded templates I can make with it tho 17:30:47 tp: h'lo 18:02:03 back 18:02:03 --- quit: tabemann (Remote host closed the connection) 18:02:18 --- join: tabemann joined #forth 18:09:08 --- join: rdrop-exit joined #forth 18:13:29 --- join: boru` joined #forth 18:13:32 --- quit: boru (Disconnected by services) 18:13:35 --- nick: boru` -> boru 18:21:47 good morning Forthists c[] 18:23:35 rdrop-exit, morning Zen Forth Guru! 18:24:04 hi Forth master Tech (tm)! 18:33:41 hey guys 18:33:49 rdrop-exit, had your coffee yet ? 18:33:55 hey tabemann 18:34:02 hi tabemann 18:34:08 here it is: c[] 18:35:12 rdrop-exit and tabemann mind having a quick look at a very short sample of my latest bitfields output and cast a critical eye ? http://dpaste.com/3KKNGTT 18:36:05 I'm now resorting to looking in the 'description field' for transform information 18:38:36 these look at a number of factors, the register 'access type' and if unknown the 'description field'. It also makes choices on multi or single bit fields etc 18:39:40 where the choice is restricted to one access type, ie 'read-only' it knows the action can only be read related 18:39:54 where are each parent field defined? 18:40:19 tabemann, theyre just a list of memory maps 18:40:41 which are all derived address constants 18:40:49 you always read/modify/write bitfields individually? 18:41:14 tabemann, which are uploaded first 18:41:23 rdrop-exit, I do 18:42:04 you know, if this was for zeptoforth 18:42:07 rdrop-exit, because in embedded, each bitfield is a 'atom' of hardware configuration 18:42:29 what I'd do is make read-modify-write words that take lambdas 18:43:06 tabemann, programmers do that kind of stuff :) 18:43:15 not always tp 18:43:47 rdrop-exit, please elaborate ? 18:45:19 I'm always looking to better under`stand and improve this system, so all criticism and suggestions are gretefully received 18:45:29 gratefully even 18:47:37 some combinations of the different bitfields in a word may be invalid if they work as a group, and therefore should be modified together in a single memory write 18:48:08 rdrop-exit, I wrote a blog article about how I see the tech programmer dichotomy recently: https://mecrisp-stellaris-folkdoc.sourceforge.io/bitfields-declare-early.html 18:49:15 your words return a value and an address, which is not convenient if you want to combine values before writing 18:49:21 rdrop-exit, thats perfectly true, and Keil C attempt to do that with their include file, but I observe various fails (I think) with their system 18:50:28 rdrop-exit, many words do return a value and an address but only because there are multiple actions possible at that stage 18:51:23 rdrop-exit, unless there is only one sensible action choice, in which case the stack comment and word use that 18:51:35 such as bit@ 18:53:00 I see where you're doing that, but again are you always doing a memory read for each one of those read-only fields? 18:53:04 --- join: Chobbes joined #forth 18:54:36 I would normally read the whole register, then isolate the bits 18:55:18 If a register has 10 read-only bitfields, I don't normally want to do 10 memory reads to get at them 18:58:55 even more so with writing, I don't want to do 10 individual read/modify/writes to modifiy 10 bitfields 19:00:16 especially if that might lead to unstable combinations somewhere between the 1st r/m/w and the 10th 19:00:34 yes, always doing a read, and it may not be apparent ? but 905% of this stuff all occurs at the application boot up stage 19:01:06 what I'm almost thinking of is something like [: 0 swap set-FOO 1 swap set-BAR ;] modify-FOOBAR 19:01:14 where [: ;] is a lambda 19:01:19 rdrop-exit, another excellent point re atomic actions 19:02:06 tabemann, now I have to go and find out what a lambda is ! ;-) 19:02:08 tabemann, would that ever be efficient? This is lowest level code we're discussing 19:02:28 rdrop-exit: lambdas in zeptoforth are very light-weight 19:02:35 they're not closures 19:02:41 they're not allocated 19:02:46 they do not carry state 19:02:58 rdrop-exit, thats right, the only 'lower' thing are the memory mapped constants 19:03:16 all they do is push the address of the lambda onto the stack then jump over it 19:03:44 lambdas don't even have word headers (they don't exist in the dictionary) 19:04:46 tabemann, lightweight to me means removing unneeded overhead, not adding it in 19:07:02 I guess you'd need to compare the machine code that's generated when using your approach, versus the traditional straightforward approach 19:07:37 ^ for tabemann 19:08:00 they're essentially equivalent to an unconditional branch followed by a CONSTANT when they're instantiated, and when they're executed they're like any other user-defined word 19:08:33 well, compare the machine code, if it's worse, then why bother 19:09:38 tabemann, i will have a go at using your method (when I understand it) and we can compare the file sizes ? 19:10:25 by that logic we should all be coding in hand-crafted assembly, as Forth code isn't going to approach it in density and speed 19:11:08 no, that's not the implication 19:11:23 tabemann, no that's wrong, we should all be coding in hand coded machine code! 19:11:42 assembly is far too wasteful! 19:13:53 you're saying you would do it in Forth using lambdas, versus doing it in Forth without lambdas. I'm saying I would not bother if all you're doing is adding overhead 19:16:02 --- quit: dddddd (Ping timeout: 246 seconds) 19:16:43 there is overhead - 4 instructions worth at instantiation time, 2 instructions worth at execution time 19:17:26 that's why I wouldn't bother, I really can't see what that overhead is buying me 19:18:47 I very reticent to add runtime overhead without a very strong reason 19:19:36 by that logic you shouldn't use ?do +loop 19:19:58 I rarely use ?do +loop 19:20:03 in zeptoforth, ?do +loop is far, far more expensive than [: ;] 19:20:36 I have cheaper looping constructs than ?do +loop for certain situations 19:20:58 when applicable I use those 19:21:09 TBH I only use ?do +loop when I really don't care about efficiency 19:22:57 but the matter is that it constrains one's programming considerably when one is concerned with shaving off every last cycle possible 19:24:50 and I'm my case with embedded, speed is my last priority as any MCU is usually a million times faster than I need in the real world 19:27:05 in most cases in the real world, people are far more liberal in their use of processor time than we Forthers 19:27:29 like look at the popularity of Java, C#, JavaScript, and Python! 19:27:41 eww, must I ? 19:27:45 :) 19:28:01 back 19:28:16 wb 19:29:44 here is a simple example, if I scan a switch in Forth using the shortest, most efficient code, it will be utterly useless to me. In fact to scan a switch, I usually have to stop the MCU for a million clock cycles first, read the switch, stop it for another million clock cycles etc 19:30:10 this is just to allow for 'contact bounce' 19:31:27 tabemann, I think you're looking at it the wrong way, it's not about shaving cycles 19:32:11 It's about not needlessly adding overhead 19:34:38 you're adding a new construct to your Forth, that adds runtime overhead, presumably something makes that worthwhile to you 19:35:38 What I'm not getting is the positive you see with your lambda alternative that makes it worthwhile 19:36:39 lambdas are about defining executable blocks of code within other words 19:36:42 especially in this particular case 19:37:06 tabemann, ok? 19:37:17 in this case one is defining a self-contained read-modify-write cycle for a register 19:37:24 in one word 19:37:40 otherwise you'd have to have a read word and a write word 19:38:09 naturally the way to do this is to pass an xt to the read-modify-write word that defines the modification desired 19:38:34 one could do this with defining a new word, and then [']-ing it 19:38:51 but then you have to pollute the dictionary 19:39:09 and it looks ugly 19:39:23 none of that makes any sense to me 19:39:38 doing it with a lambda is much nicer, and is no more expensive than doing it the other way 19:40:43 this is coming from a Haskell programmer, and this was precisely the way state is modified in Haskell for a reason 19:40:56 it makes state modification self-contained 19:41:02 sorry, but none of that makes any sense to me 19:41:30 the alternative is to split up reads and writes 19:42:06 which you need anyway 19:43:16 unless you're using a cpu instruction that does an atomic r/m/w, you're going to need the factors 19:43:30 it makes modifying individual fields much simpler, whereas doing it the other way makes it more likely clobber other fields in the register\ 19:44:18 because you have one modify words, and then modify words for each individual field 19:45:20 for any given register you'd have one read word and one modify word 19:45:32 you lost me, does anything you said explain why adding lambdas for this vs not ? 19:45:32 --- quit: jedb (Remote host closed the connection) 19:46:19 the part where lambdas come into play is that they're nicer here than defining new words for each individual register update desired 19:46:55 --- join: jedb joined #forth 19:47:44 note: in cortex-m bit operations have special registers that ensure atomic operations 19:47:50 lambdas are as cheap or cheaper than defining a new word, considering that each new word has a header, while lambdas are headerless 19:48:18 only cell wide writes and reads are not atomic 19:48:32 is anyone proposing defining new words for each individual update required? 19:48:37 hey tp 19:48:41 tabemann, your concept does sound interesting 19:48:46 MrMobius, hey 19:49:43 if it's a factor, it should be named 19:49:45 rdrop-exit, if this were to be implemented, it would require defining new words were lambdas not available 19:51:52 sorry, what new words? 19:54:24 In forth, you want to name factors 19:54:50 if you need to save space, you can always behead them later 19:55:53 what is your opinion of retro's use of quotations? 19:56:10 as what I call lambdas and crc calls quotations are the exact same thing 19:56:11 I haven't looked at retro 19:56:33 other than snippets posted on this channel 19:57:29 so lambdas basically add runtime overhead so you can avoid naming a factor? 19:58:47 seems ass-backwards to me 20:00:02 need more coffee, brb 20:00:19 no, they are no more expensive than naming a factor 20:00:49 in time? space? 20:01:00 correct 20:01:39 names can be beaheaded 20:01:49 as to speed, have you compared? 20:02:15 and runtime code space? 20:02:44 I doubt very much lambdas have 0 runtime overhead 20:02:50 they're one instruction more expensive 20:03:11 so lambdas basically add runtime overhead so you can avoid naming a factor. 20:03:26 seems ass-backwards to me 20:03:32 you're getting hung up over *one* instruction 20:05:09 and unless factors are beheaded, they're considerably cheaper space-wise 20:05:39 no I'm hung up on you purposefully adding that overhead, and thinking you've made your Forth better by adding it 20:06:15 when it seems completely unecessary to have lambdas in the first place 20:07:18 you seem to have this idea where even the slightest bit of overhead categorically rules something out regardless of whatever benefits it might have 20:07:33 what benefits? 20:08:02 I haven't seen the benefits 20:08:09 being able to define executable blocks from within other code, anonymously 20:10:30 being able to simply pass code to other words without having to break it out of its relevant context 20:12:32 if you're passing code to other words you are by definition breaking it out of its original context, it's a factor 20:13:17 (or a label) 20:15:27 a key example is words for defining control structures, which by design allow the lambdas passed to them to modify the outside stack, and thus it is useful to define the code passed in immediately before it is executed to make it clear what the stack it sees is 20:17:33 Sorry, I can't parse that, you can define any control structures you want in your Forth, no lambdas necessary 20:19:18 Control structure words don't normally deal with xts 20:19:29 they deal with code addresses 20:22:16 it's an alternate way of doing data structures 20:22:22 e.g. look at retro 20:27:09 I may one day 20:28:28 but for the moment I'm trying to understand the benefits your lambda example 20:28:41 benefits of ... 20:29:10 whoops 20:29:17 *control structures 20:29:34 got it 20:34:12 atm I'm not convinced there are any pluses to using lambdas in low-level code vs not using them 20:34:45 I'm not even sure there's a real benefit in high level code 20:35:00 I wouldn't use them if one is writing speed-critical code, where every last cycle matters 20:35:15 but most code isn't that speed-critical 20:35:37 where even a single extra instruction is too much 20:36:40 you keep focusing on little they cost, I'm focusing on why would I want to pay any cost at all if they don't buy me anything 20:36:40 even in embedded, as tp says, there are more cycles available than one knows what to do with them 20:37:21 a large part of it is coding style - I come from haskell, were it is the norm to use lambdas liberally 20:37:38 * crc isn't sure how he'd implement traditional forth control structures in retro efficiently 20:38:15 maybe they're great for Haskell, but this is Sparta... err... this is Forth 20:39:12 just because they have clear benefits in Haskell, doesn't necessarily carry over to their usefulness for Forth 20:40:11 Programmers coming from other languages often bring with them their fetishes from other languages 20:40:30 But often they're not relevant to Forth 20:41:47 and can even be counterproductive 20:43:10 But said programmers are convinced they are absolutely positively necessary because they can't imagine life without them 20:43:30 --- quit: reepca (Read error: Connection reset by peer) 20:44:00 --- join: reepca joined #forth 20:44:14 to be honest, I don't use lambdas very much, just because I usually don't find myself having to pass a block of code into something else 20:44:43 but I like having them available, and find them more natural than named factors in places 20:46:11 The places where you find them more natural, might be places that need rethinking, as is the case with things like PICK and ROLL. 20:47:00 for myself, I can function without lambdas (and did for years), but I personally prefer using them 20:47:02 I'm careful not to add words to Forth that make it relatively painless to do the wrong thing. 20:48:48 As Chuck says one change at the bottom can avoid many problems at the top, or something like that, need to dig up the exact quote. 20:49:35 need c[], brb 20:52:20 The evolution of Forth prior to 1978 was completely dominated by Moore himself. As we have seen, Moore was and is a fanatic minimalist, dedicated to the principle of zero-based design in which every feature and every instruction must justify its existence or be ruthlessly scrapped. 20:52:39 to me it's like, "here's some stinky fish, it only costs you *1* instruction at runtime", hence my reaction of why would I want stinky fish. 20:53:41 What people don't get about Chuck, is that he's willing to design a new Forth specific to a particular project. 20:54:15 see, you've already decided it's a stinky fish 20:55:35 all bloat is stinky to me 20:56:20 even if it's soooo cheap 20:56:23 aren't VM-based forths bloat, when one could always compile to native code? 20:57:14 I know what I'm buying with a VM, and whether in this particular case the tradeoff is worthwhile to me 20:58:12 both the positives and negatives are clear to me 20:58:59 Id be interested to see the kind of bitfield templates that zeptoforth would require with this technique 20:59:50 hmm, my neighbour is drunk again and revving the crap out of his highly worked Harley 21:00:21 :)) 21:00:22 lol, Im 25 metres away and can feel the vibration thru our common concrete pad! 21:01:16 and his engine is HOT, that bike pulls like a x-class locomotive 21:02:09 ahh .. the silence is deafening now it's stopped 21:03:14 While in the case of lambdas it seems more like an affectation 21:04:20 People coming from languages like Haskell see the world through lambda tainted glasses 21:04:53 Same with the Object Oriented crowd, they see the world through OO tainted glasses 21:04:57 tp: the modify words would take the form of : modify-MYREGISTER MYREGISTER @ execute MYREGISTER ! ; and the bitfields would have the form of : set-MYFIELD swap MYSHIFT lshift MYMASK and swap MYMASK not and or ; and : get-MYFIELD MYMASK and MYSHIFT rshift ; 21:05:11 tabemann, thanks! 21:07:30 okay, I'm kinda falling asleep, so I'm gonna hit the sack 21:07:41 if your Forth does peephole, you can base the shift/ors on the literal mask. 21:07:45 whoops 21:08:03 : modify-MYREGISTER MYREGISTER @ swap execute MYREGISTER ! ; 21:08:55 night tabemann 21:09:03 goodnight tabemann 21:09:04 g'night guys 21:12:27 here's my equivalent to tabemann's get bitfield, that will work with any contiguous bitfield mask: 21:12:52 bitfield Extract a bitfield (contiguous bits). 21:12:52 When is a literal |bitfield| optimizes down to 21:12:52 an |and| followed by a right shift (if needed). 21:13:07 : bitfield ( x mask -- bits ) tuck and swap rshunt ;inline 21:14:46 so if you have this mask: 21:15:04 15 12 bits constant %csr.mcontrol.action 21:15:28 you would do: 21:15:56 %csr.mcontrol.action bitfield 21:16:38 to get extract the %csr.mcontrol.action bitfield from 21:18:43 all bitfields for cortex-m are contiguous in my experience 21:20:36 that's usually the case, except for things like ISAs that scramble the bits of a value into several bitfields 21:22:56 the important thing to notice is that I only need one BITFIELD word, and it optimizes down to the appropriate AND and possibly RSHIFT 21:23:00 do you mean "scramble the bits of a bitfield into several non contiguous bit positions within a register" ? 21:23:45 yes, but personnaly I just consider those cases to be multiple bitfields that need to be unscrambled into a value 21:24:18 can you give me an example of such a single BITFIELD word ? 21:24:27 I consider a bitfield to be a contiguous sequence of bits 21:24:37 I just did, see above 21:24:38 I do as well 21:24:57 no, thats not a example, thats a concept 21:25:05 no that's code 21:25:14 oh ok! 21:25:21 csr.mcontrol 21:25:36 sorry I missed that being risc-v I think ? 21:25:59 yes, I just randomly picked a bitfield from my RISC-V code 21:26:20 for the example 21:28:23 bbiab, wife is summoning me for something 21:28:30 --- quit: rdrop-exit (Quit: Lost terminal) 21:29:00 no problemo 22:07:41 --- quit: reepca (Read error: Connection reset by peer) 22:08:07 --- join: reepca joined #forth 22:08:33 --- join: gravicappa joined #forth 22:13:19 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 22:13:47 --- join: Zarutian_HTC joined #forth 22:50:04 --- quit: jsoft (Ping timeout: 260 seconds) 22:51:41 --- join: jsoft joined #forth 23:28:23 --- quit: Zarutian_HTC (Remote host closed the connection) 23:59:59 --- log: ended forth/20.05.07