00:01:20 --- log: started forth/06.04.01 00:01:20 no, I'm currently working at the dict. 00:02:39 you like stabbing into wounds, eh? 00:04:24 * Robert wonders if there's any non-controversial subject in this channel. :) 00:05:33 its 3am and i'm drunk 00:06:50 when slava is here then no, I think :-) 00:09:43 Heh. 00:09:55 You're not the one to say that, virl ;) 00:10:50 heh 01:58:41 --- join: Cheery (i=Henri@a81-197-45-47.elisa-laajakaista.fi) joined #forth 02:04:28 hello Cheery 02:10:39 Hi virl 02:37:09 I finished the dict, hooray, that was the part where I had a lot of problems with. 02:37:51 http://robos.org/2610.ps :) 02:38:00 Simpler Than Forth. 02:39:25 ehm, whats that? 02:39:31 A computer. 02:39:54 a computer? what does it? 02:40:10 Compute things. 02:40:22 It's really simple, but doable. 02:40:31 (..with discrete transistors, diodes and resistors) 02:40:59 well, is that the american notation of circuits? are they ands or what? 02:41:34 Yeah, it's american. I'm using "xcircuit" to draw that. 02:41:39 Most and AND gates, yes. 02:41:49 (because you get them for free with DTL) 02:44:25 and what do you do with it? 02:45:03 because I can't read it's purpose out of it's circuit, because I don't want todo a logic table to get a glue about it. 02:45:08 get an idea about it 02:45:38 There is a documentation page about it, but it's down atm (grr...) 02:46:19 It is a simple CPU with a 3-bit instruction pointer (so 8 instructions). 02:46:19 Every instruction also contains a pointer to the next instruction. 02:46:35 Hmm... two operations: AND and XOR. Two input and two output ports. 02:47:59 the brainfuck computer? 02:48:34 No, it has a simple but traditional register-based instruction set. 02:48:40 ok.. 02:49:16 The question "why" is obviously not a good one. 02:49:31 so in this circuit mess of ands, xor,etc you implement registers, fascinating. I wouldn't see that 02:49:35 'for fun' is for me a good answer 02:49:42 Good! 02:49:58 heh? 02:50:20 Too many people don't accept that as a reason. :) 02:55:08 oh.. 02:57:05 what are the aN outputs? 02:58:36 Address lines. 02:59:06 The memory will be a simple discrete diode ROM (with switches, so you can reprogram it). 03:00:07 so memory can hold 8 elements? 03:07:54 The program memory, yes, although that can easily be extended if you need to. 03:08:26 There is no real RAM. You have three registers (and up to two more, if you connect the input ports to the output ports). 03:08:45 saon: Thanks for that last trick, which nearly doubles the storage capacity! ;) 03:09:56 whoho.. startup time at the moment isn't so bad :-) good for pix 03:10:11 What? 03:10:58 ehm, for xell, pix is the portable implementation of xell. 03:11:46 I only tested my dict code and was happy that it's not as slow as I expected. 03:12:06 Nice. :) 03:15:36 the dict uses subroutine threading, I think. that's one of the few threading techniques which aren't ugly. 03:17:52 it's probably slow during execution, because it uses malloc & free 03:28:38 a question, when does it makes sense to stop execution of a program? 03:35:09 When the user's attention span expires. 03:48:39 real 0m0.500s for 1024 x Hello world, hmm 04:53:21 that's slow eh? well, the same in C does is a little bit faster 05:19:03 --- join: PoppaVic (n=pete@0-1pool66-13.nas22.chicago4.il.us.da.qwest.net) joined #forth 05:23:46 --- join: segher (n=segher@dslb-084-056-191-161.pools.arcor-ip.net) joined #forth 05:33:23 --- quit: segher_ (Read error: 110 (Connection timed out)) 06:46:25 huh? what are you doing in C that takes almost 500ms? 06:46:42 hmm? 06:46:53 I think he means that it would be faster in C. 06:47:27 he said a littlel bit 06:47:37 I tried this: for(i = 0; i < 1024; ++i) { printf("Hello, World!\n"); } 06:48:04 which took 24ms the first time, and 18ms thereafter 06:48:13 now try it with puts() instead of printf 06:48:14 and only 5ms if I >/dev/null 06:49:13 17ms 06:49:35 I wasn't actually taking that "a little bit" literally. 06:50:01 I musta' missed something dire 06:50:15 still get 5ms when >/dev/null 06:50:24 yeah, sounds fair 06:50:39 I meant that I tested my dictionary code and it took 0m0.500s for 1024 printing HelloWorld and when I do the same in raw C it tooks a little bit lesser. 06:50:59 I get 3 or sometimes 4 ms if I spell the command wrong and get "bash: hello: command not found" 06:52:09 I've a lot of respect for C.. If yer approaching their speeds, you are doing something well. 06:52:30 looks like it takes 4ms to load the C libs and all that 06:52:41 yeah, I believe that 06:53:14 this takes 4ms: int main(int argc, char** argv) { return 0; } 06:53:22 PoppaVic, who does something well? 06:53:30 well, the setup and loader, too Jas 06:53:37 virl: yer code, I meant 06:54:12 I'm just saying that's the overhead, so it actually only takes 1ms to run this loop for(i = 0; i < 1024; ++i) { printf("Hello, World!\n"); } 06:54:17 JasonWoof: remember - it's setting up environ and the argv/envp ptrs, too 06:54:34 right, "Shee's quuiick" ;-) 06:58:18 well on my machine not 06:59:03 depends on what's going on, and the layers of abstraction 06:59:49 I don't think that this loop does only take 1ms 07:12:00 virl: well, w/o profiling, the best you'll ever get is merely a rough. However, the more tests a tidbit performs, the better your estimate. 07:12:38 I think I'll profile the code 07:12:48 good luck, I tried it once 07:13:17 yer, means your? 07:13:23 ya 07:13:57 (it's the standard 'area-accent' for "your" and "you're") 07:14:46 sorta' like you hear brits pronouce something like "dater" for "data" 07:21:52 anyone here anything new about the tathi-tinkers? 07:22:04 hear, darn it 07:24:08 tathi-tinkers? 07:24:34 yeah, he was beating up the fovium bytecode stuff 07:24:48 well.. I profiled the code, because it's important that dictionary runs fast. 07:25:14 yeah, fairly important - but it's still interp-time 07:27:04 I guess the question becomes: how long does it take to look up some number of words, how long to add some number, and how long to run the generated codes? 07:27:05 virl if it is slow it C, then the time is probably being taken up by your terminal scrolling 07:27:23 virl: try running it like so: time ./hello > /dev/null 07:27:29 well, I don't think it's slow. 07:27:38 JasonWoof: iirc, I used to test that to >/dev/null and also a real file 07:27:41 500ms is very slow for C 07:27:58 JasonWoof: took 5ms on my box, and 4ms of that was just loading 07:28:09 well, that's the time it takes on my machine. 07:28:22 what's the cpu/base/compiler? 07:28:51 gcc 4.0.3, amd duron 755mhz 07:28:58 hmm 07:29:09 I'm running at 450Mhz 07:29:12 G4 07:29:25 755 is ok, last I heard durons were akin to a celeron 07:29:46 JasonWoof: yeah, I've a faster g4, so that sounds right 07:30:30 it might well be gcc4+ or the code itself 07:30:30 virl: if it takes more than 10ms in C then I'd bet most of the time is passing while waiting for your terminal [emulator] to update the screen 07:30:43 * Robert thinks a C64 could do it in less than 500ms. 07:31:09 JasonWoof: well, again: boost the iterations, test against dev/null and a file. 07:31:27 PoppaVic: why? 07:31:59 just because the boost will minimize the overhead-time, and dev/null is always faster than a file, and a file is always faster than a termwin 07:32:02 well, my dict code is ok. 07:33:08 it takes a compareable time with the C program. 07:33:31 both around 500 ms, even when the terminal emulation is slow. 07:34:03 virl: there's no way in hell that the C version takes more than 10ms 07:34:27 you've got a few ms of the C program and 495ms of your terminal trying to scroll 07:35:05 you can test just your program by running it with >/dev/null 07:35:58 JasonWoof, how should I test my dict code with /dev/null? 07:36:22 $ time ls -al 07:36:23 real 0m0.081s 07:36:23 user 0m0.020s 07:36:23 sys 0m0.000s 07:36:46 virl: I thought you were testing this: : hello 1024 for ." Hello, World!" cr next ; 07:36:47 $ time ls -al >/dev/null 07:36:47 real 0m0.063s 07:36:47 user 0m0.000s 07:36:47 sys 0m0.010s 07:36:58 here: real 0m0.167s 07:36:58 user 0m0.015s 07:36:58 sys 0m0.006s 07:37:19 eh.. 07:37:26 real 0m0.020s 07:37:26 user 0m0.012s 07:37:26 sys 0m0.007s 07:37:58 soo, where is 500ms? 07:39:46 JasonWoof, I tested this: #include int main(){ int i=0; for(i=0; i<1024; i++){printf("Hello...\n"); printf("World...\n"); printf("colon\n");} return 0;} in comparison to my dictionary C test code, which does the same. 07:40:12 your dictionary does helloworld? 07:40:17 and both take about 500ms 07:40:53 PoppaVic, it was a simple test, just compilation of primitves and normal words and then executing them. 07:41:16 ohh... OHHHH 07:41:50 yer saying your non-C test was doing an entire load, link, compile, and execute all along the line? 07:42:58 well, yes. where is the problem? 07:43:09 virl: how long does that C program take to execute with >/dev/null? 07:43:10 oh, none - NOW I see 500ms 07:44:13 JasonWoof: he's comparing a precompiled C program with his VM program loading and building and running the equiv )I think) 07:44:35 PoppaVic, exactly.. 07:45:19 virl: that's not remotely fair... Try instead to time the entire make, execute of the C - and THEN time the VM alternative 07:45:22 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 07:45:44 virl: with your C code above I get about 200ms real with my terminal, and 6ms if I >/dev/null 07:45:46 hi tathi 07:46:37 virl: the 500ms thing is meaningless, that's how long it takes your terminal emulator to scroll 07:46:56 hmm. Nope 07:47:23 well, JasonWoof then it's the cpu, yours is faster. 07:47:40 JasonWoof: he built the vm, compiled it. Runs it to interpret and compile the bytecode and execute that as well. 07:47:45 virl: no, my cpu is not faster. it's 450Mhz 07:47:54 virl: my terminal emulator is faster 07:47:56 hi all 07:48:01 hi tathi :) 07:48:01 you use a g4 07:48:07 what's the latest, tathi ? 07:48:26 virl: yes, it's more effecient per cycle, but you have almost double the clock speed 07:48:27 virl: I ain't run you code, and I'm using a gig G4. 07:48:37 you/your 07:48:38 PoppaVic: nothing computer related today yet :) 07:48:42 whatever, it seems that I can't describe it you what I did. 07:48:51 tathi: what was the news on yesterdays labors? 07:49:12 virl: would you please please please please try this: time ./hello > /dev/null 07:49:43 (where "./hello" is the compiled C version you pasted above) 07:50:20 PoppaVic: I got the basic bytecode execution bit about where I want it 07:50:29 nifty 07:50:31 now need to decide what exactly I'm doing about dictionaries 07:50:46 right.. Abstracting at least one level, I hope? 07:50:50 JasonWoof, no. 07:51:04 why should I 07:51:20 * PoppaVic sighs 07:51:25 I'm still not clear what you mean by "abstracting a level" 07:51:45 tathi: I was presuming you meant "add a word" and "find a word", etc 07:51:51 virl: because it will tell you how long your program took to execute. 07:51:55 well, I'm also an idiot. because PoppaVic thinks I compile bytecode yet. 07:52:08 ok, one last try to explain what I did. 07:52:18 virl: timing it normally gives you the time it took to execute plus the time it took your terminal emulator to display it all and scroll 07:52:36 it's process-time 07:53:08 tathi: working on your punctuated forth? 07:53:42 yeah, a bytecoded one that I want to use for game logic in vor eventually :) 07:55:23 virl: and seeing as how your terminal emulator takes about 100 times longer than your C program, you really cannot get even a vague idea of how long the C program takes if the number also includes the time from the terminal emulator 07:55:35 tathi: cool :) 07:56:11 I programmed the above C program and I compared it to my C dictionary test program, which creates primitves, one which prints 'hello..', one which prints 'world...' and one which prints 'colon', then my test program writes bytes to a file and then it reads it again and creates a normal word which links the primitives together and then it executes them 1024 times. 07:57:10 virl: ok 07:58:01 virl: so if you'd like to know how long it takes your terminal emulator to display 3072 lines of text, you can do this: time ./hello 07:58:04 JasonWoof, I went to console and tested both programs once again. C program: 0m0.080s and the C dictionary test program takes: 0m0.086s 07:58:29 virl: if you'd like to know how long it takes your program to run, do this: time ./hello >/dev/null 07:58:40 JasonWoof, I use time to test the programs. 07:58:52 JasonWoof: yer beating a dead horse. 07:59:11 virl: no, you're using time to test the programs and your terminal emulator together 07:59:31 "What we've got here... is a failure to.. 'communicate'" 07:59:43 PoppaVic: you're one to talk 07:59:55 indeed, I am. 08:00:46 Perhaps you can tell him in ASM? NASM? GAS? 08:01:11 virl: why do you think it runs so much faster in the console? 08:01:50 ok, I tested it and C program: 0m0.005s and the dict code 0m0.008s, so what it 08:02:13 you have one slow-ass terminal 08:02:23 xterm.. 08:04:00 and the result is: 'no virl, it's not slow, it's at the moment fast, because it hasn't much overhead' 08:04:17 oh, that took very long. 08:08:16 I'm guessing everyone is on their period. 08:09:00 ok, I fixed the other-endian detect bug in fovium and made a new tarball dated today 08:09:13 tathi: are you planning to bytecode into a buffer, and then malloc and memmove as required? 08:10:43 huh? currently you pick how big a memory space you want (for bytecode and data) when you create an instance. 08:10:59 ahhh 08:11:09 one for all and all for one. 08:12:03 tathi: so, you are - if I understand correctly - using the term "dictionary" to mean the collective image-space? 08:12:25 oh. I usually use "dictionary" to mean "headers" 08:12:32 ok 08:12:40 that simplifies it 08:13:06 where does the "compiled bytecode" go? 08:13:47 it has a heap, as forths usually do 08:13:58 hmm 08:14:13 a single one for bytecode and data, currently 08:14:30 S'ok.. Look forward to perusing the newer tarball ;-) 08:14:35 although you could certainly have separate ones instead 08:47:22 --- quit: PoppaVic ("recycles") 08:48:38 tathi: what do you mean by bytecode? 08:48:59 --- join: PoppaVic (n=pete@0-1pool74-194.nas24.chicago4.il.us.da.qwest.net) joined #forth 08:51:10 like fovium 08:51:19 hmm? 08:51:32 answering Jason 08:51:57 tathi: ahh, so it'll take a sort of binary image 08:53:38 tathi: you going to make it so you can attach little scripts to "objects" such as rocks 08:53:58 well...I was planning on adding naming stuff as opcodes, so it could interpret source. 08:54:19 so it would just be a scripting engine, like ficl or atlast 08:54:51 and as for attaching scripts to objects, we'll see 08:54:55 sounds plan 08:55:02 sound, two 08:55:32 I can't tell yet what stuff it will make sense to factor out and allow scripts to control, and what stuff it makes more sense to just leave in C. 08:55:33 please_dontWriteFuncs_thisLong() 08:56:24 tathi: yeah, I've been trying to dive that low and codify for a few weeks now. 08:57:10 PoppaVic: oh, I was talking about the game. 08:57:22 I've been looking at enums, structs, vtables... and then starting on the "Standard C" website 08:57:23 I know pretty much where I want to divide things with the forth 08:57:35 right, I'm not sure I do yet, is all 08:57:53 yeah. I have specific goals for this, so it's easy enough to make the decisions. 08:58:17 You almost need a solid core of interpreted words - including mode-switchers and integral 'types' - first. 09:00:28 Anyway, yeah... It's a bother... I'm thinking of just screaming and abandoning it for awhile to persue something pleasant for a change. 09:01:42 tathi: I think C should handle the camera and drawing everything 09:02:43 I think C should continue to have a bunch of useful functions that forth could call 09:03:59 W/o at least conformant wrappers or a structured plugin, the FFI can get really nasty. 09:04:29 PoppaVic: whaat? 09:04:49 I was thinking call-down (from bytecode to C) 09:05:25 PoppaVic: he's building the forth implementation into the C program, it's not hard to call C functions in that C program 09:05:34 * PoppaVic sighs 09:05:47 I said _calldown_ from the pcode. 09:05:58 I don't know what that means 09:06:09 w/i the C, it's all SN(AFU) 09:06:35 calling UP from C shouldn't be too tough, calling down might be 09:20:36 --- quit: PoppaVic ("Pulls the pin...") 09:24:06 sheesh. why does he have to map his imaginary problems onto everybody else's perfectly simple, functional software? 10:15:01 problems like? 10:15:47 tathi, how do you design your game engine? 10:15:57 oh. maybe he was talking about his project after all. 10:16:21 I don't really have a game engine yet. 10:16:41 or what do you want exactly todo with it? 10:16:57 there's a little 2D spaceship game that Jason and I have modified a bunch. 10:17:27 a little spaceship game? =) like what? 10:17:35 http://happypenguin.org/show?VoR 10:18:10 and the original: http://happypenguin.org/show?Rock%20Dodger 10:18:11 uhh... :-) 10:18:45 I can think of a bunch of things to do with the basic setting (flying a spaceship, with rocks around) 10:19:20 so I've been working toward being able to separate the game engine part from the bits that are specific to this game. 10:21:32 O_O 10:22:27 hey, I said it was a "little" game :) 10:23:08 your forth for your game and xell for my games ;-) 10:23:41 perhaps my will all suck 10:24:46 tathi, thanks for kicking me in the ass. 10:25:07 sure, any time ;-) 10:25:21 how's xell going, anyway? 10:25:44 it has now a working dictionary *yipee* 10:26:12 ah, that's always good 10:26:13 now I need to implement the xell api 10:26:39 do you have that planned out already, or are you still making it up? 10:27:32 I'm still making it up. 10:30:01 but I only need to plan the core api, the profiles(libraries) apis I don't need to plan yet. 10:33:34 I see 10:41:10 Have you ever implemented a Forth on a system without simultaneous write and execute access to memory pages? 11:11:24 can't say I have 11:11:27 have you? 11:12:09 hmm...I guess you'd need at least two separate pages for it to even be possible 11:12:15 interesting 11:12:25 No. Just wondering if you had any good workarounds. 11:12:43 for one of my systems, all machine code is in rom. so yes. 11:12:51 Hehe. 11:13:15 any simple direct or indirect threaded system will do, really 11:13:44 erm, direct threaded not, for the std imlpementation 11:14:16 Forgot to mention that it should be subroutine threaded/native code. 11:14:59 well that's impossible then -- you need to write the code before you can execute it 11:15:12 oh i see now -- _simultaneous_ 11:15:40 Well, I was thinking about being able to write code and then execute it without a ton of mprotect() calls. 11:15:56 Or equivalent. 11:16:02 you'll need to do a cache synchronize too 11:16:24 Yeah... guess there's no really easy fix. 11:17:46 you can try to hide (almost) all of it in COMPILE, 11:32:12 mprotect usually does the cache sync, doesn't it? 11:33:31 nah 11:34:42 well, that's good to know. 11:34:58 I just assumed it did other places too. 11:50:34 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth 12:08:51 I guess GC'd languages will have a hard time running in ROM :) 12:09:48 Maybe it uses a modem to connect to the garbage collecting services of your city and ask them to take care of the ROM? 12:10:20 that's a GC pause 13:12:37 and now GCs are going crazy 13:13:26 I mean that could be possible future, because of the hype of grid computing, java and .net. 13:56:13 the other possible future would be xell hell 13:56:59 and factor would be a better future.. hah.. 13:57:59 uh, slava is such an ass. 13:59:52 --- quit: Cheery ("Leaving") 14:09:41 -.-' 14:10:36 arke, you know what I'm talking about, eh? 14:10:59 no, this is more in regard to your unecessary statement just now 14:11:13 :) 14:13:32 ah, shit 14:19:52 lol, I just stumbled over a nice leaking error, I found out that the option -pg for gcc produces an output code which allocates something and doesn't free it. 14:20:52 leaking memory everywhere.. 14:25:18 I thought you didn't like C? 14:29:40 I never said that I don't like C 17:31:06 --- quit: uiuiuiu (Remote closed the connection) 17:31:10 --- join: uiuiuiu (i=ian@dslb-084-056-229-057.pools.arcor-ip.net) joined #forth 18:48:01 --- quit: tathi ("leaving") 19:03:43 --- quit: scope ("Client exiting") 19:52:39 --- quit: JasonWoof ("off to bed") 20:01:47 --- join: nballen (n=nballen@adsl-69-109-11-176.dsl.renocs.pacbell.net) joined #forth 21:27:45 --- quit: nballen () 23:28:39 --- join: Cheery (i=Henri@a81-197-45-47.elisa-laajakaista.fi) joined #forth 23:59:59 --- log: ended forth/06.04.01