00:00:00 --- log: started forth/18.06.12 00:12:53 --- join: smokeink (~smokeink@185.134.120.54) joined #forth 00:17:19 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 00:33:01 --- join: mtsd (~mtsd@77.110.61.100) joined #forth 00:46:03 --- join: reepca (~user@208.89.170.230) joined #forth 00:46:28 --- join: ncv_ (~neceve@90.192.3.231) joined #forth 00:46:28 --- quit: ncv_ (Changing host) 00:46:28 --- join: ncv_ (~neceve@unaffiliated/neceve) joined #forth 01:05:42 --- quit: karswell_ (Remote host closed the connection) 01:07:33 --- join: karswell_ (~user@cust125-dsl91-135-5.idnet.net) joined #forth 01:23:20 --- quit: smokeink (Remote host closed the connection) 01:24:05 --- join: smokeink (~smokeink@59-125-75-78.HINET-IP.hinet.net) joined #forth 02:13:12 --- quit: koisoke_ (Ping timeout: 240 seconds) 02:13:19 --- join: koisoke (xef4@epilogue.org) joined #forth 02:37:33 zy]x[yz: Well, if you only wanted to use it sparingly, you could have words that selected a stack. While selected, a particular stack would be the implicit operand target. 02:37:52 That solves the software compactness problem, but at the hardware level you'd still have to have muxed data paths, which add delay. 02:38:16 Well, and in a software implementation the decision would have to be made somewhere, which would add execution time. 02:38:27 But it eliminates the code compactness issue completely. 02:39:09 --- quit: pierpal (Quit: Poof) 02:39:26 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 02:40:03 And that decision / muxing would apply whether you were "using" the facility or not. 02:40:24 I tend to dislike such things, that penalize you all the time and only provide occasional benefit. 02:42:00 I've played with hardware stack machine design a good bit (on paper, at least), and sometimes I find that some particular feature would be nice, but would require an extra layer of logic in the more core part of the design (the part you'd regardas the hardware NEXT, say). Extra layer = more prop delay = longer clock cycle, all the time forever. 02:42:13 So it has to be a damn valuable feature in order to be tolerable. 02:42:42 I try to make that part of the system two layers deep. 02:44:33 Since you really can't do anything much in one layer, but you can do a lot in two. And adding a third takes delay from 2 to 3, which takes clock frequency down by 33%. 02:45:32 "Layers" here refers to layers of LUTs (Look Up Tables) in an FPGA. 02:45:37 In between flip flops. 02:46:38 So "two layers" is (flip flop output) -> (combinational only LUT layer) -> (flip-flopped LUT layer) 02:48:02 Back when I used to pour over this stuff LUT combinational delay was a bit under 5ns, so you could think about trying for a 100 MHz clock frequency. 02:48:07 At least in the parts I looked at. 02:54:52 It was easy enough to implement an ALU that did and, or not, xor, 2/, 2*, swap, dup, drop, etc. etc. in two layers. 02:55:16 But then you came to +, -, neg, and other things that involved carry, and that wouldn't happen in two layers. 02:55:29 So suddenly those ops aren't as "fundamental" as the others. 02:56:02 At the software level it's easy to forget that addition is a rather complicated operation and can cost a lot of logic to make happen fast. 02:56:16 That's why there's often special high speed carry chain logic in FPGAs. 02:56:38 --- quit: ncv_ (Remote host closed the connection) 02:56:56 --- join: ncv_ (~neceve@2a02:c7d:c5c9:a900:c1c7:50c:8461:8572) joined #forth 02:56:56 --- quit: ncv_ (Changing host) 02:56:56 --- join: ncv_ (~neceve@unaffiliated/neceve) joined #forth 02:57:47 Sometimes I would think about designs that had those carry-using words pop the stack into a special carry chain ALU, with the idea that you'd fetch the result later. 02:58:28 So you'd pop the operands into that unit, and then do other operations you needed on your main fast unit, and then when you knew you'd waited long enough for the carry op to be done you'd have a word to pull that result onto the stack. 02:59:18 --- quit: dys (Ping timeout: 248 seconds) 02:59:50 Similar with external memory access - you'd pop the address for a memory read into a memory unit, and then carry on with other business and only later pull the result to the stack. 02:59:57 So @ got split into two fast instructions. 03:00:23 --- join: dys (~dys@tmo-101-87.customers.d1-online.com) joined #forth 03:00:27 ! was more forgiving, since you could just pop address and data into the memory unit and you were done, even though the memory unit would take a while to finish. 03:00:55 I usually called those [@ and @]. 03:01:32 And I left it up to me the programmer to make sure I put enough stuff in between them. 03:02:26 Or would have, if I'd ever gotten one of these actually built. :-) 03:03:44 But anyway, if I made the clock cycle long enough for + to FINISH in one instruction cycle, it just killed my potential performance. 03:05:44 Modern CPUs devote a lot of hardware to making + fast. It seemed more Forthy to me to ask the programmer to understand that + took time, and instead devote that logic to increasing core count. 03:08:19 Bottom line, though - if you have a CPU that makes results of + instantly available, you are paying for that convenience, either in CPU frequency or core count. TNSTAAFL. 03:12:49 You could have a design that had a high clock frequency but blocked for a few cycles on +, @, etc. But even then you've paid a *small* price by missing some work opportunities. 03:13:24 And at least a bit of hardware is required to implement that block. 03:15:00 A related issue here (sorry to babble this morning - feel free to TLDR me) is that +1 is required in stepping to the next instruction. 03:15:37 I developed a trick that used a pseudo-random shift generator to get a one-fast-cycle increment to the next value. 03:16:15 That caused successive values to be spread out all over numerical space. To use it you'd have the compiler emulate that shift register in software, and you'd store your successive program cells accordingly. 03:17:04 Those shift registers will cover all of your values 1-2^N without repetition - the only cost is that you never get 0. 03:17:11 --- quit: smokeink (Ping timeout: 260 seconds) 03:18:27 But it was an eye-opener for me - even FETCHING SEQUENTIAL MEMORY LOCATIONS has a high (and avoidable) cost associated with it. And yet EVERY PROCESSOR does it that way. 03:25:06 Of course that would make fetching a cache line of instructions effectively impossible. I was thinking in terms of fetching from internal FPGA block RAM, where you have no cache. 03:25:52 ja, linear feedback shift registers are efficient only for strictly sequencial stuff 03:25:52 as soon as there is any random access, the adder will be faster 03:26:04 Absolutely. 03:26:19 So you'd want to use absolute branching. 03:26:30 Relative branching would be a nightmare. 03:27:03 Compiler could implement relative branching, but at the hardware level it would need to be absolute. 03:27:45 A good cache solves the problem without costing you that relative capability. 03:28:36 Well, I guess it semi-solves the problem. Solves the external memory access time problem, but you still have that logic inside devoted to +1'ing your program counter really fast. 03:41:28 I guess I better got to work, guys - sorry again for the novel. :-| Guess the caffeine just started to seep into my skull. Cheers... 03:45:00 --- quit: dave0 (Ping timeout: 244 seconds) 03:47:46 --- quit: ThirtyOne32nds (Ping timeout: 268 seconds) 04:25:24 --- quit: pierpal (Ping timeout: 255 seconds) 04:42:57 --- quit: WilhelmVonWeiner (Ping timeout: 255 seconds) 05:05:08 --- quit: karswell_ (Remote host closed the connection) 05:06:16 --- join: karswell_ (~user@cust125-dsl91-135-5.idnet.net) joined #forth 05:36:30 --- quit: Zarutian (Read error: Connection reset by peer) 05:36:38 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 05:51:44 --- nick: Zarutian_2 -> Zarutian 05:53:56 --- join: ThirtyOne32nds (~rtmanpage@132.sub-174-204-10.myvzw.com) joined #forth 06:06:57 --- join: smokeink (~smokeink@59-125-75-78.HINET-IP.hinet.net) joined #forth 06:07:50 --- quit: mtsd (Remote host closed the connection) 06:42:44 --- quit: dys (Ping timeout: 264 seconds) 07:28:56 --- join: dys (~dys@tmo-101-87.customers.d1-online.com) joined #forth 07:29:46 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 07:34:49 --- quit: pierpal (Remote host closed the connection) 07:41:47 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 08:14:55 --- join: TCZ (~Johnny@ip-91.189.219.193.skyware.pl) joined #forth 08:34:32 --- quit: smokeink (Ping timeout: 268 seconds) 08:59:00 --- quit: TCZ (Quit: Leaving) 09:09:01 --- quit: tadni (Read error: Connection reset by peer) 09:09:02 --- quit: pointfree1 (Remote host closed the connection) 09:09:02 --- quit: M-jimt (Read error: Connection reset by peer) 09:09:08 --- quit: bb010g (Remote host closed the connection) 09:39:27 --- join: bb010g (bb010gmatr@gateway/shell/matrix.org/x-cvilazdvouostorp) joined #forth 11:07:26 James Bowman just launched a nifty new project (firmware written in MyForth) https://www.crowdsupply.com/excamera/spidriver 11:23:57 --- quit: ncv_ (Ping timeout: 276 seconds) 11:31:07 --- join: TCZ (~Johnny@ip-91.189.219.193.skyware.pl) joined #forth 11:45:04 --- quit: pierpal (Quit: Poof) 11:45:22 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 12:13:38 --- join: Keshl_ (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 12:13:52 --- quit: Keshl (Read error: Connection reset by peer) 12:30:41 --- nick: Keshl_ -> Keshl 12:41:29 --- quit: pierpal (Quit: Poof) 12:41:46 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 12:57:18 --- quit: karswell_ (Read error: No route to host) 13:04:53 --- quit: TCZ (Quit: Leaving) 13:05:54 --- quit: pierpal (Read error: Connection reset by peer) 13:16:44 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 13:49:53 --- quit: ecraven (Quit: bye) 13:50:12 --- join: ecraven (ecraven@www.nexoid.at) joined #forth 13:50:41 --- quit: bb010g (Read error: Connection reset by peer) 14:13:01 --- join: bb010g (bb010gmatr@gateway/shell/matrix.org/x-skvojbqkvkwvlhjx) joined #forth 14:15:50 --- join: dave0 (~dave@207.213.dsl.syd.iprimus.net.au) joined #forth 14:15:54 hi 14:43:50 --- join: pierpa (57100917@gateway/web/freenode/ip.87.16.9.23) joined #forth 15:00:08 --- quit: dys (Ping timeout: 264 seconds) 16:16:55 --- quit: bb010g (Write error: Connection reset by peer) 16:28:56 --- join: WilhelmVonWeiner (dch@ny1.hashbang.sh) joined #forth 16:39:37 --- join: bb010g (bb010gmatr@gateway/shell/matrix.org/x-itkmnswltoxikxrr) joined #forth 17:01:50 --- quit: dddddd (Remote host closed the connection) 17:33:47 --- join: pointfree1 (pointfreem@gateway/shell/matrix.org/x-kvkcqusjsjtnqgqr) joined #forth 17:33:47 --- join: M-jimt (jimtmatrix@gateway/shell/matrix.org/x-rbthefgxgqjevxlh) joined #forth 17:33:47 --- join: tadni (tadnimatri@gateway/shell/matrix.org/x-tifwofbopkhdsnhl) joined #forth 17:34:20 Hi Dave. 17:59:57 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 19:55:10 --- quit: pierpa (Quit: Page closed) 20:23:59 --- quit: pierpal (Quit: Poof) 20:24:15 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 20:29:45 hi KipIngram 20:30:10 my friend dropped by, we watched a movie "blown away" with tommy lee jones 20:35:38 ima cook some lunch and have a nap 21:13:10 --- join: TheBlueWizard (60f083f3@gateway/web/freenode/ip.96.240.131.243) joined #forth 21:28:20 --- part: TheBlueWizard left #forth 21:29:30 still cooking lunch :-) 21:30:02 wow time flew.. wasn't cooking the whole time 21:30:13 dave0: where are you ? if you were having lunch, then you must not in europe and us 21:30:41 australia! 21:30:50 throw another shrimp on the barbie! 21:30:55 ah, good, west or east? 21:31:01 it's a late lunch... it's 2:30pm 21:31:14 east.. i live in wollongong, south of sydney 21:31:35 wow, i knew that univercity is very famous 21:32:12 i think they ported unix back in the 70's 21:32:36 my professor ian piper knew his stuff 21:36:33 do you have plan to Port Augusta? 21:37:14 me? nope don't even know it 21:37:37 ok 21:37:54 there's a sundrop farm at Port Augusta, which i am very interesting 22:48:01 i'm gonna go sit in bed and finish reading starting forth and thinking forth books 22:48:08 bbl 22:48:15 one love 23:11:12 --- join: dys (~dys@tmo-107-64.customers.d1-online.com) joined #forth 23:38:44 --- quit: Labu (Quit: WeeChat 2.0.1) 23:53:53 --- join: mtsd (~mtsd@77.110.61.100) joined #forth 23:59:59 --- log: ended forth/18.06.12