00:00:00 --- log: started retro/12.03.20 02:09:45 --- quit: virl (Remote host closed the connection) 03:52:18 __tthomas__: toNumber can be revectored 03:53:08 __tthomas__: you'll probably need to modify isNumber? as well for that 05:32:27 --- quit: SimonRC (Ping timeout: 240 seconds) 05:32:27 --- join: SimonRC (~sc@fof.durge.org) joined #retro 07:00:46 --- join: retro-commits (~retro-com@sh1-ext.rs.github.com) joined #retro 07:00:46 [retro-language] crcx pushed 1 new commit to master: http://git.io/sAViIg 07:00:46 [retro-language/master] add 'cleaner' target to Makefile - crc 07:00:46 --- part: retro-commits left #retro 08:21:42 --- join: virl (~virl__@85-127-158-92.dynamic.xdsl-line.inode.at) joined #retro 09:00:22 --- join: __tthomas__ (~tthomas@slosvr6.aeromecheng.com) joined #retro 10:21:02 __tthomas__: toNumber can be revectored 10:28:44 --- quit: virl (Remote host closed the connection) 10:47:41 <__tthomas__> cool, I remember you were changing some of the core words to decrease space.. 10:49:25 <__tthomas__> s/decrease/increase 11:13:18 yes, but all visible colon definitions remain revectorable 11:13:41 internal, hidden ones (e.g., between {{ and ---reveal---) are not 11:15:36 <__tthomas__> Okay, that makes sense.. 11:16:09 <__tthomas__> is it ever possible to use a hidden word outside of {{ ---reveal--- ? 11:36:11 not without doing bizarre things like leaving an xt on the stack and manually creating a call to it later 11:41:24 : isRevectorable? ( a-f ) xt->d dup [ [ @d->class &.data <> ] [ @d->xt @+ swap @ [ 0 = ] bi@ and ] bi and ] ifTrue ; 11:41:54 pass this an xt, and it'll give a flag indicating if a word can be revecored 11:58:28 --- join: retro-commits (~retro-com@sh1-ext.rs.github.com) joined #retro 11:58:28 [retro-language] crcx pushed 1 new commit to master: http://git.io/KQ_aog 11:58:28 [retro-language/master] add introspection' library - crc 11:58:28 --- part: retro-commits left #retro 12:15:48 <__tthomas__> Cool, I might write a vocabulary for temp dictionary's using buffer then.. 12:16:52 <__tthomas__> currently trying to write a proper implementation of /* which is way harder than I thought, mostly keeping the carry and add's straight in my head is giving me trouble.. 12:17:01 <__tthomas__> */ I mean.. 12:34:49 --- join: Mat2 (5b4085c5@gateway/web/freenode/ip.91.64.133.197) joined #retro 12:34:59 hi @ all 12:35:17 <__tthomas__> hi 12:36:39 hi ! 12:37:08 what's new ? 12:38:22 <__tthomas__> not much, was working on double cells for multiplication.. 12:38:47 <__tthomas__> I worked on it for like 3 hours and didn't really get anywhere.. 12:40:11 hmm, what platform ? 12:40:27 <__tthomas__> retroforth, library.. 12:40:52 <__tthomas__> I think going to switch to nibble implementation, make it easier to verify if it is correct.. 12:42:11 can you give me a code snipped, please ? 12:43:31 <__tthomas__> I don't really have any handy... but basic concept is multiply 2 cells together and get result in 2 cells.. 12:45:55 implement classic carry adder as base 12:46:05 <__tthomas__> So I was doing LowWord LowWord * which returns result plus carry, where LowWord is defined as 16 >> 12:46:37 <__tthomas__> Yeah, I implemented a 16 bit multiplay with carry, but numbers were so large I couldn't tell if they were right.. 12:47:28 <__tthomas__> So I am going to implement a 4bit multiply with carry to test first since numbers are saner to look at.. 12:48:14 <__tthomas__> : LowWord $FFFF and ; : HighWord 16 >> ; 12:48:21 <__tthomas__> had it backwards.. 12:49:34 ok, 12:49:43 should work 12:50:06 i see no error with the results 12:51:03 <__tthomas__> It is the shifting adding and deciding where to store the results and how to organize the code where I am having difficulties, I thought it might be language tripping me up at first, then realized was having same issues organizing it in C.. 12:53:02 I had stored both results in two variables 12:55:48 <__tthomas__> Yeah, I tried that, but this is 4 terms, 2 16bit on top, 2 16bit on bottom.. I think I am just making it harder than it is, probably what I get for trying to code while watching television.. 12:57:42 then skip watching tv 12:57:51 <__tthomas__> heh.. :) 12:58:10 * crc does most of his coding while involved in other activities 13:00:45 <__tthomas__> I found a cool article by Leo Brodie in forth dimensions that had an 8 line library for working with fixed point, so I ported it and borrowed parsing word from decimal.rx, it works super awesome, but precision is very low, so I decided to try and get a full implementation of */ working.. Though my version is probably about as precise as his considering he was probably working on a 16bit platform.. :) 13:01:18 is that code in your repo? 13:01:37 <__tthomas__> Nope, but I can add it, I just have to rename it.. It is still named decimal.rx 13:02:36 fixed.rx :) 13:02:46 would be nice 13:07:52 I have here a good fixed point arithetic library written in Pascal which would be easy to port 13:09:15 the question is: What precision have Leo Brodies lib ? 13:11:50 the precision of the Pascal lib is: +/- 2147483647 * E10 13:12:53 <__tthomas__> Nice, not sure how precise it is.... but useage is nice... can do things like 8 1 2 /. *. putn 13:12:59 <__tthomas__> which returns 4 13:13:36 <__tthomas__> also supports standard d0.4000 d1.2000 *. .F 13:15:00 looks good :) 13:15:02 <__tthomas__> cool, merged and committed.. 13:15:25 <__tthomas__> I thought the fractions and being able to combine float and integers made it really cool.. 13:16:38 <__tthomas__> I have a dump implementation in there as well that works pretty well.. 13:16:50 --- join: retro-commits (~retro-com@sh1-ext.rs.github.com) joined #retro 13:16:50 [retro-language] crcx pushed 2 new commits to master: http://git.io/u_c6JA 13:16:50 [retro-language/master] [] Added fixed.rx - tthomas@duelcraft2.com <> 13:16:50 [retro-language/master] pull from tthomas, adds fixed', dump utility - crc 13:16:50 --- part: retro-commits left #retro 13:17:59 is dumpVM.rx intended to be a library? 13:19:05 <__tthomas__> Eventually yes, but should be moved right now, as it needs a ton of work.. It is intended to allow running of 16bit images under 32bit retro.. 13:21:06 <__tthomas__> Though I need to implement an array with relative addressing before start working on it again.. 13:21:10 --- join: retro-commits (~retro-com@sh2.rs.github.com) joined #retro 13:21:10 [retro-language] crcx pushed 1 new commit to master: http://git.io/JjLQqw 13:21:10 [retro-language/master] move debugVM.rx to incoming/ - crc 13:21:10 --- part: retro-commits left #retro 13:23:32 what is better ? Multiply instruction or add+carry and shift operations ? 13:24:41 I've implemented add+carry and left multiply and division instructions out 13:25:56 as result, the instruction set have now only 16 opcodes and I can combine two for bulding static superinstructions 13:26:38 without effort reducing dispatch overhead ~50 % 13:27:23 so far 13:28:07 test: 13:34:11 <__tthomas__> I haven't done enough to say for sure, but doesn't add with carry require you to add in a loop with a counter? 13:36:40 --- join: virl (~virl__@85-127-158-92.dynamic.xdsl-line.inode.at) joined #retro 13:39:56 i'm not sure about your question but think in counted loops the counter need to be incread or decreased so the answer is yes 13:41:37 <__tthomas__> so if you were doing add with carry of 20 * 5, would have to run through loop 5 times, adding 20 through each iteration.. 13:45:37 I would use another algorithm: shift+carry, decreasing the iterations to 0 for all results multiple of 2 13:46:09 <__tthomas__> So shift twice add once in this case.. 13:46:39 sorry, yes 13:47:52 for most cpu architectures this solution is as fast as the hardware instructions for this purpose (with exception: Intel processors) 13:49:33 <__tthomas__> I can see that.. 13:51:00 simple dispatch test: 13:51:22 <__tthomas__> I would think the hard part would be determing how much to shift what.. like 20 * 20 would be 20 << 4 + 20 << 2 13:53:28 old ngaro version: 0m3.989s, new vm: 0m0.976s, ngaro-threaded: 0m1.436s 13:53:48 <__tthomas__> whats that? 13:54:14 performance test between ngaro current and my experimental new vm 13:54:57 $FFFFFF iterations counting 0 -> n = n+1 13:55:39 <__tthomas__> I just realized recently how slow the python version really is.. On my netbook running python version is visibly slow when using needs 13:55:41 the new one has 16 instructions combining two slots into an 8 bit opcode 13:56:21 <__tthomas__> Cool, what language was it implemented in? 13:56:37 assembly and a C version 13:57:49 problem is: I must port retro from scratch 13:58:00 <__tthomas__> heh, why? 13:58:26 the new instruction format is all but compatible with nagros's 13:58:57 __tthomas__: use pypy if possible, it's much faster than cpython is 13:59:36 <__tthomas__> crc yeah, I just started compiling c version, appartently when I compiled c version via commandline I compiled with debug info last time.. it is only a 13K executable and pretty fast now.. 14:00:56 <__tthomas__> Mat2 couldn't you write a dictionary for machine words and have retro compile the core words for you? 14:02:57 not so simple because each opcode has two instruction slots and 8 or 4 opcodes abre bundled into a VLIW like word 14:03:28 it is also a harvard design 14:03:43 but i'm making progress 14:04:15 <__tthomas__> ah, so architecture similar to streamer16 and c18 14:04:22 yeah 14:05:24 <__tthomas__> I had thought about that, but figured it would be slower, I guess it is probably cheaper to shift a register than grab a new address everytime.. 14:06:26 it is 14:07:28 much less cache stress 14:07:29 <__tthomas__> Though I would think the normal case wouldn't be that different as stack operations and fetches are still going to eat up quite a bit of your execution time.. 14:08:45 the main advantage overwhelming all other is: You can reduce the dispatch overhead because instructions can now be freely executed as bundles 14:09:54 memory acceses are reduced too because of the harvard design I can cache immediate parameter in registers 14:10:16 tike tos 14:10:41 <__tthomas__> c18 gets away with 18 bit instructions easily since it only has 64 bits of addressable ram or rom.. so anything can fit inside its instructions.. 14:12:06 the old i4004 has the same advantage, all 16 immediate combinations where included as instructions 14:12:29 so no need for immediate loading 14:12:53 <__tthomas__> nice.. 14:13:34 my vm hold immediate parameter in the first level cache 14:14:36 ok, now I need an assembler for the vm 14:15:20 I think retro is a good fit for this 14:15:29 <__tthomas__> crc's ngaro assembler is pretty easy to follow, I am sure you could use it plus could use retro for macro language so would make porting a bit easier.. 14:16:27 I plan a moniter like assembler with full-screen editor like on old commodore home-computers 14:16:30 <__tthomas__> Maybe you will come up with ingenious porting scheme and we can use it with map/reduce algorithms to generate native code.. :P 14:17:18 nice idea 14:18:03 <__tthomas__> Or parial evaluation which I still don't really understand.. 14:18:31 <__tthomas__> partial evaluation I mean 14:18:59 don't know the term 14:19:20 <__tthomas__> It is an algorithm for automatically generating specialized compilers for interpreters.. 14:19:47 --- join: Kumul (~Kumul@adsl-72-50-91-28.prtc.net) joined #retro 14:20:16 a something like vmgen 14:20:32 (terrible source code by the way) 14:21:15 <__tthomas__> *shrug* I have a pdf on it, but I can't make heads or tails of what they are talking about.. 14:23:56 nothing to worry about, I bet most text is science-typical meaningless overhead 14:26:27 (I know about it, because that's the kind of publication I spend years on formulating for money as sidework) 14:27:26 and the main requested criteria for such publications was all but clear and precise formulation... 14:28:09 <__tthomas__> This is an old technique from 60's used to generate lisp compilers.. 14:29:31 <__tthomas__> It is full of math notation that I don't quite grok.. 14:31:03 <__tthomas__> http://en.wikipedia.org/wiki/Partial_evaluation 14:34:32 <__tthomas__> I do a lot of work for the military, so I know all about how painful documentation can be.. 14:35:47 --- quit: virl (Remote host closed the connection) 14:38:51 ok, as I see it it's simply another word for a technique I know from functional programming langauges 14:40:12 transorm a source form into some kind of code applicable for an optimizated compiler created for it 14:44:29 <__tthomas__> There is definitely a disconnect between how much code we write and how much is generated, its complex and a little scary.. 14:46:28 speaking for forth the idea is: Write a minimal vm and building the language on top of it, increasing it abstraction level at demand 14:47:08 in the ideal case porting mean changing some assembly routines 14:47:16 <__tthomas__> Yeah, and compilation happens immediately, so you can inspect what was generated and optimize your algorithms.. 14:47:43 <__tthomas__> ngaro is one abstraction apart, but it is a good abstraction, makes portability trivial.. 14:48:19 <__tthomas__> I would still love to see eforth running on ngaro, think that would be such a cool project.. 14:48:19 the functional folk get the same result but with much more code effort, call it an academic resultion 14:48:47 sorry solution 14:49:03 who had written eForth ? 14:49:36 <__tthomas__> well, Lisp is dependent on linked lists which ends up taking up tons of memory.. Though code can fit solutions nicely.. 14:51:02 that's right 14:53:22 <__tthomas__> http://www.forth.org/eforth.html There are lots of implementations.. I like the zenforth write up.. It is very detailed.. 14:55:59 looks interessting, the dispatch routine is quite slow though 14:56:27 resembles me of chforth 14:57:04 <__tthomas__> I think forth got it's bad reputation from 8bit micro days.. People were resource constrained so used tiny nondescriptive names for words and tried to write shortest code possible, so it ended up being largely unreadable.. 15:00:21 hmm, I think the main problem for forth is that it's design philosopy is so unconventional 15:00:41 like UPN 15:01:12 <__tthomas__> it is modeled after language imo.. you have words that are well defined, and you combine them to define new words.. 15:02:25 <__tthomas__> the lack of syntax and compile errors might scare people off too.. :) 15:02:57 tht's what make it attractive to me :) 15:03:04 that's 15:03:59 <__tthomas__> for me is the fact that it hides nothing from me, I have direct control over stacks, memory, how words are compiled into memory.. I can learn the whole system and customize it for my own use.. 15:04:12 in forth I can create a language which implied the solution for my problem and abstract from this for solving similar problems without extra effort 15:04:58 Mr. Moore call this factoring 15:05:22 <__tthomas__> Brodie called this decomposition I believe.. 15:06:58 <__tthomas__> composition, decomposition and factoring are tightly related.. 15:07:08 yes 15:08:23 another aspect is: I can program in a functional way without syntax limitation 15:09:11 <__tthomas__> having direct access to the parser is a huge boon, why rewrite a parser when you can just use the one your language comes with.. 15:12:50 right 15:13:24 but uncommon for programmers of conventional languages 15:28:28 new test: ngaro: 0m22.597s, new vm: 0m0.920s 15:29:17 some dispatch optimisations 15:29:48 and inclusion of fused opcodes 15:30:55 I will spend some time on assembler hacking, ciao 15:31:02 --- quit: Mat2 (Quit: Page closed) 16:18:30 --- join: Raystm2 (Raystm2@c-71-196-164-161.hsd1.co.comcast.net) joined #retro 16:18:38 Hi all! 16:19:43 crc , Hi! making progress. reporting that I took your advice at your webpage, started a Launchpad account ( still have to get ssh keys) and just intalled a windows version of Bazzar. 16:19:58 After getting keys, i'll install a local branch. 16:21:01 In a day or two, I'll be up to the I/O tutorials, and start coding the file-i/o stuff to the java implementation. 16:21:47 everyday I take a look at your other language versions to be sure I know what is required for java. 16:22:08 Looks like all 'port[4] stuff, far as I can tell. 16:22:27 Please advise if there is any differences. 16:25:27 I'm a bit newb to versioning, but I assume what is done is that, since your java already works, we branch my work until tested and then merge at a later date? 16:39:25 hi ray 16:41:46 if you'ree looking ag the omplementations, the C and the Python have the most testing (by me) 16:41:59 hmm, odd typos there 16:42:27 --- quit: Kumul (Remote host closed the connection) 16:43:10 regarding versioning: you'll commit and push to your branch, and I can merge your changes into the main source tree as needed 16:50:54 FULL ACK 16:51:18 just now learning about ssh keys. 16:51:46 goal is to be all set up and ready before Nan want the computer tonight. :-) 16:52:03 ok 17:26:23 --- join: retro-commits (~retro-com@sh1-ext.rs.github.com) joined #retro 17:26:24 [retro-language] crcx pushed 1 new commit to master: http://git.io/_auTew 17:26:24 [retro-language/master] remove excess whitespace in fixed' - crc 17:26:24 --- part: retro-commits left #retro 17:47:37 --- part: __tthomas__ left #retro 18:26:38 crc is there a Retro Language team to join? Does not appear to be a link to join a team. Is that even necessary? 18:29:24 no 18:29:42 --- join: retro-commits (~retro-com@sh1-ext.rs.github.com) joined #retro 18:29:42 [retro-language] crcx pushed 2 new commits to master: http://git.io/Uc0tZQ 18:29:42 [retro-language/master] don't autoinclude subcell' when loading it initially - crc 18:29:42 [retro-language/master] whitespace reduction, minor tweaks to dump' - crc 18:29:42 --- part: retro-commits left #retro 18:35:07 okay, thank you. 18:35:19 currently building local. 18:45:59 I'm working through the latest commits, cleaning up excess whitespace and contemplating the mysteries of unsigned numbers 19:00:47 --- join: retro-commits (~retro-com@sh2.rs.github.com) joined #retro 19:00:47 [retro-language] crcx pushed 2 new commits to master: http://git.io/BSnebQ 19:00:47 [retro-language/master] update the release notes - crc 19:00:47 [retro-language/master] whitepace policing, minor tweaks to vectorAdd example - crc 19:00:47 --- part: retro-commits left #retro 19:14:43 time for a new cygwin. back tomorrow, GN :) 19:14:54 --- quit: Raystm2 (Quit: bye!) 20:14:17 --- join: roarde (~roarde@pdpc/supporter/active/roarde) joined #retro 22:58:22 --- quit: roarde (Quit: Leaving) 23:03:58 --- join: virl (~virl__@85-127-248-189.dynamic.xdsl-line.inode.at) joined #retro 23:30:26 --- quit: virl (Remote host closed the connection) 23:59:59 --- log: ended retro/12.03.20