00:00:00 --- log: started forth/20.02.15 00:09:29 --- join: proteus-dude joined #forth 00:18:45 --- join: jedb joined #forth 00:24:24 --- quit: _whitelogger (Remote host closed the connection) 00:27:27 --- join: _whitelogger joined #forth 00:45:25 --- quit: _whitelogger (Remote host closed the connection) 00:48:28 --- join: _whitelogger joined #forth 01:13:49 --- quit: dddddd (Ping timeout: 268 seconds) 03:08:17 --- join: xek joined #forth 03:44:03 --- quit: iyzsong (Ping timeout: 272 seconds) 04:21:25 --- quit: xek (Ping timeout: 272 seconds) 04:36:01 --- join: xek joined #forth 05:28:41 --- join: dys joined #forth 05:34:24 --- quit: cheater (Quit: Reconnecting) 05:34:45 --- join: cheater joined #forth 05:47:23 --- join: dddddd joined #forth 05:54:01 --- quit: jsoft (Ping timeout: 240 seconds) 07:10:33 --- quit: xek (Ping timeout: 260 seconds) 08:24:26 --- quit: tabemann (Ping timeout: 248 seconds) 08:31:01 --- quit: dys (Ping timeout: 268 seconds) 09:03:29 --- quit: gravicappa (Ping timeout: 260 seconds) 10:17:50 --- join: gravicappa joined #forth 10:51:33 --- quit: gravicappa (Ping timeout: 272 seconds) 11:27:46 --- join: X-Scale` joined #forth 11:28:59 --- quit: X-Scale (Ping timeout: 265 seconds) 11:31:00 --- join: X-Scale joined #forth 11:32:09 --- quit: X-Scale` (Ping timeout: 240 seconds) 11:53:28 --- join: pierpal joined #forth 12:47:06 --- join: xek joined #forth 13:02:09 --- join: gravicappa joined #forth 13:13:37 --- quit: gravicappa (Ping timeout: 240 seconds) 13:20:45 --- quit: pierpal (Quit: Poof) 13:21:05 --- join: pierpal joined #forth 14:28:18 --- quit: pierpal (Ping timeout: 265 seconds) 14:28:59 --- join: jsoft joined #forth 14:30:01 --- quit: xek (Ping timeout: 240 seconds) 15:21:19 --- join: pierpal joined #forth 15:31:15 --- quit: jsoft (Remote host closed the connection) 16:25:37 --- quit: pierpal (Ping timeout: 240 seconds) 16:26:35 --- join: dave0 joined #forth 16:37:04 --- join: tabemann joined #forth 17:23:21 --- join: iyzsong joined #forth 17:46:43 is there a way to write something like [ value 1 + ] literal so that it still does what it does in compile more but can also be used in immediate mode? 17:46:57 as if the [ ] and literal werent there 17:55:39 --- quit: tabemann (Ping timeout: 265 seconds) 18:26:14 --- join: pierpal joined #forth 18:36:41 --- join: boru` joined #forth 18:36:44 --- quit: boru (Disconnected by services) 18:36:46 --- nick: boru` -> boru 18:38:25 --- quit: proteus-guy (Ping timeout: 260 seconds) 18:38:57 --- quit: proteus-dude (Ping timeout: 272 seconds) 18:54:43 --- quit: pierpal (Read error: Connection reset by peer) 19:04:05 --- join: iyzsong-x joined #forth 19:04:21 --- quit: iyzsong (Ping timeout: 268 seconds) 19:21:42 --- join: tabemann joined #forth 19:36:02 --- join: iyzsong joined #forth 19:37:07 --- quit: iyzsong-x (Read error: Connection reset by peer) 19:58:26 --- join: rdrop-exit joined #forth 20:06:41 MrMobius, if you're Forth has a peephole optimizer then 5 1+ should end up compiled as 6 20:11:02 if not you could make a word to reduce the clutter 20:12:24 e.g. instead of [ foo 2 + ] literal 20:12:46 you could have something like [ foo 2 + ]# 20:14:15 If your Forth has a peephole optimizer then no need, just use: foo 2 + 20:15:40 The above assumes foo is a constant 20:31:40 hey 20:31:54 hi tabemann! 20:32:27 rdrop-exit, Zen Forth Guru! 20:32:31 hey tabemann 20:32:34 hey tp 20:32:52 hello Master Forth Technician from Down-Under (tm) 20:33:18 zeptoforth seems almost complete, at least for the DISCOVERY board, but I don't really know how to debug it 20:33:42 rdrop-exit, I have no clue about the use of " [ foo 2 + ] literal" would you mind giving a example of it's use ? 20:34:18 [ foo 2 + ] puts the system in interpretation mode, evaluates foo, and adds 2 to it 20:34:28 rdrop-exit, recently on fire Australia, then wet Australia, now sunny and humid Australia 20:34:31 literal takes a value off the top of the stack and compiles it as literal 20:34:41 I don't think it would apply to you tp, since you're Forth has peephole optimization 20:34:52 rdrop-exit, ahh 20:35:08 In a forth without peephole optimization something like: 20:35:35 10 constant foo 20:35:39 tabemann, yeah, I have a comprehensive dictionary explaining individual commands but whee I have trouble is in imagining the application 20:35:54 : example ... foo 2 + ... ; 20:36:26 basically you put everything you want evaluated immediately between brackets 20:36:45 then, after it's been evaluated immediately, the close bracket sends you back to compilation 20:37:05 so if you've put a value on top of the stack while executing immediately 20:37:15 would probably compile (depending on the Forth and its idiosynchracies)... 20:37:16 you can then use LITERAL to compile that value 20:37:38 |lit|10|lit|2|+| 20:37:59 it's very useful if one has expensive operations that you only need to evaluate once, at compile-time 20:38:00 while : example ... [ foo 2 + ] literal ... ; 20:38:06 might compile... 20:38:19 |...|lit|12|...| 20:39:38 A peephole optimizer would take care of it for you, if you're Forth doesn't have one, you have to explicitly do it yourself 20:41:02 [ puts you into interpretation state 20:41:11 yes 20:41:18 you then add 2 to 10 while in interpretation state 20:41:24 it's very useful if one has expensive operations that you only need to evaluate once, at compile-time <-- aha 20:41:34 then you get out of interpreation state with ] 20:41:41 yes 20:41:53 and use LITERAL to compile the calculated literal 20:42:28 yes, I can follow the syntax and what they do, I couldnt see the application 20:42:38 You could do a shorthand to make it less wordy, e.g. 20:43:00 seeing the application in these cases is my difficulty 20:43:12 : ]# { x -- }( -- x ) postpone literal ] ; immediate 20:43:37 you mean 20:43:43 a little shorter, allows you to do [ foo 2 + ]# 20:43:58 instead of [ foo 2 + ] literal 20:44:11 : ]# { x -- }( -- x ) postpone ] postpone literal ; immediate 20:45:05 why are you postponing ] ? 20:45:22 okay, forget about it 20:45:32 * tabemann for a sec thought ] was immediate 20:45:48 In my Forth the actual syntax would be: 20:46:27 : ]# { x -- }{ -- x } lit, ] ; directive 20:46:44 but that's non-standard ;) 20:47:04 I don't have LITERAL anymore 20:47:19 just lit, which isn't immediate 20:47:40 oops wrong stack comment, try again 20:48:00 : ]# { x -- }( -- x ) lit, ] ; directive 20:49:09 It's still something to keep in mind when you're dealing with a small resident Forth that has no optimization 20:51:10 thanks guys 20:51:40 I've heavily used [ ] literal when working on math routines in the past 20:51:44 I understand the application and mechanism now :) 20:51:53 cool :) 20:52:08 where often things can be very expensive, but only needing execution once 20:53:19 Another option is to just do constant foo 20:53:50 *calculations 20:53:50 I always have tons of time to get stuff done, so expensive operations are rarely a issue for me 20:55:16 the technique also saves dictionary space as well reducing runtime overhead 20:55:58 I still wonder how those 64-bit fixed point values mecrisp-stellaris uses work on a platform lacking 64-bit division altogether 20:56:05 But in your case your Mecrisp Forth takes care of it for you 20:57:29 Division is best avoided altogether when possible 20:58:29 tabemann, Mecrisp-Stellaris only has 32 bit division with a 64 bit result I think 20:58:46 you mean multiplication 20:59:45 there are all sorts of tricks to avoid division by small constants 21:01:49 even C lacks double-word by single-word division 21:02:43 except perhaps as a non-standard compiler intrinsic 21:03:52 in fact C even lacks a double-word product 21:06:10 no, you cast to __int128 and then do your product there :D 21:06:18 yes, that's not standard 21:06:23 non-standard 21:06:24 but both gcc and clang support it 21:08:03 * tabemann is willing to use a feature if both gcc and clang have it 21:08:04 actually IIRC anything to do with 128 bits is non-standard 21:08:10 yes 21:08:52 even though I've run into compilers that are sufficiently standard that hey don't even support declaring variables anywhere but at the top of a block 21:09:52 never heard of that 21:10:15 I mean local variables 21:10:16 rdrop-exit, yes, in a way Mecrisp-Stellaris has made my Forth life a lot easier by taking care of so many issues 21:10:36 rdrop-exit, which is ok for a tech, but would annoy a programmer I guess 21:11:52 tp, as long as you can switch optmizations off it's ok 21:12:04 zeptoforth is a stupid compiler 21:12:13 i.e. it compiles exactly what you tell it to 21:12:43 that's fine, any smarts should be layered on and optional 21:13:08 rdrop-exit, I can by using a version that isnt optimised 21:13:21 the Mecrisp-Stellaris binary isnt called with any switches 21:14:46 tp, I imagine there's words such as -peep +peep to switch any smarts off or on 21:15:28 (not necessarily those specific names) 21:15:52 no 21:16:07 I know all the base words by heart 21:16:09 oh well 21:16:32 there may be secret wizard ways that arent documented or only in Gernam 21:17:13 the mecrisp-stellaris code is maddening when it's all in german, because my german isn't that good 21:17:20 You haven't earned your Mecrisp Secret Decoder Ring (tm) yet 21:17:36 they arent as bad as the C "-01" ? where loops get optimised away 21:17:58 rdrop-exit, hahah, no and I probably never will, but frankly, I dont care 21:18:05 I never optimize control flow in my Forths 21:18:12 all I want Mecrisp-Stellaris to do is help me make hardware 21:18:16 (except for tail call elimination) 21:18:41 No soup for you 21:18:50 there is another final level of opts that Ive never used, this is done via a Word 21:19:27 in my world, I have tons of speed, tons of memory, tons of peripherals, so I pretty much want for nothing 21:19:34 the problem with TCE in Cortex-M is that farther bl calls are smaller than farther b calls, where one *needs* to create a literal and then feed it into blx 21:19:45 for me this is the 'Golden Age" of microprocessors 21:19:51 I don't want an optimizer that does too much 21:20:25 just light peephole stuff + tail call 21:21:32 in fact ... I read a embedded forum thread a couple of days ago where posters debated about the best way deal with a dead commericial eprom burner as the OP wanted to program a 2716. The debate was about Arduino or HAL, or Mbed etc 21:22:06 I was stunned that someone would even post about the subjet as a Forth solution is a no brainer 21:22:53 in the 70's we would make one ourselves with some logic chips and transistors, no mcu, and not think twice about it 21:24:50 to me the only variables are 1) data input method, clone physical rom in socket to another 2716 ?, copy the data to a file ? burn new eprom from a file ? etc 21:25:04 the actual technology is dead simple 21:26:12 people don't get simple anymore 21:26:35 next I bet they will start building one with Arduino and running into 21V dc issues, or accurate delay time issues, or wether to use interrupts 21:26:54 they see the problem through the lenses of they're bloated tools 21:26:55 or maybe problems with structures or pointers 21:27:00 *their 21:27:02 they sure seem to 21:27:50 Forth allows me to see the problem, then it FORCES me to understand what the problem actually is 21:28:09 the code retreats into the background, it's not in my way 21:29:02 no premature abstraction 21:29:07 if anything, the main issue I have with Forth is deciding which one of the many available methods to use 21:29:35 because they all will work just fine 21:30:00 --- join: gravicappa joined #forth 21:30:09 it's like, I need a hole, should I use the shovel, or posthole digger ? 21:31:17 chrome-plated posthole digger 21:31:39 I nearly followed up to the forum Post advising them it a simple solution just use Forth, then I remembered the typical C user disdain for Forth, and didn't bother. 21:32:02 they won't get it anyway 21:32:06 hehe, Forth has uncountable solutions for every problem 21:32:29 yeah, I'm (just) wise enough to know not to waste my time there 21:32:56 Don't forget it's a secret weapon 21:33:27 I feel that in the end, when the binary hits the hardware, all solutions look much the same, wether it started out as C or Forth, etc 21:33:57 it's the getting to the binary where the major differences, gains and traps lie 21:34:32 in theory you're right, but I'm sure there are plenty of bloated binaries out there 21:34:47 as a tech, it's the getting to the binary that is my main area of interest 21:35:01 youre definitely right 21:35:43 If one uses the standard STM32 libs and Gcc for a blinky, the binary is about 30kB it's massive! 21:35:53 bbiab 21:35:56 to me, Forth is essentially the love child of assembly and Lisp - it is almost as low level as assembly, but it is also simultaneously high level and has a powerful REPL and metaprogramming capabilities like Lisp 21:36:22 then using various Opts it can get down to the same size as Forth, providing one knows the safe C opts to use 21:36:36 tabemann, I agree 21:37:21 tabemann, I see Forth as a layered top down design where all the Words at the top look a lot likeAssembly 21:37:45 and as the Word list increases they look and are more HLL 21:38:04 until finally the Words are the actual PDL 21:38:23 on wash spin stop 21:38:25 etc 21:38:25 I've written Forth that looks very low level and Forth that looks very high level 21:39:15 and yes, it's a progression from low level to high level typically 21:39:22 thats typical of programmers for sure, but real world device Forth code behaves as I described 21:39:43 without all the low level stuff the higher levels can't happen 21:41:18 I tend to have two files, one is for all the low level stuff and is loaded first, the second is the high level stuff and is loaded last 21:41:38 this is all orchestrated when I click the 'make' button in my gui editor 21:42:07 I simply dont need to see the low level stuff after it's written and tested 21:46:22 so in essence you've written something like a HAL layer that you can forget once it's working? 21:52:19 --- join: jsoft joined #forth 21:54:35 --- quit: dddddd (Ping timeout: 248 seconds) 21:59:23 good question 21:59:49 but it's not a layer to me. To me it's just hardware 'configuration' 22:00:48 once the low level hardware has been configured I can then move to the next level, designing Words to use the hardware 22:07:24 I'm annoyed that I have run into the same problem that mecrisp-stellaris has 22:07:36 you simply cannot allocate memory while compiling code in flash 22:07:36 too much German ? 22:08:10 the problem is this 22:08:11 can you elaborate ? 22:08:20 if you could allocate RAM in flash 22:08:41 then flash would be pointing to arbitrary RAM floating in the middle of memory after rebooting 22:09:07 the only real way to allocate memory from flash 22:09:17 is to define offset pointers as constants in flash 22:09:32 and to allot RAM by these offsets on bootup 22:09:59 there is some trickery going on for sure 22:10:43 ram has actual addresses, the same as flash 22:11:18 I guess on could just allocate ram based on addresses from flash ? 22:11:43 Mecrisp-Stellaris has a number of pointers that keep track of stuff like that 22:12:13 I'm just going to use a word I call HERE! 22:12:18 which sets the HERE pointer 22:12:23 which can be used on bootup 22:12:38 ALLOT could be used too 22:13:13 i have a "here" word 22:13:35 HERE! is for setting HERE 22:13:44 to an absolute address 22:13:51 I'm compiling in ram in this case 22:13:55 here hex. 20002DE0 ok. 22:14:27 actually, I've just got an idea! 22:14:38 and now I've switched to 'compiletoflash' 22:14:41 here hex. 0000CDB0 ok. 22:15:16 I make a word that takes the form of : ALLOT-CONSTANT HERE SWAP ALLOT CONSTANT ; 22:15:27 I did things slightly differently 22:15:44 there are two HERE pointers, one for RAM and one for Flash, which are kept separate 22:16:01 and there are a set of words that choose which to use based upon compilation mode 22:16:12 but they're still underlyingly separate 22:16:22 so you can still use HERE while compiling to flash 22:17:45 i use HERE to compute the remaining ram and flash while developing user apps 22:18:06 but it's result depends one the mode (Flash or Ram) 22:23:19 --- join: proteus-guy joined #forth 22:33:21 hey 22:38:26 --- join: proteus-dude joined #forth 22:39:47 rdrop-exit, the thing is I'm doing a text replacement on some symbols and replacing them with [ array_base const_offset + ] literal which saves a lot of space 22:39:59 but then you cant use those symbols in immediate mode 22:40:45 --- quit: proteus-dude (Client Quit) 22:41:02 is there something clever you could replace the symbol with that would function like [ x y + ] literal in compile mode but x y + in immediate mode? 22:56:46 --- quit: dave0 (Quit: dave's not here) 22:57:44 back 22:59:08 : [+literal] STATE @ IF + POSTPONE LITERAL ELSE + THEN ; IMMEDIATE 22:59:43 well 22:59:56 maybe just 23:00:05 : +lit STATE @ IF + POSTPONE LITERAL ELSE + THEN ; IMMEDIATE 23:00:08 for short 23:00:38 MrMobius, does your Forth have constant folding? If it does you don't need to hand-optimize compilation with [ x y + ] literal 23:00:56 tabemann, that won't work 23:03:23 yes it does 23:03:33 1 2 + lit . 3 ok 23:03:42 there's nothing on the stack to add at compile-time 23:03:43 : foo [ 1 2 ] +lit ; ok 23:03:51 foo . 3 ok 23:04:16 sure if you use [ ... ] but that's what he's trying to avoid 23:05:03 if I understood correctly he wants the code to look the same whether he's interpreting or compiling 23:05:17 and I don't see how you can do that 23:05:45 unless 23:05:48 You'd have to make a fairly ugly prefix word 23:05:56 yeah 23:06:00 which I wouldn't recommend in for this 23:06:11 you'd have to make a word that parses x and y as its arguments after it 23:06:19 yup 23:06:22 which seems like a bad way to do it 23:06:27 yup 23:06:36 I agree 23:08:00 Good uses of prefix words are fairly limited, exception handling and redirecting words, I don't think this is a good use case 23:09:11 (and defining words) 23:11:20 unless his Forth is running on a very small target, constant folding is the way to go I think 23:13:05 gotta go, kids are coming over, catch you all soon 23:13:17 --- quit: rdrop-exit (Quit: Lost terminal) 23:21:40 so basically something like : foo bar ; create foo2 bar , 23:22:19 which becomes the equivalent of : foo [ base offset + ] literal ; create foo2 base offset + , 23:22:45 and no onstant folding to answer rdrop-exit's question 23:24:25 MrMobius, base offset + sounds like youre creating memory mapped Words ? 23:25:26 individual byte size variables 23:25:33 saves about 600 bytes doing it this way 23:25:43 which is significant on a 6502 system 23:26:00 definitely 23:26:53 I do a similar thing but it's processed externally from a XML file 23:27:45 how does that work? 23:28:26 i have a big xml file of all the registers and I parse it with xlst into memory mapped words like so 23:28:45 $40021000 constant RCC ( Reset and clock control ) 23:28:45 RCC $0 + constant RCC_CR ( Clock control register ) 23:28:45 RCC $4 + constant RCC_CFGR ( Clock configuration register RCC_CFGR ) 23:28:45 RCC $8 + constant RCC_CIR ( Clock interrupt register RCC_CIR ) 23:29:03 and so on for thousands of registers in some cases 23:32:40 neat 23:33:53 it was one of the first things I did when I started using Forth because cortex-m mcus can have up to complex peripherals on the chip 23:34:02 up to 97 peripherals 23:34:39 and they can have lots of registers which have thousands of bitfields 23:35:55 up until them all the Forth cortex-m users were just making their own unique memory mapped words so reusing their code was nearly impossible 23:42:14 I had some annoyances on a cortex m0 in C 23:42:37 different pins needed different code to do the same thing 0_0 23:47:53 yeah, cortex-m0 has a couple of those 23:48:32 i was also annoyed when I discovered those too 23:49:12 I found them because my parser produced some different Words with the same memory mappings 23:50:09 I can only imagine the C structure complexity top handle those cases 23:50:13 -p 23:51:04 they are really efficient actually 23:51:54 if you give it a constant, it will shorten it down to exactly the code you need rather than including useless code you dont need for that pin 23:53:44 one would hope so, but that leads me into a observation I have about C for embedded 23:54:46 one can do the same kind of 'structure' in Forth thing that C does and at least one ex Forth user put a lot of effort into doing just that 23:55:15 that was the now defunct 'geelabs' 'embello' thing 23:56:12 but as a Forth user I find that Im usually only changing one config at a time, the last thing I'd ever want to have to do is configure every bitfield in a register at once 23:56:33 which is what C users seem to do 23:59:59 --- log: ended forth/20.02.15