00:00:00 --- log: started forth/17.01.02 01:12:44 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 01:17:38 --- quit: mnemnia (Remote host closed the connection) 01:46:41 --- quit: dzho (Ping timeout: 256 seconds) 01:47:09 --- join: dzho (~dzho@unaffiliated/dzho) joined #forth 03:05:11 --- join: Mat4 (~claude4@ip5b40bc14.dynamic.kabel-deutschland.de) joined #forth 03:09:29 --- quit: Mat4 (Client Quit) 04:32:29 --- join: true-grue (~true-grue@176.14.222.10) joined #forth 06:21:10 --- quit: proteus-guy (Remote host closed the connection) 06:21:33 --- join: proteus-guy (~proteusgu@180.183.13.253) joined #forth 06:32:20 --- quit: proteus-guy (Remote host closed the connection) 06:32:27 --- quit: Keshl__ (Read error: Connection reset by peer) 06:32:43 --- join: Keshl__ (~Purple@24.115.181.94.res-cmts.gld.ptd.net) joined #forth 06:33:26 --- join: proteus-guy (~proteusgu@180.183.13.253) joined #forth 07:40:42 --- join: mnemnion (~mnemnion@71.198.73.193) joined #forth 07:44:48 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 07:45:23 --- quit: mnemnion (Ping timeout: 256 seconds) 08:21:29 --- quit: proteus-guy (Remote host closed the connection) 08:22:18 --- join: proteus-guy (~proteusgu@180.183.13.253) joined #forth 08:33:15 --- join: mnemnion (~mnemnion@71.198.73.193) joined #forth 08:37:31 --- quit: mnemnion (Ping timeout: 245 seconds) 08:40:18 --- join: reepca (~user@208.89.170.250) joined #forth 08:43:58 So I've got a scenario where I want to get an array of xts, but the array needs to be built up as the words are defined, and even worse, I don't know how many there will be in advance. I was thinking of building up the array from the end of the dictionary and then copying it to HERE once it's finished, but am not sure about the consequences of working with un-ALLOTed memory. 08:48:31 although the simplest way would probably be to say "screw portability" and try to figure out how to manually access the dictionary linked list so I can get the last n xts... 08:53:23 reepca, Place them in PAD! %) 08:53:43 ... but what if PAD is too small? 08:54:34 : PAD HERE 340 + ; ( or so) 08:55:08 what comes after PAD? 08:55:19 I dunno 08:55:33 Well I have seen a number of forthers who use PAD as a generic memory buffer :) 08:55:44 been awhile since I looked at a diagram of the dictionary 08:57:20 --- join: Mat4 (~claude4@ip5b40bc14.dynamic.kabel-deutschland.de) joined #forth 08:57:42 pointfree: and if PAD is just a pointer to a region of un-ALLOTed memory, why not go all the way and work from the end? 08:58:44 hello 08:58:57 The older copy of Starting Forth has a diagram of the memory map of a typical forth system (multitasking and not multitasking). This may have been removed in the newer edition. As far as I a can remember the PAD is in the middle of the memory map with data stack and return stack on the extreme ends. 08:59:16 You may also place the data in the blocks memory buffer. If your Forth supports good old blocks, of course :) 09:00:34 I doubt that pad start in the middle of available memory in most systems 09:01:29 anyhow, would such usage not be predestinated for a linked list ? 09:02:52 the problem is that I need literally random index-based access to the xts 09:03:14 (as in random is in the problem statement) 09:03:46 which I admittedly *could* do with a list, but I cringe at it 09:04:18 Or you may create a special word HEAP of #HEAP size (allot). And then implement simple garbage collection algorithm which will work with the heap. 09:04:20 that would involve some implementation complexity 09:05:25 ftp://fremontoktoberfest.com/programming/Forth/LeoBrodie-StartingForth/LeoBrodie-StartingForth-09-Under%20The%20Hood.pdf#page=17 09:06:47 (I've got 239 copies of 1981 "Starting Forth" in my apartment) 09:06:47 reepca, you can use the block buffer if existent 09:08:00 Could you comma compile an array of xt's? 09:08:08 Like a lookup table? 09:09:31 It'd involve manually re-stating the names of all of the words involved, which I'm trying to avoid 09:09:33 Oh. "I don't know how many there will be in advance" 09:11:27 Would it not make sense to just build up the array from HERE UNUSED + ? 09:14:09 pointfree, I still have the book here at my workplace. It was one of my first books about programming which I readed as child 09:14:19 In C they they just write like this: 09:14:20 xt_t xt_table[MAX_XT_TABLE_SIZE]; 09:14:32 And you can do the same. 09:15:21 just reserving some dictionary space if possible 09:17:01 this require some pointer management because the array size is not static 09:18:48 however reserving chains of memory blocks (probably of different size) is maybe a good tradeof 09:19:42 Like a resizable array implementation that doesn't free the old buffer but just links up a new buffer instead? So I get something like a logarithmic random access time? 09:19:57 reepca: The array would grow backwards with "UNUSED HERE +" ? So you would issue CREATE the header when you are done building the array instead of when you start? 09:20:05 Or you can allocate the data right in the stack memory. It's quite popular technique in PostScript. 09:20:52 pointfree: I was thinking I would copy the array to HERE after it was constructed 09:21:08 reepca, yes 09:22:29 the most prominent method of implementation for this are Obasaki lists to my knowledge 09:23:03 Okasaki? 09:23:17 yes, sorry, type error 09:23:38 The author of the famous book on func. data structures. 09:26:46 --- join: mnemnion (~mnemnion@71.198.73.193) joined #forth 09:41:58 here is a paper from him describing his method: https://www.cs.oberlin.edu/~jwalker/refs/fpca95.ps 09:44:11 it can be that someone has implemented it in Forth already 09:45:34 --- join: neceve (~ncv@79.115.225.255) joined #forth 09:45:34 --- quit: neceve (Changing host) 09:45:34 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth 09:52:36 --- quit: ovf (Ping timeout: 258 seconds) 09:52:43 --- quit: pointfree (Ping timeout: 260 seconds) 09:52:59 --- quit: crc (Ping timeout: 240 seconds) 09:54:39 --- quit: Mat4 (Quit: Leaving) 09:57:30 --- join: crc (uid2647@gateway/web/irccloud.com/x-tawcpucxxwkqtyym) joined #forth 09:58:02 --- quit: neceve (Quit: Konversation terminated!) 09:58:07 --- join: pointfree (uid204397@gateway/web/irccloud.com/x-ebfdeuhpggtorxsd) joined #forth 09:59:20 --- join: ovf (sid19068@gateway/web/irccloud.com/x-zclamwciloachcqb) joined #forth 10:04:39 --- join: Mat4 (~claude4@ip5b40bc14.dynamic.kabel-deutschland.de) joined #forth 10:34:55 --- quit: gravicappa (Remote host closed the connection) 10:53:30 --- quit: Mat4 (Quit: Leaving) 11:40:46 --- quit: dograt (Quit: No Ping reply in 180 seconds.) 11:42:05 --- join: dograt (~dograt@unaffiliated/dograt) joined #forth 11:43:08 --- join: John[Lisbeth] (~user@173-160-167-234-Washington.hfc.comcastbusiness.net) joined #forth 11:48:50 --- join: mnemnia (~mnemnion@2601:643:8102:7c95:54d8:b9a3:a967:8ca6) joined #forth 11:52:12 --- quit: mnemnion (Ping timeout: 252 seconds) 14:10:57 I wish gForth would let me factor out slices of code containing loop indexes without POSTPONE or ]] ... [[ everywhere. 14:11:31 A word should function as an abbreviation anywhere I want it to. 14:20:07 My javascript forth is becoming alot more like factor/lisp 14:23:15 --- quit: true-grue (Read error: Connection reset by peer) 14:27:19 pointfree: how would that even be implemented? It would have to either cause everything that uses that word to be inlined all the way up or somehow know how many calls are going to be between the word that uses the loop construct and itself. 14:28:12 I suppose if it didn't use the return stack for holding indices, it wouldn't be an issue. Does the standard require the return stack to be used for that? 14:35:39 reepca: afaik FreeForth doesn't even require control structures to be inside a colon definition because it's always compiling. 14:49:29 how does that work, always compiling? 14:58:15 reepca: FreeForth uses anonymous definitions everywhere. No STATE, but still interactive. However, expressions written interactively must also be terminated by a ; 14:58:23 e.g: 14:58:35 3 4 + . ; 14:59:07 --- quit: John[Lisbeth] (Ping timeout: 248 seconds) 15:02:52 how does it reclaim the memory used for the anonymous definitions? 15:03:18 Are they put together in a separate area of memory than HERE? 15:06:43 Not sure, but I would have it reclaimed by ; similar to the parameter stack. 15:15:07 what do you mean by that? And how does it make sure not to interfere with regular dictionary memory usage? For example, if the anonymous definition did some ALLOTing? 15:44:00 --- join: Mat4 (~claude4@ip5b40bc14.dynamic.kabel-deutschland.de) joined #forth 15:46:47 reepca, anonymous definations do not need to be permanent stored in the dictionary. Because every source line is always compiled new compiled ones can simply override the prior compiled code 15:48:01 new dictionary memory need only be allocated if the prior compiled code is declared as colon definition 15:49:40 I work on adding this principle to Retroforth at moment 15:49:56 (alias Retro) 15:53:40 the same applies to data allocations, there must be named. New compiled code then override the dictionary memory after the allocated word until the next named defination is created 15:54:25 --- quit: mnemnia (Remote host closed the connection) 16:02:14 as side note: I will add the rule that the carriage return character execute prior compiled code. HERE is then subtracted by the number of bytes compiled so that after execution the anonymous code sequence get overridden 16:03:46 this way at runtime executed expressions do not need to be terminated with a colon 16:03:47 Mat4: Perhaps that might be better than using ; to execute. 16:04:03 I think so 16:04:43 named definitions are just signaled with a colon as prefix, eg: 16:04:55 instead of - 16:05:11 : multi dup * ; 16:05:26 dup * :multi + 16:06:26 I think that's even more natural because a postfix way of defining words 16:06:27 --- join: mnemnion (~mnemnion@71.198.73.193) joined #forth 16:08:15 --- join: John[Lisbeth] (~user@173-160-167-234-Washington.hfc.comcastbusiness.net) joined #forth 16:09:47 the other feature I want to implement is differentiating between scalar, tuple and array parameters. For this I think to experiment with 3 dictionaries for each case 16:10:47 1 2 3 4 5 6 7; 3 + 16:11:22 should be compiled as vector addition 16:12:10 what does it result in? 16:13:44 4 5 6 7 8 9 10 <- tos 16:13:55 you need a function like map 16:14:07 of course 16:14:25 To map you need a list or an array/tree/etc 16:14:38 so first you must implement the datastructure you want to use map with 16:14:56 I sugguest you use dynamic arrays [like this ] 16:15:07 similarly to hwo factor does 16:15:18 I thought about doing that postfix naming in an experiment I called Foot-in-Forth. One possible problem is that you need the expression to flow in two directions to confine the expression into a word on both ends and distinguish a definition from interpreted code. There's probably a solution or a way for me to not need to care about this problem. Machine 16:15:18 Forth and ColorForth words have multiple semicolons. 16:16:52 I just need some kind of stack tagging to differentiate the data format for each stack element 16:19:20 that's also something which should happen at edit time. Because Retro already compile (or execute) tokens at typing I think that's an easy addition 16:19:34 (weill I hope so) 16:19:39 ^well 16:21:23 pointfree, the colon prefix just create a dictionary header for the prior compiled code and adjust HERE. That's a solution for this 16:23:08 otherwise I would require multiple semicolon definations like Colorforth 16:23:30 the drawbreak is, that formating now matters 16:23:41 ^formatting 16:24:43 because a carriage return have a language relevant function (code execution) 16:25:55 Retro just handle the space character identical to carriage return 16:26:37 at default. This would not be the case any more with my changes 16:27:08 ciao 16:27:12 --- quit: Mat4 (Quit: Leaving) 16:45:26 but like, if I typed 0 , 0 , 0 , ; it would either overwrite the anonymous definition as it gets executed (possibly overwriting past where it currently is executing!) or, if HERE is past where the anonymous definition ends, it wouldn't be clear how to reclaim that memory since there's already more alloted past it. 17:03:00 --- quit: John[Lisbeth] (Ping timeout: 256 seconds) 17:30:41 --- quit: proteusguy (Ping timeout: 258 seconds) 17:32:42 --- join: proteusguy (~proteus-g@2405:9800:b400:495c:4a51:b7ff:fe38:d966) joined #forth 17:32:42 --- mode: ChanServ set +v proteusguy 18:07:52 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth 18:31:19 --- join: John[Lisbeth] (~user@2601:601:8f01:a6a0:bdb7:f502:974f:9782) joined #forth 18:39:41 --- quit: reepca (Ping timeout: 258 seconds) 19:15:53 --- quit: Zarutian (Quit: Zarutian) 19:46:32 --- quit: groovy2shoes (Quit: Leaving) 19:48:25 --- join: karswell` (~user@252.135.46.217.dyn.plus.net) joined #forth 19:52:41 --- nick: karswell` -> karswell 19:54:27 --- join: ricky_ricardo (~rickyrica@2601:240:4203:ecb0:974:2e1c:6303:3be8) joined #forth 19:57:55 --- quit: neceve (Ping timeout: 258 seconds) 20:00:46 --- join: neceve (~ncv@79.115.225.255) joined #forth 20:00:46 --- quit: neceve (Changing host) 20:00:46 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth 20:01:02 Anyone have any examples of a forth targeting a RISC store & forward architecture CPU? I'm playing around with the RISC-V chipset which seems quite interesting but also challenging to implement a stack based language. 20:20:09 --- quit: ricky_ricardo (Ping timeout: 258 seconds) 20:43:45 proteus-guy: What device is that? 20:47:34 --- join: gravicappa (~gravicapp@h62-133-162-72.static.bashtel.ru) joined #forth 21:03:10 --- quit: neceve (Quit: Konversation terminated!) 21:33:45 proteus-guy: Sam Falvo is doing a Forth for the RISC-V https://kestrelcomputer.github.io/kestrel/ 22:41:45 --- join: mat4 (~Claude@ip5b4104d5.dynamic.kabel-deutschland.de) joined #forth 22:45:31 reepca: this must be handled differently (principal possible with two independent memory regions, one for data and one for program code) 22:45:45 --- quit: mat4 (Client Quit) 22:46:10 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth 22:53:48 --- part: PoppaVic left #forth 23:11:23 --- join: mtsd (4d6e3d64@gateway/web/freenode/ip.77.110.61.100) joined #forth 23:59:59 --- log: ended forth/17.01.02