00:00:00 --- log: started forth/18.09.01 00:27:09 --- join: lonjil (~quassel@2a02:418:6050:ed15:ed15:ed15:e741:32d6) joined #forth 00:31:45 --- quit: lonjil (Ping timeout: 252 seconds) 00:32:43 --- join: lonjil (~quassel@2a02:418:6050:ed15:ed15:ed15:e741:32d6) joined #forth 00:43:24 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 02:05:02 --- quit: ashirase (Ping timeout: 260 seconds) 02:06:58 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:10:23 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth 02:10:23 --- quit: ncv (Changing host) 02:10:23 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 02:49:19 --- quit: Zarutian (Read error: Connection reset by peer) 02:49:39 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 03:02:48 --- quit: pierpal (Ping timeout: 240 seconds) 03:04:36 --- quit: unrznbl[m] (Read error: Connection reset by peer) 03:04:41 --- quit: pointfree[m] (Remote host closed the connection) 03:04:46 --- quit: jimt[m] (Remote host closed the connection) 03:04:46 --- quit: bb010g[m] (Write error: Connection reset by peer) 03:14:03 --- join: pointfree[m] (pointfreem@gateway/shell/matrix.org/x-ocsqwmpcgubsfmgt) joined #forth 03:20:17 --- join: X-Scale (~ARM@83.223.242.66) joined #forth 03:31:02 Researching Forth on EVM 03:32:29 But I had been placed under the impression EVM had two stacks 03:32:36 WilhelmVonWeiner: Ethereum VM? Well it is pretty shittly specified harvard architecture single stack machine with the equiv of volatile work ram and seperate data eeprom 03:33:53 Of course a contract for the EVM is compiled, so a good compiler can compile code that looks and acts and sounds like Forth 03:34:11 But there would be a bunch of overhead sorting the stack. 03:34:13 Bollocks. 03:34:56 plus it has contracts have reentrancy issues as each 'call' to a contract gives it a whole new wram. Plus the data eeprom isnt commited until after the contract has finished running without errors 03:35:29 WilhelmVonWeiner: do not be lured by the siren song of "sufficiently smart compiler" 03:36:00 spefically when such a compiler must become part of your trusted computing base when making contracts. 03:38:51 --- join: pierpal (~pierpal@host60-229-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 03:39:38 I think it is best to write a small Forth VM in Ethereum VM assembler. Use the 'data eeprom' as the memory for the stacks, program and data. 03:41:13 That's what I'm thinking. 03:41:49 --- quit: pierpal (Client Quit) 03:42:08 --- join: pierpal (~pierpal@host60-229-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 03:42:34 --- join: jimt[m] (jimtmatrix@gateway/shell/matrix.org/x-wosfgonobqzglgrl) joined #forth 03:42:34 --- join: bb010g[m] (bb010gmatr@gateway/shell/matrix.org/x-jlaeaoypfeaqkewr) joined #forth 03:42:34 --- join: unrznbl[m] (unrznblmat@gateway/shell/matrix.org/x-xrqkghocqhmtbhhk) joined #forth 03:42:50 Lol. A contract that is a Forth, and then a wealthy Ethereum user can call that contract from their own program. 03:43:56 The most convoluted Forth I've ever thunk 03:44:44 WilhelmVonWeiner: you could have it so that the Forth contract first checks if there is enough gas to at least append the request to an 'event queue' and then run a cycle or two. 03:45:40 btw, I knew about and have put together smart contracts before Ethereum's inventor was a glint in his fathers eye. 03:46:08 Should've told his Father about dial stack machines. 03:46:13 *dual 03:46:29 but such need contract hosts to run. 03:46:40 Dial stack machines are Chuck Moore's attempt at reinventing the telephone. 03:46:53 still a WIP 03:47:38 well, Bitcoin script targets pretty much a dual stack machine, and Vitalik was rumoured to get inspiration from that. 03:50:53 should've just forked Bitcoin and added conditional loops TBQH 03:53:02 --- quit: ncv (Remote host closed the connection) 03:53:08 --- join: ncv (~neceve@90.207.222.160) joined #forth 03:53:08 --- quit: ncv (Changing host) 03:53:08 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 03:56:08 WilhelmVonWeiner: and added the gas checking and not allow contracts to be reentrant (already in callstack! or some such) 04:04:40 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 04:06:48 --- quit: MrMobius (Ping timeout: 240 seconds) 04:06:48 --- nick: [1]MrMobius -> MrMobius 04:47:30 --- quit: lonjil (Ping timeout: 252 seconds) 04:50:57 --- join: epony (~epony@unaffiliated/epony) joined #forth 05:15:38 --- join: lonjil (~quassel@2a02:418:6050:ed15:ed15:ed15:e741:32d6) joined #forth 05:29:49 --- quit: FatalNIX (Changing host) 05:29:49 --- join: FatalNIX (~FatalNIX@unaffiliated/fatalnix) joined #forth 07:47:45 I was looking at the core wordset comparison PDF crc made 07:48:10 FIG Forth is chock-full of words 08:08:11 --- quit: pierpal (Quit: Poof) 08:08:32 --- join: pierpal (~pierpal@host60-229-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 09:31:01 --- quit: dave0 (Quit: dave's not here) 09:32:37 --- join: dave0 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 10:56:48 --- quit: dave9 (Quit: one love) 10:56:56 --- quit: malyn (*.net *.split) 10:56:57 --- quit: ecraven (*.net *.split) 11:02:17 --- join: ecraven (~ecraven@www.nexoid.at) joined #forth 11:02:46 WilhelmVonWeiner: havent looked at that pdf, is eForth in there or? 11:02:54 --- join: malyn (~malyn@unaffiliated/malyn) joined #forth 11:03:41 I forget which one of you guys told me that x86 architecture is a microcode implemented vm on top of something altogether different. Either Zarutian or xy]z[yx I think. 11:03:48 Anyway, found this earlier: 11:03:51 https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf 11:04:08 Those guys actually opened a processor up and instrumented it, and did reverse engineering work on the microcode architecture. 11:05:19 KipIngram: remind me next friday before 17:00 UTC and I can ask a guy that attends the same weekly meeting about this kind of stuff. He worked at Intel. 11:05:42 * Zarutian takes a look at that paper. 11:06:47 Ah, I will put an alarm in my phone. 11:07:04 Just remind you here in channel? 11:07:41 That article says the microcode is in volatile memory, so it's loaded on every processor reset. 11:07:53 That's cool - you couldn't even brick your system by playing around at that level. 11:09:01 I wonder if multiple cores are implemented that way? As separate virtual cores running on one fast underlying layer? 11:09:22 If so that opens the possibility of developing your own "lower resource" core design and winding up with an increased core count. 11:10:03 I bet virtual memory and so on is implemented via microcode too - you could in theory dispense with that and use the microcode resources some other way. 11:10:40 * KipIngram wants a microcoded Forth... 11:13:22 yeah, remind me here 11:14:12 Ok - got it in my calendar. 11:19:02 say, what is it called in Forth or dual stack machine design where NOS and TOS are fed directly to a Full Adder, XOR et ceterata and there is a mux that selects which output is pushed based on opcode? 11:19:35 Hmmm. "Hardcoded operands"? 11:19:47 I think there is a commonly used phrase; thinking. 11:19:59 One of the things that makes Forth so compact. 11:22:00 hardwired operands. I know this trick is used in J1 from excamera. It speeds up execution tremendously as the result is already 'known' 11:23:26 Right. 11:23:46 Basically as soon as the stack "settles" from the last operation, it's already computing ALL POSSIBLE next operations. 11:23:53 yep 11:23:54 All your next instruction really does is select one of those. 11:24:06 Probably not the most power-efficient way to do things, but yeah, for performance it rocks. 11:24:33 I think of that as one of the best features of stack machines. 11:24:47 well, if your space of operators is small, say sixteen or a bit less then it is cost effective. 11:29:12 UM+, &, ^, 1<< and 1+ are operators I have in a dual stack machine hardware description. 11:29:58 (the first one requires a 2-into-1 mux on the NOS or data port of the datastack memory) 11:30:43 what more does one need? specially when the rest are easily synthesizable. 11:31:08 (oh and 1<< should actually be Left Bit Rotate and not just a shift) 11:49:11 --- join: gravicappa (~gravicapp@ppp83-237-161-70.pppoe.mtu-net.ru) joined #forth 11:55:08 That sounds pretty cool. When I was thinking about my hardware Forth processor I was pretty fanatic about not adding layers of logic. Unless you arrange for different instructions to take different amounts of time you pay the extra delay of that layer on every instruction, whether you needed it for that one or not. 11:55:23 I was trying hard to have only two layers of LUTs between flip flop outputs and inputs. 11:56:12 Because you can't do it in just one, and adding a third extends the minimum clock period by order of 50%. 11:56:35 33% whack to your achievable clock rate. 11:57:12 I had a hardware stack, with 32 elements. 11:57:24 Well, I guess it could have had any number. 11:57:37 32's just what I had in mind when I toted up logic element counts. 11:58:06 well, I am a bit of anachronistic in logic and electronics design. I think of the logic in gates and wires that connect them. I do define blocks to simplify. 11:58:41 and frankly I hate both verilog and vhdl 12:03:08 I'm not that different - I think of a LUT (in Spartan 6) as a six-input, two-output "gate" that I can define to be any pair of boolean functions of six inputs that I wish. 12:03:35 I've just never gotten into the "behavioral programming" thing - I think about those "gates" (fancy though they may be), and how they're interconnected. 12:04:01 I think the "new way" encouraged engineers to not think about what they're really creating, sometimes with bad results. 12:04:06 encourages 12:04:40 So I think I'm still looking at it all "essentially" the same way you are. 12:05:12 I'm 55 - by the time the new way came along I was sort of an "old dog" I guess. 12:05:51 --- quit: groovy2shoes (Ping timeout: 252 seconds) 12:06:30 It's easy enough to think about FPGAs that way. What's not particularly easy is to pay a lot of attention to WHERE in the chip you're putting things. I'd like to do that too, but the methods they give you for such "floor planning" are pretty cumbersome, and they don't seem to interested in improving them (the FPGA companies totally encourage the "behavioral" mind-set). 12:07:02 Most of the work they do on their design environments winds up adding abstraction. 12:18:18 --- quit: pointfree[m] (Remote host closed the connection) 12:18:27 --- quit: bb010g[m] (Remote host closed the connection) 12:18:31 --- quit: jimt[m] (Read error: Connection reset by peer) 12:18:32 --- quit: unrznbl[m] (Remote host closed the connection) 12:32:23 --- join: pointfree[m] (pointfreem@gateway/shell/matrix.org/x-xgkviehqxfzbkjfa) joined #forth 12:39:54 KipIngram: yeah, I have been looking for basic bistream format for any FPGA and never found any. Why am I looking for it? Too much damn abstraction that I do not need in their tools and their tools seem to use random number generators for some placements. Monte Carlo fitting perhaps? 12:40:34 I liked the logic cell layout and defnition ATmel had with their now discontinued FPGAs 12:55:46 Zarutian: there are some people on ##openfpga reversing FPGAs bitstreams formats 13:03:23 --- join: jimt[m] (jimtmatrix@gateway/shell/matrix.org/x-cvuknkysspzzcmzy) joined #forth 13:03:23 --- join: unrznbl[m] (unrznblmat@gateway/shell/matrix.org/x-xupbbuykiwzgkhuh) joined #forth 13:03:23 --- join: bb010g[m] (bb010gmatr@gateway/shell/matrix.org/x-vkniwhfljdeizbnb) joined #forth 13:51:01 --- quit: gravicappa (Ping timeout: 246 seconds) 14:13:10 --- join: john_metcalf (~digital_w@host86-133-49-189.range86-133.btcentralplus.com) joined #forth 14:32:54 --- quit: epony (Ping timeout: 245 seconds) 14:43:33 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 14:46:28 --- quit: MrMobius (Ping timeout: 240 seconds) 14:46:28 --- nick: [1]MrMobius -> MrMobius 14:54:33 ##openfpga is great 14:55:05 can't wait for the PSoC5LP to be finished 14:55:43 also Zarutian: http://forthworks.com/forth 14:56:00 WilhelmVonWeiner: that is crc's site, no? 14:56:26 Yep 14:56:31 more than just Retro 15:12:00 --- join: epony (~epony@unaffiliated/epony) joined #forth 16:06:09 WilhelmVonWeiner: re that FPGA, isnt that the part used in Ice something? 16:19:45 don't think they're at all related 16:19:51 PSoC5LP is cypress 16:20:07 ice40 is lattice(?) 16:20:40 iCE40HX1-8K 17:15:17 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 17:28:03 --- join: siraben (~user@unaffiliated/siraben) joined #forth 18:36:11 --- quit: dddddd (Remote host closed the connection) 18:37:37 --- quit: nighty- (Quit: Disappears in a puff of smoke) 19:28:45 --- quit: siraben (Quit: ERC (IRC client for Emacs 26.1)) 19:33:30 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 20:58:11 --- quit: ncv (Remote host closed the connection) 23:39:48 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 23:40:48 hi 23:59:59 --- log: ended forth/18.09.01