00:00:00 --- log: started forth/16.07.29 00:21:58 how forth-friendly is ARM? For perspective, is it more or less "forth-friendly" (feel free to define that term for yourself) than x86 or x86_64? I guess more generally, where could I find information about which architectures are well-suited to forth? 00:26:16 Hah, I was just thinking about this. Maybe there are some tricks that would make arm forth work well, but to me it seems like a load-store architecture means you really want to make use of all your registers, and a forth implementation won't do that. 00:30:01 Brad Rordiguez's "Moving Forth" series has a good overview on what it takes to implement forth, with case studies for a few processors, showing how you'd implement some of the more important words. 00:59:49 --- quit: Keshl (Ping timeout: 260 seconds) 01:05:19 --- quit: MickyW (Quit: Verlassend/leaving) 01:05:27 --- join: Keshl (~Purple@24.115.181.94.res-cmts.gld.ptd.net) joined #forth 01:05:41 --- join: nal2 (~nal@adsl-64-237-237-8.prtc.net) joined #forth 01:09:31 --- quit: nal1 (Ping timeout: 260 seconds) 02:40:06 Gracana: has someone update moving forth? its cpus are now not that modern 02:41:46 --- quit: ASau (Ping timeout: 250 seconds) 03:05:43 --- quit: nal2 (Quit: WeeChat 1.4) 03:30:41 --- quit: wa5qjh (Remote host closed the connection) 03:40:14 --- join: wa5qjh (~Thunderbi@203.111.224.35) joined #forth 03:46:20 --- quit: nighty (Quit: Disappears in a puff of smoke) 04:08:45 It seems like such a waste, leaving a bunch of registers unused and having to constantly load from memory into TOS, but I can't think of any way to compile code to make use of them without having to move all of the stack-register-things up one whenever something gets popped. Somewhere I remember someone claiming that there were "native code" (subroutine-threaded?) forths that could be "just as fast as C" (their words, not mine), and I'm 04:08:47 wondering how they do that 04:11:08 (and I assume that they didn't mean "with highly-optimized assembler"...) 04:12:30 reepca: I guess it is a Forth compiler. 04:14:05 DKordic: what's the distinction between a "Forth compiler" and, for example, gforth? 04:14:09 yunfan: Good question. It could be [[http://www.camelforth.com/news.php][CamelForth]] source (not yet). 04:15:23 reepca: Sorry, I meant to say an optimizing compiler. Machine code or not. 04:17:01 Can an optimizing compiler make use of the extra registers after the ones mentioned in the first part of Moving Forth are allocated? Or rather, do any currently? 04:31:21 That problem is called ``[[https://en.wikipedia.org/wiki/Register_allocation][Register Allocation]]''. 04:46:38 DKordic: so that's your project? 04:50:25 yunfan: Of course not :) . It's by Brad Rodriguez. 04:51:45 and its not open sourced/ 04:55:13 --- quit: DGASAU (Ping timeout: 244 seconds) 04:58:36 --- join: leaverite (~Thunderbi@203.111.224.54) joined #forth 04:59:32 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 04:59:52 --- quit: wa5qjh (Ping timeout: 244 seconds) 04:59:53 --- nick: leaverite -> wa5qjh 05:16:22 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 05:18:13 yunfan: it has not been updated, but I think it's still worth reading 05:27:36 --- quit: groovy2shoes (Quit: Leaving) 05:33:46 Gracana: but i even knew those cpu 05:34:15 isnt it better to explain using x86 or arm 05:37:39 It would be today. 06:00:29 well, it's just a matter of optimization, really, and subroutine threaded has the best ability to do it 06:03:14 for instance, if putting a literal on the stack used 2 ops, i.e. push tos and load literal to tos, and then you did an add on it, i.e. pop to another reg and add it to tos, STC could optimize that to "load literal to another reg, add it to tos" 06:05:03 so the unused registers aren't part of a "register stack" or anything like that, they're used just as sort of "scratch" registers? 06:05:34 yeah 06:05:46 "register stack" tends to be very inefficient 06:06:55 one thing to keep in mind is that there's nothing special about forth, or about c, from the way the cpu is 06:07:12 c uses a lot of stack space too, just differently 06:07:27 and one of it's optimizations is keeping stuff in registers 06:07:32 and forth can do it too 06:07:33 But I suppose it's ultimately the same thing that C does, if I stop to think about it - the data stack is for passing parameters between words/functions, and using spare registers to make the words themselves fast isn't in conflict with that at all 06:10:27 one of the things I've always wanted to try is an "inline everything" for forth 06:10:50 and do whole-program-optimization, try to keep as much in registers as possible? 06:11:01 basically munge all the words all the way down to their assembly code roots 06:11:41 as a "ok, I've got this thing working right, now lets make it fast" 06:13:22 That wouldn't be too difficult, I would think. You'd just have to change the default compilation semantics from "append interpretation semantics" to "postpone the word", right? 06:14:03 although if you wanted to go *all* the way down to assembler, I guess you'd have to do something special 06:18:29 and I guess you'd have to make every word immediate. 06:20:33 well, it's fairly simple, it's similar to debugging a word 06:21:33 I'd just have a word that would read the next word, then recursively debug it till you got to an assembly defined word, then append it's execution semantics, and so on 06:23:19 all I know of "debug it" is SEE 06:30:22 yes 06:30:32 basically, same implementation as SEE 06:30:36 just recursive 06:45:06 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 07:21:36 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 08:55:04 --- quit: DGASAU (Ping timeout: 276 seconds) 09:07:41 --- join: DGASAU (~user@194.31.92.26) joined #forth 09:09:48 --- quit: DGASAU (Write error: Connection reset by peer) 09:10:49 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 10:33:40 --- quit: byteflame (Quit: leaving) 10:33:51 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 10:36:25 --- quit: byteflame (Client Quit) 10:36:35 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 10:38:20 --- quit: byteflame (Client Quit) 10:48:06 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 11:14:09 --- quit: byteflame (Quit: leaving) 11:14:17 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 11:15:01 --- join: MickyW (~MickyW@p57A2F2C4.dip0.t-ipconnect.de) joined #forth 11:26:17 --- quit: byteflame (Quit: leaving) 11:26:25 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 11:30:57 --- quit: karswell (Read error: Connection reset by peer) 11:32:13 --- join: karswell (~user@179.63.114.87.dyn.plus.net) joined #forth 11:33:54 --- quit: gravicappa (Ping timeout: 260 seconds) 11:35:31 --- quit: byteflame (Quit: leaving) 11:35:42 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 11:36:19 --- quit: byteflame (Client Quit) 11:36:29 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 11:38:08 --- quit: byteflame (Client Quit) 11:39:59 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 11:55:35 --- quit: karswell (Remote host closed the connection) 11:56:56 --- join: karswell (~user@179.63.114.87.dyn.plus.net) joined #forth 12:15:06 --- quit: DGASAU (Read error: Connection reset by peer) 12:15:18 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 12:22:10 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 12:24:28 --- quit: fiddlerwoaroof (Client Quit) 12:25:19 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 12:40:11 --- quit: wa5qjh (Ping timeout: 250 seconds) 12:43:22 --- quit: MickyW (Quit: Verlassend/leaving) 12:55:46 --- join: dys (~dys@ip-109-44-0-162.web.vodafone.de) joined #forth 13:22:08 --- join: impomatic_ (~digital_w@host81-129-217-145.range81-129.btcentralplus.com) joined #forth 13:26:19 --- quit: byteflame (Quit: leaving) 13:27:03 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 13:28:24 --- quit: byteflame (Client Quit) 13:28:36 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 13:51:25 --- quit: byteflame (Quit: leaving) 13:51:34 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 13:53:21 --- join: byteflam1 (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 13:54:02 --- quit: byteflam1 (Client Quit) 13:54:14 --- quit: byteflame (Read error: Connection reset by peer) 14:09:24 --- join: wa5qjh (~Thunderbi@203.111.224.54) joined #forth 14:12:02 --- join: byteflame (~byteflame@70-89-65-45-little-rock-ar.hfc.comcastbusiness.net) joined #forth 14:12:12 --- quit: DGASAU (Ping timeout: 244 seconds) 14:13:15 --- join: DGASAU (~user@194.31.92.26) joined #forth 14:32:42 --- quit: byteflame (Ping timeout: 244 seconds) 14:49:08 --- quit: DGASAU (Read error: Connection reset by peer) 14:53:20 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 15:36:24 is there a portable way to test if a word is immediate? 15:37:22 I don't think so 17:16:40 --- quit: DGASAU (Read error: Connection reset by peer) 17:17:25 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 17:37:43 --- join: byteflame (~byteflame@c-71-238-242-230.hsd1.ar.comcast.net) joined #forth 17:51:41 --- quit: byteflame (Ping timeout: 260 seconds) 18:18:25 --- quit: beretta (Ping timeout: 240 seconds) 18:21:42 --- quit: karswell (Quit: ERC (IRC client for Emacs 24.5.1)) 18:27:09 --- join: nal (~nal@adsl-64-237-238-8.prtc.net) joined #forth 18:30:50 --- join: beretta (~beretta@cpe-98-30-146-54.columbus.res.rr.com) joined #forth 18:32:34 --- join: byteflame (~byteflame@c-71-238-242-230.hsd1.ar.comcast.net) joined #forth 18:53:31 --- quit: byteflame (Ping timeout: 260 seconds) 19:05:59 --- quit: DGASAU (Ping timeout: 260 seconds) 19:11:04 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 19:23:11 --- join: karswell (~user@179.63.114.87.dyn.plus.net) joined #forth 19:40:21 --- quit: DGASAU (Read error: Connection reset by peer) 19:40:31 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 19:50:02 https://github.com/ralfdoering/cmsis-svd-fth/blob/master/examples/device-stm32-401.fth this is very cool 19:51:07 example of automated conversion from CMSIS-SVD (cortex microcontroller software interface standard - system view definition) files (XML) to forth word definitions 19:58:53 --- quit: Zarutian (Quit: Zarutian) 20:35:38 --- quit: DGASAU (Ping timeout: 264 seconds) 20:40:34 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 20:45:27 --- join: proteusguy (~proteusgu@183.89.124.141) joined #forth 20:45:27 --- mode: ChanServ set +v proteusguy 20:45:31 --- quit: DGASAU (Ping timeout: 260 seconds) 20:54:50 --- quit: proteusguy (Ping timeout: 264 seconds) 21:32:17 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 21:44:26 --- quit: DGASAU (Ping timeout: 260 seconds) 21:44:39 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 22:22:31 --- join: gravicappa (~gravicapp@h62-133-162-13.static.bashtel.ru) joined #forth 22:39:30 --- join: MickyW (~MickyW@p57A2FC6A.dip0.t-ipconnect.de) joined #forth 22:58:03 is there a way to CREATE without giving a name? like :NONAME, but not? 23:01:13 I don't think there is 23:01:14 --- quit: pointfree (Remote host closed the connection) 23:01:21 it occurs to me that CREATEd words are a lot like closures, but they always have names 23:01:34 It could probably be done in theory but not in a standard way 23:02:46 --- join: pointfree (~pointfree@c-174-62-81-78.hsd1.ca.comcast.net) joined #forth 23:04:45 does redefining a word make the old word's xt invalid in any way? 23:06:21 I guess it shouldn't, since a word can refer to its old definition within itself 23:07:35 it doesn't, it's just impossible to refer to the old definition without the old xt 23:09:16 so I could have a word that internally CREATEs a word with the same name every time, but then immediately gets and returns the xt? 23:09:48 I bet there'd be a lot of duplicated headers though, rather wasteful 23:11:49 not sure... it's been a while since I've experimented with CREATE 23:15:33 --- quit: pointfree (Remote host closed the connection) 23:17:04 --- join: pointfree (~pointfree@c-174-62-81-78.hsd1.ca.comcast.net) joined #forth 23:22:21 --- join: byteflame (~byteflame@50.25.160.41) joined #forth 23:25:11 reepca: As far as I know, (im about to implement a forth) CREATE would deny to create a word which allready exists. 23:26:11 in gforth at least, it just says "redefined " instead of "ok" 23:27:05 --- quit: byteflame (Ping timeout: 244 seconds) 23:27:35 Ah. And it creates a dictinary entry? Well. May be. Depends on how it solves multiple definitions-conflicts, I assume. 23:29:03 reepca. In my implementation there some words, which I call "Hidden". They have a link field (and may high or low level) but no name field. Maybe you could write such a word yourself. 23:29:27 Such a defining word, I meant. 23:29:40 --- quit: wa5qjh (Remote host closed the connection) 23:30:57 Just mimicing CREATE but do not use find, just compile a header, with zero name length. Coarsely spoken. 23:35:04 --- join: wa5qjh (~Thunderbi@203.111.224.54) joined #forth 23:35:27 Forth will create a word which already exists. The old definition will still be in the dictionary and continue to be used by any words which already called it. The new definition will also be in the dictionary and be used by any new words. 23:41:34 --- quit: DocPlatypus (Quit: Leaving) 23:50:07 impomatic: My fault. Youre right. A message may be emitted telling that the definition is not unique but it will be created. 23:50:17 --- join: DocPlatypus (~skquinn@c-73-166-108-48.hsd1.tx.comcast.net) joined #forth 23:59:59 --- log: ended forth/16.07.29