00:00:00 --- log: started forth/04.08.05
00:36:52 --- join: Mur (~mur@mgw2.uiah.fi) joined #forth
00:36:57 --- quit: doublec ("Leaving")
00:49:25 --- quit: Mur_ (Read error: 110 (Connection timed out))
01:42:25 --- join: Mur_ (~mur@uiah.fi) joined #forth
01:54:38 --- quit: Mur (Read error: 110 (Connection timed out))
01:59:09 --- join: Fractal (jah@selling.kernels.to.linus.torvalds.at.hcsw.org) joined #forth
02:14:48 --- quit: Mur_ (Remote closed the connection)
02:15:27 --- join: Mur (~mur@uiah.fi) joined #forth
03:14:33 --- join: Topaz (jonny@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth
03:52:28 --- join: Mur_ (~mur@smtp.uiah.fi) joined #forth
04:03:07 --- join: crc (crc@0-1pool36-91.nas35.philadelphia1.pa.us.da.qwest.net) joined #forth
04:05:00 --- quit: Mur (Read error: 110 (Connection timed out))
04:05:49 --- join: chris2 (~chris@p50914939.dip0.t-ipconnect.de) joined #forth
04:17:05 --- quit: madwork (Read error: 104 (Connection reset by peer))
04:17:06 --- quit: madgarden (Read error: 104 (Connection reset by peer))
04:33:19 <chris2> anyone know of papers on optimizing forth compilers?
04:34:16 <Robert> I've been looking around a bit, too... I think forth.org had some links.
04:34:49 <chris2> or on stack based languages in general...
04:35:29 <Robert> http://www.complang.tuwien.ac.at/projects/rafts.html
04:35:38 <Robert> That was what I found.
04:35:47 <chris2> thx
04:44:10 --- quit: Mur_ (Remote closed the connection)
04:44:41 --- join: Mur (~mur@uiah.fi) joined #forth
05:16:35 --- join: Mur_ (~mur@uiah.fi) joined #forth
05:29:07 --- quit: Mur (Read error: 110 (Connection timed out))
06:04:16 --- quit: chris2 ("Client exiting")
06:21:55 --- join: I440r_ (~mark4@216-110-82-203.gen.twtelecom.net) joined #forth
06:22:56 --- join: madwork_ (~madgarden@derby.metrics.com) joined #forth
06:25:34 --- quit: Mur_ (Remote closed the connection)
06:26:05 --- join: Mur (~mur@smtp.uiah.fi) joined #forth
07:47:29 --- quit: crc ("Time for bed... Goodnight all!")
07:57:00 --- join: Mur_ (~mur@kyberias.uiah.fi) joined #forth
08:08:44 --- quit: Mur (Read error: 110 (Connection timed out))
08:29:01 --- nick: Mur_ -> Mur
08:33:52 --- join: warpzero (~warpzero@mi092.dn183.umontana.edu) joined #forth
08:36:47 --- join: Mur_ (~mur@mgw2.uiah.fi) joined #forth
08:38:39 --- quit: Mur (Read error: 60 (Operation timed out))
08:47:34 --- join: I4404__ (~mark4@216-110-82-203.gen.twtelecom.net) joined #forth
08:52:21 --- quit: fridge (Read error: 110 (Connection timed out))
08:59:14 --- join: fridge (~Jim@CommSecureAustPtyLtd.sb1.optus.net.au) joined #forth
09:01:08 --- quit: I440r_ (Read error: 110 (Connection timed out))
09:04:40 --- join: Astrobe (~astrobe@ARouen-106-2-2-82.w193-251.abo.wanadoo.fr) joined #forth
09:13:07 --- part: Astrobe left #forth
09:14:14 --- join: I440r_ (~mark4@216-110-82-205.gen.twtelecom.net) joined #forth
09:17:06 --- quit: fridge (Remote closed the connection)
09:18:45 --- join: fridge (~Jim@CommSecureAustPtyLtd.sb1.optus.net.au) joined #forth
09:28:06 --- join: fridge_ (~fridge@dsl-203-33-167-9.NSW.netspace.net.au) joined #forth
09:29:46 --- quit: I4404__ (Read error: 110 (Connection timed out))
09:40:24 --- quit: I440r_ (Read error: 110 (Connection timed out))
09:41:55 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth
09:42:05 --- mode: ChanServ set +o kc5tja
09:43:09 <kc5tja> Well, folks, I am seriously considering ditching the TTA architecture in favor of a more traditional CPU architecture at this point.  I am just plain NOT being successful in my attempts at engineering this new architecture so everything runs clean and smoothly.
09:44:16 <kc5tja> For example, the way instruction fetching works naturally sets up a two-stage pipeline.  Therefore control flow operations would have a branch delay slot associated with them, including subroutine calls!
09:46:13 <kc5tja> Working around these issues will involve a LOT of logic design (read, 'gates').
09:47:18 <kc5tja> For example, to eliminate the two-stage pipeline, I need to drive the internal bus multiplexors with the values read directly off the data bus.  Put another way, there is no distinct instruction register.
09:47:55 <kc5tja> But as soon as wait-states are introduced (e.g., as when reading or writing data to memory, for example), this obviously means the contents of the data bus will be lost, and therefore, the "instruction" will change.
09:48:59 <kc5tja> This also affects how literal data is loaded into the microprocessor as well.
09:49:19 <arke>   hi
09:50:02 <arke> :/
09:50:06 <arke> suck
09:50:23 <kc5tja> Therefore, I need to implement enough logic to temporarily store the last received instruction, and be smart about when when I load the instruction register and when I don't.
09:50:36 <arke> :/
09:50:59 <arke> you could make a staack addressomg ,acjomer
09:51:10 <kc5tja> umm...what?
09:51:17 <arke> err
09:51:21 <arke> forgive, i just woke up
09:51:24 <arke> stack addressing machine
09:51:37 <kc5tja> arke: I was making a stack machine.
09:51:39 <arke> instead of registers, you pass offsets into the stack
09:51:47 <arke> dunno how good that would work
09:51:55 <kc5tja> arke: Offsets into stack == registers.
09:52:11 <arke> swap would be xchg 0, 1
09:52:20 <arke> over would be push 1
09:52:22 <arke> etc
09:52:34 <kc5tja> That does not solve my issues.
09:52:37 <arke> :/
09:52:39 <arke> okies.
09:52:47 <arke> forgive, i just woke up
09:52:53 <kc5tja> First of all, you're introducing the notion of "operations" into the instructions, which isn't TTA anymore.
09:53:21 <arke> well, you said you wanted to ditch teh tta
09:53:24 <arke> so i have an idea
09:53:27 <arke> one that sucks :/
09:53:31 <kc5tja> Second, a stack architecture really needs no bits for addressing into the stack -- zero-operand is the ideal for code density and execution speed.
09:54:23 <arke> :/
09:54:48 <kc5tja> At this point, I'm very frustrated.
09:54:59 <arke> so you think you couldnt fit a decent tta on a FPGA? :/
09:55:09 <kc5tja> I never said that.
09:55:32 <arke> oh
09:55:38 <arke> so its just a hassle to do all of that?
09:55:42 <arke> but it would fit?
09:55:49 <kc5tja> I'm just saying, getting the TTA concept to work will involve a LOT more work and will be a LOT more complex than I'd originally anticipated.
09:55:57 * arke note to self: turn on brain
09:56:04 <arke> :/
09:56:13 <kc5tja> And frankly, I'm getting impatient.
09:57:31 <kc5tja> I came a long, long way on the MISC architecture, because it was trivial to design, easy to get code running for, and it was extremely fast in its execution.
09:57:54 <kc5tja> Now, I have to engineer a whole new CPU architecture, a whole new compiler that has to be made to fit that architecture, etc.
09:58:05 <kc5tja> Dude, I haven't even gotten to engineering the peripheral chips yet.
09:58:07 <arke> :'(
09:58:08 <kc5tja> This project is getting out of hand.
09:58:48 <kc5tja> I'm thinking of just going with an OpenRISC 1200 processor, and letting that be the main CPU.
09:58:51 <arke> what was the exact thing in your MISC that violated the patent again?
09:58:58 <kc5tja> arke: EVERYTHING.
09:59:02 <arke> oh, and then have an optimizing compiler? :)
09:59:06 <arke> kc5tja: er......
09:59:15 <arke> kc5tja: it wasnt just something like the idea of packed instructions? :/
09:59:59 <kc5tja> arke: The very *definition* of a MISC was in that patent.  The packed instructions, how the stacks operated internally, the pre-computation of results, etc.
10:00:17 <arke> shit :/
10:00:43 <kc5tja> Because it *all* ties together -- *all* those features combined are what makes the MISC uniquely adept at doing things.
10:00:46 <kc5tja> (and fast)
10:01:23 <kc5tja> Anyway, the OR1K architecture is essentially just like a MIPS architecture.
10:01:31 <arke> cool
10:01:33 <kc5tja> And it's available off of OpenCores, so it's under a free license.
10:01:44 <kc5tja> They also have VGA controllers, SDRAM controllers, etc.
10:01:46 <arke> an optimizing compiler could create good forth code for it, i think
10:01:51 <arke> aah, coool
10:02:06 <kc5tja> Problem is, Forth wastes the overwhelming majority of the chip's resources.
10:02:17 <kc5tja> Forth just plain doesn't need 32 general purpose registers.
10:02:28 <arke> yep :/
10:02:34 <kc5tja> Although, it IS true that in the O1K, there is no distinction between an integer and floating point register.  I *like* that.
10:02:40 <arke> :)
10:03:33 * arke googles
10:03:38 <kc5tja> Supposedly, in a Xilinx Virtex II FPGA, they have achieved 33MHz maximum clock rate on it, which is fast enough for my needs.
10:03:58 <arke> cool
10:04:20 <arke> only problem is writing a compiler that can take advantage of the RISC stuff :/
10:04:29 <arke> forth doesnt exactly lend itself well
10:04:45 <kc5tja> no, but with a good set of libraries, you can mitigate that.
10:05:01 <arke> libraries? or copmiler?
10:05:14 * arke would LOVE to write an optimizing compiler!
10:05:33 <kc5tja> A good set of vector words can really help increase the speed of a program, if you can think in terms of vectors.
10:05:47 <arke> well, help me think in vectors  :)
10:05:55 <kc5tja> arke: Learn J.
10:06:00 <arke> :/
10:06:00 <arke> ok
10:06:02 * arke google.s
10:06:50 <kc5tja> I can't help you learn anything you don't really want to learn, and it'll take me FOREVER to teach you the basics of vector programming, when a set of tutorials for J do that already.
10:07:17 <arke> okies
10:07:29 <kc5tja> The briefest, most concise, synopsis I can give is: Lists are the core data structure of Lisp and Scheme, and tables for Lua.  In a vector language, it is the humble array.
10:07:45 <arke> hmm
10:07:47 * arke reads
10:08:15 <kc5tja> The other thing that I was thinking of using the system for also was Smalltalk and Oberon.
10:08:32 <arke> aah
10:08:45 <arke> its kinda like SIMD im getting the impression
10:08:45 <kc5tja> This would increase the appeal of the computer to those beyond the Forth community.
10:09:13 <kc5tja> Yes, vector operations have (conceptually) one "opcode" and one or two vectors of data, each of which has N elements, where N is some positive integer.
10:09:30 <kc5tja> That one opcode *ideally* operates on all elements of a vector concurrently.
10:09:40 <arke> aah, cool.
10:09:58 <arke> but why would that help making a forth faster on a RISC? :/
10:10:04 <madwork_> Doesn't Joy do something similar with stacks?
10:10:07 --- nick: madwork_ -> madwork
10:10:09 <kc5tja> madwork_: No.
10:10:14 * arke 's brain is still on the bed pillow, sleeping
10:10:37 <kc5tja> arke: Because, as with J, it eliminates explicit looping.
10:10:44 <kc5tja> If you want to add two vectors, you say "V+".
10:11:04 <kc5tja> Not, BEGIN DUP WHILE 2DUP @ SWAP @ + somehow-store-it 1+ SWAP 1+ SWAP REPEAT
10:11:14 <kc5tja> (you get the idea)
10:11:28 <kc5tja> V+ would be coded in hand-tuned assembly language for the underlying hardware.
10:11:32 <arke> wow
10:11:38 <arke> there is a LOT of stuff to this language'
10:11:46 <kc5tja> Yes, and the language is *TINY*.
10:11:50 <kc5tja> It's just how it's all put together.
10:12:15 <kc5tja> Also, J's performance competes VERY well with that of raw C -- and it's purely interpreted, like the old 8-bit BASICs!
10:12:29 <arke> woah
10:12:31 <arke> nice
10:12:34 <kc5tja> It doesn't even compile to an intermediate bytecode first (in fact, no need to -- each operation is one, maybe two ASCII characters)
10:12:48 --- join: I440r_ (~mark4@216-110-82-66.gen.twtelecom.net) joined #forth
10:12:48 <kc5tja> This is what convinced me of the viability of vector processing.
10:12:49 <arke> (hey, I'd write a GW-BASIC clone for the kestrel :D )
10:13:14 <kc5tja> arke: Dude, if you can make a BASIC implementation that supported good vector operations, you'd be rocking.
10:13:18 <kc5tja> And you'd have a loyal fan base, I'm sure.
10:13:30 --- quit: fridge ("Leaving")
10:13:37 <arke> in-basic SIMD?? :/
10:13:41 <kc5tja> Why not?
10:13:48 <arke> nice....
10:13:50 <arke> :D
10:13:50 <kc5tja> Nothing wrong with the idea.
10:13:54 <madwork> And Forth doesn't map to vector processing?
10:14:06 <arke> arrays are already there. Now add some instructions to add them
10:14:07 <arke> :)
10:14:10 <kc5tja> madwork: Forth can map as much or as little as you like.  
10:14:26 <kc5tja> madwork: My point is, Forth needs a vocabulary (e.g., a library) of words to make it happen.
10:14:42 <kc5tja> Otherwise, Forth totally wastes the underlying capabilities of the CPU.
10:14:58 <kc5tja> madwork: Note: I'm considering ditching the TTA in favor of a more traditional RISC -- the OpenRISC 1200.
10:15:14 <kc5tja> Shit, I gotta get to work.
10:15:15 * kc5tja sighs
10:15:29 <arke> :/
10:15:29 <madwork> And J doesn't have a vocabulary of words?
10:15:33 <kc5tja> But anyway, here's my rationale: I'm getting sick and tired of waiting.
10:15:38 <kc5tja> madwork: What?
10:15:41 <madwork> If it's simpler, do it!
10:15:52 <arke> is there an emulator for teh openrisc 1.2k floating around?
10:15:56 <arke> and/or assembler?
10:15:56 <kc5tja> madwork: J is **THE** quintessential vector programming language -- it is a direct descendent of APL!
10:16:18 <madwork> I'm just not (immediately) seeing how J is doing anything a hand-tuned Forth can't do similarly. 
10:16:18 <kc5tja> arke: It's all on OpenCores.  It even has a version of Linux ported to it.
10:16:27 <kc5tja> madwork: THAT IS MY POINT.
10:16:35 <madwork> Oh, heh. :)
10:17:06 <kc5tja> madwork: If J, a BASIC-like language, can get C-like speeds, then so can Forth.  I don't NEED to optimize the Forth environment to hell and back *IF* (a) a good set of vector-oriented words are available, and (b) only those words are optimized.
10:17:22 <madwork> Yes.
10:17:59 <kc5tja> The idea being, optimize the most-often used words by coding in raw assembly language (or some other suitable language conducive to taking full advantage of the underlying CPU), and just use Forth as a "binding language" so to speak.
10:18:04 <madwork> I'll be doing something like this with Forthy as it advances (within my abilities), since I have stacks as a basic type.
10:18:12 <madwork> Right.
10:18:14 <kc5tja> Forth would execute so "rarely" compared to the SIMD words that its performance is inconsequential.
10:18:38 <madwork> Yes of course. It's all in the hardware.
10:18:46 <kc5tja> No, it's in the software.
10:18:58 <kc5tja> But the SIMD words are hand-tuned.
10:19:15 * madwork scrolls back looking for "SIMD"
10:19:26 <kc5tja> OpenRISC 1200, while it does have the vector instruction extension, sucks ass for vector processing.  It's not even superscalar.
10:19:43 <kc5tja> NO processor today gets hardware vector operation right.
10:19:44 <kc5tja> NONE.
10:19:46 <kc5tja> >:(
10:20:03 <madwork> You'll be the first?
10:20:21 <kc5tja> No.  The Amiga had a *damn* fine (and *damn* fast for its time) vector processor -- the blitter.
10:20:31 <kc5tja> Problem is, it was limited only to doing binary operations.
10:20:33 <madwork> Ahh.
10:20:37 <kc5tja> binary LOGICAL operations, that is.
10:20:45 <kc5tja> That's how it got its graphics so damn fast.
10:20:59 <kc5tja> The CPU was actually slower than that in a Macintosh.
10:21:03 <kc5tja> (by about 1MHz)
10:21:35 <madwork> Well I'll be looking forward to your next design. Sounds like you're going in an interesting direction.
10:21:54 <kc5tja> Well, I full-heartedly intend on making good on my promise of a C64-like system.
10:22:06 <madwork> Cool. :D
10:22:12 <kc5tja> That is never, ever going to change.
10:22:19 <kc5tja> Because that is what distinguishes my computer from a PC or Mac.
10:22:21 <arke> im making a GW-BASOIC :)
10:22:27 <madwork> BASOIC?
10:23:03 <kc5tja> Anyway, i gotta get to work.
10:23:05 <arke> basic
10:23:11 <arke> lates kc5tja
10:23:17 <kc5tja> It's even too late for me to shower now.
10:23:39 <arke> :/
10:23:43 <arke> sorry :/
10:24:03 <kc5tja> Don't worry -- it's not like I sweat there or anything.  (Unless the A/C is broken again, in which case, they get what they deserve.)
10:24:11 <madwork> Well, get going! :)
10:24:32 <kc5tja> All i can say is this: I'm getting damn impatient, and I've not even gotten around to designing the peripheral chips yet.
10:24:46 <kc5tja> And I found a VGA controller on OpenCores the other day too, which I'm probably going to use as well.
10:24:48 <madwork> I mean, get going to work. ;)
10:25:26 <arke> you're making him feel as if we d0ont want him here :)
10:25:31 <kc5tja> I just hope I can get everything as Verilog source files.
10:25:50 <madwork> I just want the guy to get to work on time so he can make money and Kestrels. ;)
10:25:51 <kc5tja> OpenRISC 1200 I know comes in Verilog source; but the VGA controller may not, in which case, I may have to implement my own anyway.
10:25:58 <kc5tja> Heheh :)
10:26:02 <kc5tja> OK, I'm out.
10:26:09 <madwork> Later!
10:26:09 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK")
10:26:27 <arke> :)
10:26:42 <madwork> arke, seperated control-flow is dreamy compared to how I had it before.
10:27:01 <arke> cool
10:27:14 <madwork> Yes. 
10:27:59 <madwork> Now I can work on some of the decompiler aspects.
10:51:58 --- quit: fridge_ ("rock out with your cock out")
11:04:46 --- join: Mur (~mur@kyberias.uiah.fi) joined #forth
11:15:31 --- quit: Mur_ (Read error: 110 (Connection timed out))
11:25:33 --- join: Mur_ (~mur@kyberias.uiah.fi) joined #forth
11:38:05 --- quit: Mur (Read error: 110 (Connection timed out))
11:47:00 --- join: TheBlueWizard (TheBlueWiz@207.111.96.120) joined #forth
11:47:00 --- mode: ChanServ set +o TheBlueWizard
11:48:17 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth
11:50:12 --- quit: SDO (Read error: 60 (Operation timed out))
11:54:40 --- join: arke_ (~chris@wbar8.lax1-4-11-100-108.dsl-verizon.net) joined #forth
11:54:40 --- quit: arke (Read error: 104 (Connection reset by peer))
12:01:24 --- join: ASau (~root@217.16.31.100) joined #forth
12:01:33 <ASau> Dobryjj vecher!
12:03:00 <TheBlueWizard> ASau hiya :)
12:04:07 <slava> hi
12:04:11 <Robert> Hi
12:09:52 <TheBlueWizard> slava hiya
12:09:56 <TheBlueWizard> Robert hiya
12:10:52 --- quit: tgunr (Read error: 104 (Connection reset by peer))
12:11:56 <Robert> Heh.
12:12:01 <Robert> You have a memory!
12:12:06 <Robert> Unlike certain Forth bots...
12:12:36 <TheBlueWizard> huh?
12:12:39 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth
12:12:49 <TheBlueWizard> tgunr hiya
12:14:35 <Robert> TheBlueWizard: The correct-ordered greetings.
12:16:25 <TheBlueWizard> ah...heh...though I may forgot certain localization versions :-]
12:17:05 <Robert> I think I remember most, actually.
12:17:22 * TheBlueWizard nods
12:17:30 <Robert> But only some languages.. I don't speak a single word french, for example. ;)
12:17:35 <Robert> Or Spanish.
12:17:41 <Robert> Except for 'XD'.
12:17:48 <TheBlueWizard> do you know when kc5tja usually comes online?
12:17:57 <TheBlueWizard> XD?
12:18:23 <arke_> TheBlueWizard: he had to go to work, so expect him in either 9 hours or not at all today
12:18:44 <Robert> TheBlueWizard: XD is the favourite smiley of most spanish-speakers.
12:18:49 --- quit: tgunr (Read error: 104 (Connection reset by peer))
12:18:54 --- nick: arke_ -> arke
12:18:56 <TheBlueWizard> arke_: I see
12:20:06 <TheBlueWizard> Robert: oh really? hmm...I do know some French and Spanish (I am picking up some Spanish words from all those signs and pamphlets in my town...a lot of them :)
12:20:43 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth
12:23:15 <Robert> TheBlueWizard: Not too much Spanish around here... Some immigrants (those we didn't send back to south america to be shot), but not really any public signs in it. :)
12:23:26 <arke> :)
12:23:28 <Robert> TheBlueWizard: It's either Swedish or English..
12:24:33 * TheBlueWizard nods
12:33:22 --- join: fridge (~fridge@dsl-203-33-167-9.NSW.netspace.net.au) joined #forth
12:33:33 --- quit: fridge (Client Quit)
12:35:32 --- join: fridge (~fridge@dsl-203-33-167-9.NSW.netspace.net.au) joined #forth
12:35:42 --- quit: fridge (Client Quit)
12:38:06 --- join: fridge (~fridge@dsl-203-33-167-9.NSW.netspace.net.au) joined #forth
12:47:22 <TheBlueWizard> all bye
12:47:33 --- part: TheBlueWizard left #forth
12:50:16 <madwork> Hi ASau.
12:51:23 <slava> ok, ratios work and i have a test suite to prove it :) time to start work on floats.
12:51:29 <slava> for now, i'll use libc routines to do str <-> float conversions
12:52:26 <madwork> 'Tis what I do.
12:52:56 <slava> what funcs do you use?
12:53:19 <madwork> sprintf, atoi, atof
12:53:36 <slava> ok
12:54:02 * arke is commenting code i didn't write
12:54:11 * arke is commenting PIC programming code
12:54:13 * arke hatesit
12:54:19 <arke> Robert: GONNA KILL YOU ASAALKAAAAGS
12:54:24 <arke> :)
12:54:26 <Robert> o_O
12:54:35 <Robert> That was unexpected.
12:54:55 <arke> well, you could have AT LEAST left a reference to the origin of the code
12:54:57 <arke> but noooooo
12:55:02 <arke> >:(
13:01:33 <arke> anyway...
13:01:42 <arke> this is gonna take me awhile
13:02:02 <Robert> Bah.
13:02:08 <Robert> Just go on.
13:02:12 <arke> no
13:02:15 <arke> i need this commented
13:02:15 <arke> !!1
13:02:23 <Robert> That's your problem then.
13:02:24 <arke> just because you are a slacker does not mean I am :)
13:02:34 <arke> its not that bad
13:02:39 <arke> just requires some cross-checking
13:03:17 <fridge> hah
13:03:25 <Robert> Who's being a slacker allowing himself getting stuck at that crap?
13:03:36 <arke> ...
13:03:38 <arke> my dear friedn
13:03:59 <arke> I am taking the time to sift through those pages, check up the numbers in a reference, figure out what they do, comment on it.
13:04:05 <arke> and if it doesnt make sense, check it again
13:04:07 <arke> elsewhere
13:04:09 <arke> that takes effort
13:04:11 <arke> im not a slacker
13:04:12 <arke> :)
13:05:01 <Robert> It's like saying I'm not a slacker if all I do is going in the woods picking mushrooms and feeding invisible friends with them, because that too requires some effort.
13:05:15 <arke> :D
13:05:19 <arke> ok, lets stop
13:05:32 <madwork> slackForth
13:05:37 <arke> Robert: by the way - I do not see how this could work. It's doing an unsupported PIC call
13:05:41 <fridge> Robert: I always wondered who that guy in the woods was
13:05:45 <Robert> arke: Oh?
13:05:50 <Robert> fridge: :)
13:06:02 <Robert> fridge: You're welcome to help me collecting them.
13:06:18 <arke> Robert: yeah
13:06:24 <arke> Look it up yourself
13:06:52 <arke> 0xff as byte 4 - that means bit 1 is set which is unsupported
13:07:30 <Robert> Hm, OK.
13:08:05 * Robert solves the problem by quietly ignoring it.
13:08:26 <arke> grr
13:08:35 <arke> could you PLEASE figure out where you got that code from?
13:10:39 <arke> man, this is so screwed up
13:10:43 <arke> pleae, find out who
13:14:02 <Robert> Uhm...
13:14:05 <Robert> How should I know?
13:14:08 <Robert> :P
13:14:15 <arke> actually, hold on, i think I might have figured this out
13:14:21 <arke> YOU STOLE THE FUCKING CODE!
13:14:24 <Robert> Oh.. Tell me when you got it.
13:14:36 <Robert> So WHAT? It's not like I'm its parent.
13:14:39 <arke> :/
13:14:45 <arke> you need to know the father, mmkay?
13:15:01 <Robert> Heh.... irq.asm - mein Sorgenkind.
13:15:08 <arke> :)
13:16:15 <fridge> haha
13:26:37 <arke> Robert: alrighty, got it figured out
13:26:42 <Robert> Nice. What was it?
13:26:46 <arke> Robert: it works. its compliant. 
13:26:56 <arke> Robert: it initializes the PIC
13:27:02 <arke> Robert: masks all interrupt
13:27:05 <Robert> The 0xff command was valid?
13:27:14 <arke> Robert: yes - I saw it in the wrong context
13:27:16 <Robert> (YAY I RULE)
13:27:17 --- quit: I440r_ ("Leaving")
13:27:30 <arke> Robert: since it was in init mode, not operation mode by then
13:27:59 <arke> would you like me to send you the file once I'm completely done? (just have a few more things to do)
13:28:22 <arke> Robert: wait --- did you write that code? :/
13:31:07 <arke> Robert: another question - out dl, al is valid,right?
13:33:10 <Robert> What are you porting it to?
13:33:11 <Robert> No
13:33:26 <Robert> Or are you just fixing it up?
13:35:28 <arke> fixing it up a bit, because its massively duplicated
13:36:41 <arke> also, i'm having it save the clobbered registers
13:36:46 <arke> so that they .... aren't clobbered
13:44:56 <madwork> Is there a good reason why ANS forth makes seperate compile words for stuff like CHAR? I'd think you're more likely to just want a char immediately during a word definition, rather than having to know to type [CHAR]. If you really want to, just POSTPONE it. Seems like a compiled CHAR is a less-likely case.
13:45:53 <arke> because its ANS thats why
13:46:54 <Robert> madwork: Well, CHAR can be useful for compile-time stuff.
13:50:50 <arke> Robert: teehee. the new irq_enable looks longer because of the comments ;)
13:50:59 <arke> Robert: but its actually shorter than the old one
13:51:59 <madwork> Robert, example?
13:52:32 <madwork> I tend to think I'm more likely to want the char literal during most of my word definitions, than the behaviour of CHAR at run-time.
13:52:32 <Robert> madwork: Stuff like   CHAR * CONSTANT MULTIPLICATION-OPERATOR
13:52:58 <madwork> That's run-time usage...
13:55:10 <Robert> Hmm... Run-time is pretty much the same as compile-time. Excuse my C-influenced terminology :)
13:55:25 <madwork> Heh.
13:55:27 <slava>   ( 0 ) 1 3 /f .
13:55:27 <slava> #<float>
13:55:31 <slava> ok, making progress :)
13:55:34 <Robert> That didn't make too much sense. Heh.
13:55:50 <Robert> (re: my own statement...)
13:55:52 <madwork> I'm just saying that : foo [char] * 42 emit ; is silly.
13:55:58 <slava>   ( 1 ) 1 3 /f 1 3 /f 1 3 /f + + >fixnum .
13:55:58 <slava> 1
13:56:02 <slava> great :)
13:56:08 <slava> now i need to do float>str and float>str
13:56:37 <Robert> slava: If you come up with any good code, I'm interested-
13:56:51 * Robert would also like floating-point support in some of his projects.
13:57:09 <slava> well for now i'm using libc to do the string conversions
13:57:13 <slava> i'll write my own code later
13:57:28 <madwork> Why?
13:57:39 <slava> why libc, or why write my own?
13:57:44 <madwork> Why your own.
13:58:06 <slava> well i use unicode strings, and doing a float -> c string -> factor string just seems messy.
13:58:10 <slava> or vice versa
13:58:19 <madwork> Ahh, of course.
13:58:25 <madwork> Taken from Forthy: snprintf(tmp, 32, "%.16g", value->value.f);
13:58:35 <slava> how big is tmp?
13:58:43 <madwork> 33
13:58:45 <slava> ah
13:59:20 <madwork> Next line is:                tmp[32]=0;
13:59:21 <madwork> ;)
13:59:39 <Robert> Mmm... paranoia.
14:00:10 <slava> doesn't snprintf write a null byte?
14:00:15 <madwork> Well, snprintf won't write the last null if the string's too long.
14:00:54 <slava> oh.
14:01:10 <madwork> So yes, just because I'm paranoid, doesn't mean people aren't following me.
14:01:58 <slava> void primitive_str_to_float(void)
14:01:58 <slava> {
14:01:58 <slava> 	char* c_str = to_c_string(untag_string(env.dt));
14:01:58 <slava> 	env.dt = make_float(atof(c_str));
14:01:58 <slava> }
14:02:27 <Robert> madwork: :)
14:02:49 <slava> note i don't have to deallocate c_str manually :)
14:03:13 <madwork> slava, your C code looks very lispy somehow. ;)
14:03:27 <slava> :)
14:03:45 <madwork> c_str is stored in a temporary buffer?
14:03:53 <madwork> Or just the string, rather.
14:04:32 <slava> c_str is allocated in the heap
14:04:38 <slava> by to_c_string
14:05:10 <madwork> Yes. make_float() deallocates it then?
14:05:15 <slava> no
14:05:17 <slava> i have gc
14:05:24 <slava> make_float takes a double argument
14:05:25 <madwork> Ah.
14:05:36 <slava> my floats are 'boxed', unfortunately.
14:05:41 <madwork> boxed?
14:05:59 <slava> yes, each float is a heap allocated object storing the float value
14:06:06 <madwork> Ahh.
14:06:13 <slava> heap allocation is fast -- its just a HERE increment
14:06:23 <slava> but this uses up memory quickly if you do heavy fp calculation, so you need frequent gc
14:06:33 <madwork> My only GC is the stack.
14:06:44 <arke> :D
14:06:45 <madwork> Or rather, value copies and drops.
14:06:48 <slava> yes, at least i don't have to copy strings when i do 'dup' :)
14:06:55 <arke> :)
14:06:56 <madwork> Heh. 
14:07:01 <madwork> Well, I can change that easily enough.
14:07:38 <madwork> So you have reference-tracked strings then.
14:10:43 <slava> hmm
14:10:45 <slava> almost works:
14:10:46 <slava>   ( 0 ) "12.3" str>float .
14:10:46 <slava> 16901403
14:10:46 <slava>   ( 1 ) 1 3 /f unparse-float .
14:10:46 <slava> "0.3333333333333333"
14:11:05 <slava> oh it thinks str>float returned a fixnum...
14:11:59 --- quit: tgunr (Read error: 104 (Connection reset by peer))
14:14:25 <arke> Robert: alright, irq.asm is  l33t c0mpl33t
14:15:48 <Robert> n33t.
14:16:05 <arke> uum
14:16:16 <arke> would you host teh f2? :)
14:16:26 --- nick: TomasuAway -> Tomasu
14:16:27 <Robert> Sure.
14:16:29 * Tomasu is back (gone 43:30:30)
14:16:30 <slava> YAYAYAYAYAAYYAYA
14:16:30 <slava>   ( 1 ) 0.3 0.3 + .
14:16:30 <arke> yay
14:16:30 <slava> 0.6
14:16:43 <arke> yayayayayayyyyy
14:16:43 <arke> ;)
14:17:22 <arke> then you can take a look and change things
14:17:23 <arke> :)
14:19:50 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth
14:21:47 <arke> Robert: uum, I'll have a working microkernel sent to you before you sleep. When do you go to sleep?
14:22:11 <Robert> When I feel sleepy.
14:22:25 <slava> madwork, ping
14:22:34 <slava> madwork, what format specifier do i need so that there is always at least one zero after .?
14:22:39 <slava> eg i want 1.0 to be printed as 1.0 not 1
14:24:07 <madwork> Hmm.
14:24:26 <madwork> That's a good question. I should do that as well.
14:24:52 <madwork> slava, why str>float? Why not just >float?
14:25:29 <slava> because >float converts integers/ratios to floats
14:25:36 <slava> i like to keep number coercion and strign parsing separate
14:26:03 <madwork> OK... but I'd think you should just convert to float no matter the source type.
14:26:19 <slava> no, because >float is primitive and eventually str>float will be a colon def.
14:26:20 <madwork> I am taking a scripting stance, though.
14:26:30 <slava> i'm taking a theoretical purity stance :)
14:26:36 <madwork> Heh. Fair enough. 
14:26:49 <slava> java factor did all kinds of automatic conversion
14:26:53 <slava> eg you could do "2" "2" + . and get 4
14:26:59 <slava> but this was too complicated
14:27:18 <madwork> static void word_to_float(FSYSTEM *sys) 
14:27:18 <madwork> { 
14:27:18 <madwork>      double value; 
14:27:18 <madwork>      
14:27:18 <madwork>      value=fs_get_float(sys, -1);
14:27:19 <madwork>      fs_pop(sys);
14:27:21 <madwork>      fs_push_float(sys, value);
14:27:23 <madwork> }
14:28:08 <slava> any ideas with the 1.0 thing?
14:28:55 <madwork> Let me take a look...
14:34:19 <madwork>      printf("*%.01f*\n", 0);
14:34:48 <madwork> Actually, nope.
14:34:49 <slava> thanks!
14:34:53 <slava> oh :)
14:35:01 <madwork> That works, but decimal precision is only 1 digit.
14:35:10 <madwork> You'll get a 0.0 though. :)
14:35:23 --- quit: Topaz ("Leaving")
14:35:37 <madwork> You may have to special-case this.
14:36:22 <slava> well its no big deal, i'll fix it later.
14:36:39 <slava> next up on the 'port from java' list: complex numbers.
14:37:03 <slava> after this, primitives for sin/cos etc... and my 31337 math library will work
14:38:47 <madwork> Hehe.
14:39:02 <madwork> Why don't you just let the user export their own primitives?
14:41:48 <slava> what do you mean?
14:42:06 <slava> there will be an FFI, much much later.
14:43:07 <madwork> What's FFI?
14:43:31 <madwork> And I mean... if they want a SIN primitive, they could export a function that does that. If they don't want it, they don't add it.
14:44:11 <slava> FFI = foreign function interface
14:44:15 <slava> what do you mean 'export'?
14:44:50 <madwork> Well, they'd "register" the primitives. Like so:
14:44:50 <madwork>      fs_register_func(sys, "drop", fs_pop, FS_DEFAULT); 
14:44:50 <madwork>      fs_register_func(sys, "swap", word_swap, FS_DEFAULT); 
14:44:50 <madwork>      fs_register_func(sys, "dup", word_dup, FS_DEFAULT); 
14:44:50 <madwork>      fs_register_func(sys, "over", word_over, FS_DEFAULT); 
14:45:09 <slava> ah
14:45:13 <slava> well this isn't really for embedding
14:45:17 <madwork> Ah.
14:45:18 <slava> although later i plan on supporting that.
14:45:33 <slava> java factor exists for my game. C factor exists for my http server :)
14:45:34 <madwork> Cool.
14:45:36 <slava> which it can't run yet :)
14:45:39 <madwork> Hehe.
14:46:29 <madwork> My philosophy with Forthy was that it should only have what it needs, the rest is up to the user. So I've got a VM manipulation API, and they can compose whatever language style they like out of that.
14:46:34 <slava> java factor is cool for embedding because its very easy to call java APIs and make java objects
14:46:43 <madwork> Sounds nice.
14:46:47 <slava> i have this philosophy too
14:46:54 <slava> except my idea of 'what it needs' is a bit bigger :)
14:47:05 <slava> i think nice math primitives are a must
14:47:14 <slava> but if i ever do graphics, etc it will be optional.
14:47:24 <madwork> Heh. Well stuff like SIN/COS etc are not needed if you're using it as a configuration file system.
14:47:37 <madwork> Or, writing high-level AI in it.
14:47:44 <madwork> But then again, I'm not a math person. ;)
14:47:48 <slava> true, but 200kb is a bit big for a configuration file system, no? :)
14:47:57 <slava> sin/cos are cheap though beucase its just libc calls after all...
14:47:59 <madwork> What's 20Kb? :P
14:48:02 <madwork> 200Kb?
14:48:11 <slava> factor executable + image
14:48:13 <madwork> Forthy is <90K compiled.
14:48:14 <slava> executable is 39kb.
14:48:23 <slava> is that an exe?
14:48:25 <madwork> Yea.
14:48:25 <slava> or does it have a library too?
14:48:35 <slava> like a library of forthy code
14:48:36 <madwork> Well, some of the C libs it uses.
14:48:42 <madwork> Oh.
14:48:48 <slava> is everything in C?
14:48:55 <madwork> That's just the size of my standalone app I use for testing.
14:49:03 <madwork> Yea, all C. Well, some soft words in my test.
14:49:20 <slava> ok
14:49:30 <slava> you don't think you'd reduce size by writing some parts in forthy?
14:49:49 <madwork> Yea, but I want it to be fast, too.
14:49:59 <slava> true :)
14:50:06 <madwork> And, I didn't think a 90K exe was too bad. :)
14:50:27 <slava> factor is not unbearably slow but its slower than a DTC forth, primarily because I do type checks and there is more memory allocation happening
14:50:55 <slava> howver, people are willing to put up with mozilla, openoffice, java, etc... :)
14:50:56 <madwork> OK, 84K for the current console app I have building here at work.
14:50:59 <madwork> Heh, yes.
14:51:04 <madwork> Forthy is ITC.
14:51:19 <madwork> And its speed is comparable to Lua.
14:51:23 <madwork> So, I'm happy with that.
14:52:10 <madwork> OK, gotta go home for supper, etc. bbl.
14:52:13 <slava> bye
14:53:19 <fridge> bye
14:53:21 --- quit: fridge ("rock out with your cock out")
15:19:37 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576090.sympatico.ca) joined #forth
15:20:13 <madgarden> Back!
15:20:28 --- quit: ASau (Remote closed the connection)
15:20:33 <arke> :)
15:23:44 <madgarden> arke, your head a splode.
15:24:48 <arke> OX(
15:30:11 <slava> hi mad
15:32:34 <madgarden> Hi again.
15:57:36 --- nick: Mur_ -> mur
16:19:00 --- quit: warpzero (Read error: 60 (Operation timed out))
16:21:32 --- nick: Tomasu -> TomasuAway
16:21:34 --- nick: TomasuAway -> Tomasu
16:45:26 --- join: doublec (~doublec@coretech.co.nz) joined #forth
16:46:08 <doublec> slava, "Printing floating point numbers quickly and accurately": http://www.cs.indiana.edu/~burger/FP-Printing-PLDI96.pdf
16:46:13 <doublec> slava, maybe a useful paper?
16:46:29 <slava> nice
16:46:40 <slava> you read the logs huh :)
16:46:46 <doublec> yup :)
16:47:07 <slava> oh FUCK FUCK FUCK
16:47:08 <doublec> scan them anyway
16:47:10 <slava> i'm trying to use FOP now
16:47:11 <slava> but
16:47:15 <slava> openjade -t fo ... just sig11's.
16:47:31 <doublec> ahh, the joys of docbook.
16:48:16 <arke> :/
16:50:05 <slava> doublec, the number tower is almost done.
16:50:20 <slava> doublec, i have to add one more primitive, then write a few words and it will have complex, floats, ratios, etc all working
16:50:51 <doublec> slava, nice!
16:51:31 <slava> doing TDD has helped tremendously
16:51:43 <madgarden> TDD?
16:52:17 <slava> test driven development
16:52:22 <slava> writing unit tests and code at the same time
16:52:30 <slava> running unit tests after each non-trivial change
16:52:39 <slava> trying to write a unit test for each potential branch in a functione
16:52:40 <slava> etc
17:54:17 --- join: TheBlueWizard (TheBlueWiz@pc6edn1d.ppp.fcc.net) joined #forth
17:54:18 --- mode: ChanServ set +o TheBlueWizard
18:08:26 <madgarden> Aha... cool.
18:18:40 --- part: TheBlueWizard left #forth
18:29:28 --- quit: madgarden (Read error: 104 (Connection reset by peer))
18:44:43 --- join: fridge (~fridge@dsl-203-33-167-9.NSW.netspace.net.au) joined #forth
18:51:04 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576090.sympatico.ca) joined #forth
18:51:27 <madgarden> WTF. Hi!
19:07:10 <madgarden> ' test ' foo is
19:07:42 <I440r> er no
19:07:45 <I440r> ' test is foo
19:07:56 <madgarden> Not with the IS I just wrote. :P
19:07:57 <I440r> or ' test !> foo
19:08:16 <madgarden> Hmm...
19:08:26 <madgarden> ' test ' foo <!
19:08:41 <I440r> erm no you would just use ! then
19:08:53 <I440r> except you would need to do a >body first
19:08:59 <madgarden> That's what <! would do.
19:09:02 <I440r> ' test ' foo >body !
19:09:07 <madgarden> Breaking standards all willy nilly is fun!
19:09:17 <I440r> that woudl read as "from-store"
19:09:57 <madgarden> Or "store-back-into-that-thing-on-the-left" if you will.
19:10:04 <I440r> lol no
19:10:18 <madgarden> Hey man, it's my Forth, I can do what I wanna. ;P
19:10:24 <I440r> why nhmm im bored :/
19:10:38 <madgarden> What's new with you?
19:10:47 <I440r> nuttin
19:10:51 <madgarden> nuttin at all?
19:10:56 <I440r> not really
19:11:04 <I440r> im kinda stagnating
19:11:12 <madgarden> Ahh.
19:11:19 <madgarden> I'm actually using my Forthy for a project at work.
19:11:30 <madgarden> As well as a game project I'm working on.
19:11:52 <I440r> :)
19:12:07 <I440r> im not allowed to talk about anything im doing at work lol
19:12:12 <madgarden> Oh no?
19:12:17 <I440r> no
19:12:40 <madgarden> super secret homeland defense initiative?
19:12:48 <I440r> yes and no
19:12:55 <madgarden> building giant nuclear robots to save the U.S. from cyborg terrorists?
19:13:00 <madgarden> ;)
19:13:04 <I440r> damn. how did you know ?
19:13:13 <madgarden> Women's intuition... er...
19:13:18 <I440r> lol
19:13:30 <madgarden> I used my wife's. She's sleeping, didn't need it.
19:19:40 --- join: madgarden_ (~madgarden@Kitchener-HSE-ppp3576090.sympatico.ca) joined #forth
19:19:55 <madgarden_> :-/
19:20:20 <I440r> lol
19:21:01 --- quit: madgarden (Read error: 113 (No route to host))
19:21:42 --- nick: madgarden_ -> madgarden
19:26:53 <madgarden> What's a good name for a yielding repeat/until/again etc.? REPEAT... ?
19:27:13 <madgarden> 10 for i . next... cr
19:28:12 --- join: proteusguy (proteusguy@66-90-229-217.dyn.grandenetworks.net) joined #forth
19:28:23 <I440r> begin while repeat you mean ?
19:29:32 <madgarden> Yes, I want to put a "yield" just before the loop-end for any of those. So, need a good syntax for these kind of loops. 
19:30:46 <I440r> yield ?
19:31:44 <madgarden> Yea. Like, cooperative multitasking, basically... but between the C system and the Forthy system.
19:33:18 <I440r> ya lost me
19:35:15 <madgarden> My C program is running a forthy program... and since it's a game, it needs to update at 60FPS. So if I'm doing some loops in forthy, I want to be able to yield the low priority code to the game system so it can update the rest of the logic, screen, etc.
19:36:30 <I440r> oh
19:36:32 <I440r> a pause
19:36:54 <I440r> why not build a pause into next
19:37:31 <I440r> or into exit :)
19:37:57 <I440r> each thread would be able to run one whole word and then ylu would task switch :)
19:38:18 <I440r> that wouldnt work too good tho :P
19:44:33 <madgarden> Well, I can't actually compile something into next. The inner loop is written in C.
19:44:45 <madgarden> But, I can single-step code if I want.
19:45:07 <madgarden> Anyway, this is a different case altogether... pause as you say, yes, but only for loops, so that the loop doesn't take over the whole system.
19:48:47 <madgarden> All I'm really asking here is a good name/syntax for the pausing loop words. ;)
19:48:51 <madgarden> REPEAT...
19:48:54 <madgarden> Or something.
19:48:56 <madgarden> REPEAT,
19:48:57 <madgarden> REPEAT.
19:49:10 <arke> hi
19:49:21 <madgarden> hi arke
19:49:27 <arke> :)
19:49:29 <arke> i made a song
19:49:33 <arke> called "meat beater"
19:50:46 <madgarden> Based on personal experiences?
19:51:00 <arke> lol
19:51:00 <arke> yeah
19:54:05 <madgarden> Hehe!
19:54:15 <madgarden> So what would *you* name a yielding loop word, arke?
20:03:59 --- quit: madgarden (niven.freenode.net irc.freenode.net)
20:05:04 --- join: madgarden (~madgarden@pptp.metrics.com) joined #forth
20:07:42 --- quit: madgarden (Killed by ballard.freenode.net (Nick collision))
20:07:42 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576090.sympatico.ca) joined #forth
20:07:45 --- quit: madgarden (Read error: 54 (Connection reset by peer))
20:08:26 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576090.sympatico.ca) joined #forth
20:08:36 --- quit: madgarden (Client Quit)
20:12:21 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576090.sympatico.ca) joined #forth
20:12:37 <madgarden> Argh.
21:32:47 --- quit: proteusguy (Read error: 104 (Connection reset by peer))
21:34:05 <madgarden> Haha, cool. Just slid a map across the screen at 60FPS, using my yielding loop words.
21:38:01 <zardon> you are working on your own forth?
21:39:13 <madgarden> Yeppers.
21:39:19 <madgarden> C Forth.
21:39:28 <madgarden> For scripting/extension.
21:41:13 <zardon> cool
21:42:45 <madgarden> Started it in the summer of 2002. Lately, I have been using it in projects, evolving it as I need.
21:44:05 <zardon> i was looking at ficl a while ago, it seems to be nice source
21:46:01 <madgarden> Yea, I refer to FICL now and then when working on my project. They are similar in some ways. FICL is faster, about 2.5x... but I think mine's nicer to use, though. ;)
21:50:20 <madgarden> Actually, with a test I just did, 1.7x faster, but it depends on what's being done, really.
21:51:47 <madgarden> And my empty for/next loop is over 2x faster than FICL's equivalent do/loop... so *shrug*.
21:55:48 <zardon> hmm
22:03:01 <madgarden> Ahh... that's better. "control-flow mismatch" is a much nicer error than "error". :)
22:04:53 <slava> hi all
22:05:06 <slava> benchmarking?
22:05:37 <madgarden> Who me?
22:06:23 <slava>   ( 1 ) [ 1000000 [ ] times ] time
22:06:23 <slava> 1820
22:06:42 <slava> (milliseconds)
22:06:54 <slava> for/next loop done 1 million times
22:07:00 <madgarden> What speed of processor?
22:07:04 <slava> 2.8ghz p4
22:07:29 <doublec> 4,619 ms on the jvm
22:07:34 <madgarden> > : test 1000000 for next ;
22:07:34 <madgarden> ok
22:07:34 <madgarden> [ ] : 0
22:07:34 <madgarden> > pstart test pend
22:07:34 <madgarden> ok
22:07:34 <madgarden> [ 1000005 0.05 ] : 0
22:07:36 <madgarden> >
22:07:44 <madgarden> On my Duron 700.
22:07:52 <slava> doublec, if i recompile native factor with -O3 and disable stack overflow checks:
22:07:54 <slava>   ( 0 ) [ 1000000 [ ] times ] time
22:07:54 <slava> 717
22:07:59 <doublec> nice
22:08:06 <slava> doublec, i'll have complex nums ocmmited shortly.
22:08:10 <doublec> cool
22:08:21 <slava> my jvm time:
22:08:23 <slava>   ( 3 ) [ 1000000 [ ] times ] time
22:08:23 <slava> 5588
22:08:36 <slava> native factor is 7x faster ;)
22:08:52 <madgarden> Heh.
22:08:53 <slava> that loop could be compiled in jvm factor though.
22:08:58 <slava> and be about 2x slower than native factor
22:09:00 <slava> let me try :)
22:09:09 <madgarden> I should try it here some time.
22:09:14 <doublec> which is especially great considering that it's not jit'd whereas the java stuff is.
22:09:34 <madgarden> 50ms for 1000000 ain't too shabby though, I figure. :)
22:10:03 <slava> madgarden, yeah, i guess you dont have the overhead of type checks?
22:10:11 <slava> doublec, i saw a freebsd port of valgrind
22:10:28 <madgarden> Actually, I do have types.
22:10:44 <doublec> slava, great!
22:11:48 <madgarden> I don't check return values for the bulk of it... I use C exceptions for errors.
22:12:13 <madgarden> Removing so many if statements sped things up quite a bit.
22:12:28 <slava> i haven't even started optimizing native factor though :)
22:13:25 <madgarden> Heh, good. ;)
22:13:46 <slava> madgarden, my inner interpreter iterates a linked list, so there's an upper bound on its performance. i could compile x86 assembly at some stage though.
22:13:52 <doublec> you could detect that your benchmark quotation has no stack affect and makes no external calls so it could just not call it. Speed 0ms. Not too good for real world benchmarking results tho!
22:14:04 <madgarden> Your system sounds to be much more dynamic than Forthy.
22:14:15 <slava> doublec, factor is too imperitive for that, its hard to make side effect guarantees
22:14:25 <madgarden> My inner loop is a tight loop... incrementing an IP.
22:14:27 <slava> doublec, unless you check the entire call tree for set-vector-nth, set-cdr, etc
22:14:38 <slava> madgarden, and i bet your + isn't generic?
22:14:48 <doublec> yes, there would be a limited set of words it could look for. Most people would consider it cheating since it'd only be useful for giving good benchmark results :)
22:14:55 <slava> madgarden, and your for/next loop is written in C, mine is in factor :)
22:15:43 <madgarden> Heh, yep.
22:15:47 <madgarden> Well, sort of.
22:15:50 <doublec> slava, what's the speed of callcc like in native factor compared to jvm factor? Is it a lighter overhead?
22:16:41 <doublec> (I'd check myself but I don't have it built where I am)
22:17:26 <slava> doublec, what should i test?
22:17:29 <slava> doublec, callcc loop?
22:19:04 <slava> doublec, wow
22:19:06 <slava> doublec, check this out
22:19:08 <slava> jvm factor:
22:19:10 <slava>   ( 11 ) 9 redo
22:19:10 <slava>   ( [ 100000  [ [ drop ] callcc0 ] times ] time )
22:19:10 <slava> 1657
22:19:19 <slava> native factor:
22:19:20 <slava>   ( 1 ) USE: continuations 0 redo
22:19:20 <slava>   ( [ 100000  [ [ drop ] callcc0 ] times ] time )
22:19:20 <slava> 1597
22:20:05 <doublec> slava, try a 'call' instead of drop.
22:20:17 <doublec> that's pretty fast.
22:23:20 <slava> native factor: 3 seconds
22:23:24 <slava> jvm factor: OutOfMemoryError?!
22:23:43 <doublec> Yeah, I'm getting the latter too. Odd. 3 seconds is very good.
22:24:29 <slava> i suspect memory leak
22:25:50 <slava> wow
22:25:54 <slava> check this out
22:26:20 <slava> http://paste.lisp.org/display/2136
22:26:56 <doublec> wow, big memory growth.
22:26:57 <slava> that is jvm factor
22:27:34 <slava> and native: http://paste.lisp.org/display/2136#1
22:27:49 <doublec> With -Xmx256m passed to the JVM, 100,000 iterations gives 3525ms.
22:28:01 <slava> although this distubs me:
22:28:02 <slava> 131072 KB total, 130437 KB free
22:28:08 <slava> 131072 KB total, 130898 KB free
22:28:15 <slava> actually no
22:28:16 <slava> i misread
22:28:37 <slava> i thought the usage reduced from startup to after this, which would suggest something got gc'd that should not have
22:29:46 <doublec> nice to see the C vm frees up everything.
22:30:25 <slava> after the http server is imported, i expect memory usage to be around 180 kb
22:30:32 <doublec> which is pretty damn good.
22:30:56 <slava> compared to scheme implementations with similar functionality? hell yeah :)
22:31:10 <slava> i'm adding bignum and float output to image.factor
22:31:22 <slava> there are literals in the math libs that aren't handled yet.
22:32:03 <doublec> ok
22:32:57 <slava> don't worry i'll get back to work on the http server very soon. it will rock with multiplexed i/o.
22:33:08 <doublec> definitely
22:33:17 <I440r> downloading at 1.01 megs per second P:)
22:33:55 <doublec> time for me to go, talk to you later.
22:35:01 --- quit: doublec ("Leaving")
22:40:19 --- join: proteusguy (proteusguy@66-90-229-17.dyn.grandenetworks.net) joined #forth
22:46:56 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth
22:47:03 --- mode: ChanServ set +o kc5tja
22:47:48 <slava> hi kc5tja
22:54:47 <kc5tja> Howdy
22:55:00 <kc5tja> The OpenRISC architecture is looking increasingly attractive to me for the Kestrel.
23:14:40 <kc5tja> slava: What are your, and other's, feelings about using the OpenRISC 1200 CPU instead of a custom-made CPU design?
23:14:48 <kc5tja> madgarden is perfectly OK with it.
23:15:10 <kc5tja> But using something like a more traditional RISC might end up turning some people off from the Kestrel.
23:15:29 <zardon> it uses delay slots does it not?
23:15:39 <kc5tja> Yes, it exposes delay slots to the programmer.
23:16:11 <zardon> have you any clever ideas regarding them, or might they just be hard to optimize for?
23:16:30 <kc5tja> I don't see them as being too terribly hard to optimize for.
23:16:44 <kc5tja> I would have to do more study on it though.
23:16:55 <kc5tja> Worst-case scenario, plot a NOP after the l.b instruction.
23:17:06 <kc5tja> err.. l.nop -- sorry.  :)
23:17:24 <kc5tja> (anyone know why OR1K instructions all start with "l."?  It's weird.  But I digress.)
23:17:56 <zardon> avoid MIPS comming after them?
23:18:16 <kc5tja> zardon: Unlikely.  They appear to use the prefix to sort various instruction types out.
23:18:22 <kc5tja> E.g., lv. are for vector operations.
23:20:30 <kc5tja> Oh well.
23:23:41 <kc5tja> I'm just not sure what direction to take the Kestrel in right now.
23:23:44 --- quit: tgunr ("Leaving")
23:23:45 <kc5tja> I'm very torn.
23:25:16 --- quit: Fractal (Read error: 110 (Connection timed out))
23:26:07 <zardon> TTA would be cool, but that would certainly add alot of time to get the system up
23:28:33 <kc5tja> Yeah, exactly.
23:29:02 <kc5tja> But the OpenRISC is more "limiting" in that I can't add unique features to it as easily (if at all, since much of the chip real-estate is going to be dedicated to the instruction and data caches).
23:36:58 <slava> kc5tja, ping
23:37:35 <slava> http://factor.sourceforge.net/factor-snapshot.png
23:37:45 <slava> in about 10 minutes, i hacked up a jedit plugin that embeds a factor interpreter
23:37:45 --- join: uxx (rpc@global.whiteh8.net) joined #forth
23:37:52 <slava> i didn't restart the editor once -- it can reload plugins :)
23:42:10 <slava> the time in the bottom left is wrong
23:42:23 <slava> i'm not sure why *nix java gives gmt time
23:44:35 --- quit: mur (Remote closed the connection)
23:45:10 --- join: mur (~mur@mgw2.uiah.fi) joined #forth
23:59:59 --- log: ended forth/04.08.05