00:00:00 --- log: started forth/19.05.02 00:28:53 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth 00:58:24 --- quit: pierpal (Quit: Poof) 00:58:44 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth 01:24:29 Well, my experimental stack processor that doesn't load it's forth image from memory is annoying 01:24:53 right now the idea is you stream in instructions and... do something 01:25:33 maybe the assembler needs to keep track of the memory locations instructions are streaming into... 01:25:37 good idea wilhelm 01:46:10 --- quit: pierpal (Quit: Poof) 01:46:27 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth 02:04:28 --- quit: ashirase (Ping timeout: 244 seconds) 02:08:55 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:23:24 --- quit: a3f (Max SendQ exceeded) 02:23:34 --- join: a3f (~a3f@chimeria.ext.pengutronix.de) joined #forth 02:23:34 --- quit: a3f (Changing host) 02:23:34 --- join: a3f (~a3f@unaffiliated/a3f) joined #forth 03:17:41 --- join: jimt[m]1 (jimtmatrix@gateway/shell/matrix.org/x-wzpmbfsddahywahv) joined #forth 03:20:05 --- quit: jimt[m] (Ping timeout: 252 seconds) 03:20:07 --- quit: bb010g (Ping timeout: 252 seconds) 03:20:32 --- join: bb010g (bb010gmatr@gateway/shell/matrix.org/x-xbzsfmrkqpnveqky) joined #forth 03:24:13 :-) 04:05:07 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:15:09 --- join: dys (~dys@217.6.179.54) joined #forth 05:11:42 --- quit: pierpal (Quit: Poof) 05:12:01 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth 05:28:44 how art thou 07:12:48 --- quit: reepca (Remote host closed the connection) 07:34:42 --- quit: tabemann (Ping timeout: 255 seconds) 07:49:16 --- quit: rdrop-exit (Quit: Lost terminal) 07:57:26 --- quit: dave0 (Quit: dave's not here) 08:14:43 --- quit: Zarutian (Remote host closed the connection) 08:17:01 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 08:17:52 --- join: reepca (~user@208.89.170.37) joined #forth 08:23:52 ullbeking: I asked because getting hold of RTX2010 or RTX2000 isnt that easy. 08:46:38 Today I learned that Chapter 8 of "Let Over Lambda", "Lisp moving Forth moving Lisp" is dedicated to implementing a Forth in Common Lisp 08:47:17 Starts off by talking about Forth's history, and even about how lisp-y it is 08:50:48 Didn't know Chuck Moore was a student of John McCarthy 08:50:57 So the Lisp/Forth heritage goes way back! 08:52:39 I have somewhere an lisp.fs file where lisp or scheme (idrcw) is implemented in FIG or ANS forth 08:55:16 can i have that file? 08:56:06 Yeah he mentions it irregularly siraben 08:56:31 dont recall on which of my offline computers it is on so I dont if I still have it or not. 08:57:04 Zarutian: Now close the loop and write a forth in that LISP. 09:00:41 john_cephalopoda: Such a loop would surely cause a mental explosion 09:06:07 the last forth-based lisp I saw compiled lisp to forth 09:06:18 so you'd be writing a forth-forth compiler 09:18:26 It would be a bootstrapping dream. Implement lisp in forth, and it's languages all the way up 09:18:58 And all you'd have to do is rewrite some assembler primitives or the Forth implementation to port it to a new target 09:25:15 maybe 09:25:23 i don't know for sure, it needs to be tried out 09:25:41 it may be better to implement a C-like language in forth 09:29:27 I haven't seen one yet 09:38:33 https://bootstrapping.miraheze.org/wiki/Forth 10:01:30 Zarutian: This individual https://twitter.com/mike_schuldt has scored an RTX20xx devboard, he was showing it too me on his phone at an svfig meeting. He's also got a SeaForth board and a bunch of other miscellaneous forth chips. 10:05:12 ...and yeah. The new budget ga144 board with pin headers, usbuart, decoupling caps, etc fully assembled and soldered is almost ready. There's just a little problem with the uart that needs to be fixed. https://hackaday.io/project/163652-ga144-evaluation-board 10:09:17 The ga144 schmartboard was flawed and inconvenient to use. The hope with this board is that with something that can just be plugged-in to a laptop and used right away with no hassle, more people will use it and find things they want to do with it. 10:12:37 also, python3 tools https://github.com/mschuldt/ga-tools 10:40:33 --- quit: dys (Ping timeout: 255 seconds) 11:24:28 --- quit: gravicappa (Ping timeout: 246 seconds) 11:27:16 --- join: gravicappa (~gravicapp@h109-187-220-185.dyn.bashtel.ru) joined #forth 11:32:17 --- join: xek (~xek@apn-31-0-23-83.dynamic.gprs.plus.pl) joined #forth 12:08:18 --- quit: gravicappa (Ping timeout: 255 seconds) 12:42:31 --- quit: lchvdlch (Read error: Connection reset by peer) 12:42:42 --- join: lchvdlch (~nestr0@191.98.151.137) joined #forth 13:01:24 the schmartboard sucked 13:01:53 I will happily desolder mine from the schmartboards when I can get one of these 13:14:31 * pointfree just discovered that he can register a .sucks domain name https://get.sucks/ 13:17:15 why is there a .sucks tld 13:17:28 and why am i only just learning about this 13:19:24 $200 13:19:28 .sucks sucks 13:21:05 "WHY .SUCKS? Protect your identity online so that no one can defame your name." 13:21:36 so... you created a tld, and then your first advertising point is "claim your domain before someone starts squatting on it?" 13:21:46 sounds like a protection racket 13:27:18 --- quit: reepca (Remote host closed the connection) 14:06:17 --- join: dys (~dys@tmo-103-53.customers.d1-online.com) joined #forth 14:29:09 --- quit: dys (Ping timeout: 255 seconds) 14:55:03 --- join: reepca (~user@208.89.170.37) joined #forth 14:59:58 --- quit: reepca (Remote host closed the connection) 15:22:23 --- join: reepca (~user@208.89.170.37) joined #forth 15:29:00 --- quit: proteusguy (Ping timeout: 255 seconds) 15:30:24 --- join: dave0 (~dave0@108.060.dsl.syd.iprimus.net.au) joined #forth 15:31:25 hi 16:15:38 --- quit: reepca (Remote host closed the connection) 16:22:55 --- join: reepca (~user@208.89.170.37) joined #forth 16:36:32 --- join: tabemann (~tabemann@71-13-2-250.static.ftbg.wi.charter.com) joined #forth 16:56:09 --- quit: john_cephalopoda (Ping timeout: 240 seconds) 17:01:59 --- quit: tabemann (Ping timeout: 246 seconds) 17:10:07 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 18:17:18 --- quit: X-Scale (Ping timeout: 255 seconds) 18:23:08 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 18:36:17 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth 18:40:37 I want to write a webassembly forth 18:41:25 the only thing is that it can't be compatible with hashforth, because hashforth is byte-addressed and webassembly operates in 32-bit or 64-bit chunks 18:41:44 except 18:43:03 tabemann: The only good tutorial I've found for webassembly is https://crypto.stanford.edu/~blynn/lambda/wasm.html and the webassembly spec 18:43:10 Let me know if you find better ones 18:43:38 tabemann: that's why the Forth standard recommends the use of ! and @ to address cells rather than bytes 18:43:44 Of course you would still have C@ and C! 18:44:47 what I mean is that you can't address parts of cells because addressing would be word-based 18:45:03 C@ and C! would be synonymous with @ and ! 18:45:31 Sure you could address parts of cells with C@ and C! 18:45:36 But then endianness comes into play 18:45:48 no, because there's no byte addressing 18:46:44 Hm, I still have byte addressing and cell addressing in my forths 18:47:12 webassembly has four basic types - i32, i64, f32, and f64 18:47:19 i think he means fetch a 32-bit cell but shift&mask bit twiddling to extract a byte 18:48:34 what I'd have to do is emulate byte addressing by multiplying each address by four, and then right-shifting each time I want to address a cell, but using the low bits to bit-twiddle when trying to address a byte 18:48:34 tabemann: is it possible to read bytes in wasm? 18:49:01 * siraben should re-read the spec 18:49:51 If webassembly is not byte addressable than don't bother with byte addressing. 18:50:39 --- join: X-Scale (~ARM@31.22.200.116) joined #forth 18:51:32 not bothering with byte addressing is probably the simplest approach 18:51:45 and probably the one that would result in the fqstest code 18:52:15 Some chips are only word addressable, e.g. Chuck's. 18:53:30 (I know nothing about Webassembly) 18:54:30 webassembly looks rather... structured... but apparently you can compile C and C++ to webassembly, and you can do all kinds of things involving arbitrary memory access with those, so you must be able to do so with webassembly 18:55:37 https://github.com/WebAssembly/design/blob/master/Portability.md#assumptions-for-efficient-execution 18:56:13 It says in the above link that it assumes the underlying execution environment is byte addressable 18:56:47 webassembly seems like it could be generated by a Lisp program 18:56:52 The asm format is all s-exp based 18:58:22 https://github.com/remko/waforth uses Racket to generate the wasm code 18:58:23 yes 18:58:45 Are you sure it doesn't support byte addressing, that would be weird when it mandates that the underlying platform is byte addressable. 19:00:17 Webassembly itself is bytecode based 19:01:54 maybe it does - but what I'm reading here says it has four types, 32 and 64-bit two's complement integers and 32 and 64-bit floating point values 19:08:16 What a horrible instruction set 19:08:32 uintN 19:08:34 An unsigned integer of N bits, represented in N/8 bytes in little endian order. N is either 8, 16, or 32. 19:09:01 It has to interop with javascript as well at some point, so you need floating points as primitives lol 19:10:00 rdrop-exit, its not designed for you you to be able to write yourself. its meant to be something compilers can output 19:10:37 --- quit: rann (Ping timeout: 258 seconds) 19:10:37 there are similar gripes about how ARM assembly is relatively hard to write by hand 19:10:53 I dont think in either case the designers care about whether its easy for people 19:11:09 So it would seem to support uint8, uint16, uint32 19:11:14 Z80 on the other hand, seems hard for compilers to output (given the relative lack of compilers) but easy to handwrite 19:11:47 I said nothing about assembly or writing anything by hand 19:12:37 --- join: rann (sid175221@gateway/web/irccloud.com/x-qkorfjnglnaremkq) joined #forth 19:13:04 oops should have prefixed my message with MrMobius 19:13:28 It'll be interesting to write once I grok the spec 19:13:46 The instruction set looks horrible to me, regardless of who or what outputs it 19:14:52 rdrop-exit: what are you comparing it to? 19:15:00 De gustibus non est disputandum 19:15:17 you forgot the carbornundum 19:15:24 :) 19:16:18 rdrop-exit: bene dictum 19:16:24 :) 19:17:16 I wasn't really comparing it to anything specific when looking it over 19:19:53 back 19:20:10 It just has so much high level stuff baked in, that repels me 19:21:17 it feels high level to me too 19:21:35 like typed parameters and results! 19:22:15 Heh, has more types than javascript! 19:22:16 It's the same reason I found the JVM spec so repelling 19:25:53 On its own it doesn't give much portability since it assumes so much about the underlying platform 19:26:49 it assumes that it's on a rather "large" platform 19:27:52 See the "Assumptions for Efficient Execution" section here: 19:27:59 https://github.com/WebAssembly/design/blob/master/Portability.md#assumptions-for-efficient-execution 19:37:13 If your machine can run a web browser, I'd say it's safe to make assumptions about the speed and addressable memory etc. 19:37:46 It's not an ISA for embedded systems, so it's somewhat orthogonal to what Forthers would like 19:38:47 Forthers don't like to make such assumptions - they would like to be able to implement it in hardware 19:39:24 I got a kick out of the R216 instruction set 19:39:26 So clean 19:39:34 bbiab 19:39:36 what's R216? 19:39:46 tabemann: glad you asked :) https://github.com/siraben/r216-forth 19:39:56 https://github.com/siraben/r216-forth/blob/master/forth.asm 19:40:00 Hardly any BS! 19:40:47 is it powder toy? 19:42:58 it's a computer implemented in powder toy 19:43:15 I'm more of a software person (currently), so I have no idea how it even works 19:43:22 at the pixel level 19:44:26 I suspect it's cycles per second are, well, low 19:44:30 its* 19:45:16 1 instruction per frame 19:45:31 running a certain command allows me to run the game at ~ 120 Hz 19:46:48 I think it comes down to Forthers don't need or want all the high level baked in stuff, while others would be lost without it. 19:47:55 I tried implementing a Forth in C, but couldn't guarantee its speed 19:48:13 Because, yes, GCC optimizes stuff, but I want to write in smaller primitives 19:48:26 It never worked, often segfaulted lol 19:48:50 all my forths have been in C, and have been less than performant 19:49:14 well, attoforth (my first forth) is significantly faster than hashforth (my second forth) 19:50:17 that's because hashforth is TTC while attoforth is ITC 19:50:22 but 19:50:38 I plan on making a version of hashforth that converts TTC code to SRT/NCI code 19:50:52 which should speed things up 19:51:44 Anything coded for portability is going to be slow. 19:53:50 part of why it's slow is that it's optimized for code compactness by default 19:54:19 i.e. it uses tokens which are 8/16 bit or 16/32 bit - it'd be faster if it just used 16 bit or 32 bit tokens 19:54:56 (it's probably also slown down by the fact that I've been testing it with some debugging checks in place) 19:55:26 --- join: jn___ (~nope@aftr-109-90-233-200.unity-media.net) joined #forth 19:55:30 Why would you need tokens that are that wide, aren't 256 opcodes enough for you? 19:55:56 --- quit: jn__ (Ping timeout: 246 seconds) 19:57:54 rdrop-exit: because ordinary words are not separated from opcodes 19:58:36 but I've gotta go - coffee shop is closing - will bbiab 19:58:46 Ah, I remember, you're doing two levels of indirection in your VM. 19:59:14 nah, it's because I don't have CALL opcodes that call things 19:59:30 rather I add new tokens that directly call things without a CALL opcode in between 19:59:49 That's your second level of indirection 20:00:03 I'm removing a level of indirection, not adding one 20:00:27 but I've gotta go 20:00:53 I don't think so, but maybe I'm missing a subtlety 20:05:00 --- quit: tabemann (Ping timeout: 258 seconds) 20:05:00 Not having a call opcode means you need an extra inner interpreter above the VM executable. 20:08:52 (or within it... I guess) 20:14:46 I'm going by the assumption we discussed a while back that you're doing the scheme where you have a separated VM that can run portable binary dictionay image files. 20:16:14 If that's not the case, then that's another kettle of fish. 20:21:58 --- join: gravicappa (~gravicapp@h109-187-220-185.dyn.bashtel.ru) joined #forth 20:40:58 --- quit: X-Scale (Ping timeout: 246 seconds) 20:43:11 --- join: X-Scale` (~ARM@46.50.2.74) joined #forth 20:43:37 --- nick: X-Scale` -> X-Scale 20:45:36 --- join: tabemann (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 20:52:47 --- quit: dave0 (Quit: dave's not here) 22:59:48 --- join: dave0 (~dave0@108.060.dsl.syd.iprimus.net.au) joined #forth 23:00:33 re 23:34:58 Hi dave0 c[_] 23:48:57 hi rdrop-exit 23:49:15 i have a cup of tea :-) 23:55:53 I just got through lunch, having a double espresso :) 23:59:59 --- log: ended forth/19.05.02