00:00:00 --- log: started forth/17.11.28 00:40:53 --- join: dys (~dys@2003:5b:203b:100:6af7:28ff:fe06:801) joined #forth 01:21:35 --- quit: mnemnion (Remote host closed the connection) 03:59:31 --- quit: nighty- (Quit: Disappears in a puff of smoke) 04:19:42 hi 04:19:51 i tried cloning jonesforth and running it, but it segfaults 04:19:59 git clone git://git.annexia.org/git/jonesforth.git 04:20:10 has someone fixed it? 04:21:25 works fine for me, are you running an old git version? 04:21:32 no i just cloned it 04:23:15 https://bpaste.net/show/5ce87241eabf 05:41:34 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 06:05:45 --- quit: DGASAU (Read error: Connection reset by peer) 06:10:07 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 06:30:33 --- quit: DGASAU (Ping timeout: 258 seconds) 06:43:36 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 07:23:32 --- quit: rpcope (Ping timeout: 250 seconds) 07:28:51 --- join: rpcope (~GOTZNC@162.245.217.4) joined #forth 08:02:02 --- join: [1]MrMobius (~MrMobius@c-68-45-74-146.hsd1.pa.comcast.net) joined #forth 08:04:27 --- quit: MrMobius (Ping timeout: 268 seconds) 08:09:43 --- join: MrMobius (~MrMobius@c-68-45-74-146.hsd1.in.comcast.net) joined #forth 08:11:51 --- quit: [1]MrMobius (Ping timeout: 268 seconds) 09:45:23 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:25d3:9372:f43d:6d82) joined #forth 11:10:37 --- join: Labu (~mik@mvice.pck.nerim.net) joined #forth 11:38:07 hi 11:38:47 is there a way to compile a forth-like down to an fpga? i mean, not build a "forth cpu" that'll run forth code, but actually generate a netlist that will do what your forth program would do. 11:39:58 --- join: schuldt (~user@50.232.156.226) joined #forth 11:40:48 technically-correct but not-what-you-want answer: yes. Just compile a forth cpu that will run forth code, then hard-code the forth instructions. 11:41:28 (a bit like "python can be compiled, just put a copy of the interpreter's native code in with the compiled program!") 11:42:25 yeah it's only correct if you ignore 3/4 of the question lol 11:46:26 --- quit: schuldt (Quit: ERC (IRC client for Emacs 27.0.50)) 11:47:56 How are you defining "not build a forth cpu"? I realize that's probably not a technical requirement of the "must not be equivalent in some way to a forth cpu" form, more of an implementation goal, but it's hard to make statements about mushy stuff like that. 11:47:57 --- quit: bedah (Ping timeout: 258 seconds) 11:50:00 i'm not sure how to answer this other than "it's kind of obvious" but that would be snarky, sorry 11:51:16 --- join: schuldt (~user@50.232.156.226) joined #forth 11:57:33 the obvious definition to me is "don't produce something equivalent in functionality to a forth cpu", but if you want to be able to compile any arbitrary sequence of forth instructions to have the same functionality as if they were executed by a forth cpu, I don't see how that's possible - you will, by definition, have to compile something equivalent in functionality at some point. Example: suppose I compile a forth program that only 11:57:34 gets an instruction from somewhere, puts it in memory right before a return instruction, and calls it, then loops. That must be compiled to something equivalent to a forth cpu. 11:59:25 if the definition is obvious, it should be easy to provide, right? 11:59:54 --- join: bedah (~bedah@2a02:810d:243f:f584:8a4:19a3:aca:ab7a) joined #forth 12:01:12 maybe you're trying to do too much. i'd start without endless looping, with simple, terminating code that is total. 12:02:39 if your program is only a composition of n-ary functions that return onto the stack, then it seems that should have a very simple, direct even, translation to a netlist 12:02:55 that does seem quite restricted, but then you are saying forth-like. 12:03:06 then again* 12:03:17 when one function pushes n things onto the stack, and other functions use those things as their arguments, then that's equivalent to a wire between those two functions 12:03:45 yeah. i'm mostly considering a total, terminating subset forth when i think about forth 12:03:58 i think that's a neat and useful subset 12:05:59 in that case, yes, it should be possible to never have to produce something equivalent in functionality to a forth cpu (given the whole "no looping" thing). Do you have a plan for finite repitition, or just loop unrolling? 12:07:52 finite repetition is done using a specific "higher oder" net list that takes a cell and repeatedly applies it. I believe this requires state. you could of course auto-unroll (vectorize) these things if you know the amount of loop iterations a priori and you have fpga space. 12:09:08 "cell" there meaning something other than the "forth alias for cpu-word", I assume? 12:10:26 yes. a cell in terms of fpgas means something like a gate or self-contained logical unit. 12:10:41 --- quit: schuldt (Quit: ERC (IRC client for Emacs 27.0.50)) 12:11:03 so an AND gate could be a cell, but an FPU could also be a cell, or a thing that computes the MD5 digest of some data. 12:11:17 i'm not sure if this is strictly correct nomenclature, but it seems to work when i talk to people. 12:11:25 works for me 12:11:35 --- join: schuldt (~user@50.232.156.226) joined #forth 12:14:17 sounds like said forth->fpga compiler would basically be making superinstructions in the literal sense. gforth combines sequences of forth-vm-primitives to remove interpreter overhead, it seems like you're doing it at the hardware level. 12:16:31 --- part: schuldt left #forth 12:19:23 --- join: schuldt (~user@50.232.156.226) joined #forth 12:20:33 I suppose recursion is also not allowed? 12:25:47 --- quit: schuldt (Quit: ERC (IRC client for Emacs 27.0.50)) 12:26:44 --- join: schuldt (~user@50.232.156.226) joined #forth 12:55:55 can anybody else try jonesforth and see if it works or segfaults? 12:56:07 git clone git://git.annexia.org/git/jonesforth.git ; cd jonesforth ; make ; ./jonesforth 12:56:31 rain1: it segfaulted for me, though I also had to first set SHELL because I'm on guixsd and it assumes /bin/bash. 12:56:53 so its not just me! thats good to know 13:02:44 rain1: last I used it earlier this year, it segfaulted 13:03:33 i will have a go fixing it 13:06:37 in the past i was following along but making it 64 bit 13:32:06 reepca: "combines sequences" how? 14:30:33 --- quit: Labu (Ping timeout: 276 seconds) 15:22:36 --- quit: nighty- (Quit: Disappears in a puff of smoke) 16:09:00 cheater, did you figure things out with your fpga question? 16:11:31 can they ever be figured out? 16:11:44 the answer is very much a resounding no 17:49:47 rain1: iirc I had to remove some gcc flags to build jonesforth and not get a segfault. 18:21:14 --- quit: schuldt (Ping timeout: 240 seconds) 18:37:46 --- join: Gromboli (~Gromboli@static-72-88-80-103.bflony.fios.verizon.net) joined #forth 20:11:20 --- quit: tusj (Ping timeout: 240 seconds) 20:14:17 --- join: tusj (~tusj@185.176.244.94) joined #forth 21:04:55 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 21:08:14 --- quit: Gromboli (Quit: Leaving) 21:21:24 cheater: apologies for the delay, by that I mean it sees stuff like "dup * +" would normally be compiled as
in threaded code, and dup would end by running NEXT and going to *. But all of that jumping around has overhead. So they just make a new "primitive" that is just a copy of dup's machine code with the NEXT removed next to a copy of *'s machine code with the NEXT removed next to a copy 21:21:24 of +'s machine code. The entire thing is called a "superinstruction", because it's just a combination of forth instructions, but with the interpreter overhead removed. 21:21:51 and then every time it sees "dup * +" it can replace it with the address of that superinstruction 21:22:00 in gforth, that is 21:34:48 reepca: isnt this mainly done because $NEXT is pretty much: jmp [forth_ip++]; which is highly metamorphic control transferwise, no? 21:37:25 if by that you mean it makes the jumps more predictable, yep 21:41:08 predictability that is required if the processing unit executing the code has long ish pipeline and an hierchical memory system that tries to act as it had unsegmented address space, no? 21:41:59 ¯\_(ツ)_/¯ 21:43:24 that is if you had an in order simple processing unit, say a 6502 and rather limited in size put pretty fast memory, say sram then doing what you described does give enough benefit. 21:43:49 does not give enough* 21:56:56 --- join: proteusguy (~proteus-g@14.207.5.13) joined #forth 21:56:56 --- mode: ChanServ set +v proteusguy 22:47:31 --- join: Labu (~mik@mvice.pck.nerim.net) joined #forth 23:02:04 --- quit: proteus-guy (Ping timeout: 260 seconds) 23:02:41 --- join: proteus-guy (~proteusgu@180.183.141.50) joined #forth 23:59:59 --- log: ended forth/17.11.28