00:00:00 --- log: started forth/02.07.29 00:59:44 --- quit: Robert (bear.openprojects.net irc.openprojects.net) 00:59:44 --- quit: Soap` (bear.openprojects.net irc.openprojects.net) 01:11:03 --- quit: proteusguy (Read error: 110 (Connection timed out)) 02:52:40 --- join: proteusguy (~irc@24-197-147-197.charterga.net) joined #forth 03:06:44 --- join: Soap` (~flop@202-0-42-22.cable.paradise.net.nz) joined #forth 03:28:50 --- join: Robert (~Robert@h137n2fls31o965.telia.com) joined #forth 04:10:30 --- quit: proteusguy (Read error: 110 (Connection timed out)) 05:00:15 --- join: dsmith (firewall-u@cherry7.comerica.com) joined #forth 05:52:36 --- join: proteusguy (~irc@24-197-147-197.charterga.net) joined #forth 06:00:35 --- join: tathi (~josh@ip68-9-68-213.ri.ri.cox.net) joined #forth 06:28:17 --- quit: proteusguy (Read error: 104 (Connection reset by peer)) 07:11:11 --- join: cleverdra (jfondren@0-1pool36-226.nas2.florence1.sc.us.da.qwest.net) joined #forth 07:25:07 --- join: proteusguy (~irc@bonzo.iss.net) joined #forth 07:59:33 --- quit: cleverdra (Read error: 104 (Connection reset by peer)) 07:59:39 --- join: cleverdra (jfondren@0-1pool36-226.nas2.florence1.sc.us.da.qwest.net) joined #forth 08:07:00 --- quit: cleverdra ("Leaving") 09:05:32 --- join: cleverdra (jfondren@0-1pool36-10.nas2.florence1.sc.us.da.qwest.net) joined #forth 09:37:36 --- join: kc5tja (~kc5tja@ip68-8-206-226.sd.sd.cox.net) joined #forth 09:38:39 Well, I think I'm going to abandon the MachineForth-ish substrate on which FS/Forth is built on, and just switch over to a real x86 assembler. 09:39:06 why? 09:39:14 It's just a nightmare. 09:39:40 For every Forth primitive I add, I have to create at least one more MachineForth target compiler primitive to implement it with. 09:40:02 The target compiler's wordset is actually bigger than the target image's wordset because of this now. 09:40:10 And it's becoming increasingly difficult to manage. 09:40:30 (The code it produces isn't all that great either, but that's a side issue I was hoping to address later) 09:41:01 It becomes annoying and highly bug-prone. 09:41:09 * cleverdra nods. 09:41:31 Thus, I'm going to rip out the MF-like parts of my target compiler and replace it with a genuine 16-bit 386 assembler. 09:42:20 I may even restart the whole project from scratch if this change becomes too big for the existing substrate. 09:42:37 But I can at least cut-n-paste code from the old to the new to get it up to where it is now quickly. 09:43:11 And it'll at least give me a chance to fix a major bug with the system: a personal bug. RULE #1 OF WRITING FORTH IMPLEMENTATIONS: THE ABSOLUTE FIRST WORD YOU MUST WRITE IS .S !! :) 09:43:42 Now that I'm finding a need to write .S, I'm finding I need to implement . and therefore a bunch of other numeric output words. And I'm finding that these words all need their own primitives, and buffer management is a major issue. 09:44:42 Well, I can still write .S easily enough. It's just that the need for numerous more primitives is aggrevating me. 09:45:02 I'm finding I can't keep it all in my head (the big picture; source contains the details) 09:54:57 Are you going to have a ANS <# #> setup? 09:55:26 Similar semantics, but I was going to let the user specify the buffer they load the number into. 09:55:57 So while "standard" words like . and U. would probably use PAD, if you wanted to use <# and #> yourself, you could explicitly set the buffer. 09:56:16 Or, maybe I'll have the numeric buffer be a user variable. I don't know for sure just yet. I think user variable would be easier. 09:57:26 less reentrant, maybe. 10:00:29 Yes, but . and friends are hardly re-entrant themselves. 10:00:48 I envision if you want re-entrancy, you could make it explicit: 10:01:18 : my. #Buffer @ MyBuffer #Buffer ! . #Buffer ! ; 10:01:25 (like BASE variable) 10:02:00 Otherwise, the stack becomes way too convoluted during processing. 10:02:13 I don't see any other efficient way around it. 10:05:52 I suppose one possible method would be to allocate a buffer on the return stack somehow. But I don't know how well accepted that would be. And that absolutely will prevent FS/Forth from *ever* existing on pure stack architectures. :) 10:06:57 Another possibility is the use of a third stack (where each task running in the system has its own third stack). 10:07:18 --- quit: cleverdra ("Leaving") 10:08:43 Hmm... 10:09:05 that might be interesting... 10:09:18 Well, I'm off to work. I'll be back online in about 30 minutes 10:10:11 Yeah, a small, software managed stack for holding temporary stuff, besides the return stack. I'll need to add yet another stack, I think, for when I add continuations, so I'm pretty much looking at a 4-stack architecture if I use that technique. 10:11:25 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 10:41:07 --- join: kc5tja (~kc5tja@user-24-214-86-42.knology.net) joined #forth 10:41:14 back 10:41:16 (at work currently) 10:44:40 --- join: I440r (~mark4@1Cust239.tnt2.bloomington.in.da.uu.net) joined #forth 10:45:10 hey kc5 - I got knocked off a few nights ago talking with you.. how things going? 10:45:29 OK 10:45:39 * kc5tja is going to probably re-work my Forth compiler. 10:46:09 uh oh - how much of it you reworking & why? 10:46:50 The MachineForth-ish approach isn't working for my needs as such. 10:46:50 At least, not the way it's currently architected. 10:47:20 Architecture is always the critical part to get right. You can always re-implement later if your architure is good. 10:47:27 I was thinking of just dropping a 16-bit 386 assembler into the target compiler to compile primitives, but that got me thinking a bit more about the root of the problem. 10:47:47 If your architecture is good, you have 0 need to re-implement. 10:47:55 If you need to re-implement something, it's because you really flubbed it up. 10:48:06 Anyway, the way I'd use the 16-bit assembler is as follows: 10:48:28 no - I mean you can architect your system's ABI or policies and implement only as an interpreter at first, then do inline asm stuff later. 10:48:40 : DUP [ 2 #_ BP_ SUB_ BX_ 0 [BP]_ MOV_ ] ; 10:49:03 I'm doing inline asm stuff now. It's a native code compiler. 10:49:28 yes I know - doesn't that result in lots of upfront work before you can try new things? 10:49:35 Anyway, the above code is significant, because I'm executing the target assembler's primitives directly, without having to create intervening proxy words to bridge the gap. 10:49:40 No. 10:49:44 No more than a regular compiler. 10:49:47 (threaded) 10:50:04 hmmm... ok 10:50:12 In fact, the threaded compiler is harder to work with, because you basically need two compilers -- one for primitives, and oen for colon-definitions. 10:50:23 right 10:50:35 * kc5tja just has one compiler. 10:50:55 proteusguy i priv messaged you :P 10:53:02 Needless to say, I'll be making myself a 16-bit assembler for this, and just sticking with that. 10:53:20 you didn't have your own asm before? 10:53:31 * proteusguy is confused perhaps... 10:53:31 No. 10:53:42 you hard coded machine ops? 10:53:54 I tried implementing the system with a form of Machine Forth that more or less exposed the x86 architecture. 10:55:04 Machine Forth is something that already exists? 10:56:04 MachineForth is a concept that you write your software in an assembler that looks uncannily like Forth, except the "primitives" map to one or two hardware instructions. 10:56:10 It's existed for years. :) 10:56:57 ok -- that's what I did for my 6809 stuff.... 10:57:10 Well, be careful. 10:57:13 looked like a name brand the way you did it. 10:57:20 MachineForth isn't your normal assembler. 10:57:33 1 2 + 6 < IF HelloWorld THEN is valid MachineForth! 10:57:51 well I didn't have a WHOLE computer to deal with - just embedded stuff and hard coded addresses were ok. 10:58:08 sure 10:58:27 build your words carefully or get lost real quick... 10:59:01 I did build my words carefully, and I'm not lost -- I'm innundated. 10:59:03 that's why mine was extremely minimulist and most everything was interepreted until I identified things that *had* to be machine code. 10:59:24 That's fine if you already have the interpretter. What do you write the interpretter in? 10:59:27 well that's understandable I guess... how's the assumbler gonna make it easier for you? 10:59:37 bbl guys, i gtg take sis to hospital, she pranged her car yesterday and hurts today :P 10:59:39 bbl 10:59:57 I wrote the interpreter in a tiny bit of ASM, some hard coded machine, and then with the few FORTH prims it created. 11:00:06 Exactly. 11:00:23 I have to code the interpretter myself, which means I need to code a lot of primitives. 11:00:35 (especially I/O primitives) 11:00:55 yep - I actually rehosted the asm-generated machine code (from another environment) then manually edited it. 11:01:24 And since my Forth is written in Forth, I need the assembler to be in Forth as well. :) 11:01:32 Hence my need to write my own assembler. 11:02:14 well you don't need a whole assembler - mine was like an ASM pre-processor at best. 11:03:32 I guess cpus are more expensive now but it shouldn't take too much to get you operation I wouldn't expect. 11:03:53 expensive==complex I mean 11:05:10 I don't understand what you mean by "assembler pre-processor." 11:05:58 well a full assembler does a lot of stuff and knows some things about the state of the cpu... you don't need all those features (data allocation,allignment, etc)... 11:06:09 ...kinda just need a big search/replace. 11:06:21 That's not at all how Forth assemblers work. 11:06:58 Forth assemblers consist of a large dictionary of words which map to opcodes. These opcodes, ultimately, just use C, or , to emit the bytes into the dictionary. 11:07:06 wait- when you say assembler you aren't talking about an ASM->op code assembler but a FORTH->op code assembler? 11:07:14 No. 11:07:32 I440r: Hello there,what do you think would be the easiest way to add graphics to IsForth? 11:07:50 : DUP [ 2 #, BP SUB, BX 0 [BP] MOV, ] ; 11:07:54 sorry - I got completely confused about what you were leadning too - thought you wanted an ASM assembler sitting between your FORTH and the op codes. 11:08:02 yes yes - ok. 11:08:14 #, BP, SUB, BX, [BP], AND MOV, are all Forth words which updates the assembler's state. 11:08:27 SUB, and MOV, also cause the opcodes to be emitted into the dictionary. 11:08:38 Robert: he left a few minutes ago I think 11:08:40 You say assmbler to be and one thing comes to mind. :-) I call this Forth inline compiler vs. Forth interpreter. 11:08:47 tathi: Ok, okay. 11:08:56 tathi: What do you think about it? 11:09:01 What's the difference? 11:09:11 tathi: From a low level, what's the easiest way to do some kind of graphics in Linux. 11:09:15 s/./?/ 11:09:27 Link with an external library? 11:09:30 When you see a CODE definition in a Forth program, that's still a form of inlining. Yet it's pretty universally acknowledged to be an assembler. 11:10:16 Robert: The easiest would probably be to link with an external library. Second easiest would be to link with SDL, and manage the framebuffer it allocates in Forth. The hardest would be to use the kernel primitives to acquire access to the SVGA card's framebuffer yourself. 11:10:40 Okay... 11:10:43 Thanks :) 11:10:53 brb -- I need some kind of food... 11:10:55 For some reason my recollection of our prev. conversation last week had me thinking you were doing something that generated a large set of pre-compiled op codes from FORTH then ran it instead of runtime compiling. 11:11:25 That's what it does. 11:11:37 The target compiler is used to compile the Forth source into a binary image. 11:11:47 This binary image is then saved to disk. 11:12:08 The user then runs that binary image to execute the new Forth environment. 11:12:15 Robert: I'd agree with kc5 -- though if you're going to stick with I440r's "no library" mentality, it's not all _that_ hard to use the linux framebuffer through syscalls... 11:12:31 ok - that's what I understood but I had some idea you were generating ASM from your Forth compile then running it through an assembler. 11:13:43 No no no no no.... :) 11:14:01 The assembler is itself implemented in Forth in the target compiler. :) 11:14:20 It's vaguely structured like Pygmy Forth. :) 11:14:23 (or cmForth) 11:14:31 don't know em 11:14:33 I see the source of confusion now. :) 11:14:42 The assembler is an intrinsic part of the Forth environment. 11:15:03 When you meta-compile the Forth kernel, it uses its own built-in assembler to do it. 11:15:27 ok - generates a binary image of itself. 11:15:46 vs. interpreting itself. 11:16:05 Exactly. 11:16:25 neat trick... lots of extra effort it sounds to me! :-) 11:16:50 If you want a Forth environment that can re-compile itself, you have to do it. 11:16:53 There's no other way. 11:17:04 I bootstrapped via keyboard ;-) 11:17:21 finally burned to ROM. 11:18:24 brb 11:18:30 And if you wanted to make a customization of the Forth environment? (Ignoring the fact that you had to reburn a ROM...) 11:18:50 I wouldn't consider using a Forth I couldn't modify to suit my needs. :) 11:18:59 ha ha - customized presumes that there was something standardized in the first place! :-) 11:19:18 Precisely why I'd want to customize! 11:19:24 actually I ported very quickly because only a few primitives needed re-implementing and then I was done. < 1 day. 11:19:45 For example, Pygmy's implementation of #> just types the number right to the screen. It doesn't even *consider* that I *might* want it to appear in a string... :/ 11:22:06 my optimizations consisted of identifying a word that needed speeding up and consisted of multiple interpreted words - then I'd redefine it in pure ASM and short circuit it's look up. Of course those things didn't port to the new environments... 11:24:09 In my Forth environment, the Forth words compile to a series of CALL (JSR for 65/68xx series CPUs) instructions. Literals are directly inlined. 11:24:17 : FOO BAR BAZ ; 11:24:19 compiles to 11:24:24 _FOO: 11:24:26 call BAR 11:24:29 call BAZ 11:24:30 ret 11:25:03 Chuck implements tail-call optimization, but I do not, because it's incompatible with another one of my Forth environment's features. 11:25:05 what happens when you redefine a word in the interpreter - recompiles it? 11:25:19 No, it follows normal Forth behavior. 11:25:37 Only subsequent uses of the word will use the new behavior. 11:26:25 so then you pay dictionary lookup cost which interprets to similar word calls like your sample asm? 11:26:42 huh? 11:26:54 How does a CALL instruction incur a dictionary lookup cost? 11:27:05 It's a directly executed machine language instruction. 11:27:32 no no - you redefine a word in the interpreter then it gets called by the program... the program will use the new finition right? 11:27:44 de-finition I mean... 11:27:44 Correct. 11:28:16 ok - how does the program see the new definition without dictionary lookup? 11:28:42 At interpret time (e.g., when interactive with the user), it performs the lookup for each word in the input stream. 11:28:51 At run-time (e.g., post compilation), it "just goes there." 11:29:13 The compiler does the dictionary lookup at compile-time, not run-time, and uses the address in the generated instruction stream. 11:29:14 ok so it does get recompiled before the program gets to call it. 11:29:38 But your statement is highly ambiguous. 11:30:01 When you say recompiled, what do you mean? Are you talking about the whole program, or just the word? 11:30:25 Also, redefining a word doesn't change the words that are already compiled. 11:30:32 (including its old definition) 11:30:39 So: 11:30:43 : FOO ." Hello" ; 11:30:44 well I would expect that only the word needs recompiling at the CALL point is probably relocatable or a jump off point. 11:30:52 : BAR FOO ." World!" ; 11:31:00 : FOO ." Goodbye cruel " ; 11:31:07 BAR --> Hello World! 11:31:25 But that breaks Forth's behavior. 11:31:36 See the example above. 11:31:46 Note that I redefine FOO, but BAR still invokes the old behavior. 11:31:59 I see - mine would say "Goodbye cruel World!" 11:32:28 * kc5tja would never, ever make that a default behavior. 11:32:37 If I wanted to patch an old version of a word, I'd do it like this: 11:32:52 : NewFOO ." Goodbye cruel " ; ' NewFOO PATCHES FOO 11:33:24 kc5: so do you do like Chuck apparently does, and make new definitions immediately findable in the dictionary? 11:33:43 tathi: Only after ';' is executed for that definition. 11:33:58 : FOO FOO ; will yield a word not found error (unless FOO was previously defined of course) 11:34:22 ok 11:34:26 I can't imagine a FORTH that doesn't make new definitions immediately available. Wouldn't feel like FORTH. 11:34:52 I'm not familiar with what type of Forth you're using, but *none* of the Forths I've ever used behaved anything like what you're describing. :) 11:35:12 I've never used a pre-compiling forth! 11:35:18 You don't need to. 11:35:25 ColorForth and cmForth aren't pre-compiled... 11:35:41 And what 'is' pre-compiled, anyway? 11:36:09 ha ha ha - well what you're doing is pre-compiled (i.e. no need to interpret during runtime). 11:36:45 Well, again, every Forth system I've used behaved this way. Pygmy, FPC, GForth, .... 11:37:11 Only Chuck's earliest of Forths ever did run-time dictionary lookups. 11:37:14 yeah, only forth-like thing I can think of that does that kind of late binding is PostScript 11:37:31 oh well - its entirely possible that I misunderstood forth at the time - I used this feature like mad! 11:38:12 Well, I'm not saying it's wrong. It's just totally different from what the bulk of the world thinks of Forth. :) Your system sounds more like Smalltalk. 11:38:35 (In Smalltalk, you can really cripple the system by redefining the method that allows you to redefine methods!) 11:38:37 ouch! hey! 11:38:40 no smalltalk! 11:38:42 :-) 11:38:48 What's wrong with Smalltalk? 11:39:02 not for when i'm thinking forth - please.... 11:39:10 * kc5tja shrugs -- OK. 11:40:49 Lunch in 30 minutes...and counting. 11:41:03 you on left coast? 11:41:40 I'm on the West coast if that's what you're asking, yes. :) California to be specific. 11:42:17 What do you get paid to do? (Not forth I assume) 11:42:43 Unfortunately no -- I'm a semiconductor verification technician. 11:43:15 hey - you're as close to the silicon as you can get then! :-) 11:43:43 Yes, but I'm still primarily a software developer. I write and maintain our testing framework for our network processors. 11:43:56 I don't do hardware level design at all. 11:44:00 that's cool. what environment? 11:44:54 Define environment? 11:45:01 language/os/cpu 11:45:19 C/Windows NT and proprietary/x86 and MIPS 11:47:10 brb 11:56:05 yay vim 12:09:54 VIM kicks butt. :) 12:15:13 --- nick: kc5tja -> kc-food 12:24:08 --- join: Speuler (~l@195.30.184.4) joined #forth 12:24:13 hi 12:57:51 --- quit: Speuler ("using sirc version 2.211+KSIRC/1.1") 13:40:25 --- nick: kc-food -> kc5tja 14:11:33 --- quit: proteusguy () 15:01:58 --- quit: dsmith ("later..") 15:59:15 --- join: futhin (thin@h24-64-175-61.cg.shawcable.net) joined #forth 18:39:41 i440r!!!!!!!!!!!!!!!!!!1 18:39:48 :D 18:39:50 :P 18:39:54 :) 18:57:16 --- quit: kc5tja (Read error: 110 (Connection timed out)) 19:01:58 --- quit: I440r (Read error: 113 (No route to host)) 19:21:59 --- quit: tathi ("leaving") 21:05:49 --- join: proteusguy (~irc@24-197-147-197.charterga.net) joined #forth 21:41:11 hello proteusguy 22:02:49 --- join: sbk_ (~kbs@dsl-65-184-98-221.telocity.com) joined #forth 22:10:51 --- quit: proteusguy (Read error: 110 (Connection timed out)) 22:28:50 --- join: njd (melons@njd.paradise.net.nz) joined #forth 22:34:34 --- quit: Robert (bear.openprojects.net irc.openprojects.net) 22:34:34 --- quit: futhin (bear.openprojects.net irc.openprojects.net) 22:34:34 --- quit: Soap` (bear.openprojects.net irc.openprojects.net) 22:34:40 --- join: Robert (~Robert@h137n2fls31o965.telia.com) joined #forth 22:35:03 --- join: futhin (thin@h24-64-175-61.cg.shawcable.net) joined #forth 22:35:03 --- join: Soap` (~flop@202-0-42-22.cable.paradise.net.nz) joined #forth 22:36:43 --- quit: sbk_ ("Leaving") 23:15:59 --- quit: futhin ("bed") 23:26:48 --- join: njd_ (melons@njd.paradise.net.nz) joined #forth 23:28:42 --- quit: njd (Read error: 104 (Connection reset by peer)) 23:37:10 --- quit: Robert (bear.openprojects.net irc.openprojects.net) 23:37:29 --- quit: njd_ (bear.openprojects.net irc.openprojects.net) 23:37:29 --- quit: Soap` (bear.openprojects.net irc.openprojects.net) 23:37:50 --- join: Robert (~Robert@h137n2fls31o965.telia.com) joined #forth 23:37:51 --- join: njd_ (melons@njd.paradise.net.nz) joined #forth 23:37:51 --- join: Soap` (~flop@202-0-42-22.cable.paradise.net.nz) joined #forth 23:52:17 --- join: proteusguy (~irc@24-197-147-197.charterga.net) joined #forth 23:59:59 --- log: ended forth/02.07.29