00:00:00 --- log: started forth/04.05.20
00:17:21 <kc5tja> Yep.
00:17:29 <kc5tja> Wow.  I'm impressed.
00:17:50 <kc5tja> There is a minority position that states that software-based fault isolation techniques are *far* preferable to hardware-based techniques.
00:18:56 <kc5tja> By that, I mean these folks are advocating operating systems which use hardware MMUs *at most* for virtual memory; actual resource *protection* is done entirely via software (through various techniques, such as sand-boxing, or via load-time formal proof verification).
00:20:08 <kc5tja> And here I thought I was the only one who felt this way.
00:20:36 <kc5tja> I'm glad to see official position papers which exist to support my claims, with more rigorous data to back them (and by extension, me) up.
00:20:41 <kc5tja> Anyway, I'm going to head off to bed.
00:20:51 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK")
00:25:36 --- quit: I440r (Excess Flood)
00:26:22 --- join: I440r (~mark4@168-215-246-243.gen.twtelecom.net) joined #forth
00:27:11 <warp0b00> can i run a scsi320 drive on scsi160
00:42:46 <fridge> I'd say yes
00:42:46 --- quit: madgarden (Read error: 104 (Connection reset by peer))
00:42:52 <fridge> but with nothing to back me up whatsoever
01:11:11 <Herkamire> quit bedtime
01:11:16 --- quit: Herkamire ("bedtime")
02:06:01 --- join: AldoBrasil (~aldo@200165176239.user.veloxzone.com.br) joined #forth
02:06:10 <AldoBrasil> good day/night
02:23:03 <mur> you too
03:12:14 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth
03:59:29 --- nick: rO|_ -> rO|
05:12:43 --- quit: AldoBrasil ("Finalizando Cliente")
06:33:03 --- join: madwork (~madgarden@derby.metrics.com) joined #forth
06:34:26 <madwork> Gree tings!
06:34:44 <I440r> ?
06:34:49 <I440r> oh lol
06:37:20 <madwork> Heh
06:39:49 <Robert> H i
06:44:06 <madwork> Robert, gree tings.
06:44:20 * Robert eats green things.
06:46:31 <madwork> Yay, I found a bug in some software here at work, and it turns out that the behaviour I need to implement in order to fix it involves a stack. :D
06:46:50 <I440r> lol
06:47:00 <Robert> Hehe
06:47:47 <madwork> Printers are suprisingly fun to work with, especially compared to industrial networks (my previous field).
07:02:24 --- quit: fridge ("Leaving")
08:04:49 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth
08:04:58 --- mode: ChanServ set +o kc5tja
08:12:19 <Robert> Hi kx
08:12:21 <Robert> Er, kc5tja 
08:12:24 <kc5tja> Howdy
08:12:34 * kc5tja is working on a FAQ for the Kestrel page.
08:13:03 <kc5tja> And, I'm thinking that using saoftware fault isolation techniques, I can support some fairly non-trivial operatng system architectures on the Kestrel as-is, too.
08:13:30 <kc5tja> The MISC chip ought to be fast enough to substitute the use of an MMU with a purely software-based memory management technique.
08:14:19 <kc5tja> Segment-based virtual memory would be used, and although it's not nearly as fast as page-based virtual memory, it's also true that program state size won't be nearly as big either.  So it ought, by my estimations, to come out a wash.
08:21:57 <kc5tja> It's interesting to note that this same technique can apply to other, "less fortunate" microprocessors too, like 68000, 65816, and 6502.  However, the run-time overhead of imposing a purely software-based memory protection mechanism at such slow clock speeds that they run at would probably be prohibitive.
08:22:16 <kc5tja> But it IS possible, and the opportunities are quite appealing.
08:22:47 <Robert> Speaking of home-made computers, I read of a 50s computer made with about 150 (highly unreliable) Ge transistors.
08:23:38 <kc5tja> It probably didn't do very much.  :)  In fact, I'm pretty sure it probably didn't address any memory at all.
08:23:54 <Robert> But it sounds like Kestrel will be a little better than that. Unfortunately I don't know very much about system design. :(
08:24:38 <Robert> I'm not so sure, I think it did. Seems like it used quite a lot of diodes.
08:24:58 <kc5tja> Actually, the Kestrel will have several million transistors in its design.
08:24:58 <kc5tja> :)
08:25:21 <kc5tja> (if I could design my own chips at the wafer level, then obviously I'd cut back on all these transistors.)
08:25:53 <Robert> Hehe. It doesn't require that much power, does it?
08:25:56 <Robert> The CPU that is
08:26:02 <kc5tja> I do not know.
08:26:22 <Robert> I mean, compared to the monitor and other devices it shouldn't be a lot.
08:26:41 <kc5tja> It'll definitely require way more power than it should, for two reasons: the fact that it's synchronous logic, and the fact that it's implemented in an FPGA, instead of all custom logic.
08:26:55 <kc5tja> Monitors compare with light-bulbs for power -- 50W or more.
08:27:03 <Robert> Yeah.
08:27:08 <kc5tja> There is no way in hell that the FPGA will ever compete with that.
08:27:16 <Robert> And I doubt even that CPU will draw 10A from 5V. :FD
08:27:29 <kc5tja> But, the CPU will still draw more power than, say, a 6502 or 65816.
08:27:32 <Robert> Did you run it on 12MHz ?
08:27:43 <kc5tja> I didn't run anything anywhere.
08:27:49 <Robert> Will you run... *
08:28:01 <Robert> And how many clocks per instruction?
08:28:22 <kc5tja> The MISC will run at 25.175MHz, not 12.58MHz like the 65816.  Unlike the 65816, the MISC is not limited in clock speed (well, it IS, but that speed limit ought to be in the 50MHz region)
08:28:48 <kc5tja> As with all MISCs, it will execute one instruction per clock cycle.
08:29:06 <Robert> Er, did I miss something here? Did you change the main CPU?
08:29:06 <kc5tja> Like the 65816, it will also fetch or store one word of memory per clock cycle too.
08:29:22 <kc5tja> Therefore, it'll make a very high performance microprocessor all things considered.
08:29:28 <Robert> Ah, great. 
08:29:46 <kc5tja> If anything slows this down, it'll be the SDRAM interface.
08:34:02 <kc5tja> Note that software fault isolation techniques *will* cause the CPU to run applications slower, since it's intrusive into the software itself.
08:34:45 <kc5tja> Fortunately, however, only those instructions which the fault isolator aren't sure of get isolated.  Those that are known, by static analysis (which happens to be the overwhelming majority in a typical Forth application, or even C application for that matter) are NOT affected, and can run at full speed.
08:35:25 <kc5tja> In the worst case, software fault isolation can make a typical write operation go from 1 cycle to 4 cycles to complete (5 if you're using the post-increment instructions).
08:36:44 <kc5tja> OTOH, this is fertile ground to explore the concept of proof-carrying code, so that when the machine language code is placed in RAM, the proof checker can be used to assert the correctness of the loaded code, so that the effects of sandboxing can be minimized.
08:37:48 <kc5tja> These are all techniques that can easily be applied even to the humble 8088 CPU, but alas, the instruction set complexity is woefully out of hand compared to the FTS1001.  The 1001 makes these techniques seem so utterly trivial in comparison.
08:38:54 <kc5tja> The only thing that can't be accomplished with software-based fault isolation is page-based virtual memory, which is a pity.  But if you're happy with a rigorous subset of segment-based protection and virtual memory, then you can actually get by entirely without an MMU, and still reap rather significant benefits from it.
08:39:17 <qFox> kc5tja> ret, call... dont xor do they? :p
08:39:25 <kc5tja> CALL XORs, of course.
08:39:31 <Robert> How complex would those proof-generators (and checkers) become?
08:39:33 <qFox> uhm skip call
08:39:34 <kc5tja> It takes its effective address from the instruction just like JA.
08:39:39 <kc5tja> RET does *not* XOR.
08:39:44 <qFox> k
08:39:51 <Robert> I mean, if the compiler for the system takes 10 years to develop... :)
08:40:20 <kc5tja> What???
08:40:42 <kc5tja> Robert: That came out of left field for me.  I'm not understanding.
08:40:50 <Robert> Hehe.
08:41:09 <Robert> You were talking about proof-carrying code, but maybe it's just that I misunderstood that concept.
08:41:30 <kc5tja> No.  You understood correctly.
08:41:50 <kc5tja> Proof-carrying code is program code that carries a formal proof specification of the compiled code along with it.
08:42:08 <Robert> And how complex does that get in practice?
08:42:14 <kc5tja> The proof checker verifies the code against the proof specification via static analysis.
08:42:26 --- join: XeF4 (~xef4@a80-186-152-244.elisa-laajakaista.fi) joined #forth
08:43:15 <kc5tja> I have no idea.  I've never done anything of this sort before.  But it's doable, researchers have achieved results, and run into headaches due in large part to the problems surrounding the liberal instruction sets of the CPUs they're working with.
08:43:41 <kc5tja> The FTS1001 has no such liberal instruction set: one instruction opcode, one operation.  The semantics are very precise -- JUST what the doctor ordered for proving software.
08:44:15 <Robert> Hehe, okay.
08:44:32 <kc5tja> But it's equally true that, if you don't have PCC, or the proof doesn't match the code you loaded, then you can still resort to sandboxing techniques, at the cost of run-time cycles.
08:44:34 <Robert> Will you try to implement it before the release, or is it just a "maybe"-project?
08:45:00 <kc5tja> And even then, only for those instructions that aren't trust-worthy.  Trusted instructions (those that have been deduced via static analysis to be well-behaved) needn't be sandboxed.
08:45:21 <kc5tja> I intend on releasing it, but not as an initial release.
08:45:27 <kc5tja> (sandboxing version, not PCC)
08:45:45 <kc5tja> I'll leave it to those more mathematically apt than I to implement proof-checking.
08:46:19 <Robert> Sounds like a good idea, if you want to keep your sanity
08:46:53 <kc5tja> Sandboxed applications can incur up to 20% overhead, in the worst-case.  To the software, it looks just like you're using very slow RAM.
08:47:01 <kc5tja> But on average, only 5% is incurred.
08:47:13 <kc5tja> Many CPU-intensive applications only get 1% or so.
08:52:15 <XeF4> kc5: is the online stuff for the FTS1001 about the new or old Kestrel CPU?
08:52:39 <kc5tja> The material on my www.falvotech.com/kestrel.html page is new.
08:52:44 <kc5tja> The Wikis haven't been updated.
09:02:02 <XeF4> looks very nice indeed
09:02:43 <kc5tja> Thanks.  :)
09:02:56 <XeF4> though how do you manage single-cycle ROTs?
09:03:06 <kc5tja> The ROT instruction?
09:03:10 <kc5tja> :)
09:03:24 <XeF4> that
09:03:34 <kc5tja> That's how I manage it.
09:03:39 <kc5tja> It's an intrinsic instruction.
09:04:07 <XeF4> yes, but in hardware how is it done?
09:04:09 <XeF4> just curious
09:04:16 <kc5tja> Same techniques as anything else.
09:04:30 <kc5tja> The state of the results of all instructions are computed before the end of the clock cycle.
09:04:43 <kc5tja> The instruction merely selects which one gets clocked into all the registers next cycle.
09:04:59 <XeF4> same as F21 then
09:05:09 <kc5tja> It's the only way to do it.
09:07:38 <XeF4> kc5: *nod* I was just imagining the top 1 or 2 stack items in registers and the rest in a circular buffer
09:07:53 <XeF4> and trying to imagine the interconnect required for doing an atomic ROT on those
09:10:20 <kc5tja> It's just the same as a 3-bit ring-configured shift register, replicated for as many bits as there are in a stack cell.
09:11:32 <XeF4> ah right of course, you latch in the whole top 3 items
09:11:38 <XeF4> got it :)
09:12:27 <kc5tja> The entire data stack of the FTS1001 exists inside the chip.
09:16:44 * qFox votes for an additional stack
09:16:47 <qFox> ;)
09:16:59 <kc5tja> Access denied.
09:17:05 <kc5tja> I do not have infinite transistors to work with.
09:17:12 <kc5tja> The CPU is already "bloated" from a MISC point of view.
09:17:19 <qFox> hehe i know :)
09:54:36 <kc5tja> All righty!
09:54:42 <kc5tja> The FAQ is now on the site.
09:55:08 <kc5tja> Took me long enough, but it's there.
09:55:14 <kc5tja> Anyway, I have to get to work.  Adios!
09:55:21 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK")
10:15:02 --- join: TheBlueWizard (TheBlueWiz@ip-207-198-223-245.nyc.ny.FCC.NET) joined #forth
10:15:03 --- mode: ChanServ set +o TheBlueWizard
10:19:50 <mur> päivää
10:20:26 <XeF4> pavvõ
10:20:47 <TheBlueWizard> moi :)  my phone line is now fixed...I had to call in a phone repairman and he came in earlier this morning to fix that....
10:21:11 <TheBlueWizard> XeF4: is that an Estonian word for "day"?
10:21:45 <XeF4> Livonian
10:22:14 <TheBlueWizard> oh...hmm...a rare (dying, I think) language
10:23:11 <mur> # is octothorp
10:23:59 <mur> hehe, interesting idea, to make comments so difficult to read, that it's easier to read the source code :D
10:24:53 --- join: Herkamire (stjohns@h000094d30ba2.ne.client2.attbi.com) joined #forth
10:25:02 <TheBlueWizard> are you referring to "# is octothorp" thing, mur?
10:25:36 <mur> hmm
11:06:55 --- quit: I440r ("Leaving")
11:28:13 <Herkamire> anybody here have a picture of themselves on the web that you'd be willing to put a link to on this page: http://herkamire.com/jason/forth_channel_regulars
11:35:17 * XeF4 ponders if he wants to put a link to the few pictures of himself he knows of online
11:42:50 --- quit: Herkamire ("resetting router brb")
11:43:10 --- join: Herkamire (stjohns@h000094d30ba2.ne.client2.attbi.com) joined #forth
11:45:27 <XeF4> http://low.fi/~quaz/DSC00065.JPG
11:45:44 <XeF4> I am the leather jacketed one sitting (mostly) asleep by the Amstrad CPC
11:45:54 <XeF4> probably I will regret this when it ends up in google image search
11:46:44 <qFox> rename it.
11:46:48 <qFox> easily fixed
11:47:16 <XeF4> that's not on my site :)
11:52:13 <qFox> then... its not
11:53:49 --- join: doelie (~tom@200.56-200-80.adsl.skynet.be) joined #forth
11:58:23 --- join: tgunr (~davec@user-2ivflju.dialup.mindspring.com) joined #forth
12:01:38 --- join: eileod (~tom@200.56-200-80.adsl.skynet.be) joined #forth
12:01:52 --- quit: eileod (Client Quit)
12:22:17 --- join: I440r (~mark4@168-215-246-243.gen.twtelecom.net) joined #forth
12:28:16 <TheBlueWizard> hiya I440r :)
12:29:48 --- join: crc (~Charles_C@0-1pool176-1.nas6.philadelphia1.pa.us.da.qwest.net) joined #forth
12:32:44 <rO|> Ladies and Gentlemen, please welcome:  crc
12:33:14 <Herkamire> yay! <clap clap clap>
12:33:19 <rO|> wb crc
12:33:25 <crc> Hello ro|
12:33:50 <rO|> crc: how are you doing?
12:34:06 <crc> Not too bad. 
12:34:28 <crc> Busy working, but I'm finally making enough to pay the bills :-)
12:34:53 <rO|> webstuff?
12:34:56 <crc> I'm also continuing to improve RetroForth in my (small) amounts of spare time
12:35:37 <XeF4> crc: are you tcn?
12:35:40 <crc> Overnight @ a Target store, basic office work for an insurance firm, soon a website for the insurance place
12:35:47 <crc> No, I'm not tcn
12:36:14 <crc> Why?
12:36:48 <XeF4> just curious
12:37:21 <crc> Ok
12:38:16 * crc is happy. RetroForth finally supports inline strings!
12:39:21 <slava> hi all
12:41:16 <rO|> hi slava
12:41:19 --- quit: crc (Read error: 54 (Connection reset by peer))
12:41:23 <slava> whatcha coding?
12:42:04 <rO|> hot stuff ;-)
12:42:41 --- join: crc (~Charles_C@0-1pool176-37.nas6.philadelphia1.pa.us.da.qwest.net) joined #forth
12:43:23 <rO|> slava: oh, sorry, you meant the others, right? ;-)
12:44:19 <rO|> crc: looks like you're on dialin
12:44:26 <crc> Yup.
12:44:46 <crc> At least for now.
12:45:06 <crc> I hope to have a DSL or cable modem connection later this year
12:45:58 <crc> (The phone cord is currently strung across the room, so people trip on it and pull it out of the wall :-()
12:46:41 <rO|> crc: too much chatting or even multimedia isn't productive anyway ;-)
12:47:34 <crc> True. But I could *host* retroforth.org if I had an always connected internet line
12:48:42 <crc> And I could stop using Windows at last. (Linux does not support the modem in my laptop)
12:50:38 <rO|> crc: ack
12:54:18 --- quit: I440r ("Leaving")
12:55:11 <rO|> was pleased to meet rare guest crc
12:55:37 <rO|> cya (back2work:)
12:55:42 <crc> cya
13:00:28 --- join: I440r (~mark4@168-215-246-243.gen.twtelecom.net) joined #forth
13:00:28 --- quit: I440r (Client Quit)
13:02:06 --- join: I440r (~mark4@168-215-246-243.gen.twtelecom.net) joined #forth
13:04:41 <Robert> Hey
13:04:47 <Robert> How far did you come on the DNS code?
13:04:47 <slava> hey
13:04:57 <Robert> I know NOTHING about it.. :/
13:04:58 <Robert> Hi slava 
13:05:03 <crc> hey
13:05:52 <Robert> And hi crc 
13:06:48 <I440r> me ?
13:19:05 <Robert> Yep, you!
13:19:17 <Robert> Already forgot you hired me for unpaid slavery? :P
13:20:10 --- quit: crc (Read error: 54 (Connection reset by peer))
13:25:01 <I440r> lol
13:25:19 <I440r> i didnt get very far but look in src/ext/resolver.f or something
13:25:46 --- join: gNoam (NoamTuring@Orleans-ppp42591.sympatico.ca) joined #forth
13:26:19 --- part: gNoam left #forth
13:31:04 --- part: doelie left #forth
13:34:54 <Robert> OK
13:35:02 <lalalim> I440r: you're working on networking for forth?
13:35:15 <I440r> i already have some basic stuff done
13:35:52 <lalalim> nice
13:35:57 <TheBlueWizard> cool
13:35:59 <I440r> any second now ill have a bot in here
13:36:01 <lalalim> which forth implementation are you using?
13:36:04 <I440r> written in isforth
13:36:06 <I440r> my own
13:36:09 <I440r> isforth.clss.net
13:36:16 <lalalim> cool
13:36:32 --- join: [Forth] (~Forth@168-215-246-243.gen.twtelecom.net) joined #forth
13:36:35 <I440r> there
13:36:50 <I440r> [forth] is a do nothing irc bot written entirely in forth using isforth
13:37:09 <lalalim> wow nice
13:37:29 <I440r> not really - i need to totally rework the numerics part lol
13:37:41 <I440r> and theres no facility for PRIVMESG yet :)
13:37:44 <Callidus> Will we be able to give it commands using forth syntax?
13:37:51 <I440r> eventually
13:37:59 <I440r> that was the whole idea behind the bot
13:38:07 <Callidus> It's PRIVMSG, btw, which I mention because you'll probably want to get it right when you implement it.  ;)
13:38:10 <I440r> which others subsequently implemented in a lesser fassion
13:38:34 <Callidus> I played with that concept, once.
13:38:37 <I440r> i intend any user that i add to the bot to be able to write forth code and execute PROGRAMS and have the output directed to the channel
13:38:38 <Callidus> But I wasn't writing it in Forth.
13:38:54 <I440r> it will also be an isforth info type bot
13:39:31 <I440r> but right now she isnt very high on the todo list heh
13:45:12 <slava> i have a really crappy irc bot too
13:45:19 <slava> all it does is remember factoids, and say hi to people that join
13:45:44 <I440r> [forth] wont "remember" factoids people state in channel
13:45:52 * slava is currently coding a B-Tree database that indexes records by 8-byte keys
13:45:54 <slava> very nice and simple :)
13:46:26 <I440r> in forth ??? :)
13:46:33 <slava> in my lang
13:46:39 <I440r> aha
13:46:51 --- join: rO|_ (rO|@pD9545811.dip.t-dialin.net) joined #forth
13:50:05 <I440r> err slava can we make "undo" undo cursor movements too? i mean when i do an undo the cursor isnt in the same location as it was when i did the "do"
13:50:52 <slava> I440r, undo moves the cusor to the position of the edit
13:51:15 <I440r> i know
13:51:31 <I440r> because your trating an undo as a "redo"
13:51:51 <I440r> which it isnt always
13:52:10 <TheBlueWizard> [Forth] *will* remember me....cuz I robo-hypnotize it ;)
13:53:21 <I440r> hte higher your IQ the harder you are to hypnotize and [forth] has an iq of infinity to the power of infinity :)
13:55:06 <I440r> i mean your treating an undo as an edit and most times an undo is an UN-edit
13:55:43 <I440r> so the cursor (imho) should end up in exactly the same location it was when the edit was originially made
13:56:06 <slava> it used to be that way in jedit 3.x but i could never get it completely right
13:56:15 <slava> there were issues with multiple text areas, redo, and others i can't reclal
13:56:23 * TheBlueWizard wonders whether I440r is insinuating that [Forth] is a god
13:56:36 <I440r> no just super smart :)
13:56:59 <I440r> multiple edit areas should have their own undo buffers shouldnt they ?
13:57:12 <slava> each file has an undo buffer actually
13:57:17 <I440r> i can tell this behaviour is definatly NON trivial lol
13:59:40 * TheBlueWizard also wonders whether he is deemed dumb in comparison to [Forth] in I440r's estimate
13:59:55 <I440r> lol
14:00:10 * I440r will make like [forth] and keep his mouth shut :)
14:00:12 <XeF4> I440r: it's also hard to hypnotize someone who is retarded
14:00:12 <I440r> hehe
14:00:23 <I440r> xef4 :/
14:00:56 <I440r> is it possible to turn auto-indent off totally ?
14:01:12 <I440r> it auto-indents wrong when it tries to indent on an unbraced if statement
14:01:18 <I440r> if (x = 1)
14:01:22 <I440r>   blah();
14:01:46 <I440r> [X] stuff here cursor at x and hit enter - indents to level of blah() above
14:02:25 <I440r> im FIXING all the unbraced statements in this source, anyone who doesnt brace EVERY SINGLE statement is a moron.
14:02:34 <I440r> if (x = 1)
14:02:39 <I440r>   for (y = .... )
14:02:47 <I440r>     if (z = 3)
14:02:52 <I440r>     switch (foo )
14:02:55 <I440r>        ...
14:03:07 <I440r> hate that shit
14:04:40 --- quit: rO| (Connection timed out)
14:16:42 <warp0b00> sup I440r
14:16:47 <I440r> :)
14:16:53 <I440r> editing C sources sucks
14:16:57 <I440r> even when your being paid to do it
14:16:59 <warp0b00>  yeah it does
14:17:14 <warp0b00> i have to write my language in C and i don't really want to
14:18:15 <TheBlueWizard> some C code sux...some are well written...depends.... :-/
14:18:30 <XeF4> I440r: my rule is that unbraced blocks should be on the same line as the statement they belong to
14:18:33 <I440r> no c sources look nice, i HATE c
14:19:02 <I440r> xef4 thats still dangerous. someone can come along and not SEE that and you can end up with the perfectly legal...
14:19:08 <I440r> if (x = 1) y = 2;
14:19:10 <I440r> {
14:19:10 <XeF4> i.e. if a statement is too short to warrant a linefeed, it doesn't warrant braces either
14:19:15 <warp0b00> the thing that bothers me the most about C is that arrays are wacked out
14:19:17 <I440r>   this is not part of the if statement
14:19:18 <I440r> }
14:19:31 <I440r> xer4 i disagree 
14:19:41 <I440r> err xef4 even
14:19:53 <XeF4> I440r: then they would have to be blind and not even then, because a screen reader would make the intent obvious :)
14:20:06 <I440r> screen reader ?
14:20:26 <I440r> no. i cannot disagree MORE on this issue, all statemnts should be braced. no exceptions
14:20:32 <warp0b00> a program that reads the screen [aloud]
14:20:38 <XeF4> I mean one would have to be blind not to see the y=2; and if they were blind they wouldn't be reading it off a monitor anyway
14:20:48 <I440r> it makes it blatantly obvious what is and is not part of the control block
14:21:28 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth
14:21:48 --- join: lalalim_ (~lalalim@p508ABB5E.dip.t-dialin.net) joined #forth
14:22:09 <Callidus> I440r: what?  Why would someone insert a block after a semicolon-terminated statement?
14:22:16 <Callidus> That's not ambiguity, that's idiocy.
14:22:32 <I440r> callidus thats a trivial example, there are definatly NON trivial examples
14:22:59 <Callidus> I'd like to see one, because I can't think of any.  :)
14:23:05 * TheBlueWizard agrees with I440r re: braces after control statements....except when writing a throwaway code, or when writing very small function code (braces seem to give more visual "noise" sometimes ;)
14:23:13 <Callidus> The only time it becomes a problem is with something like:
14:23:14 <Callidus> if (foo)
14:23:14 <I440r> if i wasnt using jedit here i would have a great deal of difficulty deciding what code blonged with what control structure in some parts of the soruces im editing
14:23:18 <XeF4> I can see like:
14:23:20 <Callidus>   if (bar)
14:23:24 <XeF4> while(poll());
14:23:25 <Callidus>     something;
14:23:28 <XeF4> statement;
14:23:30 <Callidus>   else
14:23:33 <Callidus> And so on.
14:23:34 <I440r> xef4 THAT is very bad!
14:23:40 <I440r> whle (... )
14:23:41 <I440r>   ;
14:23:52 <I440r> do it that way. on those i can accept NO braces 
14:23:55 <I440r> because theres no content
14:24:04 <Callidus> I was going to ask.
14:24:07 <I440r> never put the brace on the end of the while statement
14:24:54 <I440r> Callidus, there are times when unbraced statements can become very difficult to read, so to prevent THOSE instances i say always brace all statements
14:25:14 --- quit: lalalim (Read error: 60 (Operation timed out))
14:25:15 <I440r> it also means that if someone else comes along and edits your code he/she is less likely to make an error
14:25:20 <Callidus> In cases of potential ambiguity, I agree.
14:25:31 <Callidus> But that's not *every* case.
14:26:03 <I440r> someone might come along later and add an else statement to yoru existing if statement
14:26:22 <I440r> always brace. saves you trouble later on
14:27:43 <TheBlueWizard> oh, one other exception that I notice myself practicing:   if (...) break;     or   if (...) continue;    or    if (...) return ...;
14:28:21 <I440r> no because someone might want to add stuff to the body of those statements later
14:28:29 <I440r> or an else part etc etc etc
14:29:15 <Callidus> I440r: that's their responsibility.
14:29:31 <I440r> no. 
14:29:33 <Callidus> And it's an obvious programming issue.
14:29:47 <I440r> when your workin in a multi developer environment its all developers responsability
14:29:59 <Callidus> It's blatantly obvious when there's only one statement in a block.
14:30:01 <TheBlueWizard> well, that's about the only exceptions that I usually make....and those are typically trivial to add braces anyway, for me at least
14:30:02 <I440r> my code should not encourage mistakes on your part
14:30:11 <Callidus> A beginning C programmer knows to add braces if he adds a statement.
14:30:23 <Callidus> brb
14:30:31 <I440r> if ( .......................................................) z = 6;
14:30:36 <slava> a neat solution would be to store pre-parsed source
14:30:44 <slava> so that display is entirely up to the editor
14:30:45 <I440r> only my editor window isnt that wide so i just dont notice the ;
14:30:50 <I440r> ..
14:32:04 <XeF4> pre­parsed C would be "interesting"
14:33:22 <I440r> lol
14:33:52 <I440r> i would argue against adding intelligence to a compiler in order to protect a developer from himself
14:34:14 <I440r> foot in self shoot should be allowed, just not encouraged
14:35:23 <I440r> slava i asked if there was a way to totally disable auto indent ?
14:36:23 <XeF4> i440r: gcc has an impressive amount of such intelligence already
14:36:25 <slava> I440r, yes
14:36:34 <slava> I440r, rebind enter and tab to 'insert newline' and 'insert tab'
14:36:35 <XeF4> that encourages all sorts of jerry rigging to get the compiler to shut up
14:36:38 <I440r> xef4 i rest my case :)
14:37:02 --- quit: tathi (""la la la la la...stupid coding style arguments are booring..."")
14:37:04 <I440r> slava err thats a complex way of doing it lol. 
14:37:27 <slava> I440r, you're a forth programmer complaining about something being complex? hehe
14:37:31 <I440r> now i have to go hunt for where key bindings are stored. look at how to rebind them and then look for the exact names of the things i need to rebind them to :)
14:37:40 <I440r> slava forth is VERY VERY VERY simple
14:37:45 <slava> I440r, its very easy
14:37:48 <slava> I440r, utilities-global options-shortcuts
14:37:59 <slava> I440r, find the commands 'insert newline' and 'insert tab' in the list
14:38:00 <I440r> you can implement a very powerfull forth compiler in a very small number of words
14:38:03 <slava> click on them
14:38:08 <slava> it will ask you to press a key to find to
14:38:10 <slava> press ENTER or TAB
14:38:11 <I440r> you can write a very non minimal forht compiler in under 24 hours
14:38:15 <slava> the old bindings will be automatically forgotten
14:39:36 <I440r> ok :)
14:40:44 <I440r> i hate this guys coding style
14:41:03 <I440r>  if ( x=1 )  looks like shit lol
14:41:08 <I440r> i would much rather see
14:41:12 <I440r>  if (x = 1)
14:41:32 <XeF4> or if((x=1)) to shut gcc up :)
14:41:52 <I440r> y would gcc complain ?
14:42:10 <XeF4> because = instead of == is a common typo
14:42:12 <I440r> actually i wish all linux people would use -Wall and -Werr
14:42:19 <I440r> oh yea lol
14:42:34 <I440r> it was in my case above too lol
14:42:36 <I440r> i hate c
14:43:29 <XeF4> come to think of it, if(x=1) is stupid
14:43:34 <XeF4> x=1;
14:43:35 <XeF4> blablabla
14:43:43 <I440r> agreed
14:43:58 <TheBlueWizard> I agree...plus some coders get so annoyed by this that they would write if (1 = x) instead, where the compiler would choke on, catching bugs this way
14:44:00 <I440r> if (some_function(some_other_functio)))  <- he does this alot too
14:45:01 <XeF4> that's perfectly reasonable
14:45:13 <I440r> ok, i turned off auto indent and its still partially enabled
14:45:29 <I440r> its still trying to automatically align the closing braces when i type them in
14:45:59 <I440r> xef4 its not totally unreasonable but he abuses it and it can obfuscate whats going on
14:46:04 <I440r> specially when you do something like
14:46:22 <I440r>  if (xxx(..) || yyy(...))
14:46:25 <I440r> {  do this
14:46:26 <Callidus> I440r: I'm about to really piss you off.
14:46:27 <I440r> }
14:46:30 <Callidus> http://austinhair.org/lustrate.c
14:46:59 <I440r> because in the above yyy(...) is called first and if IT fails the if test then xxx is never called
14:47:15 <slava> I440r, open <jedit install>/modes/c.xml (or cplusplus.xml) and comment out all auto indent-related properties then
14:47:30 <slava> I440r, select the lines inside the <PROPS> tag mentioning indent, and press C+e C+c
14:49:09 <I440r> Callidus, eek your using k&r bracing 
14:49:19 * I440r thwaps Callidus with the isforth manual (i have one now :)
14:49:40 <slava> I440r, so what are the goals for isforth?
14:50:08 <I440r> well once i have a meta-compiler and assembler im going to start work on a console based web browser and a complete mud server
14:50:23 <slava> mud server? cool!
14:50:34 <I440r> the mud will be a LIVE forth compiler. so the immortals will be able to edit the game online 
14:50:37 <I440r> using forth
14:50:46 <slava> the mortals should have a 'sandbox' too
14:50:48 <I440r> users will be sealed into the user vocabulary
14:50:58 <slava> eg if you own a house, you should be able to build stuff inside your own house
14:51:13 * slava builds himself some immediate words and a kitchen table
14:51:16 <I440r> that sounds like a cool idea :)
14:51:28 <I440r> except it would be subject to abuse
14:51:32 <slava> each location in the world could be a vocabulary or something
14:51:40 <I440r> slava yes.
14:51:41 <slava> well, try and design it so that its hard to abuse
14:51:50 <I440r> well. not as isforth currently stands.. but eventually
14:52:28 <I440r> i plan on putting ALL vocabularies in their own buffers, each one will have their own "here" and "hhere"
14:53:12 <I440r> slava you buy a house. you are an imm within you house. you develop code so that when poor unsuspecting noobie enters your house all his stuff gets deposited into a room only you can enter
14:53:27 <I440r> heh
14:53:51 <I440r> also i dont like switch statements or indents greater than two spaces
14:54:25 <I440r> and i think anyone who uses any form of conditional compilation needs a new career :P
14:54:51 <I440r> that code is unreadable to me. :/
14:55:03 <I440r> more comments might make it slightly easier to read :)
14:55:09 <XeF4> Callidus: should I seek help if I consider that sample to be 
14:55:12 <XeF4> oops
14:55:17 <XeF4> Callidus: should I seek help if I consider that sample to be quite readable
14:55:18 <slava> I440r, don't allow words from untrusted sources to manipulate certain values
14:55:29 <slava> I440r, have some kind of access control
14:55:36 <I440r> slava im not going to give any mortals the ability to create directly
14:55:47 <slava> so what will mortals do?
14:55:49 <qFox> a sourcecodefirewall
14:55:53 <I440r> slava the access control is going to be based on vocabularies
14:56:08 <slava> java has capability-based access control, its been used for this kind of stuff before
14:56:22 <I440r> slava if a mortal uses a magic item that creates a random pile of gold (or something likle that)
14:56:36 <slava> again, access control... the words to create magic gold can be restricted
14:56:59 <I440r> such an item would be self destroying probably. 
15:02:13 <TheBlueWizard> gotta go...bye all
15:02:37 --- part: TheBlueWizard left #forth
15:03:09 --- quit: [Forth] ("abort" Reality Strikes Again"")
15:03:48 <I440r> i wish the irc server wouldnt put quotes arround everyones quit message, it totally screws up my bots message!
15:04:03 <warp0b00>  is it a forth bot?
15:04:08 <I440r> yes
15:04:13 <I440r> get isforth lol
15:04:14 <warp0b00> I LOVE YOU SO MUCH
15:04:19 <I440r> the sources to the bot are in there
15:04:23 * warp0b00 kisses I440r
15:04:25 <I440r> lol
15:04:37 <I440r> no. gimme yer sister instead1
15:04:39 <warp0b00> i was going to make one out of 4th
15:04:46 <warp0b00> i don't have a sister :(
15:04:46 <I440r> this one needs alot of work
15:04:55 <I440r> then ill take your gf :))
15:04:56 <I440r> lol
15:05:03 <warp0b00> i don't have a girlfriend :(
15:05:07 <I440r> lol
15:05:23 <slava> i wouldn't write network servers in an unmanaged language -- buffer overflows etc
15:05:27 <warp0b00> if i had either do you think i would be chatting and not... uh... nm
15:05:58 <warp0b00> get ur bot back in here
15:06:00 <warp0b00> i want to play with it
15:06:06 <I440r> it doesnt do anything
15:06:16 <I440r> go to isforth.clss.net and download isforth and play with it all you want
15:06:26 <warp0b00> oh
15:06:33 <warp0b00> it should allow you to do forth evaluation
15:06:53 <I440r> thats was planned right from the beginning. 
15:07:18 <slava> : infinite infinite ; infinite
15:07:22 <slava> will it eval that? :)
15:07:39 <I440r> no
15:07:48 <I440r> : infinite recurse ; infinite
15:07:52 <slava> well whatever :)(
15:08:14 <I440r> but that will not go for ever
15:08:18 <I440r> it will stack overflow
15:08:22 <warp0b00> does isforth have threading yet
15:08:25 <I440r> : infinite begin again ; infinite
15:08:32 <I440r> define threading
15:08:34 <I440r> linux threads?
15:08:38 <I440r> thats a clone syscall
15:08:40 <I440r> add it
15:08:52 <warp0b00> you add it
15:08:53 <slava> but is the interpreter thread-safe
15:09:04 <I440r> slava define thread safe
15:09:08 <I440r> :)
15:09:21 <warp0b00> thread safe is in the eye of the beholder
15:09:25 <I440r> that should answer your question :)
15:09:26 <Callidus> I440r: good lord, you advocate bracing single statements *and* using GNU- or BSD-style braces?
15:09:27 <warp0b00> also implement some good timer stuff
15:09:43 <Callidus> if (foo)
15:09:43 <Callidus> {
15:09:45 <Callidus>     bar;
15:09:47 <Callidus> }
15:09:48 <Callidus> else
15:09:49 <Callidus> {
15:09:52 <I440r> Callidus, no. never gnu. never gnu and NEVER gnu
15:09:53 <Callidus>     foo;
15:09:53 <Callidus> }
15:09:57 <I440r> if ( x = 1)
15:09:57 <I440r> {
15:10:01 <I440r>   brace this way always
15:10:02 <I440r> }
15:10:14 <qFox> gnu!
15:10:18 <Callidus> That's obscene!
15:10:37 <I440r> i wish i still had my parody of linus's coding style doc :(
15:10:52 <Callidus> I'd probably write such a statement as (i == 1) ? foo : bar;
15:11:00 <qFox> if (x == 1) { foo }
15:11:01 <warp0b00> i just code however is convient at the moment
15:11:02 <warp0b00> :D
15:11:18 <warp0b00> i need a forth -> c compiler
15:11:33 <qFox> just do forth>asm>c
15:11:33 <Callidus> That's technically a translator, but don't they exist?
15:11:34 <qFox> :p
15:11:48 <warp0b00> qFox: that would be a step too many
15:11:58 <qFox> way easier though
15:11:59 <Callidus> Also, there's no decent way to go from ASM to C.
15:12:04 <warp0b00> qFox: a forth compiler would work if i could find a good one
15:12:17 <slava> i'm porting some c++ code to java
15:12:17 <Callidus> You may as well just compile the assembly.
15:12:18 <qFox> Callidus> and why would it be decent to go from forth to c? :\
15:12:26 <slava> its amazing how much crud c++ makes you write
15:12:31 <Callidus> It would at least be readable.
15:12:36 <warp0b00> yeah i hate c++
15:12:36 <XeF4> forth->c is practically impossible short of making a little bytecode interpreter in C and doing forth->bytecode
15:12:57 <warp0b00> well i need a POSTFIX C -> C translater then
15:12:59 <warp0b00> how is that
15:13:05 <qFox> possibly, but how will you figure out the arguments for an if, the arguments supplied for a certain word, etc.
15:13:09 <XeF4> that is doable
15:13:29 <slava> why do you need a postfix c?
15:13:36 <warp0b00> because i hate writing C
15:13:41 <slava> then don't write C
15:13:47 <warp0b00> and i can't figure how do this in any other language >:(
15:13:51 <Herkamire> a forth -> C translator shouldn't be hard to make
15:14:05 <Herkamire> simple search and replace tools aught to do it
15:14:20 <warp0b00> uh oh Herkamire your disturbing the status quo here
15:14:29 <Herkamire> replace literals with push(xxx); and put (); after every keyword
15:14:44 <warp0b00> ah no not like that
15:14:46 <slava> hi Herkamire
15:14:50 <Herkamire> hi slava :)
15:15:06 <warp0b00> if someone will explain to me how do to what I want in forth or some other real language
15:15:08 <warp0b00> i will be happy to
15:15:09 <Herkamire> and of course you'de need to replace symbols like -+?!@ etc with letters
15:15:25 <qFox> i still say you're gonna have a hard time with containing what belongs to an if, and what not
15:15:40 <Herkamire> qFox: oh right
15:16:04 <qFox> same for arguments to words
15:16:07 <Herkamire> I did forget about control constructs
15:16:21 <Herkamire> not with arguments though. I'd still use a stack
15:16:25 <warp0b00> if someone will explain to me how do to what I want in forth or some other real language
15:16:27 <warp0b00> i will be happy to
15:16:37 <qFox> c wants you to tell it what arguments it will get...
15:16:39 <Herkamire> s/if/if(pop()){/
15:16:40 <qFox> unless you cheat
15:16:43 <XeF4> if you would explain what you want, we would be happy to
15:16:48 <Herkamire> s/then/}/
15:17:02 <qFox> so, forth>asm>c would probably work best still :p
15:17:03 <Herkamire> warp0b00: what do you want to do?
15:17:06 <warp0b00> XeF4: well it has to be very compiled is all
15:17:11 <Herkamire> qFox: I'd still pass arguments on a stack
15:17:20 <qFox> yes but you wouldnt know how many
15:17:26 <qFox> or what they represent
15:17:31 <Herkamire> qFox: a global pointer, and functions/macros PUSH() and POP()
15:17:36 <warp0b00> I have to be able to run it in kernel space, have it generate assembly on the fly, ...
15:17:43 <warp0b00> and be very compiled
15:17:51 <warp0b00> and fast
15:17:54 <Herkamire> qFox: so?
15:18:08 <Herkamire> I wrote a forth in C.
15:18:15 <qFox> not the same
15:18:23 <Herkamire> it has a C function for each (kernel) word.
15:18:26 <qFox> how will you do func defs?
15:18:33 <Herkamire> it passes data around on the same stack that forth words do
15:18:36 <Callidus> func(void);
15:18:48 <Callidus> You wouldn't need to pass arguments to the functions; they'd work with the stack.
15:18:50 <qFox> so cheating
15:18:51 <qFox> :)
15:18:51 <warp0b00> qFox: its a translator it doesn't need to do function definitions
15:18:56 <qFox> well, ok then
15:19:02 <Herkamire> to translate forth->C I would start with a forth like mine, then mangle the forth source into C function calls.
15:19:08 <warp0b00> its not like it has to interactively do that
15:19:08 <qFox> but you'll still fall at flow control
15:19:18 <qFox> unless you do the same there
15:19:24 <XeF4> Herk: but then immediate stuff would behave differently than compiled stuff
15:19:28 <qFox> in that case... dunno if you're still in C :)
15:19:29 <warp0b00> well if you regimented flow control you could do it right?
15:19:44 <warp0b00> no funky flow control constructs
15:19:44 <Herkamire> XeF4: yeah, I'm not sure what to do about immediate words
15:19:51 <XeF4> Herk: not to mention doing does> at runtime
15:20:25 <qFox> warp0b00> if you have like: -1 0 OR -1 OR 0 OR -1 AND IF 0 ELSE -1 THEN
15:20:31 <Herkamire> warp0b00: right. you could do it if you just use certain immediates, that you hard code the translator to read properly (such as if/then variable begin/again etc)
15:21:01 <qFox> if you stack the if's, with just one "argument" per if, then np i guess
15:21:51 <warp0b00> I never said I wanted pure forth, just something thats not as horrible as C.
15:22:00 <warp0b00> :D
15:22:03 <warp0b00> bbiab, got to shower
15:22:04 <qFox> uh.. :)
15:22:35 <Herkamire> qFox: if always takes one argument in forth
15:23:01 <Herkamire> : if ( x -- )
15:23:16 <qFox> you'd have to trace back that one argument
15:23:24 <Herkamire> what?
15:23:27 <qFox> to check what might have caused that result
15:23:31 <qFox> -1 0 OR -1 OR 0 OR -1 AND IF 0 ELSE -1 THEN
15:23:40 <Herkamire> C version would be:  if(pop()) {
15:23:42 <XeF4> no, it compiles to if(pop())
15:23:52 <qFox> hmm
15:23:54 <qFox> k
15:24:04 <qFox> hax
15:24:05 <qFox> :p
15:24:53 <qFox> splitting headache... i'm gonna chill for a bit :\
15:45:54 --- join: Sonarman (~matt@ppp-66-124-254-227.dsl.snfc21.pacbell.net) joined #forth
15:52:02 <warp0b00> Herkamire: you there?
16:14:52 --- quit: qFox ("this is mirc's last attempt of communication...")
16:22:05 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth
16:22:13 --- mode: ChanServ set +o kc5tja
16:25:15 --- join: blockhead (default@dialin-655-tnt.nyc.bestweb.net) joined #forth
16:27:24 <kc5tja> re blockhead.
16:27:31 <blockhead> hey  'sup  :)
16:27:36 <kc5tja> Just got in from work.
16:27:39 <kc5tja> Tomorrow is my last day!
16:27:44 <kc5tja> (at In-N-Out at least)
16:27:59 <blockhead> there is a place called "in-n-out"?  that's funny
16:28:07 <kc5tja> I'm surprised nobody e-mailed me or wrote any weblog comments on my FAQ that I posted this morning.  :-)
16:28:21 <kc5tja> Especially with respect to the software-based fault isolation and proof-carrying code concepts.
16:28:32 <kc5tja> Normally you folks here are all over that stuff (yay or nay).  :-)
16:28:53 <blockhead> I hardly ever read blogs
16:29:45 * kc5tja nods
16:30:12 <kc5tja> I find that maintaining a blog is a nice way for me to judge how consistently I work on things.
16:30:38 <kc5tja> Kind of a dual-purpose task, really: a makeshift diary, while also serving as a notification for those interested in my current state of affairs.
16:30:53 <blockhead> so you wrote something that you think will annoy or surprise the people on #forth?
16:31:13 <kc5tja> It's been known to raise a few eyebrows in the past, yes.
16:31:27 <kc5tja> Basically, it's that the Kestrel is expected to have two OSes released for it.
16:31:36 <kc5tja> First is BoxForth itself.  Whoopie -- we all already knew about this.
16:32:07 <blockhead> then bill came to you with an offer?  :D
16:32:17 <kc5tja> The second is basically an adaptation of Dolphin to the Kestrel, which I've dubbed FTS/OS-1001 (the official name for Dolphin will be FTS/OS-86 when it's released too).
16:32:51 <blockhead> dolphin was your amiga-like os, right?
16:32:52 <kc5tja> The thing is, unlike the x86 platform, the FTS1001 lacks any kind of memory management capability in hardware, so *all* of its memory management MUST be done via explicit software techniques.
16:33:11 <kc5tja> Was, and still will be.  :)  Only I'm going for higher standards.
16:33:28 <kc5tja> For starters, it'll have what's called a "single level store."
16:33:45 <kc5tja> If you can imagine how a Palm Pilot works, that's roughly what you can expect from Dolphin.
16:33:50 <kc5tja> You turn on the machine, and you go.
16:34:06 <warp0b00> DUDE
16:34:12 <warp0b00> make the single-level store pluggable
16:34:17 <warp0b00> so i can use anyones dolphin
16:34:21 <slava> hi kc5tja
16:34:27 <kc5tja> You don't need to save files (unless you're saving them to removable media, for example)
16:34:43 <blockhead> heheh, play with your own dolphin  ;)
16:34:45 <warp0b00> i need some forth advice though
16:35:08 <kc5tja> warp0b00: The SLS is restricted to the boot partition, because I can't figure out how to gracefully handle SLS in an environment with removable volumes.
16:35:22 <warp0b00> flash?
16:35:31 <warp0b00> like why does the SLS need to be big?
16:35:36 <kc5tja> Whether it is flash or IDE harddrive, I don't care.
16:35:39 <warp0b00> why not just have CF port
16:35:44 <kc5tja> warp0b00: What???
16:35:54 <kc5tja> What do you mean SLS is big?
16:35:58 <warp0b00> we just confused each-other out
16:36:18 <warp0b00> i mean
16:36:38 <warp0b00> why not have the system on a storage and then just have SLS on a removable flash
16:36:41 <blockhead> have a CF port orthagonal to the SLS, restricted vis-a-vis cross-axial user paradigms  :D
16:36:56 * blockhead hides
16:37:14 <kc5tja> warp0b00: Well, the partition holding the kernel image need not be the same as the "boot partition."
16:37:23 <kc5tja> In fact, in a SLS-based OS, it *can't* be.
16:37:37 <warp0b00> so then whats the problem?
16:37:40 <kc5tja> (Not without adding special-case code to the kernel to handle it, and I'm not about to do that)
16:38:16 <kc5tja> warp0b00: The problem is easy to see: insert a floppy disk on a system running with a SLS.  The disk blocks will eventually start to be used for storing data.  now pop the disk out.  OOPS!  Where'd those blocks go?
16:38:38 <warp0b00> i don't see how this is a problem for your system though
16:38:50 <kc5tja> SLS *requires* a harddrive, at the very least, something that is permanent with respect to the machine itself, something taht can be guaranteed to be "in-volume" throughout the whole computer's life.
16:39:01 <warp0b00> why
16:39:03 <kc5tja> Dude, I *CANNOT* explain it any simpler than this.
16:39:04 <kc5tja> I CANNOT.
16:39:29 <kc5tja> Imagine running Linux with the swap partition located on a ZIP disk, and you pop the zip disk out.
16:39:40 <warp0b00> right
16:39:42 <kc5tja> *INSTANT* Kernel panic the moment Linux tries to page in a different part of the process.
16:39:49 <kc5tja> There is *NO* way to recover from that.
16:39:54 <warp0b00> i think your misunderstanding ME
16:40:08 <kc5tja> Then you're misunderstanding the concept of what a single-level store is.
16:40:20 <warp0b00> i don't think i am
16:40:57 <kc5tja> a single-level store is one where RAM is used exclusively as a harddrive cache.  The state of the computer, in its entirety, is kept on harddrive, with RAM serving only as a convenient, higher-speed memory.
16:41:05 <warp0b00> I'm just saying make the SLS removable
16:41:11 <kc5tja> Any changes to RAM pages are flushed to disk when necessary.
16:41:25 <kc5tja> You can't.  That's what I'm trying to tell you.
16:41:29 <warp0b00> the computer !should! die when you pop out the SLS
16:42:01 <warp0b00> but it should resume when you put it back in
16:42:46 <kc5tja> Wait, are you suggesting launching a virtual machine for every volume in the system?
16:43:01 <warp0b00> no, I'm suggesting only having one volume
16:43:06 <warp0b00> per machine
16:44:00 <kc5tja> Then I just can't see how it would even remotely happen.
16:44:07 <warp0b00> why not!
16:44:16 <kc5tja> You explain to me how it'd work.
16:44:18 <kc5tja> On a detailed level.
16:44:22 <warp0b00> okay
16:44:24 <kc5tja> Because I can't see it.
16:44:43 <warp0b00> lets say we're using a "disk drive" for the SLS
16:45:20 <warp0b00> my personal SLS "disk drive" is called X
16:45:33 <warp0b00> we have 2 Dolphins: A and B
16:45:33 * XeF4 imagines something like the Canon Cat where the entire machine state is dumped to removable disc which can be inserted into another Canon Cat and resumed exactly
16:45:47 <warp0b00> yeah XeF4 knows what i am talking about
16:45:59 <warp0b00> now when X is in A
16:46:03 <warp0b00> we're running fine right
16:46:17 <warp0b00> dolphin does stuff, stores it to X reads from X
16:46:29 <warp0b00> i remove X from A
16:46:37 <warp0b00> A hard freezes [no more SLS]
16:46:44 <warp0b00> i put X into B
16:46:53 <warp0b00> start B
16:46:56 <warp0b00> im right back where i was
16:47:09 <warp0b00> except on a differnet box
16:47:09 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576712.sympatico.ca) joined #forth
16:47:15 <warp0b00> but the memory is all the same
16:47:24 <kc5tja> OK, that much is easy enough.
16:47:31 <warp0b00> thats all you have to do
16:47:35 <kc5tja> You're right -- we are talking about two *WILDLY* different things.
16:47:39 <warp0b00> it doesn't matter if the box dies when you remove the SLS
16:47:43 <warp0b00> it SHOULD anyway
16:47:52 <kc5tja> *I* am talking about having a computer with, for example, a harddrive and a 250MB ZIP drive.
16:48:05 <warp0b00> i SAID only one volume
16:48:14 <kc5tja> How do you handle the harddrive if you boot of the zip drive?  How do you handle the ZIP drive if you boot of the harddrive?
16:48:22 <kc5tja> warp0b00: Afterwards.
16:48:28 <warp0b00> okay
16:48:32 <warp0b00> well do you see what i mean now
16:48:35 <kc5tja> Yes.
16:48:43 <kc5tja> And to that, I respond with, "Duh, of course."
16:48:44 <kc5tja> :)
16:48:51 <warp0b00> cache-synchronicity problems can be solved
16:49:10 <warp0b00> after all this is how AF will work AS A LANGUAGE ENVIRONMENT
16:49:16 <kc5tja> I just insist on journalling pages every few seconds, and checkpoint (replaying the journal to the page home locations) every few minutes.
16:49:37 <warp0b00> atomicity should be enough
16:49:39 <kc5tja> No more than a couple seconds worth of progress would ever be lost.
16:49:56 <kc5tja> Atomicity requires journalling.
16:50:04 <warp0b00> does not
16:50:20 <kc5tja> warp0b00: Then name me *one* database system that *doesn't* use journaling (or its logical extreme, logging).
16:50:23 <XeF4> kc5: can't one have multiple removable volumes in a SLS by treating the removable volumes as pages liable to change spontaneously?
16:51:02 <warp0b00> kc5tja: this isn't a database, its an SLS
16:51:24 <kc5tja> warp0b00: Oh, give me a break!!!!!!!!!1
16:51:38 <warp0b00> you just have to make sure atomicity exists
16:51:42 <warp0b00> its a simple concept
16:51:47 <kc5tja> Journaling is *required* to make that happen.
16:51:48 <warp0b00> and it doesn't require a journal
16:51:51 <kc5tja> Read the research on the web.
16:51:53 <kc5tja> Read the papers.
16:51:58 <kc5tja> Yes, it does.
16:52:25 <kc5tja> There is no other way to achieve safe atomicity when touching any storage device.
16:52:40 <kc5tja> There is no way to control when a power failure will occur, and quite often, it'll be smack in the middle of writing a sector.
16:52:49 <warp0b00> oh hm
16:52:50 <kc5tja> Journals are used to delineate transactional boundaries.
16:52:53 <warp0b00> i guess you're right
16:53:06 <warp0b00> i was considering SLS updates instant
16:53:15 <kc5tja> XeF4: No.
16:53:21 <XeF4> kc5: why not?
16:53:51 <kc5tja> XeF4: How do you handle that?  What are the semantics?  What happens if on floppy A, I page in part of program A, then I swap the disk so that part of program B exists where program A once was.  How does one handle that?
16:53:55 <kc5tja> XeF4: It just can't be done.
16:54:54 <XeF4> kc5tja: you kill program A with "error: blocks changed from under me"
16:55:52 <warp0b00> thats a hack
16:57:20 <kc5tja> XeF4: That's not "correct" system behavior.  When the user starts a program, (s)he expects it to remain running when changing a disk out from underneath it.  Even Windows apps don't croak when you change floppies (although AmigaOS and MacOS have the best response of all: it'll ask you politely to re-insert the relavent disk, and it'll make sure it's that same disk, before proceeding with any I/O)
16:57:47 <XeF4> kc5: asking politely to insert the disk is also feasable
16:58:01 <XeF4> assuming floppy b gets a different block range than floppy a
16:58:18 <kc5tja> The problem is, remember, that program state, NOT just data state, is kept on the disk too.
16:58:37 <warp0b00> how do you save the context properly
16:58:45 <warp0b00> in your design
16:58:56 <kc5tja> warp0b00: You keep application state in RAM, and out of the kernel space.
16:59:07 <warp0b00> even so... the stack?
16:59:10 <kc5tja> In RAM.
16:59:14 <warp0b00> huh
16:59:16 <kc5tja> It's no different from multitasking.
16:59:22 <kc5tja> A CPU only has one set of registers.
16:59:23 <warp0b00> i know that
16:59:26 <warp0b00> but how do YOU do it
16:59:32 <warp0b00> hehehe
16:59:35 <kc5tja> When it comes to task switching, you swap the register values out into RAM, and swap another set in.
16:59:57 <warp0b00> but how do you implement that given it could fail at any time
17:00:10 <XeF4> kc5: so there are blocks that are unusable for program state (on floppy), blocks that lose their contents when the machine is booted (ram), and blocks that can be freely used (fixed disc with ram cache)
17:00:24 <XeF4> kc5: all those can still be on the same logical flat level
17:00:26 <warp0b00> XeF4: thats not SLS
17:01:51 <kc5tja> warp0b00: If what fails?
17:01:57 <warp0b00> kc5tja: power
17:02:12 <kc5tja> warp0b00: Nothing will happen.  The disk still has old, but *valid* and *consistent* state.
17:02:29 <kc5tja> E.g., Atomicity isn't enough; you need full ACID properties.
17:02:30 <warp0b00> kc5tja: not if its missing cpu registers!
17:02:43 <warp0b00> including PC
17:02:54 <kc5tja> Let me restate: The disk still has OLD, but VALID and CONSISTENT state.
17:03:12 <warp0b00> HOW DO YOU GET THE REGISTERS IN THE CPU TO THE DISK
17:03:18 <warp0b00> INORDER TO MAKE THAT STATE
17:03:21 <kc5tja> E.g., if the power goes out when the disk is updating a journal, then the transaction never completed, and the journal play-back never bothers with the bad data.
17:03:32 <kc5tja> Jesus Christ, man, PAGING!!!
17:03:38 <kc5tja> The same way everything else is done!
17:03:44 <kc5tja> C'mon man, common sense!
17:04:03 <warp0b00> today in #forth I upset kc5tja :(
17:04:26 <kc5tja> I mean, I just got done explaining, SLS treats RAM *purely* and *utterly* as a cache for the harddrive.
17:04:34 <warp0b00> right
17:04:37 <warp0b00> i know that
17:04:56 <kc5tja> Hence, if any state of the system outside of the kernel is updated (and I did stipulate that thread state is stored outside of the kernel), then it follows it must also exist in some spot on the harddrive too.
17:05:14 <warp0b00> okay
17:05:48 <warp0b00> so then the CPU state [on disk] has to be updated with every atom then?
17:06:01 <kc5tja> It's treated no differently from any other page modification.
17:06:20 <warp0b00> That will make it terribly slow won't it?
17:06:22 <kc5tja> When a page is modified, and it needs to be flushed to disk, it will be.
17:06:40 <kc5tja> No, not unless you write deliberately malicious code to thrash the paging system.
17:06:50 <kc5tja> Certainly not any slower than any existing virtual memory system.
17:07:00 <kc5tja> And existing research suggests it's actually substantially faster.
17:07:19 <warp0b00> but you you have to wait until a thread gets paused before flushing pages
17:07:48 <kc5tja> No, you don't need to wait.  Mark said pages as copy-on-write, and schedule the read-only page for flushing to disk.
17:08:06 <kc5tja> This lets the application proceed while a "snapshot" exists in the system until the pager can flush it to disk.
17:08:20 <warp0b00> so you have to snapshot the CPU state!
17:08:29 <warp0b00> you either have to do one or the other
17:08:42 <kc5tja> Where did I write anything to the contrary.
17:08:44 <kc5tja> ?
17:09:00 <warp0b00> you didn't but jesus man'
17:09:17 <warp0b00> my brain can only get so many implications from your brief description here
17:09:31 <kc5tja> Well, install more RAM.  :)
17:09:57 <warp0b00> you should do this in hardware it would be faster
17:10:10 <kc5tja> FTS-1001 doesn't have said hardware.
17:10:11 <kc5tja> And won't.
17:10:21 <warp0b00> the FTS-1001 wouldn't need it
17:10:29 <kc5tja> The x86 version of the OS will obviously use the paging hardware inside the CPU.
17:10:40 <warp0b00> you'd just need a weird controller for the memory and hdd
17:10:54 <kc5tja> But the FTS-1001 version will use software-based fault isolation techniques to approximate it.
17:11:13 <kc5tja> warp0b00: Well, if I wanted that, I'd just use an IBM System/360 or any of its successors.
17:11:16 <kc5tja> Including the AS/400.  :)
17:11:24 <warp0b00> i don't know anything about those machines
17:11:40 <kc5tja> The microprocessor has a gigantic address space -- 64 bits wide usually.
17:11:46 <warp0b00> k
17:11:54 <kc5tja> Programs all run in the same physical address space, but the MMU enforces page-based protections.
17:12:03 <warp0b00> k
17:12:07 <XeF4> kc5: do you have a spare pin on the fts-1001 left? I just had a bloody lame silly redundant idea
17:12:12 <kc5tja> anyway, the S/360..S/390 at least have *hardware* that automatically handles the SLS.
17:12:34 <kc5tja> XeF4: What pins will be available depends on what chip it goes in.  I doubt I will though.
17:12:42 <warp0b00> kc5tja: and whats wrong with that?
17:13:00 <XeF4> kc5: if you would use a pin to signal whether the a memory fetch is for the instruction latch or for data, one could attatch an external MMU to the address lines
17:13:06 <XeF4> +interrupt for fault signalling
17:13:16 <kc5tja> warp0b00: Nothing.  Except the cost.  System 390 machines aren't exactly "PC-class" machines.  :D  They compete more with, oh, say, a Cray supercomputer.
17:13:31 <warp0b00> kc5tja: i mean whats wrong with using that TECHNIQUE
17:13:52 <kc5tja> XeF4: Actually, that's insufficient.  What's needed is, and I've only seen this on two CPUs (68010 and 65816), is some kind of "abort" interrupt.
17:14:08 <kc5tja> warp0b00: Nothing.
17:14:20 <warp0b00> kc5tja: for the dolphin
17:14:32 <kc5tja> warp0b00: These machines are built with 99.99999% uptime requirements (e.g., less than 5 minutes per year of downtime).  
17:15:10 <warp0b00> i can see why they would use that technology then
17:15:11 --- join: crc (~Charles_C@0-1pool176-21.nas6.philadelphia1.pa.us.da.qwest.net) joined #forth
17:15:17 <kc5tja> warp0b00: Well, there is no hardware to handle this on such a simple level.  I'm not about to implement an SLS-controller for the Kestrel because (a) it's cost, and (b) it restricts the flexibility of the machine (some might want to use it only as a home computer, others might want to use it as an embedded controller, etc)
17:15:21 <XeF4> kc5: but the MMU sits on the address lines so it can fetch some "abort" code on the next instruction latch
17:15:50 <kc5tja> XeF4: The CPU must receive notification of a bus transaction failure, so that it knows NOT to update ITS internal state.
17:15:51 <XeF4> and reserve some location for scratch by page faulting instructions
17:16:00 <warp0b00> kc5tja: i guess thats fair eoungh then -- but you'll still need hardware to do it i would think
17:16:25 <kc5tja> warp0b00: I can achieve segment-based approximations of it with decent (read, not the best, but adequate) performance using pure software techniques.
17:16:33 <kc5tja> I intend on making this happen for the first generation of Kestrels.
17:16:44 <warp0b00> kc5tja: i don't see how that would happen-- but okay
17:17:00 <kc5tja> I include various links to papers that illustrates how these things work on my FAQ page.
17:17:08 <kc5tja> Look through the various OS-related questions.
17:18:29 <XeF4> kc5: come to think of it, that is awfully suboptimal since in worse case there are 5 instructions left to execute putting the stack in whatever state it does
17:18:41 <XeF4> s/worse/worst/
17:19:12 <XeF4> still would work if the only allowed fault behaviour is thread termination though
17:19:26 <warp0b00> kc5tja: so your OS has to keep track of segment usage?
17:19:52 <kc5tja> warp0b00: Yes.  No different than (and I argue that it's easier than) paging.
17:20:07 <warp0b00> hmm
17:20:10 <kc5tja> XeF4: I'm sorry -- give me some more context?
17:20:14 <kc5tja> XeF4: You lost me.
17:20:16 <warp0b00> i can see how PROTECTION works like that
17:20:46 <warp0b00> but lets say you trust some code, then how do you keep track of accesses?
17:20:56 <warp0b00> i mean you trust it to not be bad about where
17:21:02 <warp0b00> but how do you keep track of when
17:21:33 <kc5tja> By definition, if a program is trust-worthy, you don't have to care about how it handles memory accesses.
17:21:44 <kc5tja> Otherwise, you have to fence all its memory references in.
17:21:45 <warp0b00> but you do for the SLS cache
17:22:24 <kc5tja> In order for a program to run, its code must be in memory.
17:22:34 <kc5tja> So when we switch to a task, we must make sure its code segment is first in memory.
17:22:46 <warp0b00> right
17:22:47 <kc5tja> When the code runs, it'll inevitably want to access its own memory segment.
17:22:51 <XeF4> kc5: if instead of using an abort interrupt, the MMU handles faults by not decoding any more data addresses until the CODE line is set high
17:22:56 <kc5tja> Thus, before we can let the thread run, we must swap in its data segment.
17:23:01 <kc5tja> That is necessary and sufficient to let the thread run.
17:23:03 <warp0b00> oh i see
17:23:06 <warp0b00> hmm
17:23:08 <XeF4> s/decode/forward/
17:23:08 <warp0b00> i see
17:23:15 <warp0b00> you just use HUGE segments
17:23:31 <kc5tja> Since it is untrusted, and therefore has been dynamically patched by the loader, all of its memory references MUST be constrained to its own memory segment.
17:23:42 <warp0b00> right
17:23:49 <XeF4> and then when CODE is set high, sets the address lines to point to the fault handler
17:23:53 <kc5tja> Therefore, any references to another memory space MUST be done via the host kernel, via a capability that has formerly been granted to it.
17:23:54 <warp0b00> but you have to commit the entire segment as an atom
17:24:29 <warp0b00> right?
17:24:30 <kc5tja> XeF4: No, you must not let the CPU update its internal state.
17:24:41 <kc5tja> XeF4: A failed bus transaction is fatal to the CPU's current thread of execution.
17:24:49 <warp0b00> SIGBUS
17:25:04 <warp0b00> 7) SIGBUS
17:25:07 <kc5tja> XeF4: This is why all MMU-related faults cause instruction *restarts* to occur when returning from an interrupt handler.
17:25:41 <kc5tja> warp0b00: Yes, the FTS-1001 implementation will NOT be super, duper high performance because it must synchronously writeback any cached process state that needs to be swapped out.
17:25:53 <XeF4> kc5: does the FTS-1001 have any state that matters?
17:25:58 <kc5tja> Fortunately, most process states are expected to be pretty small, considering it's a Forth-based run-time environment.
17:26:28 <kc5tja> XeF4: Yes.  Data stack, return stack, and the contents of the P register, and the instruction word register (I).
17:26:34 <kc5tja> P is the program pointer
17:27:21 --- quit: I440r (Read error: 110 (Connection timed out))
17:28:15 <XeF4> kc5: *nod* so with the hack I mentioned, the stack contents are garbage long before the fault handler gets executed
17:28:23 <XeF4> but that doesn't matter if we are terminating the thread anyway
17:29:39 <kc5tja> I won't say they're "garbage," but let's just say that crucial information will be lost (for example, when writing to memory, and a page fault occurs in your system, the value written will be lost to the CPU.  Thus, the failed instruction must be emulated by the handler.  Oh, wait, the state of the I register is lost too!  Oh, and when returning to the program, it has to return to the next instruction word, meaning that any remaining instructions in
17:30:06 <warp0b00> you got cut off
17:30:15 <warp0b00> at "any remaining instructions in"
17:30:36 <kc5tja> the I register at the time of the interrupt will also be lost.)
17:30:56 <warp0b00> kc5tja: im glad *i* don't have to deal with all of this
17:31:02 <XeF4> P will not be lost
17:32:01 <kc5tja> P always points to the next instruction word, which is not necessarily the next instruction (remember a single instruction word can contain up to 6 instructions!).
17:33:38 <XeF4> *nod* that complicates paging
17:37:47 <warp0b00> kc5tja: I'm interested in this because my language env. uses a form of SLS [though i didn't know it was called that]
17:38:09 <XeF4> however, the value written by a store will not be lost
17:38:18 <XeF4> because it will end up at the scratch location
17:38:35 --- join: ayrnieu (~julian@205.241.56.30) joined #forth
17:38:41 <kc5tja> Forth itself uses a form of what I call TLS (Two-level storage).  The dictionary is a software-managed explicit cache (for both code and data), while blocks effectively forms an external storage space.
17:39:51 <XeF4> kc5: but doesn't the normal int pin cause an instruction latch immediately?
17:40:16 <kc5tja> No.  External interrupts wait until the next instruction fetch before their handler is dispatched.
17:40:38 <warp0b00> why not not interupt the cpu
17:40:56 <kc5tja> warp0b00: Because then I'd need to save a *LOT* more state on the return stack than just a return address.
17:41:10 <kc5tja> Plus I'd need to introduce a dedicated "Return from interrupt" instruction to deal with that extra state.
17:41:14 <warp0b00> i mean at ALL
17:41:40 <kc5tja> The CPU needs interrupts to handle asynchronous events.
17:41:44 <kc5tja> You just can't get around it.
17:42:00 <warp0b00> Why is interupting it necessary for that though?
17:42:09 --- part: ayrnieu left #forth
17:42:15 <kc5tja> I can't believe I'm answering these questions.
17:42:20 <warp0b00> :(
17:42:30 <kc5tja> Why *wouldn't* you want the ability to interrupt the CPU?
17:42:53 <warp0b00> So that the hardware and software could be simpler?
17:43:14 <kc5tja> I mean, if you're busy in a tight loop computing some mathematical function on a deep matrix, you still want to know when the vertical sync is happening on the screen (e.g., if you're doing color cycling, or double-buffered animation, etc)?
17:43:48 <warp0b00> put a poll in the loop?
17:43:53 <kc5tja> or if your software ends up doing some *really* anti-social things, you still want the ability to hit a key on the keyboard, and have it drop right back to the OS...
17:43:58 <kc5tja> warp0b00: Not good enough.
17:44:14 <kc5tja> You'd have to poll on EVERY INSTRUCTION to find out whether such an event has occured.
17:44:27 <warp0b00> thats the same as an interuppt i gues
17:44:29 <warp0b00> s
17:44:30 <kc5tja> And that, at the least, will therefore cause the loop to take 3x as long to execute.
17:44:56 <kc5tja> The goal is not the absolute, most bad-ass simple processor.
17:45:05 <kc5tja> It's the most *usable* processor, the most logically designed processor, for the money.
17:45:09 <warp0b00> okay okay okay
17:45:14 <warp0b00> ill just shut up and leave
17:45:29 <kc5tja> Well, I just thought these things were so very obvious.
17:45:30 --- part: warp0b00 left #forth
17:45:53 <kc5tja> I mean, there hasn't been a CPU made that doesn't have an interrupt facility since the early 70s.
17:46:45 * kc5tja shrugs
17:46:47 <kc5tja> Whatever man.
17:47:01 <XeF4> 6807?
17:47:05 <kc5tja> From now on, no more updates on the Kestrel.  Don't even bother asking me.
17:47:10 <kc5tja> I'm through "dealing with the public."
17:47:43 <kc5tja> The 6807 still has the logic for interrupts on the chip, even if the IRQ pin isn't exposed to the outside world.
17:47:47 <kc5tja> It's the same core as the 6800.
17:47:53 --- quit: crc (Read error: 54 (Connection reset by peer))
17:48:20 <kc5tja> I mean, seriously, am I being unreasonable?  Unclear?  Ambiguous?
17:48:22 <kc5tja> No, never mind.
17:48:23 <kc5tja> Forget it.
17:48:33 <kc5tja> I'll just shut up too, and whatever happens will be posted on my site.
17:48:41 <kc5tja> Those interested are responsible for checking periodically.
17:48:43 <kc5tja> Screw it.
17:48:49 <XeF4> you're being quite clear to me
17:51:05 <XeF4> may I suggest a simple addition to FTS1001?
17:52:08 <kc5tja> What's that?
17:52:22 <XeF4> a register which may be loaded from the data stack and exchanged with I
17:52:44 <XeF4> should be enough for abort
17:53:25 <kc5tja> If I'm going to do that, I might as well just add the MMU.
17:53:50 --- join: warp0b00 (~warpzero@dsl.142.mt.onewest.net) joined #forth
17:54:08 <kc5tja> I've already changed the specs of the Kestrel wildly from when I first started it.
17:54:19 <kc5tja> I think it's time that I just set my foot down, and say, "This is it.  No more changes."
17:54:22 <kc5tja> I think now is the time to do that.
17:54:30 <XeF4> understood.
17:54:53 <kc5tja> :(
17:54:59 <kc5tja> I think my monitor is going wonky on me.
17:55:00 * warp0b00 IS SORRY
17:55:03 <kc5tja> The screen keeps flicking.
17:55:06 <warp0b00> whoops capslock
17:55:10 * warp0b00 is sorry
17:55:32 <kc5tja> Don't worry about it.  
17:55:43 <warp0b00> and anyway
17:55:48 <warp0b00> i still need some forth advice
17:56:07 <XeF4> lights are flickering here, must be some EMP weapon in testing =)
17:56:11 <kc5tja> warp0b00: JEESSUZ!!  CAN'T YO....oh...forth advice.  I can do that.  :)
17:56:19 <warp0b00> k
17:56:46 <kc5tja> o_O -- I wonder how one pronounces JEESSUZ!! anyway.
17:56:48 <kc5tja> I digress.
17:57:01 <warp0b00> Is there a forth that will /compile/ in the purest sense of the word, c-style object files?
17:57:46 <warp0b00> on multiple platforms
17:57:54 <kc5tja> warp0b00: I'm familiar with only two: FTS/Forth's target compiler, and TCOM.EXE, for the DOS Forth environment whose name I can't recall right now.
17:58:01 <kc5tja> Oh, not on multiple platforms.  Sorry.
17:58:16 <warp0b00> oh well
17:58:20 <warp0b00> its back to C coding then
17:59:31 <warp0b00> i hate writing C
17:59:54 <kc5tja> I'd FAR rather program in C than C++ though.
18:00:01 <warp0b00> yeah true that
18:00:05 <XeF4> "would you like some cheese with your whine"?
18:00:34 <kc5tja> "Nope, but here's a quarter.  Go tell someone who cares.  :)"
18:01:07 <kc5tja> And, honestly, I find functional programming languages very convenient to get used to.
18:01:28 <kc5tja> I guess, in a way, Forth is to abstract state machines, as functional languages are to formal (mathematical) proofs.
18:01:32 <warp0b00> maybe ill invent a C sytnax and have my build system translate it
18:02:18 <warp0b00> that kinda seems like overkill
18:03:58 <XeF4> warp: if I understand right, you're happy enough with C's semantics but can't stand the syntax for some reason?
18:05:28 --- quit: madgarden (zelazny.freenode.net irc.freenode.net)
18:05:28 --- quit: warp0b00 (zelazny.freenode.net irc.freenode.net)
18:05:28 --- quit: mur (zelazny.freenode.net irc.freenode.net)
18:05:46 <XeF4> prkl
18:06:00 <XeF4> I was going to suggest he write some m4 macros and be happy ever after
18:07:36 <XeF4> there is already a pseudoforth->c in m4
18:07:48 <XeF4> if he could be bothered to google for 5 minutes
18:07:48 <XeF4> 2 minutes?
18:08:37 --- join: warp0b00 (~warpzero@dsl.142.mt.onewest.net) joined #forth
18:08:43 --- join: mur (~mur@smtp.uiah.fi) joined #forth
18:10:19 <XeF4> warp0b00: after googling for "forth to c" I have concluded you are either incredibly lazy or take joy in seeing us respond
18:10:28 <kc5tja> XeF4: I've tried using m4.  It fails miserably for me.
18:10:40 <kc5tja> I tried using it as a web page preprocessor.  I just didn't work.
18:12:55 <warp0b00> XeF4: i only saw one thing and it looked dead
18:14:08 <XeF4> kc5: but for serially expanding macros it's good enough
18:15:51 <kc5tja> Yeah, I suppose.  I just never liked m4.  It's never been useful to me.
18:16:29 <warp0b00> I think perl makes a pretty good macro-language.
18:27:29 <warp0b00> XeF4: did i miss something on google
18:35:49 <XeF4> I see 3 packages with that search
18:37:04 <warp0b00> i only see 1?
18:37:33 <XeF4> http://www-personal.umich.edu/~williams/archive/forth/forth.html
18:38:08 <warp0b00> oh thanks
18:40:13 <warp0b00> i only found the ^forth one
18:48:35 <warp0b00> XeF4: i think what i really need though is just a language specialized for C
18:48:42 <warp0b00> you know?
18:50:05 <XeF4> just make a bloody macro processor
18:50:16 <warp0b00> I am
18:50:23 <warp0b00> my build system does that anyway
18:50:49 <XeF4> excellent, now it's 5am I'm going to lie down for a bit
18:50:56 <warp0b00> hehe
18:50:59 <warp0b00> where do you live?
18:56:29 <kc5tja> If memory serves me correctly, out at sea.  :)
19:11:14 <warp0b00> kc5tja: so do you honestly find that the blog method you use helps you keep development going?
19:12:01 <kc5tja> It's still too early to tell, but for me, I can see at a glance how long it's been since I last updated my site at least.
19:12:14 <kc5tja> There's a printed "receipt" if you will of all the stuff on my site.
19:12:30 <kc5tja> Speaking of which, I need to get coding on the FTS1001 assembler code.
19:12:42 <warp0b00> is your ASM done?
19:15:03 <kc5tja> I need to re-read it once more to verify everything is OK.
19:15:21 <kc5tja> I know there are a few known bugs in the design, but I want to get some kind of code up on the website so people can at least start playing with it.
19:15:51 <warp0b00> Isn't this just an assembler?
19:16:03 <kc5tja> Yes.
19:16:11 <kc5tja> It's designed to work with my CPU emulator software.
19:16:24 <warp0b00> Why are you going to such lengths to make a perfect assembler?
19:16:28 <kc5tja> But it ought not be very hard to use in isolation either.
19:16:31 <warp0b00> [Just out of curiosity.]
19:16:59 <kc5tja> My previous attempt at writing the assembler had at least one critical bug in it which prevented it from producing correct code.
19:17:04 <kc5tja> I never was able to find the bug.
19:17:09 --- join: I440r (proxyuser@adsl-67-65-218-139.dsl.snantx.swbell.net) joined #forth
19:17:18 <kc5tja> I spent three days looking for it, without success.
19:17:25 --- quit: I440r (Client Quit)
19:17:55 --- join: I440r (proxyuser@adsl-67-65-218-139.dsl.snantx.swbell.net) joined #forth
19:18:13 <I440r> im starting to HATE mirc
19:18:20 <warp0b00> uh
19:18:23 <warp0b00> why are u on windows
19:18:26 <I440r> it used to be the best irc client but it totally sucks now
19:18:56 <I440r> because my laptop cpu temp goes straight up toi 99 degrees and a few minutes later shuts off when im in linux
19:19:10 <warp0b00> !!!!
19:19:20 <kc5tja> Dude, that's a pretty serious kernel bug.
19:19:31 <kc5tja> The kernel should *always* invoke the HLT instruction when it has nothing at all to do.
19:19:48 <warp0b00> kc5tja: Did writing the ASM make your realize where your bug was?
19:20:02 <I440r> it does. but if it has even a slight ammount of work to do it cant seem to keep the cpu temp down
19:20:09 <blockhead> it's a sad day when windows is easier on the CPU than linux  :)
19:20:13 <I440r> the fan starts, then kicks in higher speed then the cpu shuts down
19:20:19 <I440r> only happens in linux
19:20:20 <kc5tja> warp0b00: No.  But I did realize a few other hidden bugs that I undoubtedly would have run into in the future had the assembler been used by more people in more different situations.
19:20:47 <kc5tja> I440r: Do you have power management features compiled into the kernel?
19:20:51 <warp0b00> kc5tja: I guess assemblers are more complex than I thought!
19:21:06 <I440r> yes i do. and cpu throttling doesnt seem to be supported on this processor
19:21:07 <kc5tja> warp0b00: This isn't a sophisticated assembler, which is why I was so pissed off about it.
19:21:18 <kc5tja> warp0b00: The ASM is helping me clear the air about what's going on in the system though.
19:21:30 <kc5tja> I440r: What CPU?
19:21:50 <I440r> athlon-xp
19:22:02 <warp0b00> I am so not suprised.
19:22:22 <I440r> it shouldnt be overheating like that just because im in linux
19:22:30 <kc5tja> warp0b00: The new assembler is equally simple too.  It's just that I've more rigorously specified the assembler's behavioral characteristics, from which I can do more sophisticated modeling and proving with.
19:22:43 <warp0b00> kc5tja: Right.
19:22:51 <warp0b00> kc5tja: Okay, I see...
19:22:51 <kc5tja> My roommate's Athlon-XP box does not exhibit this problem.
19:23:03 <kc5tja> His CPU's fan almost never turns on when in Linux, but it does in Windows XP.
19:23:09 <I440r> this is a laptop
19:23:34 <kc5tja> I440r: So?  This suggests a motherboard chipset issue rather than a CPU issue, but still, Linux *ought* to support it.
19:23:50 <kc5tja> There are only so many Athlon chipsets out there.  :)
19:23:51 <I440r> acpi
19:23:55 <I440r> i suspect acpi
19:24:09 <warp0b00> I440r: try booting it w/o power management stuff
19:24:41 <I440r> recompile acpi out ?
19:24:57 <warp0b00> yea
19:24:58 <warp0b00> and apm
19:25:00 <blockhead> maybe a differnent linux?  like a different "distro"
19:25:08 <I440r> nope 
19:25:16 <warp0b00> ?
19:25:17 <I440r> not switching distro
19:25:43 <warp0b00> what distro do you use?
19:26:14 <I440r> gentoo
19:26:26 * warp0b00 gives I440r a big giant hug
19:27:13 <I440r> lol
19:27:25 <I440r> next ull be trying to kiss me... again
19:27:26 <I440r> lol
19:27:39 <warp0b00> :(
19:27:44 <I440r> lol
19:28:17 <kc5tja> Hehe
19:28:20 <kc5tja> I don't want to know.
19:28:39 <warp0b00> Hey its my job to be friendly to gentoo users.
19:29:15 <blockhead> how "friendly
19:29:18 <blockhead> ?
19:29:19 <blockhead> :)
19:29:40 <warp0b00> lol
19:32:34 <kc5tja> bbiab -- food.
19:32:39 --- join: rsync (~pavel@CPE000c41aac435-CM000a73a75acb.cpe.net.cable.rogers.com) joined #forth
19:33:33 <I440r> hi rsync
19:34:15 <rsync> hiya
19:45:27 <warp0b00> # 767 "/usr/include/stdio.h" 3 4 <-- how do i make line number adjusting C post-preprocessor stuff like that
19:51:23 <blockhead> 'nn all
19:51:34 --- quit: blockhead ("laugha while you can, monkey boy")
19:59:42 <kc5tja> Back
20:00:02 <kc5tja> warp0b00: in C sources, you can use the #line directive, I think.
20:14:13 <warp0b00> kc5tja: really?
20:14:46 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576712.sympatico.ca) joined #forth
20:14:49 <kc5tja> Yep.
20:14:57 <madgarden> Hi.
20:14:59 <kc5tja> I don't know HOW to use it, but it's there.
20:15:36 <kc5tja> Yacc, Bison, Flex, and whatnot all use it to set the source file and line number when compiling their output via the C compiler, so you can find the right line number in the .y/.lex source file.
20:15:37 <Sonarman> #line is just expanded into the literal line number
20:15:45 <kc5tja> Sonarman: No.
20:15:50 <kc5tja> Sonarman: You're thinking of __LINE__
20:15:54 <kc5tja> __LINE__ is a macro
20:15:57 <Sonarman> oh right :)
20:16:02 <kc5tja> #line is a compiler directve.
20:16:24 <kc5tja> :)
20:16:52 <Sonarman> i think blockhead is facing some serious competition for that title. he'd better watch out :)
20:18:24 <kc5tja> :)
20:22:18 --- quit: warp0b00 (Remote closed the connection)
20:24:26 --- join: warpzero (~warpzero@dsl.142.mt.onewest.net) joined #forth
20:30:46 <warpzero> kc5tja: whats with the FTS1001's 8x8 instruction matrix thing?
20:32:31 <kc5tja> That's the "opcode map."
20:32:50 <kc5tja> The column headers indicates the first three bits of the opcode, and the row headers indicates the last three.
20:32:57 <warpzero> Why isn't it a list though?
20:33:02 <warpzero> I just found that a bit odd...
20:33:30 <kc5tja> Primarily for compactness.  Plus it helps me find what instruction the CPU is going to execute when examining raw memory by hand.
20:34:00 <warpzero> Ah okay.
20:34:48 <warpzero> Why are the s@, s! take their value from A instead of the stack?
20:36:46 --- join: tgunr1 (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth
20:36:47 <kc5tja> They take their address from A, as @a and !a do.
20:36:58 --- quit: tgunr (Read error: 60 (Operation timed out))
20:37:09 <kc5tja> S@ and S! are used to fetch from and store to CPU-specific "special purpose registers."
20:37:25 <kc5tja> For example, MMU control registers would be accessed there.
20:38:36 <warpzero> Right, but why not s@ ( spr -- n ) ( -- )
20:39:06 <kc5tja> Because it complicates the data path, the same way @ would if you placed the memory address on the data stack.
20:39:18 <warpzero> I see.
20:39:25 <kc5tja> You'd need one clock cycle to copy the T register to the address bus (memory or SPR), then another to latch the data addressed.
20:39:29 <kc5tja> Icky.
20:39:44 <kc5tja> Since you need two clocks anyway, you may as well make it explicit in the code.
20:39:54 <warpzero> I suppose so.
20:40:09 <kc5tja> That's actually what got me thinking about all this software-based fault isolation stuff too.
20:40:19 <kc5tja> I realized that the MISC architecture is really quite ideal for SFI.
20:40:44 <kc5tja> Since the instruction set is super compact and very precisely defined, formal proofs are (relatively!) trivial with MISCs.
20:40:54 <kc5tja> Thus, it's easier to guarantee program correctness.
20:41:06 <kc5tja> And therefore, easier to patch code if necessary if some program isn't trustworthy.
20:41:38 <kc5tja> Plus, the MISC doesn't have registers available to the program (except for A and B), and therefore, the problem of "running out of registers to dedicate to the SFI engine" just plain doesn't exist.
20:41:57 <warpzero> Hmm...
20:42:11 <warpzero> I guess I'm just used to always trusting code.
20:42:41 <kc5tja> The other thing to note too is that, when using SFI to impose discipline in a running program, the effect isn't the same as using a page table (as we've already discussed, it's closer to a segment system).
20:43:36 <kc5tja> More precisely, each segment behaves as a virtual machine context -- memory accesses and control flow are "sandboxed" into their respective segments, so there is no way, from within the code, to break out of its sandbox.  Only special "lightweight RPC" mechanisms are used to communicate with external modules.
20:43:36 <warpzero> WTF is darcs?
20:43:47 <kc5tja> Dave's Advanced Revision Control System
20:44:01 <kc5tja> It's a sweet replacement for things like GNU/Arch and CVS.  
20:44:04 <kc5tja> Oops -- phone.
20:44:04 <kc5tja> brb
20:46:20 <warpzero> kc5tja: I was just looking at this NRMF stuff and was very interested.
20:46:21 --- quit: madgarden ("*frotz*")
20:51:42 <futhin> remember everyone, computers are gay
20:52:01 <warpzero> I am gay for computers.
20:55:07 <kc5tja> back
20:55:14 <kc5tja> warpzero: Yeah, it is very interesting.
20:55:24 <kc5tja> NRMFs are extremely fast too.
20:55:26 --- quit: I440r ()
20:55:32 <kc5tja> I just wish I had some kind of documentation to put on how to use it.
20:55:39 <kc5tja> re futhin
20:56:00 <kc5tja> Anyway, I wasted enough time.  I'm going to hack on that assembler like I'm scheduled to do this evening.
20:56:02 --- join: madgarden_ (~madgarden@Kitchener-HSE-ppp3576712.sympatico.ca) joined #forth
20:56:02 <warpzero> kc5tja: I wish there was some and for CUT too, I need them :(
21:05:36 <kc5tja> Well, CUT is moderately self explanatory, I think.  Attempts to document it any further have totally defied me.
21:06:01 <warpzero> Yeah I'm screwing around with CUT in a second here.
21:06:06 <kc5tja> If anyone else is willing to give CUT a try and compile what they feel is better documentation, definitely feel free to submit the docs to me for inclusion.
21:06:16 --- quit: tgunr1 (Read error: 54 (Connection reset by peer))
21:07:27 --- join: tgunr (~davec@user-2ivfiq1.dialup.mindspring.com) joined #forth
21:28:19 --- join: arke (~arke@melrose-251-251.flexabit.net) joined #forth
21:28:29 --- quit: arke (Client Quit)
21:36:11 --- join: arke (~arke@melrose-251-251.flexabit.net) joined #forth
21:36:15 <kc5tja> wb
21:37:57 <arke> hi there .. can't really talk
21:38:11 <arke> mom's watching m,e ./.. putty window is offscreen as I type ^_^
21:39:36 <Sonarman> oh how i want to reach over there and hit ALT-TAB
21:40:22 <slava> arke, what are you hiding?
21:41:15 <kc5tja> slava: He's not supposed to be on IRC. 
21:41:54 <slava> hehehe
21:43:33 <arke> ^_^
21:45:20 <slava> why not?
21:45:25 --- quit: arke ("bye - sam, send me email")
21:45:46 <kc5tja> His parents are punishing him for something.  That's about all I can discern.
21:46:09 <kc5tja> His dad monitors all of his Internet traffic too.
21:46:15 <Sonarman> poor guy :(
21:46:23 <kc5tja> (apparently his dad knows how to use a packet sniffer.  :( )
21:46:24 <kc5tja> Yeah.  :(
21:46:55 <Sonarman> i remember he got into big trouble a year or so ago
21:47:57 <kc5tja> I'm not sure if this is related.  I am not sure why he's being grounded in this way.
21:49:33 <Sonarman> i think that the current situation of his being monitored is a result of what happened a year ago
21:49:50 <Sonarman> i don't know. it doesn't matter. i hope he'll be back soon
21:49:59 <kc5tja> Yeah, me too.
22:03:27 <slava> what did he do a year ago?
22:05:54 <kc5tja> I don't know.
22:28:57 --- join: Serg (~z@212.34.52.140) joined #forth
22:38:56 * Serg is screwed again - server HDD dies
22:48:45 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK")
23:00:01 --- quit: Sonarman ("leaving")
23:07:24 --- quit: Serg ()
23:13:37 --- quit: tgunr (Read error: 54 (Connection reset by peer))
23:14:52 --- join: tgunr (~davec@user-2ivfiq1.dialup.mindspring.com) joined #forth
23:59:59 --- log: ended forth/04.05.20