00:00:00 --- log: started forth/02.07.28
00:35:23 --- join: Soap` (~flop@202-0-42-22.cable.paradise.net.nz) joined #forth
05:30:37 --- join: CrowKiller (~Vapo_Rule@cnq5-233.cablevision.qc.ca) joined #forth
06:35:16 --- quit: CrowKiller ("User pushed the X - because it's Xtra, baby")
07:48:08 --- join: futhin (thin@h24-64-175-61.cg.shawcable.net) joined #forth
07:58:31 <Robert> futhin :)
08:54:25 <Speuler> god dag the_rob
09:49:08 <Robert> Goed..something, Speuler.
10:05:57 --- quit: Speuler (Read error: 110 (Connection timed out))
10:16:16 --- join: kc5tja (~kc5tja@ip68-8-206-226.sd.sd.cox.net) joined #forth
10:36:12 --- join: tathi (~josh@ip68-9-68-213.ri.ri.cox.net) joined #forth
10:40:15 <futhin> kc5tja: i know, i hang on here and i feel like such a hypocrite cause i don't code in forth.. it sucks..  and the #forth channel doesn't really seem like the most productive channel in the world..  
10:40:22 <futhin> and i wonder how it could be more productive
10:40:24 <futhin> as a channel
10:40:38 <futhin> if there is any ideas to improve #forth
10:40:40 <futhin> if at all
10:40:48 <futhin> or just tell every forther to get off and go code :P
10:41:20 <kc5tja> Well, right now I'm running some thought experiments on orthogonal persistence, and how Forth achieves 95% of that goal without even trying.
10:41:32 <futhin> yeah
10:41:37 <futhin> that's true
10:41:48 <kc5tja> The devil is in the details, however, and that remaining 5% is the problem.  
10:42:17 <kc5tja> As long as you're loading in new functionality, it can be considered persistent (it's not orthogonal since most Forth applications explicitly manage their persistent store, but it can still be automated fairly easily).
10:42:24 <futhin> 6 months ago i was telling some tunes guy who was starting his own os to use forth cause he could achieve orthogonal persistence with ease :P
10:42:44 <kc5tja> But when you're *removing* functionality....that's a whole different ball of wax.  The only solution I can think of is token threading to alleviate the dictionary compaction issues.
10:44:47 <kc5tja> On x86, this is trivial to implement since the CPU's instruction set is largely already position independent.
10:45:11 <kc5tja> On 680x0, it's only marginally more difficult because you have to explicitly use PC-relative addressing for everything (and it's not as general purpose as the other addressing modes).
10:45:15 <kc5tja> On RISCs, it's almost impossible.
10:45:20 <futhin> is the dictionary the best paradigm or can we change the dictionary or something..
10:45:49 <kc5tja> The Forth language is built around the dictionary.  I can't see any way to change it and still call it Forth.
10:46:19 <kc5tja> However, if you solve the dictionary compaction problem, I don't see any reason not to continue to use a traditional dictionary.
10:46:21 <futhin> hmm, the dictionary isn't the main thing about forth...
10:46:45 <kc5tja> Well, you need some method of mapping a word name to the word's header and functionality.
10:47:08 <futhin> yeah
10:47:18 <futhin> brb
10:47:32 <kc5tja> By definition, that's a dictionary.  It doesn't matter if it's implemented as a linked list or a B-tree or a skiplist.
10:47:39 <kc5tja> But it does have to exist.
10:47:59 <kc5tja> OK
10:53:28 <futhin> yeah you are right
10:59:13 <futhin> kc5tja: so some kind of pseudo-orthogonal persistence could be achieved..
10:59:19 <futhin> with forth?
10:59:27 <futhin> and that might be good enough?
11:01:08 <kc5tja> Well, I'm looking at ways of having my cake and eating it too.  Token threaded Forth (where word calls have one level of indirection) appears to solve a *huge* number of problems with respect to this.
11:01:33 <kc5tja> We can keep each segment of the dictionary (where one segment belongs to one application).
11:01:36 <kc5tja> oops
11:02:06 <kc5tja> We can keep each segment of the dictionary (where one segment belongs to one application) orthogonally persistent, because it uses position independent code (not sure how to do this with RISC processors easily, but with x86 and 680x0,it's easy enough to do).
11:02:26 <kc5tja> Removing an application involves merely compacting the dictionary and updating the word bindings in the "kernel."
11:02:47 <kc5tja> (I would hope removing an application also removes any dependent application, and warns the user of this first)
11:03:02 <kc5tja> Compiling new code is of course trivial -- just tack it onto the end of the dictionary space.
11:03:41 <kc5tja> Data resident in the dictionary is persisted (along with any dynamically allocated data of course, since that's maintained separately as well -- also trivial to implement).
11:04:23 <kc5tja> Note that in any persistent system, adding and removing programs is relatively expensive by nature (consider a Palm Pilot when loading new PRC files into it).  So any time taken by compaction is not really an issue, as long as it's reasonable.
11:06:02 <futhin> hmm
11:06:19 <futhin> why are RISCs so difficult?
11:06:45 <tathi> when you say it's easy enough to do position-independent code...do x86 and 68K processors have an instruction-pointer relative addressing mode or something?
11:07:25 <kc5tja> Because they lack a PC-relative addressing mode.
11:08:20 <kc5tja> Well, most of them do at least.  I think ARM has PC-relative capability.
11:09:29 <futhin> what is PC ?
11:09:38 <tathi> program counter
11:09:41 <futhin> ah
11:09:43 <futhin> doh
11:09:46 <kc5tja> Program counter
11:10:13 <tathi> I wasn't aware the x86 had PC-relative addressing mode
11:10:31 <kc5tja> tathi: For program flow instructions, that's all it has.
11:10:36 <kc5tja> tathi: For data-access, it doesn't.
11:11:06 <tathi> ah
11:11:12 <kc5tja> But that's OK; you usually end up using a global data pointer for accessing data, while for program flow, PC-relative addressing is almost always desired.
11:11:46 <tathi> well, that just shows how much I know -- I didn't know there _were_ processors without relative branching instructions
11:12:27 <kc5tja> Many RISCs don't because it adds too much complexity to the signal paths inside the chip.  (But instead they concentrate on really sophisticated instruction dispatchers.  Go figure)
11:12:46 <tathi> heh
11:13:15 <futhin> kc: forth chips for sale at 3 bucks, how many forth chips would you buy? :)
11:13:25 <kc5tja> Now I'm not saying they all are like this; I'm just saying it depends heavily on the type of processor.  PowerPCs, IIRC, can use PC-relative addressing for a branch, while MIPS is always absolute.  I can verify this if you want.
11:13:34 * kc5tja may be wrong on the MIPS aspect.
11:13:39 <futhin> tathi: how many woudl you buy?
11:13:58 <kc5tja> futhin: 20 -- no reason not to at that kind of price.
11:14:17 <kc5tja> Though, I would also need to have a project for it too.
11:14:22 <futhin> yeah
11:14:28 <futhin> well i was talking to chuck moore
11:14:33 <kc5tja> I already have 7 65816 chips... :)  Still haven't used one of them yet though.
11:14:51 <futhin> about getting people together to buy forthchips..   because it costs 60 grand for 20,000 forthchips to be made
11:14:53 <tathi> I know PPC does, was just curious because I haven't used a processor that doesn't...
11:15:20 <kc5tja> tathi: Yeah; PPC's branch instructions have a bit reserved to tell it PC-relative or absolute.
11:15:29 <tathi> yup
11:15:33 <futhin> if i can get enough people together , we could buy a batch of forth chips..
11:15:36 <futhin> what do you think?
11:15:41 <futhin> 20,000 chips heh
11:15:45 <kc5tja> Well, that's a lot of people... :)
11:15:53 <kc5tja> Would this be the 25X or the P21?
11:16:08 <futhin> which is better?  i was thinking 25x..
11:16:12 <tathi> I'm doing a colorforth for PPC, so I'm reasonably familiar with the instruction set
11:16:30 <kc5tja> tathi: Cool  :)  Are you going to distribute the sources?  For MacOS X?
11:16:30 <tathi> not that I can quite disassemble arbitrary machine code from memory or anything, but... :)
11:16:41 <futhin> isn't 25X better than p21? :)
11:17:02 <kc5tja> futhin: Well, I don't know.  The P21 has a built-in video coprocessor.  The 25X, AFAIK, doesn't.  :)
11:17:19 <kc5tja> But the 25X appears to be a mean processing engine, though each cell is limited to what it can do.  
11:17:21 <tathi> I'm more thinking as an OS on its own, I'd like to play around with hardware drivers and such
11:17:33 <futhin> well lets say we do p21
11:18:21 <futhin> and everyone is willing to purchase 20 chips..
11:18:25 <futhin> we need 1000 people :P
11:18:29 <tathi> I currently have the basic engine running OK under Linux, but haven't made an actual colorforth editor yet
11:18:42 <kc5tja> Exactly.  That's why I said it'd be a huge investment to make.  :)
11:18:59 <futhin> that's why i'm wondering about getting some company involved
11:19:03 <kc5tja> tathi: Ahh.  Is it written in pure assembly?  I assume using gas for the assembler?
11:19:19 * kc5tja nods
11:19:23 <futhin> like, demonstrate to some company that a forthchip is the biggest bang for their buck..
11:19:29 <futhin> but what company?
11:19:37 <futhin> what is a forthchip good for?
11:19:47 <kc5tja> Embedded devices, certainly.
11:20:04 <futhin> yeah..
11:20:18 <futhin> is the forthchip a lot of bang for 3 bucks?
11:20:34 <futhin> i mean, how does it compare to other chips ?
11:20:38 <tathi> kc5: yes. I'm not aware of any decent assembler for PPC... :(
11:20:50 <kc5tja> I don't think the Forth chip is the problem; the trick is convincing them that they not only need to learn Forth, but that it's better than C, AND they need to learn GOOD Forth programming practices as well.  It's a huge learning curve for companies.
11:21:26 <futhin> a layer could be developed
11:21:59 <tathi> but then why bother using a forth chip rather than what they already have that's working fine?
11:22:00 <futhin> like that chip thingie that isn't actually x86 but has a translating layer
11:22:14 <futhin> because forthchip is cheaper with a bigger bang?
11:22:35 <kc5tja> Well, it's all in the marketing of the chip.
11:22:51 <kc5tja> One possibility for selling the 25X is as a field programmable multi-processor array.
11:23:10 <futhin> which means creating a spec sheet on what the forth chip is good for, how it compares to other chips in price and speed.. etc
11:23:14 <kc5tja> It's got enough on-board memory to support one important application: neural network simulation.
11:23:25 <futhin> hmmm
11:23:31 <kc5tja> Exactly.
11:23:40 <kc5tja> Another application is systolic processing.
11:23:58 <kc5tja> However, without good floating point hardware on it, it'll probably not sell too well.
11:24:08 <kc5tja> (it will for neural nets, but not for systolic processing)
11:25:35 <futhin> systolic?
11:25:41 <kc5tja> It's possible that it could be sold for low- to mid-grade DSP applications...
11:27:05 <kc5tja> A type of parallel processing that more closely resembles pipelining than superscalar architecture; however, it's also usually multidimensional (a systolic processor array can pipeline in multiple directions concurrently).  
11:29:20 <futhin> hmm
11:29:39 <futhin> ideally getting the forthchips would be more than 60,000
11:29:46 <futhin> 60,000 is the bare minimum
11:29:51 <futhin> we want to kick back some to chuck moore
11:29:59 <kc5tja> Absolutely.
11:31:54 <futhin> well it comes down to 1) getting all the info on the capabilities of p21 and 25x 2) checking markets and demand 3) creating presentation sheets 4) distributing them to possible companies..  etc etc
11:32:03 <futhin> a bunch of work :P
11:32:20 <kc5tja> Another potential market is the home hobbiest (in various fields including ham radio and other home electronics)
11:32:40 <futhin> but i know that goshawk REALLY wants some forthchips (i think he wants p21 specifically because he wants analog i/o)
11:32:59 <kc5tja> Well, then we need to get merchant licenses so we can legally sell these things too.  What am I going to do wit 20 25x chips?  :)
11:33:11 * kc5tja nods
11:33:20 <futhin> because he wants to do music stuff with them
11:33:27 <futhin> (another possible market.. )
11:33:37 <kc5tja> He could use the 25x for DSP, and P21s for actual I/O.  :)
11:33:44 <futhin> heh
11:34:06 <futhin> if we were getting 25x and p21 that would be 120,000 for 40,000 chips..
11:34:22 <kc5tja> All I know is that I could theoretically make a 4096-color NTSC/PAL capable video display device with 3 P21s.  With 6 of them, I could go true-color.
11:34:26 <futhin> it's basically:  5 thousand for 200 chips or 60 thousand for 20,000 chips
11:36:13 <futhin> how much would a true color display device normally cost?
11:36:20 <futhin> or the 4096 color one..
11:36:27 <kc5tja> They don't make them anymore.
11:36:58 <kc5tja> I suppose you could find yourself a cheap Trident video card that supports 16-million colors at 640x480 resolution for a couple bucks (it'd basically be the cost of gas to the local trash bin that you'd find one in)
11:37:08 <futhin> heh
11:37:22 <futhin> so no demand for p21 in the video card industry? :P
11:37:23 <kc5tja> I mean, that's how commoditized true color displays are today.
11:37:27 <kc5tja> No way.
11:37:50 <futhin> heh
11:37:50 <kc5tja> Not with 800MHz+ GPUs that can do floating point illumination and real-time ray-tracing (look at ATi's recent Radeon product)
11:38:04 <futhin> forthchips are faster :P
11:38:08 <futhin> ;)
11:38:11 <kc5tja> No, actually, they're not.
11:38:40 <kc5tja> MIPS is a meaningless measurement when you consider the global scale of a project.
11:39:42 <kc5tja> Sure, it executes billions of instructions per second aggregate, but each core is just a tad over 1 billion, and even then, the instructions are such low semantic content that the performance is cut down asymptotically by the number of instructions needed to compare with other CPUs.
11:39:45 <futhin> yes i'm aware that mips are meaningless, that's why when he says 800 mips or whatever, i still don't know if that's fast or not
11:39:56 <kc5tja> I didn't say 800 MIPs.
11:40:00 <kc5tja> I said 800MHz.
11:40:01 <kc5tja> :)
11:40:05 <kc5tja> Big difference.  :)
11:40:10 <futhin> he says 800 mips
11:40:12 <futhin> for his chips
11:40:14 <futhin> or something like that
11:40:22 <futhin> i'm not confusing mips with mhz
11:40:27 <futhin> mhz is the cpu clock thingie
11:40:50 * kc5tja nods
11:41:09 <kc5tja> This is why the learning curve is so high -- most people can easily predict performance based on clock rates and MIPs with existing CPUs.
11:41:13 --- join: dsmith (dsmith@oh-strongsvillecadent1-1c-245.clvhoh.adelphia.net) joined #forth
11:41:29 <kc5tja> With the Forth chips you must perform a global analysis, and that can't be done without actually completing the whole program.  :)
11:41:48 <kc5tja> Of course, you can predict performance, but that requires you to be intimately familiar with the chip's guts.
11:42:08 <futhin> what do you think about the possibility of having some C to forth translator packaged with the forthchips
11:42:14 <futhin> so that companies don't have to deal with the learning curve?
11:42:14 <kc5tja> And both of those require knowledge of good programming practices.
11:42:29 <futhin> wouldn't the forthchip/translator still be fast enough and cheap enough to be attractive?
11:42:50 <futhin> well actually
11:43:02 <kc5tja> I would have to think on that.  My initial response to that is that performance wouldn't be anywhere near what you'd expect it to be.
11:43:07 <futhin> if we do a high-level forth to forth translator that would be better :)
11:43:12 <kc5tja> It'd WORK, it just wouldn't work well.
11:43:32 <futhin> a high-level "forth-like" language could reduce the learning curve significantly
11:43:51 <kc5tja> Why bother?  Forth is already sufficiently high-level.  But it still requires good programmer knowledge.
11:43:55 <futhin> (i'm thinking of my first exposure to "forth"  thru MUF a high-level forth-like language that i learned within an hour)
11:44:43 <kc5tja> Ah, yes, this is why C would fail to perform well on a Forth chip -- lack of randomly addressible data stack.
11:45:02 <kc5tja> C's data stack would have to be emulated in RAM in order for it to work.
11:45:53 <kc5tja> It would probably perform about as well as last generation 80486/early generation Pentium processors.
11:46:04 <kc5tja> Assuming you don't access character data.
11:46:06 <kc5tja> :)
11:46:40 <futhin> hmm
11:46:49 <futhin> gotta find/create a market for forthchips :)
11:47:01 <futhin> and then more jobs will appear for forth programmers :P
11:47:43 <kc5tja> :)
11:49:23 <futhin> well i'm definitely interested in this issue
11:50:06 <futhin> and i think it would be neat to put together all this and find a few potential companies interested in forthchips, and get tell all the forthers of the world about being able to purchase forth chips at 3 bucks a piece
11:50:15 <futhin> and then there's the development kit 
11:50:39 <futhin> to work with the forthchip
11:51:27 <futhin> somewhere in here there's profit.  maybe not in the first stage, but in later stages of creating a forthchip market and so on..  
11:51:39 <futhin> chuck moore needs funding  i bet
11:52:50 <futhin> handheld computers with forthchips would be nice
11:53:02 <futhin> but personally, i _need_ a keyboard to interact with any computer properly
11:53:05 <futhin> heh
11:55:32 <futhin> marketing is a big thing
11:55:49 <futhin> forth was never really properly marketted
11:59:15 <kc5tja> Largely because Forth was never really pinned down as being any one thing.
11:59:34 <kc5tja> Hand-helds definitely is an application for Forth chips.  As are noiseless terminals of some kind.  
12:00:08 <kc5tja> (basically low powered terminals such that they do not need a [set of] cooling fan[s])
12:01:05 <futhin> how about selling really cheap handhelds to people in thirdworld countries? 
12:01:13 <dsmith> Forth also really shines in getting something to market quickly
12:01:15 <futhin> there must be some kind of demand heh
12:01:44 <kc5tja> I don't see that as a viable market.  I see renewable energy sources to be a substantially larger market there.  It's no use having PDAs over there if you can't power them.
12:01:59 <kc5tja> So many people can't even drink clean water.
12:02:40 <kc5tja> dsmith: The software aspect of it, certainly.  But I don't see the hardware doing that.  The bulk of the time will be spent in desigining the circuit board on which the CPU sits, frankly.
12:02:40 <futhin> well it could be solarpowered handheld computers
12:02:54 <kc5tja> futhin: That's like solar powered flashlights -- I don't see a market for that.
12:03:30 <dsmith> kc5tja: Yes
12:03:33 <futhin> uh, there are solar powered flashlights
12:03:41 <kc5tja> Besides that, you can get a Dragonball CPU for $7 or so, which includes everything you need except RAM -- I/O, digitizer support, LCD controller, etc.
12:03:44 <futhin> they charge up in the day and work at night
12:03:57 * kc5tja knows, but do you know how much a backlight sucks up?
12:04:17 <futhin> the handheld comp wouldn't have a backlight
12:04:18 <kc5tja> For a palm-top to be successful, it must be small, and a set of NiCd D-cells is just not small enough
12:04:39 <kc5tja> Well, you still need to retain memory contents.
12:05:17 <futhin> 100 gig harddrive! :P
12:05:41 <kc5tja> OK, whatever.
12:06:01 <futhin> yeah i was just being silly
12:06:09 <futhin> yeah you are right
12:06:24 <futhin> the whole handheld thing for thirdworld countries isn't really that viable
12:06:34 <kc5tja> However, here IS a potential market for them: desktop computers.
12:06:46 <kc5tja> Sure, it's not PC compatible, but it doesn't draw 300W of power either.
12:06:52 <futhin> forthchips?
12:06:53 <kc5tja> And it's quiet.
12:06:56 * kc5tja nods
12:07:06 <kc5tja> Unless you want to do CPU emulation a la Transmeta style.
12:07:16 <futhin> forthchip desktop computer, forth os, etc ?
12:07:17 <kc5tja> 25x might be able to keep up with that -- might.
12:07:23 <kc5tja> Sure, why not?
12:07:36 <futhin> sure, i'm willing to do that
12:07:45 <futhin> i mean, i really support a forth os
12:07:52 <kc5tja> Using 3 P21s to generate 4096 color true-color video, a 25X for the main processing core, for a total of 28 CPUs.
12:07:56 <futhin> it would be the killer app for the language
12:08:09 <futhin> and the language would be BETTER because it has been EXTENDED
12:08:24 <kc5tja> A PalmOS-like operating environment set up by the Forth kernel, employing (semi-)persistence, etc.
12:08:28 <futhin> the language gets better the bigger it gets (sort of)
12:09:06 <kc5tja> And instead of floppy drives or ZIP drives, it'd use compact flash (basically solid state IDE storage), so it makes the software that much more trivial.
12:09:31 <futhin> um
12:09:41 <futhin> so what's the appeal of the desktop pc itself?
12:09:50 <kc5tja> It draws 3W instead of 300W.
12:09:51 <futhin> (besides the forth os)
12:10:03 <futhin> okay..  and is it really cheap?  is it small?
12:10:05 <kc5tja> Remember, third-world countries aren't rich, and they pay through the *nose* for power.
12:10:38 <kc5tja> Well, I envision that they'd be able to use an off-the-shelf ATX case, to keep *our* expenses low.
12:10:56 <kc5tja> That would allow us to create the custom power supply and motherboard needed to fit the ATX cost competitively.
12:11:17 <futhin> hmm
12:11:28 <kc5tja> There's even a *small* market for such machines (I emphasize small) in the States and maybe in Europe too.
12:12:07 <kc5tja> Basically people who don't want noisy desktop PCs.
12:13:46 <futhin> well i don't really notice my desktop pc being that noisy..
12:13:47 <futhin> heh
12:14:07 <kc5tja> My home PC isn't very noisy, but my PC at work certainly is.
12:14:18 <kc5tja> And the funny thing is, I have more fans on my home PC than I do on the one at work.
12:14:43 <kc5tja> The key to making it successful is to make it a completely open architecture though.
12:14:44 <kc5tja> COMPLETELY.
12:14:50 <kc5tja> All hardware documented.
12:14:56 <kc5tja> Right down to the electrical specifications.
12:15:01 <kc5tja> All software documented.
12:15:17 <kc5tja> Right down to the register/assembly language level.
12:15:43 <kc5tja> Provide expansion ports (whether they be PCMCIA, PCI, or even a proprietary standard), again, all documented.
12:15:54 <kc5tja> Basically, it needs to be the next Commodore 64.
12:16:22 <futhin> how cheap do you think a forthchip desktop pc is going to be?  
12:16:25 <kc5tja> Or at least the next Amiga.
12:16:40 <kc5tja> That depends on many things.  It all hinges on how cheaply we can get the PC boards for.
12:16:46 <kc5tja> The smaller the boards, the cheaper they will be.
12:16:52 <kc5tja> I don't have much pricing information on that.
12:16:56 <futhin> how fast is a 25X compared to a pentium 75mhz?
12:17:02 <futhin> i mean
12:17:06 <futhin> if theres a forth os
12:17:26 <kc5tja> For native Forth-written software that uses the 25X to its fullest potential, unbelievably fast.  Pentium has two execution units; the 25X has 25.  :)
12:17:28 <futhin> running on the 25x, and windowz 95 on p75, are they going to be comparable speed?
12:17:41 <futhin> plus
12:17:45 <kc5tja> Way faster.
12:17:48 <futhin> we can add another 25x cpu
12:17:49 <kc5tja> THe software alone guarantees that.
12:17:51 <futhin> for 3 bucks
12:17:52 <futhin> :)
12:18:01 <futhin> we could have 4 25x chips
12:18:20 --- quit: dsmith ("later..")
12:18:33 <futhin> hmm
12:18:40 <futhin> this is exciting! ;)
12:18:41 --- join: CrowKiller (Vapo_Rulez@cnq5-233.cablevision.qc.ca) joined #forth
12:18:53 <futhin> and wouldn't it be fun to hire chuck moore to help us code the os!!!
12:19:19 <CrowKiller> lol
12:19:29 <kc5tja> Heheh :)
12:19:55 <futhin> i mean, it'd be blazing fast! :D
12:19:59 <CrowKiller> no need for an os
12:20:58 <futhin> crowkiller: kc5tja and I were talking about a forthchip desktop computer.  a few 25X chips on the motherboard, and a 3 P21s for 4096 true-color display
12:21:16 <futhin> crowkiller: and selling this desktop computer to thirdworld countries because of the low-power consumption
12:21:29 <kc5tja> CrowKiller: The lack of an OS necessarily makes any software you load onto the machine an operating system.  "Not needing an OS" is a self-referentially mutually exclusive term.
12:22:06 <CrowKiller> a calculator solar cell could power a whole workstation
12:22:21 <futhin> possibly :)
12:22:23 <CrowKiller> maybe not with a screen attached
12:22:28 <futhin> about 3 watts or something..
12:22:32 <futhin> except for the monitor
12:22:40 <futhin> which is a separate issue i imagine..
12:23:24 <CrowKiller> kc5tja: then "no need for OS-ish standards" is what I truly meant
12:23:28 <futhin> what do we do about the monitor ??
12:23:42 <futhin> for the desktop
12:23:49 <CrowKiller> hmmm
12:23:55 <CrowKiller> morse piezoelectric beeper lol
12:23:57 <futhin> crowkiller: we need to set some kind of standard anyways
12:24:01 <futhin> heheh
12:24:14 <futhin> etch a sketch
12:24:17 <futhin> it's possible
12:24:22 <futhin> we could attach a motor
12:24:24 <futhin> ;)
12:24:29 <futhin> and it'll draw out something
12:24:46 <kc5tja> CrowKiller: I disagree with that.
12:25:14 <CrowKiller> don't know if OLED plasma screen would do the trick
12:25:58 <kc5tja> futhin: That is an issue that is beyond our control.  A non-backlit, reflective color LCD would draw a *lot* less power than a backlit one.  And Sony's Clie demonstrates that it's very possible to get excellent color with such a reflective system.
12:26:22 <kc5tja> However, if we're producing NTSC or PAL, we could just rely on the existing television equipment they have over there.
12:26:32 <futhin> hmmmmmm
12:26:44 <futhin> you really meant it when you said the next commodore 64 :P
12:26:48 <kc5tja> Otherwise, we're going to be needing some method of creating VGA quality video, and I'm not sure the P21s can go that fast.
12:27:19 <futhin> how much watts does a tv draw ?
12:27:27 <kc5tja> I know at least the F21s can, as thefox indicates on his website that he has attached it to a VGA monitor once.
12:27:33 <kc5tja> futhin: Depends on the TV.
12:27:37 <kc5tja> I can't answer that question.
12:27:53 <kc5tja> But even that is pushing the F21s I think...
12:28:02 <futhin> i don't even know the forthchip timeline
12:28:10 <futhin> what was the first forth chip produced? the 2nd, the third, etc?
12:28:17 <futhin> which came first? the p21 or the f21?
12:28:19 <kc5tja> MISC or non-MISC?
12:28:22 <kc5tja> P21
12:28:34 <kc5tja> F21 is Jeff Fox's version of the P21, and is vastly more sophisticated and capable.
12:28:51 <kc5tja> In fact, I should be saying 3 F21s and not P21s, because the P21's video output is analog only.
12:28:57 <futhin> so why were we limiting ourselves with P21 ??
12:29:03 <kc5tja> F21s have both analog and digital.
12:29:14 <kc5tja> Because that's what came to me.
12:29:21 <futhin> we can get them to fix the F21 problems and produce that with the 20,000 chip idea
12:29:29 <kc5tja> This whole project is pie in the sky right now anyway.  I see no real reason to get into specifics so early.
12:29:41 <futhin> :)
12:29:52 * futhin loves pies in the sky
12:30:00 <kc5tja> DEFER P21 ' F21 IS P21
12:30:06 <futhin> heh
12:31:05 <futhin> hmm
12:31:21 <futhin> and apparently there is the some advantages with the analog aspect of F21
12:31:26 <futhin> for music production and stuff
12:31:44 <futhin> imagine a forthchip desktop that also handled music production really well
12:31:50 <CrowKiller> the 10GHz echo timer (and faster versions) are truly great
12:31:56 <kc5tja> The F21 has the generic I/O coprocessor; I don't think the P21 does.
12:32:22 * kc5tja would use a separate F21 for that though, because video and audio on the same chip is loading it down, I think.
12:32:39 <futhin> yeah definitely..
12:32:52 <kc5tja> So:
12:32:54 <futhin> at 3 bucks a chip, we don't really need to be skimpy do we? :)
12:33:05 <kc5tja> 1 25X, 3 F21s for video, 2 F21s for audio and keyboard/mouse...
12:33:35 <kc5tja> with the high-end graphics workstation having 6 F21s for video (for 24-bit true-color support)
12:34:13 <kc5tja> So that's only 33 processors on the system.  Not bad.
12:34:28 <futhin> heh
12:34:33 <futhin> but i wouldn't count the 25X
12:34:34 <CrowKiller> I would love to see a more than 25X X chip in action, much like "million transistor" X chip
12:34:39 <futhin> er
12:34:44 <futhin> i mean
12:34:52 <kc5tja> CrowKiller: The point is to be inexpensive.
12:35:09 <futhin> i would count it as 3 + 2 + 1 chips = 6 chips = 12 bucks :)
12:35:31 <kc5tja> Well, sure, but that still doesn't change the fact that we have 33 processors on it.  25 of which are general purpose.
12:35:36 <futhin> yeah, shouldn't there be 4  25X chips :)
12:35:55 * kc5tja has *always* been a huge fan of having dedicated coprocessors doing as much of the workload of the CPU as possible.
12:36:32 <futhin> what i have been previously interested in is the ability to be able to build supercomputers by simply connecting a whole bunch of 386 chips together on some really flexible motherboard or something
12:36:41 <kc5tja> The audio F21s can be doing DSP, the video F21s can implement the bulk of the GUI (specifically, the scene graph), and the general purpose CPU(s) can be doing whatever is needed by the application(s).
12:37:20 <futhin> because nobody has apparently built a supercomputer by connecting a whole bunch of 386 chips or something like that on a lower level (i.e _not_ on a beowulf level)
12:37:28 <futhin> there must be some kind of obstacle..
12:37:29 <kc5tja> Yes they have.
12:37:34 <futhin> hardware wise..
12:37:36 <futhin> eh?
12:37:43 <kc5tja> Intel has a 4096 processor Pentium Pro supercomputer in Colorado.
12:37:47 <CrowKiller> did you guy know about mram?
12:38:07 <futhin> kc5tja: all the processors are on "one" motherboard or something like that ?
12:38:29 <kc5tja> No, but even with 4096 processors, neither would an F21 solution.
12:38:41 <kc5tja> But it's all in one chassis -- like a Cray supercomputer.
12:38:49 <CrowKiller> i saw an article about it in the mit technology review, ive been to Oshkosh, Wisconsin and I bought this magazine
12:39:05 <kc5tja> CrowKiller: No, never heard of mram.
12:39:07 <CrowKiller> its like dram but without the refreshing
12:39:09 <futhin> so what do they do?  a motherboard for each intel processor ?  and then they hook up all the motherboards ??
12:39:36 <kc5tja> Each motherboard has 16 processors, and they have a 256-slot PCI backplane (itself equipped with a Pentium Pro to bootstrap the system)
12:40:02 <futhin> well i'm just wondering about designing the "motherboard" of the forthchip desktop computer to be flexibil enough, that people could add 25X chips really easily, or take them out, or whatever..
12:40:31 <CrowKiller> in fact with gigabit ethernet and bewolf 2, clustering have never been easier
12:40:31 <futhin> maybe each 25X chip is on a separate board
12:40:33 <kc5tja> CrowKiller: That's easy enough -- make dram chips with built-in refresh.
12:40:37 <futhin> and you connect all the boards together
12:40:50 <CrowKiller> kc5tja: no refresh at all
12:41:08 <kc5tja> CrowKiller: Capacities are going to be abysmally small for the price then.
12:41:25 <kc5tja> CrowKiller: On-chip automatic refresh isn't hard to do, and doesn't steal cycles from the bus.
12:41:36 <CrowKiller> it use power
12:41:53 <kc5tja> CrowKiller: Not any more than static RAM does.
12:42:16 <kc5tja> futhin: Does each 25X have its own RAM, or does it use a global pool of RAM?
12:42:51 <futhin> no idea.. which is better..
12:43:00 <kc5tja> futhin: Depends on the application.
12:43:14 <futhin> well for a general purpose desktop computer..
12:43:19 <kc5tja> futhin: For general purpose computing, having a unified memory architecture is easier.
12:43:36 <futhin> oh.. i was thinking each 25x having its own ram
12:43:37 <CrowKiller> the mram chip are designed like this: conducting matrix - magnetic material at each intersection - insulator - magnetic material at each intersection - conducting matrice
12:43:39 <futhin> what about both
12:43:40 <kc5tja> futhin: Not a lot of software can take advantage of the parallelism that the 25X provides.  In fact, an embarrasingly small amount of it can.
12:43:48 <futhin> what about each 25x having some of its own ram
12:43:52 <futhin> and then global ram
12:43:53 <CrowKiller> erasing the chip is as easy as wiping a powerful magnet over it
12:44:16 <kc5tja> CrowKiller: So it's more like ROM than RAM...once written to, it can't be erased?
12:44:17 <CrowKiller> the spin of the electrons inside the magnetic materials enable or disable further lectron flows
12:44:22 <futhin> crowkiller: fortchips on mram ?
12:44:28 <CrowKiller> it can be rewritten
12:44:42 <kc5tja> futhin: It's the re-invention of magnetic bubble memory, basically.  :)
12:44:46 <CrowKiller> power up the two matrices and the intersection "bit" is rewritten
12:44:48 <kc5tja> Only faster.
12:45:00 <futhin> ahh.. i wondered where bubble memory went
12:45:11 <kc5tja> How does reading the mram perform?
12:45:16 <futhin> good to see it back i guess
12:45:19 <kc5tja> Is it like core memory, where reads are destructive?
12:45:33 <kc5tja> (hence the invention fo the term "move" instead of "copy" with respect to CPU registers!)
12:45:55 <kc5tja> If so, you still need to perform RAM refreshes (only they're done when reading, and not in the background)
12:45:58 <CrowKiller> one of the matrix get a current into it and resistance sensors at the border of the other matrix sense if current get through the magntic materials
12:45:59 <futhin> kc5tja: what about a hybrid?  global ram and ram for each 25x ?
12:46:32 <CrowKiller> no its not like core memory, truly like dram but instaed of using caps, its using sandwiched magnetic material
12:46:37 <kc5tja> futhin: That'll work, but isn't usually cost effective.  Again, how much weather simulation and parallel processing is the average desktop computer going to need?
12:46:46 <kc5tja> Well, with today's games, I take that back.  It can probably use it.  :)
12:47:12 <CrowKiller> genetic programming is a wonderful thing also, worth to be explored
12:47:24 <kc5tja> Also remember that some nodes of the 25X are going to be hardwired (via ROM) to act as chip bus interface signals, so not all 25X cores will be available for general purpose computing.  I forgot about that until just now.
12:47:48 <kc5tja> CrowKiller: Not in this context.  We leave that to the people who program our computer.  We just make the computer and provide the basic operating system for it.
12:47:52 <futhin> kc:  if its cheap enough, might as well strive for some flexibility in order to be ready to adapt to tomorrow's computing demands
12:48:27 * futhin is very interested in building the ultimate strategy game which is also deeply tied to very powerful economic simulation
12:48:31 <kc5tja> Well, what I'm saying is we already have some need for parallel processing today -- games.  And games DO help sell a platform (though I also recognize, we also need serious apps too)
12:49:01 <kc5tja> Video cards wouldn't have advanced GPUs on them if we didn't need that additional horsepower to render graphics on the flu.
12:49:03 <kc5tja> fly even
12:49:57 <kc5tja> The 25x -- does it have an external serial port?  Or do we need to devote a core to implementing it in software?
12:50:21 <kc5tja> Either way, we could just let each 25x have its own RAM, and communicate with every other 25x in the system via that serial port.
12:50:38 <CrowKiller> the new c18 has a B register
12:50:39 <kc5tja> (if we need to devote a 25x core to the port, we migth as well make it parallel just to hasten things along)
12:50:40 <futhin> pardon?  "do we need to devote a core to implementing it in software?"   ??
12:50:49 <kc5tja> The 25X has no bus interface.
12:50:54 <kc5tja> It must be implemented in software.
12:50:56 <CrowKiller> wonder if its only anothe a register or an interface to the networked bus
12:51:01 <kc5tja> Every pin on that chip is controlled by a 25X core.
12:51:03 <futhin> yes, probably
12:51:14 <futhin> yeah
12:51:17 <kc5tja> So we're going to need to devote a 25x core to inter-CPU communications.
12:51:25 <futhin> one or two of the cpu's need to be devoted to stuff
12:51:29 <kc5tja> CrowKiller: It's just another register.
12:51:36 <futhin> like inter-cpu communications, memory management, whatever
12:51:50 <kc5tja> Well, talking to SDRAM is definitely one of them, and I think that'll take more than one core.  
12:51:52 * kc5tja nods
12:52:17 <CrowKiller> mram is supposedly faster than dram and access is almost "instantaneous" as its written
12:52:27 <CrowKiller> i have the article right under my nose
12:52:27 <kc5tja> Another possibility -- if the 25X can talk to SDRAM quickly enough, we probably won't need the F21s for video, if we decide to use an external video DAC.
12:52:41 <futhin> external vidoe DAC?
12:52:51 <kc5tja> CrowKiller: Cost.  We can't adopt a technology just because "it's cool."  We need to stay in business after all.
12:52:51 <CrowKiller> www.technologyreview.com/visualize
12:53:05 <kc5tja> futhin: A digital to anaglog converter (DAC) that is outside the video chip.
12:53:14 <kc5tja> (Amiga 1000 did this, for example)
12:54:09 <CrowKiller> http://www.technologyreview.com/articles/visualize0702.asp
12:54:17 <CrowKiller> its the more specific link to mram
12:55:00 <futhin> kc:  so one of the 25x cpus dedicated to vido stuff instead of 3 f21s ??
12:56:38 <kc5tja> futhin: That's a possibility.  We have to examine the tradeoffs in greater detail, and without hardware specs available, I can't do that.
12:57:06 <futhin> isn'
12:57:11 <kc5tja> I *KNOW* I could do it with 3 F21s.  I *THINK* I can do it with a 25x chip (using the additional cores for systolic processing of video data to boot, for example, sprites and whatnot).
12:57:15 <futhin> isn't there some specs on 25X
12:57:17 <CrowKiller> how does the 25x interact with its pin?
12:57:22 <kc5tja> I have no idea.
12:57:27 <kc5tja> That's the problem.
12:57:27 <futhin> i'll go look
12:57:32 <kc5tja> NOBODY knows for sure except Chuck.
12:58:24 <futhin> http://www.colorforth.com/25x.html
12:58:30 <futhin> that is the best source i guess
12:58:31 <futhin> yeah
12:58:47 <futhin> we can talk to chuck, and chuck can redesign the chip and stuff like that
12:58:55 <futhin> it's probably customizable to an extent
12:59:39 <kc5tja> Each chip redesign he does has to be thoroughly tested.  Simulation isn't enough.
13:00:02 <kc5tja> And when you think about it, it's going to cost us a LOT more than the $60K to get a working batch of chips.
13:00:17 <kc5tja> Purely because of the need for testing and rejection of failed units.
13:00:29 <futhin> well naturally, if we are doing the desktop idea, that's a much bigger project :)
13:01:31 <kc5tja> The other thing is, does that price include packaging?  I'm almost positive that it doesn't.
13:03:06 <futhin> 3 bucks per chip doesn't include shipping and handling and development kit (how is anybody gonna do anything with the chip without some tools) and so on..
13:03:27 <kc5tja> No no
13:03:31 --- join: cleverdra (jfondren@65.142.111.19) joined #forth
13:03:42 <kc5tja> Packaging, as in, "I have a DIP chip with 64 pins," or "I have a PLCC with 88 pins."
13:03:56 <futhin> ????
13:04:04 <kc5tja> Chips come in packages.
13:04:10 <kc5tja> These packages have a number of pins on them.
13:04:14 <futhin> ahh
13:04:18 <futhin> okay
13:04:34 <futhin> hmm
13:04:36 <kc5tja> The arrangement of the pins, the quantity of the pins, and the material of the package itself all influence the final chip price.
13:05:18 <futhin> i dunno, maybe he did include the package heh..  (i hope he did) ;)
13:05:35 <kc5tja> (Not only would it be cool if we did this project, but it'd be even cooler if we did it with the company name of Commodore :) )
13:05:41 <futhin> heh
13:05:57 <kc5tja> Discussions with Jeff Fox indicates that packaging and pin management is an extra cost.
13:06:05 <futhin> and we'll call it the Commamiga ;)
13:06:17 <kc5tja> No way...Amiga is a very tightly protected name now-a-days.
13:06:21 <kc5tja> Just Commodore.  :)
13:06:23 <futhin> heh
13:06:40 <futhin> yeah, we should also avoid saying Forth too
13:06:43 <futhin> sort of 
13:07:04 <futhin> Commodore
13:07:18 <kc5tja> Well, we're going to have to mention it in the documentation at least.  But Certainly not on the package or in our PR.
13:07:22 <futhin> Commodore Sixy-Forth ;)
13:07:32 <futhin> 64th 
13:07:44 <futhin> yeah
13:08:13 * kc5tja also wants to move away from the numbering scheme of the 8-bit machines.  I love the Commodore 64/128 concept.  But those numbers are wildly outdated today.
13:08:20 <futhin> 3 25X chips.  75 cpus.  15 cpus dedicated to stuff.  60 cpus left over.   Commodore 60 Forth ;)
13:08:28 <kc5tja> Something like Commodore CX-1 or some such, that would work.
13:08:45 <futhin> well
13:08:55 <futhin> all of this sounds quite reasonable (for a pie in the sky project)
13:09:01 <futhin> :)
13:09:19 <futhin> so it sounds like funding is going to be a big component eh?
13:09:21 * kc5tja nods :)
13:09:28 <kc5tja> Funding is always the biggest component.
13:09:35 <kc5tja> Precisely why I'll probably never be involved. 
13:09:36 <futhin> heh
13:09:45 <futhin> eh?
13:10:00 <futhin> nm
13:10:03 <futhin> hmm..
13:10:32 <CrowKiller> wonder what size a chip like a c18 would be if computer printer size lithography would be used
13:11:36 <futhin> half a football field ?
13:11:47 <kc5tja> Nahh...  Not with today's 300DPI+ printers.
13:12:54 <CrowKiller> 1200dpi laser printer give great output, wonder if using transparent papers and cinductive ink to get a optical-electrical hybrid revolutionary computer lol
13:13:54 * CrowKiller wonder if its possible (last sentence written really fast and is really ugly)
13:15:17 <futhin> kc5tja:  there's different ways to go about launching this idea 1) get started selling something else, like sell the forthchips on a really basic level (get everything prepaid) and get some profit, go to the next stage, etc etc..   2) detail the idea, submit the idea to the patent office to be verified as evidence (costs 25 bucks, this is not a patent, just prior evidence), sell the idea to some company
13:15:43 <kc5tja> Not to cast true resurrection on a dead horse, but I just found out the MIPS architecture does not have PC-relative addressing.  We now return back to our currently scheduled discussion.
13:16:07 <futhin> heh, scheduled discussion ;)
13:16:28 --- mode: ChanServ set +o futhin
13:16:59 --- topic: set to 'Scheduled discussion at 2pm | Is the Forth strong in you? | x86 Linux Forth coded in asm - http://isforth.clss.net | home of forth - http://www.ultratechnology.com' by futhin
13:17:09 <futhin> deliberately vague about what timezone ;)
13:17:23 <futhin> bah, does the channel topic suck or what ??
13:17:47 <kc5tja> What is scheduled for 2PM?
13:17:49 <CrowKiller> dont have anything to say about it
13:18:25 <futhin> nothing
13:18:39 <kc5tja> Oh, you're referring to our "regularly scheduled" discussion.  I see.
13:18:45 <futhin> it's just a joke heh
13:19:02 <futhin> hopefully somebody is talking at 2pm for every time zone
13:19:08 <futhin> then it would apply
13:19:47 <futhin> Chosen to be the mirror image of an 18-bit cache memory chip. This is the fastest memory available, with 4 ns access. Its package is a 100-pin SOIC. The 18-bit Multicomputer thus has 256K words of external memory in 1 chip. 
13:19:47 <futhin> Putting the Multicomputer chip on the top of a 2-sided PCB and the SRAM chip on the bottom gives a very small footprint. A decoupling capacitor is the only other component needed. An array of such pairs is a multicomputer board. Connecting Multicomputer to SRAM is trivial, with mm traces. Routing for power and a serial network is also easy. Computers load code from the network. 
13:19:47 <futhin> A parallel computer with 60Gips nodes! Power is determined by the SRAM. 
13:20:29 <futhin> hmm
13:20:43 <kc5tja> Hmm...256K words isn't a lot... :/
13:21:01 <futhin> thinking about a desktop computer with a bunch of 25x 
13:21:16 <futhin> it could be pretty crash-resistant 
13:21:22 <futhin> and secure..
13:21:37 <futhin> like one 25x would be really secure and all the non-trusted code run on the other 25x or whatever
13:21:39 <kc5tja> I don't see how it would be any more fo those than a single-CPU system.
13:21:42 <futhin> or on the other core or whatever
13:22:04 <kc5tja> So this CPU is designed specifically for local-only SRAM.  Whatever -- that works out either way.
13:22:12 <futhin> A 7 sq mm die, packaged, will cost about $1 in quantity 1,000,000. Cost per Mip is 0. 
13:23:19 <kc5tja> Well, here's probably how we'd architect it.
13:23:59 <kc5tja> We'd have a single 25x acting as a CPU allocation controller, and at least one other 25x in the system as a processing farm.  Basically any number of CPUs can be in the system, as long as it's at least 2 (one for management, one for processing).
13:24:24 <kc5tja> Applications would be written in a manner that allowed them to easily be split across multiple CPUs.
13:24:51 <kc5tja> This way, if you want faster performance, depending on how the application was written, you only need to add more CPUs to the CPU farm.
13:25:08 <kc5tja> The applications themselves do not physically change.
13:25:29 <kc5tja> THis also means the Forth compiler sits on the master CPU, and not on the slaves.
13:25:43 <kc5tja> However, a copy of the Forth environment will be needed on all the slaves as well to enable the compiled binaries to run.
13:28:00 <kc5tja> Each 256K-word memory is equivalent to just a tad over 0.5MB.  I take that back -- it's not as bad as I thought it was.  Plus the fact that primitives are only 5 bits wide...that does allow for some nice code density.
13:28:55 <kc5tja> However, working in terms of words all the time can be a bit annoying.  Especially when you work predominently with smaller numbers.
13:32:49 --- join: futhin_ (~thin@h24-64-175-61.cg.shawcable.net) joined #forth
13:46:26 --- quit: futhin (Read error: 110 (Connection timed out))
15:07:43 <CrowKiller> I have almost finished my small compiler, it will surely fit under 512 bytes, it will implement the C18 macros with some tweaks
15:08:10 <futhin_> "compiler" ?
15:08:15 <futhin_> is it a forth implementation or not?
15:08:22 <futhin_> heh
15:08:36 <futhin_> or is it the equivalent to the COMPILE word?
15:09:50 <CrowKiller> compiler of preparsed source code
15:09:55 <CrowKiller> much like colorforth and aha
15:11:02 <CrowKiller> use the c18 instruction set with some minor twists and the aha inspired way of tokenizing
16:20:17 --- quit: cleverdra (Connection timed out)
17:02:44 <kc5tja> That's OK; I'm working on my Forth's text input routines.
17:03:26 <futhin_> hey that reminds me
17:03:30 <futhin_> i was interested in your editor
17:03:43 <kc5tja> You mean VIBE?
17:03:43 <futhin_> i'm curious how binding the keys to fortwords makes it more simple
17:03:55 <futhin_> s/fortwords/forth words
17:04:23 <futhin_> is it a full-screen editor like EDIT.COM or is it a command-line editor?
17:04:34 <kc5tja> It's like PygmyForth's block editor.
17:04:39 <kc5tja> It's not a general purpose text editor.
17:04:59 <kc5tja> In fact, that's what its name stands for: VI-like Block Editor (VIBE)
17:05:10 <futhin_> i liked pygmy's editor
17:05:13 <futhin_> sort of
17:05:19 <futhin_> i prefer edit.com
17:05:25 <futhin_> but pygmy's editor wasn't bad
17:05:31 <kc5tja> They're two completely different worlds
17:05:36 <kc5tja> One edits blocks, the other files.
17:06:02 <futhin_> well i'm more interested in the interface and stuff
17:06:17 <futhin_> surely VIBE could be adapted to edit files without too much problem?
17:06:30 <futhin_> i'm interested in a file editor
17:06:49 <kc5tja> No, it can't.
17:06:57 <kc5tja> It relies heavily on blocks.
17:07:11 <futhin_> okay
17:07:39 <futhin_> how does the binding of keys to forthwords simplify it?  would that apply to a file editor?
17:07:48 * kc5tja was considering writing a VI-like screen editor (VISE) for my Forth environment, but I'm just not to that point yet.
17:08:21 <kc5tja> I'm not sure how I can answer that question.
17:08:29 <kc5tja> It's so obvious to me that it escapes description.
17:09:01 <futhin_> well which keys are you binding
17:09:03 <futhin_> all of them?
17:09:04 <kc5tja> You have a bunch of words in the Forth dictionary.  When a user hits a key on the keyboard, it's mapped to a Forth word.  The editor simply then EXECUTEs the word.
17:09:05 <futhin_> or just a few?
17:09:23 <kc5tja> Depends on operating mode.  In Insert mode, only CTRL-keys are mapped.  In command mode, all keys are mapped.
17:09:44 <kc5tja> Keys which do not have a matching word simply do nothing (except beep to let the user know that a binding doesn't exist).
17:09:47 <futhin_> so i hit "a" and editor executes the word its mapped to?
17:09:57 <kc5tja> Which mode are you referring to?
17:10:00 <futhin_> command
17:10:03 <kc5tja> Yes.
17:10:13 <kc5tja> It will be mapped to the Forth word \a
17:10:48 <futhin_> okay, what does the code for \a do? (or look like)
17:10:58 <kc5tja> To redefine the activity of the 'a' command (or to define it if non existed prior), just define a new word \a and populate it with your new code.
17:11:07 <futhin_> hm
17:11:08 <kc5tja> Well, \a doesn't exist in VIBE -- I don't have a use for it.
17:11:17 <kc5tja> But h, j, k, and l are mapped to cursor movements.
17:11:22 <futhin_> oh
17:11:22 <futhin_> i see
17:11:22 <kc5tja> : \h   CursorLeft ;
17:11:27 <kc5tja> : \j   CursorUp ;
17:11:33 <kc5tja> : \k   CursorDown ;
17:11:35 <futhin_> so in insert mode
17:11:37 <futhin_> when you type a
17:11:39 <kc5tja> : \l   CursorRight ;
17:11:42 <futhin_> it goes straight to the screen
17:11:48 <kc5tja> Yes.
17:11:56 <kc5tja> Only control characters are mapped.
17:12:07 <kc5tja> So if you hit CTRL-A, it would be mapped it /A
17:12:13 <kc5tja> (note the forward slash)
17:12:24 <futhin_> why not ^A ? :P
17:12:29 <kc5tja> No.  
17:12:44 <kc5tja> So the mappings to switch between insert and command mode looks like this:
17:12:49 <kc5tja> : /[   CommandMode ;
17:12:53 <kc5tja> : \i   InsertMode ;
17:13:00 <futhin_> you know how its common for ctrl-<letter> to appear as ^<letter>
17:13:16 <kc5tja> (there are some minor differences between what I'm posting and what's actually in the file, but you get the idea.)
17:13:26 <kc5tja> I know, and I don't care.
17:13:41 <kc5tja> CTRL-A in command mode might be totally different than CTRL-A in insert mode.
17:13:46 <futhin_> yeah that's fine :)
17:14:45 <kc5tja> But it's easier mostly on the user, because if the user wants to augment or replace the functionality of a command, he just redefines it.  No need for updating pesky command tables or executing boilerplate code to "wedge" the command into the editor's command translation mechanism.
17:15:12 <kc5tja> The behavior of the editor can be completely remapped without having to recompile the editor -- ever.
17:15:17 <futhin_> i've never really gotten into VI
17:15:20 <kc5tja> I can make it behave like Emacs if  I wanted to.
17:15:36 <futhin_> is it really more efficient to work with than edit.com?
17:15:49 <kc5tja> That's a personal choice.  I can't answer that.
17:15:59 <CrowKiller> the dictionary enable maximum reconfigurability
17:15:59 <futhin_> i'm very used to ctrl-c ctrl-x ctrl-v
17:16:06 <kc5tja> I type 90+ WPM, and VI is bar none the single best text editor I've ever used.  It's the fastest editor I've used as well.
17:16:07 <CrowKiller> me too
17:16:15 <CrowKiller> and using arrows + shift to select text
17:16:18 <kc5tja> Edit.com, Emacs, Q-Edit, et. al. are no comparison -- FOR ME.
17:16:19 <futhin_> yes
17:16:24 <futhin_> and ctrl to select
17:16:26 <kc5tja> You might have different needs/tastes.
17:16:36 <futhin_> i cut'n'paste and select a lot
17:16:39 <futhin_> or i type
17:16:43 <futhin_> that's all i do in an editor
17:17:05 <kc5tja> I like VI because all of its commands are accessible from the standard QWERTY keys.  No need for function keys, no need for arrow keys, etc.  As a touch-typist, I really appreciate this.
17:17:25 <futhin_> I find that VI seems a little awkward to select whole paragraphs and move them around quickly.. but i am not familiar with it yet
17:17:27 <kc5tja> I also chose VI because it's extremely portable for that very reason -- it doesn't rely on environmental dependencies.
17:17:56 <CrowKiller> I was 5 years old when I started to use the ctrl commands, im totally brainwashed ;p
17:18:02 <kc5tja> futhin_: Different VI clones have different facilities.  Use VIM; it's the most featureful of all the VI editors.  It does more than any other VI clone in the world.  A close second is Elvis.
17:18:17 <CrowKiller> hope my kids will have better editors hehe
17:18:19 <kc5tja> CrowKiller: So was I.  Then I grew out of my ancient ways, and I saw the light.
17:19:28 <kc5tja> I like software that doesn't get in my way.  VI(M/BE) does exactly that.
17:20:06 <CrowKiller> in my editor its clear that I use the "search from top til found" circular dictionary construct, it enables maximum reconfigurability with the less hassle
17:20:46 <CrowKiller> i'll try to map function to one key only, to break free from my dependence to ctrl
17:21:33 <CrowKiller> who knows, maybe the guy who got his hand cut off
17:21:40 <CrowKiller> will find this useful ;p
17:21:46 <kc5tja> Well, with PygmyForth, you can bind the function keys and arrow keys to functionality because it provides a single keycode for them.  This doesn't happen under GForth, so I didn't bother with it.
17:22:35 <kc5tja> Meta-keys like CTRL and SHIFT aren't bad.  It's just that I like having a good modal user interface to a text editor.  If I'm editing a document, CTRL-keys are sometimes handy when in insert mode.  But those should be reserved only for the most frequent of operations.
17:23:19 <kc5tja> When in command-mode, I have much more I can do.  I no longer have to map EVERYTHING to cryptic control keys.  Now I have CTRL-keys in insert mode PLUS CTRL-keys in command mode PLUS regular keys in command-mode -- I've effectively tripled the command space for my editor.
17:24:40 <CrowKiller> like chuck switching keyboard function using his thumb
17:24:41 <kc5tja> Hmm...I think I've finally arrived at an architecture I'm happy with for text input on FS/Forth.
17:24:57 <futhin_> ah, what is it like?
17:25:23 <kc5tja> Well, it's a small variation of what we've been talking about, actually.  :-)
17:25:35 <kc5tja> From top down:
17:25:55 <kc5tja> : ReadLine ( buf -- )   BEGIN KEY DUP ReadLineKeyHandler EXECUTE ( done? ) UNTIL DROP ;
17:26:55 <kc5tja> : ReadLineHandler ( k -- xt )   DUP 31 U> ['] PlaceCharacter AND SWAP CELLS ReadLineHandlerTable + @ OR ;
17:27:59 <kc5tja> : PlaceCharacter ( buf k -- 0 )   SWAP DUP Buffer.Length @ OVER Buffer.MaxSize @ U<= IF (PlaceCharacter) ELSE 2DROP THEN 0 ;
17:28:41 <kc5tja> : (PlaceCharacter) ( k buf -- 0 )   2DUP DUP Buffer.Address @ SWAP Buffer.Length @ + C!   1 DUP Buffer.Length +!   DROP EMIT 0 ;
17:29:00 <kc5tja> : RL_BS ( buf k -- 0 )   ( backspace handling code here ) ;
17:29:10 <kc5tja> : RL_TAB ( buf k -- 0 )   ( Tab completion code here ) ;
17:29:24 <futhin_> do you use a lot of variables?
17:29:28 <kc5tja> : RL_CR ( buf k -- -1 )   2DROP -1 13 EMIT 10 EMIT ;
17:29:31 <kc5tja> No
17:29:47 <kc5tja> CREATE ReadLineHandlerTable 32 CELLS ALLOT
17:29:53 <kc5tja> ReadLineHandlerTable 32 CELLS 0 FILL
17:30:07 <kc5tja> ' RL_BS  8 CELLS ReadLineHandlerTable + !
17:30:16 <kc5tja> ' RL_TAB 9 CELLS ReadLineHandlerTable + !
17:30:24 <kc5tja> ; RL_CR  13 CELLS ReadLineHandlerTable + !
17:30:29 <kc5tja> There you go.
17:30:33 <kc5tja> Buffer.* are structure members.
17:31:17 <futhin_> hmm
17:31:51 <kc5tja> Basically, ReadLineHandler maps a keycode to an executable function.  If a control character, it looks it up in the key binding table (which I'm using only because I don't have full dictionary support in place yet).  Otherwise, it returns the function of PlaceCharacter directly.
17:32:45 <kc5tja> Note that Backspace (code 8), tab (code 9) and carriage return (code 13) are mapped via this table.  Note also that there is a bug in the above code where any other control character will map to the xt of 0, clearly a bug.  I'll need to fix that, but I can live with it for now as long as I'm careful.
17:33:21 <kc5tja> Basically by inserting DUP 0= ['] BEEP AND OR into the ReadLine definition.
17:34:06 <kc5tja> Again, note that FS/Forth doesn't have full dictionary support in place yet, so tab completion doesn't really do anything right now.  When I do get it in place, I can add it post-boot, without changing the remainder of the system code.
17:34:11 <kc5tja> I really like this elegance.
17:34:49 <futhin_> hmm :)
17:34:54 <futhin_> you should have up arrow
17:35:08 <futhin_> brings up what you previously typed :)
17:35:26 <futhin_> up arrow is my favorite invention ;)
17:36:24 <kc5tja> How can I?  What's the scan code for up arrow?
17:36:32 <kc5tja> I have no idea what it is.  :)
17:36:39 <kc5tja> That's very non-portable.
17:37:07 <kc5tja> Besides that, it doesn't map to the low-32 ASCII control codes at all.
17:37:35 <futhin_> the up arrow key has two control codes or something i think?
17:37:35 <kc5tja> I'd have to provide a full scale mapping, and that's hard to do, unless you use the dictionary itself to do it (which is what I do plan on doing, BTW)
17:37:41 <kc5tja> No
17:37:44 <kc5tja> It's got a plethora.
17:37:57 <kc5tja> ESC [ A for Unix, and a 16-code under DOS.
17:38:07 <kc5tja> (And under Pygmy in particular -- it's TOTALLY different under FPC)
17:38:16 <futhin_> the keyboard produces a signal
17:38:36 <kc5tja> Yes, I know how all this works.
17:38:37 <futhin_> you are reading the signal in FS/Forth aren't you?
17:38:48 <kc5tja> Yes.  Through BIOS.
17:38:49 <futhin_> for the enter key and so on
17:38:54 <kc5tja> (well, DOS techincally, but...)
17:39:08 <futhin_> so why not read the up arrow if you are reading the enter key?
17:39:19 <kc5tja> Because it doesn't map to the ASCII character set.
17:39:31 <kc5tja> I'd have to switch to a 16-bit character model if I want to do that.
17:39:36 <futhin_> hmm
17:39:39 <kc5tja> Eventually, it'll be there.   Not now, though.
17:39:41 <kc5tja> It's too early.
17:39:45 <kc5tja> I have to bootstrap the environment.
17:39:51 <futhin_> yeah :)
17:41:06 <kc5tja> Right now, the target compiler is producing code with word headers in a single linked list -- a single vocabulary.  I have no words defined to search it yet.  
17:41:46 <kc5tja> Moreover, when I do get that working, I really intend on having multiple vocabularies (so the line reader can have its mapping vocabulary, VIBE can have its own separate vocabulary, the compiler can have its own vocabulary [eliminating the need for IMMEDIATE], etc.
17:42:45 <kc5tja> What's cool is that we're all working and concentrating on different aspects of the Forth ideal.
17:42:52 <kc5tja> CrowKiller and Chuck are working with ColorForth.
17:43:11 <kc5tja> I'm concentrating on maximally exploiting the use of the dictionary.  I440r is working on compilation speed.  Etc.
17:43:23 <kc5tja> This is what I mean when I talk about "new ideas."
17:43:40 <kc5tja> Maybe in the future, when I'm ready for it, I'll make my own ColorForth dialect based on FS/Forth.
17:44:07 <kc5tja> I'm already using prefixes with FS/Forth's target compiler, and it's working out much better than using COMPILE or POSTPONE explicitly (note that I also hack Pygmy's dictionary to do this too!)
17:44:14 <futhin_> yeah, and i'm focusing on the lazy coder aspect of the forth ideal
17:44:18 <futhin_> and the forth os ;)
17:44:22 <kc5tja> Hehe :)
17:44:58 <kc5tja> I honestly have to say that not even Chuck exploits the dictionary to the degree that I do.  :)
17:46:18 <kc5tja> The other thing is I'm exploring the use of the A-register with my code too.  After I get the planned version of FS/Forth implemented, I'm going to re-write portions of the code using the A-register idea, and compare the resulting code.
17:46:45 <kc5tja> If it works out for me, I'll stick with it.  If not, well, it was fun trying.
17:46:53 * Robert shows his lack of knowledge by asking what the A-register is.
17:47:19 <futhin_> it's fictional!
17:47:19 <futhin_> ;)
17:47:27 <kc5tja> Not according to Chuck... :)
17:47:37 <kc5tja> The A register is the "address" register on the MuP21 and successor processors.
17:48:02 <kc5tja> It can be used for temporary storage or for addressing memory.  It also supports post-incrementing, so it can be used efficiently with strings of data.
17:48:21 <futhin_> so you will implement the A register in software at the bottom of FS/Forth ?
17:48:24 * kc5tja notes that the MuP21's top R-stack element works the same way too, so it really has two address pointer "registers."  :)
17:48:26 <futhin_> er
17:48:57 <kc5tja> It's a possibility.  I've experimented with it in the past in Pygmy, and it seems to have some merit.  But I also find it has a serious negative side effect: I find the resulting program code to be much harder to read with it.
17:49:01 <futhin_> is FS/Forth solely x86 or is it going to be portable?
17:49:34 <kc5tja> futhin_: It's retargetable, but x86-only right now.  To retarget it to a different processor, you must re-implement portions of its target compiler.
17:49:53 <futhin_> bbl
17:50:17 * kc5tja may consider releasing the FS/Forth target compiler sources in the future, even in their incomplete state, just to let people play with them.
17:50:41 <kc5tja> They're currently written in Pygmy Forth right now.
18:15:09 --- quit: tathi ("leaving")
18:19:58 --- quit: Soap` ()
18:22:43 <futhin_> don't i have a copy? ;)
18:23:10 <kc5tja> I don't recall giving you a copy of my target compiler.  I could be wrong though.
18:23:26 <futhin_> you did, but it was awhile ago, it's probably out of date
18:23:28 --- join: dsmith (dsmith@oh-strongsvillecadent1-1c-245.clvhoh.adelphia.net) joined #forth
18:23:48 <futhin_> don't worry, i won't release it :P
18:24:03 <kc5tja> I haven't changed it much.
18:24:15 <kc5tja> Especially if you have the BEGIN/AGAIN/WHILE/UNTIL/REPEAT words.
18:26:24 <futhin_> you sent it to me when i asked for an example of well written forth from you
18:26:57 <kc5tja> Huh?  I hardly consider my target compiler well written.  :)  It's a bootstrapping tool, and that's it.  :)
18:27:03 <kc5tja> I must have been on crack when I sent it to you.
18:27:27 <futhin_> well it was your only or biggest sample of forth code that you had?
18:30:43 <futhin_> hm..
18:31:05 <futhin_> \ FS/Forth Native Target Compiler
18:31:06 <futhin_> \ Release 2.0
18:31:40 <kc5tja> Oh no, the target compiler I have doesn't have a single \ comment in it.  Pygmy doesn't support those.  :)
18:32:03 <futhin_> i looked at it and didn't find it instantly understandable, and so i just shoved it somewhere on the harddrive to be ignored until a later date
18:32:24 <kc5tja> Probably a good idea for the time being.  :)
18:32:34 <futhin_> you started a new target compiler ?
18:32:39 <kc5tja> Even the target compiler I'm working on now isn't terribly easy to read.
18:32:40 <kc5tja> Yes.
18:32:50 <futhin_> why?
18:33:00 <kc5tja> Native code for 80386 16-bit real mode.
18:33:14 <kc5tja> Because I wasn't happy with the previous generation.
18:33:46 <kc5tja> Not only was it direct threaded, I didn't like the way the dictionary was being structured.
18:34:07 <kc5tja> I decided to switch to a more cmForth-style, and now that I've done that, I'm generalizing it to support my multi-vocabulary system.
18:34:12 <futhin_> hmm
18:34:21 <futhin_> and you switched to pygmy?
18:34:23 <kc5tja> (which is still cmForth backward compatible of sorts; it still has Forth and Compiler wordsets)
18:34:27 <kc5tja> Yes.
18:34:27 <futhin_> what were you using before pygmy?
18:34:30 <kc5tja> GForth.
18:34:35 <futhin_> ah
18:34:47 <kc5tja> And I'm sorry, I just couldn't get used to GForth's lack of integration between the editor and the compiler.
18:34:55 <futhin_> do you like pygmy better than fpc?
18:35:02 <kc5tja> **WAY** better than FPC.
18:35:06 <futhin_> yeah, i don't really care for the gforth environment
18:35:07 <kc5tja> FPC is way too intimidating for me.
18:35:15 <futhin_> yeah
18:35:21 <futhin_> i did some coding in pygmy
18:35:24 <futhin_> and then switched to fpc
18:35:26 <kc5tja> Though now I know GForth well, I'm sure FPC won't be quite so bad.  But still...it just feels too bloated.
18:35:30 <futhin_> and i haven't done any coding since
18:35:49 <futhin_> i just don't find it easy and conducive to code in FPC :(
18:35:59 <futhin_> i definitely should switch back to pygmy
18:36:14 <kc5tja> I don't understand how anyone could code in FPC.  Unless you were doing *REALLY* commercial-level stuff, it was WAY overkill.
18:36:31 <kc5tja> I think it is the lack of suitable integration, again.
18:36:39 <futhin_> pygmy is more simple and is integrated better
18:36:42 <kc5tja> I couldn't just "peruse" the source code like I could with Pygmy.
18:36:47 <futhin_> i don't like FPC's help at all
18:37:02 <futhin_> i don't like how its done in fpc
18:37:07 --- quit: dsmith (Remote closed the connection)
18:37:54 <kc5tja> The more I work with software systems of various types, the more I find Chuck's opinions of available software environments (not only in general, but Forth systems in particular) to be true.
18:38:35 <futhin_> what's his opinion for forth systems ??
18:38:41 <kc5tja> They suck.  :)
18:38:57 <kc5tja> They're too big, they're too slow, they're completely missing the point.
18:39:14 <kc5tja> "30 year old technology" he calls them.
18:39:22 <futhin_> and pygmy forth misses the point less because its closer to cmforth ?
18:39:25 <CrowKiller> new motto maybe for the topic: "Forth: using bits without limits"
18:39:36 <kc5tja> And while my Forth certainly is still rooted in the state of the art 30 years ago, I'd like to think that I'm making some kind of innovation of my own.
18:39:51 <kc5tja> No, he'd be more happy with pygmy than with FPC.
18:39:52 --- nick: futhin_ -> futhin
18:40:07 <futhin> that's what i meant/said
18:40:11 <kc5tja> Pygmy is a self-contained, wholistically designed Forth environment.  FPC is a bolt-on to DOS.
18:40:13 <futhin> misses the point _less_
18:40:27 * kc5tja didn't read that in your original post, but yes; it misses the point less.
18:40:57 --- mode: ChanServ set +o futhin
18:41:01 <kc5tja> But he even thinks that cmForth is complex compared to his recent ColorForth implementations.
18:41:03 <CrowKiller> I would love to see more circular constructs, like circular stacks, circular dictionaries
18:41:15 --- topic: set to 'Forth: using bits without limits | Is the Forth strong in you? | x86 Linux Forth coded in asm - http://isforth.clss.net | home of forth - http://www.ultratechnology.com' by futhin
18:41:33 <kc5tja> CrowKiller: I was going to play with that for my x86-MF-II system too.
18:41:37 <Robert> What's the best way to do an infinite loop using standard forth words?
18:41:38 <CrowKiller> thanks futhin!
18:41:55 <kc5tja> Using the CPU registers as data stack elements (7 deep), with an infinite return stack (since it's in RAM anyway, and the CPU manages it, might as well!).
18:41:57 <CrowKiller> on the x86 i use begin and again
18:42:03 <CrowKiller> begin clal the word following him
18:42:21 <CrowKiller> and again: "push [ESP], ret"
18:42:21 --- topic: set to 'Forth: using bits without limits | x86 Linux Forth coded in asm - http://isforth.clss.net | home of forth - http://www.ultratechnology.com' by futhin
18:42:24 <kc5tja> Use this: : infinite-loop  begin again ; -- that'll lock it up hard.  :)
18:42:44 <Robert> Okay, thanks :)
18:42:50 <futhin> xef4 wanted something in the topic changed, but i don't know what and he hasn't been on at the same time i've been
18:44:17 * kc5tja doesn't believe in playing with the return stack in that manner.  The compiler is allowed to maintain some amount of state in my systems (usually on the data stack while compiling), so BEGIN is just an internal label, and AGAIN is just a jump back to that label.
18:44:55 <kc5tja> I found ANSI-style control flow to be *very* easy to implement in x86 and FS/Forth's target compiler.  Trivial even.
18:45:49 <CrowKiller> those are the lazyest macro I could think of "Begin: call $+5" and "Again: push [ESP], ret"
18:46:04 <CrowKiller> i dont know how ANSI do it
18:46:12 <kc5tja> BEGIN compiles nothing.
18:46:21 <kc5tja> AGAIN jumps back to the instruction after BEGIN.
18:46:29 <kc5tja> It's a simple JMP instruction.
18:46:46 <CrowKiller> but I didnt know how to implement it
18:46:54 <kc5tja> Ah.
18:46:57 <kc5tja> : BEGIN   HERE ;
18:47:04 <CrowKiller> the again word search for begin?
18:47:21 <kc5tja> : AGAIN   $E8 C, HERE 2 + SWAP - , ;
18:48:19 <kc5tja> BEGIN pushes the address of the next instruction to be compiled onto the compiler's data stack.
18:48:28 <kc5tja> AGAIN uses that to compute an effective address for the x86 JMP instruction.
18:48:37 <kc5tja> (change 2 + to 4 + for 32-bit implementations)
18:48:57 <CrowKiller> no its the same, e8 then byte offset
18:49:16 <kc5tja> Yes, but you need to compute a PC-relative address.
18:49:29 <kc5tja> HERE 2 + SWAP - does that for 16-bit mode, and HERE 4 + SWAP - for 32-bit mode.
18:50:39 --- join: Speuler (~l@pD950252F.dip.t-dialin.net) joined #forth
18:50:49 <CrowKiller> but 2 and 4 are not measured byte counts? when I look at the listing of NASM, its always two more
18:50:50 <Robert> Hoi :)
18:50:53 <kc5tja> UNTIL is exactly the same as AGAIN, except it's a JZ instruction instead of JMP.
18:51:01 <CrowKiller> and all my code is in 32 bit pmode
18:51:03 <kc5tja> Look at what the code is doing.
18:51:11 <kc5tja> $E8 C, writes the JMP opcode to the dictionary.
18:51:19 <kc5tja> Thus, HERE now points to the offset of that JMP.
18:51:29 <kc5tja> That offset is 2-bytes long in 16-bit mode, and 4-bytes long in 32-bit mode.
18:52:03 <kc5tja> Since the branch target is relative to the next succeeding instruction (that is, HERE n +, where n is either 2 or 4 respectively), then we have to account for that.
18:52:03 <CrowKiller> sorry i never played with word like c,
18:52:38 <kc5tja> It's exactly like , except it writes a single character to the dictionary (it probably won't exist on x21-based Forths because the x21 series of CPUs don't have characters)
18:52:54 <kc5tja> In the case of x86 Forths, it writes an 8-bit value to the dictionary.
18:53:41 <CrowKiller> I use the esi edi register pair (and a clean direction flag) to enable the use string operators like movsb, I dont have a data stack in my compiler
18:53:58 <kc5tja> Mine does.  :)
18:54:10 <CrowKiller> i try to stick to the hardware as close as possible and it got support for two arrays referenced by two pointers
18:54:24 <CrowKiller> it keeps a 4 or 5 byte sequence 1 byte large
18:54:29 * kc5tja prefers to stick with the normal Forth way of doing things.
18:54:50 * kc5tja takes advantage of the split compile-time and interpret-time capabilities of Forth.
18:55:21 <CrowKiller> yes, it troubled me a little but i specify in the code where compile and runtime start and ends
18:55:37 <kc5tja> The compiler still has to exist.
18:55:39 <CrowKiller> between modes the register usage change
18:55:59 <CrowKiller> thats why I emphasize on mode changes
18:56:05 <kc5tja> Well, you do what you do, and I'll do what I'll do, and let's keep it at that.
18:56:15 * kc5tja doesn't want to get into any philosophical battles about this.
18:56:22 <CrowKiller> I know, im not trying to convince you
18:56:23 <CrowKiller> ;pp
18:56:31 <CrowKiller> me neither
18:56:55 <CrowKiller> I want to do things differently also ;o)
18:57:27 <CrowKiller> but I hope we could confront each others with real benchmarks when our systems are finished
18:57:32 <CrowKiller> would be very exciting ;ppp
18:57:46 <futhin> what kind of benchmarks?
18:57:49 <futhin> usability benchmarks?
18:58:01 <futhin> philosophical benchmarks?
18:58:05 <futhin> popularity benchmarks?
18:58:05 <kc5tja> :)
18:58:25 <futhin> obviously any other benchmarks are silly nonsense :P
18:58:38 <kc5tja> All of the above mentioned benchmarks are themselves silly nonsense.
18:58:45 <kc5tja> That's why I don't want to go any further in the discussion.
18:58:51 <futhin> not usability benchmarks!
18:58:53 <kc5tja> (or at least, that thread of the discussion)
18:58:58 <CrowKiller> small contests, like the olympics
18:59:07 <futhin> kc: i wasn't talking to you about the benchmarks heh
18:59:09 <CrowKiller> fastest, smallest
18:59:14 <futhin> and i was being a little silly
18:59:38 <kc5tja> Well, that's going to be hard.
18:59:55 <CrowKiller> give a processor and a job to do then compare
19:00:04 <kc5tja> Because while my BEGIN/AGAIN is rather well "optimized," the normal code execution path is hardly.  There's tons of duplicate add/sub pairs, and redundent stack pushes and pops.
19:00:37 <kc5tja> It's going to take some amount of time before my target compiler produces code anything near what a C compiler would produce, let alone with full optimizations enabled.
19:00:43 <kc5tja> s/C compiler/unoptimized C compiler/
19:01:40 <CrowKiller> I use in my macros "?dup", like Chuck uses, it removes the apparent "drop dup" fat
19:02:01 <CrowKiller> its a small optimization but its a start ;p
19:02:09 <kc5tja> My code doesn't attempt to optimize anything at all.
19:02:11 <kc5tja> Literally.
19:02:22 <kc5tja> I strictly wanted correctness, at any cost.
19:02:30 <kc5tja> So while my code is slow, it's provably correct.
19:02:32 <futhin> i want readability at any cost
19:02:46 <kc5tja> futhin: That's an *ENTIRELY* different goalset.
19:02:48 <futhin> i want a C coder to be able to instantly understand all forth code ;)
19:02:52 <kc5tja> Completely orthogonal.
19:03:00 <futhin> :D
19:03:01 <CrowKiller> i think that optimization satisfies those criterias
19:03:09 <kc5tja> futhin: That'll never happen; each language has its own learning curve, and that simply has to be accepted.
19:03:12 <futhin> completely orthogonal to correctness ????
19:03:15 <kc5tja> Yes.
19:03:23 <kc5tja> I've seen plenty of readable, incorrect languages (BASIC).
19:03:25 <futhin> a readable program is most likely a correct program
19:03:34 <kc5tja> I've seen plenty of undecipherable, correct languages (APL)
19:03:34 <futhin> incorrect language
19:03:37 <futhin> incorrect language?
19:03:49 <kc5tja> An incorrect language is a language that does not strictly obey its specifications.
19:03:49 <CrowKiller> I would not like someone disassembling my compiler's output and see "drop dup" every line or so ;p
19:03:53 <kc5tja> E.g., interpretter bugs.
19:04:37 <kc5tja> CrowKiller: no, optimization doesn't satisfy those criteria, unless you are specifically intending the machine code output for human consumption.
19:04:47 <kc5tja> I am not doing this.  In fact, I don't even have an assembler in my Forth's target compiler.
19:05:01 <kc5tja> It goes from Forth code to binary object code -- no intervening assemblers are used.
19:06:21 <kc5tja> When I write a complex Forth word, I expect it to work the same across FS/Forth, GForth, and Pygmy Forth.  That's requires a correct language, and in order to have a correct language, you must have a bug-free compiler.  
19:06:34 <kc5tja> Chuck Moore himself is fond of writing, "Make it so simple, it has to work."
19:06:41 <kc5tja> That's what I did with my compiler.
19:06:51 <kc5tja> It's so simple, there is *zero* chance of failure.  But the price is performance.
19:07:04 <Speuler> kc5tja: an assemblers is great for interfacing cpu specific capabilities to forth 
19:07:07 <kc5tja> When I start introducing optimizations, that will start to change.  I'm positive bugs will start to be introduced.
19:07:14 <CrowKiller> me neither, only all the primitives that start with "dup" now use ?dup and I get faster, cleaner and more close to the metal code for a compiler 8 bytes larger
19:07:21 <Speuler> say, port io on intel
19:07:22 <kc5tja> Speuler: I know.
19:07:26 <CrowKiller> i doubt this optimization at a macro level can introduce bugs
19:07:37 * kc5tja has words that compiles the relavent opcodes that I need.
19:08:03 <kc5tja> Well, I can make the same optimization.  But I don't, because that's one more thing that could go wrong.
19:08:09 <kc5tja> Not saying it will, but it could.
19:08:14 <CrowKiller> you can always introduce them as commented constants
19:08:16 <kc5tja> And right now, I'm not interested in fixing it.
19:08:47 <kc5tja> Commented constants?
19:08:54 * kc5tja must be speaking a completely different language.
19:09:09 <kc5tja> I already wrote that I have words that compile the appropriate opcodes into the dictionary space.
19:09:18 <CrowKiller> i meant it for specific assembler tricks
19:09:19 <kc5tja> Why would I want anything else at all?
19:09:27 <CrowKiller> it ok
19:09:30 <CrowKiller> its ok
19:10:03 <Speuler> kc5tja: you don't need an assembler because you program hex opcodes :)
19:10:45 <kc5tja> Speuler: I use NASM to assemble the appropriate opcodes I need, then use the resulting hex code to implement that portion of my Forth's target compiler.
19:11:20 <kc5tja> So in a way, yes.  This is perhaps the ultimate realization in Chuck's "early binding" philosophy: I'm assembling these codes at edit-time, rather than at compile-time.
19:12:07 <kc5tja> I've been looking at Chuck's MachineForth opcode set, and how his macros expand to x86 instructions.  Pretty neat, and will probably form the foundation for my next MF implementation.
19:12:23 <kc5tja> They aren't useful as-is, however, as I deal with both bytes and words interchangably.
19:12:24 <CrowKiller> im using those right now
19:12:46 <kc5tja> There are many questions I have relating to the information he published on his website. 
19:12:59 <kc5tja> His IF statement is listed as being just a JZ instruction (fine).  What sets the Z flag for it?
19:13:11 <CrowKiller> look at the source my dear ;p
19:13:26 <CrowKiller> ? words
19:13:39 <CrowKiller> i think words that start with ? use conditionals
19:14:00 <kc5tja> I think we're talking about two different things here.
19:14:09 <kc5tja> I'm talking strictly about MachineForth.
19:14:11 <kc5tja> Not high-level Forth.
19:14:29 <CrowKiller> he use assembled words
19:14:38 <CrowKiller> that are not machiforthish
19:14:41 <CrowKiller> "kernel words"
19:14:54 <kc5tja> So the MF instructions are implemented on top of the kernel words then.
19:16:04 <CrowKiller> the word "?" in colorforth is "?lit a9 1, , ;" all in green here
19:17:14 <CrowKiller> test opcode
19:17:47 <CrowKiller> immediate and EAX
19:17:57 <CrowKiller> i think he use this word to set the flags
19:18:16 <CrowKiller> there must be other means to do it
19:19:18 <kc5tja> Ok, I'm looking at the assembly source, and I'm not getting anywhere at all.
19:19:34 <CrowKiller> the comment for ? is Test bits, set flags, litteral only!
19:19:42 <CrowKiller> i am looking at the colorforth source
19:19:51 <CrowKiller> the one on merlintec website
19:20:03 <CrowKiller> with the fonts to a printable size
19:20:11 <CrowKiller> I printed it a while back
19:20:44 <CrowKiller> only a little hack to the color.css file to change color or size in the whole file
19:22:11 <CrowKiller> http://www.merlintec.com/download/color.html
19:22:44 <CrowKiller> download the color.html and color.css files, hack the .css and voila local copy of colorforth source, a bit old but better than nothing
19:24:34 <kc5tja> Hey, Chuck's colorforth.com site has been thoroughly updated now.  It has machine compatibility tables and all sorts of other goodies.
19:25:42 <CrowKiller> ???!  it hasnt changed since july 2001
19:25:52 <CrowKiller> url please ;p
19:28:18 --- join: Soap` (~flop@202-0-42-22.cable.paradise.net.nz) joined #forth
19:28:56 <kc5tja> http://www.colorforth.com
19:29:12 <kc5tja> http://www.colorforth.com/status.html
19:30:33 <CrowKiller> I've been to these
19:30:42 <CrowKiller> and theres nothing new, the page start with Updated 2001 July 31
19:32:13 <kc5tja> Well, I've never seen the list of things he's working on before.
19:32:19 <CrowKiller> the site hasnt chanegd since I started to be interested in Forth, about 7 months ago ;ppp
19:32:25 <kc5tja> And I've never seen the list of computer's its known to work on before.
19:32:40 <CrowKiller> kk
19:34:06 <CrowKiller> if he used the bios to read from the floppy and vesa to interface the screen, the list would be a lot bigger ;o)
19:34:51 <CrowKiller> not to say irrelevant, because he would need a list of system on wich his forth isn't able to execute properly
19:34:57 <kc5tja> He does.
19:35:04 <kc5tja> But once in protected mode, the BIOS disappears completely.
19:35:23 <futhin> maybe i should ask chuck moore for permission to maintain his site ;)
19:35:50 <CrowKiller> loading a 1.44mb in memory then switching to pmode isnt very hard using the bios, and the vesa interface dont need the bios I think
19:36:17 <kc5tja> It does.
19:36:31 <kc5tja> All VESA does is establish the video mode.
19:36:40 <kc5tja> It does nothing in the way of drawing.
19:37:07 <kc5tja> And he calls the VESA API *long* before he ever loads the blocks, let alone enters protected mode.
19:42:48 <CrowKiller> i know its the only call to bios he does
19:42:54 <CrowKiller> to set the video mode
19:43:03 <futhin> yeah, lazy bum!
19:43:04 <futhin> ;)
19:43:17 <futhin> and then all these other people with crappy bioses can run colorforth
19:43:38 <futhin> er
19:43:41 <futhin> CAN'T!
19:45:06 <futhin> kc5tja: i've been wondering about coding an agent simulation in forth, but i have no idea where to start heh
19:48:55 <kc5tja> I don't even know what you mean by "agent."
19:51:25 <kc5tja> This sucks.  The one and only floppy disk I have in this entire house is bad.
19:51:27 * kc5tja sighs
19:51:59 <kc5tja> I have to go and pick up a pack of floppies.  I'll be right back.
19:52:02 --- nick: kc5tja -> kc-errands
19:52:28 --- nick: kc-errands -> kc5tja
19:52:42 <kc5tja> ACtually, never mind.
19:53:49 <futhin> well let's say i want to simulate a group of people, and they produce kids, and those kids produce kids and so on
19:54:05 <futhin> or like, i want to simulate ants that forage and stuff
19:54:06 <CrowKiller> sims or genetic engineering?
19:54:10 <futhin> sims
19:54:32 <futhin> an agent can be an ant or a parent or whatever
19:54:48 <futhin> so an agent simulation is where you have a whole bunch of agents going around doing whatever
19:54:52 <futhin> i'm being very generid
19:54:54 <futhin> i'm being very generic
19:55:08 <CrowKiller> and whats the point of doing this?
19:55:17 <futhin> i just want to suggestions on where to start coding an agent simulation
19:55:29 <futhin> for fun, for discovery.. 
19:55:41 <futhin> they do stuff and i can discover what occurs
19:57:01 <CrowKiller> why dont you write your own forth instead? ;p
19:57:14 <futhin> hey!
19:57:18 <futhin> i could use the dictionary!!
19:57:59 <futhin> i could have PARENT1 and PARENT2 and they create kids (add those to the dictionary) and then the looping word can remove them when they die and stuff
19:58:18 <CrowKiller> look at terra or tierra or something like that, its about computer life
19:58:31 <CrowKiller> look at the Sims game, and at genetic engineering
19:58:44 <CrowKiller> maybe something more precise will jump in your face
19:58:57 <CrowKiller> genetic engineering i mean in SOFTWARE hehe ;p
19:59:03 <CrowKiller> genetic programming would be better
20:04:38 <futhin> argh!
20:04:43 <futhin> i want to convert a ps to text
20:04:43 <futhin> bah
20:05:17 <CrowKiller> those scientist still use the ps format grrrr
20:05:40 <CrowKiller> pdf is way better, at least on the accessibility side on windows machine ;p
20:11:20 <CrowKiller> the */ word of colorforth
20:11:43 <CrowKiller> ha ok
20:11:50 <CrowKiller> thats ok
20:12:02 <CrowKiller> this word and my compiler is finished!
20:17:23 <kc5tja> futhin: I don't know a thing about what you're talking about.
20:20:47 <CrowKiller> in colorforth, the */ scraps the A register
20:20:56 <CrowKiller> the reminder of the division get there
20:21:38 <CrowKiller> i never used that word, but is it better to keep the push edx pop edx of this macro or not?
20:21:52 <CrowKiller> I really dont know
20:22:02 <kc5tja> Seems like a waste to me.
20:22:58 <kc5tja> Well, I'm going to waste 512 bytes of dictionary space in FS/Forth's initial versions.  The logic I posted about ReadLineKeyHandler was faulty, and will crash regardless of input character.
20:23:11 <kc5tja> So I decided to just replace the whole thing with a single table lookup operation
20:24:20 <CrowKiller> i did this, but i use a 16 byte wide computed jump offset table to account for each 4 bit token
20:25:04 <futhin> kc5jta: lets suppose i want to simulate a colony or two of ants,  and i want the ants to forage, reproduce, die, etc
20:25:12 <futhin> where do i start with such a simulation? :)
20:25:18 <CrowKiller> futhin: environement
20:25:25 <CrowKiller> set of paramters you want to be simulated
20:25:28 <CrowKiller> build a list
20:25:47 <futhin> well maybe there's no environment 
20:26:04 <futhin> where do i start with simulating all the individual ants?
20:27:42 * CrowKiller won't bother anymore ;p
20:29:12 <kc5tja> You start by implementing an object system, and describing each ant as an object.
20:29:24 <kc5tja> Because without that, you'll never succeed.
20:29:46 <kc5tja> The object system doesn't need to be sophisticated, but it does need to be powerful enough to represent data and code together.
20:29:48 <futhin> i was going to do it as a linked list or something
20:29:56 <kc5tja> Implementation detail.
20:29:56 <futhin> or use the dictionary or something
20:30:11 <kc5tja> You need some method of saying, "That ant there -- eat."
20:30:37 <kc5tja> (BTW: Simulations is why object oriented programming came to be; the Simula language was the world's first object oriented programming language)
20:31:09 <CrowKiller> you need an environement with causal effetc for your simulations to be interesting, like if theres nothing to eat, ants die, because the environement is empty of food (example)
20:31:19 <kc5tja> Now I'm not saying that you need to define classes, and objects, and run-time environments and all that jazz.
20:31:35 <kc5tja> But you do need some method of invoking a "method" (statically or dynamically -- I don't care) on an object.
20:32:09 <kc5tja> For example, notice in my previous example the ReadLine word -- it takes a buffer for a parameter.
20:32:25 <kc5tja> That's a structure that contains three fields: a buffer address, length of buffer, and number of bytes in the buffer.
20:32:44 <kc5tja> ReadLine works with any buffer, and not just the Forth environment's terminal input buffer.
20:32:50 <CrowKiller> length and number of bytes isnt the same?
20:32:53 <kc5tja> No.
20:33:03 <kc5tja> You can have a 256 byte buffer, but do you always use those 256 bytes all the time?
20:33:13 <CrowKiller> ha ok lol
20:33:35 * CrowKiller is kind of "not entirely present right now"
20:33:41 <kc5tja> I also will have an InterpretBuffer word which replaces "EVALUATE" in ANSI Forth.
20:34:52 <kc5tja> Buffers in FS/Forth are a subtype of strings.
20:34:53 <CrowKiller> circular fifo buffers are great
20:35:06 <kc5tja> Not for line input they're not.
20:35:17 <kc5tja> For network packets, though, they're quite nice.
20:35:24 <CrowKiller> i thought some while ago of implementing them at edit time, like handling all the counting to keep within bounds at edit time
20:35:54 <CrowKiller> inter process communication also
20:36:06 <kc5tja> Actually, no; they're horrible for IPC.
20:36:23 <CrowKiller> horrible because they suck runtime
20:36:24 <kc5tja> Once a circular queue fills up, the sending task is put to sleep, which in a lot of cases is NOT what you want.
20:36:41 <kc5tja> It can lead to a lot of weirded out race conditions.
20:36:53 <CrowKiller> thats the gotcha of keeping it long enough
20:36:54 <kc5tja> Between two tasks they're OK, but between three or more, things get really iffy.
20:37:11 * kc5tja prefers signal bits in combination with doubly-linked list message queues.
20:37:26 <kc5tja> More powerful, faster, less CPU intensive.
20:37:31 <kc5tja> Who can ask for anything more?
20:39:17 <CrowKiller> the list can overflow, its the same with fifo, you need a protection somewhere to keep the structure togheter, maybe im totally wrong also lol
20:39:23 <kc5tja> No it can't.
20:40:21 <CrowKiller> i'll have to read on those
20:40:27 <kc5tja> Dynamically allocating list nodes separately from the act of sending them guarantees error recovery if needed.  And if you don't bother with dynamic allocation of list nodes, the list nodes are always valid -- they are perfectly accounted for at all times.  The system can never overflow.
20:40:47 <kc5tja> Don't bother reading the documentation that's easily available.
20:40:54 <kc5tja> They're unilaterally wrong on the subject.
20:41:25 <kc5tja> Instead, pick yourself up the Amiga ROM Kernel Reference Manual, Libraries and Devices.  Specifically, read through the Exec.library's chapter, on message passing.
20:41:43 <kc5tja> Any other document will describe how Unix does it, and Unix is manifestedly broken.
20:41:54 <kc5tja> (at least with respect to message queues)
20:42:02 <CrowKiller> kk!
20:42:53 <kc5tja> AmigaOS is based on VMS, especially in this regard, so it might help to track down how VMS does it.  However VMS does maintain kernel messages in kernel space, dynamically, so it too can run out of kernel space.
20:43:31 <CrowKiller> its on the net, ill download it and read it, thanks once again!
20:44:34 <kc5tja> n/p  :)
20:46:42 <CrowKiller> i can download Amiga ROM Kernel Reference Manual: Libraries in pdf format, 3.1 meg, compressed with rar
20:48:33 <kc5tja> OK, this really sucks.  I think I need to rework this keyboard code.  *sigh*
20:48:33 <kc5tja> The old procedural way of doing things is getting annoying, and the code isn't very re-usable.
20:48:38 <kc5tja> Using look-up tables is a good first start, I think.  If each application had their own keyboard tables, they could do whatever they wanted with the keycodes that came through.  But calling it "ReadLine" wouldn't work anymore, since it's no longer reading a line of text.
20:48:42 * kc5tja paces some more and thinks about this conundrum.
20:48:48 * kc5tja thinks to myself -- I need a central main loop, one which sits and waits for events, and dispatches them to the appropriate handlers as they arrive.  
20:48:53 <kc5tja> Event driven code is "a good thing" in this case.
20:48:57 <kc5tja> So QUIT just resets the system stacks, resets the current system event handler, and then jumps into the main loop.
20:49:58 <kc5tja> The event handler state is described by at least 256 function pointers (one per key code).
20:50:17 <kc5tja> : MAIN  BEGIN  KEY DispatchKey  AGAIN ;
20:50:21 <kc5tja> Hmmm....
20:50:35 <kc5tja> : MAIN   BEGIN KEY KeyHandler@ EXECUTE AGAIN ;
20:50:59 <kc5tja> If the mapped key handler executes an RDROP, it'll drop out of MAIN, and return to whatever called it.
20:51:34 <kc5tja> A cleaner, more portable method would be to return a flag from the handler.  A TRUE indicates the main loop should exit.
20:51:42 <kc5tja> : MAIN   BEGIN KEY KeyHandler@ EXECUTE UNTIL ;
20:52:13 <kc5tja> This leaves the R-stack untouched, which might be important especially when using continuations...
20:53:26 <kc5tja> Alternatively, we can just DEFER the key handler, and let IT decide what to do without using a table lookup.
20:53:31 <kc5tja> DEFER KeyHandler
20:53:38 <kc5tja> : MAIN   BEGIN KEY KeyHandler UNTIL ;
20:55:18 <futhin> figuring out what to name words can be tricky sometimes :)
20:55:30 <futhin> coming up with a great name can help the code :)
20:55:37 <kc5tja> Yes, and that's one of my problem.s
20:55:49 <kc5tja> I mean, if I'm going to be using a lookup table, then I should allow multiple look-up tables, right?
20:55:58 <kc5tja> And as the state of the system progresses, just advance from one to the next.
20:57:37 <futhin> i have a hardtime coding a program so that it can be easily modified/expanded later on
20:57:39 <futhin> heh
20:57:44 <futhin> i read Thinking Forth
20:57:56 <futhin> and i've been trying to get into the different paradigm
20:58:17 <CrowKiller> the keyboard is really a pain to interface with a small progra,m
20:59:24 <CrowKiller> scancode set 3 is great but not every keyboard support it
21:00:59 <CrowKiller> my editor would use a large enough lookup table for the keyboard, like a 128 entries table, and when the shift or ctrl key is pressed, it use its own table to interpret new input
21:03:05 <CrowKiller> in my editor, when you strat it ask you where you want to output your tokens, and then at each spacebar it tokenize the token
21:03:49 <CrowKiller> each key would put its ascii value on the stack
21:04:00 <CrowKiller> or maybe a tokenized internal representation
21:05:25 <CrowKiller> hmmm ill try to come up with something
21:07:11 <kc5tja> Well, I'm using whatever the BIOS gives me, so I'm not (yet) worrying about hardware level stuff.
21:07:31 <kc5tja> Even so, I am still running into major problems with interfacing the keyboard.  I could do it with a bunch of IF statements, but I really don't want to.  :)
21:07:47 <CrowKiller> me neither hehe
21:07:56 <kc5tja> If I use the IF statements, then ReadLine becomes a hard procedure that always reads from the console, and it can't easily be expanded.
21:08:11 <kc5tja> But if I use jump-tables instead, or some other form of call-back mechanism, it sucks up huge amounts of RAM.
21:08:24 * kc5tja sighs -- too many decisions!
21:08:42 <CrowKiller> tokenized internal representation is maybe the key
21:08:49 <kc5tja> No, not even close.
21:09:03 <kc5tja> I still have to interpret text from the keyboard.
21:09:37 <CrowKiller> anyway for me its perfect, ill try to come up with something, maybe choosing the color of the word at runtime
21:10:03 <kc5tja> It simply doesn't work at this stage.
21:10:10 <CrowKiller> a color for constants, a color for user words, a color for function words
21:10:19 <kc5tja> In order for pre-tokenized text to work at all, I need to be able to enter text from the keyboard.
21:10:25 <kc5tja> I can't even enter text from the keyboard yet!
21:10:42 <CrowKiller> read directly from the 8042
21:10:47 * kc5tja cries
21:10:49 <CrowKiller> youll get the scancodes
21:10:51 <kc5tja> That's not the problem!!!
21:11:02 <kc5tja> I already said that I can receive BIOS keycodes.
21:11:13 <CrowKiller> they are ugly lol
21:11:24 <CrowKiller> ascii may save you space
21:11:25 <kc5tja> THey're no different from the hardware keycodes.
21:11:32 <kc5tja> OK, next topic.
21:11:36 <kc5tja> I give up on the last one.
21:11:40 <kc5tja> Forget I even said anything.
21:11:57 <CrowKiller> ok you're the boss ;pp
21:12:13 <kc5tja> I can't hold a rational discussion if you don't listen to me.
21:12:22 <kc5tja> I'm already able to receive input.
21:12:31 <kc5tja> The problem I'm having is how to DEAL with that input.
21:12:36 <kc5tja> How to architect the system.
21:12:55 <kc5tja> Input is not, and has never been, a problem for me.
21:13:06 <kc5tja> Dataflow through the system is.
21:13:33 <kc5tja> Because I could go with 30-year old techniques where Forth words are hardwired to work with the keyboard, while others are hardwired to work with files and still others are hardwired to work with blocks.
21:13:42 <kc5tja> I don't want to do that.
21:13:47 <kc5tja> I shouldn't HAVE to do that.
21:14:00 <CrowKiller> the forth engine only run at runtime
21:14:16 <kc5tja> The Forth engine runs all the time.
21:14:21 <kc5tja> ALL the time.
21:14:41 <kc5tja> In my system, the editor is written in Forth.
21:14:56 <kc5tja> Merlinco's source pages are useless to me.
21:15:31 <futhin> whew, ate 12 popsicles
21:15:36 <CrowKiller> lol
21:15:51 <futhin> but my tongue isn't happy 
21:15:58 <kc5tja> I can't find the information I need.
21:16:00 <futhin> actions have consequences! :D
21:16:09 <kc5tja> In fact, Merlinco's pages only whet my appetite, and seems to suggest my earlier idea is valid.
21:16:13 <futhin> <-- proved it
21:16:21 <futhin> kc: what does merlinco's pages deal with?
21:16:32 <CrowKiller> kc5tja: what do you want to know?
21:18:06 <kc5tja> The source to "keyboard" among others.
21:18:24 <kc5tja> I want to see how he's implementing his event loops.
21:18:40 <CrowKiller> masm source code
21:18:50 <CrowKiller> at the end the graphic screen and that stuff is there
21:20:24 <CrowKiller> I don't understand it at all
21:20:29 <CrowKiller> lol
21:21:04 <CrowKiller> but in fact, your editor is tied to your processorm, your keyboard scancodes and your video memory
21:23:06 <kc5tja> OK, it wasn't what I thought it was.  Not sure at all what it is, actually, but i know it' snot what I was looking for.
21:23:57 * kc5tja waves his hand -- "This is not the source code you are looking for."
21:24:18 <CrowKiller> then maybe you need to think a little more ;p
21:24:44 <kc5tja> Thinking about it is futile if I can't find the root of his program.
21:24:54 <kc5tja> From what I can see, KEYBOARD just updates the video display, and has little to do with keyboard event loops.
21:25:06 <kc5tja> Unless you're hiding information about it and not telling me.
21:25:56 <CrowKiller> lol you help me all the time, I would explain it to you if I knew it for sure, dont start to be paranoid, its driving you crazy ;ppp
21:26:26 <kc5tja> Only the paranoid survive.
21:26:27 <CrowKiller> never asked anyone about how to handle keyboard input
21:26:44 <kc5tja> I asked Chuck how he handled it but he has yet to reply to my e-mail.
21:26:48 <CrowKiller> that may be the single thing I thought that I could come up with something fresh and new
21:26:57 --- join: proteusguy (~irc@24-197-147-197.charterga.net) joined #forth
21:27:25 <kc5tja> Well, currently, it's looking like FS/Forth would benefit from having a centralized event loop, but I can't figure out how to actually manifest this idea.
21:28:03 <kc5tja> Otherwise, I'll have one keyboard input loop for the shell, plus one per program (assuming they needed one), and it'd be nothing but one big mess.
21:28:11 <CrowKiller> cut your unsolvable problem into solvable ones
21:28:23 <kc5tja> That's the unsolvable problem.
21:28:46 <kc5tja> I know WHAT needs to be done.  HOW is a completely different matter.
21:28:46 <CrowKiller> i have two problems: how to go from scancodes to tokenized source code and to tokenized source code to compiled object code
21:28:53 <CrowKiller> the latter is done
21:29:03 <CrowKiller> so I'm at the same point at you
21:29:22 <CrowKiller> how to design an efficient editor
21:29:37 * kc5tja sighs!!  F*(#$ing great!  Now we have a coyote pack coming through!! >:(
21:29:45 <kc5tja> I'll never sleep with them around.  :(
21:30:06 * kc5tja isn't even to that point -- I am still trying to design an efficient keyboard event handling interface.
21:30:23 <kc5tja> Something which is small, efficient, but still re-usable.
21:30:41 <kc5tja> I'll have to think like an OS developer at this point, I think...
21:31:03 <CrowKiller> like an assembly programmer
21:31:21 <kc5tja> No, like an OS developer.  I need to see the big picture, not the minutia.
21:32:54 <CrowKiller> to me a good assembly programmer is an all knowing all seeing wizard capable of miracles, so... ;p
21:33:45 <CrowKiller> reminds me of one song of Megadeth, Five Magics lol
21:34:35 <kc5tja> No, to be a good programmer (not restricted to assembly language), you need to be "all seeing."  And when you become that way, you are a systems-level engineer.  An OS is a system.  An OS engineer is a systems engineer, by default.
21:42:03 <kc5tja> Hmm, OK, I think I see what's going on.
21:42:25 <kc5tja> Chuck Moore is playing with the return stack to implement his multitasking.  The SHOW word is what defines a new task!
21:42:40 <kc5tja> Like continuations, it repeatedly runs the remainder of the code indefinitely.
21:43:37 <kc5tja> Now that I figured that out, I need to try and decipher his I/O model.
21:45:30 <CrowKiller> thats the hard part
21:46:10 <CrowKiller> i knew a little about the multitasking, with the ACT word but its pure speculation, i/o and screen output in his system is foreign to me
21:48:00 <CrowKiller> my compiler is offcially 387 bytes qith all the bells and whistles implemented
21:49:47 <CrowKiller> its callable from runtime and return to runtime after its finished
21:51:21 * kc5tja nods
21:51:29 <kc5tja> It appears to be a very simple cooperative multitasker.
21:51:51 <kc5tja> Saves only a couple variables and switches D and R stacks.
21:51:57 <kc5tja> Not sure what SWITCH does though (used in SHOW)
21:52:07 <kc5tja> *LOTS* of return stack manipulation to make this work though.
21:52:11 <kc5tja> Much more than I'd ever use.
21:52:30 <kc5tja> I wish he included equivalent Forth code for his assembly routines.
21:52:32 <kc5tja> :)
21:52:56 <CrowKiller> http://kristopherjohnson.net/cgi-bin/twiki/view/Main/ColorForthWord
21:53:03 <CrowKiller> me too i am inclined to use the return stack
21:53:14 <CrowKiller> because a push and a call is only 1 byte wide from registers
21:53:20 <CrowKiller> and its fast
21:53:59 <CrowKiller> PAUSE switch tasks
21:54:29 <kc5tja> His source apparently uses a function SWITCH, but it's not defined in color.asm
21:54:42 <kc5tja> Ah, it's in gen.asm
21:54:50 <kc5tja> And it calls PAUSE as a matter of course.
21:55:08 <kc5tja> AHHHHHHHhhhhhhhhhhhhhhhhh.................
21:55:17 <kc5tja> SWITCH is what really does the screen update.
21:55:34 <kc5tja> Everything else draws into an off-screen buffer (presumably for speed)
21:56:01 <kc5tja> Since drawing into the framebuffer is an inherently slow operation (lots of PCI bus transactions, plus waiting for refresh windows...)
21:56:03 <CrowKiller> the offscreen buffer is at top of 32 meg of ram
21:58:02 * kc5tja nods
21:58:44 <kc5tja> Now he is using a global variable called "screen" (which is really a misnomer -- it points to the task maintaining the current screen, not the screen itself).
21:59:01 <kc5tja> That global variable is set by SHOW to point to the code following the invokation of SHOW.
21:59:17 <CrowKiller> my editor will use b8000 video ram for simplicity; no custom char set to manage or pci transactions to do
21:59:20 <kc5tja> I wonder how he handles multiple tasks writing to the display concurrently (from what it looks like, he doesn't).
21:59:34 <kc5tja> Writing to the framebuffer at all does PCI transactions.
21:59:50 <kc5tja> But for text-mode, who cares?  2000 bytes for video memory is still awfully fast on PCI.
21:59:57 <kc5tja> It's only with graphics modes that you really have to worry.
22:00:28 <kc5tja> You know, his task switching code is structured a *lot* like how an exokernel would be implemented.
22:00:30 <CrowKiller> stupid, sure the data has to apss along the pci bus, lol its kind of late here I think ;p
22:00:39 <kc5tja> Heheh :)
22:00:55 <CrowKiller> round robin scheduling
22:01:00 <CrowKiller> im doing that on pics
22:01:03 <kc5tja> That's just a detail.
22:01:03 <CrowKiller> PICs
22:01:11 <kc5tja> I'm talking about the general architecture.
22:01:28 <kc5tja> Each task apparently has (fixed in his case) pre- and post-PAUSE code that executes.
22:01:56 <kc5tja> I also notice that tasks are apparently maintained in a linked list.  It doesn't appear to be in a table.
22:04:48 <CrowKiller> task switching is still a long way ahead in my journey I think... ill stick with the "Four times, Two programs needed"  model
22:05:12 <CrowKiller> ill go to sleep, good luck in your "reversing" journey kc5tja
22:05:20 --- quit: Speuler (Read error: 110 (Connection timed out))
22:05:25 <futhin> well good night, i'm off to bed
22:05:28 --- quit: futhin ("sleep")
22:05:33 --- quit: CrowKiller ("bye all")
22:05:33 <kc5tja> Good grief.
22:07:00 <kc5tja> Oh well.  This code structure definitely doesn't appear to make much sense for my immediate needs.
22:07:24 <kc5tja> Especially since I don't do multitasking in my Forth (yet).
22:10:41 --- quit: proteusguy (Connection timed out)
22:22:06 --- join: dsmith (~dsmith@p97.usnyc3.stsn.com) joined #forth
22:30:34 <kc5tja> Well, I guess I'll go too.
22:30:35 --- part: kc5tja left #forth
23:31:36 --- quit: dsmith (Read error: 104 (Connection reset by peer))
23:52:42 --- join: proteusguy (~irc@24-197-147-197.charterga.net) joined #forth
23:59:59 --- log: ended forth/02.07.28