00:00:00 --- log: started forth/16.09.28 00:00:28 --- join: phadthai (mmondor@ginseng.pulsar-zone.net) joined #forth 00:08:16 --- quit: ASau (Ping timeout: 276 seconds) 00:13:43 --- join: John[Lisbeth] (~user@52.165.40.155) joined #forth 00:14:46 --- quit: dys (Ping timeout: 276 seconds) 00:34:46 --- quit: nal2 (Quit: WeeChat 1.4) 00:39:38 significance: "use" specifies a file that contains forth "blocks" (1024 chars each, 16*64) that can be loaded or written to. This was the usual way of using storage in old, small Forth implementations. include/include-file et. al. allow use for newfangled text files, which are far more common practice now except in really constrained environments. 00:57:57 --- join: dys (~dys@2003:5b:203b:100:6af7:28ff:fe06:801) joined #forth 01:06:11 --- quit: M-jimt (Write error: Connection reset by peer) 01:32:05 maybe we should create a smaller standard than ans forth for implementing ans forth 01:36:02 --- join: M-jimt (jimtmatrix@gateway/shell/matrix.org/x-yfrbojapfjrulufn) joined #forth 01:53:31 John[Lisbeth], there's already some good lists of fundamental forth ops for which anything else can be built upon. And standards are useful for two reasons 1) to collaborate in a team, 2) to share code for execution in multiple environments which we don't control. Incredibly few forthers find themselves in either situation and you can't have a generic standard without additional overhead and complexity which goes against the fundamental concepts of 01:53:31 good forth usage. So - hard to make a case for it. 01:55:14 AMD64 and ARM are quite popular `standards' for that purpose ;) . 01:55:37 haha that's about as high level as you're gonna get. 02:00:14 --- quit: M-jimt (K-Lined) 02:29:37 --- quit: mnemnion (Remote host closed the connection) 02:48:12 --- join: M-jimt (jimtmatrix@gateway/shell/matrix.org/x-vxewaumpqeezrtve) joined #forth 02:50:45 --- quit: phadthai (Quit: restart) 02:50:54 --- join: phadthai (mmondor@ginseng.pulsar-zone.net) joined #forth 02:52:13 whre are those lists? 03:10:58 --- quit: nighty (Quit: Disappears in a puff of smoke) 03:11:08 --- nick: DGASAU` -> DGASAU 04:19:08 yunfan, one of the best books is actually not technically about forth. It has a glossary of forth primitives on page 209. Google for Philip Koopman "Stack Computers the New Wave" book. It's available free in pdf. Outstanding book. 04:19:49 --- join: MickyW (~MickyW@p4FE8CC0C.dip0.t-ipconnect.de) joined #forth 04:27:22 There's another book you can get in pdf "ASE: Writing a forth interpreter from scratch" by Pablo de Oliveira that gives a very good foundation implementation although the primitives are scattered about a bit more. 04:27:42 --- join: gordonjcp (~gordonjcp@ilyushin.gjcp.net) joined #forth 04:31:31 You might also find "Forth Programmer's Handbook" by Edward Conklin and Elizabth Rather. I believe it's ANS Forth however. But a good book with implementation details and an indexed list. 04:36:45 Apropos wrinting a FORTH. Does anybody saw popavic during the last two or three weeks? He was about writing one. 04:42:59 Ooops. Was poppavic with double p. 04:45:19 2016-09-25T19:21 on #avr. 04:45:37 MickyW: What do You have in mind? 04:47:01 Just wondering because I didn't see him here for a while. 05:08:49 proteusguy: i have that book 05:09:27 proteusguy: aha, i have ASE too, 05:19:37 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 06:12:55 --- join: rgrinberg (~rgrinberg@24-246-56-85.cable.teksavvy.com) joined #forth 07:27:25 --- join: true-grue (~true-grue@176.14.222.10) joined #forth 07:40:05 yunfan, see you've got what you need already. :) 07:40:50 The Koopman book is my fav. My permanent side project is building an FPGA stack processor that utilizes some of his ideas and my own for a forth-like processor. 08:12:03 --- quit: groovy2shoes (Quit: Leaving) 08:19:09 Whenever I think about stack processors I keep wondering whether superscalar features are worth the price in complexity. 08:20:03 if you could choose between 1 superscalar processor and 4 simple stack processors, which would you pick? 08:22:13 reepca, I think the issue of moving memory around now puts the advantage towards zero (or low) operand stack processors over RISC/CISC models. 08:24:27 The problem is just that the extra stack-manipulating instructions negate a lot of the advantage 08:25:03 "swap" could be seen as just making the next instruction use register #2 instead of #1 08:25:44 That being said, one of the things that really interests me 08:25:53 is the idea of bignums on stack machines 08:26:20 you can't really use bignums on register machines because you can't dynamically index registers 08:26:38 or at least, you have to store each word of the number into the same register each time 08:26:48 so you can't keep the entire number in registers 08:27:16 but with a stack machine, you can keep the entire number on the stack and not have to worry about memory management until your numbers get too big to keep on it 08:27:59 I feel like that would greatly simplify what quite a few people have expressed interest in - a low-level lisp sort of thing, since garbage collection becomes a lot more "optional" when you don't need it for one of your main language features 08:29:34 I wonder if we'll ever see a consumer-level stack processor... 08:40:08 reepca, read Koopmans's book. A lot of that isn't true in actual fact. 08:40:28 I have read it... or at least, skimmed through it in some depth 08:41:43 But I'll re-check what his numbers were for stack-manipulation frequency 08:41:45 I might have mis-remembered 08:42:00 reepca, I think the biggest issue is Intel has too much to lose from going to a stack processor and they are the ones that have the smallest resolution plants. Someone's gonna have to invest in a few billion dollars to build a fabrication lab. Right now stack based own a lot of the embedded/hardened world like space vehicles. 08:44:55 neither duckduckgo nor google are loading... how am I talking to you right now??? 08:45:20 guess I'll just restart network-manager and it'll probably fix itself 08:52:28 --- quit: reepca (Ping timeout: 264 seconds) 08:53:56 --- join: mnemnion (~mnemnion@71.198.73.193) joined #forth 08:54:13 --- join: reepca (~user@std-001.cune.edu) joined #forth 08:54:43 dunno how much of what I sent you saw, my connection seemed to have died 08:57:53 "of all the instructions in the sample, approximately 25% were spent manipulating the stacks". I guess that's not too bad considering that you go from "operand, operand, destination, opcode" for an add to "opcode". 08:58:40 but function calls are incredibly cheap and returns from function calls are most often free. 08:58:52 mhm 09:48:30 --- quit: mnemnion (Remote host closed the connection) 10:05:48 --- nick: eldre_ -> eldre 10:10:14 --- join: mnemnion (~mnemnion@152.179.131.166) joined #forth 10:24:40 --- join: karswell (~user@13.239.113.87.dyn.plus.net) joined #forth 10:53:18 --- quit: crc (Quit: Lost terminal) 10:54:30 --- join: crc (~crc@li125-93.members.linode.com) joined #forth 11:07:25 --- quit: dys (Ping timeout: 272 seconds) 11:15:24 --- join: dys (~dys@ip-109-44-2-17.web.vodafone.de) joined #forth 12:34:02 --- quit: true-grue (Read error: Connection reset by peer) 12:49:07 --- quit: mnemnion (Remote host closed the connection) 13:39:36 --- quit: MickyW (Quit: Verlassend/leaving) 13:41:16 --- join: mnemnion (~mnemnion@152.179.131.166) joined #forth 14:07:30 --- join: ASau (~user@netbsd/developers/asau) joined #forth 14:57:16 --- quit: rgrinberg (Ping timeout: 264 seconds) 14:58:47 --- join: gyxile (~nick@cpc80309-grim18-2-0-cust167.12-3.cable.virginm.net) joined #forth 15:03:44 --- join: nha_ (~nha_@rea75-3-88-190-132-231.fbxo.proxad.net) joined #forth 15:33:11 --- join: Keshl_ (~Purple@24.115.181.94.res-cmts.gld.ptd.net) joined #forth 15:33:26 --- quit: Keshl (Read error: Connection reset by peer) 15:40:49 I wonder if there could already be a forth somewhere within the millions of lines of code of the linux kernel 15:50:47 --- quit: nighty (Remote host closed the connection) 16:24:41 --- join: nal (~nal@adsl-64-237-237-127.prtc.net) joined #forth 16:47:28 --- join: nighty (~nighty@d246113.ppp.asahi-net.or.jp) joined #forth 17:10:14 --- quit: gyxile (Quit: Ex-Chat) 17:12:17 --- quit: mnemnion (Remote host closed the connection) 17:28:02 --- join: mnemnion (~mnemnion@71.198.73.193) joined #forth 17:31:36 --- quit: mnemnion (Remote host closed the connection) 17:31:51 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:ccf5:9a57:3615:9f7c) joined #forth 17:49:26 --- join: zy]x[yz (~corey@71.59.19.88) joined #forth 17:58:20 --- join: rgrinberg (~rgrinberg@206-248-190-144.dsl.teksavvy.com) joined #forth 18:32:40 --- quit: rgrinberg (Ping timeout: 244 seconds) 19:32:07 --- join: rgrinberg (~rgrinberg@24-246-56-85.cable.teksavvy.com) joined #forth 20:18:36 So I was reading about Jeff Fox's aha Forth because I am planning a similar compile-at-edit-time approach. http://www.ultratechnology.com/aha.htm http://www.ultratechnology.com/ahatalk.htm http://www.ultratechnology.com/ahasrc.htm 20:20:31 That's when I had the thought: has anyone designed an instruction set around Gray codes? 20:23:41 It would be super simple to encode and decode not only opcodes but also memory addresses if you were to continue into the operands with Gray coded memory addressing. 20:27:55 https://upload.wikimedia.org/wikipedia/commons/c/c1/Binary-reflected_Gray_code_construction.svg 20:34:04 In each column, a block of contiguous 0's would have the opposite meaning to its reflection, a column of contiguous 1's. Decoding and interpreting the instruction would be just a matter of shifting the opcode. 20:35:08 Although... your instruction set would have to be organized as a full binary tree. 20:44:28 --- join: nal1 (~nal@adsl-64-237-237-127.prtc.net) joined #forth 20:47:34 --- quit: nal (Ping timeout: 272 seconds) 20:47:34 --- quit: karswell (Ping timeout: 272 seconds) 20:48:28 --- part: John[Lisbeth] left #forth 20:48:52 --- join: karswell (~user@13.239.113.87.dyn.plus.net) joined #forth 20:50:44 --- quit: M-jimt (Ping timeout: 272 seconds) 21:28:49 dangit pointfree, I already have a ton of homework late 21:29:04 and now here you are filling my head with distractions and heretical "interesting stuff" 21:32:34 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 22:01:23 --- quit: rgrinberg (Ping timeout: 244 seconds) 22:14:09 --- quit: karswell (Remote host closed the connection) 22:15:08 --- join: karswell (~user@13.239.113.87.dyn.plus.net) joined #forth 22:21:57 --- join: M-jimt (jimtmatrix@gateway/shell/matrix.org/x-axxrmicsvdkeuvrq) joined #forth 22:24:28 proteusguy: yes, i have quickly reviewed the ASE. its very precise, that i need some detail expand version, but its ok, i will check the code of youforth 22:24:43 which as i knew recommend by someone in this channel 23:05:36 pointfree: i found your schedule for euroforth 2016. you will talk about RNN, i am interesting of learning neutual network, but i might lack of math knowledges, any recomendation for reading book 23:14:07 yunfan: it's mostly just arithmetic 23:14:22 there's very little maths in computing 23:16:14 gordonjcp: any recommandation for reading? 23:17:24 yunfan: I wasn't at euroforth 2016. My real name Andreas Wagner. The RNN talk was presented by Sergey Baranov. https://wiki.forth-ev.de/doku.php/events:euroforth-2016 although, I did once do some RNN stuff in Forth a while ago. 23:17:30 is* 23:18:19 pointfree: sorry, i have searched a rnn in forth repo of yours, that made me get this mistake 23:20:25 yunfan: this article is quite good -> http://www.wildml.com/2015/09/implementing-a-neural-network-from-scratch/ 23:20:43 I don't know if Forth would be my first choice for implementing a neural network 23:20:55 I'd kind of prefer something with arrays and floating point 23:25:29 gordonjcp: i will use python :d . forth is my favorite lang currently, but not working lang 23:25:41 it's good for some stuff 23:25:45 gordonjcp: also thanks very much for that article. 23:25:49 yunfan: I drive a big old Range Rover 23:26:00 yunfan: it's quite old, and often things go a bit wrong with it 23:26:17 yunfan: I use lots of different tools when I'm repairing it, or even making replacement parts that I can't buy 23:26:48 gordonjcp: why not went to IT industry? so you can buy those things 23:27:13 while it would be nice to do everything with just one tool, it's important to realise that quite often you need a different tool :-) 23:27:16 gordonjcp: That's the article series I used for Forth RNN. I abandoned RNN in favor of (binary) sparse distributed representations for SparseForth. 23:27:31 pointfree: cool, I need to look more into SparseForth 23:27:53 yunfan: there are bits you just can't get, which I've designed replacements for, but that's not the point :-) 23:29:58 yunfan: the point is, while I found a really big hammer was the best thing for getting the retaining pins out of the airbags, it wouldn't be much good for undoing the fiddly little air hoses and a long pointy screwdriver was better for that 23:30:02 gordonjcp: ok, you mean those were created by you, not cause the money 23:30:49 gordonjcp: i knowe you point, and i do agree with it. its just everyone has a prefer or experiences, the more you use it, you more detail you'll get to know. 23:31:00 Forth is pretty damn good for running on stuff where you might not have a fast processor or memory, Python is great where you don't care about that 23:31:05 exactly 23:31:19 I doubt I'd be able to run Python on a 6809 with 16K of RAM 23:31:26 or even if I used the other banked 128K 23:33:41 gordonjcp: of course you can, but you need a special python called micropython, i have flashed it into my esp8266 chip 23:33:46 it works well 23:34:01 the only problem is it can not turn the wifi into sniffer mode 23:34:14 yeah, the ESP8266 is a full-blownn desktop machine 23:34:23 what? 23:34:40 its a wifi oriented mcu 23:35:27 with a 32-bit processor, hundreds of kilobytes of RAM and a couple of megabytes of mass storage 23:36:43 my first work PC that cost a couple of grand wasn't as high spec as that 23:37:16 ok, you beated me, i agree that its a desktop machine from a 1970s viewpoint 23:37:22 1990s 23:37:43 nah 23:38:05 that would have absolutely kicked the arse of even the servers (apart from disk space, but you can buy 64MB SPI flash) at my university in the early 90s 23:39:04 ok, i lost :[ 23:39:18 at the time I had to borrow 2MB of RAM off a mate of mine to try this newfangled Linux shite 23:39:23 4MB of RAM 23:39:39 fucking Finns, do they think we're all running around with 4MB in our desktops? 23:39:41 i heard someone has implement an FPS game on esp8266 at CCC 23:39:54 you could port Doom to it, if you had some sort of display 23:39:56 * gordonjcp -> work 23:58:19 --- join: ASau` (~user@x2f7f025.dyn.telefonica.de) joined #forth 23:59:42 --- quit: ASau (Ping timeout: 244 seconds) 23:59:59 --- log: ended forth/16.09.28