00:00:00 --- log: started forth/19.05.25 01:12:47 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 01:14:21 re 01:28:08 --- join: jpsamaroo_ (~jpsamaroo@2605:a601:a39c:7b00:ead8:7321:f185:d7a5) joined #forth 01:28:20 --- quit: jpsamaroo (Ping timeout: 246 seconds) 02:02:29 --- quit: ashirase (Ping timeout: 245 seconds) 02:09:26 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:12:48 --- join: dys (~dys@tmo-103-36.customers.d1-online.com) joined #forth 03:18:37 --- quit: WilhelmVonWeiner (Quit: Changing server) 03:23:56 --- join: WilhelmVonWeiner (dch@ny1.hashbang.sh) joined #forth 03:27:12 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 03:37:50 siraben: I love your parser generator 03:39:23 challenge: convert it to chain-style RPN like HP used to promote 03:45:28 --- quit: djinni_ (Ping timeout: 252 seconds) 03:45:53 --- join: djinni (~djinni@68.ip-149-56-14.net) joined #forth 03:47:41 --- join: john_metcalf (~digital_w@host109-152-144-112.range109-152.btcentralplus.com) joined #forth 04:15:57 WilhelmVonWeiner: Thanks. 04:17:49 pointfree: what kind of queue operations have you thought of? 04:18:08 I have an idea for a single register that can be swapped with 04:18:42 so you can map, or potentially reduce etc 04:35:46 Is that what a key value store does? http://ix.io/1K13 04:40:56 05:24:48 --- join: grmr (~Zor@80.71.142.121) joined #forth 05:30:03 Hi everybody, I'm writing a Forth brainfuck compiler using gforth, and I'm nonplussed. Code's here: https://paste.isomorphis.me/1nF&ln, running foo (which should be the forth word generated from my brainfuck code) gets me an illegal instruction 05:31:03 https://paste.isomorphis.me/OS7&ln and here you see that "see foo" looks normal, but if I run foo, I get an illegal instruction and the definition "see foo" shows changes. 05:31:21 I see something weird in it, does anyone have any tips ? 05:46:52 --- join: gravicappa (~gravicapp@h178-129-21-185.dyn.bashtel.ru) joined #forth 06:23:16 IMHO "brainfuck" is the first problem. 06:41:09 :) 06:41:43 grmr: I am not seeing the change before and after 06:43:22 what does your right and left words look like? 06:47:34 http://www.pigdog.org/auto/electro_diddle/link/784.html 07:25:44 there's a in the definition of foo the second time I run it 07:26:13 https://paste.isomorphis.me/1nF&ln, definitions of right and left here here 07:27:01 basically, it puts the top of stack back into the cell buffer, moves the index and puts the corresponding cell elements on the stack 07:59:33 grmr: on gforth 0.7.3 (on my freebsd box), "see foo" shows start, not the number, but foo hangs and I havu to kill it with ctrl+c 08:00:55 see http://forth.works/17de33f6da1037a8a0ed3bbbf56d9ed9 08:06:06 --- nick: jpsamaroo_ -> jpsamaroo 08:07:57 weird 08:08:14 I'm on 0.7.3 too 08:26:57 is there a way to debug forth code like this, to see why it hangs ? I'm not familiar at all with Forth tools. 08:33:42 grmr: BTW "1+" and "1-" are predefined. 08:34:48 One recomendation is to test each Word as You write it. 08:37:40 Why don't You define ""BF"" NameSpace: ""Create BF table >order definitions""? And then ""' 1+ Alias +"" and so on? 09:03:00 I dos't know what teols gforth has for debugging 09:03:06 *don't 09:03:11 *tools 09:03:28 my preferred debugger is ." 09:06:09 CORDIC: each word has been tested when writing it, I don't understand your point 09:09:24 grmr: Your ""compile"" is merely ""Alias"ing. 09:11:28 GForth is a plot to create ANS Forth in place of ANS Forth. 09:12:36 GForth is written in C, nuf said!! 09:13:38 oh ok, I see 09:14:15 yeah it is, that's because I didn't know about aliases, and that I was trying to grasp the whole postpone/immediate mechanism. 09:15:51 I'm not exactly sure how that would work because brainfuck doesn't have spaces between the tokens, though. 09:16:58 got any other forths that you'd suggest instead of gforth ? 09:22:23 Lina Forth 09:22:29 --- part: PoppaVic left #forth 09:23:00 grmr: If you have each character of the string sequentially in memory, you can COUNT and EVALUATE 09:23:06 and that was the spaces don't matter 09:25:38 doesn't evaluate require spaces ? 09:25:47 it's not clear from the gforth manual 09:26:18 grmr: I don't have enough experience to recomend any Forth implementation. [[http://utoh.org/3ins4th.html][3 Instruction Forth]] was enlightening to me. 3IF is a Subroutine Threaded Code (STC) implementation. 09:26:39 kinda but it's just 3 instructions to load data into memory 09:27:25 Yes CPU is the Inner Interpreter. 09:27:29 thanks, that sounds interesting. i'm interested in how small you can make a bootstrapped forth 09:31:25 grmr: [[http://yosefk.com/blog/my-history-with-forth-stack-machines.html][My history with Forth & stack machines]]. Perhaps Forth itself is something like Empty Set? 09:32:45 cheers 09:39:29 --- quit: dddddd (Quit: Hasta otra..) 09:39:48 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 10:28:53 --- quit: gravicappa (Ping timeout: 248 seconds) 10:41:58 --- quit: dave0 (Quit: dave's not here) 11:18:22 hmm 11:19:07 does anyone know how I can make a word that, when executed, add a "display this string" into the definition of the current word ? 11:19:16 --- quit: Zarutian (Read error: Connection reset by peer) 11:19:48 basically I'm trying to do something like : foo 500 postpone literal ; immediate, in gforth, but with a string 11:19:50 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 11:27:18 grmr: ""Create Msg1 ," Hello!" : hello Msg1 count type ;""? 11:32:14 --- quit: tabemann (Ping timeout: 252 seconds) 11:32:49 --- join: tabemann (~tabemann@2600:1700:7990:24e0:b944:a349:56b9:12fb) joined #forth 11:35:45 oh yeah, that could do the trick, thanks 11:43:33 damn, found the issue that caused the illegal instructions: array-out-of-bounds >< 12:28:26 finafuckinglly 12:28:37 it works 12:28:41 it was hell 13:30:51 --- quit: grmr (Quit: leaving) 16:51:51 --- join: tbemann (~androirc@2600:380:6618:9279:bbac:2f6c:131c:e13f) joined #forth 16:52:58 --- quit: tbemann (Client Quit) 16:59:13 --- quit: john_metcalf (Ping timeout: 244 seconds) 17:00:39 --- quit: john_cephalopoda (Ping timeout: 258 seconds) 17:02:36 --- nick: moony -> pushpoppeekbop 17:14:06 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:27:47 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 17:28:29 hi 17:56:08 --- quit: tabemann (Ping timeout: 252 seconds) 18:08:48 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth 18:12:25 c[_] Good morning Fortheros 18:16:35 --- quit: Keshl (Read error: Connection reset by peer) 18:20:14 hi rdrop-exit 18:20:27 hi dave0 18:21:34 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 19:02:15 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 19:38:03 --- quit: dave0 (Quit: dave's not here) 19:43:50 --- quit: Croran (Quit: No Ping reply in 180 seconds.) 19:45:05 --- join: Croran (~quassel@2601:601:1801:6dde:802f:5d6e:80f1:8454) joined #forth 19:51:18 rdrop-exit: I have heard of an alternative to TTC that I could use 19:51:41 ITC where the lowest values are not treated as addressed but are treated as opcodes 19:52:40 executed in one big case statement, where the non-opcode case is handled with default: 19:52:56 rather than there being a lookup table 19:54:07 this is what is apparently used by pforth 19:54:41 it does mean that the lowest N number of bytes of memory cannot contain Forth words, but I don't see that as being a real problem 20:10:56 Nice, but IMO if you're after a portable VM, nothing beats SRT over a VM instruction set for simplicity. 20:11:39 --- quit: tabemann (Ping timeout: 245 seconds) 20:12:29 You define a set of opcodes, implement and virtual/emulated machine, put an SRT Forth on it. 20:12:48 * implement a virtual/emulated 20:15:52 The important part is not the Forth running on the VM, you can have yours I can have mine, it's the design of the VM itself. 20:16:27 It would be a stack machine VM well suited to putting Forths on top. 20:19:07 It would be Forth-friendly alternative to the JVM and other similar VMs. 20:20:15 If you prefer ITC you could implement an ITC Forth on the VM, but most likely it would be very slow compared to an SRT/NCI Forth. 20:20:58 Both are already getting a big performance hit just from running on a VM. 20:26:30 In summary, if binary portability (as opposed to source portability) is what your after, I think the simplest approach is to use SRT/NCI on the VM. 20:26:49 * you're after 20:29:05 With the VM itself having a fixed set of fixed width stack machine opcodes. 20:31:43 When I say binary portability, I'm assuming only portability to a VM implementation that uses the same cell-width, 16, 32, or 64 bit. 20:33:48 --- join: gravicappa (~gravicapp@h178-129-21-185.dyn.bashtel.ru) joined #forth 20:35:42 --- join: tabemann (~tabemann@2600:1700:7990:24e0:b944:a349:56b9:12fb) joined #forth 20:37:17 Just to be clear when I mention ITC or SRT/NCI for the threading model, I'm speaking of the model of a Forth running on the VM, not of the VM itself which is just an emulation of machine spec using fixed with opcode tokens (bytecodes or whatever). 20:37:42 * emulation of a machine spec 20:39:40 The instruction set level is what Chuck would refer to as a Machine Forth 20:44:40 an stc/nci forth model on a vm implementing a stack machine works well for me :) 20:45:49 That's what I use for my Forth IDE as well (but it's for host machines not targets). 20:53:42 (and my portability is limited to POSIX compliant host environments) 20:55:46 whereas I combine the Forth level and the VM level, in that the Forth level is not separate from the VM level 20:57:34 the code is TTC, but there are no separate Forth levels and VM levels - the VM runs TTC code, and Forth compiles TTC code that the VM executes 20:58:08 I don't have a separate VM-on-top-of-a-VM being run on the VM which executes TTC code 21:01:31 There has to be a lowest emulated level on which the rest resides, that level is basically the emulated machine spec. 21:01:57 That level is the Machine Forth level of your VM. 21:02:53 yes, there is - it just happens that calls to code running on the VM are compiled as tokens just like opcodes are 21:03:23 It's no different than the JVM, many programming languages other than Java run on the JVM, they don't use Java, they just ride on the JVM. 21:04:14 If you have a portable Forth VM, many different Forths could ride on it, not just your prefered one. 21:04:43 each subroutine has a corresponding token, and it is these tokens that comprise the code that is executed by the VM 21:06:54 the difference the user sees between opcodes and tokens for subroutines is that the opcodes are primitive while the tokens for subroutines result in a return address being pushed and the code address for the subroutine being placed in the IP 21:08:15 I don't think you're grokking that when I say VM I really mean a virtual "machine", there is a dividing line between hardware and software even when the "hardware" is just an emulation. 21:09:13 Any Forth runs on top of a machine, either it's a real machine or its a pretend machine. 21:10:18 it's mainly that the concept of a word is built into the VM, just like the concept of a method is built into the JVM 21:11:26 To port a language onto the JVM, I don't have to write in JAVA, I just have to produce a binary image that the JVM will run. 21:11:59 yes, you could potentially program my VM to run C if you really felt like it 21:13:12 not that that'd be a good idea 21:13:16 as it's not designed to run C 21:13:19 but it'd be possible 21:13:36 It should be designed to run Forths 21:13:53 and it is 21:14:15 It sounds like it's designed to run your particular Forth 21:15:28 How would I run a SRT/NCI Forth on it? 21:16:41 subroutine calls would be just tokens for words - there is no CALL opcode 21:16:50 inlining would definitely be possible though 21:18:00 my Forth doesn't support inlining as written, but if someone were to try to write an inlining Forth on top of the VM they could definitely do it 21:18:39 What does that mean "subroutine calls would be just tokens for words" 21:19:08 rdrop-exit: each word as called from another word is just compiled as the token for that word 21:19:45 That's TTC 21:20:17 the term SRT/NCI implies that here is a CALL opcode 21:21:19 and the difference here is that "CALL" is not necessary 21:21:58 It implies that the inner interpreter (aka address interpreter) is the instruction pointer of the machine its running on, in this case the emulated machine 21:24:18 and in this case the IP is the instruction pointer of the emulated machines, just the calls are handled through special opcodes (like the TRAP instructions used on the 68K machines to implement system calls) 21:26:30 Let's rewind 21:26:53 You have a VM instruction set, yes? 21:26:59 yes 21:27:07 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 21:27:08 How many instructions does it have? 21:27:35 re 21:28:17 56 instructions, including the null instruction 21:28:21 Hi again dave0 21:28:27 hey dave 21:29:28 Ok so if I were to port some software onto your VM, I would only use those 56 instructions 21:30:33 that is definitely possible - your code would be slower, but it could be done 21:31:04 well no 21:31:05 Why would it be slower, those 56 instructions are the machine code of your machine 21:31:19 the relocator would be confused by using literals to contain code addresses 21:31:39 Huh? 21:31:46 rdrop-exit: because you'd have to manually push return addresses onto the return stack 21:32:17 about the relocator 21:32:23 Fine, the point is that there are no lower level instructions then those 56 21:32:49 Therefore all I should need are those 56 21:32:51 the issue is that the relocator assumes that the contents of LIT instructions are data values and not addresses, and thus does not relocate them on loading 21:33:22 unlike BRANCH and 0BRANCH instructions, which it does relocate 21:33:57 I'd have to add another instruction - call it ADDRESS - which is like LIT but specifically marks its contents as an address and thus relocates it on loading 21:34:09 If I follow whatever guidelines are required, I should be able to write anything using those 56 instructions 21:34:45 That's the emulated machine level 21:35:33 (or at least it should be) 21:36:28 e.g. I could write an assembler that generates a binary to run on your VM 21:37:25 I could even hand-code a binary file, and it should run on your VM. 21:37:58 * tabemann wrote an assembler that generates a binary to run on his VM - but it defines a token for each word assembled 21:38:39 But all you needed were those 56 instructions? 21:40:29 (and some guidelines) 21:40:46 if you add an ADDRESS word, yes 21:40:54 Huh? 21:41:13 there are some details, like for instance you'd have to redefine EXECUTE to take an address for a word rather than a token 21:41:41 ADDRESS is a word I mentioned above that would be like LIT but which would relocate the address included on loading 21:42:08 What if I don't need any relocation? 21:42:49 rdrop-exit: relocation is necessary because addresses included in images are relative to the start of the image, not the location the image will be loaded into memory at 21:43:40 as on many platforms one cannot know where the code will be loaded into memory 21:45:42 Ok so I follow your guidelines and lay down code (composed of your 56 instructions) and lay down data also per your guidelines, and I'm in business. 21:46:41 well, 57 instructions - ADDRESS would be needed to implement subroutine calls 21:46:43 I have produced a binary image that I can run on different implementations of your VM. 21:46:50 Ok, 57 21:48:03 So your VM porting spec would contain descriptions of those 57 instructions, and various guidelines, memory maps, whatever. 21:48:25 yes 21:48:30 (for the guy whose porting your VM to a new environment). 21:48:37 * who's 21:50:40 Since th 21:50:44 whoops 21:53:43 So with that anyone could implement they're favorite Forth with their favorite threading model 21:54:12 to run on your VM, or even just write an assembler to produce 21:54:22 target images for your VM to run 21:54:51 to make it actually efficent at doing so, though, some things would need to be changed 21:55:32 Probably those involve making your VM more similar to emulated hardware 21:55:45 e.g. I would need to add a CALL opcode, specifically because as implemented it's roundabout and slow to call an arbitrary address 21:56:37 If you can accomplish what I've just described than you basically have a Forth-friendly analogue of a JVM 21:56:49 likewise I would need to add an EXECUTE-ADDRESS opcode, which would be like CALL, but would take an address off the stack 21:59:44 I think what you'll find is that all the changes you will require all involve making your VM more similar to an actual processor 22:00:50 right now it is like the JVM in that what methods are to JVM words are to it 22:00:55 *to the JVM 22:03:01 A virtual Forth processor would be more "low level" than a virtual Java processor 22:03:31 Less weird overhead and constraints 22:03:41 (I would imagine) 22:04:31 what I've got right now is not nearly as limiting as the JVM is; it's main limitation is that the concept of the word is designed into it 22:04:33 *its 22:05:16 It's been too many years since I read the JVM spec, I don't remember much other than thoroughly disliking it 22:06:19 oh, it's extremely limiting 22:06:33 classes and methods are baked into it 22:06:50 But conceptually a FVM would play a similar role as the JVM does 22:07:08 the kinds of types that are supported natively are baked into it (and not all the kinds of types that exist in Java actually exist in the JVM) 22:07:59 a major criticism of the JVM is not what is baked into it but what is not baked into it - namely that the JVM does not have native support for generic types aside from arrays 22:08:53 another thing about the JVM is the distinction between boxed and unboxed types being fundamental 22:09:02 but yeah 22:09:13 the JVM is a good example of how not to do a VM 22:09:29 Luckily Forth doesn't care about any of those abstractions 22:11:09 --- quit: jedb (Read error: Connection reset by peer) 22:11:20 2 stacks, memory, machine-words, blissful simplicity 22:13:40 Gotta go, Sunday lunch awaits. Keep on Forthin' 22:13:49 --- quit: rdrop-exit (Quit: Lost terminal) 22:14:28 --- join: jedb_ (~jedb@103.57.72.31) joined #forth 23:45:35 --- quit: chunkypuffs (Quit: ZNC 1.7.1 - https://znc.in) 23:45:58 --- join: chunkypuffs (~chunkypuf@static.203.112.216.95.clients.your-server.de) joined #forth 23:48:18 --- quit: chunkypuffs (Remote host closed the connection) 23:49:44 --- join: chunkypuffs (~chunkypuf@2a01:4f9:2b:16d5::1) joined #forth 23:59:59 --- log: ended forth/19.05.25