00:00:00 --- log: started forth/03.04.20
00:00:01 --- log: started forth/03.04.20
00:00:01 * Speuler thinks about writing a genetic battle program synthesizer
00:19:48 --- quit: tgunr (Remote closed the connection)
00:20:43 --- join: tgunr (~davec@vsat-148-63-143-139.c189.t7.mrt.starband.net) joined #forth
01:17:44 --- quit: bwb ("Later")
03:14:42 --- join: karingo (karingo@114.portland-01-02rs.or.dial-access.att.net) joined #forth
04:01:34 --- quit: karingo ()
04:10:11 --- join: karingo (karingo@132.portland-01-02rs.or.dial-access.att.net) joined #forth
04:42:11 --- quit: tgunr (Read error: 104 (Connection reset by peer))
04:56:59 <njd> what the hell is a war bot Speuler
04:57:03 <njd> other than those lame script kiddie things
07:06:04 --- quit: karingo ()
08:01:29 --- join: sifbot (~sifforth@h0030657bb518.ne.client2.attbi.com) joined #forth
08:01:29 <sifbot> Type sifbot: <forth code here> (or /msg sifbot <forth code here> to play in private)
09:07:57 --- join: monk23 (~mind@193.140.248.25) joined #forth
09:08:06 <monk23> hi !
09:09:04 --- quit: monk23 ("reboot")
09:16:26 --- join: wossname (wossname@HSE-QuebecCity-ppp80706.qc.sympatico.ca) joined #forth
09:28:05 --- join: monk23 (~mind@193.140.248.25) joined #forth
09:54:25 --- join: snowrichard (~cpu2@c66.190.103.147.ts46v-01.mrshll.tx.charter.com) joined #forth
09:58:26 --- quit: snowrichard ("using sirc version 2.211+KSIRC/1.2.4")
10:05:41 --- join: I440r (~nospam@1Cust65.tnt1.bloomington.in.da.uu.net) joined #forth
10:05:41 --- mode: ChanServ set +o I440r
10:34:03 <monk23> byes
10:34:13 --- quit: monk23 ()
10:40:33 --- join: tgunr (~davec@vsat-148-63-143-139.c189.t7.mrt.starband.net) joined #forth
10:55:31 --- quit: tgunr ("signing off, brb")
11:06:15 --- join: tgunr (~user@vsat-148-63-143-139.c189.t7.mrt.starband.net) joined #forth
11:40:01 --- join: MrBean (~NoUser@d77243.upc-d.chello.nl) joined #forth
11:41:14 --- join: kc5tja (~kc5tja@ip68-8-206-137.sd.sd.cox.net) joined #forth
11:41:39 <MrBean> speuler there ?
11:42:07 <MrBean> hm
11:42:16 <MrBean> later...
11:42:19 --- part: MrBean left #forth
11:49:13 --- quit: wossname ("geh IS meh")
12:00:41 --- quit: tgunr (Remote closed the connection)
12:06:06 --- quit: I440r (Connection reset by peer)
12:22:08 --- join: monk23 (~mind@193.140.248.25) joined #forth
12:24:22 --- join: crc (12345678@AC98A687.ipt.aol.com) joined #forth
12:39:45 --- nick: monk23 -> monk23_busy
12:46:33 --- join: deluxe (~deluxe@p50805372.dip.t-dialin.net) joined #forth
12:47:32 <deluxe> elo!
12:48:47 <monk23_busy> hola deluxe !
12:49:24 <deluxe> elo busy! :-)
12:50:26 * deluxe installing 12h a prg...
12:50:30 <deluxe> LOL
12:51:02 <deluxe> or was it 16h?
12:51:05 <monk23_busy> monk23_busy : coding some java stuff
12:51:26 <deluxe> that is?
12:56:19 <deluxe> monk23_busy: the thread pool stuff?
12:56:45 <monk23_busy> no. i passed it. i waste my time with some SNMP Tables stuff
12:58:02 <monk23_busy> i am using a synchronizer object to interact parent and child threads..
13:13:34 <monk23_busy> however my time is up for tonight :(
13:16:34 <deluxe> still in the lab?
13:17:15 <monk23_busy> yep.
13:19:19 <monk23_busy> my time ends at 23:30 . i have 3 mins
13:19:23 --- nick: monk23_busy -> monk23
13:21:07 <deluxe> well then, have a good time...
13:21:10 --- join: mur (murr@baana-62-165-186-221.phnet.fi) joined #forth
13:21:29 <monk23> thanks :)
13:22:20 <deluxe> cu l8ter
13:23:14 <deluxe> (maybe i will have some q's after the next 12h install ;-)
13:27:15 <monk23> byes
13:27:19 --- part: monk23 left #forth
13:27:45 <mur> evenign
13:29:47 <kc5tja> re mur
13:29:59 <mur> have i been online today ?
13:30:09 * mur doest really know..
13:30:30 <mur> hello anyhow :)
13:30:39 * mur has been doing artworks the (beginning) of the day
13:31:10 <mur> i'm quite happy with the results
13:31:18 <kc5tja> Neat.
13:31:21 <kc5tja> What kind of art?
13:31:38 <mur> modern arts
13:31:39 <mur> :)
13:31:52 <mur> i have made new covers to easter egg plastic shells
13:32:05 <mur> using ink, wax colours and sandpaper
13:32:33 <mur> i'll add on them vernissage later but not now - it smells much!
13:32:45 <kc5tja> heh
13:33:01 <kc5tja> Well, it's afternoon here, and I'm hungry.
13:33:10 <kc5tja> And since it's such a nice day out, I'll take my bike instead of my car.
13:34:03 <mur> good
13:35:14 --- join: wossname (wossname@HSE-QuebecCity-ppp80706.qc.sympatico.ca) joined #forth
13:35:35 --- nick: kc5tja -> kc-bike
13:43:51 --- quit: crc ("Leaving...")
14:02:43 <Speuler> njd: that'a a prog combatting other programs, trying to eliminate them by corruption or workspace deprivation
14:03:13 <Speuler> 'morning all
14:03:40 <mur> evening Speuler
14:03:44 <ianni> hi
14:03:58 * Speuler just got up
14:04:33 <Speuler> what do we have today .. hmm . australian time :)
14:05:22 <Robert> Hi :)
14:06:01 <mur> wow, nice http://nogahshell.net/
14:16:14 --- quit: deluxe ("bb")
14:35:55 --- quit: mur ("MURR!")
14:39:35 --- join: deluxe (~deluxe@pD950F4DF.dip.t-dialin.net) joined #forth
14:44:59 --- join: Herkamire (~jason@h0030657bb518.ne.client2.attbi.com) joined #forth
14:50:28 --- quit: deluxe (Read error: 104 (Connection reset by peer))
14:52:03 --- join: deluxe (~deluxe@pD950F4DF.dip.t-dialin.net) joined #forth
15:13:26 --- quit: wossname ("gayming")
15:23:47 --- join: tcn (~r@tc2-login4.megatrondata.com) joined #forth
16:05:37 --- join: MrBean (~NoUser@d77243.upc-d.chello.nl) joined #forth
16:05:47 <MrBean> speuler there ?
16:06:13 <gilbertdeb> hello Mr Bean.
16:06:17 <MrBean> hi
16:06:29 <MrBean> was looking for speuler
16:06:35 <MrBean> seems to be away
16:06:40 <gilbertdeb> sorry to dissapoint you.
16:06:45 <gilbertdeb> but he is semtex and Speuler.
16:06:47 <Robert> Heh. Hi MrBean
16:06:48 <gilbertdeb> same person.
16:06:59 <MrBean> ?
16:07:03 <MrBean> ah
16:07:12 <MrBean> both away i guess
16:07:50 <MrBean> ill talk to him later..
16:07:59 <MrBean> not forth related ;)
16:08:25 <MrBean> k
16:08:27 <MrBean> bye
16:08:43 <gilbertdeb> au revoir.
16:08:49 --- part: MrBean left #forth
16:09:01 <tcn> hey all.. what's up?
16:09:10 <gilbertdeb> wrist braces.
16:09:38 <gilbertdeb> need to keep my wrist attached to my arm.
16:10:47 * Robert wonders what to do.
16:11:11 <gilbertdeb> about what?
16:11:22 <gilbertdeb> Robert: do you know if anyone in #asm* does MIPS?
16:11:24 <tcn> i think you need to quit irc for a while :)
16:11:40 <gilbertdeb> hehehe.
16:11:47 <gilbertdeb> what would I do?
16:11:51 <Robert> gilbertdeb: No idea.
16:12:00 <gilbertdeb> it is mostly from typing evilly long papers.
16:13:45 <gilbertdeb> I need to find me a secretary...
16:13:48 <gilbertdeb> hmmm.
16:15:02 <Robert> Marry someone. Tell him why later
16:15:23 <gilbertdeb> _him_ ?
16:16:55 <Robert> :P
16:16:57 <Robert> Well, her
16:17:01 <Robert> Or whatever,.
16:17:02 <Robert> It.
16:17:10 <Robert> Just get someone to write your papers.
16:17:18 <Robert> And type on IRC for you :)
16:17:30 <gilbertdeb> I'd secretly rather have 4 hers living in different cities or visiting at alternate times :P
16:17:40 <gilbertdeb> but 1 good she will do as well.
16:17:54 <tcn> first he'd have to move to Vermont.. heh
16:18:05 <gilbertdeb> whats in vermont?
16:19:00 <Robert> 4 ladies.
16:19:13 <gilbertdeb> ah no. the legalized same gender marriages.
16:19:34 <gilbertdeb> why it was ever illegal, I'd never no. too many neopuritans here.
16:20:57 <Robert> Bah, if you don't like it - make it illegal.
16:21:13 <gilbertdeb> having 4 wives is a big no no.
16:21:18 <gilbertdeb> again, I do not know why.
16:26:33 --- nick: kc-bike -> kc5tja
16:27:58 <tcn> hey kc
16:28:02 <kc5tja> re
16:28:09 <kc5tja> Awesome bike ride.
16:29:50 <tcn> death defying mountain biking?
16:30:07 <kc5tja> nope
16:30:17 <gilbertdeb> fossil fuel defying mountain biking.
16:30:19 <kc5tja> Death defying road cycling in California.
16:30:35 <tcn> hehe
16:30:50 <kc5tja> Averaged 8.4 MPH, despite the major slowdowns on the up-hill treks.
16:31:16 <tcn> well, I should gone for a ride today but instead I was working on this computer.. and easter supper :)
16:31:37 <gilbertdeb> I am a side walk king. the drivers in miami are happy to run anyone over.
16:31:51 <kc5tja> My family is in New York state, my roommate is having Easter supper at his parents house, leaving me all alone here...
16:31:56 <kc5tja> I'm really enjoying Easter for a change.  :D
16:32:07 <Robert> Heh.
16:32:14 <gilbertdeb> kc5tja: you made everyone dissapear! :O
16:32:17 <tcn> heh.. well i ate mine myself too :)
16:32:18 <kc5tja> It's sunny, it's quiet, it's peaceful, ... and that bike ride was damn sweet.
16:32:35 <Robert> Right, moments like these should be shared with #forth, not family ;)
16:32:54 <Robert> Oh, I had a dream about I440r tonight. I spend way too much time on IRC :)
16:32:55 <tcn> had supper with them yesterday
16:33:07 <tcn> but /they/ didn't have kielbasa
16:33:10 <Robert> Ironically he had a big house at some caribian island.
16:33:33 <tcn> a dream about i400r .. hahahhahahahahahahahahahahahhahahaAHAHAHHAHAHAahhah
16:34:18 <gilbertdeb> <Robert> Marry someone. Tell him why later
16:34:21 <gilbertdeb> hmmm robert?
16:34:23 <gilbertdeb> ;)
16:34:27 <tcn> i know what you mean though.. i've had dreams about mapping (work).. or nethack..
16:36:06 <gilbertdeb> I dreamt I was reading starting forth... the section on create does>
16:36:18 <gilbertdeb> still not sure if I turned the page or not ...
16:36:19 <Robert> :)
16:36:31 <Robert> #forth people seem to have very odd dreams. :)
16:36:47 <gilbertdeb> Robert: I'd say.
16:37:07 <gilbertdeb> the other day, ianni dreamt up forth code in an odd way and made pictures too.
16:38:45 <Robert> Heh.
16:38:49 <Robert> Freaks. :)
16:39:07 <gilbertdeb> sayeth the leader of the conga line ...
16:40:46 --- join: bwb (~bwb@ip68-4-121-108.oc.oc.cox.net) joined #forth
16:41:26 <bwb> ." Happy easter"
16:41:44 <Robert> ." ?
16:41:48 <gilbertdeb> sifbot: .( happy lord vishnu day )
16:41:49 <Robert> Compile-time, duh :P
16:41:50 <sifbot> gilbertdeb: happy lord vishnu day     
16:42:01 <bwb> Robert: I know
16:42:04 --- quit: deluxe (Read error: 60 (Operation timed out))
16:42:05 <Robert> bwb: :)
16:42:20 * Robert pets the bwb 
16:42:24 <Robert> We still love you.
16:42:26 <bwb> ?
16:42:31 * bwb not pet
16:42:31 <Robert> Ah
16:42:33 <Robert> Nevermind.
16:42:35 <Robert> :)
16:45:14 * tcn is away. Automatically set away [SZon]
16:47:00 <tcn> wtf?
16:47:37 <Robert> ?
16:47:56 <tcn> auto-away
16:50:46 <tcn> oh well, i should be going
16:50:54 <tcn> see ya's all
16:50:55 --- quit: tcn ("That's it for today")
17:00:00 <kc5tja> Hmmm
17:00:40 <kc5tja> For my 65816 computer, I think it would be cool to bootstrap the thing from a paper tape.  Just to be wildly anachronistic.  :D
17:00:53 <kc5tja> (obviously using 8-bit codes instead of 5-bit codes)
17:00:53 <gilbertdeb> how would you do that?
17:01:01 <Robert> Heh
17:01:03 <kc5tja> Well, the first thing I'd do is NOT use paper-punch.
17:01:08 <Robert> You're insane. Good. :)
17:01:14 <kc5tja> Instead, I'd use reflective techniques.
17:01:22 <kc5tja> This way, I can print out my boot code on my laser printer.
17:01:31 <gilbertdeb> 1. how are you going to get a papertape reader.
17:01:39 <kc5tja> gilbertdeb: I will make one.
17:01:45 <gilbertdeb> 2. how are you going to get the tape?
17:01:52 <kc5tja> I already explained #2.
17:02:06 <gilbertdeb> reflective techniques?
17:02:09 <gilbertdeb> what does that mean?
17:02:17 <kc5tja> Let me finish, and all will become clear.  :)
17:02:31 <kc5tja> So, I would print out my bootcode to the laser printer.
17:02:42 <kc5tja> THen I'd cut the pages into strips, and tape/splice them together.
17:03:04 <natty_> any channels on this network for general embedded systems/microcontroller/electronics hardware development stuff
17:03:05 <kc5tja> Each strip would consist of nine rows, each row containing either a black dot or not.
17:03:22 <kc5tja> Eight of the rows corresponds to the eight data bus pins.
17:03:29 <gilbertdeb> natty_: you are in one of them. shhhh
17:03:31 <kc5tja> The nineth row contains a "data valid" bit.
17:04:04 <natty_> sweet
17:04:19 <natty_> Anybody familiar with PIC
17:04:25 <kc5tja> To read in the data, the tape reader would maintain an address counter.  I'd push a button to reset the address counter to $00E000.
17:04:34 <natty_> Microchip PIC 16 series devices specifically
17:04:42 <kc5tja> natty_: Not I.  :(  I'd like to be, but I just can justify it right now.
17:05:18 <natty_> Too bad :( I'm working on my Doppler DFer USB computer interface
17:05:32 <natty_> having some hardware interfacing issues...
17:05:33 <kc5tja> Then as the paper is pulled through the reader, it waits for that data valid bit to be asserted, wherein the data on the remaining 8 bits are strobed to the bus.  Since $00E000-$00FFFF will be RAM in this type of system, it'll "load" in the kernel image.
17:05:50 <kc5tja> Oooh, you're doing USB stuff....
17:05:54 <kc5tja> That sounds like fun.
17:06:03 <natty_> yeah but the problem isn't with the USB, that was actually super easy
17:06:10 <kc5tja> How'd you do it?
17:06:23 <kc5tja> Did you implement the USB protocol in software on one of the PIC chips?
17:06:24 <gilbertdeb> natty_: good. you distracted kc5tja from his dream!!
17:06:27 <natty_> I called microchip and said "Hey send me some free USB PICs" and they were like "OK"
17:06:30 <kc5tja> gilbertdeb: No he didn't.
17:06:50 <natty_> You can download the USB firmware from their web site
17:06:57 <kc5tja> Oh, that's a pity.  I was hoping that the PICs would be fast enough to implement the USB protocol purely in software.
17:07:24 <natty_> Well a lot of it IS in software
17:07:26 <kc5tja> I'd really like to use USB for my 65816-based PC for connecting mice and keyboards to.  And other stuff.
17:07:36 <kc5tja> natty_: I mean bit-bashing.
17:07:59 <kc5tja> Most USB-enabled microcontrollers are unable to serve as a USB host controller; only as a USB slave device.
17:08:02 <natty_> Hm I haven't looked into bit-bashing, thankfully I haven't had to :)
17:08:38 <natty_> I suspect that the only special hardware is a USB specific UART, the rest is done in software
17:08:39 <kc5tja> gilbertdeb: Anyway, that's my idea.  It's relatively simple to do, though bulky, and not nearly as fast (or small) as using ROM.
17:09:04 <gilbertdeb> I always wondered... how can one burn ones own rom chip?
17:09:09 <gilbertdeb> and how much would it cost?
17:09:10 <natty_> But the PIC is also only capable of low-speed, which precludes it from being a host or hub
17:09:14 <kc5tja> natty_: Most USB uarts do things like address matching for you, among other things.  
17:09:30 <kc5tja> gilbertdeb: $200 for an EPROM burner made commercially (usually)
17:09:39 <kc5tja> gilbertdeb: blank EPROMs are pretty cheap.
17:09:40 <natty_> Although, hm I guess I don't know, the standard might not prohibit low-speed only hosts & hubs
17:09:42 <gilbertdeb> for the burner?
17:09:47 <gilbertdeb> tell me more..
17:09:47 <kc5tja> gilbertdeb: Then an EPROM eraser usually is around $80 or so.
17:09:49 <gilbertdeb> url?
17:10:00 <natty_> You can burn eproms with most PC motherboards :)
17:10:02 <kc5tja> gilbertdeb: Look around.  Jameco, etc.
17:10:13 <kc5tja> natty_: I'm not talking about home-brew parallel-port burners.
17:10:17 <natty_> I konw
17:10:23 <kc5tja> natty_: Those aren't guaranteed to work with all EPROM types anyway.
17:10:24 <natty_> I wasn't either
17:10:38 <natty_> I was suggesting you erase your BIOS and burn whatever else you want on there :)
17:10:46 <natty_> Kind of hard to boot up after that though
17:10:48 * kc5tja thinks --- No.
17:10:56 <kc5tja> :)
17:11:09 <kc5tja> Besides, that's not EPROM -- that's EEPROM, and more often, Flash ROM.
17:12:11 * kc5tja would rather build one of those parallel port burners for EPROMs.
17:12:27 * kc5tja has seen a few, but I'm not 100% convinced that they'll work in all cases.
17:13:27 --- quit: bwb (Remote closed the connection)
17:15:08 <kc5tja> Here's one on the net that uses the parallel port; loads data into the supporting hardware via serial bit-stream (which is how I'd do it too!), then strobes a bit to program the ROM.
17:15:20 <kc5tja> http://home.quicknet.com.au/andrewm/eprom1/
17:17:13 <Herkamire> my forth is shaping up :)
17:17:26 <Herkamire> I just wrote something that prints out the whole source in color
17:17:36 <Herkamire> it's a far cry from an editor, but it's a start :)
17:18:09 <kc5tja> Herkamire: Are you writing an editor with source code coloring support?
17:18:20 <kc5tja> Herkamire: Or is it a ColorForth?
17:18:25 <Herkamire> colorforth
17:19:28 <Herkamire> and I'm storing the source in a binary format with the dictionary lookups and colors coded in.
17:19:35 <Herkamire> but that format is useless without an editor
17:21:21 <Herkamire> all words in src are 16 bits. 4 for color. for compile, execute and define colors, the other 12 bits are it's offset into the dictionary.
17:22:51 <kc5tja> Are the 12 bits an index into an array of words, or an actual byte-offset into the dictionary space?
17:23:02 <kc5tja> If an offset, that's a really tiny dictionary.  :)
17:23:32 <Herkamire> depends on how you look at it.
17:23:44 <Herkamire> if you keep the 12 bits high, then it's bytes
17:24:07 <Herkamire> (16 byte dictionary intries)
17:24:17 <Herkamire> 12 bits is an index.
17:25:08 <kc5tja> Oh, I see.
17:25:15 <gilbertdeb> kc5tja: is your machine going to display via a television?
17:25:24 <kc5tja> So the dictionary entry, then, holds the real address of the word's definition then?
17:25:40 <kc5tja> gilbertdeb: I'm working very hard to make it display via VGA monitor.
17:25:56 <gilbertdeb> wouldn't it be easier to make it plug into a tv?
17:25:59 <Herkamire> kc5tja: yes, and the text for the word
17:26:15 <kc5tja> I mean, I can definitely make it display via VGA, but I'm looking to get a maximum number of colors using various techniques.
17:26:31 <kc5tja> Herkamire: OK, I see.  So it's indirect threaded then.  
17:26:46 --- quit: njd ()
17:26:51 <Herkamire> kc5tja: I don't think so. I forget what that means again.
17:27:03 <Herkamire> I wrote an assembler, and everything compiles native.
17:27:26 <kc5tja> OK.
17:27:37 <Herkamire> the text is just there for the editor to display, and do name lookups as you type.
17:27:40 <kc5tja> So you store both the source text AND the compiled form in memory then.
17:27:45 * kc5tja nods
17:27:48 <kc5tja> OK, I get it.
17:27:59 <kc5tja> Interesting.
17:28:24 <Herkamire> I'm just using that format for my source file instead of ascii.
17:29:21 * kc5tja was probably going to experiment with his own ColorForth variant someday.  In particular, with ColorForth, I see no reason for a MACROS and FORTH vocabulary split.  Words you want to execute at compile-time just appear as executed tokens, instead of as compiled tokens.  This eliminates the distinction between the two word types.
17:29:25 <Herkamire> my source file has 3 parts: 1) dictionary. 2) source. 3) data
17:29:53 <Herkamire> kc5tja: I don't have a seperate vocabulary.
17:30:20 <Herkamire> I haven't made immediates or anything yet. which is currenly annoying. I haven't decided how I want to deal with it.
17:30:26 <kc5tja> So words like BEGIN and IF in every way the same as normal words then?
17:30:56 <Herkamire> I'm currently putting words like IF in the execute color. (that's what's annoying)
17:31:01 <kc5tja> In my proposed environment, there wouldn't ever be such a thing as an immediate word.
17:31:14 <kc5tja> Ahh, so you're already doing what I was going to experiment with.
17:31:19 <Herkamire> kc5tja: what would you do with IF and the like+
17:31:29 --- join: njd (melons@njd.paradise.net.nz) joined #forth
17:31:30 <kc5tja> Exactly what you've already got.  :)
17:31:34 <njd> hey Speuler
17:31:36 <Herkamire> heh :)
17:31:58 <kc5tja> I already distinguish between "system" and non-system words by case.  Why shouldn't I distinguish them by color, especially if doing so automatically takes care of immediacy for me?
17:32:10 <kc5tja> I discovered I really liked that technique when I was developing FS/Forth's target compiler.
17:32:23 <Herkamire> kc5tja: currently it's bothersome. but I think I'm going to write an editor before I do anything about it. because that might make it a non-problem.
17:32:25 <kc5tja> In the target compiler, Pygmy words that start with \\ are visible as "immediate" words to the target image.
17:32:48 <njd> Speuler ive done everything except for []
17:32:57 <Herkamire> kc5tja: cool.
17:33:12 <kc5tja> I discovered that many compiler words invoke other compiler words; having to POSTPONE or [COMPILE] them is aggrevating for me.
17:33:17 <kc5tja> So, I have things like:
17:33:35 <kc5tja> : \\REPEAT   \\AGAIN \\THEN ;
17:33:49 <Herkamire> kc5tja: I have a naming convention for words that compile something.
17:33:58 <kc5tja> That's when I realized that my punctuation prefix could be considered a "color token," and that's what led me to my current idea.
17:34:38 <kc5tja> Herkamire: As do I; except for words already defined by the ANS standard (no point in avoiding those), all my compiling words end with a comma.
17:34:42 <kc5tja> Including all the assembler words.
17:34:51 <kc5tja> I support "code" words using interpret-mode, like this:
17:35:08 <kc5tja> : +   [ bp sp xchg, bx pop, bp sp xchg, bx ax add, ] ;
17:35:23 <kc5tja> (I use subroutine threading, so this kind of thing works *beautifully* well for me)
17:35:24 <Herkamire> I do want to be able to type if without hitting keys to make sure it's in the execute color. but I haven't how that's going to happen. I could do immediates. or I could have the editor color it execute for you.
17:36:35 * kc5tja nods
17:37:22 <Herkamire> which one is subrutine threading again? that's where your definitions are actual machine code right?
17:37:43 <Fractal> Ya, a bunch of call statements, typically...
17:37:58 <Fractal> Interesting to see somebody still using subroutine threading... I thought that went out of vogue years ago...
17:38:04 <Herkamire> and indirect threaded means your definitions are a bunch of addresses.
17:38:23 <Fractal> Well, a bunch of addresses pointing to address of machine code...
17:38:58 <kc5tja> Fractal: Subroutine threading is an enabling technology for me to "inline" assembly into a normal Forth definition.
17:39:08 <Herkamire> tathi decided that indirect threaded would be a bunch slower on PPC (my platform)
17:39:13 <kc5tja> Fractal: It's also the enabling technology that lets me evolve towards a more intelligent compiler that produces real native code.
17:39:37 <Fractal> Ya, it certainly has it's uses...
17:39:46 <Fractal> its
17:39:59 <Herkamire> yay :) I wanna write an optomizer too. that's another reason why I want to have things execute when they are in the compile color.
17:40:10 <kc5tja> Fractal: Also, subroutine threading is markedly faster of processors like the 6502/65816 and 6800 series, because it eliminates a whole bunch of memory and register operations on these CPUs.  
17:40:26 <Herkamire> it seems very sily to compile a subroutine call for dup which is just one instruction.
17:40:47 <kc5tja> I do that for the time being, but that'll go away quickly.
17:40:57 <kc5tja> The execution performance seems to be on par with Pygmy Forth for my system.
17:41:08 <Herkamire> my convention for a word that compiles something is to start it with a _
17:41:12 <kc5tja> Space overhead is only 33% larger, due to the extra byte being compiled in per word call (the CALL opcode)
17:41:15 <Herkamire> right now I have dup and _dup
17:41:18 <Fractal> kc5tja : How many bytes does it take for a long call on those processors though? 3 bytes?
17:41:31 <Fractal> Ya
17:41:55 <kc5tja> Fractal: 6502 only has 16-bit JSR form, so it takes 3 bytes.  The 65816 has both 3-byte and 4-byte forms (the 4-byte can JSR to anywhere in the 16MB address space)
17:41:58 <Herkamire> kc5tja: it's different on ppc. on ppc there is overhead per definition (not per call in there)
17:42:12 <Fractal> The biggest problem with optimizing forth compilers is that, of course, you can't decompile words very easily... It also makes forth source level debuggers much more difficult to write.
17:42:27 <kc5tja> x86 has overhead in both places.  There's the overhead in invoking the subroutine (the time it takes to invoke the CALL instruction), adn the time it takes to RETurn from it.
17:42:39 <kc5tja> Herkamire: PowerPC also has this overhead.  But it's much, much, much, much, much faster than x86.
17:43:09 <Herkamire> yeah. I think that's why there's so many indirect threaded x86 forths.
17:43:13 <Herkamire> I want it to be native.
17:43:16 <Herkamire>  I really like PPC
17:43:19 <kc5tja> Fractal: That isn't an issue for me.  I have my source, and I do extensive unit-testing anyway.  I don't recall the last time I really needed a debugger for my work.
17:43:27 <Herkamire> PPC also seems like it would be a lot of fun to optomize.
17:43:30 <Herkamire> on
17:43:49 <kc5tja> Herkamire: Actually, direct threading is the "fastest" on x86 platforms.  But with modern processors, branch prediction makes subroutine overhead negligable.
17:44:03 <Herkamire> heh :)
17:44:18 <kc5tja> MOV EAX,[ESI]
17:44:21 <Herkamire> yes. the new PPCs have great branch prediction
17:44:21 <kc5tja> ADD ESI,4
17:44:26 <kc5tja> JMP EAX
17:44:43 <kc5tja> that's direct threaded.
17:44:46 <kc5tja> This is indirect threaded:
17:44:49 <kc5tja> MOV EAX,[ESI]
17:44:54 <kc5tja> ADD ESI,4
17:44:57 <kc5tja> MOV EBX,[EAX]
17:45:02 <kc5tja> JMP EBX
17:45:11 <Herkamire> what's ESI?
17:45:20 <kc5tja> The "source index" register of the x86.
17:45:37 <kc5tja> 80x86 has only 7 general purpose registers (versus 32 in PowerPC).
17:45:39 <Herkamire> that's where the call should return to?
17:45:47 <kc5tja> EAX, EBX, ECX, EDX, ESI, EDI, and EBP.
17:45:59 <kc5tja> ESP is the stack pointer, and that's cooperatively managed by both the software and the hardware.
17:46:10 <kc5tja> In the above code, ESI is the virtual instruction pointer.
17:46:48 <Herkamire> why do you need an virtual instruction pointer in direct threaded.
17:47:00 <kc5tja> To keep track of where you are in the Forth program.
17:47:02 <Herkamire> can't your code just be: CALL CALL CALL CALL
17:47:09 <kc5tja> Herkamire: That's subroutine threading.
17:47:15 <Herkamire> right.
17:47:42 <Herkamire> there's three methods! that's why I'm all confused.
17:47:43 <kc5tja> That actually has higher overhead at run-time than direct threading on Pentium and earlier x86 processors.
17:47:52 <Herkamire> I thought there was just subroutine threaded, and indirect.
17:48:19 <kc5tja> No
17:48:22 <kc5tja> No no no
17:48:31 <Herkamire> that's why I can't keep the terms straight. 
17:48:36 <Herkamire> so how does direct threaded work?
17:48:37 <Fractal> There's a number of different threading techniques...
17:48:37 <kc5tja> Indirect threading was the first, then it was optimized to direct threading, and then subroutine threading, and now, native code compilation.
17:48:51 <Fractal> Direct threading points directly to executable machine code.
17:49:01 <Herkamire> native code, is called subroutine threaded.
17:49:17 <Herkamire> indirect threaded is when your definitions are a series of addresses
17:49:25 <kc5tja> Nope.
17:49:32 <Fractal> Typically it points to a jump or call instruction, which jumps to the CFA
17:49:41 <kc5tja> Indirect **AND** direct threaded is when your code is a series of addresses.  The differences is what those addresses point to.
17:49:49 <Fractal> Herkamire : Yes, that's true, but direct threaded is a series of addresses as well.
17:49:54 <Herkamire> ok.
17:50:06 <Herkamire> tathi explained this to me once.
17:50:10 <Herkamire> see if I have this right.
17:50:23 <Fractal> Herkamire : The advantage of indirect threaded code is that the code field is a simple address.
17:50:43 <Fractal> (This isn't much of an advantage, really, which is why most forths use direct threading)
17:50:50 <Herkamire> one of them (direct?) has those addresses pointing to some code which loops through the definition of the funtion you are branching to.
17:51:13 <kc5tja> Herkamire: You have that in indirect threading too.  It's called DOCOLON usually.
17:51:30 <Herkamire> where is indirect has the address pointing directly to the first address in the definition of tho word you are branching to
17:51:52 * kc5tja grins -- let me try to explain, in PowerPC assembly language.
17:51:59 <Herkamire> :)
17:52:12 <Herkamire> what's the difference between direct and indirect?
17:52:16 <Fractal> Well usually you'll have DOCOLON in direct threading too. It's just a difference between how the NEXT routine handles the code field address of each word, the DOCOLON CFA for instance.
17:52:22 <kc5tja> # INdirect threading; r1->I, r2->W
17:52:31 <kc5tja> _NEXT:
17:52:52 <kc5tja>  ldwu r2,4(r1)
17:53:10 <kc5tja>  mtspr r2,lr
17:53:13 <kc5tja>  blr
17:53:16 <kc5tja>  
17:53:30 <kc5tja> doggone it; that should read DIRECT threading, not INDIRECT threading.
17:53:35 <Herkamire> what's r1 and r2?
17:53:40 <Herkamire> ok
17:53:54 <kc5tja> R1 is the virtual instruction pointer (I), and R2 is the word pointer (W)
17:53:59 <kc5tja>  
17:54:15 <kc5tja> # INDIRECT threading; same registers; r3 -> scratch register
17:54:18 <kc5tja> _NEXT:
17:54:24 <kc5tja>  ldwu r2,4(r1)
17:54:37 <kc5tja>  ldw r3,0(r2)
17:54:45 <kc5tja>  mtspr r3,lr
17:54:46 <kc5tja>  blr
17:54:47 <kc5tja>  
17:54:49 <Herkamire> ok now the code makes sense.
17:55:32 <kc5tja> Now, the "EXIT" word compiles a branch to _NEXT (not a call to _NEXT, but a real unconditional branch).
17:55:39 <kc5tja> Note that my code is NOT optimized for minimum run-time.
17:55:55 <kc5tja> There are tons of pipeline stalls in the above code, which is why it's one of the slowest forms to use on the PowerPC.
17:56:39 --- quit: natty_ (Read error: 60 (Operation timed out))
17:57:19 <kc5tja> Also note that, due to the behavior of how the ldwu instruction operates, the I pseudo-register must point 4 bytes AHEAD of the next Forth instruction to execute; that is, at all times, the I register is pointing AT the word that is CURRENTLY executing, rather than at the _next_ word to execute.
17:57:30 <Herkamire> kc5tja: so, in indirect, the words that you're reading in (from r1) are addresses to what? the dictionary entry?
17:57:40 <kc5tja> Yes.
17:57:55 <Herkamire> oh.
17:57:56 <Herkamire> ok
17:58:01 <kc5tja> The first field of the dictionary entry (offset 0; hence 0(r1)) is usually the code field address for that word.
17:58:04 <Herkamire> that's the difference?
17:58:09 <kc5tja> That's the ONLY difference.
17:58:15 <Herkamire> that's retarded.
17:58:19 * kc5tja laughs
17:58:29 <Herkamire> why would anybody code something like that?
17:58:53 <kc5tja> It has its roots in Chuck's original Forth implementations, for the really old, big-iron machines he used to use.
17:58:53 --- join: natty (~n1ywb@155.42.84.139) joined #forth
17:58:56 <kc5tja> re natty
17:58:58 <Herkamire> I suppose it makes it easy to change the difinitions of words that you've already compiled cals to, but you shouldn't do that.
17:59:10 <Herkamire> kc5tja: ldwu == lwzu right?
17:59:15 <kc5tja> Modern hardware generally doesn't rely on indirect threading except in some limited circumstances.
17:59:41 <kc5tja> Load word and update; I'm only familiar with the PowerPC 601 assembler syntax (yeah, I know; a lot has changed since).
17:59:59 <Herkamire> yep. it's lwzu
18:00:02 <kc5tja> (and yes, that's the last PowerPC I ever programmed in assembly for... :( )
18:00:13 <kc5tja> Everything else since has been for MIPS.
18:00:45 <Herkamire> kc5tja: good memory :)
18:01:09 <kc5tja> I think it's possible to speed things up a bit by doing this:
18:01:20 <kc5tja> ldw r2,4(r1)
18:01:26 <kc5tja> add r1,4,r1
18:01:29 <kc5tja> ..etc...
18:01:40 <kc5tja> But I'm not sure how much it speeds it up by.
18:01:43 <Herkamire> that would slow it down wouldn't it?
18:01:43 <kc5tja> It's been too long.
18:02:06 <kc5tja> Herkamire: Not necessarily.  The ldw after the ldwu represents a read-after-write pipeline stall.
18:02:16 <kc5tja> the add doesn't have that problem.
18:02:34 <kc5tja> So although there are more instructions, it could be a net win performance wise.
18:02:57 --- quit: Fractal (Read error: 104 (Connection reset by peer))
18:02:59 --- join: Fractal (hsnif@new.cure.for.SARS.found.to.be.strongLSD.com) joined #forth
18:03:05 <Herkamire> oh, for indirect. I'm not even thinking about indirect. it seems so useless
18:03:15 <Herkamire> what's the use of having your tokens point to the dictionary?
18:03:23 <Herkamire> it just slows the whole thing down.
18:03:25 <kc5tja> You could use smaller token sizes, for one.
18:03:31 <Herkamire> oh,
18:03:37 <Herkamire> good point
18:03:42 <kc5tja> For example, a byte-code (e.g., Java) could be implemented this way, with 256 entries in the dictionary.
18:03:46 <kc5tja> But yes, it is known to be slow.
18:03:48 <Herkamire> right :)
18:03:59 <kc5tja> Another reason is that it permits relatively easy "patching" of already compiled code.
18:04:02 <Herkamire> that's probably why chuck did it in the first place.
18:04:06 <kc5tja> Perhaps.
18:04:18 <Herkamire> but now that we have rediculous amounts of memory...
18:04:39 <kc5tja> Also, when your *EDITOR* does the compiling (as it does in ColorForth), it can actually make things rather convenient, because then you can just use straight look-up tables to do the compilation with.
18:04:56 <Herkamire> exactly :)
18:05:10 <Herkamire> with my compiled src the interpret loop is a joke
18:05:19 <kc5tja> But I'm a punctuated Forth person for the time being; I need to finish FS/Forth before I explore ColorForth a bit.
18:06:06 <Herkamire> my interpret loop (in asm) is 6 instructions.
18:06:12 <kc5tja> Oh, can I see it?
18:06:18 <kc5tja> Can you post it here?  
18:06:54 <Herkamire>         lhzu r3, 2(source_cur)
18:06:54 <Herkamire>         rlwinm r0, r3, 2, 26, 29
18:06:54 <Herkamire>         clrrwi r3, r3, 4
18:06:54 <Herkamire>         # we pass the dictionary offset to color_* in r3
18:06:54 <Herkamire>         add r0, color_jump_reg, r0
18:06:57 <Herkamire>         mtctr r0
18:06:59 <Herkamire>         bctr # jump into the color_jump table, and have it return to the top of this loop.
18:08:08 <kc5tja> When does this code execute?
18:08:21 <kc5tja> This looks amazingly like the NEXT primitive of (in)direct threaded implementations.
18:08:29 * kc5tja is confused; you said your Forth was native code??
18:08:49 <Herkamire> that's the interpret loop
18:09:09 <kc5tja> Oh, that's what's executed when interactive?
18:09:12 <Herkamire> the jump table at color_jump_reg compiles or executes or whatever. then branches back to the top of the code I just pasted
18:09:32 <Herkamire> kc5tja: yeah, pretty much.
18:09:41 <Herkamire> it isn't really interactive, just the editor is.
18:09:47 * kc5tja nods
18:10:12 <kc5tja> This is the interpretter when loading a block.  :)
18:10:13 --- join: bwb (~bwb@ip68-4-121-108.oc.oc.cox.net) joined #forth
18:10:15 <kc5tja> re bwb
18:10:19 <bwb> re
18:10:31 <kc5tja> It first compiles the block to tokens, then this walks over the token buffer and executes them.
18:10:43 <kc5tja> (I'm guessing)
18:10:46 <Herkamire> but that code reads the source (from source_cur) and calls the function to handle that color
18:10:48 <bwb> what does?
18:11:01 --- quit: natty (Read error: 60 (Operation timed out))
18:11:07 <Herkamire> kc5tja: I store the tokens on disk.
18:11:17 <Herkamire> when I start up my forth it reads in the file.
18:11:41 <Herkamire> I also coded a much more complicated text interpreter (for me to use until I write my editor)
18:11:59 <Herkamire> that code just handles source tokens
18:13:13 --- join: natty (~n1ywb@155.42.84.139) joined #forth
18:13:14 <Herkamire> bwb: http://tunes.org/~nef/logs/forth/03.04.20
18:13:22 <Herkamire> brb
18:30:40 --- part: bwb left #forth
18:35:36 --- quit: Speuler ("memory access violation at addr $80024b2d")
18:44:51 --- join: Fractal_ (popqdyjo@new.cure.for.SARS.found.to.be.strongLSD.com) joined #forth
18:48:48 --- quit: Fractal (Read error: 104 (Connection reset by peer))
18:48:48 --- nick: Fractal_ -> Fractal
18:55:53 <kc5tja> back
18:55:59 <kc5tja> sorry; was on the phone with my parents.
18:57:22 <Herkamire> and I had dinner :)
18:58:50 <kc5tja> heh
18:59:10 <kc5tja> If I work with ColorForth, I would start with the editor first, then work backwards towards the interpretter and compiler.
18:59:52 <Herkamire> that makes sense, except what would you code the editor in?
18:59:56 <kc5tja> Right now, with FS/Forth, I started first with the code to collect a line of input from the user, and had just finished writing the parser for it.  Now the interpretter is a pretty easy piece of code to bridge the two.
19:00:24 <kc5tja> I am not averse to coding in hand-compiled pseudo-Forth for something like that.
19:00:36 <kc5tja> Especially for bootstrapping purposes.
19:01:11 <Herkamire> I was either going to write an encoder or an interpreter
19:02:48 <kc5tja> I must ask, though, do you prefer ColorForth over a more traditional Forth environment?
19:04:04 <Herkamire> I think so. although what I'm doing isn't much different from traditional yet. I'm still using vim
19:04:32 <Herkamire> since I don't have a colofroth editor, I put in symbols to denote the color changes.
19:04:56 <kc5tja> Vaguely similar to my standardized prefixes then.  :)
19:05:12 <Herkamire> I have syntax highlighting to display the words in the right colors, but you still see the color change tokens
19:05:20 * kc5tja nods
19:05:38 <kc5tja> So _ is a standard prefix for "compile this word" in your system?
19:05:55 <kc5tja> That kind of fits in, I guess, since $ is used as a standard prefix for hexadecimal numbers.
19:05:55 <Herkamire> : makes next word define   [ switches to execute color  ] switches to compile color
19:06:16 <kc5tja> Hmm...can you post a simple example?
19:06:19 <Herkamire> kc5tja: I like the idea of using comma
19:07:14 <Herkamire> : |51 [ r_tos r_tos 21 6  10 _rlwinm ] aor [ ;
19:08:00 * kc5tja laughs!  That's *almost* what my FS/Forth code looks like.  To recap, this is actual source code for +:
19:08:11 <Herkamire> my (temporary) text interpreter strips out the : [ ] and [ and colors the words accordingly
19:08:14 <kc5tja> : +   [ bp sp xchg, bx pop, bp sp xchg, bx ax add, ] ;
19:08:15 <kc5tja> :)
19:08:26 <Herkamire> exactly.
19:08:38 <kc5tja> Only mine is in traditional punctuated Forth style.
19:08:45 <kc5tja> (e.g., I support the idea of immediate words)
19:09:13 <Herkamire> my text interpreter just strips out these:  : [ ] '  and encodes the source tokens I described earlier.
19:09:25 * kc5tja nods
19:09:27 <Herkamire> in the future the editor will do the encoding and I won't have those symbols.
19:09:54 <kc5tja> Well, you might still have :.  In Chuck's ColorForth, he has : VARIABLE and CONSTANT I think.
19:09:57 <Herkamire> it's annoying to have to do   [ if ]   and   [ ;
19:10:10 <kc5tja> : makes all future red words define colon-definitions.  VARIABLE makes all future red words define a new variable, etc.
19:10:26 <kc5tja> Yeah, when hacking on plain text, I can see how that would get annoying.
19:10:32 <Herkamire> cool! I didn't think of that
19:11:13 <Herkamire> kc5tja: yep. partly why I haven't done anything about it, is that I won't be hacking in plain text for much longer. I don't want to solve a problem that will iether go away, or I'll see a better solution for soon.
19:11:39 <kc5tja> Well, you can look at it this way: the editor is the solution to your problem.
19:11:56 <Herkamire> yeah. I still want immediates though.
19:12:05 * kc5tja nods
19:12:14 <Herkamire> I want to make the dictionary have to code pointers. one for the immediate definition, and one for runtime.
19:12:40 * kc5tja does that in FS/Forth by having two separate word lists: COMPILER and FORTH.
19:13:07 <kc5tja> The only disadvantage to this solution is that a single word that exists in both wordlists will have two separate dictionary headers compiled.
19:13:15 <Herkamire> for example DUP would have both. one would compile:  addi stack, stack, 4    the other would execute
19:13:51 <Herkamire> kc5tja: my major problem with that is that you cannot override a COMPILER word with a normal one.
19:14:03 <kc5tja> I'm curious: Doesn't the top of stack also need to be stored in memory as well?  Wouldn't it be addi stack,stack,4 followed by (or preceeded by) a stw to actually replicate?
19:14:07 <Herkamire> I haven't decided how I want that solved though.
19:14:21 <Herkamire> kc5tja: I cache TOS in a register
19:14:30 <kc5tja> Herkamire: I have the same problem, since the compiler wordlist is always searched first.
19:14:51 <Herkamire> oh, shit. sorry. it's:    stwu tos, 4(stack)
19:15:03 <kc5tja> Herkamire: That doesn't eliminate the problem.  Indeed, it compounds it; when the TOS is mutilated into something else, it's permanently destroyed UNLESS you back it to RAM when DUP is called/compiled.
19:15:10 <kc5tja> Herkamire: OK, that's better.  :D
19:15:27 <Herkamire> ooopsia
19:15:45 <Herkamire> drop is two instructions though... grrr
19:15:52 * kc5tja nods
19:15:57 <kc5tja> That does tend to get annoying, yes.
19:16:05 <kc5tja> It could be worse though.
19:16:25 <Herkamire> I just wish there was a post-decrement fetch
19:16:41 <kc5tja> In FS/Forth under 16-bit DOS environment, I am *constantly* having to XCHG BP,SP to put the data stack pointer in SP to use PUSH and POP instructions, and XCHGing back when I'm done.
19:17:01 <kc5tja> This is a huge time sink for my Forth.
19:17:18 <kc5tja> But that's OK; I'm concentrating on correctness for the time being; I'll optimize the run-time environment for speed later on.
19:17:22 <Herkamire> what's xchg?
19:17:25 <kc5tja> And, when running in 32-bit mode, all that goes away.
19:17:27 <kc5tja> Exchange
19:17:40 <Herkamire> swaps the registers?
19:17:43 <kc5tja> Yes
19:17:43 <Herkamire> never mind.
19:17:45 <Herkamire> ok
19:18:10 <Herkamire> is that because you can only access memory with a certain register or something?
19:18:18 <kc5tja> Yes
19:18:24 <Herkamire> gotcha.
19:18:40 <Herkamire> I've only done asm on PPC so this stuff all seems very wierd
19:19:00 <kc5tja> In 32-bit mode, the register set becomes much, much more regular.  EBP (the 32-bit version of BP) is useful as any old register, while using BP for addressing and address arithmetic is really slow and tedious.
19:19:31 <Herkamire> I had a hard time believing that x86 doesn't allign instructions.
19:19:45 <kc5tja> You haven't lived until you've done x86 assembly language.  :D  You have no idea of the kind of freedom you have until you work with a non-orthogonal, register-starved, designed-by-committee processor like x86.
19:19:58 <Herkamire> lol
19:20:02 <kc5tja> x86 opcodes are byte-encoded, not word-encoded, and can appear on any address alignment.
19:20:10 <Herkamire> I know.
19:20:17 <kc5tja> Some instructions are 1 byte long; others can be up to 16 bytes long.
19:20:19 <Herkamire> I'm used to getting a segfault for that sort of thing
19:20:39 * kc5tja *adored* the 68000 architecture!  I still do.  I think it's the best CISC architecture processor in existance.
19:20:59 <Herkamire> that's the 16 bit macs right?
19:21:09 <kc5tja> The 68000 is a 32-bit processor.
19:21:19 <kc5tja> It has a 16-bit external data bus, but it is a true 32-bit processor.
19:21:28 <kc5tja> Macintosh, Amiga, and Atari ST all used it.
19:21:32 <Herkamire> tathi says he really likes that.
19:21:40 <kc5tja> And many, many, many, many, many, many, many Unix boxen.
19:21:56 <Herkamire> he wants to make a handheld computer with the old dragonball that still uses 68K
19:22:27 <kc5tja> 16-bit opcodes (must be aligned on 16-bit boundary), 16 semi-general purpose registers (8 data registers, 8 address registers), user/supervisor modes, and an instruction set to die for.
19:22:53 * kc5tja was considering using the 68010 for his homebrew machine, but the 65816 is cheaper and runs almost as fast, clock for clock.
19:23:07 <natty> SHIT
19:23:16 <kc5tja> natty: ?
19:23:22 <natty> my problem is far from what I thought it was (I was reading the PIC spec sheet wrong)
19:23:35 <natty> which is to say that now I don't know what it is
19:23:44 <Herkamire> phone one sec
19:23:46 <kc5tja> Oh, that really sucks.  :(
19:23:46 <natty> time to try and steal a logic analyzer from the lab
19:24:25 <kc5tja> natty: Sometimes, when stuff like that happens, I start over from scratch, adding software and/or hardware modules one by one and testing each thoroughly.
19:24:36 <kc5tja> natty: Not sure if that'll help you in your project...
19:24:48 <kc5tja> It's very expensive to do if you're really far into it.
19:25:41 <natty> that wouldn'
19:25:53 <natty> t really be feasable here. I need to troubleshoot it
19:26:48 <kc5tja> natty: What project are you working on, anyway?  Do you find USB really easy to work with from a developers perspective (this problem not necessarily withstanding)?
19:27:29 <natty> Oh yeah, it's tit. The PIC code especially is easy to use. Writing a device driver for your OS (linux obviously in my case) is the trickiest part
19:27:40 <natty> the hardware is damn simple
19:29:09 <kc5tja> Cool.  I've never done any USB development before, but I'd be interested in learning sometime in the future.
19:29:22 <kc5tja> Especially since I want a USB host controller of some kind in my homebrew box.
19:29:54 <Herkamire> natty: what sort of device are you making?
19:29:54 <natty> heh well I dunno about host controllers, I suspect most people just buy a chipset to do it
19:30:03 <natty> it's a RDF->PC interface
19:30:03 <Herkamire> can you just use the usb/serial driver?
19:30:21 <natty> It's not a driver problem
19:30:45 <natty> the PIC isn't getting consistantly good data from the RDF unit
19:31:09 <Herkamire> kc5tja: yeah 68K processors sound very cool. I haven't programmed for them though.
19:31:10 <kc5tja> natty: No, actually they don't.  The host controllers of today are firmly embedded inside the motherboards of PCs and Macintoshes.  There are, to the best of my knowledge, NO separate host controller ICs for USB.  :(
19:31:28 <kc5tja> Herkamire: On the one hand, very RISC-like, and on the other hand, very CISC.  :D
19:31:47 <kc5tja> movem.l d0-d7/a0-a6,-(a7)  <-- saves all registers on the stack; very CISC
19:32:08 <Herkamire> smokes!
19:32:51 <kc5tja> move.b 45(d0.w,[d2.l,a2]),99(d3.l,[d0.w,a5])  <-- HORRIBLY CISC (actually doesn't exist on 68010 and earlier; 68020 and later only)
19:33:07 <Herkamire> I like the way my colorforth code looks without the symbols
19:33:13 <kc5tja> move.l d0,12(a2) <- extremely RISC. :D
19:33:35 <kc5tja> Fortunately, most 680x0 code is of the simpler variety.
19:33:49 <Herkamire> I think it's wierd to cale a memory store, a load, and a remister copy "MOVE"
19:34:37 <Herkamire> perhaps this is why they don't call it that anymore on ppc
19:34:42 <kc5tja> I don't have much of a problem with it; indeed, most CISC CPUs do it.
19:34:49 <Herkamire> yep.
19:34:52 <Herkamire> I'm just not used to it.
19:34:52 <kc5tja> The exception that I'm aware of being the 6502/65816 series.
19:35:05 <kc5tja> (and the 680x 8-bit Motorola CPUs)
19:35:18 <kc5tja> It's named such because it "moves" data around the system.
19:36:09 <Herkamire> yeah. but it copies it
19:36:19 <kc5tja> Technically, yes.  :)
19:36:29 <kc5tja> Have you read some of Henry Baker's papers on linear logic memory management?
19:36:36 <Herkamire> no
19:36:40 <Herkamire> never heard of it
19:36:43 <kc5tja> The idea is that as you consume data in an operation, it's permanently destroyed.
19:36:58 <kc5tja> For example, 1 2 + yeilds 3 on the data stack; the 1 and 2 are no longer to be found there.
19:36:59 <Herkamire> like forth math
19:37:03 * kc5tja nods
19:37:12 <kc5tja> But the concept can be extended to a lot more.
19:37:36 <kc5tja> If you have a data structure that you'd like to read a field from, for example, reading that field disposes of the whole structure.
19:37:47 <kc5tja> (in concept at least; obviously, that'd be a horribly expensive operation in reality)
19:38:17 <Herkamire> where's he getting all this data that he can be so descructive with?
19:38:17 <kc5tja> Thus, if you want to do something with an object, while still having that object hang around for later use, you must explicitly duplicate it.
19:38:37 <Herkamire> ok, so lots of dups and overs :)
19:38:46 * kc5tja nods
19:38:47 <Herkamire> sounds forth-like
19:39:24 <kc5tja> He created a simple, theoretical virtual machine for one of his LISP compilers to compile to that had a TRUE MOVE instruction.  MOV R1,R2 really DID destroy the contents of R1, for example. :)
19:39:52 <kc5tja> This was done with tag bits in a special register, that recorded whether or not a register contents were valid or not.
19:40:07 <Herkamire> heh
19:40:08 <kc5tja> Pretty interesting stuff, actually.
19:40:44 <Herkamire> I can't imagine what I could use 32 registers for
19:40:58 <kc5tja> C compilers love them.
19:41:11 <Herkamire> yeah, it's great for tha
19:41:13 <kc5tja> It lets them keep a lot of stuff in "level -1 cache" so to speak.
19:41:18 <Herkamire> that's why there are so many I presume
19:41:22 * kc5tja nods
19:41:37 <kc5tja> RISCs are optimized for C and other similar languages (e.g., Pascal and Oberon could easily benefit from them).
19:41:53 <kc5tja> 8 is too small, though, even for some hand-written assembly language software.
19:42:02 * kc5tja finds 16 registers to be a really nice compromise.
19:42:42 <Herkamire> I have stuff sitting around in registers that I almost never use (such as a pointer to the begining of my data section (which I only use to save my bootstrap)
19:43:25 <kc5tja> When I port FS/Forth to Linux, I'm going to really wish I had extra registers.
19:43:30 <kc5tja> Ditto for Win32.
19:43:30 <Herkamire> I plan to write an optomizer, but I don't think that will use more than 4 or 6 registers
19:43:45 <Herkamire> why?
19:43:57 <kc5tja> The dictionary for it could potentially appear at *any* address, so I have to always keep the dictionary pointer in one particular register.
19:44:09 <kc5tja> That leaves me with only 6 registers to use for other things.
19:44:16 <Herkamire> oh right.
19:44:35 <Herkamire> I keep forgetting that you can't use most of the registers.
19:45:36 <kc5tja> Well, in 32-bit I can.
19:45:51 <kc5tja> Only ESP has dedicated usage (ECX does too, but it's a LOT less than in 16-bit mode)
19:47:22 <kc5tja> Here's probably how I'm going to break down the registers: Top of stack (EAX), next top of stack (EBX), loop counter (ECX), Address register (EDX), Data Stack Pointer (ESI), scratch (EDI), Return stack (ESP), data stack (EBP)
19:50:51 <natty> sweet I scored a 4 channel 100MHz HP digital scope :)
19:52:26 <Herkamire> I have 10 registers for scratch and syscalls, and 20 regsers for my forth (tos, stack, rstack, dict, useless stuff)
19:53:25 <kc5tja> I'm just glad I'm not doing direct threaded, or else I'd be even more cramped.  I'd have to give up the second top of stack cache (EBX) and probably use that for the word pointer, and use EDI for the virtual instruction pointer.
19:53:35 <kc5tja> That would suck, because then I won't have ANY free registers.
19:54:13 <Herkamire> kc5tja: get a ppc ;)
19:54:19 <kc5tja> Herkamire: Too expensive.
19:54:33 <Herkamire> ok, now how's this editor going to work...
19:54:35 * Herkamire hmmmmmms
19:54:52 <Herkamire> kc5tja: you said you liked 68K... get an old one :)
19:55:21 <kc5tja> Herkamire: Even those are too expensive for me right now.  I do have my Amiga 500 still, but it's in storage, and I have no place to set it up right now.  And it won't work with VGA monitors.
19:55:42 <Herkamire> oh well.
19:55:43 <kc5tja> There's an Amiga 4000 up for sale on eBay right now, but that's out of my price range already.  Until I land a job, I just can't afford to purchase it.  :( :(
19:55:53 <kc5tja> (Amiga 4000s use 68040s)
19:56:10 <kc5tja> Otherwise, you can bet your bottom's dollar I'd jump all over it.  :)
19:56:10 <Herkamire> play with what you have :)
19:56:21 <kc5tja> I am.
19:56:35 <kc5tja> And I'm hating every minute of it.
19:56:49 <kc5tja> I'm forced to use the PC architecture by default, not because I want to.
19:56:56 <Herkamire> I did spend a lot on this computer. but it's almost three years ago, and I still consider it fast.
19:57:06 <Herkamire> (dual G4 450Mhz)
19:57:18 <gilbertdeb> kc5tja: by default?
19:57:27 <gilbertdeb> ebay is the solution. whats the question?
19:57:34 <kc5tja> My biggest problem with PowerPC-based motherboards, Macs not withstanding, are that they're just IBM PC/AT motherboards with PowerPCs on them for processors.
19:57:52 <Herkamire> are they?
19:58:06 <kc5tja> Even the Mac mobos are based heavily on "standard" PowerPC chipsets, which just have all the standard IBM PC/AT peripherals on them.
19:58:08 <kc5tja> Yes, they are.
19:58:19 <kc5tja> Some things are different, but not much.
19:58:40 <kc5tja> The IDE interface is the same, the built-in interval timers are the same, the USB OHCI controllers are the same, etc.
19:58:50 <ianni> whats the problem with that?
19:58:53 <kc5tja> They do it to reduce cost of manufacture, which makes sense from that point of view.
19:59:01 <ianni> its not as good as some other kind of board?
19:59:12 <ianni> well, it's nice that everything is fairly interoperable too
19:59:24 <kc5tja> The problem is that the hardware is bloated and monolithic -- you can't have nearly as much *fun* with them like you could the older hardware, which was much simpler and easier to bit-bang.
19:59:34 <ianni> ah
19:59:52 <ianni> you want @executable_path
19:59:55 <kc5tja> For example, the floppy disk controllers on the standard chipsets do *NOT* give bit-level access to the data stored on a floppy.
19:59:57 <ianni> misfire
19:59:59 <kc5tja> Amiga's hardware does.
20:00:00 <ianni> interesting
20:00:40 <Herkamire> by bit-level you mean that you can read and write everything on there right?
20:00:54 <kc5tja> And with the frequency with which floppy disks lose data now-a-days, having that bit-level access is awfully important for data recovery purposes.
20:01:05 <kc5tja> Herkamire: Yes.  EVERYTHING.
20:01:23 <kc5tja> Amiga's floppies can read/write MacOS (fixed-speed) disks, PC disks, Atari ST disks, and of course, its own disks.
20:01:31 <Herkamire> well, I say you aughta have bit-level access
20:01:54 <Herkamire> I don't have a floppy at all
20:02:00 <gilbertdeb> kc5tja: isn't it the software for the drive that does the reading?
20:02:05 <kc5tja> gilbertdeb: No
20:02:12 <kc5tja> gilbertdeb: Not for the PC, at least.
20:02:28 <gilbertdeb> are you serious?
20:02:30 <Herkamire> that sucks
20:02:31 <kc5tja> gilbertdeb: The FDC does the reading; the PC merely offloads the 512 "cooked" bytes from the FDC into memory via a DMA channel.
20:02:35 <gilbertdeb> the amiga had it in hardware?
20:03:11 <kc5tja> gilbertdeb: Hardware/software; the hardware did **NOTHING** to interpret the data on the disk; it was entirely up to the software to interpret the contents of a cylinder into useful data for the rest of the system.
20:03:51 <kc5tja> Likewise, when writing data to the disk, the software had to MFM-encode (or GCR encode if writing to an C1581 disk) the bitstream before sending it to the floppy for writing.
20:03:54 <Herkamire> I haven't spent any money on computers since I bought my computer almost 3 years ago, but I'm considering buying one of Apple's 17" flatpannels. It's a lot of money for a luxury, but DAMN they're nice. I use this computer soo much
20:04:33 <kc5tja> The only thing the Amiga's hardware did was DMA the raw cylinder data to and from memory.  That's it.
20:04:48 <Herkamire> kc5tja: sounds cool.
20:05:00 <ianni> I want a 17" powerbook
20:05:03 <kc5tja> Oh, it was.  And it came in damn handy on occasion too.
20:05:12 <ianni> i tried a 1ghz one at the store yesterday.. holy shit
20:05:15 <Herkamire> I want to have access like that to IDE disks in my OS
20:05:17 <ianni> im used to my 400mhz desktop..
20:05:17 * kc5tja wants to know when 21" PowerBooks will become available... :D
20:05:25 <ianni> kc5tja will ther ebe such a thing? haha
20:05:41 <kc5tja> Doubt it.  LCDs that big are horrendously expensive.
20:05:41 <Herkamire> kc5tja: hehe :)
20:05:51 <kc5tja> 80% the cost of the laptop is the LCD, believe it or not.
20:06:14 <Herkamire> kc5tja: and the most annoying part too :)
20:06:52 <kc5tja> Hmmm....now that is an idea.  Instead of hooking my 65816 to the VGA monitor, I suppose I could equip it with a spinning mirror projection display using red, green, and blue LEDs.  :D
20:07:13 <gilbertdeb> kc5tja: sounds like the amiga was the schizniz
20:07:21 <kc5tja> gilbertdeb: It was.
20:07:33 <kc5tja> gilbertdeb: If it weren't for the Amiga, we wouldn't have PCs as powerful as we have them today.
20:07:44 <kc5tja> Macs would probably still be in the 256-color era.
20:08:03 <gilbertdeb> kc5tja: what motivated the makers?
20:08:26 <kc5tja> gilbertdeb: AmigaOS was a true, preemptive multitasking operating system that could run to full capacity in as little as 128KB of RAM.
20:09:15 <kc5tja> gilbertdeb: The video architecture was the first the world had ever seen; an evolution of the Atari 800 video chipset, the Agnus and Denise chips provided the user with 8 sprites and up to 640x400 resolution graphics with 16 out of 4096 colors, and up to 320x400 graphics with up to 4096 colors on the screen at once.
20:10:12 <Herkamire> I got to try an Amiga a few month ago.
20:10:26 <kc5tja> gilbertdeb: The audio chipset was earth-shattering at the time; no computer in the world could claim stereo sound.  Though the audio channels used 8-bit DACs, each output channel had an additional 6-bit DAC for "volume control."  The DMA controller could be configured to fetch volume data with each sample, producing an effective 12-bit audio.  Unheard of in a computer of that era.
20:10:42 <Herkamire> I was very impressed. it had a windowing system, acons, games (wich fullscreen movement) all on that ancient machine, and all off a floppy.
20:11:03 <kc5tja> And nowhere in the world could a 7.15909MHz processor be found performing 640x400 full-screen animation at 60 frames per second!
20:11:34 <gilbertdeb> kc5tja: an Amiga revival is required.
20:11:40 <gilbertdeb> kc5tja: is the OS open?
20:11:44 <kc5tja> gilbertdeb: It's been tried.  Every attempt has failed.
20:11:50 <Herkamire> pacmanie was quite impressive :) if the joystick didn't suck so much it would have been awesome :)
20:11:57 <gilbertdeb> freeAmiga then.
20:12:03 <kc5tja> gilbertdeb: No.  That's part of the problem.  But AmigaOS isn't strictly required.  
20:12:26 <gilbertdeb> kc5tja: but the OS was quite the thing according to what you said no?
20:12:37 <kc5tja> What's needed is an OS environment that is sufficiently AmigaOS-like.  I've done it, several times (my Dolphin series).  But I've never gotten beyond the simple kernel.
20:13:11 <kc5tja> gilbertdeb: Yes, but it isn't just the operating system.  It is just as much the equipped hardware as it is the software.
20:13:31 <kc5tja> The PC today can be made sufficiently Amiga-like, but only because there are coprocessors for everything, including the kitchen sink, all included on the video card.
20:13:33 <gilbertdeb> kc5tja: do you think with current hardware anything like that could be achieved in just as little space?
20:13:55 --- part: gilbertdeb left #forth
20:13:59 <kc5tja> But ti still lacks the fine-grained control for things like floppy drive, and the SCSI interfaces for the PC are still not quite standard.
20:14:00 --- join: gilbertdeb (~gilbert@fl-nked-ubr2-c3a-29.dad.adelphia.net) joined #forth
20:14:03 <gilbertdeb> hmm.
20:14:13 <kc5tja> gilbertdeb: Smaller space, actually.
20:14:25 <gilbertdeb> smaller than what the amiga offered?
20:14:26 <kc5tja> gilbertdeb: My exec.library-killer was coded in as little as 8KB.
20:14:30 * kc5tja nods
20:14:42 <kc5tja> The GUI architecture and graphics libraries took up the bulk of the ROM space.
20:14:45 <gilbertdeb> kc5tja: this is the net, we need url's :)
20:14:54 <gilbertdeb> of the 8kb?
20:14:57 <kc5tja> gilbertdeb: URLs for what?
20:14:58 <gilbertdeb> you must be kidding !
20:15:02 <kc5tja> Nope.
20:15:05 <kc5tja> Multitasking is not hard.
20:15:07 <gilbertdeb> kc5tja: this stuff!
20:15:25 <kc5tja> All my stuff is gone now.  I have no idea what happened to it all, unfortunately...  :(
20:15:32 <gilbertdeb> kc5tja: so why does say linux require such a magnificent effort?
20:15:36 <kc5tja> I do intend on recreating it someday though.
20:16:09 <kc5tja> gilbertdeb: Because the OS architecture is highly monolithic, not well factored, and is fucking based on goddamned 30-year old technology, and I don't give two fucking shits WHAT Linus says!
20:16:14 <kc5tja> Linux *IS* UNIX.
20:16:17 <kc5tja> As is BSD.
20:16:24 <kc5tja> THAT'S why it's damned huge.
20:16:41 * kc5tja is still sore to this day taht Linux hasn't shrunk over time.
20:16:53 <kc5tja> It's only gotten bigger, and bigger, and bigger, and bigger, and ...
20:16:58 <kc5tja> And the complexity of it is through the roof.
20:17:04 <kc5tja> Whatever happened to "Linux for the Desktop?"
20:17:07 <kc5tja> Bah.
20:17:09 <kc5tja> Piece of shit.
20:17:12 <kc5tja> I hate it.
20:17:13 <kc5tja> I hate lInux.
20:17:16 <kc5tja> I hate WIndws.\
20:17:19 <kc5tja> asdf
20:17:22 <kc5tja> I hate Windows.
20:17:25 <kc5tja> I hate BSD.
20:17:28 <kc5tja> I hate OS/2
20:17:30 <kc5tja> I hate them all!
20:17:48 <kc5tja> Every frigging OS for the PC is EITHER based on Unix, or based on CP/M in some manner or another.
20:17:49 <Herkamire> kc5tja: you should get back to dolphin
20:17:56 <Herkamire> I want to see more OSes
20:18:10 <kc5tja> Herkamire: I am getting back to Dolphin.  FS/Forth has a huge role to play in delivering Dolphin 0.5 to the market.
20:18:25 <gilbertdeb> kc5tja: what about the mac?
20:18:29 <kc5tja> The alternative is to code Dolphin 0.5 purely in assembly language.
20:18:31 <Herkamire> what is FS/Forth. you keep mentioning it
20:18:40 <kc5tja> FS/Forth is the Forth environment that I'm coding up.
20:18:42 <gilbertdeb> kc5tjaforth Herkamire
20:18:43 <kc5tja> gilbertdeb: What about it?
20:18:52 <gilbertdeb> do you like it?
20:19:01 <Herkamire> gilbertdeb: huh?
20:19:10 <kc5tja> gilbertdeb: I like its user interface, but that's it.  Its OS architecture makes Windows disgustingly simple in comparison.
20:19:43 <kc5tja> MacOS used to be pretty simple, back in the day.  But today, it's insanely complex.
20:19:58 <gilbertdeb> how did you lrn so much about the amigaos innards?
20:20:03 <kc5tja> And MacOS X only makes it worse, since it's MacOS System 9, MacOS X native, and NeXTStep all roled into one system.
20:20:15 <kc5tja> gilbertdeb: I coded software for Amiga back in the mid to late 80s.
20:20:23 <kc5tja> gilbertdeb: Later I used to work for Amiga, Inc.
20:20:31 <gilbertdeb> i see
20:20:33 <kc5tja> (post Gateway sale)
20:20:36 <ianni> well, i wouldnt say it's os9 and osx and nextstep
20:20:44 <ianni> the bluebox is just a spearate exectuable
20:20:55 <kc5tja> ianni: I would.  It's all so seemlessly integrated, it may as well be one big chunk o' code.
20:21:03 <ianni> well
20:21:05 <Herkamire> my mom just bought a mac, and it didn't have OS 9 installed.
20:21:08 <ianni> yeah, foundation.. hmm
20:21:11 <kc5tja> Heh -- are they still calling it yellow box and blue box?  :)
20:21:12 <ianni> i wouldnt knoiw
20:21:17 <njd> my mac os x machines came with os9
20:21:26 <ianni> I don't know - just that they call classic environment blue box i think
20:21:27 <ianni> iirc
20:21:29 <njd> it's only ran when an older application needs it and doesn't support mac os x
20:21:36 <ianni> Apple doesn't ship boxes that run OS9 anymore..
20:21:43 <ianni> for good reason...
20:21:48 <ianni> everyone should go to OSX
20:21:59 <Herkamire> it was on the CD's I think
20:22:06 <kc5tja> My friend's MacOS X-based laptop came with MacOS 9 as well.  You double-click on an OS9 application, and it spends 15 minutes loading and running the MacOS 9 software.  Complete with "loading extensions".  :)
20:22:08 <ianni> thoguh i'd be pissed if i needed os9 and i got a new one
20:22:20 <njd> kc5tja 15 mins?! mine takes bout 10 seconds
20:22:25 <ianni> kc5tja: classic environment boots in less than 60 seconds for me
20:22:29 <Herkamire> 15 minutes???
20:22:29 <kc5tja> njd: I was being facetious
20:22:34 <ianni> ;)
20:22:39 <njd> ah
20:22:59 <ianni> it runs pretty well, for being the entire OS9 resident inside the other os
20:23:11 <kc5tja> Most of the MacOS "Classic" environments I've seen take more than 60 seconds to boot, because they have so many drivers and extensions loaded.  I've seen those icons go three rows deep on the screen.  :)
20:23:19 <kc5tja> Yes, it does.
20:23:24 <Herkamire> I asumed it wasn't all integrated. I can (and did at work) run Mac OS 9 inside Linux
20:23:32 <njd> kc5tja damn that's alot
20:23:46 <kc5tja> But where MacOS boots in less than 60 seconds, AmigaOS (similarly equipped) boots in less than 10 seconds flat.
20:24:05 <kc5tja> My Amiga 500 boots in only 4 seconds, after the cold-boot memory check.
20:24:29 <Herkamire> that's one of the things that pisses me off in a major way about recent Operating Systems.
20:24:31 <kc5tja> And it's still running on a bone-stock processor at 7MHz.
20:24:39 <Herkamire> what the hell could they possibly be doing that would take 60 secconds.
20:25:00 <kc5tja> Herkamire: Well, part of the problem is that MacOS X is, you got it, Unix.
20:25:09 <kc5tja> It's going through the normal Unix boot sequence.
20:25:17 <Herkamire> all I want my computer to do when I turn it on is pick up where I left off, which it doesn't even do.
20:25:21 <kc5tja> Mounting file systems, checking volumes, etc.
20:26:26 <njd> the dock is very nice though :)
20:26:38 <kc5tja> njd: That's NeXTStep's dock.  :)
20:26:52 <njd> apple steal alot of things
20:27:03 <kc5tja> MacOS X is the next NeXTStep.  The API is even littered with function names and classes that all start with NS.
20:27:04 <gilbertdeb> njd: they borrowed it from Jobs.
20:27:19 <njd> who's seen pirates at silicon valley
20:27:23 <kc5tja> njd: "Borrowed"?  "Stole?"  No, sir; this was Jobs' plan right from the start.
20:27:24 <ianni> kc5tja: not really littered.. it is an opensdtep!
20:27:26 <TreyB> Borrowed?!  They paid $400M for it.
20:27:31 <Herkamire> kc5tja: oooooh. I never figured out why they had NS in them
20:27:33 <ianni> And it works great.
20:27:44 * kc5tja nods to TreyB
20:27:47 <ianni> and it makes win32 look like qbasic
20:27:52 <ianni> obfuscated
20:27:58 <njd> i found a bug in qbasic!
20:27:59 <kc5tja> From the day Jobs left Apple and created NeXT, inc., this has always been part of Job's vision of the next Mac.
20:28:03 <ianni> heh nice :)
20:28:04 <kc5tja> He *knew* what would happen all along.
20:28:14 <gilbertdeb> kc5tja: isn't he the sneaky one?
20:28:18 <ianni> never used next
20:28:23 <ianni> but openstep kicks ass!
20:28:30 <ianni> its like java, but better
20:28:34 <kc5tja> ianni: It's pretty much the same thing.
20:28:38 <ianni> nod
20:28:38 <njd> what's openstep ? programming language?
20:28:41 <ianni> it's the spec
20:28:57 <kc5tja> njd: It's the minimal API specification for NeXTStep, basically.  
20:28:59 <ianni> objective C just provides basic syntax
20:29:13 <ianni> openstep is like the class libraries and memory allocation stuff, 
20:29:21 <gilbertdeb> kc5tja: wouldn't you say server software is simply large and thats why all these other os'es are so large?
20:29:21 <njd> oh yep
20:29:29 <kc5tja> gilbertdeb: No.
20:29:35 <Herkamire> gilbertdeb: no
20:29:41 <kc5tja> gilbertdeb: Think about it: every GUI application has an event loop at its core, correct?
20:29:46 <gilbertdeb> eg winNt's vms influence, linux/bsd's unix influence etc ?
20:29:54 <kc5tja> gilbertdeb: And every server has an event loop at its core, correct?
20:30:04 <gilbertdeb> kc5tja: sure if you say so :)
20:30:06 <kc5tja> gilbertdeb: Why, then, is apache more than 10 times as large as the average GUI program?
20:30:06 <gilbertdeb> I really don't know.
20:30:15 <gilbertdeb> hmmm.
20:30:17 <ianni> whats wrong with apache
20:30:24 <Herkamire> I think GUI software is harder to write (and ends up bigger) than server software.
20:30:38 <ianni> cocoa makes gui software a joy to write
20:30:53 <ianni> (apple's nextstep)
20:30:54 <kc5tja> gilbertdeb: It's because of the following: to talk over the network, you need to use sockets.  To talk to the filesystem, you need to use file handles.  To talk to sub-processes and threads, you need to use pipes, message queues, or the like.
20:31:15 <kc5tja> Each of these "file-like" objects all have *completely* different semantics in Unix, and as a result, all require bizarre ioctl()s and what not to configure them.
20:31:15 <gilbertdeb> kc5tja: I know you can setup an http server in rebol... given that the whole language is < 500k ... apache could seem bloated from that pov.
20:31:29 <kc5tja> gilbertdeb: Apache is a mammoth.
20:31:51 <kc5tja> But let's not forget that Linux actually has an embedded web server *IN IT* that Apache relies on to optimize the network performance for speed.
20:32:11 <Herkamire> apache doesn't rely in the kernel httpd
20:32:20 <njd> i heard they are getting rid of that
20:32:21 <gilbertdeb> so kc5tja if you redid it, would you then have just one ioctl?
20:32:50 <kc5tja> Herkamire: My rear end it doesn't.  That's why it was placed there to begin with; the Apache programmers were complaining that linux was too slow compared to BSD's network performance, and optimization attempts showed it to be the massive user-kernel-user boundary changes.
20:32:59 <ianni> *nod*, apache ships with macosx for ex.
20:33:09 <ianni> theres no linux kernel there
20:33:16 <kc5tja> ianni: Ever heard of #ifdef?  :)
20:33:26 <kc5tja> It's the conditional compilation directive for C compilers.
20:33:26 <ianni> so wait
20:33:30 <Herkamire> kc5tja: sure apache goes faster with it. but it works fine without it.
20:33:32 <ianni> yes, of course I have
20:33:37 <kc5tja> Herkamire: Did I say it didn't?
20:33:39 <ianni> what does apache rely on?
20:33:42 <ianni> im curious
20:33:50 <gilbertdeb> ianni: what do you mean?
20:33:51 <kc5tja> ianni: Whatever is available in the kernel.
20:33:56 <gilbertdeb> it relies on an OS :)
20:33:58 <ianni> kc5tja for a webserver?
20:34:03 <ianni> ?!?? apache is one
20:34:07 <ianni> that makes no sense haha
20:34:20 <kc5tja> ianni: Apache sits on the port, and waits for HTTP requests.
20:34:35 <kc5tja> When it gets one, and it's not a CGI, it passes the port and file handle to the kernel, and says, "Send it."
20:34:49 <kc5tja> The kernel then sends the file to that port, all without the gratuitous user/kernel boundary changes.
20:34:50 <ianni> would that not bring performance improvements?
20:35:00 <kc5tja> ianni: That's why it's there.
20:35:02 <ianni> i mean isnt that what would happen in the end anyway?
20:35:04 <ianni> ah
20:35:07 <ianni> i follow
20:35:07 <kc5tja> No.
20:35:20 --- quit: semtex (Connection timed out)
20:35:28 <kc5tja> Because otherwise, you'd have to call upon the sockets API to send the data, and there, you're repeatedly making calls to send() or some such.
20:35:30 <ianni> its telling it what and where to send instead of manually telling it what to send and where
20:35:37 <kc5tja> Precisely.
20:35:38 <ianni> *nod*
20:35:48 <ianni> interesting...
20:35:51 <kc5tja> All in the attempt to reduce user/kernel boundary crossings.
20:36:02 <ianni> it's intresting that orion server, a pure java application, could beat apache 1 at static content
20:36:03 <Herkamire> I'm not too sure about streams and filehandles and stuff.
20:36:08 --- join: semtex (~Speuler@mnch-d9ba4d4f.pool.mediaWays.net) joined #forth
20:36:09 <ianni> according to some benchmarks
20:36:24 <kc5tja> ianni: I use Zope without Apache, and have had zero problems with it.
20:36:34 <kc5tja> Apparently this performance "bottleneck" only appears on heavily loaded servers.
20:36:54 <kc5tja> But realistically speaking, if you're that heavily loaded, you're going to have the cash to either webcache or distribute the web loads anyway.
20:37:01 <kc5tja> Why pollute the damn kernel with this crap?
20:37:08 <kc5tja> It really pisses me off.
20:37:26 <Herkamire> I would try Zope, except last time I checked it required a certain version of python. and I'm not going to screw with python because that's what my package management is written in (Gentoo)
20:37:47 <kc5tja> I ahve to admit that AmigaOS's ROMs were 256K and 512K in size, and included all the relavent drivers to boot the system and whatnot.  But good grief, Linux goes way, way overboard.
20:38:06 <kc5tja> Herkamire: Zope has always come with its own Python version, ever since 1.0.
20:38:23 <kc5tja> Herkamire: At least the Linux distributions have.  
20:38:25 <Herkamire> kc5tja: when was that?
20:38:29 <kc5tja> Herkamire: Since 1.0
20:38:59 <ianni> kc5tja: it's funny when people do the equivalent of getting a watch maker to fix their cheap timex, when they could just buy a real watch :)
20:39:17 <kc5tja> ianni: Exactly!  And that's the problem I have with Linux.
20:39:31 <kc5tja> Ever try to use CORBA with GTK?  You can't do it!!
20:39:33 <kc5tja> Just can't !!
20:39:41 <kc5tja> My question si WHY though?  
20:39:42 <Herkamire> kc5tja: ok, so nobody has bothered to make Zope a proper build script for Gentoo.
20:39:51 <ianni> oh that's scary... I avoid corba and I avoid GTK like the plague :)
20:40:04 <ianni> i only recently learned C++
20:40:06 <kc5tja> Herkamire: Oooohhhh...gentoo likes to fsck with a lot of stuff.  I really don't like Gentoo for doing that.
20:40:13 <ianni> before then it all looked scary.. now it just looks scary and stupid..
20:40:21 <kc5tja> CORBA is the best system around.
20:40:26 <kc5tja> I've not yet found anything better.
20:40:38 <Herkamire> kc5tja: gentoo is so many miles better that YDL (based on Redhat)
20:40:39 <ianni> it's for RMI?
20:40:49 <ianni> im not familiar
20:40:55 <kc5tja> ianni: No.
20:41:10 <Herkamire> gentoo will automagically install almost everything I want, and I can hack the sources when I like.
20:41:22 <njd> what is zope ? php-type thing ?
20:41:32 <kc5tja> ianni: CORBA is to enable remote object invokations, regardless of language.  RMI is Java-specific.  Though RMI uses IIOP, it is not CORBA.
20:41:54 <kc5tja> njd: No; PHP is passe.  Zope is a Cold Fusion destroyer.  http://www.zope.org
20:42:18 <ianni> nice...
20:42:20 <Herkamire> PHP is passe?
20:42:20 <ianni> I do J2EE
20:42:29 <kc5tja> Herkamire: I tried Gentoo.  It royally fscked up my whole system, to the point where Portage just plain didn't work at all.  Eveyrthing I tried to install via Portage just errored out.  The system became unusable.
20:42:30 <ianni> php seems nie for small websites or scripting maybe
20:42:42 <ianni> j2ee is better for real enterprise/web apps
20:42:43 <Herkamire> kc5tja: bugger
20:42:50 <Herkamire> kc5tja: I haven't heard of that
20:43:16 <Herkamire> kc5tja: I uninstalled python once, but other than that I had much trouble
20:43:25 <kc5tja> ianni: J2EE is CORBA compatible, IIRC.  With only minimal work, you can expose Java objects as CORBA objects.
20:43:46 <kc5tja> Herkamire: I assume you mean hadn't instead of had
20:44:04 <Herkamire> kc5tja: mmmm yes :)
20:44:36 <kc5tja> Dolphin was going to use CORBA rather extensively at first, back when I was gearing it under a microkernel architecture.
20:44:38 <Herkamire> asside from a few things it wouldnt install or wouldn't install my way, I've been very very happy with gentoo
20:44:55 <kc5tja> But now that I'm heavily leaning towards exokernel, I am leaving that decision up to the user-space software developers.
20:45:17 <Herkamire> CORBA sounds frightening. but I don't have a real clear idea what it is.
20:45:38 <kc5tja> Herkamire: Well, the first red-flag I had was when I modified the USE variable to include "-xdm", and it happily installed and configured it, subsuming my preferences entirely, regardless.
20:46:05 <kc5tja> Herkamire: CORBA is a glorified (and very, very run-time efficient) object-oriented remote procedure call system.
20:46:18 <kc5tja> s/run-time/network bandwidth/
20:46:29 <Herkamire> ok. still scarry...
20:46:37 <kc5tja> Why is it scary?
20:46:48 <Herkamire> how does authentication work?
20:46:59 <kc5tja> It doesn't.
20:47:04 <Herkamire> that's scary
20:47:07 <kc5tja> No, it's not.
20:47:11 <kc5tja> Why is that scary?
20:47:13 <Herkamire> what is it used for?
20:47:33 <Herkamire> why don't you open a tcp socket and just communicate to the other computer
20:47:52 <Herkamire> or just send it a message with udp
20:47:52 <kc5tja> Remote object invokations, network management, distributed GUI architectures (e.g., Berlin uses CORBA), pretty much anything that you would otherwise have to create your own networking protocol for.
20:48:09 <kc5tja> Herkamire: Because then you end up having to write all that infrastructure yourself.
20:48:24 <kc5tja> CORBA just takes an IDL file, and generates server and client code for you.  You just fill in the gaps.
20:48:41 <Herkamire> what about authentication?
20:48:49 <kc5tja> What about HTTP authentication?
20:48:54 <kc5tja> What about SMTP authentication?
20:48:59 <kc5tja> What about FTP authentication?
20:49:08 <Herkamire> they suck
20:49:10 <kc5tja> It isn't the job of the network transport to authenticate.
20:49:17 <kc5tja> It's the job fo the software behind it.
20:49:23 <kc5tja> They don't suck.
20:49:52 <kc5tja> If those suck, then there is literally *no* authentication system that will satisfy you.
20:50:07 <Herkamire> HTTPS is ok
20:50:17 <kc5tja> So use CORBA over an SSL channel.
20:50:20 <kc5tja> Problem solved.
20:50:21 <Herkamire> I'm kinda interested in securidy right now
20:50:41 * kc5tja believes in capability-based security, not ACL-based.
20:50:52 <Herkamire> particularly in a way of knowing for sure who the message is coming from
20:50:54 <kc5tja> It's significantly lower-overhead, and is just plain eaiser to deal with.
20:51:04 <kc5tja> You always know who the message is coming from anyway.
20:51:28 <Herkamire> by ip?
20:51:38 <kc5tja> IP and port.  
20:51:46 <kc5tja> And if you spoof an IP, it subsumes even SSL anyway.
20:51:49 <kc5tja> So where's the benefit?
20:52:10 * kc5tja used to work for Hifn, a company that specialized in making security-related products for the Internet.
20:52:31 <Herkamire> ok, so you can do authentication in CORBA the same as you might do it over a socket.
20:52:35 <kc5tja> Authentication should always be high-level, and software backed.  Network transport should have *nothing* to do with it.
20:52:54 <Herkamire> I don't see the advantage of corba over tcp/udp
20:52:54 <kc5tja> If the ORB provides that service, yes.  Most don't, because most find it's simply not needed.
20:53:01 * kc5tja slaps his forehead.
20:53:02 <ianni> kc5tja: yes, there are corba libs for java
20:53:21 <ianni> thats where most of my experience with it comes from, seeing the corba libs :)
20:53:26 <kc5tja> OK, you can spend the three weeks it takes to write a client and server for your highly proprietary network exchange format.
20:53:32 <ianni> not really even in use.. just seeing them around
20:53:57 <kc5tja> And you can waste (and I do mean waste) ports for each individual session.
20:54:02 <ianni> kc5tja: i think java/j2ee has corba-like stuff. its just if i needed to talk to something else
20:54:04 <Herkamire> kc5tja: it's not that hard. and you only have to do it once.
20:54:16 <kc5tja> Herkamire: I've done it, and I hated it.
20:54:17 * ianni only avoids corba because of ignorance and not needing anything of that nature
20:54:17 <Herkamire> I'm sure I could write the tcp code much faster that learning CORBA
20:54:25 <kc5tja> Herkamire: It is the biggest time sink I can think of.
20:54:41 <kc5tja> Because you're just writing the same software, over, and over, and over, and over again, for each individual application.
20:54:47 <kc5tja> Think of all the different servers on a typical Unix box.
20:54:54 <kc5tja> Think of all the socket code that they ALL have in common.
20:55:00 <kc5tja> But they're all so very different, at the same time.
20:55:01 <kc5tja> Why?
20:55:04 <kc5tja> There's no need.
20:55:09 <kc5tja> CORBA eliminates this problem.
20:55:28 <kc5tja> And it makes it so that you can access remote objects on the same system, WITHOUT intervening with the network.
20:55:40 <kc5tja> This means, that "remote" objects that aren't really remote, get invoked via a mere subroutine call.
20:55:41 <Herkamire> so you put the code in a common C file (or whatever language) and include it in your project
20:55:46 <gilbertdeb> kc5tja: what are you saying? that with corba you can reduce some of the complexities signifcantly?
20:56:10 <ianni> i think he's saying corba does what you want 
20:56:20 <kc5tja> No, you write an IDL file (Interface Description Language).  You then compile this IDL file, and it will generate client and server skeletons for you.  These skeletons use a consistent server library.
20:56:31 <ianni> thats nice
20:56:46 <kc5tja> The server, then, is written like any other application object.
20:56:52 <kc5tja> In C++, the server is a C++ class.
20:56:53 <kc5tja> etc.
20:56:57 * ianni is kinda scared, a DCOM framework going into production soon 
20:57:05 <ianni> at the mercy of MS
20:57:06 <ianni> hehehe
20:57:47 <kc5tja> The client works by calling upon the remote object, which looks exactly like a normal, say, Python object (assuming the client is written in Python).
20:58:31 <kc5tja> The client stub is responsible for determining if the object referenced is local (if so, just call it directly), or remote, and if remote, to create a network packet with the relavent data (method parameters), and invokes the service.
20:59:09 <Herkamire> I think that offering access to function calls on objects to remote applications would introduce TONS of security holes.
20:59:13 <kc5tja> The ORB (think of it as an HTTP server, because it's very similar to one) receives this packet, and dispatches the request to the relavent software skeleton, where the parameters are unmarshalled, and the actual server code invoked.
20:59:26 <kc5tja> Herkamire: CORBA ahs been around since 85.
20:59:32 <kc5tja> I'm not familiar with a single security breach.
20:59:50 <ianni> not a bad track record
21:00:10 <kc5tja> Each request to the ORB has the equivalent of a URL included in it: it has a (machine ID, object ID) tuple which uniquely identifies the object.  If that object doesn't exist, the method isn't invoked.
21:00:31 <kc5tja> If it does exist, then yes, the method IS invoked.
21:00:48 <kc5tja> HOWEVER, like all secure software, THE SERVER IS RESPONSIBLE for checking credentials!
21:00:54 <Herkamire> ok, so CORBA is like tcp or udp, but it has a better API
21:01:02 <kc5tja> This means, you pass, as an implicit or explicit parameter, some kind of object that the server can verify.
21:01:12 <kc5tja> It relies on TCP.
21:01:40 <Herkamire> kc5tja: what do you (personally) use corba for?
21:02:00 * gilbertdeb wants to hear more about how os'es can slim down significantly.
21:02:19 <Herkamire> gilbertdeb: they can start from scratch
21:02:21 <natty> OMG this is the best episode of aquateen hunger force EVER! It's the attack of the killer web pop-up ads!
21:02:22 <kc5tja> When I was working for Armored Internet, I used it for automating user creation and maintenance, where a single console application would create user accounts on our web server box, our news server (for news server authentication), our mail server, or FTP server, etc.
21:02:27 <gilbertdeb> Herkamire: I thought they did.
21:02:38 <kc5tja> Each of these servers were separate boxes.
21:02:38 <Herkamire> gilbertdeb: ther's a bunch of tiny Operating Systems for x86.
21:02:49 <kc5tja> A simple shell script would not suffice, and was not scalable.
21:02:56 <gilbertdeb> Herkamire: do they have all the functionalities?
21:03:03 <gilbertdeb> eg reliable servers etc ?
21:03:39 <kc5tja> I also used CORBA to monitor these services, to ensure that they stayed up.
21:04:10 <kc5tja> We had a dedicated logging machine that could report to us (via e-mail to pagers) whether power went out, network went out, which individual services went out, etc.
21:04:40 <Herkamire> huh.
21:04:44 <kc5tja> Using CORBA, it didn't matter that all these services were located on the same machine or not -- the software codebase was exactly the same either way.
21:04:56 <kc5tja> Today, I don't use it for much of anything because I simply lack the need to.
21:05:22 <gilbertdeb> kc5tja: would you put corba in your kc5tjaforth?
21:05:25 <kc5tja> I am working at home for the most part, and I have no need for distributed computing; my 800MHz Athlon box is plenty sufficient for my needs.  :)
21:05:26 <Herkamire> I would use ssh for the remote commands, and write a local script that would hit the servers regularly, and notify me if it couldn't reach them
21:05:31 <kc5tja> gilbertdeb: Absolutely, as the need arised.
21:06:29 <kc5tja> Herkamire: But see, you're doing the job of CORBA.  And it's a hell of a lot more inconvenient and doesn't report the same information that the CORBA system could.
21:06:39 <Herkamire> I've used ssh, tcpclient and tcpserver for my networking.
21:06:45 <kc5tja> I took existing server software, and hacked in CORBA support, giving me internal views of each server.
21:06:49 <kc5tja> You can't do that with shell scripts.
21:07:09 <Herkamire> I don't want an internal view. I want to know that it's working.
21:07:26 <kc5tja> Yes, and you're completely re-inventing the wheel every time, and it's network inefficient (you're passing data back and forth as text, not binary).
21:07:26 <ianni> but i think you could get both from the former
21:07:28 <Herkamire> to test if Apache is working, I would sent it a request. If it get's back to me in a reasonable amount of time, then all's well
21:07:37 <kc5tja> Herkamire: And so do I.
21:07:44 <kc5tja> Why do you think I got internal states of the servers?
21:08:17 <Herkamire> I haven't bothered writing server monitors.
21:08:28 <kc5tja> For tech support especially, I needed to see what passwords people were typing in.  "But I AM typing my proper password!"  "No sir, you're prepending a space before typing your password.  That's why it's not logging you on."  <-- That type of stuff.
21:08:36 <kc5tja> I ran a business.  I *HAD* to write it.
21:08:52 <Herkamire> If I did, I would put some monitoring stuff on the server it's self, and have it e-mail me if it found something odd/bad. and I'd put something local to make sure the server is still up.
21:09:12 <kc5tja> Again, hack hack hack
21:09:18 <kc5tja> Hacks will break.
21:09:25 <kc5tja> In my experience, repeatedly, hacks will break.
21:09:26 <Herkamire> and what of your hacks?
21:09:42 <Herkamire> svscan works great
21:10:01 <kc5tja> They never broke for me.  And I had the benefit of real-time status updates.
21:10:13 <kc5tja> As soon as something went wrong, *boom* I knew it.
21:10:27 <Herkamire> do yo have to watch the status screen?
21:10:40 <kc5tja> For some of the technical support stuff, yes.
21:10:43 <kc5tja> Very much so.
21:10:54 <kc5tja> Especially when people *were* typing in proper user names and passwords.
21:10:54 <ianni> same as watching a pager though
21:11:02 <kc5tja> ianni: Nope.  Not at all.
21:11:08 <kc5tja> ianni: That isn't real-time.
21:11:10 <ianni> i mean you have to watch something
21:11:15 <ianni> but you had logs?
21:11:30 <kc5tja> ianni: Only the logs that the servers produced.  They don't log everything.
21:11:46 <kc5tja> (of course, we did change that, but we still found the Corba interfaces to be overwhelmingly more productive)
21:12:39 <kc5tja> The only server we didn't instrument was DNews, and that's because it was a commercial application.
21:13:15 <kc5tja> Fortunately, that server pretty much took care of itself.  And when it did go down, nobody knew about it, because nobody reads usenet news anymore.
21:13:29 <Herkamire> I'll stick with ssh, tcpserver, tcpclient, wget and the like.
21:13:39 * kc5tja shrugs
21:13:50 <Herkamire> time for bed
21:13:59 <Herkamire> see yous later
21:14:13 --- quit: Herkamire ("zzzZZZ")
21:15:08 <kc5tja> Another downfall to using SSH, in particular, is the sheer length of time it takes to establish a connection.
21:15:15 <kc5tja> Quite definitely NOT real-time.
21:16:24 <kc5tja> It makes me very, very sad when people look at technologies like CORBA and they just don't get it, and then they go and create software that does *exactly* what CORBA was designed to do.
21:16:28 * kc5tja just doesn't understand it.
21:17:35 <kc5tja> One of the reasons I like Forth is that it lets me re-use more of my code than other languages, more productively.
21:18:03 <kc5tja> CORBA is just one way I can re-use code in an operating system environment like Unix or Windows.
21:22:11 <kc5tja> brb -- I need to reset my X server; my window manager isn't accepting a new configuration for some retarded reason
21:22:17 <kc5tja> (This is another MAJOR problem that I have with OSes!!)
21:22:25 --- quit: kc5tja ("[x]chat")
21:27:36 --- join: kc5tja (~kc5tja@ip68-8-206-137.sd.sd.cox.net) joined #forth
21:29:00 <kc5tja> Cool.  Everything works again.
21:30:51 <gilbertdeb> isn't linux great?
21:31:00 <gilbertdeb> kc5tja: I am tempted to find me an amiga running the os.
21:32:07 <kc5tja> Heheh :)
21:32:19 <kc5tja> Well, I'm looking to move forward from AmigaOS.
21:32:29 <kc5tja> As great as AmigaOS is, it still is an OS.
21:32:45 <kc5tja> I'm looking for something that is more ... personally involving than AmigaOS.
21:32:54 <kc5tja> That's why I am "returning" to Forth for this purpose.
21:33:33 <kc5tja> But I do definitely want to resume work on Dolphin at some point, so as to put to rest, once and for all, the concept of Linux as being viable for the desktop.  >:)
21:35:34 <gilbertdeb> kc5tja: linux is only viable because there is a lot of software for it.
21:35:42 <gilbertdeb> but, what about the backend?
21:35:44 <gilbertdeb> the server side?
21:36:45 <kc5tja> I don't understand your question.
21:37:20 <gilbertdeb> you say desktop.
21:37:25 <gilbertdeb> I think thats not too hard ...
21:37:38 <gilbertdeb> but what about simple servers that do all the stuff todays servers do?
21:38:17 <kc5tja> I am concentrating on the desktop because that's where the user's "experience" comes from the most.
21:38:36 <kc5tja> The average user doesn't care about servers.
21:40:13 <kc5tja> That being the case, I've heard good things about AmigaOS being used for server applications.  But AmigaOS is a personal computer operating system; there isn't a lick of multi-user support anywhere in the system.
21:43:04 <gilbertdeb> so how would you design a better server?
21:43:28 <gilbertdeb> are there any models to go on?
21:45:01 <kc5tja> A typical GUI program is purely event driven.
21:45:15 <kc5tja> It has an event loop that looks something like this (in Python pseudo-code):
21:45:20 <kc5tja> def Main():
21:45:24 <kc5tja>   InitializeProgram
21:45:31 <kc5tja>   WHILE not Done():
21:45:36 <kc5tja>     evt = GetEvent()
21:45:43 <kc5tja>     HandleEvent( evt )
21:45:49 <kc5tja>   FinalizeProgram
21:46:02 <kc5tja> Interestingly enough, server code has *exactly* the same structure.
21:46:21 <gilbertdeb> what kind of servers are popular?
21:46:28 <gilbertdeb> database, web, mail, ftp, and whatelse?
21:46:35 <gilbertdeb> oh irc and im.
21:46:41 <gilbertdeb> does that cover everything?
21:46:42 <kc5tja> That's because they really are doing the same thing: the GUI framework is calling upon the application to do something via its event queue; likewise, a client is calling upon the server to do something via the IPC channel.
21:46:54 * kc5tja shrugs -- I have no idea, nor do I care.
21:47:00 <kc5tja> To me, a server is a server.
21:47:11 <kc5tja> They all boil down to that code fragment above, in one way or another.
21:47:30 <gilbertdeb> so a lot of 'factoring' is possible you think?
21:47:55 <kc5tja> In AmigaOS, *all* I/O functions were inherently asynchronous.  The *ONLY* thing that ever caused a program to stop was the exec.library call Wait(), which waited for something to happen.
21:47:57 <kc5tja> Yes.
21:48:14 <kc5tja> As it happens, AmigaOS uses the above code idiom extensively.  Indeed, much of the OS is itself written with that same fragment.
21:49:02 <kc5tja> The separation of event signals from asynchronous I/O made for a highly scalable, highly factored, highly reusable architecture.
21:49:13 <kc5tja> With Unix you have to work *HARD* to get that.
21:49:26 <gilbertdeb> which other oses do you know?
21:49:27 <gilbertdeb> vms?
21:49:36 <kc5tja> AmigaOS is heavily influenced by VMS.
21:49:42 <gilbertdeb> really?
21:49:43 <kc5tja> VMS was a great operating system.
21:49:44 <kc5tja> Yes.
21:49:52 <gilbertdeb> but it was humongous wasn't it?
21:49:59 <kc5tja> VMS is where it got AmigaDOS's CLI syntax, and exec.library's event and messaging architecture.
21:50:05 <kc5tja> Yes.
21:50:13 <kc5tja> Which goes to show you the power of factoring.
21:50:29 <gilbertdeb> I don't see the power of factoring if vms was so large!
21:50:39 <gilbertdeb> or you mean the amiga version?
21:50:39 <kc5tja> VMS == multi-megabyte operating system.
21:50:53 <kc5tja> AmigaOS == less than 256K for kernel and device drivers, and GUI.
21:51:27 <kc5tja> AmigaOS is a highly refined operating environment.  It's well engineered, the APIs are designed to be like Legos -- reusable and configurable.
21:51:40 <gilbertdeb> kc5tja: forth I say :)
21:51:52 <kc5tja> gilbertdeb: Yes, Forth shares many similar attributes.
21:51:55 <gilbertdeb> sassenrath still lists a forth on his personal home page.
21:52:13 <kc5tja> Well, he did author that Forth, but I doubt he still supports it or even works with Forth.
21:52:25 <kc5tja> The last I conversed with him, he didn't.
21:52:26 <gilbertdeb> yeah there was no link to it. just a mention.
21:52:51 <gilbertdeb> so was the amiga os lacking anything from vms?
21:53:20 <kc5tja> But don't under-estimate him.  exec.library (the part of AmigaOS he was responsible for, also the single most significant part of the whole OS) is a piece of art, and it definitely shows that he is skilled in writing well factored, highly reusable code.
21:53:27 <kc5tja> Yes.
21:53:37 <gilbertdeb> whats that?
21:53:40 <kc5tja> As I indicated, AmigaOS is purely a single-user OS.
21:53:45 <gilbertdeb> ah that.
21:53:47 <kc5tja> VMS supported a lot of users.
21:54:02 <kc5tja> Also, AmigaOS is a single-address-space (SAS) operating system; it worked without the aide of an MMU.
21:54:03 <gilbertdeb> could it have been extended to support multiple users and still be relatively small?
21:54:12 --- quit: sifbot (Read error: 110 (Connection timed out))
21:54:15 <kc5tja> VMS, however, enforced inter-process memory protection; it required a MMU to work.
21:54:24 <kc5tja> Yes, but that's dangerous.
21:54:34 <gilbertdeb> why?
21:54:36 <kc5tja> Because any one user could peek/poke another user's program memory.
21:54:45 <gilbertdeb> oh I see.
21:55:05 <kc5tja> Dolphin was going to extend the AmigaOS API, at some cost in speed, to support memory protection.
21:55:22 <kc5tja> Messaging between threads would be lightning fast -- just some pointer manipulation.
21:55:43 <kc5tja> Messaging between processes would take longer, since it had to remap pages and copy a maximum of 8KB of data, depending on data alignment.
21:56:42 <kc5tja> It also relied on a handle-based security system that was virtually infallible.
21:57:05 <gilbertdeb> I heard the vms team was behind winNT*
21:57:12 <kc5tja> Back then, this made some sense, as I was basing it on a microkernel architecture.  But today, I'm not so sure.  I'd like to use exokernel if at all possible.
21:57:13 <gilbertdeb> why did they make it so big then?
21:57:15 <gilbertdeb> and sucky too.
21:57:27 <kc5tja> NT's kernel isn't big (it's only 250KB), and it's not sucky.
21:57:38 <gilbertdeb> you prefer nt?
21:57:41 <kc5tja> It's the win32 layer that sits on top of the NT kernel that is sucky, big, bloated, and outrageously slow.
21:58:04 <kc5tja> No, I still prefer AmigaOS over NT.
21:58:05 <gilbertdeb> was the vms team responsible for the win32 layer?
21:58:08 <kc5tja> No.
21:58:14 <gilbertdeb> so they did learn :)
21:58:14 <kc5tja> Microsoft was purely responsible for the Win32 layer.
21:58:22 <kc5tja> Nope.  :(
21:58:29 <gilbertdeb> the vms team i mean.
21:58:30 <kc5tja> Microsoft had nothing to do with the creation of the NT kernel.  :(
21:58:41 <gilbertdeb> who created it?
21:58:44 <gilbertdeb> surely not IBM!
21:58:53 <kc5tja> About half of the original VMS team.
21:59:01 <kc5tja> The other half went on to other projects at the time.
21:59:23 <kc5tja> IBM is responsible for OS/2, another pretty solid design (though inspired by VMS, it's much less so than AmigaOS).
21:59:50 <gilbertdeb> 250k you say for a vms-ish kernel?
21:59:53 <kc5tja> OS/2's primary influence, though, is VM/MVS, IBM's mainframe operating system.
21:59:57 <kc5tja> gilbertdeb: Yep.
22:00:00 <kc5tja> It's not that big.
22:00:02 <gilbertdeb> the vms kernel on the vaxes were they that small too?
22:00:25 <kc5tja> I think the kernel without the device drivers, was probably about 300 to 400K back then.
22:00:48 <gilbertdeb> hmm.
22:00:56 <kc5tja> The device drivers and terminal I/O support, plus record processing services which came standard with the OS (don't ask -- big-iron mainframe stuff) took up most of the space.
22:00:57 <gilbertdeb> how does one find out more about vms'es internals?
22:01:09 <gilbertdeb> it sounds like the whole damned thing can fit on a floppy and be just fine.
22:01:20 <kc5tja> I just did a lot of Internet research via Google, and I happened to find a book on VMS internal architecture design.
22:01:28 <gilbertdeb> did you read it?
22:01:33 <kc5tja> That book's in storage now, so I cn't post an ISBN, but when I find it, I'll be sure to pass it on.
22:01:35 <kc5tja> Yes.
22:01:46 <gilbertdeb> did you like the stuff it said?
22:01:51 <gilbertdeb> is it doable by one person?
22:01:57 <gilbertdeb> or does it require team lifting?
22:02:32 <gilbertdeb> I say team lifting in the sense that one man can build a wright flyer1, but it takes a corporation to build a jumbo jet.
22:05:16 <kc5tja> With careful study, it is quite doable by one person.
22:05:35 <gilbertdeb> in forth? :)
22:05:36 <kc5tja> But it does take a lot of time to get the details right.
22:05:39 <kc5tja> Yes, definitely.
22:06:02 <kc5tja> It doesn't matter what language the OS kernel is written in; as long as it presents a consistent and easily accessible system call interface.
22:08:02 <gilbertdeb> have you seen/heard much about plan9 and inferno?
22:08:07 <gilbertdeb> what do you think of those?
22:08:24 <kc5tja> I think they're neat toys.
22:08:31 <kc5tja> I don't see anything serious coming from them.
22:08:43 <kc5tja> They miss the point about designing operating systems for *people* to use.
22:09:52 <gilbertdeb> how large do you suppose the very first unix was?
22:10:08 <kc5tja> Now, maybe it's true that a Forth OS that exposed Forth to the user wouldn't be any easier, but certainly, there is a huge niche for a single-user, simple, fast, small and easily configured operating system for today's PCs.
22:10:16 <kc5tja> gilbertdeb: About 30KB.
22:10:20 <gilbertdeb> :O
22:10:22 <kc5tja> It only had 33 system calls.
22:10:31 <gilbertdeb> thats pretty fscking small.
22:10:34 <gilbertdeb> what happened to it?
22:10:39 <kc5tja> Remember it had to fit in the memory space of a PDP-7 with only 64K words of RAM.  :)
22:11:24 <kc5tja> What happened to it?  Computer "scientists" got their hands on it, that's what happened to it.
22:13:26 <gilbertdeb> wow.
22:14:07 <kc5tja> See, it's not hard to write a small operating system that is fast and reliable.
22:14:22 <kc5tja> But the desire to sell the latest, greatest, gee-whiz products causes it to grow without bounds.
22:14:43 <kc5tja> The result is a thoroughly unmanagable monstrosity that requires a team of 250 to maintain.
22:14:52 <kc5tja> Did you know that Windows NT is backed by over 1500 programmers?
22:14:55 <kc5tja> Isn't that pathetic?
22:15:11 <gilbertdeb> :O
22:15:37 <gilbertdeb> I say linux should walk over those guys just to show them what :)
22:16:17 <gilbertdeb> so is there any one person who understands the whole thing?
22:16:46 <kc5tja> No
22:16:55 <kc5tja> Just as there is no one person who understands all of Linux.
22:17:16 <kc5tja> Linus is as close as you'll get, and I can guarantee you he has zero knowledge of about half the drivers that ship with Linux (especially the ham radio related stuff).
22:17:42 <gilbertdeb> hehehe
22:18:00 <gilbertdeb> VAX/VMS Internals and Data Structures
22:18:05 <gilbertdeb> is that the book you read?
22:18:09 <kc5tja> Yes, that's it!
22:18:24 <kc5tja> Is it online?  Black book with white lettering on it?
22:18:36 <gilbertdeb> no.
22:18:44 <gilbertdeb> i googled for vms internals
22:18:50 <gilbertdeb> and thats what came up.
22:19:17 <kc5tja> See, this is why I want to write Dolphin in Forth.  It'll help create a nice, small, compact executable for starters.  Secondly, a single person could understand it, maybe with the help of an architectural document explaining how the pieces fit together.
22:19:30 <njd> whats dolphin?
22:19:53 <kc5tja> Third, if something needs changing in the kernel, a single person can do it, *fast*.  I'm willing to bet that a single person can affect the same amount of change in Dolphin as a team of 10 can in Linux.
22:19:59 <kc5tja> Dolphin is the name of my operating system.
22:20:20 <njd> oh true, does it have a website or anything
22:20:25 <kc5tja> Not anymore.
22:20:29 <gilbertdeb> kc5tja: but how would you pretend to understand all the drivers and such it needs?
22:20:32 <kc5tja> It's been years since I last worked on it.
22:20:38 <njd> oh
22:20:44 <njd> what programming language? forth?
22:20:45 <kc5tja> I don't even have the original source code to 0.2 or 0.3 anymore.  I never started 0.5.
22:21:00 <kc5tja> Dolphin was originally written in assembly, then in C, and for 0.5, I'm looking to do it in Forth.
22:21:15 <njd> ah i see
22:21:21 <gilbertdeb> 0.1 and 0.4 don't get a mention?
22:21:41 <kc5tja> Nope.  :)  0.1 was a failed experiment, and 0.4 was ... embarrassing.  :)
22:22:23 <kc5tja> 0.4 was my first attempt to retrofit MMU-based memory management on top of the 0.3 kernel.  The result was that I could only address 4MB of memory because I accidentally locked myself out of the page table data.  :)
22:23:00 <kc5tja> It also lacked memory allocation functions, because I couldn't figure out how to do it effectively in a paged environment.
22:23:19 <njd> guessing it was console-based?
22:23:28 <kc5tja> Not even that.
22:23:34 <njd> oh
22:23:40 <kc5tja> It was purely the kernel.
22:24:04 <kc5tja> I did write a keyboard driver for it, but it only worked in Dolphin 0.3.  But it otherwise didn't do much with it.
22:24:30 <kc5tja> Had I been aware of Forth at the time, I would have written a Forth environment for it.  But I didn't discover Forth for another year afterwards.
22:25:47 <njd> i've just recently started forth. i'm making a brainfuck interepter in it (an idea of Speuler's for me to start off). i've done everything up to the []'s
22:26:02 <kc5tja> Heheh :)
22:26:23 <njd> i don't know what to do for the []'s so yeah
22:26:24 <njd> that's me done
22:27:12 <kc5tja> That's an interesting project, actually.  Although I wouldn't use Brainfuck, I would consider using something like Befunge 2D for the purposes of  teaching Forth.
22:27:33 * njd googles befunge
22:28:40 <gilbertdeb> befunge?
22:28:45 <gilbertdeb> kc5tja: it is so fugly!!!
22:28:57 <njd> looks harder
22:29:01 <kc5tja> Yeah, but it's a challenge to write code in! :)
22:29:15 <kc5tja> And it's ideal for Forth's blocks.
22:29:30 <kc5tja> Though it does set a limit for how big a Befunge program you can execute.
22:31:49 <njd> { copy.f: copy file. usage: copy < infile > outfile  }
22:31:49 <njd> ß[^$1_=~][,]#
22:31:49 <njd> right
22:32:33 <gilbertdeb> kc5tja -> http://ebay3.ipixmedia.com/abc/M28/_EBAY_47e31d4b91d415fa96087063ea33e356/i-1.JPG
22:32:41 <gilbertdeb> does that qualify or is that too old?
22:34:37 <gilbertdeb> btw whats the difference btn vms and openvms ?
22:35:05 <kc5tja> Ahh, the Amiga 500!  :)  That's what I have.
22:35:14 <gilbertdeb> :)
22:35:57 <gilbertdeb> is that a good amiga?
22:36:01 <gilbertdeb> with os and all that?
22:36:07 <kc5tja> OpenVMS is "open", or supposed to be, in the same sense as Unix.  Of course, the community refuses to port it to x86 -- only VAX and DEC Alpha.  If it were available for x86, I might consider giving it a try.  As it is, they're stubbornness prevents me from experimenting with it.
22:36:27 <gilbertdeb> kc5tja: can anyone view its source?
22:36:55 <kc5tja> Amiga 500s are iffy with the OS; they were made in an era back when AmigaOS 1.2 and 1.3 were common.  The modern OS might not run on the machine without some hacking on the motherboard (the ROM socket needs a jumper from the microprocessor to a pin that isn't connected on the socket).
22:37:01 <kc5tja> gilbertdeb: I haven't checked.
22:37:11 <kc5tja> My Amiga 500, for example, has just such a hardware hack.
22:37:24 <kc5tja> Amiga 3000s and 4000s have native support for AmigaOS 2.04 and later.
22:39:09 <gilbertdeb> is the 500 the machine sassenrath worked on?
22:41:22 <kc5tja> No; he worked on AmigaOS, not any hardware per se.
22:41:37 <gilbertdeb> yes I mean is his os on this machine?
22:41:42 <kc5tja> But when he created AmigaOS, it was back in the days of the Amiga 1000 (the first Amiga to be made; in fact, it's the only Amiga without a number on the case)
22:41:47 <kc5tja> Yes
22:42:17 <kc5tja> The exec.library for the Amiga 4000 is virtually unchanged from the original found on the Amiga 1000.
22:42:37 <gilbertdeb> amiga 500 sounds < than amiga 1000
22:43:08 <kc5tja> It's actually better.
22:43:24 <kc5tja> The Amiga 500 is the "home computer" version of the Amiga 2000, which was intended to be a "business computer."
22:43:53 <kc5tja> The only thing the Amiga 500 lacks over the Amiga 2000 is the support for multiple expansion slots (it has only one slot, like the Amiga 1000).
22:46:10 <gilbertdeb> hmmm. ever heard of the amiga guru book?
22:46:49 <kc5tja> Yes.
22:46:52 <kc5tja> I never owned it though.
22:47:03 <kc5tja> But it contained a listing of all the system error codes (GURU Mediation alerts)
22:47:07 <kc5tja> And what they meant.
23:00:16 <natty> bloody hell. So I'm 99% sure the bogus data I'm getting is caused by noise
23:00:53 <natty> I've got a ribbon cable with a bunch of TTL lines in it. I've got a ground line inbetween each data line. But I'm still getting big noise spikes. What can I do?
23:08:01 <kc5tja> natty: Is the board wire-wrapped or is it printed circuit board?  Also, how fast is data being transferred?
23:08:58 <natty> PCB, groundplane construction, pretty decent. I'm pretty sure the crosstalk is occuring in my ribbon cable. 
23:09:09 <natty> There's 4 lines carrying the signal from a 4 bit counter
23:09:12 <natty> and theres one trigger line
23:10:00 <natty> When the counter rolls over from 15 to 0 it induces a pretty big spike on the trigger line, which I suspect is why the PIC is reading random zeros interspersed with the correct values
23:10:15 <natty> it makes sense, it just sucks
23:10:24 <natty> maybe some decoupling caps
23:12:24 <natty> how do you keep the crosstalk down on a ribbon cable?
23:13:00 --- nick: natty -> natzzz
23:14:07 <kc5tja> doh, he left.
23:14:31 <kc5tja> Though I don't have an answer.  A ribbon cable is supposed to be pretty well shielded as long as you have interleaved ground lines... :(
23:17:35 --- join: karingo (karingo@196.portland-03-04rs.or.dial-access.att.net) joined #forth
23:19:12 <gilbertdeb> kc5tja: how small do you reckon linux could be with some refactoring and re-doing?
23:19:26 <gilbertdeb> kernel, gui, servers, etc.
23:22:24 <kc5tja> I'd say the whole system could fit within 10MB of harddrive space.
23:22:39 <kc5tja> But such a system wouldn't be Linux anymore.
23:24:53 <natzzz> I'm still here sorta, just on my way to be
23:24:54 <natzzz> e
23:24:55 <natzzz> d
23:27:26 <natzzz> it's a pretty narrow spike, but it only has to be 10ns long to trigger the PIC
23:28:53 <kc5tja> Yeah, I don't know.  :(
23:28:59 <kc5tja> I would say to add more decoupling on it.
23:29:08 <kc5tja> One thing's for sure, ribbon cable isn't coaxial cable.  :)
23:29:33 <kc5tja> Interesting.  I accidentally found a page containing GNU software for programming PIC chips.
23:29:39 <natzzz> Yup
23:29:40 <kc5tja> http://www.gnupic.org/i_compile.html
23:29:45 <natzzz> I think GCC has a PIC target
23:30:01 <natzzz> I know theres at least one PIC forth compiler
23:30:07 * kc5tja nods
23:30:54 <natzzz> then again maybe it doesn't
23:35:58 --- join: bwb (~bwb@ip68-4-121-108.oc.oc.cox.net) joined #forth
23:39:28 --- quit: gilbertdeb (Read error: 110 (Connection timed out))
23:44:54 <kc5tja> Well, I should be going to bed soon.  I need to get up for school tomorrow.
23:45:49 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK")
23:59:59 --- log: ended forth/03.04.20