00:00:00 --- log: started forth/14.11.24 00:05:13 --- quit: xyh (Remote host closed the connection) 00:18:41 --- quit: PoppaVic (Ping timeout: 245 seconds) 00:27:28 --- join: nighty^ (~nighty@hokuriku.rural-networks.com) joined #forth 00:38:50 --- join: impomatic_ (~digital_w@88.98.199.146.dyn.plus.net) joined #forth 01:20:46 --- quit: ErhardtMundt (Ping timeout: 245 seconds) 01:24:29 --- join: ErhardtMundt (~quassel@93-43-163-57.ip92.fastwebnet.it) joined #forth 02:58:01 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 02:59:20 --- quit: justgreg (Ping timeout: 255 seconds) 03:55:53 --- quit: samrat (Quit: Computer has gone to sleep.) 04:07:11 --- join: justgreg (~greg@125.164.156.210) joined #forth 04:17:43 --- quit: vanila (Remote host closed the connection) 04:34:22 --- quit: Azel (Ping timeout: 255 seconds) 04:34:32 --- quit: proteusguy (Remote host closed the connection) 04:40:06 --- join: proteusguy (~proteusgu@ppp-110-168-229-22.revip5.asianet.co.th) joined #forth 04:44:22 --- join: samrat (~samrat@123.236.183.195) joined #forth 05:04:20 --- join: true-grue (~grue@89-178-226-100.broadband.corbina.ru) joined #forth 05:20:32 --- quit: Bahman (Quit: Leaving.) 05:25:11 --- quit: crc (Read error: Connection reset by peer) 05:25:53 --- join: crc (sid2647@gateway/web/irccloud.com/x-uhkbrfxmeuxvyqbl) joined #forth 05:26:09 --- quit: aksatac (Read error: Connection reset by peer) 05:27:49 --- join: aksatac (sid12717@gateway/web/irccloud.com/x-mufmmrudsnvowmet) joined #forth 06:01:10 --- quit: justgreg (Quit: Leaving) 07:07:04 --- quit: Zarutian (Quit: Zarutian) 07:34:25 --- join: Bahman (~Bahman@188.159.53.9) joined #forth 07:37:38 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 07:58:59 --- join: mnemnion (~mnemnion@67.164.37.196) joined #forth 09:03:08 --- join: PoppaVic (~pops@unaffiliated/poppavic) joined #forth 09:23:11 --- join: vanila (~user@unaffiliated/vanila) joined #forth 10:44:45 --- quit: fantazo (Ping timeout: 255 seconds) 11:09:33 --- quit: Bahman (Quit: Ave atque vale) 11:17:09 --- quit: beretta (Ping timeout: 255 seconds) 11:26:01 --- join: Mat4 (~claude@ip5b414c9f.dynamic.kabel-deutschland.de) joined #forth 11:26:06 hello 11:28:01 heya 11:31:41 hi tangentstorm 11:40:38 I've implemented my idea for replacing all stack operators with a single pick instruction, operating on a circular stack whereby pick 0 = dup, pick 1 = over. 11:41:49 :) nice. i remember you telling me about this a while back 11:42:15 remember: purists will hate you ;-) 11:42:49 I do not care obviously :D 11:43:13 about puritans 11:44:00 sorry, purists 11:48:14 --- join: fantazo (~fantazo@2001:858:5:3a41:99d8:b33b:fce0:c986) joined #forth 11:49:10 as I see it these scheme for stack accessing has two advantages: First, the most used stack values are freely accessible and second, the otherwise unavoidable stack management is now unnecessary 11:49:50 --- quit: samrat (Quit: Computer has gone to sleep.) 11:50:37 however, it is one more step away from traditional Forth 11:55:58 --- join: pgomes (~pgomes@ipb2182f12.dynamic.kabel-deutschland.de) joined #forth 11:56:02 I always found the gymnastics totally disgusting. SURE, they can be useful - but geezus.. 11:56:49 and, the contrary view that the stacks COULD be other than an accessible sequence of slots in mem remains valid. 11:59:39 hmm 11:59:43 --- quit: mnemnion (Remote host closed the connection) 12:00:18 --- join: mnemnion (~mnemnion@67.164.37.196) joined #forth 12:02:37 * Mat4 watching http://vimeo.com/108094559 12:04:53 --- quit: mnemnion (Ping timeout: 258 seconds) 12:07:17 i've thought about that 12:07:33 you could use n registers for the top n items on the stack 12:08:14 on x86, afaik there's no way to dynamically choose a register based on data in a single operation. 12:08:47 but maybe you could just generate n different copies of the primitive operations 12:24:49 for x86 native code generation, I statical cache the topmost 8 stack elements in registers by compiling dependent on a virtual stack pointer. For subroutine branches, the first 3 stack elements are copied to the first 3 registers and the virtual stack pointer is setted accordant. For my VM design, I simply unroll the stack 1024 elements deep 12:29:12 Beside implementation at assembler code level in both cases the stack is accessible 8 elements deep with wraparound as described above 12:30:27 anyone recall the link to whateverthehell profiling Anton or whoever did that mentions max stack-depths and other "things that make you go hmmm"? 12:33:01 --- quit: nighty^ (Quit: Disappears in a puff of smoke) 12:36:30 I think to know this publication and found it an interesting read to be said. However because most well factored code seem to relate on max. 3 stack items a small data stack should be sufficient dependent on programming style (at least functional style which only requires functions with no, one or two parameters returning either no or a single result [see currying]) 12:37:40 Pf. 12:37:41 I don't give a damn about currying. I was remembering they'd metacompiled a forth for some stats and run a bunch of tests for the rest - including recursion. 12:38:00 This "single result [see currying]" requires creating closures dynamically. 12:39:21 Besides, the best way to optimise in this case is to lift lambdas. :) 12:39:48 To my knowledge programming languages like Haskell reduce in a simple, static way 12:40:19 Not at all. 12:40:54 good point then, I take some research 12:40:58 You can find paper after Leroy where he analysed the issue. 12:43:06 anyway, Mr. Thun described an approach for sure in his analysis of Joy which is implementable in a staic way (I know this, because have done it) 12:43:24 ^static 12:43:37 mill architecture smells like Transmeta. 12:44:06 I don't understand fully what your "static way" applies to. 12:44:24 ASau: Probably we have different definations of 'static' 12:44:28 But either it is another name of lambda lifting or it is something strange. 12:44:50 no, definatly not 'lamda lifing' 12:45:01 eh, sorry, I mean lifting 12:45:51 sadly his side has been gone, it's an quite interesting read 12:45:57 Then you can find Leroy's paper where he discusses the issue of optimisations of curried invocations. 12:45:59 (better was) 12:46:34 His conclusion was, mostly, lift, if you can, or do some hard optimisations of how you compile the code. 12:47:05 In terms of intermediate VM code. 12:47:59 well, for a concatenative language the later approach is always possible because the whole runtime state is known at parsing (you have no side effects) 12:50:32 It doesn't matter. 12:50:55 however, because Forth allows them - all written is not really applicable to Forth (at least standard Forth environments) 12:51:04 O'Caml, which was main target of Leroy, _is_ a "concatenative" language at his consideration level. 12:52:08 if he thinks so... 12:52:18 fine 12:52:39 (I must not agree with any opinion) 12:52:52 * ASau shrugs. 12:53:10 to be more precise, let me read his publications first 12:54:00 I can not relate on an argumentation which I do not know in detail 12:54:41 probably his argumentation is valid and we talk here around different nomenclature 13:01:12 I'm not sure what you can contend there. 13:01:31 He has come up with several strategies, implemented all of them, and compared run time. 13:02:52 Leaving program in curried form has turned out worse than passing more arguments to the original function. 13:03:23 Optimising closure construction didn't help enough. 13:04:16 To contest the result, you should come up either with new data (e.g. measurements on modern machines) 13:04:28 or you have to invent something really new and effective. 13:08:45 my point about currying was that this transformation reduce intermediate stack usage 13:09:34 Yes, but the price is increased heap usage. 13:10:30 You need to create the intermediate closure somewhere. 13:10:34 If it isn't stack, it is heap. 13:13:33 Besides, you have stack usage decrease this way only when you drop parameters. 13:13:40 This isn't always possible. 13:15:08 no, because these small stack can be efficiently transformed into a sequence of compiled machine code which accesses a set of native registers simply by static sheduling. Because the register content is known at compilation time, heap accesses can be transformed thereby on the fly by insertion. 13:16:04 the resulting code is quite efficient 13:16:56 at least executed on common multiscalar out-of-order CPU architectures 13:17:20 If you're talking about that, then de-currying gives you more space for static scheduling. 13:22:04 there are CPU's out there which are not known for there large register file. In case of need for a more sophisticated register scheduling (which means at last register copying or local stack frames) this would resulting in a larger overhead decreasing performance if implemented static 13:22:41 that make more sense for JIT compilers 13:22:59 probably 13:23:24 however, I want to avoid the ressource overhead for this 13:23:55 If scheduler hits the limit, then there's no gain, if it doesn't hit, there's gain. 13:24:25 probably, it depends on the code 13:24:51 That's why de-currying only improves, unless you drop enough parameters to outweigh currying overhead. 13:25:46 for my design (which executes whole instruction bundles) the overhead is not worth the effort 13:30:44 --- quit: fantazo (Quit: Verlassend) 13:31:28 if the O'Caml interpreter differences here, I do not know but chances are high, I would say 13:31:55 anyhow; Let me read that paper 13:31:59 ciao 13:32:05 --- part: Mat4 left #forth 14:21:18 --- quit: pgomes (Quit: Leaving) 14:27:50 --- quit: proteusguy (Ping timeout: 264 seconds) 14:33:45 --- join: proteusguy (~proteusgu@ppp-110-168-229-22.revip5.asianet.co.th) joined #forth 14:33:46 --- quit: true-grue (Read error: Connection reset by peer) 14:43:32 --- quit: proteusguy (Ping timeout: 272 seconds) 14:57:25 --- join: proteusguy (~proteusgu@ppp-110-168-229-22.revip5.asianet.co.th) joined #forth 15:08:33 --- quit: impomatic_ (Ping timeout: 244 seconds) 15:09:22 --- quit: impomatic (Ping timeout: 255 seconds) 15:23:45 --- quit: nighty^_ (Ping timeout: 240 seconds) 15:24:52 --- join: nighty^ (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 15:37:34 --- quit: vanila (Quit: Leaving) 15:40:11 --- join: impomatic_ (~digital_w@88.98.199.146.dyn.plus.net) joined #forth 16:46:12 --- join: mnemnion (~mnemnion@67.164.37.196) joined #forth 16:47:37 --- join: saml_ (~saml@pool-71-190-3-251.nycmny.east.verizon.net) joined #forth 16:53:33 --- quit: saml_ (Ping timeout: 258 seconds) 17:07:04 --- join: saml_ (~saml@pool-71-190-3-251.nycmny.east.verizon.net) joined #forth 17:11:24 someone here was asking about belt machines http://millcomputing.com/docs/belt/ 17:12:48 --- quit: Zarutian (Quit: Zarutian) 17:13:16 --- quit: mnemnion (Remote host closed the connection) 17:13:52 --- join: mnemnion (~mnemnion@67.164.37.196) joined #forth 17:18:42 --- quit: mnemnion (Ping timeout: 272 seconds) 17:22:58 --- join: mnemnion (~mnemnion@67.164.37.196) joined #forth 17:31:07 --- join: kumul (~mool@adsl-64-237-237-249.prtc.net) joined #forth 17:36:02 --- quit: mnemnion (Remote host closed the connection) 17:36:34 --- join: mnemnion (~mnemnion@67.164.37.196) joined #forth 17:40:57 --- quit: mnemnion (Ping timeout: 255 seconds) 18:13:20 --- quit: ErhardtMundt (Ping timeout: 240 seconds) 18:14:42 --- join: ErhardtMundt (~quassel@93-43-163-57.ip92.fastwebnet.it) joined #forth 18:16:22 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 18:17:22 --- quit: kumul (Quit: Leaving) 18:58:18 --- quit: cataska (Read error: Connection reset by peer) 19:09:38 --- join: vanila (~user@unaffiliated/vanila) joined #forth 19:20:38 --- join: cataska (~cataska@118-163-69-1.HINET-IP.hinet.net) joined #forth 19:47:42 --- join: protist (~javery@158.253.69.111.dynamic.snap.net.nz) joined #forth 19:54:20 --- join: samrat (~samrat@123.236.183.195) joined #forth 20:24:50 --- quit: saml_ (Quit: Leaving) 20:36:15 Mat4, ASau appreciate any links/references to said papers. 20:42:14 --- join: spoofer (~cruella@72.10.28.164) joined #forth 20:51:09 --- quit: xyh (Ping timeout: 265 seconds) 20:51:33 --- quit: samrat (Quit: Computer has gone to sleep.) 20:57:08 --- quit: proteusguy (Remote host closed the connection) 21:16:41 --- join: proteusguy (~proteusgu@180.183.139.197) joined #forth 21:44:30 --- join: samrat (~samrat@61.12.96.226) joined #forth 21:45:31 --- quit: spoofer (Remote host closed the connection) 21:51:10 --- quit: samrat (Ping timeout: 255 seconds) 21:55:25 --- join: samrat (~samrat@182.72.122.6) joined #forth 21:59:41 --- quit: samrat (Ping timeout: 240 seconds) 22:02:27 --- join: samrat (~samrat@182.72.122.6) joined #forth 22:09:15 --- quit: samrat (Ping timeout: 255 seconds) 22:10:30 --- join: samrat (~samrat@182.72.122.6) joined #forth 22:15:16 --- quit: samrat (Ping timeout: 265 seconds) 22:16:40 --- join: samrat (~samrat@182.72.122.6) joined #forth 22:33:35 --- quit: samrat (Ping timeout: 258 seconds) 22:35:49 --- join: samrat (~samrat@182.72.122.6) joined #forth 22:47:30 --- quit: samrat (Ping timeout: 264 seconds) 22:50:16 --- join: samrat (~samrat@182.72.122.6) joined #forth 22:51:52 --- join: Bahman (~Bahman@84.241.8.144) joined #forth 22:59:15 --- quit: samrat (Ping timeout: 256 seconds) 23:00:42 --- join: samrat (~samrat@182.72.122.6) joined #forth 23:17:17 --- quit: samrat (Ping timeout: 240 seconds) 23:30:33 --- join: samrat (~samrat@182.72.122.6) joined #forth 23:51:57 --- quit: proteusguy (Ping timeout: 256 seconds) 23:58:22 --- quit: Bahman (Ping timeout: 272 seconds) 23:59:59 --- log: ended forth/14.11.24