00:00:00 --- log: started forth/03.07.03
01:10:01 --- join: deluxe (~deluxe@pD9EE1050.dip.t-dialin.net) joined #forth
01:10:37 <deluxe> bonjour
01:15:45 --- quit: kc-movie ("[x]chat")
01:28:09 <deluxe> bye ;-)
01:28:27 --- quit: a7r (Read error: 110 (Connection timed out))
02:32:11 --- join: Serg_Penguin (Serg_Pengu@212.34.52.140) joined #forth
02:32:16 --- quit: Serg_Penguin (Client Quit)
03:59:42 --- join: mur (murr@baana-62-165-185-218.phnet.fi) joined #forth
04:36:13 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth
07:03:11 --- join: PoppaVic (~pfv@s39.waters.gtlakes.com) joined #forth
07:39:13 --- part: tathi left #forth
08:16:45 --- join: wossname (wossname@HSE-QuebecCity-ppp81458.qc.sympatico.ca) joined #forth
08:39:48 --- quit: PoppaVic ("(I don't need a reason)")
08:52:16 --- join: deluxe_ (~deluxe@pD9EE121A.dip.t-dialin.net) joined #forth
08:59:05 --- quit: wossname ()
09:01:16 --- join: Herkamire (~jason@h0030657bb518.ne.client2.attbi.com) joined #forth
09:10:09 --- quit: deluxe (Read error: 110 (Connection timed out))
09:18:17 --- part: deluxe_ left #forth
10:14:34 --- join: PoppaVic (~pfv@s195.waters.gtlakes.com) joined #forth
10:19:19 <PoppaVic> anyone have a moment for a logic-bomb?
10:21:15 <PoppaVic> *the terminal*:12: Cannot tick compile-only word (try COMP' ... DROP)
10:21:15 <PoppaVic> ' [']
10:21:15 <PoppaVic>   ^^^
10:22:42 <Herkamire> weird
10:22:59 <PoppaVic> well, that's gforth - but the point remains
10:23:25 <PoppaVic> Isn't tick nothing more than find + nfa>cfa ?
10:23:29 <Herkamire> I havn't figured out how I want immediates to work.
10:23:56 <PoppaVic> I've dropped a user-accessible STATE altogether, and words may now be 4-mode.
10:24:45 <PoppaVic> But, this doesn't answer the immediate dilemma - which is: isn't tick just lookup & field-recalc?
10:25:48 <PoppaVic> Herkamire: dcc offering
10:26:50 <PoppaVic> Seems to me that ' (tick) should ALWAYS work.. But that the compiler and interpreter are the ones that need to check modes and scream as required.
10:33:12 --- join: w1k1_ (~w1k1@pD9EE121A.dip.t-dialin.net) joined #forth
10:36:58 --- part: PoppaVic left #forth
10:41:45 --- part: w1k1_ left #forth
10:43:01 --- join: w1k1 (~w1k1@pD9EE120E.dip.t-dialin.net) joined #forth
10:46:36 --- join: a7r (~a7r@206.72.82.135) joined #forth
10:46:41 <a7r> hey
11:07:50 --- join: kc5tja (~kc5tja@ip68-8-206-137.sd.sd.cox.net) joined #forth
11:07:50 --- mode: ChanServ set +o kc5tja
11:35:55 <Herkamire> hey a7r
11:36:21 <Herkamire> wb kc5tja 
11:36:22 <a7r> Herkamire: how's it going?
11:36:23 <a7r> kc5tja: yoh
11:37:33 <mur> where's robert?
11:39:16 <Herkamire> I'm ok. I'm feeling lazy, but I'm starting to enjoy procrastinating :)
11:39:49 <kc5tja> re
11:40:27 * kc5tja is writing a quick C and assembly language application for Linux which attempts to guage the best method of compiling FS/Forth code to native code.
11:40:45 * kc5tja is going to investigate the use of ESI and EBP to hold the data stack pointer, along with a couple of other things.
11:40:57 <Herkamire> how will it guage?
11:41:02 <kc5tja> It'll time them.
11:41:10 <Herkamire> are you looking to see how gcc optomizes?
11:41:12 <kc5tja> The method that takes the least amount of time wins.
11:41:15 <kc5tja> No
11:41:23 <kc5tja> Though GCC's output is used as a baseline.
11:41:31 <w1k1> Herkamire: how's sifbot btw? ;-)
11:42:04 <Herkamire> w1k1: I took sifbot down because it was incomplete, undocumented, and I've lost interest in working on it.
11:42:55 <Herkamire> w1k1: you can have the code if you want to play with it.
11:47:05 <w1k1> :-)
11:47:06 --- quit: a7r (Read error: 60 (Operation timed out))
11:48:00 <Herkamire> now I'm playing with PPC asm, pre-parsed source (like aha and enth/flux) and contemplating writing a colorforth editor.
11:48:47 <Herkamire> right now I'm mostly thinking about how to implement blocks for my source.
11:49:52 <w1k1> Herkamire: thx, yes i would like to have a look at it :-)
11:50:39 <Herkamire> the forth: http://herkamire.homeip.net:5000/svn/sif/
11:50:46 <Herkamire> the bot: http://herkamire.homeip.net:5000/svn/sifbot/
11:51:42 <Herkamire> sometimes I shut this computer down at night.
11:51:59 <w1k1> Herkamire: can't promise you docs for it, but my (newbie) thoughts, questions and answers(hopefully;-) will go into a ForthFAQWiki right away..
11:52:40 <w1k1> Herkamire: sometimes? lol, same here..
11:53:42 <w1k1> at least until i have that ultralowpower server.. ;-)
11:53:47 <Herkamire> currently I'm running a proxy that get's my girl friend's computer online. Since she usually get's up before me, I'll probably be leaving my computer on a lot.
11:54:12 <Herkamire> is the wiki up yet?
11:55:12 <Herkamire> I haven't written a wiki sort of thing yet.
11:58:10 <kc5tja> OK, GCC baseline code can do it in about 15 seconds without -O3 -fomitframepointer.  Lets see what it can do with those optimizations.
11:59:19 <kc5tja> Yikes -- 8.3 seconds.  :D
11:59:42 <kc5tja> Now to hand-assemble the equivalent Forth code.
12:18:00 <kc5tja> OK, for all you NASM experts here, how the *HELL* does one make a symbol public?
12:18:06 <kc5tja> [extern] works fine, but [public] doesn't.
12:18:42 <kc5tja> Ahh, global.
12:27:34 <kc5tja> OK, this really sucks...  :(
12:27:53 <kc5tja> Does Linux allow *any* kind of stack pointer manipulations AT ALL?
12:28:04 <kc5tja> I do something like:
12:28:08 <kc5tja> mov ebp,esp
12:28:10 <kc5tja> sub esp,1024
12:28:20 <kc5tja> call Foo <-- it segfaults here; Foo is NOT executed.
12:28:35 <kc5tja> It just doesn't make any sense.
12:28:44 <kc5tja> Oh, wait...I need to push EBP first.  Forgot about that.
12:29:56 <kc5tja> Nope, that didn't fix it.  :(
13:00:40 <TreyB> Hmmm.
13:01:45 <TreyB> The isforth guy had similar complaints about stack pointer manipulation.
13:03:32 <TreyB> Out of curiosity, why do you want to consume 1K of stack space this way?
13:04:18 <kc5tja> To provide a temporary data stack for the "Forth"-code I'm benchmarking.
13:04:37 <kc5tja> Without having to go through the rigamorole of providing a 100% fully-equipped Forth environment.
13:13:08 <TreyB> Did you cross a page boundary with the 'sub esp,1024'?
13:15:20 <kc5tja> It's possible, I don't know.
13:20:38 <TreyB> extern int doit(int x, char *);
13:20:38 <TreyB> int somefunc(int y)
13:20:39 <TreyB> {
13:20:39 <TreyB>         char buf[1024];
13:20:41 <TreyB>         return doit(y, buf);
13:20:41 <TreyB> }
13:20:59 <TreyB> via: gcc -c check.c -O
13:21:03 <TreyB> gives:
13:21:12 <TreyB> 00000000 <somefunc>:
13:21:12 <TreyB>    0:   55                      push   %ebp
13:21:13 <TreyB>    1:   89 e5                   mov    %esp,%ebp
13:21:13 <TreyB>    3:   81 ec 10 04 00 00       sub    $0x410,%esp
13:21:16 <TreyB>    9:   8d 85 f8 fb ff ff       lea    0xfffffbf8(%ebp),%eax
13:21:16 <TreyB>    f:   50                      push   %eax
13:21:16 <TreyB>   10:   ff 75 08                pushl  0x8(%ebp)
13:21:17 <TreyB>   13:   e8 fc ff ff ff          call   14 <somefunc+0x14>
13:21:19 <TreyB>   18:   c9                      leave
13:21:21 <TreyB>   19:   c3                      ret
13:22:37 * kc5tja nods
13:23:17 <TreyB> Notice the push before the call.
13:23:28 <kc5tja> Yes.
13:23:35 <kc5tja> I know how C calls work.
13:24:04 <TreyB> I suspect that you might have crossed the page boundary with the sub, and linux had not yet commited the physical page.
13:24:05 <kc5tja> I'm not allocating the buffer THEN calling the code, I'm allocating the buffer WITHIN the code.
13:24:50 <kc5tja> But yet, even if it does such, the above code (assuming doit() is written in C) will work flawlessly.
13:25:24 <kc5tja> Hence my consternation.
13:25:26 <TreyB> I suspect that it traps the fault, sees the PUSH, commits the page, and restarts the instruction.
13:25:47 <kc5tja> Yes, but it doesn't need to inspect instructions for this to happen.
13:26:03 <kc5tja> x86 records enough state to enable the host OS to expand the stack as needed.
13:26:13 <kc5tja> (one of the few things it does correctly)
13:26:34 <kc5tja> (amazingly enough, that is)
13:27:11 <TreyB> Sure, but the Linux kernel might consider an error writing off the edge of the stack with anything but a PUSH.
13:27:26 <kc5tja> Or a CALL, which is what I'm doing.
13:27:48 <kc5tja> Change doit() to be a void doit(void), and you'll see it doesn't push anything before calling it.
13:30:13 <TreyB>    0:   55                      push   %ebp
13:30:13 <TreyB>    1:   89 e5                   mov    %esp,%ebp
13:30:14 <TreyB>    3:   81 ec 08 04 00 00       sub    $0x408,%esp
13:30:14 <TreyB>    9:   e8 fc ff ff ff          call   a <somefunc+0xa>
13:30:18 <TreyB> Hmmm.
13:31:34 <kc5tja> So, I'm at a total loss.  There is nothing at all in the Linux FAQs about this.
13:31:46 <kc5tja> The Assembly HOWTO was enlightening, but doesn't help me find the problem.
13:31:54 <kc5tja> I *CAN* go straight to the raw kernel interface though.
13:32:04 <kc5tja> So whatever problems exist appears to be purely and utterly in the C runtime environment.
13:32:24 <TreyB> You wrote your code in NASM?
13:32:31 <kc5tja> Which, of course, defeats the purpose of why I'm even trying to write it for Linux to begin with.
13:32:35 <kc5tja> yes
13:32:49 <TreyB> What does objdump -D of your .o file have to say?
13:33:00 <kc5tja> It's a bit big.
13:33:18 <TreyB> I don't need the whole thing :-)
13:33:47 <kc5tja> Nothing.
13:33:54 <kc5tja> It says it's an ELF file, and that's it.
13:34:06 <kc5tja> There we go.
13:34:09 <kc5tja> What do you want to know?
13:34:31 <TreyB> I want to see the dumped part of your call to Foo.
13:34:50 <TreyB> (morbid curiosity)
13:35:40 <kc5tja>    0:   55                      push   %ebp
13:35:40 <kc5tja>    1:   89 e5                   mov    %esp,%ebp
13:35:40 <kc5tja>    3:   81 ec 00 04 00 00       sub    $0x400,%esp
13:35:40 <kc5tja>    9:   e8 18 00 00 00          call   26 <SubroutineThreadedX100>
13:35:40 <kc5tja>    e:   e8 13 00 00 00          call   26 <SubroutineThreadedX100>
13:35:42 <kc5tja>   13:   e8 0e 00 00 00          call   26 <SubroutineThreadedX100>
13:35:43 <kc5tja>   18:   e8 09 00 00 00          call   26 <SubroutineThreadedX100>
13:35:45 <kc5tja>   1d:   e8 04 00 00 00          call   26 <SubroutineThreadedX100>
13:35:47 <kc5tja>   22:   89 ec                   mov    %ebp,%esp
13:35:51 <kc5tja>   24:   5d                      pop    %ebp
13:35:53 <kc5tja>   25:   c3                      ret    
13:36:22 <kc5tja> and:
13:36:30 <kc5tja> 00000026 <SubroutineThreadedX100>:
13:36:30 <kc5tja>   26:   e8 d7 00 00 00          call   102 <dot>
13:36:30 <kc5tja>   2b:   e8 d2 00 00 00          call   102 <dot>
13:36:30 <kc5tja>   30:   c3                      ret    
13:37:03 <kc5tja> dot just prints a dot to the screen using Linux system call interface.
13:38:02 --- join: a7r (~a7r@206.72.82.135) joined #forth
13:38:17 <TreyB> It looks sane to me.
13:38:27 <kc5tja> Yeah.
13:38:34 <kc5tja> There's no reason why it shouldn't work.
13:38:44 <kc5tja> Now if I change dot to use libc instead of system call interface, it breaks.
13:38:57 <a7r> oi
13:39:13 <TreyB> You mean it works with the kernel API and not with libc?
13:39:31 <kc5tja> For the purposes of printing a humble dot on the screen, yes.
13:39:59 <kc5tja> But I save all the registers I need to save when calling libc, and it still doesn't print, even when I fprintf to stderr.
13:40:10 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth
13:40:31 <kc5tja> But this is actually unrelated to my initial problem, which I can probably at least have a chance of debugging now that I can print a dot to the screen.
13:40:44 <kc5tja> But goddammit, how can I get any networking done if I can't even call fprintf?!
13:41:30 <tathi> more horribly weird bugs kc5?
13:41:47 <TreyB> If you want to use the C runtime at all, you'll have an easier time if you have a C main() and drop into your own code from there.
13:42:01 * kc5tja cries!!!  I DO!!
13:42:15 <kc5tja> But that's not the point!!!
13:42:35 <kc5tja> The point is, my code crashes under Linux, with no obvious explanation why.
13:42:48 <kc5tja> SO, I decided to insert print statements to trace execution.
13:42:57 <kc5tja> Those print statements DO NOT WORK>
13:43:13 <kc5tja> The calls to fprintf are exactly liek those produced by a C compiler.
13:43:25 <kc5tja> Inspected by me from the output of GCC directly.
13:43:48 <TreyB> Have you tried using gdb?
13:43:54 <kc5tja> yes
13:44:59 --- quit: ChanServ (Shutting Down)
13:45:04 <TreyB> Ooops.
13:45:17 --- join: ChanServ (ChanServ@services.) joined #forth
13:45:17 --- mode: leguin.freenode.net set +o ChanServ
13:46:01 <TreyB> kc5tja: I don't know how else to help short of my running your code in a debugger.  I'd love to volunteer, but I don't have that much time right now.
13:46:16 <kc5tja> That's OK.
13:46:36 <TreyB> Keep your chin up, mate!
13:46:45 <kc5tja> I'm starting to feel that working within Linux is going to be more trouble than its worth, and that it'd perhaps be a better use of my time to go straight to naked hardware.
13:47:31 <kc5tja> If I have to replicate every damn library I want to use under Linux within Linux, I may as well just rewrite the damned code to run under my own host environment.
13:48:17 <TreyB> I think that once you've solved the library problem once you won't need to do it again.
13:48:22 <kc5tja> It's either that, or take a *severe* performance hit and define a byte-code interpreter in C, with the Forth environment compiling to bytecode.
13:48:41 <TreyB> But you definitely have a long row to hoe to get there.
13:48:54 <kc5tja> Exactly, and I *SHOULDN'T* have a long row to hoe.
13:49:06 <kc5tja> Dude, the x86 has only 8 GPRs.
13:49:14 <kc5tja> I can configure them in only so many ways!
13:49:37 <kc5tja> There should be *zero* cause for fprintf to not work from my assembly code, but works from within C.
13:49:38 <TreyB> I disagree.  The x86 EABI and C-runtime has many complexities.
13:49:57 <TreyB> You just need to find the one you've tripped over.
13:50:03 <kc5tja> Well, I just looked at the Linux Assembly HOWTO, and it vindicates the correctness of my code.
13:50:44 <TreyB> It doesn't work, so you can draw one of two conclusions: you didn't do it correctly, or the HOWTO has it wrong :-)
13:52:14 <kc5tja> Again, there are only so many ways for this to work.
14:01:57 <kc5tja> OK, I managed to get fprintf working, after searching further on the Internet.  I also managed to get dolit and drop working as well.
14:04:03 <TreyB> What did you have to do?
14:05:00 <kc5tja> change push stderr to mov eax,[stderr]   push eax
14:05:13 <kc5tja> Now I'm debugging the actual cause of failure in my code.
14:05:25 <kc5tja> Got dup, drop, and a bunch of other "words" working.
14:06:47 <TreyB> Ah, you got bit by the variable dereference.
14:08:15 <kc5tja> Yeah, but I'm not having much additional luck with the bug I'm trying to diagnose now.
14:20:46 <kc5tja> OK, looks like I got the bug tracked down and squashed.
14:21:08 <kc5tja> The results are impressive though.  :)
14:21:31 <TreyB> :-)
14:21:38 <kc5tja> PURE subroutine threading is about as fast as GCC without optimization -- a tad bit slower, but still within the ball-park.
14:21:49 <kc5tja> Oops
14:21:52 <kc5tja> OK, about twice as slow.
14:22:21 <kc5tja> GCC without -O3 runs through the benchmark at 15 seconds; Pure subroutine threading, using EBP to store data stack pointer, runs at 38 seconds.
14:22:29 <kc5tja> But it's still *DAMN* good, I think.
14:22:36 <kc5tja> But, the benchmarks must go on.
14:23:26 <TreyB> You have to do optimization or pure STC will not perform well.
14:23:50 <TreyB> heh: I said "optimization" and "pure STC" in the same sentence.
14:24:03 * TreyB needs to go on vacation.
14:25:32 --- quit: mur ("MURR! save the http://rainforest.care2.com/ (click url there)")
14:33:13 <kc5tja> Well, that's why I'm benchmarking.
14:33:19 <kc5tja> I'm deliberately starting with the slowest stuff first.
14:34:32 <TreyB> You should get pretty far by inlining the usual stack operators.
14:35:08 --- join: crc (~crc@ACA7F81A.ipt.aol.com) joined #forth
14:35:47 <TreyB> Thanks for the chat.  Good luck.
14:40:04 <kc5tja> Well, that's what I'm hoping.  :
14:40:05 <kc5tja> :)
14:40:25 <kc5tja> Basically, what this is all boiling down to is, should I use EBP or ESI to house the data stack pointer?
14:40:40 <kc5tja> There might be advantages and disadvantages to each, and I want to measure their effects early.
14:43:23 <kc5tja> Gahh, now I have to debug a problem with the ESI code's implementation of store.  :(
14:47:57 <kc5tja> Problem was in OVER, actually.  :/
14:48:01 <kc5tja> But it's fixed.
14:52:27 <kc5tja> Wow.  :)
14:52:50 <kc5tja> Using ESI for the data stack is a sure-fire winner for (in)direct-threaded and subroutine-threaded implementations.
14:53:03 <kc5tja> It is consistently 17% (average) greater performance.
15:17:49 <kc5tja> w00t!!!!
15:18:05 <kc5tja> Inlined code using ESI is 200% faster than the output from GCC with -O3.
15:36:14 <ianni> nice
15:36:19 <ianni> you go, kc5tja 
15:37:34 <kc5tja> :)
15:37:49 <kc5tja> Final test is now in.
15:38:06 <kc5tja> Even using EBP and exchanging EBP and ESP all the time, it's an average of 1.8 times faster than GCC's best output
15:38:35 <kc5tja> But using ESI (or even EBP without using stack instructions) results in a 17% performance increase still.
15:38:55 <kc5tja> Here's a sample output:
15:39:02 <kc5tja> Baseline (GCC): 8539999 us
15:39:05 <kc5tja> Subroutine Threaded (EBP): 41309999 us
15:39:05 <kc5tja> Subroutine Threaded (ESI): 35919999 us
15:39:05 <kc5tja> Native Code (EBP): 4769999 us
15:39:05 <kc5tja> Native Code (ESI): 4009999 us
15:39:27 <kc5tja> Note that native code (ESI) is 2.17 times faster than GCC's best.  :)
15:41:09 --- quit: crc ("I was using TinyIRC! Visit http://www.tinyirc.net/ for more information.")
15:41:31 <kc5tja> This test was run on an 800MHz AMD Athlon (original K7 design) with 640MB of RAM.
15:53:12 <TreyB> kc5tja: will you put up a page or Email me a tarball with your "native" and STC tests, please?
15:54:36 <kc5tja> TreyB: I have a ZIP file of it.  What's your e-mail?  I do intend on putting a page up soon, on the bespin site.
15:54:54 <TreyB> trey@treysoft.com
15:55:02 <kc5tja> Hold please...
15:58:08 <kc5tja> OK, on its way.
16:02:46 <TreyB> Thanks.
16:03:11 <kc5tja> I had a friend just try it on his P4-M laptop, at 2.2GHz.  Interested in seeing his numbers?
16:03:18 <TreyB> Sure.
16:03:27 <kc5tja> <BSDKnight> Baseline (GCC) 4749999 us
16:03:27 <kc5tja> <BSDKnight> Subroutine Threaded (EBP) 8749999 us
16:03:27 <kc5tja> <BSDKnight> Subroutine Threaded (ESI) 7349999 us
16:03:27 <kc5tja> <BSDKnight> Native Code (EBP) 1579999 us
16:03:27 <kc5tja> <BSDKnight> Native Code (ESI) 1879999 us
16:03:50 * TreyB will try on his Athlon 2400+ under VMWare.
16:04:21 <kc5tja> eerk -- clock speeds getting high enough that Linux timer resolution starts becoming a significant factor.  :D
16:04:38 <kc5tja> If you get weirded out numbers, I can make you a version that runs the software for longer, thus getting more accurate results.
16:04:58 <TreyB> Yeah, you have to get the instruction timing registers and use those instead.
16:11:15 <TreyB> Baseline (GCC): 37769999 us
16:11:16 <TreyB> Subroutine Threaded (EBP): 97719999 us
16:11:16 <TreyB> Subroutine Threaded (ESI): 66709999 us
16:11:17 <TreyB> Native Code (EBP): 26009999 us
16:11:17 <TreyB> Native Code (ESI): 17979999 us
16:11:55 <TreyB> PPro 150MHz
16:16:44 <kc5tja> Cool.  :)
16:16:55 <kc5tja> Yeah, I didn't want to bother looking up the opcodes for those.  :)
16:17:05 <kc5tja> This seems to work decently enough.
16:18:04 --- quit: w1k1 ("!")
16:18:10 <kc5tja> My friend with a P4 shows that native code offers a 3x boost in performance instead of 2x boost.  But otherwise, the numbers are astonishingly congruent with expectations.
16:19:27 <TreyB> Baseline (GCC): 5527373 us
16:19:27 <TreyB> Subroutine Threaded (EBP): 18017640 us
16:19:28 <TreyB> Subroutine Threaded (ESI): 17972657 us
16:19:28 <TreyB> Native Code (EBP): 5914067 us
16:19:29 <TreyB> Native Code (ESI): 2880866 us
16:19:54 <kc5tja> What platform?
16:20:11 <TreyB> Athlon 2400+ under VMWare on a Win2K host.
16:20:18 <kc5tja> Ahh
16:21:07 <kc5tja> I'm sorry; I have to get going.  I have a headache, so I need to lie down for a bit.  Then I need to get some food.  err....that should be the other way around.  :)
16:21:12 <kc5tja> Had the headache since yesterday.  :/
16:21:17 * kc5tja hates migranes...
16:21:27 * TreyB has to take his family to dinner and then light some fireworks.
16:21:43 * kc5tja is going to stay home and listen to ham radio/shortwave radio for tonight.
16:21:45 <TreyB> Take it easy.
16:21:51 <kc5tja> Traffic is going to be pretty bad anyway.
16:21:53 <kc5tja> OK, thanks.  :)
16:21:58 <ianni> have fun
16:22:35 <kc5tja> Heheh :D
16:22:58 * kc5tja is still doing the happy dance from his coding experiment....  I definitely now know exactly what kind of code to produce.
16:54:56 --- quit: tathi ("leaving")
17:17:36 <kc5tja> back -- currently eating.
17:24:22 --- join: TheBlueWizard (TheBlueWiz@207.111.96.11) joined #forth
17:24:22 --- mode: ChanServ set +o TheBlueWizard
17:24:29 <TheBlueWizard> hiya all
17:27:23 <kc5tja> re tbw
17:27:33 <TheBlueWizard> hiya kc5tja
17:27:53 <TheBlueWizard> how's your project going? just curious
17:28:12 <Herkamire> hi TheBlueWizard 
17:28:18 <kc5tja> Very well indeed.
17:28:18 <TheBlueWizard> hiya Herkamire
17:28:23 <TheBlueWizard> :)
17:29:48 <Herkamire> I still haven't decided how my blocks of source should work
17:30:05 <Herkamire> how should I keep track of how much source is in there?
17:30:54 <kc5tja> I'm not sure I understand the question?
17:31:15 <Herkamire> a block is 1024 bytes, so thats 512 source tokens
17:31:40 <Herkamire> I probably won't be using all 512.
17:32:12 <Herkamire> how should I make LOAD interpret exactly the number of source tokens I have in that block?
17:33:04 <kc5tja> One possibility is to define a "null token" that acts as a sentinel.
17:34:16 <Herkamire> yeah. I don't like that one though.
17:34:40 <Herkamire> maybe because I haven't figured out how to do it a way I like :)
17:40:01 --- quit: a7r (Read error: 110 (Connection timed out))
17:43:50 --- join: Jim7J1AJH (~jwt@n1.dskk.co.jp) joined #forth
18:03:15 --- join: a7r (~a7r@206.72.82.135) joined #forth
18:05:43 <TheBlueWizard> hiya a7r
18:06:00 <a7r> TheBlueWizard: hol
18:06:01 <a7r> a
18:07:07 <TheBlueWizard> :)
18:08:05 --- join: a7r_ (~a7r@206.72.82.135) joined #forth
18:28:39 <TheBlueWizard> well, I must go...bye all
18:29:02 <kc5tja> OK
18:29:05 <kc5tja> Laters!  :)
18:29:25 <TheBlueWizard> bye kc5tja :)
18:29:29 --- part: TheBlueWizard left #forth
18:30:15 <kc5tja>            Baseline (GCC):    9039999 us
18:30:16 <kc5tja> Subroutine Threaded (EBP):   40349999 us
18:30:16 <kc5tja> Subroutine Threaded (ESI):   34729999 us
18:30:16 <kc5tja>         Native Code (EBP):    4739999 us
18:30:16 <kc5tja>         Native Code (ESI):    3969999 us
18:30:16 <kc5tja>              Raw Assembly:    1979999 us
18:30:20 <kc5tja> Updated numbers . . .
18:30:28 <kc5tja> Raw assembly is the fastest I can produce.
18:30:57 <kc5tja> My roommate can probably produce a version that's faster by using the FPU or MMX instructions.
18:31:11 * kc5tja isn't familiar with techniques for using the FPU/MMX instructions.
18:36:23 --- quit: a7r_ (Read error: 110 (Connection timed out))
18:48:03 <Herkamire> kc5tja: the Baseline is using C code?
18:48:44 <Herkamire> food, it does the body good :)  and the mood
18:49:27 <kc5tja> OOPS...I discovered a pretty critical bug in the code.  :(
18:49:38 <kc5tja> The C code goes through 4MB of data, while the Forth code goes through only 1MB.
18:52:28 <kc5tja> Fixed that, and the Forth code isn't quite so fast anymore.  :D
18:52:41 <kc5tja> But, it's as fast as GCC without any -O options of any kind.
18:53:07 <kc5tja> So it is still about twice as slow as raw assembler though.
19:00:17 <Herkamire> oops :) how fast is the Baseline now?
19:01:17 <Herkamire> can I see the C code? I'm curious
19:09:11 --- quit: skylan (Read error: 54 (Connection reset by peer))
19:09:30 <kc5tja> It's the same.
19:09:36 <kc5tja> Yeah.  E-mail address?
19:09:48 <kc5tja> Actually hold on...
19:10:05 <kc5tja> roommate is helping me to optimize the raw assembly version to take cache access into account.
19:11:43 --- join: skylan_ (sjh@nwc57-182.nwconx.net) joined #forth
19:13:06 --- nick: skylan_ -> skylan
19:13:11 <Herkamire> oh, you bumped the forth up to 4MB.
19:17:59 <kc5tja> Yeah.
19:41:29 --- part: Jim7J1AJH left #forth
20:13:13 --- quit: a7r (Read error: 60 (Operation timed out))
21:11:56 --- join: a7r (~a7r@206.72.82.135) joined #forth
21:49:11 <kc5tja> Final performance test source is now accessible on the #Forth website.
21:49:15 <kc5tja> Check news items for details.
22:16:20 --- quit: Herkamire ("bedtime")
22:22:56 <kc5tja> Going out.
22:22:59 --- nick: kc5tja -> kc-away
22:42:07 --- join: Serg_Penguin (Serg_Pengu@212.34.52.140) joined #forth
22:42:13 --- quit: Serg_Penguin (Client Quit)
23:10:01 <a7r> re..
23:21:57 --- nick: kc-away -> kc5tja
23:22:05 <kc5tja> Back
23:22:55 <kc5tja> a7r: Not sure if you noticed or not, but FS/Forth for Linux will be comparable in speed to GCC
23:23:09 <a7r> kc5tja: elite
23:23:37 <a7r> that sounds pretty impressive
23:41:30 * kc5tja nods
23:42:06 <kc5tja> Granted GCC is 2.2x faster than FS/Forth's code when used with -O3 -mcpu=athlon (for my Athlon boxes; speedup varies across processor line of course).
23:42:31 <kc5tja> But still, a factor of 2 isn't going to show itself unless you're working with a *LOT* of data.
23:43:15 * kc5tja is really pleased with the outcome, considering the generated code is grossly under-utilizing the hardware.  :D
23:43:20 <kc5tja> And is very memory-intensive.
23:43:30 <kc5tja> I have actual numbers posted on a website.
23:43:34 <kc5tja> (if you're interested)
23:51:28 <kc5tja> http://forum.forth.bespin.org/viewtopic.php?t=8
23:59:59 --- log: ended forth/03.07.03