00:00:00 --- log: started forth/04.12.09
00:23:33 --- quit: Herkamire ("bed")
00:46:43 --- quit: onetom ("leaving")
01:06:36 --- join: snowrichard (~richard@adsl-64-219-110-102.dsl.lgvwtx.swbell.net) joined #forth
01:06:40 <snowrichard> hello
01:23:13 --- part: snowrichard left #forth
01:30:34 <ASau> Dobry den!
02:33:24 --- join: Baughn (~svein@cloud.brage.info) joined #forth
02:47:25 --- quit: tgunr1 (Excess Flood)
02:49:18 --- join: tgunr (~davec@vsat-148-65-228-91.c012.g4.mrt.starband.net) joined #forth
03:38:18 --- join: saon (1000@c-24-129-90-197.se.client2.attbi.com) joined #forth
04:08:29 <ASau> Guten Tag, saon!
04:10:52 <saon> hello
04:15:19 <ASau> How's forthing?
04:19:59 <saon> good
04:21:58 --- quit: saon ("Leaving")
05:12:08 --- quit: fridge (Remote closed the connection)
05:32:35 --- quit: SDO_ (Read error: 110 (Connection timed out))
06:11:35 --- join: onetom (~tom@cab.bio.u-szeged.hu) joined #forth
06:20:05 --- join: snowrichard (~richard@adsl-64-219-110-102.dsl.lgvwtx.swbell.net) joined #forth
06:23:09 --- quit: snowrichard (Client Quit)
06:39:05 --- join: rob_ert (~purple@c-4d5a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth
06:39:36 <rob_ert> I440r: Bug report (or is this a feature?). isForth is one day ahead of me.
07:45:20 --- join: SDO_ (~chatzilla@chcgil2-ar7-4-34-139-110.chcgil2.dsl-verizon.net) joined #forth
08:13:17 --- quit: SDO_ (Read error: 110 (Connection timed out))
08:20:32 --- quit: rey_ (Remote closed the connection)
08:25:44 --- join: snowrichard (~richard@adsl-64-219-110-102.dsl.lgvwtx.swbell.net) joined #forth
08:25:49 <rob_ert> Hi snowrichard 
08:25:51 <snowrichard> good morning
08:26:07 <snowrichard> http://richardsnow2.is-a-geek.net:8000/richard.ogg.m3u
08:26:26 <snowrichard> icecast server
08:26:30 --- join: rey_ (~ikke@igwesl3.vub.ac.be) joined #forth
08:27:11 * rob_ert tries
08:29:05 <rob_ert> It's working. :)
08:29:12 <snowrichard> cool
08:29:27 <rob_ert> I'm hearing some kind of modern music
08:29:31 <rob_ert> A woman singing
08:29:43 <snowrichard> contemporary christian
08:47:49 --- join: hierarchy (apache@11.198.216.81.dre.siw.siwnet.net) joined #forth
08:50:21 <rob_ert> You rule us, hierarchy 
08:50:24 <rob_ert> You fool us, hierarchy 
08:50:31 <rob_ert> You shoot at us, too!
08:50:35 <rob_ert> You eat for us.
08:51:43 --- quit: hierarchy (Client Quit)
08:52:54 --- join: hierarchy (apache@11.198.216.81.dre.siw.siwnet.net) joined #forth
08:53:15 <rob_ert> But I do all the work,
08:53:35 <hierarchy> :)
08:54:18 <rob_ert> I've written half of an optimizing machineforth -> x86 native code compiler in isForth.
09:04:29 --- quit: snowrichard ("Leaving")
09:24:43 --- quit: hierarchy ("CGI:IRC (EOF)")
09:31:11 --- quit: rob_ert ("leaving")
09:52:12 --- quit: Baughn (Read error: 113 (No route to host))
10:10:54 --- join: Baughn (~svein@cloud.brage.info) joined #forth
10:13:36 --- quit: Raystm2 ("User pushed the X - because it's Xtra, baby")
10:43:44 --- quit: tgunr ("Leaving")
10:50:39 --- join: tgunr (~davec@vsat-148-65-228-91.c012.g4.mrt.starband.net) joined #forth
10:51:16 --- nick: tgunr -> tgunr1
10:59:29 --- join: TheBlueWizard (TheBlueWiz@modem-063.nyc-tc03a.fcc.net) joined #forth
10:59:45 --- join: I440r_ (~mark4@216-110-82-59.gen.twtelecom.net) joined #forth
10:59:56 <TheBlueWizard> hiya I440r_
11:00:10 <I440r_> hi
11:12:54 --- join: hierarchy (apache@11.198.216.81.dre.siw.siwnet.net) joined #forth
11:13:52 <hierarchy> success! mark slicker's VESA colorforth with the loveall floppy code works without a hitch on our school computers! :)
11:15:11 <TheBlueWizard> :)
11:18:30 --- join: ows (~ows@83.132.99.46) joined #forth
11:22:19 --- quit: hierarchy ("CGI:IRC (EOF)")
11:26:48 --- join: SDO_ (~chatzilla@chcgil2-ar7-4-34-139-110.chcgil2.dsl-verizon.net) joined #forth
11:40:40 --- quit: Baughn (Read error: 113 (No route to host))
11:41:02 --- quit: SDO_ ("ChatZilla 0.9.61 [Mozilla rv:1.7.3/20040910]")
11:44:41 --- join: SDO_ (~chatzilla@chcgil2-ar7-4-34-139-110.chcgil2.dsl-verizon.net) joined #forth
11:44:45 --- quit: SDO_ (Client Quit)
11:47:06 <OrngeTide> I440r_, : arm+ arm-popr1 arm-popr2 targetbuf 01010002 , arm-push ;
11:47:34 <OrngeTide> crappy forth code. but you get the idea. popr1 and popr2 can take a value off the stack and load it into a register (r1 or r2 respectively)
11:47:52 <OrngeTide> arm push loads r0 into the stack
11:48:10 <OrngeTide> targetbuf is a memory area that you want to compile to.
11:48:20 <OrngeTide> 0101002 is add r0, r1, r2
11:49:16 <OrngeTide> how's that for a seed to a forth-based cross compiler without using an assembler.
11:53:30 <OrngeTide> you could play games with optimizing I'm sure. i'm not sure how fast you need this code generation to be.
11:54:45 --- quit: Teratogen ("SKYKING, SKYKING, DO NOT ANSWER.")
11:55:49 --- join: Raystm2 (~Ray@adsl-68-95-251-162.dsl.rcsntx.swbell.net) joined #forth
12:09:29 --- quit: fca ("Client exiting")
12:10:11 --- join: fca (~anvil@h229n2fls31o815.telia.com) joined #forth
12:13:45 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth
12:19:44 --- quit: tgunr1 (Remote closed the connection)
12:48:49 --- join: saon (1000@c-24-129-90-197.se.client2.attbi.com) joined #forth
12:50:06 --- join: yes (~purple@c-4d5a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth
12:55:08 --- quit: cmeme (Read error: 54 (Connection reset by peer))
12:55:41 --- quit: raystm22 ("User pushed the X - because it's Xtra, baby")
12:58:22 --- join: raystm22 (~color4th@adsl-68-95-251-162.dsl.rcsntx.swbell.net) joined #forth
12:58:52 --- join: cmeme (~cmeme@216.184.11.2) joined #forth
12:59:09 --- quit: cmeme (Remote closed the connection)
12:59:55 --- join: cmeme (~cmeme@216.184.11.2) joined #forth
13:00:31 <yes> Hi ray
13:00:34 <yes> And welcome back, bot
13:02:56 --- quit: raystm22 (Client Quit)
13:06:57 --- join: raystm22 (~color4th@adsl-68-95-251-162.dsl.rcsntx.swbell.net) joined #forth
13:07:15 <yes> Hi
13:08:15 --- quit: Raystm2 ("User pushed the X - because it's Xtra, baby")
13:08:55 <tathi> yes, hi. :P
13:10:42 * yes sir!
13:10:42 <yes> I'm also the registered owner of "no".
13:10:55 <yes> Which means that "yes" can ghost "no".
13:11:04 <tathi> Yeah, I knew that.
13:11:05 <yes> And "no" can ghost "yes".
13:11:22 <tathi> But I hadn't seen you use "yes" before.
13:11:24 <yes> Wow, you must have a great memory.
13:11:33 <yes> I'm in low-power mode.
13:11:42 <yes> IRC kind of got too much, and I'm slowly recovering. ;)
13:12:08 <tathi> :)
13:12:29 <yes> Got some coding done, though.
13:18:47 --- join: Raystm2 (~Ray@adsl-68-95-251-162.dsl.rcsntx.swbell.net) joined #forth
13:20:48 <tathi> real coding, or homework? ;)
13:21:05 <yes> Christmas vacation!
13:21:30 <tathi> oh, right.
13:21:34 <yes> Perhaps you didn't see what I wrote earlier, but I've been working on an optimizing machineforth->x86 native code compiler in isForth.
13:22:04 <tathi> I bet I440r is really excited about that :)
13:22:09 <tathi> cool though.
13:22:12 <tathi> how's it going?
13:22:46 <yes> Well, this means he'll have to answer questions about isForth internals... so perhaps not THAT happy.
13:22:59 <yes> It compiled its first "dup +" the other day.
13:23:43 <tathi> coming along then...
13:24:22 <tathi> well, I was referring to his dislike of optimizers :)
13:24:51 <yes> Oh.
13:25:08 <yes> Well, "STC is NOT Forth!!" is how I'd describe him to strangers.
13:26:47 <tathi> :) yup.
13:37:48 --- join: SDO_ (~chatzilla@chcgil2-ar7-4-34-139-110.chcgil2.dsl-verizon.net) joined #forth
13:44:32 <warp0x00> forth is pretty cool
13:44:56 <tathi> no...really?
13:46:32 <yes> Lies.
13:48:25 --- quit: raystm22 ("User pushed the X - because it's Xtra, baby")
13:51:45 --- join: raystm22 (~color4th@adsl-68-95-251-162.dsl.rcsntx.swbell.net) joined #forth
14:23:49 --- join: Sonarman (~matt@adsl-67-113-234-212.dsl.snfc21.pacbell.net) joined #forth
14:24:46 <yes> Hi Sonarman 
14:31:40 --- join: rsync (nobody@CPE000c41aac435-CM00111ae4f4cc.cpe.net.cable.rogers.com) joined #forth
14:35:15 --- join: Baughn (~svein@cloud.brage.info) joined #forth
14:40:23 <Sonarman> hey rob
14:41:09 <yes> How's Forth?
14:49:52 --- quit: ASau (Read error: 110 (Connection timed out))
14:58:33 <TheBlueWizard> gotta go...bye!
14:58:58 --- part: TheBlueWizard left #forth
15:22:37 --- quit: Sonarman ("leaving")
15:25:02 --- join: Sonarman (~matt@adsl-67-113-234-212.dsl.snfc21.pacbell.net) joined #forth
15:27:26 <yes> Hi again
15:27:40 <Sonarman> Hi
15:44:31 --- quit: tathi ("leaving")
15:49:54 <yes> What do you think about computer system complexity - necessary abstractions to base future software on, or something that obscures the fact that computers are tools?
15:54:14 <Sonarman> erm, i'm not really the most qualified person to answer, but i think that in some cases they increase the utility and usefulness of the tool, while in other cases they are unnecessary
15:56:23 <yes> Hey, I was asking for opinions, not facts. ;)
15:56:41 <yes> Nobody is too stupid to have an opinion. Except perhaps the really stupid.
16:00:17 <Sonarman> well, there's my opinion, then :)
16:01:46 <yes> Yay.
16:02:11 <yes> I'm trying to figure out how much of it that's needed.
16:04:08 <Sonarman> what kinds of abstractions?
16:06:18 <yes> High-level languages, complex file systems, databases, and so on.
16:07:24 <yes> One example I came to think of - today people set up MySQL when Forth using raw disk blocks would be more than enough.
16:08:21 <yes> Is this a good thing? In a way I can see that it could be good to use general tools for specific problems, but in another way it seems pretty stupid.
16:08:32 --- join: slava (~slava@CPE00096ba44261-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth
16:08:39 <yes> Hi slava 
16:08:56 <slava> hi, yes, err... yes, hi, ...
16:09:00 <slava> no!
16:09:45 * yes ter day
16:14:27 <yes> Either way I think I take it too seriously, but I don't have much to do until I figure out the (an) answer.
16:34:08 <OrngeTide> yes, MySQL has the advantage that once you know how to use it to debug your application, you can use the same techniques for the next application.
16:35:02 <OrngeTide> mysql offers things that might be useful. like the ability to back up. the ability to export as sql and import into a different database (SQLite for example)
16:35:38 <OrngeTide> of course when you choose an abstraction like that someone still has to design and write a way to interface it.
16:36:07 <OrngeTide> i'd rather write code that did something real, instead of the wrappers necessary to talk to mysql.
16:37:22 <crc> hello all
16:37:31 <yes> And even if a program is very powerful - what good does it make if you only use it for a very simple task?
16:37:34 <yes> Hi crc 
16:37:54 <OrngeTide> none.
16:38:11 <OrngeTide> the only reason i use mysql is because it can make debugging my application easier. i can just poke around with some fancy sql queries.
16:38:26 <yes> I'm not against using powerful software when you need to do something complex, and what I'm thinking about is if it's a good idea to use it for simple tasks. It DOES have the advantage that you have to rewrite less code, learn fewer programs, etc.
16:38:42 <OrngeTide> and things like bugzilla and testlink I use at work all the time. but I often find myself writing little scripts to access mysql directly to generate reports or other repetive tasks
16:39:02 <crc> hi yes
16:42:25 * yes <-- Robert, hiding.
16:42:31 <slava> oh hi Robert
16:42:42 <slava> how's your compiler going?
16:42:46 <crc> yes, why  are  you hiding?
16:43:07 <slava> because he's writing a forth compler in C
16:43:35 <crc> hmm
16:44:02 * crc dislikes C most of the tom
16:44:02 <crc> time even
16:46:06 <yes> Haha
16:46:17 <yes> slava, I'm not doing it in C anymore.
16:46:24 <yes> Actually, now I'm using isForth.
16:46:32 <slava> writing a compiler for isForth?
16:46:53 <yes> For and in.
16:46:59 <slava> cool
16:47:06 <slava> isforth is kind of slow :)
16:48:10 <yes> And large.
16:48:28 <slava> large and slow are not correlated
16:48:48 <yes> No, but they can coexist.
16:50:16 <OrngeTide> i'm writing mine in pforth. only cuz i couldn't get gforth to cross compile.
16:50:36 <slava> yes, we'll have a performance bakeoff one day
16:50:58 <yes> Bakeoff?
16:51:02 <slava> benchmarks, etc
16:51:09 <OrngeTide> isforth doesn't like screen's brokeness. nor will it run on my Mac or arm systems. so I don't use it
16:51:23 <yes> slava: Ah
16:51:46 <OrngeTide> forth monster benchmarks http://home.iae.nl/users/mhx/monsterbench.html
16:51:54 --- quit: Raystm2 ("User pushed the X - because it's Xtra, baby")
16:52:18 --- quit: raystm22 ("User pushed the X - because it's Xtra, baby")
16:52:29 <slava> i should port those to factor
16:52:50 <OrngeTide> yea.
16:54:08 <yes> My goal is to base the compiler on something smaller than isForth, which is based on the primtives the optimizer will support. Still haven't decided on the details.
16:56:26 <OrngeTide> isforth isn't small enough?
16:56:39 <yes> It's pretty large.
16:57:08 <slava> it has a big library though with useful stuff
16:57:12 <slava> no use having just dup drop and + :)
16:57:42 <yes> Nope, but I don't think I need everything from isForth.
16:58:32 <yes> And with an optimizer I can simplify a lot of things. isForth has TONS of words to make its DTC code faster and shorter.
16:58:43 <slava> heh
16:59:39 <slava> i wonder what i440r has to say
17:00:41 <slava> yes, what kind of optimizations are you planning?
17:00:55 <yes> Well, I can't blame him. It's DTC only and should be optimized for that
17:01:00 <yes> But things DO get messy
17:01:03 <slava> still its not particularly fast :)
17:01:06 <slava> gforth is very fast dtc
17:01:11 <yes> Could be worse.
17:01:21 <yes> What does gforth do to make it so much faster?
17:01:39 <slava> it doesnt mix data and code AFAIK, and it 'cheats' by inlining asm in some parts of your DTC
17:01:41 <slava> so its not really DTC
17:01:53 <slava> or maybe im wrong
17:01:59 <slava> it has some kind of 'dynamic superinstructions' scheme
17:02:07 <yes> About optimizations: the basic idea is that I cache everything in registers instead of using the data stack.
17:02:18 <slava> so all stack effects are known?
17:02:35 <slava> doesn't the save/restore of registers add overhead to procedure calls?
17:03:42 <yes> Like I've said before, in Forth a lot of functions are used only once or twice and thus inlined with no overhead. I also did some calculations on how much time the register juggling takes.
17:03:47 <yes> I was suprised
17:03:50 <slava> oh right
17:03:58 <slava> you calculate call counts?
17:03:58 <yes> push/pop and mov are both pairable and one-cycle
17:04:19 <yes> Yes (but that isn't implemented)
17:04:29 * slava steals yes's idea
17:04:41 <yes> Hehe.
17:05:02 <slava> i can only store integers and floats in registers unfortunately
17:06:09 <yes> Still haven't figured out the details about the calling conventions.
17:06:17 <slava> something C like presumably?
17:06:40 <yes> Allowing EXECUTE would be more flexible, of course, but also add some extra overhead.
17:07:06 <slava> i only allow execute-like stuff in the interpreter
17:07:19 <yes> Well, I'm thinking about using only registers for passing parameters, and the return stack for saving the current registers on a function call.
17:07:29 <slava> ok
17:07:56 <slava> what if a function has more values than can fit in registers?
17:08:03 <slava> have you thought about your register allocator?
17:08:41 <yes> It's pretty straightforward atm, but I guess you could use some tricks for more optimal allocation with respect to the x86 mess.
17:08:56 <yes> And about running out of registers... just don't let that happen. ;)
17:09:13 <slava> heh
17:09:34 <yes> You have perhaps 5 to 7 registers you can use. Was it the i21 Forth chip that had a 6 element data stack?
17:09:36 --- quit: crc (Excess Flood)
17:09:46 --- join: crc (crc@pool-70-20-162-28.phil.east.verizon.net) joined #forth
17:10:55 <slava> yes, what about words with unknown stack effects?
17:14:12 <OrngeTide> delete those words. they suck
17:14:29 <OrngeTide> you don't need PICK
17:14:42 <OrngeTide> iirc strongforth doesn't have pick
17:17:01 <yes> Right, just stay away from them.
17:17:39 <yes> For example, THEN will make sure that the register caching is the same no matter which way the branch went.
17:17:58 <slava> but what if its not?
17:18:00 <slava> raise an error?
17:18:05 <yes> Right.
17:18:15 <yes> I don't think you need those words anyway.
17:18:38 <slava> what about recursive words?
17:19:49 <yes> Tail recursion? Normal recursion using the return stack is done exactly the same way as other function calls.
17:20:14 <slava> i meant you have to take care the stack effects balance in recursive words
17:20:16 <Sonarman> speaking of strongforth... anyone know what happened to it?
17:21:20 <yes> slava: Ah... Mandatory stack comments (I know, they'll hang me for that) will provide that information in the start of a word definition. So that won't be a problem.
17:21:36 <slava> yes, there is an automatic way to do it
17:22:00 <crc> yes: I wouldn't be able to use your forth then. I don't do stack comments in the source.
17:24:32 <yes> crc: Do you do them at all?
17:24:45 <yes> And why would you use my Forth? You have retro
17:25:02 <yes> slava: Yes, but why complicate matters?
17:25:22 <slava> yes, comments should not have semantic meaning
17:28:10 <crc> yes: in the documentation
17:28:18 <crc> yes: I like trying other forths :)
17:28:26 * crc has even used Factor a bit
17:30:47 <slava> my favorite forths are retro, is and g, in no particular order
17:32:28 <crc> :)
17:32:29 <yes> Ah, sorry for confusing you
17:32:38 <yes> But now I remember what I was going to do.
17:32:57 <yes> Since I use threaded code as an intermediate step, I can calculate the stack effects from there.
17:33:17 <slava> you should read my blog then :)
17:33:27 <slava> i described an algorithm for doing this in the recursive case, and i have code (but its not forth)
17:35:10 <yes> Oh, I don't think it's very hard. You know what the stack looks like when the word is called, so you can just adjust the current caching to that and jump.
17:39:42 <Sonarman> are you going to explicitly state, in the source code, the stack effects of primitive words such as dup?
17:40:19 <yes> Using this method, no.
17:40:32 <slava> you'll execute dup at compile time?
17:41:12 <Sonarman> how are you going to define dup in you rsystem?
17:41:36 <yes> The primitives (such as dup) have known stack effects, and they (actually, just words to compile them, cache registers, etc) will be run cmopile time.
17:42:08 <yes> Here's my current dup (I don't think it'll change much)
17:42:38 <yes> : [dup]  0 vtype treg = if tvreg else 0 vtype then 0 vval vpush ;
17:42:51 <slava> can you explain how it works?
17:43:43 <yes> vtype ( n -- x )  and vval ( n -- x )   return the type (tvreg = virtual register, treg = register, tlit = literal) and the value (register number or the literal) of stack number n, respectively
17:44:11 <yes> vpush ( type val n -- )  pushes a new item to this (compile time only) stack.
17:44:38 <yes> Basically this words simply duplicates a literal, or creates a virtual register from a register (or another virtual register)
17:44:52 <slava> what happend when a literal is duplicated?
17:45:03 <slava> you don't store literals in registers, you jsut compile their address when they're used?
17:45:25 <yes> A virtual register is a register which has been used several times, so each additional copy is read-only.
17:45:42 <slava> ok
17:45:48 <yes> I only store literals in registers when necessary. For example when returning from a word.
17:46:04 <slava> this is how my old JVM compiler worked
17:46:08 <yes> The idea is that  5 +  should compile to  add edx,5  (or whatever register TOS is represented by)
17:46:14 <slava> right
17:46:39 <yes> What does a JVM compiler do?
17:46:47 <slava> generate java vm bytecode
17:47:02 <yes> Does it use registers?
17:47:15 <slava> it has registers and a stack, but the stack is weird
17:47:22 <slava> you pass parameters on the stack, but the method receives them in registers
17:47:30 <slava> so you can't really use the stack in a forth like fashion
17:47:31 <yes> Heh, OK.
17:48:23 <Sonarman> : [dup[
17:48:29 <Sonarman> iioos'
17:48:34 <Sonarman> oopsm ignore those
17:48:39 <yes> Heh
17:55:20 --- quit: crc ("" Time for bed... Goodnight!" type cr bye")
17:56:02 <yes> Mm.. got to love Forth with its numerous, unportable, ways of printing "Hello, world!"
18:02:03 --- quit: Baughn (Read error: 113 (No route to host))
18:03:13 --- join: crc (crc@pool-70-20-230-229.phil.east.verizon.net) joined #forth
18:04:11 <yes> Can't sleep?
18:04:33 <slava> maybe he's sleep-irc'ing?
18:04:39 <slava> ask him tomorrow if he dreamt of talking on irc
18:07:17 <yes> Hehe. :)
18:07:32 * yes thinks about having an addressing stack.
18:08:07 <yes> Would be easy to implement efficiently.
18:08:23 <yes> Just transfering elements from the data stack.
18:09:00 <yes> That way I don't have to waste a register on A when it's not used.
18:09:14 <slava> A is a bad idea IMHO
18:09:22 <yes> Why?
18:09:26 <crc> A can be  *very* useful
18:09:43 * crc doesn't have A in the retroforth core though
18:09:43 <slava> you have to know if each word uses A
18:09:47 <crc> so?
18:09:52 <slava> what if you have a lot of words?
18:09:58 <crc> You *should* know  your code
18:10:06 <slava> of course, but not to the point of one change breaking everything
18:10:17 <yes> slava: If you use a stack this is not a problem.
18:10:29 <slava> but an A stack is just another data stack which doesn't seem useful
18:10:35 <yes> slava: A new "A" register is allocated for you if one is already in use.
18:10:47 <slava> so its not a register
18:10:57 <slava> it has 'scope' being the current word?
18:11:00 <yes> Not from Forth's point of view - no.
18:11:35 <yes> But when compiled it will be assigned a register (or not even that)
18:12:06 <yes> $b8000 >a c! a> drop    or something.
18:12:30 <yes> A bit ugly since you're only doing one operation with it, but you get the idea.
18:12:47 <yes> That would be compiled to   mov [0xb8000],TOS cache
18:22:16 <OrngeTide> weee.. hi
18:23:48 <yes> Weeeee!
18:23:50 <yes> Hi
18:24:08 <arke> weee!
18:24:08 <arke> Hi.
18:24:56 <crc> hi arke
18:24:59 <OrngeTide> eheh
18:25:36 <arke> i like the idea of an A register
18:25:50 <slava> i like the idea of ARKE
18:25:51 <arke> if you have A, you don't need dup swap drop over etc.
18:26:07 <arke> you can define all of them with a@ a! :)
18:26:11 <slava> if you have locals you don't need those either, but locals are not good :)
18:26:13 <arke> same with @ and !
18:26:18 <arke> LOCALS SUCK ASS!
18:26:35 <crc> arke: you still need dup swap etc.
18:26:38 <arke> : swap a! >r a@ r> ; :)
18:26:53 <arke> : dup a! a@ a@ ;
18:26:57 <arke> : drop a! ;
18:27:08 <arke> : @ a! @a ;
18:27:19 <arke> : ! a! !a ;
18:27:21 <slava> and then somebody writes
18:27:25 <slava> >a drop a> ...
18:27:30 <slava> and their code doesn't work
18:27:47 <arke> muahaha!! :)
18:27:50 <yes> Heh
18:27:59 <arke> slava: you're a 100xforther. stfu. :)
18:28:14 <slava> i'm not a forther, biatch!
18:28:39 <yes> : swap  >a >a aswap a> a> ;   <--- wouldn't break a thing! :)
18:28:40 <arke> you're a "factorer", but thats the last thing you do.
18:28:43 <yes> And generates 0 byte of code.
18:28:54 <slava> aswap?
18:29:03 <yes> Well, I admit that's leeching of aswap.
18:29:16 <yes> SWAP but for the A stack.
18:29:20 <yes> (obviously)
18:29:24 <slava> man
18:29:44 <yes> Admit it will be good for strcpy! ;)
18:30:02 <slava> strcpy is not needed with immutable strings
18:30:07 <yes> c@+ aswap c!+ aswap
18:30:11 <yes> Silence.
18:30:58 <arke> silence slava
18:31:02 <OrngeTide> A is specifically there so you can do repetitive actions effeciently like copying memory, without having to have an actual copy memory instruction. or shuffle the stack every step in your loop.
18:31:11 <slava> OrngeTide, that's what a compiler is for
18:31:22 <slava> otherwise you might as well use asm and make full use of all registers not just a
18:31:30 <Sonarman> : strcpy ( src dest u -- ) bounds do c@+ i c! loop drop ;
18:31:45 <Sonarman> where c@+ operates on the TOS, not A
18:31:51 <Sonarman> who needs a stinkin' A?
18:31:55 <I440r> slava EXACTLY!!!!!
18:31:59 <yes> Sonarman: Tss...
18:32:01 <slava> hi I440r 
18:32:01 <yes> Hey I440r 
18:32:02 <I440r> the a register is a redundancy
18:32:05 <yes> I440r: Did you get my bug report?
18:32:13 <I440r> code it and make USE of the processor
18:32:15 <I440r> yes... no
18:32:16 <I440r> lol
18:32:21 <yes> Hehe.
18:32:22 <OrngeTide> slava, machineforth is designed to be optimal without having to resort to the time wasting task of implementing a good optimizing compiler
18:32:28 <I440r> what bug report ?
18:32:29 <yes> I440r: isForth is one day ahead!
18:32:38 <I440r> one day ahead of what ?
18:32:39 <slava> OrngeTide, machineforth is optimal on a forth cpu
18:32:40 <yes>  List 498470 Head 484295 Depth    0 Base 10 Fri, 11 Dec 2004 03:31:51 +0100    
18:32:45 <I440r> oh
18:32:46 <I440r> i know
18:32:46 <OrngeTide> machineforth also makes a good intermediate for your compiler...
18:32:49 <slava> yes, its futuristic
18:32:52 <I440r> thats because im doing it wrong
18:32:57 <slava> OrngeTide, how so? intermedaite from what?
18:33:03 <arke> I440r: ...you're missing a 1-? :)
18:33:03 <OrngeTide> slava, it's fairly optimal on x86 and arm.
18:33:05 <slava> I440r, isforth is so fast it runs one day ahead
18:33:12 <slava> OrngeTide, not as optimal as, say, gcc or sbcl
18:33:19 <arke> etroforth is faster :)
18:33:20 <I440r> i have to fix some code i was working on. once i got that fixed the plan is to figure out how to interpret tzfiles
18:33:28 <I440r> and calculate the current time zone offset from gmt
18:33:40 <I440r> however. not everyone has the system clock at gmt
18:33:46 <I440r> so i have to account for that too
18:34:06 <yes> Fri, 11 Dec 2004 03:33:33 +0100 
18:34:08 <OrngeTide> slava, well you know how c/c++/fortran/etc compilers have front-end and back-end. the backend reads in an architecture indepedent instruction set and converts it to the architecture. machineforth would suite this purpose as well.
18:34:08 <yes> xD
18:34:09 <I440r> its a bit complex and im not sure if i can do it
18:34:14 <arke> OR, yo could just not have an ugly fflash screeen ^_^
18:34:22 <I440r> needs some discovery 
18:34:27 <slava> OrngeTide, a backend IR needs to represent dataflow in some way, which forth doesn't
18:34:31 <OrngeTide> I440r, did you see my arm code gen example?
18:34:43 <I440r> OrngeTide, no ive been at work heh
18:34:53 <I440r> im about to start laying down the ground work for an arm forth
18:35:02 <slava> you got some arm hardware?
18:35:03 <yes> Cool :)
18:35:11 <I440r> im thinking of doing it all in thumb mode
18:35:14 <OrngeTide> slava, c-- isn't that sophesticated and it works
18:35:21 <I440r> and keeping the forth itself in the flash rom
18:35:21 <slava> what is c--?
18:35:27 <I440r> and compiling TO flash too
18:35:35 <OrngeTide> slava, one of those intermediates
18:35:54 <OrngeTide> it's neat because it looks like C but you can actually implement real tail recursion on it. it's closer to asm than it is to c.
18:36:12 <OrngeTide> gcc uses it's own thing, because stallman doesn't want people writing propritary backends.
18:36:32 <OrngeTide> I440r, sounds like fun. i'm doing a mix of arm and thumb.
18:36:43 <slava> gcc uses a 3-opearnd register machine i believe
18:36:54 <OrngeTide> I440r, anyways. i pasted a bit of pseudo-forth to show how my cross-dev forth works.
18:37:25 <OrngeTide> gcc is mediocre at optimization too
18:37:36 <OrngeTide> it generates some really funny code for x86_64
18:37:36 <slava> mediocre?
18:37:41 --- join: raystm22 (~color4th@adsl-68-95-251-162.dsl.rcsntx.swbell.net) joined #forth
18:37:50 <slava> it generates pretty fast code
18:38:35 <OrngeTide> medicore
18:38:53 <slava> what generates better code?
18:39:07 <slava> that's open source
18:39:08 <I440r> msvc does
18:39:12 <slava> *cough* :)
18:39:13 <OrngeTide> oh. that's open source... nothing
18:39:29 <OrngeTide> gcc is fantastic considering you didn't have to pay anything for it.
18:39:54 <yes> How much faster are other C compilers?
18:40:05 <OrngeTide> the full version of msvc produces significantly better code than gcc does for x86. the free version of course is crippled.
18:40:27 --- join: Raystm2 (~Ray@adsl-68-95-251-162.dsl.rcsntx.swbell.net) joined #forth
18:40:40 <OrngeTide> codewarrior is really fast at compiling. and generates better code for ppc and mips than gcc does.
18:40:48 <slava> who cares about ppc and mips :)
18:40:53 <OrngeTide> i do.
18:41:09 <OrngeTide> i mainly devel for arm, ppc and mips
18:41:14 <OrngeTide> and x86_64. :P
18:41:52 <yes> Cheater.
18:42:01 <slava> gcc's x86 backend is better than all the others
18:42:07 <slava> maybe apple is making the ppc one better these days
18:42:11 <OrngeTide> i work in storage and 64-bit architectures are where it's at. and the whole arm thing is because I have a gumstix and I440r is getting me interested in writing something from my gameboy advance.
18:42:35 <OrngeTide> slava, apple needs to improve gcc's ppc a lot still. :(
18:43:09 <slava> apple has a vested interest in selling faster cpus :)
18:43:21 <OrngeTide> icc and codewarrior both produce better x86. mipspro produces wildly better mips code than gcc
18:43:35 <OrngeTide> but honestly we're talking about a 2% to 0.1% difference in performance.
18:43:39 <slava> indeed
18:43:44 <slava> so it doesn't matter
18:43:54 <slava> but i do notice gcc has a very wide lead over any OSS forth though :)
18:44:06 <OrngeTide> gcc is mediocre because it's basically producing code that is 1% slower than the best thing out there. i have a logrithmic gradient.
18:44:17 <OrngeTide> or would that be exponential. i dunno
18:44:25 <slava> icc has auto-vectorization etc which is cool
18:44:34 <OrngeTide> it's that last 1% that takes most of the work
18:44:57 <yes> So a true forther ignores it, right?
18:44:58 <OrngeTide> slava, yea. i wish it was possible for icc to get merged into gcc :P
18:45:17 <OrngeTide> yes, it's cheaper to buy a 1% faster cpu than do extra work. :P
18:45:32 * yes dreams about an x25 cluster for christmas
18:45:53 <slava> what does chuck moore do these days?
18:45:58 <slava> did itv ever materialize?
18:46:07 <OrngeTide> yay. gcc successfully canadian-cross compiled. I've gotta go install it now. ttyl.
18:46:12 <yes> Perhaps he's being Santa Claus in some mall.
18:46:21 <OrngeTide> slava, chuck is doing some 2500MIPS forth chip.
18:46:28 <OrngeTide> slava, and fighting two patent law suits
18:46:40 <slava> will it be crippled by something like 19 bit word size, a 3 element deep stack, etc? :)
18:46:44 <OrngeTide> (his stuff must be good if people are suing him)
18:46:45 <yes> OrngeTide: 25*25000 :)
18:47:05 <yes> slava: I think it's deeper now, 18 elements or something.
18:47:17 <OrngeTide> slava, more than likely it will make a great dsp. but a sucky general purpose chip.
18:47:22 <yes> But the word size... let's not talk about that. ;)
18:47:33 <slava> why doesn't he use 32 bit?
18:47:38 <OrngeTide> why should he?
18:47:50 <slava> because its a power of two
18:47:58 <yes> OrngeTide: With 60G instructions per second... they don't have to be ultra-efficient. :)
18:48:50 <OrngeTide> slava, but that's arbitrary
18:49:07 <OrngeTide> it takes 5 bits to represent 0-31. why don't you use 16-bit or 256-bit instead?
18:49:25 <slava> doesn't it simplify some algorithms?
18:49:26 <OrngeTide> then you can have 8-bits to represent 0-255.
18:49:28 <OrngeTide> no.
18:49:46 <slava> a larger word size in general is better because you don't need bignums as much
18:49:51 <slava> maybe power of two is not important :)
18:50:01 <OrngeTide> it's just that character encodings are 8-bit now, so having a multiple of 8 is helpful.
18:50:12 <slava> don't you mean 16 bit?
18:50:17 <OrngeTide> PICs and things can have 12,14 or 16 bit.
18:50:33 <OrngeTide> no. 8-bit
18:50:40 <slava> unicode is 16 bit
18:50:42 <OrngeTide> good character encoding takes almost 32-bits.
18:50:47 <OrngeTide> unicode is 32-bit
18:50:54 <slava> well, a useful subset is 16 bit
18:50:59 <slava> full unicode is 21 bit (yay for chuck)
18:51:07 <OrngeTide> then there are 16-bit and 8-bit methods to address the 32-bits.
18:51:22 <OrngeTide> utf8 is better than ucs2
18:51:29 <slava> its more complicated
18:51:29 <OrngeTide> although i use all ucs4 internally.
18:51:40 <OrngeTide> they are equally complicated.
18:51:45 <yes> Yay for multiple standards.
18:51:49 <OrngeTide> takes the same number of lines of C code to decode.
18:51:53 <slava> well, if your ucs2 handles the case of chars above the 16 bit range
18:51:59 <OrngeTide> of course it does.
18:52:00 <yes> 9/11 was revenge for ASCII I bet
18:52:25 <OrngeTide> you can no bother to handle chars above 128, then utf8 is easy. :P
18:52:30 <slava> hah
18:53:39 <OrngeTide> utf8 works better as a null terminated string than ucs2 does. and it can detect and recover from corrupted code sequences. which ucs2 doesnt
18:53:49 <slava> null terminated strings are an abberation
18:54:22 <OrngeTide> also utf8 is typically smaller for encoding western european text. and typically the same size for most asian text.
18:54:42 <slava> yes but operations like nth-char become O(n)
18:54:53 <slava> so you have to code in a more complicated 'iterator' style
18:55:18 <OrngeTide> slava, yea. keeping track of the length in a program is better. but then you have to use 32-bit lengths since it's easy for a string to go over 65536
18:55:22 <yes> Heh. The word "yes" is highlighted.
18:55:30 <slava> sure, nothing wrong with 32-bit lengths
18:55:36 <OrngeTide> yea. nth-char isn't O(n) in ucs16 if you use it properly.
18:55:42 <OrngeTide> the trick is. avoid nth-char
18:55:52 <OrngeTide> YES
18:55:54 <OrngeTide> :)
18:56:00 <yes> Don't abuse this. ;)
18:56:04 <slava> yes, you can code with an iterator style
18:56:10 <slava> -vs- taking indices of strings
18:56:12 <OrngeTide> anyways. yes, I really have to go.
18:56:13 --- nick: yes -> rob_ert
18:56:17 <slava> it basically makes your strings look like likned lists
18:56:44 <OrngeTide> that's how my text editor works.
18:56:51 * OrngeTide disappears!
18:57:07 <rob_ert> Hmm.. that's something I've been thinking about.
18:57:17 <arke> hi robtrob
18:57:17 <rob_ert> What's a good way to store text internally in a text editor?
18:57:21 <arke> what happened to your name?
18:57:27 <rob_ert> What do you mean?
18:57:29 <crc> as an array of characters :)
18:57:31 <slava> rob_ert, there's tons of ways
18:57:39 <rob_ert> crc: I do that for small files.
18:57:40 <slava> crc, a gap buffer is better since consecutive insertions become O(1)
18:57:51 <rob_ert> What's a gap buffer?
18:58:17 <slava> i can either tell you to google, or point you to java code.
18:58:26 <slava> you prefer #1?
18:58:53 <rob_ert> Yes
18:58:55 <rob_ert> :)
18:58:57 <crc> slava: an array of characters is pretty simple to implement and is fast enough for small <1MB files
18:59:08 <slava> crc, its not fast to shift all text upward for every keystroke...
18:59:09 <rob_ert> crc: Depends on the CPU
18:59:19 <crc> 386 and above :)
18:59:24 <rob_ert> Not really.
18:59:27 <slava> crc, think about 'replace all' and stuff
18:59:36 <slava> if there's a million occurrences in a 30mb file, you don't want to shift it each time
18:59:46 <crc> slava: for *small* files
18:59:59 <slava> sure, but if its fast for large files it will be fast for small files too
19:00:03 <crc> If I was editing a 30MB file, I'd use a different method
19:00:21 <rob_ert> I tried that on my 386
19:00:28 <slava> you have a 386?
19:00:29 * slava is impressed
19:00:30 * crc does
19:00:38 <crc> I have an original IBM PC too
19:00:49 <slava> cool
19:00:50 <crc> (Runs a 16-bit version of RetroForth) :)
19:00:55 <slava> one exists?
19:00:57 <slava> how big is it?
19:00:59 <crc> Yes
19:01:04 <arke> rob_ert: what happened to Robert?
19:01:14 <slava> arke, he swallowed an underscore
19:01:18 <crc> ~3k right now
19:01:22 <arke> slava: grr
19:01:29 <rob_ert> You know that rob_ert is my first nick, right?
19:01:40 <rob_ert> Then I made the ircops steal "Robert" from some other guy and give it to me.
19:01:54 <slava> arke, grr
19:02:09 <rob_ert> crc: Neat
19:02:18 <rob_ert> crc: Native or using DOS?
19:02:23 <crc> Native
19:02:42 <rob_ert> I was using my TForth on the 286 laptop.
19:02:48 <crc> With all of 64k RAM in that box, I can't run DOS
19:02:52 <rob_ert> Probably I scared half my class away from Forth.
19:02:55 <slava> crc, not even dos 1?
19:02:58 <rob_ert> Uh
19:03:07 <slava> rob_ert, well, modern forths don't differ much from tforth do they? :)
19:03:09 <crc> I don't have DOS 1 to try
19:03:10 <rob_ert> 64kB isn't enough for DOS?
19:03:15 <slava> crc, does it have basic in rom?
19:03:27 <crc> rob_ert: not versions beyond 3.x
19:03:29 <crc> slava: yes
19:03:39 <rob_ert> slava: TForth is per definition modern!
19:03:45 <rob_ert> I run DOS 3.3
19:03:49 <arke> rob_ert: I know, but why aren't you Robert anymore?
19:03:53 <rob_ert> But my laptop has 640kB of memory.
19:04:03 <slava> that's modern
19:04:04 <crc> I have a DOS 2.11 disk, but it's scratched :(
19:04:06 <rob_ert> arke: That Robert is away for a little while.
19:04:11 <rob_ert> crc: Aww.
19:04:15 <slava> rob_ert, you'll never in your life need more, i mean who can fill up 640 blocks of code?
19:04:26 <arke> rob_ert: why?
19:04:46 * crc has ~15MB worth of blocks on this box
19:04:47 <rob_ert> slava: Good question. Software will never get THAT bloated.
19:04:55 <crc> mostly notes, not code though
19:04:59 <rob_ert> arke: Breakdown?
19:05:05 <slava> crc, how do you organize them?
19:05:06 <fca> apples gcc is about on the same level as metrowerks c nowdays, and on the G5 it's better 
19:05:32 <crc> 1190 constant RetroForthDevelopmentJournal
19:05:37 <slava> wow
19:05:44 <slava> how masochistic ;)
19:05:51 <slava> what if you have to add a new block in the middle?
19:05:52 <crc> 2478 constant WaysToImplementIF/THEN
19:06:17 <crc> I don't
19:06:26 <fca> there's just two major drawbacks with apples gcc, it's slow and it don't support sane inline assembly (but that applies to gcc in general)
19:06:31 <crc> I move the blocks elsewhere, and delete the original ones
19:06:41 <slava> crc, but then you have to update constants
19:06:44 <slava> why not jsut use a file system?
19:07:04 <crc> I have a few blocks with the constants. It's a couple keystrokes to restart Forth and recompile with new constants
19:07:04 <slava> what advantage does this offer over WaysToImplementIF/THEN.txt?
19:07:19 <crc> No complexity in *implementing* the filesystems
19:07:26 <slava> its not that complex to implement a simple fs
19:07:42 <slava> here you implement it in your head, and a cpu is better than your head for doing such bookkeeping
19:07:51 <slava> you might as well use pen and paper, then no code is involved
19:08:01 <crc> :)
19:08:17 <slava> i use pen and paper for notes
19:08:22 <crc> Normally I don't start writing anything new before I finish what I'm working on
19:08:25 <crc> slava: me too
19:08:38 <slava> if i write them on my computer, i'll lose them too, except then they fill up the hd
19:08:55 <crc> When coding though, I'll set up a few blocks for notes
19:09:28 <slava> you do coding in retroforth/native?
19:09:34 <slava> or even in fbsd you use blocks?
19:09:58 <crc> I do coding in retroforth/native
19:10:04 <slava> how do you transfer the code to fbsd?
19:10:12 <crc> I don't.
19:10:19 <slava> do you consider tcp/ip unnecessary complexity?
19:10:23 <crc> I can rewrite most code from memory
19:10:27 <slava> heh
19:10:36 <crc> tcp/ip is overly complex, but useful for compatibility
19:10:51 <crc> It's the *only* external compatibility interface that I actually need
19:10:58 <rob_ert> Error correction is for people who can't do pattern recognition!
19:11:09 --- quit: raystm22 ("User pushed the X - because it's Xtra, baby")
19:11:25 <crc> If I have tcp/ip, I can communicate with others
19:11:36 <slava> but you can just call them on the phone instead
19:12:12 <crc> Not if I want to share code with them, or if they live in a foreign country
19:12:16 <rob_ert> slava: Phone? Modern crap
19:12:26 <rob_ert> Morse code. :)
19:12:34 <slava> telegraph can transfer forth code
19:12:35 * crc is poor; I can't afford to call overseas
19:12:47 <rob_ert> crc: You can telegraph Forth
19:12:50 <slava> right
19:12:53 <crc> rob_ert: I know that
19:12:57 <rob_ert> Actually, one should develop morse-friendly Forth
19:13:02 <slava> it should only take a few minutes to transfer one block of code
19:13:05 <slava> that's modern
19:13:05 <saon> hey all
19:13:09 <rob_ert> Hi saon 
19:13:12 <crc> Hi saon
19:13:25 <arke> slava: why the fuck are you so hellbent on converting crc to a non-crc way?
19:13:26 * crc will be going to bed very soon...
19:13:35 <crc> arke: I won't change :)
19:13:35 <slava> arke, i'm not
19:13:38 <saon> what's everybody up to?
19:13:50 <rob_ert> saon: Debating, writing, playing.
19:14:03 <crc> saon: taking a break from coding now that the irc client is working
19:14:07 <rob_ert> In the background: reading and listening to Beach Boys
19:14:12 <slava> crc, did futhin add ACTION?
19:14:16 <crc> Yes
19:14:18 <slava> cool
19:14:22 --- join: raystm22 (~color4th@adsl-68-95-251-162.dsl.rcsntx.swbell.net) joined #forth
19:14:28 <crc> I don't have it in my copy yet though
19:15:04 <saon> yay, my minidisc player works as an external hd now :)
19:15:47 <slava> saon, use cassette tape instead, minidisc is unnecessary complexity :)
19:16:10 <crc> no! use a wax cylinder!
19:16:17 <saon> lol
19:16:17 <slava> player piano!
19:16:22 <crc> hmm
19:16:49 <crc> bark and charcoal!
19:16:55 <slava> singing!
19:17:00 <crc> grunting!
19:17:10 <slava> back to the caves!
19:17:20 * slava hunts some meat
19:17:25 <saon> heheh
19:17:40 <rob_ert> Hmmm...
19:17:55 * crc discovers fire
19:17:58 <rob_ert> slava, don't you try.
19:18:12 <slava> rob_ert, hurry up and discover the wheel
19:18:15 * rob_ert has an old matrix printer, casette player and a bunch of keyboards.
19:18:23 <rob_ert> I'm tempted...so very tempted.
19:18:28 <slava> there's an idea for music -- dot matrix printer
19:18:42 <slava> old keyboards are actually nice
19:18:50 <slava> compared to the crappy internet keybaords with 300 buttons and bad tactile feel
19:19:15 <rob_ert> Well, a dot matrix printer eliminates the need for a monitor.
19:19:21 <slava> right
19:19:25 <saon> heh
19:19:27 <slava> an abacus eliminates the need for a cpu
19:19:29 <rob_ert> I have hundreds of meters of paper and an extra color band
19:19:41 <rob_ert> slava: Nah, I wouldn't take it THAT far.
19:23:46 * crc goes to bed. Be back tomorrow :)
19:24:04 <slava> bye crc
19:24:46 <rob_ert> Hrm
19:24:53 <crc> bye slava
19:24:57 <rob_ert> Night
19:25:03 <crc> night rob_ert
19:25:04 <rob_ert> Says the European...
19:25:18 <crc> what european?
19:25:21 * rob_ert
19:25:50 <rob_ert> OK, not the only one in here, but still. When the americans go to bed before I do...
19:25:59 <crc> :)
19:26:03 <crc> goodnight all
19:26:05 <rob_ert> Night anyway
19:30:03 <SDO_> nite
20:56:22 --- quit: ows ("Client Exiting")
21:57:50 --- quit: madgarden (Read error: 104 (Connection reset by peer))
22:01:24 --- join: madgarden (~madgarden@Ottawa-HSE-ppp4082712.sympatico.ca) joined #forth
22:01:45 --- join: fridge (~Jim@CommSecureAustPtyLtd.sb1.optus.net.au) joined #forth
22:36:34 --- quit: Sonarman ("leaving")
22:45:00 --- part: slava left #forth
22:58:00 --- join: madgarden_ (~madgarden@Ottawa-HSE-ppp4082712.sympatico.ca) joined #forth
22:58:00 --- quit: madgarden (Read error: 104 (Connection reset by peer))
23:59:59 --- log: ended forth/04.12.09