00:00:00 --- log: started forth/03.11.16 00:38:28 --- quit: melinda (Read error: 110 (Connection timed out)) 01:19:25 --- quit: onetom ("Lost terminal") 01:20:20 --- join: onetom (~tom@cab.bio.u-szeged.hu) joined #forth 03:08:10 --- join: haroldo_ (~haroldo@r200-40-166-143.adsl.anteldata.net.uy) joined #forth 03:15:43 --- quit: haroldo (Read error: 110 (Connection timed out)) 03:43:25 --- join: Robert_ (~snofs@c-255a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 03:45:55 --- quit: Robert (Read error: 104 (Connection reset by peer)) 04:01:51 --- nick: Robert_ -> Robert 04:26:38 --- join: schihei (~schihei@pD95486B0.dip.t-dialin.net) joined #forth 05:56:32 --- quit: schihei (Client Quit) 09:33:06 greetings 09:52:03 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 09:57:11 terve 09:57:15 anybody here right now? 10:11:25 --- quit: warp0x00 (Read error: 110 (Connection timed out)) 10:14:46 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 10:24:29 --- join: melinda (melinda@melinda.usercloak.freenode) joined #forth 10:40:24 --- quit: warp0x00 (Read error: 110 (Connection timed out)) 10:40:54 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 10:50:14 --- quit: warp0x00 (Read error: 60 (Operation timed out)) 11:01:04 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 11:15:28 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 11:15:28 --- mode: ChanServ set +o kc5tja 11:15:49 I rode 8.5 miles into work today on my bike. I arrived much earlier than I expected to (a definite good sign). 11:15:59 Then I found out that I wasn't scheduled to work that day. 11:16:06 So I rode back 8.5 miles. :) 11:16:47 Total distance: approximately 17 miles. Total time: almost *exactly* two hours. Average round-trip speed: 8.5 miles per hour. Seeing as this is up from 6MPH last time, I'd say that's a definite overall health improvement. 11:16:58 (especially considering the hills I have to go over. Sheesh!) 11:19:44 --- quit: warp0x00 (Read error: 110 (Connection timed out)) 11:20:00 --- join: jamc (dne@as3-6-8.asp.s.bonet.se) joined #forth 11:27:48 * kc5tja is away: helping roommate w/ homework 11:45:24 --- join: moritz_ (~moritz@p50877F31.dip.t-dialin.net) joined #forth 11:45:38 hello 11:53:59 --- join: suprdupr (CrowKilr@Ottawa-HSE-ppp3654343.sympatico.ca) joined #forth 11:54:21 hi there 12:33:00 --- quit: haroldo_ (calvino.freenode.net irc.freenode.net) 12:33:01 --- quit: mur (calvino.freenode.net irc.freenode.net) 12:33:01 --- quit: oooo (calvino.freenode.net irc.freenode.net) 12:33:01 --- quit: ianP (calvino.freenode.net irc.freenode.net) 12:33:01 --- quit: skylan (calvino.freenode.net irc.freenode.net) 12:33:01 --- quit: MysticOne (calvino.freenode.net irc.freenode.net) 12:33:01 --- quit: chandler (calvino.freenode.net irc.freenode.net) 12:34:12 --- join: haroldo_ (~haroldo@r200-40-166-143.adsl.anteldata.net.uy) joined #forth 12:34:12 --- join: skylan (sjh@vickesh01-4649.tbaytel.net) joined #forth 12:34:12 --- join: oooo (o@virgo.bombsquad.org) joined #forth 12:34:12 --- join: MysticOne (mysticone@mysticone.usercloak.freenode) joined #forth 12:34:12 --- join: mur (~mur@smtp.uiah.fi) joined #forth 12:34:12 --- join: ianP (ian@inpuj.net) joined #forth 12:34:12 --- join: chandler (~darmok@64-145-60-36.client.dsl.net) joined #forth 12:34:30 * kc5tja is back (gone 01:06:42) 12:46:44 * suprdupr is writing a post for clf about his DTC-ESP thought 12:46:55 * kc5tja nods 12:47:05 * kc5tja needs food . . . badly. 12:47:15 Rode 17 miles on my bike today. 12:48:42 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 12:48:56 ! 12:49:13 here its starting to get cold, i wouldnt do that 12:49:40 www.themeatrix.com 12:49:41 When you don't have a car, you have no choice. 12:49:48 or a bus pass ;p 12:50:49 one of my goal at the university is to modify a car o compressed air 12:51:29 OK, let me rephrase: you don't have a car, AND the bus schedules are wholesale out of whack with your work schedule. 12:52:09 still the same job? 12:53:12 hey kc5tja 12:53:58 kc5tja: for lib.fs , whats the difference between (int) and (int...) 12:54:40 Yes. 12:54:49 Context? 12:54:50 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 12:54:56 As in I need some more context? :) 12:55:24 kc5tja: gforth, lib.fs 12:55:37 you know what that means, because you posted something to clf something a while ago 12:55:44 :D 12:56:02 my question is, whats the difference between the two types, (int) and (int...)? 12:56:14 and (float) and (float...) and (void) and (void...) 12:57:18 In C, ... indicates "variable number of arguments follow this one." 12:57:35 So maybe the difference between int and int... is the latter probably handles varargs somehow. 12:57:37 oh 12:57:40 This is JUST a guess though. 12:57:49 but thats a _return_ type! 12:57:49 I do not know a thing about how GForth's C-interface API works. 12:57:50 heh 12:57:54 neither do i 12:58:01 im just trying to get it to work for me :) 12:58:14 If that's a return type, then I don't know. 12:58:26 ok 12:58:30 * arke posts on clf 12:58:47 Also, I don't recall posting anything to CLF about this topic. 12:58:51 Especially recently. 12:59:26 Hmmm....complex carbohydrates!! After the bike ride today, this hits the spot (pasta). 13:04:14 In article , 13:04:14 kc5tja@dolphin.openprojects.net (Samuel A. Falvo II) wrote: 13:04:14 > OK, folks. I've downloaded GForth 0.4.0, and I still cannot find any 13:04:14 > included documentation on how to use its ability to "import" libraries. 13:04:15 The main reason for not documenting is that it is going to change as soon as 13:04:17 [snip] 13:04:39 http://groups.google.com/groups?q=gforth+how+to+use+lib.fs&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=787em6%24j6 13:05:31 And I posted that . . . when? 13:05:39 I'm using GForth 0.6.2 now. :D 13:05:54 January 21, 1999 13:05:55 lol 13:05:57 thats so ancient 13:05:58 :P 13:06:09 And it's detestible that the author still hasn't documented it. 13:06:22 (I do know that he changed it again from 0.5.0 to 0.6.0) 13:06:22 yeah.... 13:06:36 nod 13:06:52 Hmmm....daytime....I'm home....I have big antenna outside....I have antenna tuner....10m should be propegating.....hmmm..... 13:07:00 I'm trying to make a SDL binding for gforth 13:07:08 Play NWN? Or play on the radio? NWN? Radio? Tough.... 13:07:17 and the documentation (read: the lack thereof) isn't helping 13:07:17 That'd be nice. 13:07:32 :) 13:07:35 yeah 13:07:36 * kc5tja is researching and studying object models and "middleware infrastructure" again. 13:07:43 whats that? 13:07:53 CORBA is considered "middleware." 13:08:02 ..........................? 13:08:23 (application A) <---> CORBA (note it's in the "middle") <----> (application B) 13:08:24 i should make a BF for gforth, just because I can. 13:08:30 oh, ok :) 13:09:36 DCOM is a competitor to CORBA, based on COM. 13:09:43 :) 13:09:50 * kc5tja really likes COM. Simple, to the point, works well, minimal overhead. 13:09:58 DCOM just blows it *WAY* the hell out of proportion though. 13:10:31 heh 13:10:37 100 allot create buffer 13:10:41 why does that not seem right? 13:10:44 or is it right? 13:12:37 aaaccck 13:13:08 You need to create the buffer before you give it any space. :) 13:14:14 wtf is up with allot? 13:14:22 isnt allot supposed to be (n -- addr) 13:14:25 aaargh 13:14:38 ok, so how do i make a buffer with this retarded allot? 13:14:41 No. 13:14:44 Absolutely not. 13:14:48 (n -- ) 13:14:52 says dpans 13:14:55 ALLOT's job is to allocate space in the dictionary. 13:15:04 Not on the heap. 13:15:08 so i shoudlnt even use it? 13:15:10 ack 13:15:12 ack! 13:15:13 CREATE's job is to create a label. 13:15:17 Listen to me first. 13:15:23 CREATE's job is to create a label for something. 13:15:25 ANything. 13:15:27 Doesn't matter what. 13:15:38 So "create buffer" will create a new word called "buffer". 13:15:54 When you run buffer, it returns the address of its body (again, *anything*) 13:16:00 ALLOT allocates space. 13:16:17 So, CREATE BUFFER 100 ALLOT is used to create a buffer called BUFFER, which consists of 100 bytes. 13:16:38 --- quit: warp0x00 (Read error: 110 (Connection timed out)) 13:17:54 I either thoroughly confused you, or you're off doing something else. :) 13:18:07 no, it makes sense 13:18:24 however, i've always though allot was (n -- addr) 13:18:28 Nope. 13:18:29 :) 13:18:30 for no particular reason, i guess :) 13:18:33 thanks 13:18:36 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 13:18:37 allocate works... 13:18:46 Well, because it's usually the only memory allocation word a Forth programmer tends to use. 13:19:02 Yep, ALLOCATE is used for heap allocation. 13:19:48 ok, so I'll use that... 13:26:23 hrm 13:26:32 the rkforth allot could be 13:27:24 : allot current-dictionary dictionary-end @ + dictionary-end ! ; 13:27:28 :) 13:30:27 --- quit: suprdupr () 13:36:55 That's basically how allot is implemented in most Forth's I've seen. 13:37:07 : allot h +! ; 13:37:17 : , here ! 1 cells allot ; 13:37:25 : c, here c! 1 chars allot ; 13:37:28 etc. 13:37:39 where h is the variable used to hold the current value of HERE. 13:37:42 : here h @ ; 13:40:03 :) 13:44:03 --- quit: warp0x00 (Read error: 110 (Connection timed out)) 13:44:24 --- part: moritz_ left #forth 13:44:57 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 13:58:56 --- quit: tathi ("leaving") 14:07:51 kc5tja: did you go watch The Elegant Universe? :) 14:08:13 --- quit: warp0x00 (Read error: 110 (Connection timed out)) 14:14:51 No 14:15:06 I don't have cable here. 14:15:52 it's not on cable :) but, that's okay, because it's on the Internet! 14:16:21 http://www.pbs.org/wgbh/nova/elegant/program.html 14:16:22 it's cool 14:16:32 all about string theory, multiple dimensions, etc :) 14:17:10 * kc5tja nods 14:19:04 Good evening 14:28:45 re 14:28:58 --- quit: melinda (Read error: 104 (Connection reset by peer)) 14:29:45 bbiab 14:31:25 --- join: melinda (melinda@melinda.usercloak.freenode) joined #forth 14:51:47 back 14:51:56 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 14:56:01 kc5tja: anyway, go watch that series when you get a chance ... it's really interesting :) 14:56:23 I will. 14:56:29 I have other things at the moment to complete. 14:56:35 I'll try to watch it later tonight. 15:01:00 --- quit: warp0x00 (Read error: 60 (Operation timed out)) 15:04:56 --- join: haroldo (~haroldo@r200-40-166-152.adsl.anteldata.net.uy) joined #forth 15:06:12 --- quit: jamc ("I'm a nuclear submarine under the polar ice cap and I need a Kleenex!") 15:07:37 hmm, Mops 5.4 15:13:31 --- quit: haroldo_ (Read error: 104 (Connection reset by peer)) 15:13:58 Anyone here know which Slackware package contains libgimpprint1.so? 15:15:02 * chandler suggests kc5tja ask #slackware 15:15:14 --- join: warp0x00 (~warpzero@dsl.142.mt.onewest.net) joined #forth 15:17:34 I was just curious to know if anyone here knew. 15:18:11 aah. my knee-jerk reaction is caused by running #slackware 15:18:31 hmm. #hamradio 15:20:40 Running #slackware? That is your channel? 15:26:01 well, I am but one op 15:26:22 Hmmm...just got done reading the vitriol about /away messages. 15:26:47 If I'm going to be kick-banned for typing something like /away food, then that channel can go to hell. 15:27:14 I wouldn't arbitrarily kickban for that, for starters. and secondly, it's public notifications that are the problem 15:27:41 Well, I'm just saying the text in the /away stuff is unnecessarily antagonistic, and downright threatening. 15:27:59 there are up to 200 people in that channel, and the away messages would be annoying if everyone had them on 15:28:01 * kc5tja left because nothing of interest was going on, BTW. 15:28:22 tis often the case. 15:28:36 OTOH, away messages are sent only once, when its set. 15:28:48 and then when you return 15:28:52 Right. 15:28:55 but many clients come with autoaways too 15:29:15 My point being, one line out of a hundred or so per person, in my experience, isn't that bad. 15:29:33 I'm not an op, so obviously I don't have the control you do. But from my perspective, it's not that big of a deal. 15:29:33 most of the people in the channel are just idling, so that's all they ever say 15:29:47 #debian has tons of idlers too. It's not an issue there. 15:30:07 * kc5tja finds nick-changers far, far, far, far more offensive than /away-users. 15:30:17 yes, that was the other reason I put that up there 15:30:23 I didn't say I'd kickban anyone anyway 15:30:33 We had this one person in #hamradio who would **CONSTANTLY** change his nick. Very annoying. :) 15:30:35 it was just the recommended three minutes' hate 15:30:43 Heh 15:31:03 btw, de n9vfl 15:31:30 :) 15:31:40 You active on HF at all? 15:31:50 no. I'm a no-code tech 15:31:53 Ahh 15:32:00 and I haven't found the ham station here at IU yet 15:32:03 * kc5tja upgraded to tech+ while in the military about 10 years ago. 15:32:05 (IU == Indiana University) 15:32:09 so you're General now? 15:32:12 Trying to pass general, but I need to find the free time to actually take the test. 15:32:27 I thought all Tech+'s became Generals a while back 15:32:31 No 15:32:43 ok, my memory is obviously a bit crufty 15:32:48 Tech +'s will remain tech+'s for as long as they renew, but don't upgrade. 15:32:55 oh. ok 15:33:09 It's just that they're not issuing new tech+'s now. 15:33:14 I'm trying to remember why I thought that - did they drop the extra code requirement on the general or something? 15:33:31 All CW requirements are 5wpm now. 15:33:31 :) 15:33:36 Right up to Extra class. 15:33:42 aah, that's right. that's why my father took Extra 15:34:10 (he didn't have a problem with the test, as RF engineer is his dayjob) 15:34:37 I find most of what he does quite inscruitable :-) 15:34:45 --- join: warpzero (~warpzero@dsl.142.mt.onewest.net) joined #forth 15:35:40 --- quit: warp0x00 (Connection timed out) 15:36:30 How do you mean? 15:36:54 I don't grok the RF mindest, beyond the basic physics 15:37:24 I'm a digital person 15:45:04 * kc5tja nods 15:45:15 I kind of strattle both lines, but I admit to having more digital experience than RF. 15:45:44 I like your inet.decay.txt file. Would it be OK if I took it and re-posted it on a site that I'm planning on putting up? 15:45:55 (I do intend on tweaking its appearance to make it "fit in" a bit more) 15:45:55 --- join: ayrnieu (julian@206.61.132.173) joined #forth 15:49:03 kc5tja: that's not my web site 15:49:07 that rant was written by somebody else 15:50:03 hmm 15:50:06 I'll just link to it then. 15:51:03 fucking qwest 15:53:02 --- quit: warpzero ("#") 15:59:40 what the smeggin' hell is wrong with mpegs? 16:03:07 I keep finding movies I want to see in proprietary encodings. 16:04:26 --- join: Sonarman (~matt@adsl-64-171-254-156.dsl.snfc21.pacbell.net) joined #forth 16:06:34 Indeed, that is annoying. 16:13:30 Hmmm 16:13:35 What media player are you using? 16:13:50 I'm finding mplayer works quite well on at least 90% of the movies I download. 16:14:53 I keep seing quicktime or realplayer 16:15:21 I use mplayer 16:17:01 modern quicktime (as in post-sorensen) is MPEG, an actual standard. needless to say, I don't think mplayer plays it all that well 16:18:45 mplayer works great on mpegs 16:20:43 MPEG4? 16:20:55 as in, real ISO MPEG4, not the unrelated DivX format? 16:21:04 I've never found a quicktime movie that it plays, and I can't even figure out how to download realplayer movies 16:21:12 donno about mpeg3 16:21:17 I mean mpeg4 16:21:23 Herkamire: Hmm...Is your mplayer able to use the Win32 plug-ins at all? 16:21:46 I asume it can't. I'm on PPC 16:22:05 http://www.apple.com/quicktime/gallery/mpeg4.html 16:22:22 you're wasting a perfectly good ppc on something that doesn't run quicktime? :-) 16:22:42 chandler: yeah, and every six months or so I sorta want to watch something in quicktime 16:27:46 chandler: no dice on those mpegs 16:27:58 ok. those are real ISO MPEG4s 16:28:05 those are quicktime files 16:28:13 ISO MPEG4 is QuickTime 6 16:28:54 More accurately, QT6 encapsulates an MPG4 video stream. 16:29:09 I thought QuickTime was the designated wrapper for MPEG4? 16:29:14 MPEG is just a compression standard. It's not a file format standard in and of itself. It's possible to have ISO MPEG 4 encoded AVIs, for example. 16:29:34 Perhaps it's the suggested wrapper, I wasn't aware ISO made such recommendations. 16:29:51 But I know the core "codec" is able to be used independently of any wrapper technology. At least it has in the past. 16:36:07 oh, looks like I installed mplayer without mpeg support. stupid ebuild didn't list mpeg as an option 16:38:12 chandler: I've never been a particular fan of quicktime. It was always laggy when I used it, but that was before apple started rendering the desktop as a scene graph (or whatever you call it) on the graphics card 16:38:12 --- join: ASau (~asau@158.250.48.197) joined #forth 16:38:27 Dobryjj nocher! 16:38:51 Dobroe utro! 16:39:13 Tol'ko ochen' rannee utro... 16:48:00 --- quit: haroldo (calvino.freenode.net irc.freenode.net) 16:48:00 --- quit: mur (calvino.freenode.net irc.freenode.net) 16:48:00 --- quit: oooo (calvino.freenode.net irc.freenode.net) 16:48:00 --- quit: ianP (calvino.freenode.net irc.freenode.net) 16:48:00 --- quit: skylan (calvino.freenode.net irc.freenode.net) 16:48:00 --- quit: MysticOne (calvino.freenode.net irc.freenode.net) 16:48:00 --- quit: chandler (calvino.freenode.net irc.freenode.net) 16:48:18 --- quit: melinda (calvino.freenode.net irc.freenode.net) 16:48:18 --- quit: Robert (calvino.freenode.net irc.freenode.net) 16:49:04 --- join: haroldo (~haroldo@r200-40-166-152.adsl.anteldata.net.uy) joined #forth 16:49:04 --- join: chandler (~darmok@64-145-60-36.client.dsl.net) joined #forth 16:49:04 --- join: ianP (ian@inpuj.net) joined #forth 16:49:04 --- join: mur (~mur@smtp.uiah.fi) joined #forth 16:49:04 --- join: MysticOne (mysticone@mysticone.usercloak.freenode) joined #forth 16:49:04 --- join: oooo (o@virgo.bombsquad.org) joined #forth 16:49:04 --- join: skylan (sjh@vickesh01-4649.tbaytel.net) joined #forth 16:49:43 --- join: melinda (melinda@melinda.usercloak.freenode) joined #forth 16:49:43 --- join: Robert (~snofs@c-255a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 17:21:34 --- quit: ayrnieu (calvino.freenode.net irc.freenode.net) 17:21:34 --- quit: TreyB (calvino.freenode.net irc.freenode.net) 17:21:34 --- quit: arke (calvino.freenode.net irc.freenode.net) 17:21:34 --- quit: Sonarman (calvino.freenode.net irc.freenode.net) 17:24:27 --- quit: melinda (calvino.freenode.net irc.freenode.net) 17:24:27 --- quit: Robert (calvino.freenode.net irc.freenode.net) 17:24:28 --- quit: oooo (calvino.freenode.net irc.freenode.net) 17:24:28 --- quit: MysticOne (calvino.freenode.net irc.freenode.net) 17:24:28 --- quit: haroldo (calvino.freenode.net irc.freenode.net) 17:24:28 --- quit: ianP (calvino.freenode.net irc.freenode.net) 17:24:28 --- quit: skylan (calvino.freenode.net irc.freenode.net) 17:24:28 --- quit: chandler (calvino.freenode.net irc.freenode.net) 17:24:28 --- quit: mur (calvino.freenode.net irc.freenode.net) 17:24:28 --- quit: onetom (calvino.freenode.net irc.freenode.net) 17:24:29 --- quit: kc5tja (calvino.freenode.net irc.freenode.net) 17:24:29 --- quit: Herkamire (calvino.freenode.net irc.freenode.net) 17:24:29 --- quit: Zoopee (calvino.freenode.net irc.freenode.net) 17:24:29 --- quit: ChanServ (calvino.freenode.net irc.freenode.net) 17:26:00 --- join: Robert (~snofs@c-255a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 17:26:00 --- join: melinda (melinda@melinda.usercloak.freenode) joined #forth 17:26:00 --- join: onetom (~tom@cab.bio.u-szeged.hu) joined #forth 17:26:00 --- join: haroldo (~haroldo@r200-40-166-152.adsl.anteldata.net.uy) joined #forth 17:26:00 --- join: chandler (~darmok@64-145-60-36.client.dsl.net) joined #forth 17:26:00 --- join: ianP (ian@inpuj.net) joined #forth 17:26:00 --- join: mur (~mur@smtp.uiah.fi) joined #forth 17:26:00 --- join: MysticOne (mysticone@mysticone.usercloak.freenode) joined #forth 17:26:00 --- join: oooo (o@virgo.bombsquad.org) joined #forth 17:26:00 --- join: skylan (sjh@vickesh01-4649.tbaytel.net) joined #forth 17:27:11 --- join: ayrnieu (julian@206.61.132.173) joined #forth 17:27:11 --- join: arke (~chris@ca-cmrilo-cuda1-c3b-66.vnnyca.adelphia.net) joined #forth 17:27:11 --- join: TreyB (~trey@cpe-66-87-192-27.tx.sprintbbd.net) joined #forth 17:27:14 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 17:27:14 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 17:27:14 --- join: Zoopee (alsbergt@zoopee.org) joined #forth 17:27:14 --- mode: calvino.freenode.net set +o kc5tja 17:27:17 --- join: Sonarman (~matt@adsl-64-171-254-156.dsl.snfc21.pacbell.net) joined #forth 17:28:59 --- join: ChanServ (ChanServ@services.) joined #forth 17:28:59 --- mode: calvino.freenode.net set +o ChanServ 17:29:18 --- quit: ChanServ (Shutting Down) 17:46:13 --- join: I440r (~mark4@12-58.lctv-a5.cablelynx.com) joined #forth 17:49:35 ? 17:52:02 --- join: warp0x00 (~warpzero@dsl.142.mt.onewest.net) joined #forth 17:53:08 Good morning! 18:09:55 Greetings. 18:10:47 Any topic for today? 18:10:50 --- join: ChanServ (ChanServ@services.) joined #forth 18:10:50 --- mode: calvino.freenode.net set +o ChanServ 18:11:03 It seems I've missed one. 18:11:33 Nope. It's been pretty quiet. 18:11:49 Rats -- I need to get to the supermarket, but it's dark, and I don't want to ride my bike in the dark. 18:12:25 Hm. Do you have to ride crossroad? 18:13:18 i hate quest 18:13:23 *qwest 18:16:17 --- quit: ChanServ (Shutting Down) 18:16:32 I've seen a post in one gamers' echo. 18:16:43 --- join: ChanServ (ChanServ@services.) joined #forth 18:16:43 --- mode: calvino.freenode.net set +o ChanServ 18:16:43 1: I've installed a new game. 18:16:58 No. I ride my bike in to work. 18:17:14 2: A console? How many levels? 18:17:32 I did just receive a request to complete Dolphin, and to write a harddrive recording software package for it though. :) 18:17:41 1: 8 consoles. 5 levels but difficult to advance... 18:17:42 ... 18:17:47 1: FreeBSD. 18:18:04 Just a quest. 18:19:19 kc, what is "Dolphin"? 18:19:51 It's an operating system I was writing earlier (some years ago), then stopped due to a combination of lack of interest from other people, and lack of time on my part. 18:20:31 Is it free? Can I evaluate? 18:27:29 It doesn't exist (anymore). 18:27:31 I have to re-write it. 18:27:40 The OS was intended to be free, but apps were allowed to be commercial. 18:28:36 OK, when/if you get it run, call me. :) 18:28:52 Oh, I intend on making quite a splash with it. 18:29:11 The first thing, it'll be a small OS, concentrating on useful productivity, not on flash and dazzle. 18:29:57 Secondly, it'll be based heavily on a standardized object model, permitting greater software "meta-integration." 18:30:08 By that I mean, like Unix, software is typically shipped as a collection of well-defined, small apps. 18:30:27 The "meta-app" just couples them together, piece by piece, like a Unix-style pipeline. 18:31:09 Of course, nothing prevents the construction of large, tightly integrated behemoths. It's just that such software won't "fit" in the general vibe of the rest of the system. 18:58:43 How would you encapsulate low-level parts during construction? 18:59:27 You have to bootstrap the process. 19:00:10 Hide through rebuildinig? 19:00:25 That's one of the nice things I like about COM: there is virtually no boot-strapping required. 19:00:41 What do you mean by hide by rebuilding? 19:00:54 I mean this: 19:01:31 you have different low-level objects (functions, words, objects...) 19:02:05 when you create more high-level ones you have to restrict access to previous 19:02:37 it's a matter not of protection but of usage 19:02:59 I am not sure I know how to answer your specific question. 19:03:17 You code in/for Dolphin like you would in most other OSes. 19:03:37 Certain functions in your software is exposed in the form of OS-conforming "interfaces." 19:03:59 Software can access information only through these interfaces. 19:04:27 For in-process methods, the call is a simple indirect jump through a v-table. 19:05:12 For machine-local methods that are not in-process, or for in-process methods that cross thread boundaries, (a)synchronous message passing is required to invoke the functionality desired. 19:05:35 For remote invokations, networking is required. 19:07:32 --- quit: arke (Connection reset by peer) 19:08:01 --- join: arke (~chris@ca-cmrilo-cuda1-c3b-66.vnnyca.adelphia.net) joined #forth 19:09:03 In fact, I have not seen any OS solved my problem. 19:09:27 Consider a name space. 19:09:40 I don't remember many details of your last problem, but I do remember determining it wasn't possible for an OS to solve your specific problem. 19:10:07 You have the root one that is only visible at start. 19:10:37 In my case, there are only so many ways to get data from point A to point B; that path needs to be as highly optimized as possible. 19:10:57 Direct subroutine calls are obviously the ideal solution; however, they won't work in a component-structured software environment. 19:11:51 When you increase complexity, you want to utilize the most complex things at first, not the simplest ones. 19:12:18 For any given set of requirements, there is an irreducable amount of complexity. 19:12:44 For component-structured software, you must have a consistent and system-wide object infrastructure that transcends programming language. 19:12:51 It's common problem, I see, when bootstrapping, to hide names of basic operations' names, after they're used. 19:13:44 I'm not sure we're discussing the same thing. 19:13:46 Just for not to list the primitives first and not override them. 19:14:03 I'm sure we're not. ;) 19:14:30 Well, the whole purpose of an interface is to establish a strong contract with the user of the interface: you do not want to expose inner details, because it violates the very thing that makes interfaces work in the first place. 19:14:49 To do so necessarily causes the inner details to become part of the interface itself anyway, so where does one draw the line? 19:15:33 If I have a directory, I can create a new file, open an existing one, delete a file, or rename a file. That's it. Everything else is accomplished using those basic four methods. There is no point in exposing anything beyond those four functions. 19:15:59 But is it a RAM-disk directory? Is it a FAT32 directory? NTFS? Each directory is implemented differently. It's wreckless to expose per-type details. 19:16:34 If you need FAT32-specific details, or access to HPFS extended attributes, you can use specific per-filesystem interfaces that go beyond the "normal" interface. 19:16:47 Well, consider you're bootstrapping file-oriented system. 19:16:54 That's what I love about component object model -- it fully embraces this. 19:17:31 There's really not a whole lot to consider. 19:17:35 First you define buffering level, next file level. 19:17:52 Buffering would not be part of the directory interface. 19:18:04 That's a fundamentally different part of the whole system -- it's represented with its own set of interfaces. 19:18:09 How would you hide buffering level names after you've utilized them? 19:18:15 I wouldn't. 19:18:23 They are proper objects in their own right. 19:18:56 How would you change name space access order? 19:19:03 The details you hide are the details that are decidedly implementation-specific. Disk cache/buffering is not related to a filesystem, so it doesn't belong in the filesystem code. 19:19:10 I wouldn't. 19:19:47 In C, an interface is represented as a table of function pointers. 19:19:53 In C++, a class with a set of virtual methods. 19:20:02 In Oberon, a record type with a collection of type-bound procedures. 19:20:08 In Lisp, a CLOS object with multimethods. 19:20:56 One should never attempt to fight their desired programming language. 19:21:04 Instead, one should learn to take advantage of it. 19:21:12 hello kc5tja 19:21:18 That's all the same. 19:21:37 See my comment above about "certain minimum complexity for any given task." 19:21:46 You defend programmer's point. 19:21:46 It's provable, has been proven, and will continue to hold true forever. 19:21:51 --- quit: warp0x00 (Client Quit) 19:21:58 And only this one. 19:22:16 Well, I've been researching this for about 10 years now. 19:22:25 I think I have a pretty solid understanding of the requirements involved. 19:23:00 kc5tja: this might be OT, but 19:23:06 Hm. De Broyle hypothesis was not proved for several years. ;) 19:23:17 kc5tja: whats your thoughts on MS's implementing a Database filesystem in longhorn? 19:23:26 arke: About Damned Time. 19:23:28 (tm) 19:23:35 They've been promising that for years. 19:24:06 ReiserFS for Linux beat them to the punch though. 19:24:29 * kc5tja is using ReiserFS for Linux at the moment, and it's the single fastest filesystem I've ever used. 19:25:04 Have you seen journalling FS shoot-out? 19:25:06 how does Reiser work/ 19:25:08 ? 19:25:11 ASau: Nope. 19:25:24 arke: Almost everything in the filesystem is represented as a B-tree. 19:25:26 Just look at devchannel.org 19:25:44 ASau: I tried using XFS, but it hosed my system. I won't touch XFS ever again. 19:25:59 Reiser's is not the fastest in ceratain cases. 19:26:01 kc5tja: ? 19:26:09 B-tree = binary tree, i know that 19:26:11 ASau: Well, that argument is applicable to anything. 19:26:11 but how? 19:26:16 arke: No, it isn't. 19:26:24 B-tree = balanced tree. 19:26:53 Robert Sedgewick has written whole books on how B-trees work, how to construct them, and manipulate them. 19:27:02 I don't think I could offer a succinct answer to your question. 19:27:16 kc Just look at article, you may have the case. 19:27:20 er................. 19:27:42 arke: B-trees are not simple data structures. :) 19:28:09 arke: They are balanced and constructed and maintained so that to find anything takes log_2(n) time, where n is the number of items in the database. 19:28:34 In the case of ReiserFS, both directories and the file contents themselves are stored in B-trees. 19:28:56 The directory lookup returns the file's inode given a filename. 19:29:18 Having that information, the filesystem can construct a database key of the form (inode, offset). 19:29:32 This is then used to index into the database on the disk. 19:31:46 neat 19:31:53 * kc5tja nods 19:32:21 Random access is fast, but not in case of writing. 19:32:39 Reiser is fast at writing too. 19:33:02 hrm 19:33:05 The same block allocation strategies used in other high performance (journaled or logged) filesystems apply to DB-based filesystems too. 19:33:23 Also, it has some problems when space is short. 19:33:29 * arke thinks he has figured out rkfs 19:33:35 Well, all filesystems do. 19:33:42 --- join: warp0x00 (~warpzero@dsl.142.mt.onewest.net) joined #forth 19:33:46 ext2fs will happily kernel-panic under Linux when space gets too short. 19:33:56 rkfs wont 19:33:58 :) 19:34:06 Remember that harddrive filesystems tend to allocate huge expanses of storage space to minimize fragmentation. 19:34:19 in fact, rkfs could have every single block allocated, and still happily do reads and writes 19:34:22 As soon as disk space starts to expire, it can't do that, so it must start to fragment to store data. 19:34:34 * arke nods 19:34:43 arke: If you work on a block-by-block basis, you'r FS *will* be slow. Guaranteed. 19:34:44 :) 19:34:49 rkfs is based on aligned defragmentation 19:35:04 kc5tja: why's that? 19:35:06 I know that in our quantum chemistry lab XFS is used, Reiser's causes some problems. 19:35:23 Because you're read and write times will be dominated by seek times. 19:35:34 XFS is highly unstable for me. 19:35:50 It routinely kernel panics when the init process launches. 19:36:00 Meaning, I can't boot with it. 19:36:16 ouch. 19:36:36 ReiserFS has been exceptionally high performance for me. 19:36:37 I think they have different FS for booting and working. 19:36:40 kc5tja: no, it won't. 19:36:41 * kc5tja is imminently pleased with it. 19:37:04 it probably wont be as fast as reiser, but it can work quite well on low disp space 19:37:07 disk* 19:37:29 arke: Modern filesystems deal with extents, which are spans of blocks, rather than individual blocks. They don't start allocating individual blocks unless they absolutely, positively, 100% have to. 19:37:56 arke: When a filesystem is said to "not work well in low disk space" situations, it means that it slows to a crawl because of fragmentation. 19:38:31 It usually does not mean that it will crash (though ext2fs has in the past for me), or something. 19:38:49 But the truth still holds: if you have 100% of a partition full, that's it -- no more data is going to be stored there, no matter how hard you try. 19:39:13 which is also not necessarily true for rkfs 19:39:14 kc: QM folk use XFS because of dramatic speed lossage. 19:39:40 ASau: there is no doubt in my mind that XFS is a fast filesystem. 19:39:43 ...in Reiser 19:39:49 kc5tja: i'll tell ya why 19:39:51 It is, after all, designed specifically for real-time multimedia applications. 19:40:01 But that doesn't change the fact that ReiserFS is itself a damn fast filesystem. 19:40:15 I just point that another case exists. 19:40:21 kc5tja: the blocks are all aligned, and header+data will always be exactly 1024 bytes (or maybe a different figure, for later on) 19:40:25 XFS has its faults too though. 19:40:48 kc5tja: this means that its possible for a block to be allocated for something, and not be completely full. 19:40:59 arke: Disk blocks are always aligned to something. 512 bytes is the sector size on a PC-formatted disk. 19:41:03 in that case, a 100% full partition can still get some data 19:41:15 well, then 2 sectors make a block. 19:41:23 arke: How? 19:41:36 arke: A 100% full partition is full, by definition. It cannot possibly receive more data. 19:41:37 and if you're block is only 3/4 filled, and the whole disk is allocated, you can _still_ write 19:41:51 arke: Well, by definition, then, it's not full, now is it? 19:41:51 :) 19:41:58 i define a full partition as a partition in which all blocks have been allocated to something. 19:42:07 Not me. 19:42:14 so, its "full" because you can't have anymore blocks 19:42:18 Well, I do too, but I don't sublet individual disk blocks. 19:42:58 Though, it would be an interesting experiment to try and make a filesystem which does. 19:43:03 I've often thought of it in the past. 19:43:14 But I've never before been able to arrive at a satisfactory solution for my needs. 19:43:27 in rkfs, if the disk is full, you can still do level 1 block calls without a problem, unless they have to invoke the level 0 call, new-buffer 19:44:04 Example: files often start off small, but then tend to grow over time. Using byte-granularity on a storage medium with this kind of behavior will involve much copying as new space is allocated to hold the new (larger) copy of the file. 19:44:19 ok, my boot detects the hpt370a then hjda and then hdd and HANGS :( 19:44:27 I440r: :( 19:44:33 I440r: what do you have to say about rkfs? 19:44:39 ? 19:44:42 lol 19:44:46 sounds like a good idea 19:44:49 arke: OK, good luck. I just don't think you'll find really good performance with it. 19:44:55 make it bigger on the inside than it is on the outside 19:45:05 so a 1 k drive will fit 500 gigs of data :) 19:45:10 I440r: :) 19:45:33 I440r: Well, his idea has merit in that it eliminates internal fragmentation. 19:45:36 kc5tja: no, but if i manage to do it the way i plan it, it should have at least semi-acceptable performance 19:45:44 brb fone 19:45:48 But unless you're fetching more than 1024 bytes of data, performance isn't going to be really good. :) 19:46:08 kc5tja: well, you don't really fetch it...............:) 19:46:13 * kc5tja also wants to explore logged filesystems too. 19:46:18 well, you do, but you dont .... its one of those 19:46:32 logged? a CVS based fs? 19:46:32 lol 19:46:34 Yeah. You have to read 1024 bytes just to access a 64-byte sub-chunk of it. :) 19:46:38 No. 19:46:49 kc5tja: thats called buffering. almost every OS does that. 19:46:54 A logged filesystem is a filesystem that journals not only meta-data updates, but also the very data itself. 19:47:04 a.k.a. CVS 19:47:08 arke: Yes, and that's why small-file performance on nearly any OS sucks eggs. :) 19:47:08 =P 19:47:21 arke: no, CVS doesn't qualify as a filesystem, I'm sorry. 19:47:28 I believe I made that patently clear already. 19:47:31 CVS _based_ FS :) 19:47:35 Ummm 19:47:36 no. 19:47:36 :) 19:47:39 yes 19:47:40 There's no versioning. 19:47:46 lol 19:47:57 And there is little to no "concurrency" in the same sense as CVS. 19:48:17 how fast can computers today read a 1kb chunk of stuff from HD into RAM? 19:48:22 i think quite fast. 19:48:56 --- quit: I440r ("brb") 19:49:08 If it's streaming, sure. 19:49:17 Seek times are still measured in milliseconds though. 19:49:39 This is why modern systems use extents (whole spans of blocks) instead of individual blocks. 19:50:45 ok 19:50:46 hrm 19:50:55 * arke likes his fs ... its very simplistic 19:51:05 Well, I'm not saying it won't work. :) 19:51:14 it will work, i know it will. 19:51:20 it just might not be the fastest 19:51:38 but it will work just fine with low capacity things 19:52:07 Well, it'd be ideal for floppies -- they have such slow access times that the overhead for super-small files is easily dwarfed by seek times. 19:52:26 The CPU can be busy pulling data from one block while the drive is fetching the next data, and still have time left over to dispatch to another task in the OS. 19:52:38 :) 19:52:59 x86 RkF Forth model: 19:53:05 - Inline STC 19:53:33 - Hardware stack used as Return Stack (eliminates pretty much all software call overhead) 19:53:41 - EBP used as Data Stack 19:53:48 - EBX is Top of Data Stack 19:54:42 - ********** EDI points to output buffer ************** 19:54:53 - *********** ESI points to input buffer ************* 19:55:24 - ECX is Top of Loop Stack 19:55:32 Dang it... I'm getting really hungry. 19:55:33 - EDX is Loop Stack 19:55:37 EAX is scratch 19:55:40 And I don't have a car. >:/ 19:55:41 what do you think? 19:55:52 aww, poor little samuel =P 19:55:53 EDX is loop stack pointer I assume. 19:55:59 yep 19:56:01 arke: I could ride my bike, but it's dark out. 19:56:04 And that means unsafe. 19:56:07 :) 19:56:14 so what do you think about my reg assignemtns? 19:56:21 They seem decent enough. 19:56:34 As long as you use RISC-level instructions, performance should be good. 19:57:04 i read that as "no 'loop' or repXX" 19:57:17 EDI and ESI are brilliant, IMHO 19:57:22 and so is the loop stack :) 19:57:53 and it would be nice to have some more regs 19:58:56 Yep. 19:59:01 x86 is really register starved. 19:59:04 come on, tell me some things you like alot, and you dont like too much, and advice, and things you swould change! 19:59:10 s/swould/would 19:59:11 Though the 64-bit AMD Athlons are finally addressing that problem. :) 19:59:26 EEX, EFX, EGX, EHX?????? finally ... lol 20:00:00 i value your opinion alot, you know that? 20:00:08 Actually, no. 20:00:21 EAX => QAX in 64-bit mode, with IA-32 register naming conventions. 20:00:26 EBX => QBX, etc. 20:00:29 But, 20:01:17 QAX = QR0, QCX = QR1, QDX = QR2, QBX = QR3, QSP = QR4, QBP = QR5, QSI = QR6, QDI = QR7, then, QR8, QR9, QR10, QR11, QR12, QR13, QR14, and QR15. 20:01:47 oh, so they're finally going for _numbered_ registers :) 20:01:52 Yes. 20:01:58 And good riddence. 20:02:00 Welcome to the world of DEC PDP-11! 20:02:08 is intel following along with that? 20:02:16 since they've got their IA64 20:02:19 oh my god 20:02:25 arke: Intel is prepared to if necessary, but they're currently placing all their hopes on IA64. 20:02:38 i looked at the kernel IA64 source ..........holy F***, it looks just like C! 20:02:53 intel needs to die 20:02:57 same with microsoft 20:03:01 ASau: 16 registers is all anyone ever needs, really. ARM is a RISC processor taht can hold its own against any PowerPC, yet it only has 16 registers. 20:03:08 theyve been flooding teh market with shitty ... well, shit 20:03:25 arke: You were looking at something that wasn't assembly language then. 20:03:41 IA64 assembly looks like PA-RISC assembly language (because EPIC is based on PA-RISC). 20:03:44 arke: Digital Equipment foreva! 20:04:31 * kc5tja notes the Motorola 68000 series is the best CISC line *ever* made on Earth. Holy hot tomalies. Based on the PDP-series of CPUs, it blows the doors off the PDP or Intel CISC architectures any day. 20:04:33 Now we need post-increment and pre-decrement addressing. :) 20:04:36 Too bad it's so heavily microcode dependent. 20:05:06 wtf is microcode? 20:05:40 The CPU fetches opcodes from memory, then uses a hardware interpreter (with its own opcodes, called microcodes) to decode and interpret the machine language instruction. 20:06:09 No doubt it looks like C, arke, C is PDP-11. 20:06:10 wierd 20:06:17 why is it 20:06:21 Literally, it is a whole microprocessor with a small amount of embedded RAM (the CPU "registers" you use in assembly language programming, plus the occasional temporary register). 20:06:27 mov out1=sp 20:06:29 thats ugly 20:06:39 Nahh, you're just not used to it. 20:07:08 And frankly, the 'mov' is redundant. 20:07:15 just my thoughts 20:07:18 IIRC, some CPU's could be reprogrammed through microcode. 20:07:29 When, in a 3-operand machine like ARM or PowerPC, you write: add r0,r1,r2, why not just say r0 := r1 + r2 instead? 20:07:44 ASau: Yep. PERQ-series computers are like that. 20:07:47 that would be neat 20:07:50 lol 20:07:54 And, to a limited extent, so can Intel CPUs. 20:08:05 That's how they "fixed" the Pentium division bug and f00f bug, IIRC. 20:08:13 i could make a C-based x86 assembler :) 20:08:18 include #define's etc. 20:08:21 --- quit: TreyB () 20:08:31 arke: It's already been done before, and it wasn't terribly well received. 20:08:36 lol 20:08:39 i can imagine :) 20:08:49 Besides, were it not for the single-stack architecture, C would be a fine assembler. 20:08:49 eax = 1; 20:09:11 For x86 it's called "terse", IIRC. You can find this on the net. 20:09:21 Yeah, I couldn't remember the name. 20:09:51 There exists a free analogue, C-- 20:10:11 Though more high level. 20:11:25 BTW, Il'ja Tarasov have done x86 assembly just by coding AX+=BX sort of words. 20:11:34 The statement that PDP-11 was "C" couldn't be more spot on, either. C was, in fact, originally conceived of specifically to serve as a portable assembly language between the PDP-7 and PDP-11 platforms, when porting Unix to a bigger machine. 20:11:49 ASau: You mean in Forth? 20:11:57 Yes, in Forth. 20:12:10 That's a good idea. I never thought of using that syntax before. :) 20:12:54 IIRC, he said he'd got need of asm, one day. 20:13:17 But he didn't want to think. So he simply hardcoded it. 20:13:23 * kc5tja nods 20:13:35 I'll be right back. I need food. :) 20:13:46 (and I need to pick up some shampoo too, now that I think about it...) 20:13:54 * kc5tja is away: I'm busy. 20:14:12 terse is ugly 20:14:52 btw, for the record, my favorite systems level programming language is Oberon. And with that, I'm outta here. :) 20:14:56 arke: Why not: "BX AX +!" ? 20:16:34 :) 20:16:38 neat 20:16:56 a forth-based assembler 20:17:06 AX BX CX + * 20:17:07 Wah! Just pretty idea! 20:17:11 becomes 20:17:20 add bx, cx 20:17:35 mul ax, bx 20:17:37 :) 20:18:33 bx @ ax +! => add ax,[bx] 20:19:10 Hm. There're some difficulties in syntax or translation. 20:19:31 Yeah. 20:19:31 yeah 20:20:10 (C) ASau. 7:47am, 17 Nov 2003 :) 20:20:34 bx ax ! => mov ax,bx 20:20:51 bx @ ax +! => add ax,[bx] 20:21:10 8 bx @+ ax +! => add ax,[bx+8] 20:21:21 i am having some issues following this conversation 20:21:29 -! *! /! etc 20:22:52 No. MUL and (I)DIV has one fixed arguments. 20:23:34 warp: You're free to speak. 20:23:49 yeah i know 20:44:35 wow 20:44:55 teh 6809 is really a perfect Forth CPU 20:52:00 I should go. 20:52:04 Bye! 20:52:06 --- quit: ASau ("Toffee IRC client for DOS v1.0/b535") 20:53:21 :) 20:55:09 --- quit: warp0x00 ("brb") 20:56:19 :) 20:56:20 :) 21:02:02 --- join: proteusguy (~proteusgu@216.27.161.121) joined #forth 21:04:03 --- quit: proteusguy (Client Quit) 21:05:50 --- join: proteusguy (~proteusgu@216.27.161.121) joined #forth 21:06:52 --- join: _proteus (~proteusgu@216.27.161.121) joined #forth 21:08:01 --- quit: proteusguy (Connection reset by peer) 21:08:59 --- nick: _proteus -> proteusguy 21:11:13 im bored 21:11:17 somebody talk to me 21:13:29 --- quit: proteusguy (Connection reset by peer) 21:16:06 --- join: proteusguy (~proteusgu@216.27.161.121) joined #forth 21:23:58 --- quit: proteusguy (Read error: 54 (Connection reset by peer)) 21:31:43 * kc5tja is back (gone 01:17:48) 21:32:18 * kc5tja prefers the 6502 over the 6809, but I agree that the 6809 is a quite nice CPU. 21:35:21 i switched the regs around a little bit, for nicerness 21:35:29 eax=TOS 21:36:35 ebx=lsp 21:36:42 edx=scratch 21:36:44 :) 21:37:04 * kc5tja nods 21:37:11 the only problem i see there, of course, is ! 21:37:13 * kc5tja has EAX as the top of stack cache in his FS/Forth. 21:37:40 but moving forth says that ! is always a problem with TOS 21:37:43 so im not too worried 21:37:54 What is the problem? 21:38:34 EBX 21:38:37 etc. 21:38:49 without TOS, ! can be simply 21:38:51 pop eax 21:38:57 er, scratch that 21:39:10 pop ebx, pop eax, mov [ebx], eax, push eax 21:39:18 with TOS(ebx), its 21:39:35 pop eax, mov [ebx], eax 21:39:49 er, wait, those are wrong lol 21:40:19 but the fact that im using tos AND non-addressable register AND non-hardware data stack 21:40:22 it just adds up 21:41:03 With EBX as TOS, you get this: pop eax; mov [ebx],eax; pop ebx 21:41:14 With EAX as TOS: pop ebx; mov [eax],ebx; pop eax 21:41:33 i thought you cant address eax? 21:41:47 You're working with 32-bit code, not 16-bit, right? 21:42:23 yeah 21:42:26 :) 21:42:29 ok 21:42:53 xchg eax, [ebp] <--- nice :) 21:43:04 * kc5tja nods 21:43:57 makes my swap quite fast 21:44:15 i think i don't even need to inline my stc, since ive got virtually no call overhead 21:45:55 The last time I measured call overhead on an AMD Athlon 800MHz, slot A (yes, it's that old), it came out to be like 3 or 4 cycles per call/ret pair. 21:47:16 o.O 21:47:30 well, i've got no software call overhead 21:48:10 Let me put things into perspective: an 80486 takes 18 to 24 clock cycles per call/ret pair. 21:48:11 :) 21:48:12 since psp isn't esp, i dont have to save and restore anything 21:48:29 ... 21:48:45 its a friggin push ip, pop ip pair 21:48:53 why does it take so long? 21:49:02 oh 21:49:08 pipelining, huh? 21:49:09 Several reasons, but one of the reasons is the need to flush and refill the instruction pipeline. 21:49:21 yeah 21:49:29 Since the modern CPUs have branch prediction logic, it can accurately pre-fetch the second instruction stream most of the time. 21:49:46 Only on a mis-prediction will it ever suck up huge clock cycles. 21:50:08 Still not as good as a RISC or MISC though. 21:50:25 this is what i dont get --- why the hell does branch prediction kick in for unconditional branches? 21:50:42 Consider the following example: 21:50:46 CMP EAX,42 21:50:51 JZ 1$ 21:50:57 JMP FOO_1 21:51:00 1$: JMP FOO_2 21:51:11 Both JMPs are unconditional branches, but only *one* will ever win. 21:51:13 Which one? 21:51:28 that is stupid code 21:51:31 Branch prediction logic helps determine (with, I'd say, 70% accuracy) which one will run. 21:51:37 cmp eax, 42 21:51:42 jz foo_1 21:51:48 I used that as an example. 21:51:48 jmp foo_2 21:51:51 ok 21:51:59 There are other possibilities to consider. 21:52:06 mov eax,[some_vector_somewhere] 21:52:07 call eax 21:52:10 :) 21:52:23 yes, but here, the _conditional_ comes first, which overrides the other ones, and kicks in _normal_ branch prediction 21:53:27 Branch prediction logic simply tries to save time by prefetching the instruction stream it thinks will execute, so that pipeline refill time isn't felt. 21:53:59 Whether it's a jz/jmp or jz/jmp/jmp combination, or a call r32 instruction -- the point is, the branch prediction logic has to make some kind of decision as to what to try to prefetch. 21:54:44 In the event that it's wrong, it can potentially take hundreds of clock cycles to remedy (e.g., memory fetches on modern CPUs takes hundreds of clocks, and it must fetch from RAM to refill the code cache lines). 21:54:55 In the event that it's right, the branch can be done in a few clocks. 21:55:01 Big, big, big difference. :) 21:55:24 why do memory fetches take so forbiddingly long? 21:56:17 Capacitance on the bus. 21:56:43 The interconnects inside the chip are measured in nanometers now-a-days, and so have femptofarads of capacitance. 21:57:02 ??????????????????????????????????????????????????????????????????????????????????????????????????????????????? 21:57:12 rarely have you confused me this much 21:57:15 Meanwhile, the bus interconnects outside the chip have widths plainly visible to the human eye, and are have capacitances measured in nanofarads. 21:57:21 You asked. :) 21:57:38 Suffice it to say that a bus outside the chip fundamentally will be slower than a bus inside the chip. 21:57:52 By up to three orders of magnitude sometimes. 21:58:13 So while the guts of the chip can be running at 2GHz, the outside bus might be working at most at 333MHz. 21:58:34 mov edx. [ebp] 21:58:38 mov [eax], edx 21:58:40 For the sake of doing math in my head without a calculator, I'm going to round up and be generous. 21:58:41 add ebp, 8 21:58:43 mov eax, [ebp-4] 21:58:44 ret 21:58:53 2000MHz/400MHz = 20/4 = 5 21:59:19 optimize that for me, because thats horribly slow pipelining-wise 21:59:32 and also takes up lots of memory 21:59:37 So, in the time it takes the CPU to fetch one word of memory, the CPU has performed 5 cycles worth of instructions, which can amount to as many as 15 to 35 instructions, depending on what's going on at the time. 21:59:53 What do I optimize for, speed or small footprint? 22:00:07 speed 22:00:18 but both would be nice 22:00:24 (this is !, btw) 22:02:53 How many scratch registers do I have to play with? 22:04:07 edx only 22:04:18 mov edx,[ebp] 22:04:19 unless you save them on the stack and restore them 22:04:22 add ebp,8 22:04:33 mov [eax],edx 22:04:51 mov eax,[ebp-4] 22:04:53 ret 22:05:13 if you had an imaginary SX register as scratch, how would you use it? 22:05:29 Let me see... 22:08:29 mov edx,[ebp] : mov esx,[ebp+4] : mov [eax],edx : lea ebp,[ebp+8] : mov eax,esx : ret 22:08:42 So, time-wise, it'd execute like this: 22:08:49 mov edx,[ebp] : mov esx,[ebp+4] 22:08:58 mov [eax],edx : lea ebp,[ebp+8] 22:09:04 mov eax,esx : ret 22:09:16 E.g., it'd take about 6 clock cycles (including the CALL to it, best-case) 22:09:36 what does lea do? lol 22:09:41 * arke has never ever used lea 22:09:42 (4 for the call and ret, plus 3 for the body of the code above; OK, 7 cycles) 22:09:47 Load Effective Address 22:09:53 i know that part 22:09:59 what does it _do_? 22:10:07 It loads the effect address into the register. :) 22:10:12 ........ 22:10:16 lea eax,[ebx+ecx*4] 22:10:19 is the same as 22:10:25 eax := ebx + (ecx * 4) 22:11:06 so, like 22:11:48 mov eax, ecx ; mul 4 ; add eax, ebx 22:11:58 right? 22:12:13 Yes. But in a single clock (usually). 22:12:38 so lea ebp, [ebp+8] is basically ebp+=8? 22:12:41 I could just as easily have said ADD EBP,8, but whatever. Same effect. 22:12:54 no difference, eh? 22:13:04 LEA comes in really handy when you are dealing with 3-operands. 22:13:22 :) 22:13:30 LEA is generally pretty useless otherwise. 22:13:40 Also, unlike ADD, it does NOT set or change the flags. 22:13:41 just one of those intel things... 22:13:58 So sometimes, if you want to add or subtract a constant from something without affecting the flags, LEA is definitely the way to go. 22:14:18 i cant think of a time when i would :) 22:14:58 call some_func_that_sets_or_clears_carry_based_on_something_important 22:15:08 lea esp,[esp+8] ; fix up the stack or whatever. 22:15:18 jc some_label 22:15:20 ...etc... 22:15:53 true 22:16:36 : +! dup @ -rot + swap ! ; 22:16:46 now, im gonna write +! in asm 22:17:15 --- join: Serg_Penguin (~z@212.34.52.140) joined #forth 22:17:34 this might be interesting. 22:17:44 re 22:18:30 re Serg_Penguin 22:18:53 Well, I have to get to bed. I have to bike into work tomorrow again. 22:18:55 --- quit: Zoopee (calvino.freenode.net irc.freenode.net) 22:18:55 --- quit: Herkamire (calvino.freenode.net irc.freenode.net) 22:18:55 --- quit: kc5tja (calvino.freenode.net irc.freenode.net) 22:18:55 --- quit: onetom (calvino.freenode.net irc.freenode.net) 22:18:56 --- quit: ayrnieu (calvino.freenode.net irc.freenode.net) 22:18:56 --- quit: melinda (calvino.freenode.net irc.freenode.net) 22:18:56 --- quit: Robert (calvino.freenode.net irc.freenode.net) 22:18:56 --- quit: arke (calvino.freenode.net irc.freenode.net) 22:18:56 --- quit: ChanServ (calvino.freenode.net irc.freenode.net) 22:18:57 --- quit: Sonarman (calvino.freenode.net irc.freenode.net) 22:18:57 --- quit: oooo (calvino.freenode.net irc.freenode.net) 22:18:57 --- quit: MysticOne (calvino.freenode.net irc.freenode.net) 22:18:57 --- quit: haroldo (calvino.freenode.net irc.freenode.net) 22:18:57 --- quit: ianP (calvino.freenode.net irc.freenode.net) 22:18:57 --- quit: skylan (calvino.freenode.net irc.freenode.net) 22:18:57 --- quit: chandler (calvino.freenode.net irc.freenode.net) 22:18:57 --- quit: mur (calvino.freenode.net irc.freenode.net) 22:21:16 --- join: ChanServ (ChanServ@services.) joined #forth 22:21:16 --- join: Zoopee (alsbergt@zoopee.org) joined #forth 22:21:16 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 22:21:16 --- join: arke (~chris@ca-cmrilo-cuda1-c3b-66.vnnyca.adelphia.net) joined #forth 22:21:16 --- join: ayrnieu (julian@206.61.132.173) joined #forth 22:21:16 --- join: Sonarman (~matt@adsl-64-171-254-156.dsl.snfc21.pacbell.net) joined #forth 22:21:16 --- join: Robert (~snofs@c-255a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 22:21:16 --- join: melinda (melinda@melinda.usercloak.freenode) joined #forth 22:21:16 --- join: haroldo (~haroldo@r200-40-166-152.adsl.anteldata.net.uy) joined #forth 22:21:16 --- join: skylan (sjh@vickesh01-4649.tbaytel.net) joined #forth 22:21:16 --- join: oooo (o@virgo.bombsquad.org) joined #forth 22:21:16 --- join: MysticOne (mysticone@mysticone.usercloak.freenode) joined #forth 22:21:16 --- join: mur (~mur@smtp.uiah.fi) joined #forth 22:21:16 --- join: ianP (ian@inpuj.net) joined #forth 22:21:16 --- join: chandler (~darmok@64-145-60-36.client.dsl.net) joined #forth 22:21:16 --- mode: calvino.freenode.net set +o ChanServ 22:22:11 --- join: onetom (~tom@cab.bio.u-szeged.hu) joined #forth 23:00:03 --- quit: Sonarman ("leaving") 23:13:12 --- quit: Serg_Penguin () 23:26:48 --- quit: Herkamire ("bedtime") 23:34:55 --- join: warp0x00 (~warpzero@dsl.142.mt.onewest.net) joined #forth 23:59:59 --- log: ended forth/03.11.16