00:00:00 --- log: started forth/19.07.08 01:25:40 Morning Forth 01:37:32 Hi WilhelmVW 02:08:58 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 02:09:16 What's up? 02:09:57 re 02:12:06 Not much, relaxing 02:12:13 hi dave0 02:57:16 --- join: Blue_flame (~cdadr@2405:204:9022:c13c:2960:6134:3c:4d8a) joined #forth 03:13:53 rdrop-exit, any particularly interesting articles in the EuroForml proceedings? 03:17:30 --- quit: dave0 (Ping timeout: 245 seconds) 03:17:56 --- quit: rdrop-exit (Ping timeout: 268 seconds) 03:28:12 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 03:31:01 --- join: rdrop-exit (~markwilli@112.201.174.189) joined #forth 03:33:46 --- quit: Blue_flame (Quit: Blue_flame) 04:24:20 proteusdude: Of the '85 ones, not yet, but I've only read 3 so far. Keep getting sidetracked by other things. 04:25:48 haha I know how that goes.... was searching for hours for a particular paper of interest this weekend but kept "discovering" old papers that I forgot I had that were too interesting not to review again. 04:29:39 so many interesting things, so little time. Im a hardware guy so I don't read all the papers that Forth programmer love, however my distraction is using interesting hardware with my Forth hardware, and that seems to be endless 04:35:11 There are many hardware control related articles in the old FORML proceedings you might enjoy 04:39:45 rdrop-exit, probably not, I don't have any interest in old hardware from the mid 80's, I'm not a retro guy at all 04:40:24 by hardware I mean modern chips such as the LM01 two terminal temperature sensor etc 04:40:34 LMT-01 ... sorry 04:42:22 tp: Two terminal? So using the 1 wire protocol? 04:42:59 Zarutian, no, I really dislike the Dallas ' 1 wire protocol' 04:43:36 this chip sends a number of pulses proportional to temperature 04:45:19 I have a page when I wrote a multi LMT-01 project : https://mecrisp-stellaris-folkdoc.sourceforge.io/project.3temp.sensors.html?highlight=temperature#project-lmt01-temperature-sensor 04:45:33 complete with flowchart :) 04:45:53 please excuse crappy Forth code as I'm still a Forth beginner 04:53:02 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 05:14:15 that's okay mate 05:16:49 it's funny, the Internet is full of Arduino articles featuring the DS18B20 'one wire sensor' and theyre all copies of copies, and theyre all terrible, the poor MCU is flat out handling that dinosaur of a temperature sensor 05:18:04 there are only two articles I could find on the LMT-01, both Arduino and both use the reference article in the LMT-01 data book for continuous monitoring with only one sensor 05:19:10 Forth made it easy for me to design a multi sensor project using Interrupts on STM32F0 which adds almost no load to the MCU 05:21:43 Yes, Arduino is a stupid joke. 05:23:26 people forget or never knew that Arduino was based on a teaching system ("wiring") and designed for artists with zero electronics of computer skills 05:24:45 I see more and more articles by Arduino users who are encountering basic electronics issues, such as those caused by noise or electrical spikes and they are totally flummoxed ... 05:25:45 it reminds me of the days of Visual Basic where a 'team' would design something only to encounter real engineering issues at the later stages of the project that they had no tools or experience to resolve 05:26:01 I don't know what ""designed for "" means. Logo was ""designed for children"", and it is a stupid joke as well. 05:26:53 IMHO they are an offnse to artists and children. 05:27:17 it means whatever the sales droids thought the word would accomplish, usually sales and $$ ? 05:27:56 it's a world full of consumers waiting to be relieved of their money buying 'bargains' 05:28:51 Well said. 05:48:24 i admit I just finished a rant on the "blue pill', a favourite amongst the 'arduino crowd' nowadays https://mecrisp-stellaris-folkdoc.sourceforge.io/rants.html#rant-blue-pill 06:00:01 Why do You use SourceForge? 06:00:25 Or better said how can You? 06:01:31 easy, it's free, fast and they have a HTTP server 06:02:08 I used to pay for a Digital Ocean server for my Forth documentation page but the cost was too much over 5 years 06:02:28 as long as my content is Open Source I can use them 06:03:42 personally I use Fossil as my SCM so I only host tarballs via the py.sphinx system I have uploaded to sourceforge 06:04:28 plus Mecrisp-Stellaris is also hosted on sourceforge 06:23:15 --- quit: rdrop-exit (Quit: Lost terminal) 06:55:49 --- quit: john_metcalf (Ping timeout: 245 seconds) 07:41:29 --- quit: tabemann (Ping timeout: 250 seconds) 08:23:14 --- join: MartijnBraam (martijnbri@gateway/shell/matrix.org/x-bmfrwqnzjrimvpfp) joined #forth 08:50:28 --- quit: dave0 (Quit: dave's not here) 09:08:17 going on holiday soon 09:08:41 a cognitive holiday to the countryside; Gloucestershire 09:09:03 will use some of my time to (hopefully) write a Forth I can be happy with. 09:14:23 some horrible fusion of Retro and Reforth probably 09:14:46 Reforth does a lot right. FOR, DO, etc should have all used the same END keyword 09:15:30 Though I want the only loops to be recursion and a word ;; that jumps to TORS and decrements NORS 09:15:41 ...something like that. 09:39:23 how does `END` determine what it needs to consume? 09:40:02 --- part: MartijnBraam left #forth 09:46:48 found it: http://forth.works/9f423e8b72f0d9b5caa8ee2d43784fb4 09:46:48 (hardcoded handlers, based on a flag passed on the stack) 10:31:45 I did a quick implementation of subwords (sans the ability to use them like vocabularies) and the `my` and `at` local variables: http://forth.works/examples/reforth.retro.html 10:35:50 I thought doing infinitly nestable subwords was pretty easy to do in many single-dictionay Forths 10:36:48 the kind where subwords are only name accessible in its enclosing word definition. 10:39:18 keep a up-down-counter to keep track of how many levels deep of definition levels at specfic character in the parsing it is 10:41:28 if that counter is non-zero when encountering an : then compile in a jump which gets patched later in ; and comma the contents of LAST before begining the usual word header 10:43:29 also comma in a pointer to the start of the enclosing word definition 10:44:43 then at each ; at apropos level restore LAST to the saved value 10:47:12 the jump adds two cells of size overhead per definition on my system, which isn't significant in most cases (I'm not resource constrained most of the time), but it does incur a performance hit on running the word as it now has to skip over anything nested (this will add up a bit) 10:48:59 the space overhead is four cells but indeed the jumping adds up 10:50:03 but then this allows for intermixing of definitions and code that uses them. 10:50:03 the local variable bits are a much bigger hit though: with 500,000 iterations of calling a nested word 5 times, my test system takes 3.43s on average, compared to 0.20s without this 10:51:10 the up-down-counter is only used during compilation, not during running the word. 10:51:17 space overhead on my system is two cells (one for the lit/jump/nop/nop (liju....) instruction and one for the jump target address) 10:51:59 the LAST contents and pointer to enclosing word take two 10:52:39 a non-nested approach with the same conditions runs in 0.17s, so not signficantly faster 10:53:30 the variables caching the pointer to the enclosing word's dictionary header and nesting depth are a fixed, one time cost 10:53:39 I found trying to measure run-time of code in wall-clock time only applicable with hard real time software writing. 10:55:03 measuring in ops is better as that eliminates specific hardware and run noise 10:56:55 but yeah thinking about this kind of juggling isnt easy 10:58:24 The local variables are a big enough hit to be noticeable. The nested definitions aren't, but they make the compiler more complex and don't offer any readability improvements IMO 10:59:55 it's fun to implement things like this, even if I won't end up using them 11:00:05 I find I sometimes refactor a word into many smaller words that do not have any application outside the bigger word 11:01:01 I have a scoping construct to hide factors (the {{ ---reveal--- }} bits) 11:03:25 http://forth.works/book.html#lexical-scope and the glossary entries at http://forth.works/e33775ba807229a7e3d40a03e7cd59b1 11:07:30 --- quit: rprimus (Ping timeout: 245 seconds) 11:09:34 --- join: rprimus (~micro@unaffiliated/micro) joined #forth 11:54:59 --- quit: deesix (Ping timeout: 245 seconds) 11:55:36 --- quit: dddddd (Ping timeout: 272 seconds) 11:56:08 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 11:56:49 --- join: deesix (~dddddd@unaffiliated/dddddd) joined #forth 12:37:52 --- quit: gravicappa (Ping timeout: 268 seconds) 12:41:16 --- quit: dddddd (Ping timeout: 244 seconds) 12:41:50 --- quit: deesix (Ping timeout: 272 seconds) 12:44:37 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 12:48:36 --- join: deesix (~dddddd@unaffiliated/dddddd) joined #forth 12:51:07 I agree with your opinion on the vocab implementation crc 12:51:15 Just seems unnecessary 13:20:20 I don't miss vocabularies; it's much simpler just having a single dictionary 13:22:02 I honestly don't know why retro has lexical scoping, it seems to antithetical to the simplicity 13:36:41 the scoping bits are an old carryover from retro6/7; I've always liked having some control over what factors are exposed in the dictionary, which this provides in a fairly straightforward manner 14:15:33 --- quit: andrei-n (Remote host closed the connection) 16:14:49 --- quit: john_cephalopoda (Ping timeout: 264 seconds) 16:27:35 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:35:24 --- join: rdrop-exit (~markwilli@112.201.174.189) joined #forth 16:38:13 c[] Good morning Forth aficionados 17:02:28 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 17:15:22 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 17:32:31 Good evening rdrop-exit 17:32:59 Greetings and salutations crc 17:35:07 sup o7 17:35:23 hello presiden 17:43:32 hey guys 17:44:02 Hi tabemann 17:47:16 I need to actually get around to porting hashforth to that Discovery board I got 17:48:24 I'm not sure if I want to just port the C code I have or whether I want to do a rewrite in ARM assembly 18:03:15 okay, gotta head out, bbl 18:03:36 cya 18:04:33 --- quit: tabemann (Read error: Connection reset by peer) 18:05:44 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 18:11:07 --- quit: tabemann (Read error: Connection reset by peer) 18:17:59 rdrop-exit, you were right, I was wrong :) 18:18:19 about? 18:18:36 rdrop-exit, I looked at the docs you mentioned and found some very interesting 18:18:47 cool :) 18:18:57 https://www.complang.tuwien.ac.at/anton/euroforth/ef85/papers/ 18:20:38 it seems Forth just never stops giving ;-) 18:23:41 excellent 18:30:18 --- join: amuck_ (~amuck@152.243.185.35.bc.googleusercontent.com) joined #forth 18:31:01 --- quit: amuck (Quit: ZNC 1.7.3 - https://znc.in) 18:31:07 --- nick: amuck_ -> amuck 18:33:47 --- join: tabemann (~tabemann@2600:1700:7990:24e0:3d62:1943:253e:4966) joined #forth 19:38:24 --- part: tabemann left #forth 19:38:54 --- join: tabemann (~tabemann@2600:1700:7990:24e0:3d62:1943:253e:4966) joined #forth 19:59:10 hey.. I'm implementing an ITC forth-like in C for an embedded system.. and I'm looking at moving forth pt 3 ... it looks like dodoes requires implementing putting machine instructions as a header to the does-word 19:59:50 I'm trying to avoid having to use assembly anywhere.. anyone got any ideas? 20:00:41 https://www.bradrodriguez.com/papers/mov3-8.gif .. that specifically 20:00:43 the JSR DODOES 20:03:56 hey 20:04:05 I've implemented an ITC forth 20:04:22 what I did is put a function pointer in the word header 20:04:30 yah, as your CFA? 20:04:48 I'm not familiar with the terminology 20:04:56 code field 20:05:05 yeah 20:05:24 that's what I have right now.. it goes function pointer, parameter[] .. but the problem is dodoes requires a second indirection 20:05:27 like in non-primitive words I would put what would be called docol or dodoes in that field 20:05:55 what I do is I put a pointer to the start of the Forth code in the header 20:06:04 and docol or dodoes invokes this code 20:06:17 and where do you put the parameter field? 20:06:30 what do you mean by "parameter" - the data field? 20:06:34 yah 20:06:50 I put a pointer to that in the header as well 20:08:30 ok, so a does requires 3 pointers right? the code for the dodoes, the data field, and then the word that dodoes needs to execute 20:09:28 you can reduce it to two if one puts the data right after the header, but I prefer to put a pointer to the data so I can put the header anywhere 20:09:38 ok 20:09:51 like the Forth I am currently working on is TTC 20:10:03 so the header is not contiguous with the data or with the Forth code 20:10:24 cool, I can see how I could do dodoes if I give myself another cell worth of pointer. 20:10:53 note that one also needs a docreate 20:11:55 (one could do the same with dodoes if one checks for a Forth code pointer that is null, but having a separate code function will be faster) 20:29:19 tabemann: https://github.com/arborstate/emtk/blob/master/bootstrap.fth .. that's what I have right now 20:29:36 the dict looks like: link, count, string (aligned), code pointer, param[] 20:40:24 back 20:41:42 you know you can derive CONSTANT with : CONSTANT CREATE , DOES> @ ; right? 21:06:37 It just occured to me that its been over 25 years since I last used ITC. Time flies. 21:09:26 In the early issues of Forth Dimensions Bill Ragsdale editorial stance was that if it wasn't ITC it wasn't Forth. 21:10:08 my first Forth was ITC, my second Forth is TTC because it's meant to allow loading portable images, and TTC is more suited to that 21:10:42 --- join: gravicappa (~gravicapp@h109-187-239-230.dyn.bashtel.ru) joined #forth 21:12:23 I still haven't decided what form my Discovery hashforth will take 21:12:34 I'm almost thinking of writing an assembler in Forth 21:12:51 and then writing my Discovery hashforth for that assember 21:13:08 so I don't need to tie myself to the gcc toolchain or like 21:20:25 You could use the Forth tp mentioned to cross-assemble your initial image. 21:21:20 It targets ARM IIRC 21:22:11 you mean mecrisp-stellaris? isn't that a Forth meant for target systems? 21:22:52 I thought mecrisp-stellaris itself was written in GNU as? 21:23:31 He mentioned there's also a "cross" variant. 21:24:52 do you have a link? (I'd be very interested) 21:26:23 I don't, I'm not familiar with it, just what I read here. 21:26:27 it's called 'mecrisp-across' 21:27:00 ...and like magic he appears :) 21:27:03 https://mecrisp-across-folkdoc.sourceforge.io/index.html 21:27:31 i hear the irc 'beeps' while Im working and check every few minutes :) 21:28:15 tabemann, Mecrisp-Stellaris cross compiles for MSP430 on a Cortex-M4 21:28:25 I should look into configuring my irc client to do that, not sure if it can. 21:28:59 it also emulates the MSP430 with a slowdown of about 20x (no that I notice) 21:29:09 this irc client is 'hexchat' 21:29:28 I'm using "irssi" 21:29:31 just a fork of xchat 21:30:10 all programmers use irssi but Im a tech so I click n grunt like a windows user ;-) 21:30:30 :)) 21:31:20 back 21:32:02 what I need is something that runs in roughly ANS Forth which will crossassemble to ARM Cortex-M 21:32:25 (while my Forth doesn't run ANS Forth, it's close enough that it's easy to translate ANS Forth to run under it) 21:32:58 * tabemann is using a homemade IRC client written in Haskell, Amphibian 21:33:18 the author of mecrisp-across won't do a cross compiler to cortex-M, he doesnt like ARM 21:33:31 he also says it's too complex 21:34:12 well I'm targeting ARM, so I might as well write my own ARM assembler in Forth then 21:34:20 oh well 21:34:24 he thinks in MSP430 assembly language which he loves, and I fdont blame him, it's as smooth as silk 21:34:44 --- quit: dave0 (Quit: dave's not here) 21:35:02 My mistake, I thought there was an ARM version 21:35:13 hmm 21:35:28 are you thinking of his assembler-m0 ? 21:36:10 No, I thought you mentioned ARM before, just me getting senile. 21:37:03 tabemann, grab the latest "mecrisp-stellaris" tarball from here https://sourceforge.net/projects/mecrisp/files/ 21:37:32 and grab the "assembler-mo.txt" from the /common directory 21:38:11 thats a cortex-m0 assembler that runs under Forth, a kind of interactive assembler if you will\ 21:38:46 rdrop-exit, all I mention is ARM as it's all I use (cortex-M0) 21:39:20 ah 21:40:18 thanks 21:41:00 rdrop-exit, mainly because I bought 480 off STM32F051 MCU's back in 2014 from AVENET for $0.56 each 21:41:12 tabemann, no problemo, I hope it's useful 21:44:00 the only issue is unless Cortex-M0 is forwards-compatible with Cortex-M4, I might have to port Matthias Koch's code 21:44:42 m4 will run m0 code no problemo 21:44:50 but not the other way around 21:44:56 the problem with that is that Matthias Koch wrote most of his comments in German!!! 21:45:30 https://translate.google.com :) 21:45:36 ich spreche ein bisschen Deutsch, aber ich dieses Deutsch nicht kann!!!! 21:45:50 thats probably because he's German, and taught himself english 21:46:11 Ich bin ein Berliner 21:46:47 but yeah 21:47:00 I might just want to write it in Cortex-M0 assembler anyways 21:47:06 for the sake of backwards compatibility 21:47:58 I would because even the lowly M0 is awesome and billions are used every year 21:48:32 and from there you can use any Cortex-M processor 21:48:54 there is also a 'assembler-m3' in the /common directory 21:53:56 I don't see an assembler-m3 21:54:05 even though I do see a disassembler-m3 21:55:00 oops 21:55:20 apologies, I conflated that which should not be conflated 21:55:34 there is only assembler-m0 21:56:14 --- quit: dddddd (Remote host closed the connection) 21:57:07 of course, I'd have to mix licenses, because I'd have to modify assembler-m0 to fit hashforth, but assembler-m0 is GPL3 and hashforth is BSD3 21:57:31 that's not too much of a problem, because I just would not integrate assembler-m0 into the hashforth image 21:57:41 but rather require it to be loaded with include/require 21:58:33 youd have to write your own anyway as assembler-m0 isnt complete 21:58:43 I'm a BSD3 man myself 21:59:28 assembler-m0 seems like it could be usable 21:59:42 as I'm not using it to allow the user to embed their own code in assembly 21:59:57 but rather just to assemble a hashforth executable for Cortex M 22:00:43 ahh 22:00:50 hashforth-m0 ? 22:02:33 yes 22:03:21 I'm targeting Discovery for starters, but would like to use a single executable as much as possible for all of Cortex M 22:03:39 as hashforth is in C compiled for X86, cant you just target cortex thumb for a M0 version ? 22:04:10 I could do that, but I'd like to make it independent of C by rewriting it in assembly 22:04:23 there is no need to target a discovery as the disco adds nothing to the chip it doesnt already have 22:04:24 my POSIX version would stay in C 22:04:36 well yes 22:04:47 I'd really be targeting Cortex-M4 22:04:49 Forth runs quite happily standalone on a M0 chip 22:05:00 or a M3, or M4 etc 22:05:32 I have Mecrisp-Stellaris running on a stm32f051 with only a powersupply smoothing capacitor, nothing else 22:06:06 the real difference between devices is memory sizes and peripherals 22:06:20 true 22:06:42 Discovery does have an FPU, though, and while I have held off trying to add FPU support, I could add it if I wanted to 22:06:48 and they all have the same basic peripherals with the modern chips 22:07:06 only a disco M4 has a FPU in the F4 chip 22:08:48 okay, I should be off to bed 22:08:54 Mecrisp-Stellaris has good fixed point support and we tend to use that 22:09:01 but thanks for pointing me towards that m0 assembler 22:09:06 pleasure 22:09:11 nighto! 22:09:27 g'night 22:33:51 tabemann: I could derive it.. but I don't have does> yet 22:34:06 (constant, that is) 22:47:36 --- join: proteusguy (~proteusgu@14.207.170.252) joined #forth 22:47:36 --- mode: ChanServ set +v proteusguy 22:55:23 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 22:56:02 re 23:04:35 er 23:12:34 ee 23:20:41 --- join: john_metcalf (~digital_w@host31-54-142-171.range31-54.btcentralplus.com) joined #forth 23:59:59 --- log: ended forth/19.07.08