00:00:00 --- log: started forth/18.07.09 00:33:42 --- quit: pierpal (Ping timeout: 264 seconds) 00:46:56 --- join: sigjuice (~sigjuice@2604:a880:1:20::83:6001) joined #forth 01:02:23 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 01:04:43 --- quit: M-jimt (Ping timeout: 240 seconds) 01:05:23 --- quit: MrMobius (Ping timeout: 260 seconds) 01:05:23 --- nick: [1]MrMobius -> MrMobius 01:21:53 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 01:28:56 --- join: M-jimt (jimtmatrix@gateway/shell/matrix.org/x-swinybifctvicjxl) joined #forth 01:57:26 --- join: smokeink (~smokeink@li1870-239.members.linode.com) joined #forth 02:04:22 --- quit: ashirase (Ping timeout: 248 seconds) 02:08:29 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:45:42 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 02:53:26 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth 02:53:26 --- quit: ncv (Changing host) 02:53:26 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 03:35:56 --- join: Keshl_ (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 03:36:46 --- quit: Keshl (Ping timeout: 260 seconds) 05:30:51 reepca-laptop: Well, your target image has to contain everything that it needs to run. Since the target might be an entirely different processor model, you do have to produce the primitives that will run on it somehow. 05:49:12 --- quit: wa5qjh (Ping timeout: 244 seconds) 05:57:26 if it's the same platform and you know where your core wordset stops, and depending on how your interpreter works, you might be able to get away with just cloning that part of your dictionary 06:27:59 --- join: _0x80___ (413371c2@gateway/web/freenode/ip.65.51.113.194) joined #forth 06:28:01 Yes, if the code is relocatable. But Forth primitives most often are. 06:28:11 They're usually friendly that way. :-) 06:28:12 <_0x80___> Hello! 06:28:23 <_0x80___> Glad theres a channel for Forth 06:28:27 Morning. 06:29:27 <_0x80___> I have a question about forth efficiency [I understand it depends on implementation probably]. 06:29:45 Hit us with it. 06:30:21 <_0x80___> Is pipelining taken advantage of in Forth or does the language generally trip over it in our common register machine cpus? 06:31:46 Well, depending on the architecture the NEXT operation (the bit of code that moves you to the next primitive) usually doesn't share resources with the "action" of the primitive. 06:31:50 For most primitives anyway. 06:32:11 So in theory you could be running next in parallel with the actual primitive action, if your architecture is able to do that. 06:32:24 <_0x80___> I see 06:33:09 If you think of Forth as having a "virtual machine" (and it's a good way to think about Forth), that would be equivalent to pre-fetching instructions. 06:33:56 Then within the action part of the various primitives your processor may be pre-fetching the actual machine instructions too. 06:34:15 <_0x80___> And the other question I've been thinking of is whether forth functions have less overhead than frame-based function calls due to not having to save register state every call. Is my understanding correct? 06:34:42 --- quit: smokeink (Ping timeout: 240 seconds) 06:34:52 Furthermore, since Forth has operands implicit as the top element or two of the stack, your ALU can generate all of the common results before even knowing which one of them the next instruction is going to want. 06:35:03 +, -, and, or, not, xor, etc. 06:35:33 Yes, I think a well-designed Forth has much lower overhead of that sort than, say, C. 06:35:56 Because your stack state "already is" - you don't have to push all of a function's parameters onto the stack before calling it. 06:36:06 <_0x80___> Thanks so much! 06:36:17 You bet - happy you dropped in. 06:36:24 <_0x80___> And lastly haha: 06:38:02 Another way of stating the NEXT overlapping is that if your processor does speculative execution of NEXT, it's almost always going to be able to commit those results. 06:38:05 <_0x80___> I have heard of forths that do very nice register allocation, does the advantage of "stack state 'already is'" disappear due to this other optimization? I'd imagine that in such a case it would be similar to frames and such 06:38:23 It depends on how far they take the register thing. 06:38:35 Almost all modern Forths cache the top element of the stack in a register. 06:38:45 That doesn't give up much (any?) "certainty" about the state. 06:39:29 <_0x80___> I'm thinking of code that does a lot of stack juggling 06:39:45 But someone (the GForth guys, maybe?) has researched keeping more stack items in registers. If you implement that in an entirely straightforward way so that the state is always fixed, it doesn't really buy you any more, and can even hurt. But you can try to be clever and let the specific register assignments vary, and have the compiler keep up with it. 06:40:16 That can buy you more performance, but it complicates the system in other ways - you often have to have multiple versions of your primitives. One for each possible variant of the register assignments, and the compiler figures out which one to use. 06:40:23 I've never tried to do one like that myself. 06:40:39 But keeping the one item "top of stack" in a reg is generally a win. 06:41:25 <_0x80___> Thanks for explaining, I feel I understand a little better. And feel a bit more motivated to possibly use Forth instead of Rust/C. 06:41:39 So if your compiler could keep either one or two items in registers, you could implement DROP or NIP entirely in the compiler (provided you started out with both regs being used). You'd just move the compiler from a state of "two items in registers" to "one item in register." 06:43:05 My usual reasoning on this is that TOS in a register is pure win, so I do that. But I figure I can profile my code and identify the critical spots, and then just use assembly in those spots if I really truly have to have top performance. 06:43:23 In most of the code you right that utter "bleeding edge" performance really just doesn't matter. 06:43:35 s/right/write/ 06:44:43 And where it does matter, a good Forth gives you the tools to optimize. 06:45:20 <_0x80___> You are referring to inline assembly and such? 06:46:33 <_0x80___> I have to go, thanks again for your help. I'll check the logs later for the continuation of this thread 06:47:00 --- quit: _0x80___ () 06:49:26 --- quit: impomatic (Ping timeout: 240 seconds) 07:00:03 --- join: _0x80___ (413371c2@gateway/web/freenode/ip.65.51.113.194) joined #forth 07:02:13 --- quit: _0x80___ (Client Quit) 07:15:48 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 08:12:29 --- quit: fiddlerwoaroof (Read error: Connection reset by peer) 08:18:31 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 08:26:13 --- quit: fiddlerwoaroof (Read error: Connection reset by peer) 08:30:48 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 09:05:02 --- quit: pierpal (Read error: Connection reset by peer) 09:19:32 --- join: point3r (413371c2@gateway/web/freenode/ip.65.51.113.194) joined #forth 09:22:16 --- quit: point3r (Client Quit) 09:37:46 --- quit: epony (Quit: QUIT) 10:07:17 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth 11:13:37 --- join: epony (~nym@77-85-141-166.ip.btc-net.bg) joined #forth 11:44:47 --- join: dys (~dys@tmo-110-151.customers.d1-online.com) joined #forth 11:57:19 --- join: proteus-guy (~proteus-g@cm-134-196-84-218.revip18.asianet.co.th) joined #forth 12:45:19 --- join: impomatic (~digital_w@host86-137-197-211.range86-137.btcentralplus.com) joined #forth 13:36:19 --- join: TCZ (~Johnny@ip-91.189.219.214.skyware.pl) joined #forth 14:04:05 --- quit: ashirase (Ping timeout: 255 seconds) 14:05:39 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 14:06:24 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 14:15:08 --- quit: TCZ (Quit: Leaving) 14:23:48 --- nick: Keshl_ -> Keshl 14:27:15 So can any of you x86 gurus explain this one? I have these two lines in my EXECUTE (to handle the relocation stuff - those details aren't necessary for this quesiton): 14:27:17 1296 sub r8, r15 14:27:19 1297 movsx r9, dword [r15+r8] 14:27:27 That works just fine - passes all tests. 14:27:44 But if I remove the sub r8, r15 line completely and remove the r15+ from the brackets, it segfaults. 14:28:05 It looks to me like I'm subtracting R15 and adding R15, for net result "no change." 14:28:11 But apparently there's more to it than that. 14:28:25 KipIngram: I guess I was thinking about some sort of lazy compiling for the platform-independent parts. Where, on attempting to compile something defined only in a non-target wordlist, the source for that definition would just automatically be evaluated. 14:28:33 No other uses of the registers in nearby code that would cause a problem. 14:29:19 In this situation the value in r15 is guaranteed to be less than the value in r8. 14:29:33 R15 is the base address of my whole system. 14:47:56 --- join: pierpa (57043661@gateway/web/freenode/ip.87.4.54.97) joined #forth 15:15:42 KipIngram: what instruction does it segfault on? 15:17:17 and what are the values in r8 and r15 15:17:58 knowing nothing about the code of execution environment i'm skeptical that no other code depends on r8 there 15:18:05 I don't know that - I would suspect either the movsx or the jmp. 15:18:13 But I don't really have a debugging environment. 15:18:32 I debugged this thing primarily by moving "exit" through my words until I isolated the trouble spot. 15:19:04 And later, when more was working, quit instead of exit, because I could then inspect the stack. 15:19:17 you have enough of an operating system to trap page violations so you should be able to use some kind of debugger 15:19:55 --- quit: dys (Ping timeout: 264 seconds) 15:20:01 I could. I've managed without one so far, though. I'm willing to go forward with the sub r8, r15 version which works. 15:20:12 I just don't understand how the other version doesn't work. 15:20:26 There must be some subtlety to the [r8+r15] that I'm not aware of. 15:20:35 without seeing the execution environment or other instructions i don't either :P 15:21:04 I just thought my question might trigger a bit of knowledge that someone here had. 15:21:46 About some bit of x86 esoterica. 15:21:54 then first guess would be to look for anything using r8 even if you think nothing is 15:22:36 I'm absolutely sure it's not. It's my W register - used as scratch for the indirect threading. 15:23:18 r9 is scratch as well. 15:23:33 I use both of those for whatever I want to in primitives. 15:23:45 Up above what I posted is a mov r8, rcx - rcx is my TOS register. 15:25:32 This is my "next": 15:25:34 320 movsx r8, dword [r13] 15:25:36 321 add r13, 4 15:25:38 322 movsx r9, dword [r15+r8] 15:25:40 323 add r9, r15 15:25:42 324 jmp r9 15:26:35 Oh, I understand what's going on. 15:26:47 The problem isn't with executing a PRIMITIVE this way. 15:26:53 Because primitives don't use R8. 15:26:55 But you're right. 15:27:34 The docol runtime for definitions uses it, to access the PFA of the definition. 15:27:46 Ok - that makes total sense now. 15:55:46 --- join: wa5qjh (~quassel@175.158.225.223) joined #forth 15:55:47 --- quit: wa5qjh (Changing host) 15:55:47 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 16:02:01 --- quit: nighty- (Quit: Disappears in a puff of smoke) 16:22:55 --- quit: tadni- (Read error: Connection reset by peer) 16:23:11 --- quit: wa5qjh (Read error: Connection reset by peer) 16:24:16 --- join: tadni_ (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #forth 16:24:25 --- join: wa5qjh (~quassel@175.158.225.223) joined #forth 16:24:30 --- quit: wa5qjh (Changing host) 16:24:30 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 16:44:02 --- quit: wa5qjh (Remote host closed the connection) 16:48:04 --- quit: ashirase (Ping timeout: 268 seconds) 16:48:56 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 16:49:18 --- quit: pierpal (Ping timeout: 268 seconds) 17:09:42 --- quit: tadni_ (Ping timeout: 240 seconds) 17:14:31 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 17:33:35 --- join: smokeink (~smokeink@li1870-239.members.linode.com) joined #forth 17:39:35 --- quit: dddddd (Remote host closed the connection) 17:40:22 --- quit: smokeink (Ping timeout: 248 seconds) 17:57:04 KipIngram: was that x86_64 gas or at&t assembly? 17:58:48 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #forth 17:59:08 --- join: tadni_ (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #forth 18:00:23 --- quit: tadni (Remote host closed the connection) 18:03:59 gas 18:25:00 --- join: dave0 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 18:55:44 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 18:59:48 --- quit: pierpal (Ping timeout: 240 seconds) 19:00:41 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 19:01:19 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 19:01:35 hi 19:17:01 --- join: a3f_ (~a3f@irc.a3f.at) joined #forth 19:17:07 --- join: koisoke_ (xef4@epilogue.org) joined #forth 19:18:00 --- join: jn___ (~nope@aftr-109-91-33-105.unity-media.net) joined #forth 19:18:08 --- join: zy]x[yz_ (~corey@c-76-97-179-143.hsd1.ga.comcast.net) joined #forth 19:18:34 --- quit: zy]x[yz_ (Changing host) 19:18:35 --- join: zy]x[yz_ (~corey@unaffiliated/cmtptr) joined #forth 19:19:43 --- quit: dave0 (Ping timeout: 240 seconds) 19:19:50 --- quit: tadni_ (Ping timeout: 240 seconds) 19:19:50 --- quit: nighty- (Ping timeout: 240 seconds) 19:19:51 --- quit: proteus-guy (Ping timeout: 240 seconds) 19:20:00 --- join: phadthai_ (mmondor@206.248.143.74) joined #forth 19:20:01 --- join: cheater_ (~cheater@80-110-80-49.cgn.dynamic.surfer.at) joined #forth 19:20:03 --- quit: a3f (Ping timeout: 260 seconds) 19:20:10 --- quit: koisoke (Ping timeout: 260 seconds) 19:20:11 --- quit: phadthai (Ping timeout: 260 seconds) 19:20:14 --- quit: jedb (Ping timeout: 260 seconds) 19:20:15 --- quit: cheater (Ping timeout: 260 seconds) 19:20:15 --- quit: zy]x[yz (Ping timeout: 260 seconds) 19:20:15 --- quit: jn__ (Ping timeout: 260 seconds) 19:20:22 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #forth 19:20:24 --- join: jedb (~jedb@199.66.90.209) joined #forth 19:20:32 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 19:20:33 --- quit: cheater_ (Changing host) 19:20:33 --- join: cheater_ (~cheater@unaffiliated/cheater) joined #forth 19:20:38 --- quit: cheater_ (*.net *.split) 19:20:39 --- quit: phadthai_ (*.net *.split) 19:20:45 --- join: phadthai (mmondor@ginseng.pulsar-zone.net) joined #forth 19:21:41 --- join: proteus-guy (~proteus-g@cm-134-196-84-218.revip18.asianet.co.th) joined #forth 19:26:15 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth 20:08:10 --- quit: pierpa (Quit: Page closed) 20:12:35 !eForth 20:12:49 show yourself, robot 20:28:37 --- quit: pierpal (Quit: Poof) 20:28:57 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 21:12:09 --- join: dave0 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 21:18:08 --- quit: dave9 (Quit: one love) 21:23:03 --- join: smokeink (~smokeink@li1870-239.members.linode.com) joined #forth 21:27:59 --- quit: smokeink (Ping timeout: 244 seconds) 21:35:53 --- quit: epony (Quit: QUIT) 21:39:15 --- join: smokeink (~smokeink@li1870-239.members.linode.com) joined #forth 21:44:48 --- quit: smokeink (Ping timeout: 240 seconds) 22:01:30 --- quit: tadni (Remote host closed the connection) 22:35:02 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 22:35:27 re 23:01:18 --- quit: cheater (Ping timeout: 240 seconds) 23:26:28 --- quit: Keshl (Read error: Connection reset by peer) 23:26:50 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 23:36:35 --- join: dys (~dys@tmo-081-135.customers.d1-online.com) joined #forth 23:55:08 --- quit: Lord_Nightmare (Quit: ZNC - http://znc.in) 23:59:59 --- log: ended forth/18.07.09