00:00:00 --- log: started retro/10.01.06 01:42:32 --- join: virl (n=virl__@chello062178085149.1.12.vie.surfer.at) joined #retro 02:00:38 Hi Virl 02:01:03 hi, what are you doing? 02:02:02 not much, just messin around... wrote an even faster, but 2 cell longer, version of compare in retro. Working on making it both faster and shorter. 02:02:25 I can if I only had a do/while loop... and being it's forth, I decided to make one. 02:04:24 Found a nasty bug (in my opinion) in the retro kernel forth code. 02:04:56 try : foo 3 3 What are you up to? 02:14:38 --- join: Mat2 (i=5b43e0e4@gateway/web/freenode/x-zbkdfozyanbicdsn) joined #retro 02:14:54 G'Day 02:15:04 Hi Mat, what's up? 02:15:25 i'm coding on my functional colorforth dialect 02:15:42 and have finished the native-code compiler part 02:16:26 coolo 02:16:31 * Mat2 want to metacompile ngaro from this if it's finished * 02:16:53 uh... meta compile retro? 02:17:04 is there a colorforth version of the ngaro vm??? 02:17:28 not finsihed yet 02:17:43 I have a OK ngaro done in emacs lisp. Needs a few tweeks before I check it in. 02:18:11 nice, how have you handled the stacks ? 02:18:38 (defvar ngaro-mem nil "The memory image of the current ngaro VM. There can only be one.") 02:18:38 (defvar ngaro-memsize 0 "The size, in 29bit cells, of the memory image.") 02:18:38 (defvar ngaro-dstk (make-vector 99 0) "The data (aka parameter) stack of the current ngaro VM.") 02:18:38 (defvar ngaro-rstk (make-vector 99 0) "The return (aka address) stack of the current ngaro VM.") 02:18:38 (defvar ngaro-dsp 2 "Index of the top element of the data stack.") 02:18:38 (defvar ngaro-rsp 2 "Index of the top element of the return stack.") 02:18:54 memory is a vector of 29 bit ints. 02:19:12 Can barely load a normal image. Can easily load a --shrink one. 02:19:18 hmm, the performance would interesst me 02:20:14 you have a good performance measuring tool? For me the bytecompiled version feels almost slow, the interpreted emacs lisp version is too slow for anything but debugging or a toy. 02:21:27 to answer your lost question yesterday: I have written an extended ngaro vm with an AOT compiler which compiles an platform independend assembly language (accumulator store ISA) into new primitves 02:21:48 this way the interpreter can be extended at runtime 02:22:56 I don't know "AOT" 02:23:06 Ahead Of Time compiling 02:23:43 For performance tests I use X-nix time command 02:24:08 OK, my compare is 1 cell shorter, and since it makes no calls it is much faster. 02:24:51 my string compare in retro forth, compared to the one in the kernel. 02:25:31 it's not really pretty forth though. 02:27:25 you can take a look at the extended vm, the interpeter is optimated also and uses a replicated-switch threading for dispatch. It's performance is en par with gforth on my machine for some tests 02:28:47 I have to take off, back in a while. Have fun! 02:29:00 ciao 02:30:42 --- part: Mat2 left #retro 03:57:55 --- join: crcx (i=d8012b82@gateway/web/freenode/x-mcpidkemobarvsco) joined #retro 04:28:32 Hi crcx: 04:34:07 hi js4 04:35:29 So did you see my stuff about yes 04:35:42 also... I am trying to make my unit test tools better. 04:35:57 I'm currently looking into it 04:37:01 My code is still untested, but is close I think... 04:37:02 t: t->if ( R: xy- C: -a ) 04:37:02 10 # t-, t-here 2 # + t-, 8 # t-, (if) ; 04:37:02 t: t- 11 # t-, t-here 2 # + t-, 8 # t-, (if) ; 04:37:23 Also if you have a couple minutes to help me with a howto type question? 04:37:30 sure 04:38:07 I am trying to make a compile time word to build up a lit of test words to run. Later at run time run them all one by one. It'f for my unit test tools. 04:39:02 What I am trying is: compile code to call the current value of variable foo, then save my xt in foo, then let : take over. 04:39:23 : (rut.add) last @ d->xt rut:suite @ swap rut:suite ! literal, ` execute ; compile-only 04:40:32 then... 04:40:39 : t.rut.x=1 (rut.add) 0 1 rut.x= ; 04:40:39 : t.rut.x=2 (rut.add) 0 0 rut.x= ; 04:40:59 And t.rut.x=1 has a good call to the stub for the first test. 04:41:08 But t.rut.x=2 doesn't. 04:41:34 ok see t.rut.x=1 04:41:34 7858 nop 04:41:34 7859 nop 04:41:34 7860 lit 7467 ( rut.first.test ) 04:41:34 7862 call 197 ( execute ) 04:41:34 7864 lit 0 ( FALSE ) 04:41:36 7866 lit 1 04:41:38 7868 lit 7848 04:41:40 7870 call 7605 ( (rut.x=) ) 04:41:42 7872 ; 04:41:44 ok see t.rut.x=2 04:41:46 7886 nop 04:41:48 7887 nop 04:41:50 7888 lit 7847 04:41:52 7890 call 197 ( execute ) 04:41:54 7892 lit 0 ( FALSE ) 04:41:56 7894 lit 0 ( FALSE ) 04:41:58 7896 lit 7876 04:42:00 7898 call 7605 ( (rut.x=) ) 04:42:02 7900 ; 04:46:03 This does the same thing, might be easier to understand... 04:46:04 : (rut.add) rut:suite @ literal, ` execute last @ d->xt rut:suite ! ; compile-only 04:46:30 you have to fetch the xt after d->xt 04:46:36 oh 04:47:11 Yay! It works!! 04:47:17 Thank you. ^_^ 04:47:24 no problem 04:48:11 Also... I got my string compare down to 30 cells, 1 less than the one in the kernel, and it makes no calls at all. Pure VM 'assembly' code. To do it I made do =while. 04:48:29 This is the final ugly result... 04:48:46 : comp ( $$-f) 04:48:46 [ here ] 04:48:46 dup @ push 1+ swap 04:48:46 dup @ push 1+ pop dup pop swap 04:48:46 !if drop drop dup xor ;; then 04:48:46 0 [ 12 , , ] 04:48:48 drop drop -1 04:48:50 ; 04:49:33 the stuff in [ ] is what do =until would compile/do 05:03:08 [ here ] = repeat 05:05:11 : =until 12 , , ; compile-only 05:09:38 yep that works. I just didn't want to give you code that would increase the size of the core. My ugly version will make the core 1 cell smaller. 05:09:56 : do here ; compile-only 05:09:56 : =until 12 , , ; compile-only 05:10:23 but yeah, prolly should just use repeat 05:10:47 Don't need yet another crazy looping word. 05:11:32 I would never spend this much time, or write such inpenetrable code if it weren't the innermost loop of a critical part of the core. 05:18:53 [crcx/retro10] 132777: faster, tighter "compare" from js4 05:19:11 oooo, you like it? 05:19:24 yes 05:19:30 I am working on making a nice unitest tool set, then writing unittests for all the words in the core. 05:19:38 I left the old definition as a comment in the source 05:19:45 Right now I am stumbling over.... 05:20:14 : rut: create .word (rut.add) ( call : sorta ) ; immediate 05:21:20 usage will be (include blob) rut: t1 .... rut.x= ; rut: t2 ... ; rut.run forget rut 05:22:14 I already have code that will print the name of the word that fails a test. You just got me going so rut: can build up a list of tests and rut.run can run them all. 05:23:12 --- quit: virl (Remote closed the connection) 05:23:33 All of this project fails a big rule of good forth code: avoid writing state smart words. 05:24:54 : rut: create ['] .word reclass ] ` (rut.add) ; 05:25:31 O.O Thankyou /me goes to try it... 05:25:57 no immediate ? 05:26:05 no 05:27:29 coolo! Now updating my ll tests and compare tests 05:27:45 I'll add this to the contrib ofcourse... 05:40:50 cool 06:25:23 js4: regarding if; they have worked this way for two years now 06:25:52 yep 06:26:13 : test 3 3 You *could* just define same with > 06:27:01 >if does >=if 06:27:10 I'll note the behavior in the docs 06:27:25 I actually should have done that a long time ago... 06:28:12 yep, like dropping or not dropping if's -- long as it's documented what it does, it's not wrong. 06:28:40 or the deeper and longer discussion about the colorforth switch to rings instead of stacks. 06:28:53 [crcx/retro10] 6f7e46: if are actually = in behavior. no... 06:29:37 I might actually change to rings in the future 06:30:09 your additions will help with that :) 06:30:21 My statistics measuring shows that 64 is probably big enough for like almost all programs. 06:31:11 Though the current definition of rut: takes advantage of the fact that the stack is 1024 deep ^_^ It's a very hacky trick I am using. Should do something better... 06:31:18 but it's just unit tests... 06:32:28 btw, unit tests are a great way to document how code behaves. 06:33:10 rut: 3<3 3 3 uh oh... looks like there might be a bug lurking somewhere... either in my new rut: stuff... or in that string compare... 06:36:51 or in my unit tests. always a possibility... 06:37:25 code? 06:40:17 ok, you can relax! I typoed my compare when changing to the rut: tests ^_^ 06:41:13 06:41:14 ok rut.run ................................................................................. 06:41:14 06:41:14 OK passed 81 tests of 81 trials. 06:41:14 06:41:14 ok 06:41:42 That's the string compare unit test code there... 06:44:10 * crcx is looking forward to this 06:44:44 to what? 06:44:54 [js4/retro10] 0f4f6c: faster, tighter "compare" from js4 06:45:50 unit tests 06:47:38 well, I have to get right up to the tip, rebuild and retest everything, then I'll check in. 06:47:52 [js4/ngaro] e26fa5: minor speedup from js4 06:48:13 I'm about a day behind and might be about to spam the channel, sorry. 06:48:26 that's fine 06:52:51 OMG! 06:53:07 before the change to compare: 06:53:08 3939329 | 9 | VM_RETURN 06:53:20 after 06:53:21 937255 | 9 | VM_RETURN 06:53:43 3,000,000 call/return's taken out of building the image! 07:02:11 that alone makes it worth using your implementation 07:03:44 I only have one regret about it... it's not really all that forth like a blob of code now. Number 2 opcode these days? DUP. 07:04:44 And I know it's the change to that single word that made the difference. Sigh... I dunno what the heck I'm gonna use for a 'good' profile of 'real' forth code. I'll keep looking... 07:16:14 ah, beautiful. it's almost pure ngaro assembley now :) 07:17:25 ^_^ Yep, the first paid gig I ever got was assembly. Like I said, It's kinda sad to so radically "deforth" that part... but it makes a big performance improovement. 07:17:44 crc's code was really pretty. 07:19:15 yeah, but with inner loops changing it to assembley is what you are supposed to do 07:19:32 on the other hand, maybe it could be re-prettied with macros? 07:20:38 --- join: Mat2 (i=5b43e0e4@gateway/web/freenode/x-cwacrujvbnstzlef) joined #retro 07:20:47 hello again 07:20:54 hi Mat2 07:21:04 hi ! 07:21:07 Hi Mat 07:21:10 docl: the readable version is still there as a comment block 07:21:19 what's going on ? 07:21:23 And the algorithm is almost the same... 07:21:31 cool 07:22:01 hi crcx 07:22:35 Mat2: we added a faster string comparison word in retro. It cuts 3,000,000 call operations out of rebuilding the image. 07:22:49 wow, that's great 07:23:48 * Mat2 will benchmark the new image with his vm * 07:24:41 * sorry, the rebuilding time * 07:24:55 also, js4 is working on code for unit tests 07:26:54 i'm currently testing out a new calling cheme for the ngaro compiler part. It uses x64-64 feature for RIP relative addressing for fast call though linking 07:27:07 lea r12, [rip+2] 07:27:16 jmp address 07:27:22 return: 07:27:25 jmp r12 07:27:50 on AMD cpu's this lead to a hugh performange increase 07:29:15 and the boost seems to be remarkable on Intel cpu's too 07:29:19 very cool, cause something like 20-33% of all opcodes in forth is call or return. 07:29:50 but... where's the stack? I don't understand that instruction 07:30:16 is that the next routine? 07:30:56 the stack is only involved for nesting level > 1 just like with most RISC cpu's 07:31:17 how do you know when you are going to level 2? 07:31:29 (the compiler checks the stack state at compile time 07:31:31 ) 07:31:45 that's possible because it is a AOT compiler 07:31:46 oh... very nice. 07:32:32 the new vm uses subroutine threading 07:33:37 internal 07:33:55 very cool, so you care compiling Ngaro opcodes to intel? 07:34:03 yes 07:34:10 awesome! 07:37:29 the only problem I have is ngaro's divmod opcode because idiv with remainder a damn slow operation 07:38:22 ups, i forgot the is 07:39:45 ups 2: the index was wrong: 07:39:50 jmp rdx 07:40:08 lea r12,[rip+2] 07:40:12 jmp rdx 07:41:57 (the problem is an immediate call have only 4 bytes for it's address field and the caller can be mapped above 4 GB theoretically dependent on the os) 07:42:42 (so the address must be loaded in a regulary register before) 07:43:28 I suppose someday 4GB of Retro will be reasonable... 07:44:32 I just realized I felt relieved that the 32K --shrink image was so small emacs could deal with it like any other file. Then remembered when 48k was all the memory you could put in the computer. 07:45:52 hmm, I think future memory managers will be bound to an vm and the vm will be the kernel like projects like Microsoft's Singularity show. 07:46:20 then an application only operate on references 07:46:37 have you looked at the language E? 07:46:48 you mean Amgige E ? 07:46:51 Amiga 07:48:04 ok, I think you mean this http://www.skyhunter.com/marcs/ewalnut.html#SEC9 ? 07:48:43 http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing 07:49:15 you said "only operate on references" reminded me... 07:49:31 my dream system right now is sorta E mixed with Factor. 07:50:33 there have choosen a good security modell for this language (E) 07:51:13 yep. pretty cool stuff I think... 07:53:38 Erlang have something similar with it's process model I think 07:54:29 I havent read anything about erlang, seen the name many times though. 07:55:28 Erlang is used specially for time critical applications (cell phones, router hardware etc.) 07:55:32 like Forth 07:56:46 (but instead of it with a complex and huge vm as base) 07:57:11 it is optimated for parallel processing 07:57:42 that's a weak point of current forth systems 07:58:23 with excaption of Charles Moores Colorforth for there multi-code cpu's 07:58:30 core 07:59:42 yeah, I look forward to seeing where Charles Moore goes with colorforth and greenarays. 08:01:33 If there found an supporter, say an automobile cartell, than there save, I think 08:03:05 omg: Each character consumes 8 bytes of memory on a 32 bit machine (a 32 bit integer and a 32 bit pointer) and twice as much on 64 bit machines 08:03:45 I sure hope so... but it's a tough time v.v 08:04:21 bad but Ngaro doesn't support byte addressing 08:04:42 a cell can be loaded and the string packed though 08:05:44 lol, I was quoting the erlang faq. It's true though, on a 32 bit machine Ngaro/retro uses 4 bytes per char, on a 64 I bet it is 8 but don't know. 08:06:07 it's 8 byte per character 08:07:45 hmm, packed strings don't make sense with encodings other than ASCII because there need a variable number of bytes 08:08:04 but UTF-16 would be a good target 08:08:12 well, unicode is actually 21bits per character... 08:08:26 I was thinking a 24 bit machine.... 08:08:54 yeah pack and unpack to utf8 maybe, but manipulate the strings as 24 bit chars 08:09:46 do you now the ez80 cpu ? It has 24 bit registers 08:10:03 factor did something kinda cute -- two parallel arrays. One is a normal 8 bit wide array, the other is a sparse array holding the top 16 bits. 08:10:13 No I don't know the ez80 08:10:44 http://en.wikipedia.org/wiki/Zilog_eZ80 08:10:53 Zilogs newest cpu 08:11:23 ok, but handling two arrays can be a little bit slow 08:11:44 (my) ngaro uses 32-bit cells, so it's 4 bytes per cell on both 32-bit and 64-bit systems 08:12:37 yes but my vm cache TOS in a real register and this is 64 bit on x86-64 cpu's 08:12:45 true enough 08:13:06 cool re the ez80. Maybe time to port my jupiter ace ^_^ 08:13:13 one can ignore the upper 32 bits though 08:13:24 you have a Jupiter Ace ???? 08:13:32 ^_^ Yes 08:13:51 I was dieing for one so bad when they were new. 08:14:00 The simulators are pretty nice. 08:14:17 the real deal? Kinda disapointing after many years on modern computers v.v 08:14:57 I stood outside a shop window practically drooling the first time I saw one. 08:14:58 yes, I know what you mean 08:17:07 one bad thing is: Modern Intel cpu's can't even protect there system managment mode so rootkit's can bypass all security options of modern operating systems without there notice 08:17:19 that's rootkit functionality in hardware !!!! 08:17:26 O.O 08:18:24 yeah, Intel make it possible 08:19:10 * I hate Intel cpu's * 08:20:53 and I wonder why my operating systems need GB of ram for things, a Amstrad CPC can do, look: 08:20:56 http://www.symbos.de/ 08:22:01 a microkernel os for 128k ram which make it possible to watch MP3 decoded videos with 24 frames per second 08:22:33 OMG, I am seriously shocked about that SMM thing. 08:23:49 sad, isn't it 08:24:31 http://www.msuiche.net/2008/08/06/smm-rootkit-limitations-and-how-to-defeat-it/ 08:25:53 [crcx/retro10] 1c9f2c: jump to "listen" rather than call it 08:26:23 the SMM mode can be entered from within every application with any privileg level 08:26:49 though some port magic 08:27:09 so a rootkit doesn't need to start at boot time 08:28:16 i'm sorry, but http://www.msuiche.net/2008/08/06/smm-rootkit-limitations-and-how-to-defeat-it/ don't show a way to handle this 08:30:54 [crcx/retro10] 7cd8a8: smaller getLength implementation 08:31:23 time for me to take a break I think, talk to y'all later! 08:31:30 ciao 08:31:44 later js4 08:34:50 @crcx: have you plans for something like ngaro 2 ? 08:35:37 I mean, a reworking of the instruction set 08:35:45 I'm starting to consider that 08:36:59 I have here these prototypical vm with a vliw alike opcode format 08:38:03 if youre interested I can upload some tiny documentation to the newsgroup 08:38:18 please do 08:38:24 ok 08:40:13 so time for some work, possibly read you later again 08:40:23 ok, ttyl 08:40:30 --- part: Mat2 left #retro 08:51:52 [crcx/retro10] e86033: update initial images 09:44:25 --- quit: crcx ("Page closed") 10:24:40 --- join: Mat2_ (i=5b43e0e4@gateway/web/freenode/x-ngkkovlkxkwhgcqc) joined #retro 10:24:57 hello again 10:27:01 @crcx: I have uploaded a poster with the opcode format for the vm (AVM) and written a sort summery of its functionality (the ISA). 10:27:35 bye 10:27:41 --- part: Mat2_ left #retro 11:48:32 --- join: virl (n=virl__@chello062178085149.1.12.vie.surfer.at) joined #retro 15:13:01 [js4/wheke] 0f4ec6: Add some unit test tools 15:14:53 [js4/wheke] f60be0: String compare and unit tests 15:20:54 [js4/retro10] 5623fb: jump to "listen" rather than call it 15:47:51 --- join: erider (n=chatzill@unaffiliated/erider) joined #retro 15:58:46 hi 16:03:38 Hi, whassup? 16:17:40 js4: nothing much and you 16:18:39 was watching http://www.vimeo.com/859408 Interesting content, presentation/quality is low 16:19:08 I checked in some unit test tools and sort of a history of how I came up with that string compare. 16:19:43 maybe I'll finish ngaro.el The compiled .elc runs pretty well now. 16:24:36 ah emacs it once was my favorite 16:24:57 js4: hey do you use msvc for the commandline 16:25:04 what do you use now? 16:25:24 I don't know how do to things with msvc command line. I use cygwin + gcc 16:27:44 js4: I use lcc-win32 16:28:30 I dunno what that is 16:29:53 * js4 reads lcc-win32 website 16:29:56 interesting 16:31:03 it's c? c++? ansi c?? 16:31:13 k&r c? ( just kidding ) 17:02:25 its a free compiler :) 17:25:44 crc: hi 17:26:10 hi erider 17:27:03 fasm is weird assembler I am not even sure if I would classify it as that at all 17:28:10 fasm is a pretty nice assembler actually 17:29:56 it looks more like a higher level language :) 17:30:51 crc: what are you up to today 17:31:02 [crcx/wheke] 5431c6: Add some unit test tools 17:31:19 erider: lots of small cleanups and tweaks 17:31:53 [crcx/wheke] 61484f: move testing stuff to a separate directory 17:35:03 howdy folks 17:35:09 hi docl 17:35:19 what's cooking? 17:35:41 not much yet 17:35:54 js4 checked in the start of the unit testing framework 17:35:56 to wheke 17:36:05 crc: fasm is interesting hehe 17:36:25 erider: the high level stuff comes from macros. you don't have to use them :) 17:53:09 crc: I am not trying to learn it I am just looking at some code 19:08:16 --- quit: erider ("ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]") 19:56:53 [crcx/retro10] 90b5f1: add "jump:" to metacompiler; more efficient code f... 19:59:41 crc: You there? 19:59:47 yes 19:59:51 for another hour or so 20:00:03 Is there a boot strap issue? which is loaded first meta.retro or core.retro? 20:00:11 meta.retro 20:00:14 then core.retro 20:00:23 ok, cool. I understand now. THanks! 20:04:54 * crc is adjusting a couple of small things in the metacompiler. it'll soon be feasible to build all three parts (core, stage2, stage3) in one run 20:05:11 Cool, why isn't it right now? 20:05:33 the original metacompiler doesn't actually boot the new image, just relocate, save, and quit 20:05:43 I'm testing the change now before I commit 20:09:12 There's a big advantage to not booting the image. The op codes may be different between the current VM and the one that will run the image being built. 20:09:49 there you'd use a slightly different metacompiler 20:09:56 [crcx/retro10] 10066a: update examples in dealing with blockfiles 20:10:25 but for targeting the same vm you're running on, it's easier to track stats of the entire build 20:13:38 Yes, then I don't have to write code to do the "add up the last run's stats with this one. 20:14:23 It turns out though that the run with meta.reto included is bigger than the sum of stage2 and stage3. 20:14:53 [crcx/retro10] 5ab3ea: build everything in one run 20:17:20 Coolo! 20:28:02 the code to save and quit after relocating is still there, just not called 20:28:43 * js4 looks at new source... 20:29:01 almost no changes :) 20:30:42 I am LOLing right now at the [ 8 , 0 , ] 20:31:09 dunno why, but it makes me laugh... 21:23:53 [crcx/retro10] cfb923: cleaner "copy" in metacompiler; no variables used 21:52:20 --- quit: docl (Read error: 104 (Connection reset by peer)) 21:55:56 --- join: docl (n=luke@97-120-215-229.ptld.qwest.net) joined #retro 22:03:52 [js4/retro10] c78472: update examples in dealing with blockfiles 22:04:58 Hmmm.... how do I make github give me your latest and abandon what ever it thinks I have? 22:05:09 I don't think I have any changes outstanding... 23:59:59 --- log: ended retro/10.01.06