00:00:00 --- log: started forth/21.04.12 00:52:20 --- quit: boru (Read error: Connection reset by peer) 00:52:38 --- join: boru joined #forth 00:55:14 --- quit: Zarutian_HTC1 (Ping timeout: 240 seconds) 01:33:31 --- join: mtsd_ joined #forth 01:36:03 --- quit: mtsd (Ping timeout: 240 seconds) 01:49:58 --- join: mtsd joined #forth 01:49:59 --- quit: mtsd_ (Ping timeout: 252 seconds) 03:07:07 --- quit: dave0 (Quit: dave's not here) 03:46:26 --- nick: jedb__ -> jedb 04:10:18 --- join: Zarutian_HTC joined #forth 04:11:33 --- quit: joe9 (Ping timeout: 260 seconds) 04:14:43 --- join: joe9 joined #forth 04:20:06 --- join: f-a joined #forth 04:56:33 --- quit: f-a (Quit: leaving) 05:36:14 --- quit: Zarutian_HTC (Ping timeout: 240 seconds) 05:45:27 --- quit: APic (Ping timeout: 268 seconds) 05:46:45 --- join: APic joined #forth 06:06:03 --- quit: X-Scale (Ping timeout: 240 seconds) 06:08:36 --- join: X-Scale` joined #forth 06:09:33 --- nick: X-Scale` -> X-Scale 06:15:20 --- join: f-a joined #forth 06:20:01 --- join: Zarutian_HTC joined #forth 06:22:24 --- quit: f-a (Quit: leaving) 06:45:16 --- quit: APic (Ping timeout: 268 seconds) 06:47:16 --- join: APic joined #forth 06:48:51 --- join: tech_exorcist joined #forth 06:51:34 --- quit: APic (Ping timeout: 240 seconds) 06:54:03 --- join: APic joined #forth 07:13:04 --- quit: Zarutian_HTC (Remote host closed the connection) 07:42:33 --- join: f-a joined #forth 07:45:31 --- quit: andrei-n (Write error: Connection reset by peer) 07:45:51 --- join: andrei-n joined #forth 08:25:15 --- join: f-a_ joined #forth 08:25:56 --- quit: f-a (Read error: Connection reset by peer) 08:29:39 --- quit: f-a_ (Client Quit) 08:29:56 --- join: f-a joined #forth 08:36:54 --- quit: APic (Ping timeout: 240 seconds) 08:44:10 --- join: APic joined #forth 08:45:29 --- quit: f-a (Read error: Connection reset by peer) 08:46:49 --- join: f-a joined #forth 09:22:00 --- join: Zarutian_HTC joined #forth 10:06:13 --- quit: Kumool (Ping timeout: 265 seconds) 10:10:49 --- quit: tech_exorcist (Remote host closed the connection) 10:11:38 --- join: tech_exorcist joined #forth 10:12:25 --- quit: tech_exorcist (Remote host closed the connection) 10:12:44 --- join: tech_exorcist joined #forth 10:13:03 --- join: Kumool joined #forth 10:29:28 --- quit: gravicappa (Ping timeout: 240 seconds) 10:33:00 --- join: gravicappa joined #forth 10:51:19 --- quit: Zarutian_HTC (Remote host closed the connection) 11:01:27 --- join: _0x1d3 joined #forth 11:07:27 --- quit: mtsd (Remote host closed the connection) 11:11:19 --- join: mtsd joined #forth 11:48:12 --- quit: APic (Ping timeout: 265 seconds) 12:18:26 --- join: lispmacs[work] joined #forth 12:42:03 --- quit: tech_exorcist (Remote host closed the connection) 12:42:12 --- join: tech_exorcist_ joined #forth 12:42:34 --- join: Zarutian_HTC joined #forth 12:44:45 --- quit: f-a (Ping timeout: 265 seconds) 12:46:25 --- join: f-a joined #forth 12:52:52 --- quit: gravicappa (Ping timeout: 260 seconds) 13:40:14 --- quit: andrei-n (Quit: Leaving) 13:54:54 --- quit: mtsd (Ping timeout: 240 seconds) 14:15:34 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 14:15:45 --- join: Zarutian_HTC joined #forth 14:20:46 --- join: dave0 joined #forth 14:21:06 maw 14:28:01 hi, I was just wondering: it is fairly common, if you need some array space briefly, to just allot and - allot the memory while inside a word? 14:30:11 --- quit: wineroots (Read error: Connection reset by peer) 14:34:19 --- quit: f-a (Quit: leaving) 14:34:55 --- quit: tech_exorcist_ (Quit: tech_exorcist_) 14:35:14 --- join: tech_exorcist joined #forth 14:35:25 you cant really do that since the array and word youre defining share the same ditionary 14:36:02 unless you mean after youre done defining all words 14:36:42 lispmacs[work]: it sounds sensible but i'm a newbie 14:39:20 Since allot doesn't assign a word, why would the dictionary matter? 14:45:24 it's a really fast way to get some temporary space.. just an add to allocate and a sub to free 14:46:47 thinking it through, you would have to be careful in embedded applications, so you weren't doing a lot of writes to flash code space 14:47:05 my mind thinking in the context of flashforth 14:51:23 it's a little bit confusing to me 14:52:12 but according to FF reference sheet, `,' appends `x' to the current data section 14:52:30 and the dictionary is stored in flash memory 14:53:10 so storing data that way temporarily would burn out your flash memory 14:53:29 if you called that word regularly 14:55:11 or is the data section outside of the dictionary? 14:55:16 need more sleep 14:57:44 wait, in flashforth, there are keywords to set which memory type data section is currently referring to - ram, eeprom, or flash 15:44:56 --- quit: tech_exorcist (Quit: tech_exorcist) 16:05:30 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 16:05:34 --- join: Zarutian_HTC1 joined #forth 16:11:20 --- quit: dave0 (Quit: dave's not here) 17:42:41 --- nick: Zarutian_HTC1 -> Zarutian_HTC 17:42:49 hey guys 18:05:19 Evening. Got my number conversion stuff plugged in today. 18:05:25 --- quit: lispmacs[work] (Remote host closed the connection) 18:05:34 I rewrote it - it's even more highly factored than before. 18:07:19 I used a little trick to stitch it into the interpreter loop, but that won't extend to compiling; I'll have to redo that loop. 18:07:25 But it was good enough for pretty solid testing. 18:25:29 --- quit: Kumool (Ping timeout: 252 seconds) 18:27:28 --- join: Kumool joined #forth 18:32:55 --- join: boru` joined #forth 18:32:57 --- quit: boru (Disconnected by services) 18:33:00 --- nick: boru` -> boru 18:33:23 --- join: APic joined #forth 18:46:43 --- join: Rakko^ joined #forth 18:47:26 --- nick: Rakko^ -> Rakko 18:54:28 --- join: dave0 joined #forth 18:56:15 maw 18:56:23 hey 18:58:43 hi tabemann 19:00:25 KipIngram: what forth are you using? for zeptoforth I added a hook to allow external number parsers and like to be added to the interpreter 19:04:08 Oh, this is one I'm writing, in assembly with nasm. 19:04:35 I had it pretty far along, but decided to rework and tidy it up, so I'm working through the pieces step by step. 19:04:47 It won't be long before I can load source from disk. 19:07:47 how are you working around the fact that x86 machines are a royal pain to code for on the bare metal, when it comes to device support issues and like? 19:09:20 Haven't really encountered any problems yet. But I haven't interfaced any devices yet either. 19:09:57 I used system calls for the console, and will use it for disk i/o. 19:10:32 I might port it to "real" bare metal someday - I've always figured I'll do some gadget building in retirement - this will be the software. 19:12:57 that's why I opted to go embedded to work on the real bare metal 19:13:13 embedded is far, far more friendly to embedded than PC's 19:13:17 I basically did the jump to bare metal when I wanted to do "all IO is async + blocks the current coroutine, while running others" 19:13:19 *to bare metal 19:13:23 and ditched amd64 for aarch64 19:13:44 and yeah, aarch64 bare-metal is infinitely nicer 19:14:45 Most of my career was embedded. It's been a while, though. 19:14:46 I've been doing all my work for more than a year on Cortex-M targets 19:14:57 my work on my own that is 19:15:06 my day job is as a web developer :( 19:15:20 The idea is for this Forth to be easy to port to ARM. 19:15:49 The primitives are written using a set of macros that I call portable instructions." 19:16:06 The idea is that if I implement the pi macros in ARM, the rest will just work. 19:16:12 We'll see how it turns out. :-) 19:16:27 I just decided to write directly for ARM from the getgo 19:16:29 for running under linux, probably 19:17:17 I tried writing a portable Forth that could work under both linux and embedded, but then decided eventually that it just wasn't gonna work 19:17:39 so I decided to stop bothering with Linux and instead to specifically target ARM 19:17:44 on the bare metal 19:18:00 if you haven't seen io_uring, it's a step towards making them closer, but you need a kernel from within the last ~2 years 19:18:34 i wonder what the performance of a 64 bit x86 forth is like 19:18:52 From what I can tell around 25-30 percent of C. 19:19:06 with all the register renaming and other stuff, I wonder if the performance hit is a lot less 19:19:09 Rough estimate based on a few measurements. 19:19:29 I've heard similar statistics 19:19:31 thats amd64? 19:19:43 I testedit on Intel. 19:20:03 dunno if it would be much different on 32 bit but just curious 19:20:18 the biggest hit is probably all the stack interfacing 19:20:34 so it probably wouldn't make much of a difference whether it is on 32 bit or 64 bit 19:20:59 yeah, I've been wondering about trying to do one where the stack is in vector registers 19:21:00 thats one of the things I was curious about 19:21:02 probably the best way to increase performance is to find ways to intelligently put data in the stack in registers 19:21:05 (and you only have 16 slots or w/e) 19:21:20 remexre: Oh, that's interesting. 19:21:48 I was asking in another channel about that when I read about swiftforth i think it was that ignores most registers and makes heavy use of the stack 19:22:03 from what i heard, that might not actually slow you down like it would on embedded since x86 is so sophisticated 19:22:41 The GForth guys did some research on caching more than just one stack item in registers. They got a small benefit, but not nearly as much as you get caching the top element. 19:23:37 the problem with keeping things in registers is its too easy to write code that does unpredictable things to the stack which doesnt really happen in C code 19:23:48 you have to spill all your registers with something as simple as IF 5 THEN 19:24:39 zeptoforth only caches the top element 19:26:44 the main optimizations that zeptoforth does are A) caching the top element, B) inlining, and C) merging constants into instructions when possible 19:26:53 Mine too. Just one item. 19:27:34 It has a pair of address registers, though, of the sort Chuck suggested alongn the way. A and B. 19:27:43 And they support post-increment and so on. 19:27:47 ive thought about how you would optimize if you could recognize code that doesnt unbalance the stack and can therefore skip the stack and use registers 19:28:07 so you give the user to write in a constrained way for good performance or in a convenient way if performance doesnt matter on that line 19:28:11 well, as part of merging constants it also sometimes when it can't actually merge instructions it loads arguments into registers and then uses them there rather than putting them in the TOS register, thus avoiding pushing the old TOS onto the stack 19:29:00 MrMobius: the problem with that is that it'd require multipass compilation, which would be hard on things like embedded systems 19:29:33 That's an interesting idea. Keep a window of several instructions and look for combinations that allow performance enhancements. 19:29:43 I'll have to give that some thought. 19:29:59 zeptoforth only delays constants from being applied immediately 19:30:21 so it can look for something like + - * / lshift rshift arshift etc. to merge it with afterwards 19:30:41 note that it is smart enough that it can treat a CONSTANT like a numeric literal here 19:30:42 I don't yet have any optimizations beyond caching that one register and optimizing tail calls. 19:31:19 I don't do optimizing tail calls because that might break some cases of RDROP EXIT 19:32:08 Yeah, I can manually suppress it when I want to. 19:33:59 I don't so much care about that one return - I do it so I can actually use deep tail recursion without worrying about the stack. 19:34:12 also, I don't really make significant use of recursion in Forth as I do in functional languages, though 19:35:20 I do quite a bit of tail recursion. But I've never done a really deep one. I basically do most of my loops that way. 19:35:34 tabemann, hmm ya youd have to compile to RAM temporarily and possibly edit 19:36:53 tabemann, can it turn something like "3 lshift" into one instruction? 19:37:51 KipIngram: the problem with tail call optimization in Forth is that it's hard for the compiler to see : foo if bar else baz then ; such that it treats bar and baz as tail calls 19:37:55 MrMobius, yes 19:38:16 Well, yeah - it takes a little doing. 19:38:26 I've managed to make it work though. 19:38:53 If the last thing in the word is THEN, it doesn't optimize that one. 19:39:00 You're right that it takes care. 19:39:41 I don't really use IF THEN much - I've gotten so I do most of my conditionals with conditional returns of one or two levels. 19:39:55 It's an opportunity to factor. 19:42:09 zeptoforth is a much more conventional forth in that regard 19:51:54 --- quit: sts-q (Ping timeout: 240 seconds) 19:57:26 I'll have to look at my old one to get the precise details, but basically I look at the CFA of each word I compile. If it's the : handler, I set a state variable. Under certain conditions I clear the variable. Then I just se that flag to decide whethr to optimize or not. 19:58:12 I did require keeping thta bit of state to get it right. 20:03:03 --- join: sts-q joined #forth 20:03:29 to me at least, as I see it, TCO in the general case requires caching the whole of what is being compiled in RAM, so the compiler can figure out after the fact whether something is a tail call of not 20:09:06 anyways, g'night 20:09:06 I couldn't guarantee you there are no cass that will break mine. I just know it's never misbehaved yet. 20:09:15 Night, man. Rest well! 20:10:37 When I wrote the number conversion stuff for my previous Forth, I wrote it to convert floating point numbers too. I didn't actually flesh that out this time, but there's an obvious place where a bit more code would need to go to handle it. 20:11:19 I throw an error in this one, since floats are unsupported, but at the time I do that all theinformation to complete the conversion is on the stack. 20:11:46 It supports arbitrary base up to 62. 20:19:06 --- quit: sts-q (Quit: ) 20:19:32 --- join: sts-q joined #forth 20:51:36 --- join: mtsd joined #forth 21:57:53 --- join: gravicappa joined #forth 22:02:22 --- join: jedb_ joined #forth 22:04:28 --- quit: jedb (Ping timeout: 240 seconds) 22:47:50 --- quit: APic (Ping timeout: 252 seconds) 23:26:21 --- join: APic joined #forth 23:27:55 --- join: andrei-n joined #forth 23:59:59 --- log: ended forth/21.04.12