00:00:00 --- log: started forth/10.02.20
00:11:25 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
00:50:10 --- join: GeDaMo (~gedamo@dyn-62-56-89-110.dslaccess.co.uk) joined #forth
02:02:39 --- quit: kar8nga (Remote host closed the connection)
03:51:52 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth
03:58:58 --- join: iostres (~ivan@78-1-171-213.adsl.net.t-com.hr) joined #forth
04:07:12 --- quit: GeDaMo (Quit: Now I lay me down to sleep; Try to count electric sheep)
05:10:32 --- quit: iostres (Read error: Operation timed out)
05:30:48 <ASau> Deformative: what do you want to know about old disk access words?
05:49:02 --- join: nighty__ (~nighty@x122091.ppp.asahi-net.or.jp) joined #forth
05:59:21 --- quit: nighty__ (Ping timeout: 272 seconds)
06:38:32 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
07:01:11 --- join: tgunr_ (~tgunr@cust-66-249-166-11.static.o1.com) joined #forth
07:04:06 --- quit: tgunr (Read error: Connection reset by peer)
07:06:46 --- join: GeDaMo (~gedamo@dyn-62-56-89-110.dslaccess.co.uk) joined #forth
07:31:49 --- quit: kar8nga (Remote host closed the connection)
08:43:16 --- join: erider (~chatzilla@pool-173-69-160-231.bltmmd.fios.verizon.net) joined #forth
08:43:25 --- quit: erider (Changing host)
08:43:26 --- join: erider (~chatzilla@unaffiliated/erider) joined #forth
09:05:52 --- quit: ASau (Remote host closed the connection)
09:07:07 --- join: ASau (~user@83.69.227.32) joined #forth
09:45:07 <KipIngram> Wow - I just sat down to read "Shutter Island."  First page of the prologe and I'm already hooked; nothing's grabbed me like that in a long time.
09:45:20 <ASau> What's it?
09:46:54 <Deformative> Movie looks good.
09:48:38 <Deformative> ASau: Nevermind the disk access stuff, I will ask more when I get to that part.
09:49:39 <KipIngram> I've only seen the movie previews; it's a suspense movie set in a mental institution on a remote island.
09:50:05 <KipIngram> A couple of federal agents go there for some official reason and discover all kinds of weird things.  That's all I know right now.
09:50:20 <KipIngram> It isn't the plot that's grabbed me -- it's just the *tone* the author has already set, on page 1.
09:50:33 <Deformative> I see.
09:50:59 <Deformative> I tend to enjoy movies where mental illness is a theme.
09:51:16 <Deformative> Not so cool in real life.
09:54:15 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
09:56:47 <KipIngram> :)  You get today's award for stating the obvious.
09:58:30 <KipIngram> Hey, my wife's "Redbook" issue came yesterday.  Julia Louis-Dreyfus (from Seinfeld) is on the cover.  I had no idea she could look so good.  And if I'm impressed enough to mention it here I must be pretty impressed.
09:59:59 <Deformative> Heh. :D
10:00:08 <Deformative> Sorry, it's early. ^^
10:01:46 <KipIngram> Deformative: how old are you?
10:01:53 <KipIngram> Early 20?
10:01:55 <KipIngram> 20's?
10:01:56 <Deformative> 18
10:02:03 <KipIngram> :D
10:02:10 <Deformative> Why?
10:02:27 <KipIngram> Ok.  She's 49, so maybe not your category so much.  I'm 47 though, so she's perfect.
10:03:13 <Deformative> Oh, I completely missed the bit about the red book.
10:03:49 <KipIngram> Oh; sorry.  So you were still commenting on the Shutter Island thread.  Ok.
10:04:05 <Deformative> No worries.
10:04:21 <KipIngram> Anyway, back to this book.
10:05:52 <ASau> KipIngram: I thought you're much older.
10:06:07 <Deformative> Lawl.
10:06:30 <ASau> You're 47 and talked like you're in mid 50s at the very least.
10:06:48 <ASau> More like mid 60s.
10:07:01 <Deformative> My guess was right on as far as his age goes.
10:08:21 <Deformative> Because he said he had a daughter who was ready to pick out colleges, and so I estimated at my dad's age. ^^
10:09:27 <ASau> I don't know your education system that much.
10:10:24 <Deformative> First year college students are typically 18-19.
10:10:54 <ASau> Hm.
10:11:12 <ASau> Alright, it's almost like here.
10:11:29 <Deformative> Where is there?
10:13:08 <ASau> Here.
10:13:16 <Deformative> Meh.
10:14:05 <ASau> Deformative: it is easy to figure out if you understand networking.
10:14:22 <Deformative> I figured you had your hostname proxied.
10:15:23 <Deformative> If not, then moscow.
10:24:53 <KipIngram> Sorry to disappoint you ASau.
10:25:37 <ASau> KipIngram: I'm not disappointed.
10:25:51 <ASau> It's just a bit strange that you talked that way.
10:25:55 <KipIngram> Ok, I'm looking through some more of this game programming book, and came to the parts relating to disk access speed, seek times, and so forth.
10:26:00 <KipIngram> Since we just discussed blocks.
10:26:20 <KipIngram> Clearly in game loading and any other app that requires lots of fast disk access the physical layout of your data on the drive matters.
10:26:36 <KipIngram> Forth's block system lets you control that *completely*.  You put everything exactly where you want it.
10:26:56 <KipIngram> Does any mainstream language or any modern operating system honor that sort of control?  I can't think of one example other than Forth.
10:27:12 <ASau> Yes.
10:27:16 <KipIngram> Details please.
10:27:21 <ASau> Any modern operating system provides more.
10:27:36 <KipIngram> How?
10:28:10 <ASau> First, there's mmap.
10:28:14 <KipIngram> In writing a casual C program under windows, how do I guarantee that a given collection of data items go on the same track, so that I don't have to seek the read head to get all of them?
10:28:30 <ASau> This is faster than dealing with that yourself in most cases.
10:28:39 <ASau> Second, there's raw access to devices.
10:28:40 <KipIngram> I don't know what that is; please summarize.
10:28:56 <ASau> Third, there's aio for the cases when you need it.
10:29:10 <KipIngram> Yes, you can do raw access to the devices, but won't that risk big problems to your os?  How do you get the os to allocate the space where you need it to begin with?
10:30:17 <KipIngram> Are these things available in C, some other language, or what exactly?
10:30:37 <ASau> How does it present problems?
10:30:59 <ASau> Consider BSD systems.
10:31:12 <ASau> When you need full disk access, you just access the raw device.
10:31:23 <ASau> When you need access to part of disk, you allocate a partition.
10:31:34 <KipIngram> Because the problem arises when you create the file, not when you access it.  Windows might scatter the allocated blocks for your file all over the place.  The fact that you can access those blocks in low-level way doesn't help.
10:31:37 <ASau> And you work with it as if it is regular file.
10:31:46 <KipIngram> You need to get them all lined up to start with, at file creation time.
10:32:14 <KipIngram> Ok, so what you're really saying is you avoid OS problems by using a dedicated device.
10:32:20 <KipIngram> Sure; easy answer.
10:32:33 <ASau> How is it different in Forth case?
10:32:51 <KipIngram> But it would be nice if I could tell Windows to create a file of a given size and to arrange it on tracks and sectors in a certain way.
10:33:15 <ASau> Well... It may be that NT supports it, I don't now and I don't care.
10:33:20 <KipIngram> Obviously that might fail, if the necessary blank space wasn't available, but Windows could either tell you that or move things around like defrag to make the necessary space available.
10:33:36 <KipIngram> Then once you'd done that you could use conventional file access methods to read and write the data.
10:33:59 <ASau> As for tracks and sectors.
10:34:01 <ASau> Forget them.
10:34:06 <ASau> They don't exist nowadays.
10:34:13 <KipIngram> Forth just lets you move data to and from the disk; how you organize it is up to you.  There's no "OS structure" to interfere with.  You're responsible for everything.
10:34:41 <KipIngram> Hard drive read heads still have to seek.  "Track" --> specific position of the readhead.
10:34:59 <KipIngram> You still have to wait for the hard drive to spin.  "Sectors" --> specific angle range of the platter.
10:35:01 <ASau> You are isolated from this completely nowadays.
10:35:23 <ASau> HDD firmware does too many things today.
10:35:44 <KipIngram> That's the *point*, ASau.  You're so isolated that you can't optimize.  Geez, you just look at things in such an odd way.
10:35:58 <ASau> You don't need to optimize it anyway.
10:36:45 <KipIngram> Yes, you do.  Never mind; talking to you never gets me anywhere.  Once in a while you say something interesting, but I think from now on I'll treat you as a "read only resource."
10:36:54 <ASau> Things are arranged so that they've designed special
10:36:54 <ASau> algorithms which are smarter than you can do yourself
10:37:02 <ASau> Unless you work in the area.
10:41:08 --- quit: madwork (Ping timeout: 240 seconds)
10:45:03 <Deformative> Lol.
10:45:16 <Deformative> ASau: I will still talk to you.
10:45:27 <Deformative> Show me something interesting.
10:47:52 <Deformative> :(
11:25:02 <Deformative> A fella in D is playing around with distributed fractal generation, this is intense:  http://demented.no-ip.org/~stacy/test21.sc.png
11:31:29 --- quit: ASau (Ping timeout: 240 seconds)
11:39:59 <scj> the top part looks like a octorok from the zelda games
11:42:27 --- join: ASau (~user@83.69.227.32) joined #forth
11:46:52 --- quit: ASau (Remote host closed the connection)
11:49:41 --- join: ASau (~user@83.69.227.32) joined #forth
12:02:10 <Deformative> I suppose.
12:04:42 --- join: iostres (~ivan@93-138-58-137.adsl.net.t-com.hr) joined #forth
12:07:20 --- quit: erider (Ping timeout: 272 seconds)
12:25:49 --- quit: ASau (Remote host closed the connection)
12:42:46 --- join: ASau (~user@83.69.227.32) joined #forth
12:46:23 --- quit: ASau (Remote host closed the connection)
13:05:50 --- join: ASau (~user@83.69.227.32) joined #forth
13:07:10 --- join: segher (~segher@84-105-60-153.cable.quicknet.nl) joined #forth
13:12:41 --- quit: ASau (Ping timeout: 240 seconds)
13:26:53 --- join: Al2O3 (~Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth
13:41:53 <KipIngram> buffer 3
13:41:59 <KipIngram> Ooops...
14:05:15 --- join: davec (~tgunr@cust-66-249-166-11.static.o1.com) joined #forth
14:05:43 --- nick: davec -> Guest69977
14:06:41 --- quit: Guest69977 (Remote host closed the connection)
14:07:12 --- join: tgunr (~tgunr@cust-66-249-166-11.static.o1.com) joined #forth
14:28:51 --- quit: qFox (Quit: Time for cookies!)
14:34:57 --- quit: iostres (Ping timeout: 265 seconds)
14:37:31 --- quit: GeDaMo (Quit: Now I lay me down to sleep; Try to count electric sheep)
14:43:25 --- join: iostres (~ivan@93-138-58-137.adsl.net.t-com.hr) joined #forth
15:01:18 --- quit: mathrick (Read error: Connection reset by peer)
15:03:02 --- join: mathrick (~mathrick@users177.kollegienet.dk) joined #forth
15:04:24 <iostres> n
15:04:32 <crc> n?
15:04:42 <iostres> lol, wrong window
15:04:46 <iostres> n goes to gdb :)
15:04:51 <crc> ok
15:44:14 --- join: ASau (~user@83.69.227.32) joined #forth
15:54:11 --- quit: ASau (Remote host closed the connection)
16:06:10 --- quit: iostres (Quit: My damn controlling terminal disappeared!)
16:11:43 --- quit: kar8nga (Remote host closed the connection)
16:55:19 --- quit: Al2O3 (Ping timeout: 256 seconds)
16:56:04 --- join: Al2O3 (~Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth
17:11:20 <Deformative> Why do forth dictionary entries store the length of the word?
17:11:41 <Deformative> Why not a C style string?
17:12:09 <crc> my forth uses zero terminated strings, but most don't
17:12:24 <crc> reva stores both the count, and zero terminates strings, so you can use either approach
17:13:05 <Deformative> Yeah, I don't see any reason for holding a length.
17:13:45 <Deformative> I think I will make the parameter stack downward building instead of upward.
17:13:48 <Deformative> Same for the return stack
17:14:18 <Deformative> Then keep the "heap" upward building.
17:14:30 <Deformative> And keep all code definitions in the "heap."
17:17:21 <crc> holding the length can be useful if you have a large, non-hashed dictionary
17:17:36 <crc> you can compare length and discard shorter or longer entries quickly
17:18:15 <Deformative> That would seem to only hold true if there was a high density where the initial characters are the same.
17:18:24 <Deformative> Like a lot of words beginning with A for example.
17:18:54 <Deformative> I am using a linked list dictionary. :)
17:20:36 <crc> me too
17:21:55 <Deformative> My assembler is lame and educational.
17:21:58 <Deformative> So I cannot use .ansi
17:22:12 <Deformative> I need to do .data val \n .data val etc etc
17:22:20 <Deformative> Is there a way you think I can simiplfy this with CPP?
17:22:34 <crc> I metacompile :)
17:22:48 <Deformative> Me too, I am bootsrapping though.
17:23:09 <Deformative> Like SOMEMACRO(word) convert it to .data ansiforw .data ansiforo .data ansiforr .data ansiford
17:23:33 <Deformative> I don't think cpp has that power. :(
17:23:43 <Deformative> I could make my own preprocessor, but I really don't want to.
17:35:45 <crc> what platform?
17:39:45 <Deformative> What, the preprocessor, or the target?
17:40:18 <crc> target
17:40:39 <Deformative> Custom.
17:41:11 <Deformative> My professor calls it the "e100"  he designed it to be easy to learn/design/program on an fpga.
17:48:08 <crc> ok
17:48:15 <crc> is the assembler custom?
17:49:37 <KipIngram> Forth encourages you to define a lot of words, so you might wind up with a lot starting with common letters.
17:49:59 <KipIngram> I like that idea of having the length and a null terminator.
17:55:00 <Deformative> crc: Yes.
18:02:05 <Deformative> For length, it would result in a lot of extra asm.
18:02:07 <Deformative> Not worth it fo rme.
18:03:34 <crc> Deformative: can you explain in slightly more detail what you want the macro to do?
18:04:19 <crc> what are ansiforw, ansiforo, etc?
18:04:23 <Deformative> Well, I need one to convert a string to a ".data num \n" for each ansi of the string.
18:04:42 <crc> ahh, ok
18:06:01 <Deformative> Then I also need to do a #define repeat(statement, times)  in order to allocate space fo stacks.
18:06:24 <Deformative> I need to have ".data 0 \n" for each word of the stack.
18:06:34 <Deformative> There is no way to allocate larger data.
18:10:42 <segher> there is .fill
18:10:50 <Deformative> This assembler does not have that.
18:10:54 <segher> oh okay
18:11:01 <crc> Deformative: write a better assembler
18:11:26 --- join: ASau (~user@83.69.227.32) joined #forth
18:12:45 <Deformative> crc: I am very pressed for time.
18:15:49 <KipIngram> How about just dispensing with the fluffy automated stuff and grind the dictionary out one entry at a time?  That's how I wrote my first Forth.
18:16:50 <KipIngram> I think it was DB for "define bytes".
18:20:58 <KipIngram> If I can remember right it went something like this, for a word called WORD
18:21:07 <KipIngram> WORDN:     4
18:21:10 <KipIngram> Wait.
18:21:16 <KipIngram> WORDN:     DB     4
18:21:25 <KipIngram>           DB     'WORD'
18:21:49 <KipIngram>            DW     <lastword>N
18:21:53 <KipIngram> etc.
18:22:15 <KipIngram> I put the length byte in manually; nothing counted the name characters for me.
18:22:51 <Deformative> Yeah, I don't have such an option.
18:22:53 * ASau thinks that it was meant for "data bytes."
18:23:08 <ASau> But it doesn't matter at all.
18:23:23 <KipIngram> That could be.  This was the "EDTASM" assembler for the TRS-80 Color Computer.  Circa 1982.
18:23:51 <KipIngram> Used a cassette tape for storage.
18:23:54 <ASau> It goes since damn ancient IBM assemblers.
18:24:42 <KipIngram> Well, it got the job done.
18:25:55 <ASau> I strongly advise placing link field before name field.
18:26:33 <ASau> Remember old rule on records:
18:26:42 <KipIngram> I can't remember for sure exactly how I laid it out.  However it was defined in "Forth Fundamentals" by McCabe.
18:26:45 <ASau> fixed length fields first.
18:26:51 <KipIngram> That was my Forth bible in those days.
18:27:07 <ASau> It changed somewhere between 1977 and 1979.
18:27:26 <ASau> Between FIG Forth and Forth-79 more exactly.
18:27:46 <KipIngram> Can't remember.  Book's upstairs on my shelf, though.
18:27:47 <ASau> And it is good.
18:30:47 <KipIngram> Putting at least the link back to the previous name before the string would particularly make sense with C-style strings, but with a length byte it's not riduculously hard to jump over the string.  Still a smidge better not having to, though, so I agree with that.
18:31:06 <ASau> It makes much sense in Forth as well.
18:31:21 <KipIngram> No, I meant if you used a C-style string for the name.
18:31:34 <KipIngram> But I do think the CFA and PFA should be next to each other.
18:31:40 <ASau> String representation matters little here.
18:31:52 <ASau> First, this makes traversing list easier.
18:32:09 <ASau> You can reuse linked list words later.
18:33:13 <ASau> Second, it makes introspection _possible_.
18:34:49 <ASau> You don't need to do tricks just to be able to perform CFA or PFA to NFA mapping.
18:42:42 <Deformative> So yes, I don't think there is a pp that does what I want.
18:42:49 <Deformative> I will just do it by hand I suppose.
18:42:59 <Deformative> Not too big of a deal, I don't see myself having more than 32 primatives.
18:45:45 <ASau> Deformative: "pp"?
18:45:53 <crc> preprocessor
18:45:59 <KipIngram> That is true; in the traditional layout going from CFA or PFA *to* NFA is tricky.
18:46:01 <ASau> Well...
18:46:08 <Deformative> What crc said.
18:46:17 <ASau> IF you're brave, you may want to look at m4.
18:46:31 <Deformative> I was looking at it.
18:46:48 <KipIngram> Hey, Deformative, that "FIRST / THIRD" approach used just 12 primitives for FIRST, then built the rest on top of that.
18:47:04 <ASau> There is existing practice of writing Forth in as+m4.
18:47:14 <Deformative> KipIngram: I am making a primative for every opcall in the system as well as those needed for forth.
18:47:29 <Deformative> KipIngram: I have 19 opcalls.
18:47:37 <Deformative> Erm, 20.
18:47:43 <Deformative> But I am not making a word for halt.
18:47:44 <Deformative> So 19.
18:47:52 <ASau> If you know how it is done, it takes ca. 1 night.
18:47:57 <crc> http://www.eecs.umich.edu/~pmchen/engr100/lab5/ ?
18:48:29 <Deformative> crc: Yes.
18:49:27 <crc> the assembler won't run on my systems :(
18:50:08 --- quit: ASau (Remote host closed the connection)
18:50:21 <Deformative> You don't have a linux on x86_32 or _64?
18:50:53 <crc> the binary I found was for x86-64, my linux boxen are x86-32
18:51:32 <Deformative> Hmm, professor chen put a 32 bit version up somewhere.
18:51:37 * Deformative searches.
18:53:21 <Deformative> He may have taken it down.
18:53:48 <Deformative> I can get my hands on it next time I go to lab, the 32 bit version is on all the machines there.
18:54:36 <crc> ok
18:54:50 <crc> if you can, I may be able to write you a better assembler to use
18:55:25 <Deformative> Well, the assembler has a built in simulator.
18:55:31 <Deformative> So it is pretty cool.
18:55:55 <crc> judging from the stuff online, the assembler part looks sucky :)
18:56:07 <Deformative> Yeah, the assembler is sucky.
18:56:21 <Deformative> But the simulator is pretty cool.
18:56:39 <Deformative> Simulates all the io ports including vga, shows the complete memory image as it goes.
18:57:48 --- quit: crc (Quit: crc)
18:58:19 --- join: crc2 (~charlesch@c-68-80-139-0.hsd1.pa.comcast.net) joined #forth
18:59:02 --- mode: ChanServ set +o crc2
18:59:12 --- nick: crc2 -> crc
19:00:19 <Deformative> Welcome back.
19:00:29 <crc> thanks
19:17:40 <Deformative> Mmm, this is fun.
19:18:23 <Deformative> I am trying to decide how to structure my memory.
19:19:36 <Deformative> I need a parameter stack, a return stack, the built in code, and the "heap"
19:19:45 <Deformative> I am thinking I can put definitions in the "heap"
19:41:37 <Deformative> Hmm.
19:41:38 <Deformative> http://www.annexia.org/_file/jonesforth.s.txt
19:41:43 <Deformative> Some bits of that are confusing.
19:41:51 <Deformative> I feel like it should define colon first.
19:41:52 <Deformative> Then the rest.
19:43:39 <KipIngram> You're going to put system stuff in a *heap*???
19:43:46 <KipIngram> Why?
19:44:51 <KipIngram> Normally the dictionary goes at the bottom of memory and grows up.  Data stack grows down, but not from the top.
19:45:03 <KipIngram> There's a block at the top for disk buffers, return stack, and sundry other stuff.
19:45:50 <KipIngram> If you have a heap at all I think it should be for your application data, not for Forth.  Forth doesn't really need it; it's so small.
19:45:58 <KipIngram> How much RAM will your system have?
19:46:05 <Deformative> KipIngram: That is what i meant by heap.
19:46:07 <Deformative> Not really a heap.
19:46:18 <KipIngram> But you don't put definitions there.
19:46:22 <Deformative> But just a hunk of memory that isn't one of the two stacks.
19:47:02 <Deformative> System has like 16k or something.
19:47:02 <KipIngram> Well, I guess I won't tell you not to try something different.  God knows I hate it when people tell me that.
19:47:15 <Deformative> Well, what do you have in mind?
19:47:22 <Deformative> How is the forth memory typically partitioned?
19:47:32 <Deformative> I was thinking definitions and application memory would share.
19:48:06 <KipIngram> This is from memory, but I think that generally the dictionary goes at the bottom (low addresses, except for anything your processor requires like reset vectors and so on).
19:48:13 <KipIngram> It grows toward high memory.
19:48:33 <KipIngram> Then there is a boundary line somewhere up towards the top, maybe at 13k or 14k for you.
19:48:48 <KipIngram> The data stack grows down from there.
19:49:13 <Deformative> Makes sense.
19:49:18 <KipIngram> I don't really remember how that top block works exactly, but perhaps the return stack would grow from the very top down and then you'd have buffers, user variables, and things liek that.
19:49:21 <Deformative> And the return/parameter stacks are constant size?
19:49:54 <KipIngram> Well, yes it does.  Hey, "Forth Fundamentals" by McCabe discusses all of this.  You can deviate if you want, but it's a great introduction to the reasoning behind it all.
19:50:38 <KipIngram> Well, I guess the return stack is, since it's growing toward fixed location, fixed size things.
19:50:56 <KipIngram> But you make it big enough not to be an issue.
19:51:19 <Deformative> How big would you think, 128 words?
19:51:31 <Deformative> 64 words for parameter?
19:53:04 <KipIngram> No, much bigger.  I'd want to be able to go hundreds of calls deep.
19:53:22 <KipIngram> Forth wants you to use small words.  Don't make yourself worry about running out of stack space.
19:53:45 <KipIngram> If you ever have to stress over whether you should factor a defintion into  more levels then you didn't give yourself enough room.
19:54:04 <KipIngram> With only 16k I think I'd limit myself to just one disk buffer; two tops.  Those are 1k each.
19:54:13 <KipIngram> Say you use 2.
19:54:29 <KipIngram> Then allocate another 1k for the return stack and "other small stuff".
19:54:45 <KipIngram> That leaves you with 13k.  Data stack grows down into that and dictionary grows up into it.
19:55:10 <Deformative> The reasoning there is obvious.
19:55:16 <Deformative> How large do I make hte parameter stack?
19:55:20 <KipIngram> You will never use 1k for the data stack, I imagine, and 12k is enough room for a *lot* of forth code, particularly if the machine code is compact.
19:55:23 <Deformative> I know the return stack should be much larger.
19:55:40 <KipIngram> Don't worry about a limit.  It just grows down, from 12k in my example.  
19:55:48 <KipIngram> The dictionary grows up from 0, or 0+a bit.
19:55:55 <KipIngram> As long as they don't *collide* you're fine.
19:56:08 <KipIngram> You don't enforce some arbitrary limit on the parameter stack.
19:56:20 <KipIngram> If the dictionary top (HERE) is still several k down, why would you care?
19:56:46 <Deformative> What about the parameter stack though?
19:57:06 <Deformative> Also, do I keep uninterpreted code in a disk block, or?
19:57:14 <KipIngram> If you have an application that needs a real heap, because it allocates and de-allocates a bunch of stuff, then I'd just declare that as a big Forth array (VARIABLE HEAP 4096 ALLOT) and manage it with app code.
19:57:15 <Deformative> Code that still needs to be run through the interpreter.
19:57:38 <Deformative> Makes sense.
19:57:53 <KipIngram> You compile the source you need for whatever app you're running when you run that app.  Source for other apps will be off on disk blocks, not loaded.
19:58:25 <KipIngram> If you will skim "Forth Fundamentals" and "Thinking Forth" you will get a huge education.
19:59:31 <KipIngram> I don't mind answering these questions -- it's not that.  It's just that it's been a long time since I've read them so my memory may be faulty, and they do such a *good job*.
19:59:39 <KipIngram> But if you want to ask me instead that's cool too.
20:00:47 <Deformative> Yah, I will probably read those books sooner or later.
20:00:51 <Deformative> But for now, I would like to ask.
20:00:58 <KipIngram> Normally you will set up your disk so that you can load an app by loading one screen.  (<screen number> LOAD).  If you wanted to you could define constants in your base system that associated appropriate block numbers with each app.
20:01:02 <KipIngram> EDITOR LOAD
20:01:25 <KipIngram> Then on whatever block EDITOR corresponded to you would use THRU to load the range of blocks necessary to fully load the app.
20:02:11 <Deformative> This is what I currently have my memory image looking like: 
20:02:13 <Deformative> // +-------+-----+-----------+----------+-------------------------------+--------+------------+
20:02:15 <Deformative> // | CONST | REG | CORE CODE | BUILTINS | DEFINITIONS->  <-RETURN STACK | PARAMS | DISKBUFFER |
20:02:16 <Deformative> // +-------+-----+-----------+----------+-------------------------------+--------+------------+
20:02:28 <Deformative> That probably won't look so good unless you hve a huge irc client.
20:02:52 <KipIngram> No, it showed up fine on my weechat app.
20:03:06 <KipIngram> PARAMS is the PARAMstack?
20:03:29 <KipIngram> Hang on; I'm going upstairs to fetch McCabe.
20:04:21 <Deformative> Yes.
20:04:49 <Deformative> You can ignore const, I just need a place to store 0,1,2,3,4
20:04:59 <Deformative> Because of limitations in the asm.
20:06:19 <KipIngram> Wow; how fortuitous.  I bought a book on GNU Make yesterday, and as I was looking for McCabe I discovered I already owned a copy.  Now I can take yesterday's purchase back.
20:06:38 <KipIngram> I would fret over being forgetful, but I've probably had it for years and years.
20:06:40 <Deformative> Hah.
20:06:57 <KipIngram> Then I opened McCabe up, and it opened to the page on the memory layout. :-)
20:07:26 <KipIngram> Here you go, from low addresses to hi.  Bear with me, since you aren't getting the book yet I'll be just a bit detailed.
20:07:45 <KipIngram> ORIGIN is the lowest memory address available to Forth.  Below that is reset vector, interrupt vectors, etc.
20:07:56 <KipIngram> Then comes a section called "Boot Up Literals"
20:08:08 <KipIngram> Then the dictionary.  Core words first, and then user defined words.
20:08:20 <KipIngram> That gets us to the address returned by HERE.
20:08:41 <KipIngram> Then the "word buffer", which I think is where Forth puts words it's parsing out of the input stream.
20:09:17 <KipIngram> Then there's an addressed returned by a word called PAD,
20:09:37 <KipIngram> I suppose PAD is just HERE+<some number>, where <some number> is the biggest size any word is expected to be.
20:09:51 <KipIngram> Then comes a "text buffer".  Not sure right now what that is, but I can look it up in this book.
20:09:54 <KipIngram> Then free ram.
20:10:15 <KipIngram> Then the parameter stack; top at low address and bottom at high address.
20:10:38 <KipIngram> S0 @ returns that address (the address from which the parameter stack grows downward).
20:11:20 <KipIngram> To summarize so far, you set ORIGIN based on your system.  You set S0 @.  The other things I mentioned (HERE and PAD) float upward as the dictionary grows.
20:11:50 <KipIngram> From the bottom of the parameter stack up there is the terminal input buffer, TIB.  So S0 @ = TIB @
20:11:55 <KipIngram> Just two names for the same thing.
20:12:23 <KipIngram> Somewhere up higher is the return stack range.  So you pick a place for it to start (R0 @) and it grows down from there, toward the TIB.
20:13:01 <KipIngram> Above R0 @ is the "user area."  I forget what all's in it.
20:13:17 <KipIngram> Then mass storage buffers, and then a "simulated disk" if you have enough memory (you don't).
20:13:38 <KipIngram> But if you have hundreds of kB, or evenjust 64kB, then you can use a bunch of it as a RAM disk.
20:13:45 <KipIngram> That's it; what do you think?
20:13:50 <KipIngram> That's the FIG Forth model, I think.
20:14:26 <Deformative> x.x
20:14:27 <KipIngram> Boot up literals are defined as numeric values necessary for system initialization.  That might be how you set ORIGIN, where the user area starts, etc. etc.
20:14:28 <Deformative> Confusing.
20:14:42 <KipIngram> Well, that's my fault.
20:14:53 <KipIngram> I'm trying to summarize something that's laid out in beautiful detail in this book.
20:15:00 <Deformative> I looked at that book, and my university doesn't provide it as an electronic resource.
20:15:18 <KipIngram> I wrote my first Forth before reading this book.  Then when I read the book I felt like an idiot.
20:15:32 <KipIngram> I remember thinking "Wow, it's all so *simple*."
20:15:41 <KipIngram> "So *clean*."
20:15:51 <crc> my forth has a jump to the startup code, a few variables (dictionary header pointer, heap pointer), the initial forth kernel, and some buffers. everything beyond that is considered free.
20:16:09 <KipIngram> I had not idea what I was doing the first time, beyond some notion of how I wanted it to behave.  My implementation was wildly complex.
20:16:15 <Deformative> My library has it in remote shelving.
20:16:21 <crc> there's an optional block buffer at the end of the memory area
20:16:24 <Deformative> So I can order it, and I will get it within 2 days.
20:16:54 <KipIngram> I recommend it highly.  I don't recommend that you follow it blindly; just that you read it for educational purposes and then make your own decisions.
20:17:34 <Deformative> Can you make a sequential chart of what that book says it should look like?
20:17:58 <KipIngram> Ok; nobody type for a sec.
20:18:01 <KipIngram> 0+ORIGIN
20:18:07 <KipIngram> Core Words
20:18:12 <KipIngram> User Defined Words
20:18:17 <KipIngram> HERE:
20:18:20 <KipIngram> Word buffer
20:18:24 <KipIngram> PAD:
20:18:26 <KipIngram> Text buffer
20:18:30 <KipIngram> Free RAM
20:18:33 <KipIngram> SP @:
20:18:38 <KipIngram> Parameter stack
20:18:41 <KipIngram> S0 @:
20:18:46 <KipIngram> TIB @:
20:18:50 <KipIngram> Terminal input buffer
20:18:56 <KipIngram> Return stack
20:19:01 <KipIngram> R0 @:
20:19:03 <KipIngram> Uer area
20:19:07 <KipIngram> (sorry - user area)
20:19:11 <KipIngram> FIRST:
20:19:15 <KipIngram> Mass Storage Buffers
20:19:18 <KipIngram> LIMIT:
20:19:21 <KipIngram> LO:
20:19:24 <KipIngram> Simulated disk
20:19:26 <KipIngram> HI:
20:19:34 <KipIngram> -----------------------
20:19:53 <KipIngram> Except for 0+ORIGIN I put a : at the end of address markers, and the things without : are area descriptions.
20:19:57 <KipIngram> Is that what you meant?
20:20:05 <Deformative> Yes.
20:20:29 <KipIngram> That's "upside down" from McCabe's illustration, since low addresses are generally drawn at the bottom of the page.  In my list low addresses are first.
20:20:46 <Deformative> I thought HERE was supposed to be in the free ram, not a place that would be overwritten by definitions.
20:21:04 <KipIngram> I'm sorry; I left out boot up literals.  That came right at 0+ORIGIN:, before core words.
20:22:11 --- quit: nighty^ (Remote host closed the connection)
20:23:22 <KipIngram> I think what this book is telling me is that you'd put values in the boot up literal section that told you the initial value of HERE, how much room to put between HERE and PAD, where S0 @ should be, where R0@ should be, and where FIRST, LIMIT, LO, and HI should be.  And so on.
20:25:43 <crc> http://retroforth.com/paste/?id=1977 is the layout I'm currently using
20:26:41 <Deformative> crc: Interesting.
20:27:27 <Deformative> Where is your return stack?
20:27:31 <Deformative> At the end of free memory?
20:27:32 <crc> if I allocated stacks from memory, they'd be located near the end of memory
20:28:22 <crc> the stacks are part of the processor/vm I use
20:28:42 <Deformative> I don't think I will allow for HERE.
20:28:44 * Deformative ponders.
20:28:46 <Deformative> Is it needed?
20:28:52 <Deformative> I mean, arrays can always be used.
20:28:53 <KipIngram> Yes, in my FPGA processor the stacks are in hardware, and of fixed depth.
20:29:02 <KipIngram> Yes, you need HERE.
20:29:24 <Deformative> Can I mix it in with the definitions?
20:29:25 <KipIngram> Forth lets you define words that do fancy compiling; you can extend the language.  You will need HERE.
20:29:30 <crc> Deformative: here returns a pointer to the next free address
20:29:36 <KipIngram> of course; it just returns an address.
20:30:28 <Deformative> Ooh.
20:30:32 <Deformative> I misunderstood here I think.
20:31:03 <crc> in my forth,  : here ( -a ) heap @ ;
20:32:36 <KipIngram> HERE will get used by many of the defintions that are part of standard Forth, so yo may as well make it available for yourself as well.
20:32:55 <Deformative> Here is what I am thinking: | CONST | REG | CORE CODE | BUILTINS | DEFINITIONS-> FREE <-RETURN STACK | PARAMS | INPUT BUFFER | DISKBUFFER |
20:33:05 <Deformative> REG have all the stack pointers and stuff.
20:33:15 <Deformative> HERE for example. (If I understand HERE correctly)
20:33:43 <Deformative> HERE is the end of definitions, yes?
20:33:52 <KipIngram> Yes.
20:34:20 <Deformative> Ok, I already had a HERE and I didn't know that was what it was.
20:34:36 <KipIngram> So if you wanted to create a word that added to the dictionary that's how you know where to go.
20:34:49 <Deformative> I see!
20:34:52 <Deformative> Oh cool.
20:35:00 <KipIngram> LOVE those light bulbs. :-)
20:35:07 <Deformative> The FIRST/THRID didn't explain that.
20:35:08 <KipIngram> Yes; it *is* cool.
20:35:28 <Deformative> So HERE can be used to allocate arrays in definition space.
20:35:42 <KipIngram> Yes.  Old school Forth as a word called CREATE.
20:35:59 <KipIngram> CREATE <some word> will parse <some word> from the input stream and create a header for it.
20:36:08 <KipIngram> That advances HERE by whatever room is required for the header.
20:36:45 <KipIngram> <some word>, if executed, will initially just return the address right after the header (which is the same value as HERE had right after CREATE built that header).
20:37:09 <KipIngram> You can then allot space for an array, or whatever, to be referenced by <some word>.
20:37:09 <Deformative> Makes sense.
20:37:27 <KipIngram> Then there's a word called DOES> that lets  you define defining words.
20:38:24 <KipIngram> I don't remember the syntax exactly, but it lets you create a word that you can then use to define new words, and the DOES> part specifies how those words will behave.
20:38:43 <KipIngram> The sky really is the limit.
20:39:15 <Deformative> Which does compile time and which does runtime behavior?
20:39:23 <KipIngram> In Forth all variables are in definition space, unless they're "user variables" which I never had much use for anyway.
20:39:47 <KipIngram> If you say VARIABLE ALPHA then the two bytes that actually represent the place where the variable is stored are in defintion space.
20:39:51 <KipIngram> It's all linear.
20:40:22 <KipIngram> Ok, I'll try.  Here's a code snip:
20:40:35 <KipIngram> CREATE ALPHA DOES> <forth code>
20:40:40 <KipIngram> ALPHA BETA
20:41:02 <Deformative> OK, FIRST/THIRD confused me.
20:41:07 <Deformative> I am getting a better understanding now.
20:41:16 <KipIngram> That second line declares a new word, BETA, which causes the code defined in <forth code> to execute, starting with the PFA of BETA on the stack.
20:41:54 <KipIngram> So <forth code> can do any darn thing it pleases, and because it has an address specific to BETA on the stack it does it specific to BETA.
20:42:41 <KipIngram> I may be describing this wrong.  Let me look at McCabe; one sec.
20:42:41 <Deformative> So : ___ is basically create ___ does>
20:43:14 <KipIngram> Of course; the system uses this mechanism to define the built-in defining words.  Nice, huh?
20:44:23 <Deformative> Well, in FIRST/THRID : and immediate were the primatives.
20:44:27 <Deformative> The others were derived from those.
20:44:34 <Deformative> In what you describe it is reverse.
20:45:00 <KipIngram> Ok, here you go.
20:45:23 <KipIngram> : <defining word> CREATE <compile action> DOES> <run action> ;
20:45:29 <KipIngram> <defining word> BETA
20:45:42 <KipIngram> This definesw a word, BETA.  
20:45:57 <KipIngram> <compile action> runs when BETA is defined, so you can allocate space, initialize it, etc. etc.
20:46:24 <KipIngram> When BETA gets executed the system puts the address of the memory block associated with BETA on the stack and then executes <run action>.
20:46:31 <KipIngram> I thought I was leaving something out.
20:46:55 <KipIngram> The more you ponder this the more you will see you can do with it.
20:47:20 <KipIngram> Forth lets you completely define application-specific languages, both for compile purposes and for run purposes.
20:49:43 <KipIngram> There is a volume 2 of Forth Fundamentals.  Some words in FIG Forth are defined in assembly, and the rest are defined in FORTH.  FF volume 2 explicitly gives those Forth definitions.
20:49:56 <KipIngram> I don't recommend copying them necessarily, but they are very educational.
20:52:16 <Deformative> I might order this book.
20:52:24 <Deformative> I wonder how long I can hold onto it for.
20:52:33 <Deformative> Perhaps I will just buy it instead of getting it out of the library.
21:01:25 <KipIngram> Get it from the library and then decide.  You're a student; I remember money being pretty precious in those days.
21:02:46 <Deformative> Books are cheap thanks to the internet.
21:03:03 <Deformative> My time is much more valuable to me than money.
21:03:34 <Deformative> If it were not, I wouldn't be on a 3 year track.
21:04:18 <KipIngram> Well, then buy that.  It will jump you past many false starts on this.  You're actually doing this Forth thing as part of your formal college program.  This is an investment.
21:04:51 <Deformative> I always enjoy adding books to my shelf.
21:05:47 <Deformative> Though, it hink it is comming along nicely.
21:05:52 <Deformative> And jonesforth is helping a lot.
21:06:19 <KipIngram> Yes, when I was in your position there was no internet, no irc #forth, etc. etc.  I was completely on my own.  So the book was a *real* eye opener.
21:07:02 <KipIngram> The internet is just such a wonderful thing.  I remember when I started out as a hardware engineer I had to drive around to the offices of electronics distributors and get data books from them so that I would know what parts were available and how they worked.
21:07:07 <KipIngram> No clue about cost, etc. etc.
21:07:31 <KipIngram> These days you google what you're interested into identify parts, download the datasheets, and check prices on Digikey and Mouser.
21:07:47 <KipIngram> You can do in a couple of hours what took days or weeks in the old days.
21:08:26 <KipIngram> One of the big advantages that highly experienced engineers had in those days was familiarity with the parts universe.  The internet has greatly reduced the signficance of that advantage.
21:08:56 <KipIngram> Us old guys still do have some advantages, having to do with lessons learned and so on, but that one has gotten a lot smaller.
21:10:48 <Deformative> Mmm, how large did you recommend I make the param stack again?
21:10:50 <Deformative> 1k?
21:11:37 <KipIngram> The parameter stack doesn't have a limit.  It grows down toward HERE.
21:12:06 <KipIngram> Or, to put it another way, the dictionary and the parameter stack share the same block of memory, growing toward each other from the ends.
21:12:09 <Deformative> I have the return stack grow toward HERE>
21:12:40 <crc> 1k should be plenty for the data stack
21:12:41 <KipIngram> Ok.  Look, some people define mechanisms for local variables and so on in Forth, which could even include arrays.
21:12:42 <Deformative> I have dictionary -> FREE <- return | parameter->
21:12:53 <KipIngram> Those generally get allocated on the data stack.
21:13:02 <KipIngram> I guess you could put them on the return stack, but it's "different."
21:14:13 <KipIngram> You can always change any of this by reassembling your system, of course.
21:14:39 <Deformative> Yep.
21:18:41 <Deformative> I am going to sleep on it, then possibly order that book in the morning or some time during the week.
21:22:03 <Deformative> The FIRST/THRID thing would be a lot better if the C bootstrap was readable.
21:25:03 <KipIngram> Well, for several reasons I thought that guy had a really cool idea but didn't have the patience to see it through all the way.  I'd have also liked it better if it had been FIRST / Forth.  Why not go all the way?
21:27:07 <Deformative> Indeed.
21:28:49 <Deformative> Interesting, I should be able to define \n as a word which searches for the next word.
21:28:53 <Deformative> :D
21:31:54 <KipIngram> You mean the next word in the input stream?
21:32:17 <Deformative> Yes.
21:32:36 <Deformative> But if I do that, it might build up my return stack.
21:32:40 <KipIngram> There is a word for that; hang on.
21:32:42 * Deformative ponders.
21:34:00 <KipIngram> Interestingly enough, it's called WORD. ;-)
21:34:17 <KipIngram> You pass a delimiter character to it on the stack, and it parses the next delimited word from the stream.
21:34:28 <KipIngram> Leaves you an address that points to it.
21:34:39 <Deformative> Yep.
21:34:50 <Deformative> I was going to give \n the same definition as word.
21:34:54 <Deformative> Is there a way to do that in forth?
21:35:08 <KipIngram> It will normally put that at HERE, so that it's already in place when you want to use it in a header.
21:35:17 <KipIngram> That is Forth.  WORD is a Forth word.
21:35:26 <Deformative> I know.
21:35:35 <Deformative> But is there a way to define something as something else.
21:35:37 <KipIngram> So do you mean can you define that in forth?
21:35:37 <Deformative> Virbatim.
21:36:06 <KipIngram> Or do you mean can you create a word called \n that does the same thing as WORD?
21:36:12 <KipIngram> You can; like this:
21:36:16 <KipIngram> : \n WORD ;
21:36:44 <Deformative> But then it has an extra stackframe.
21:36:56 <KipIngram> Yes, that costs you two bytes of return stack space.
21:37:04 <KipIngram> There is no #define mechanism in Forth.
21:37:20 <Deformative> I see.
21:37:23 <crc> some forths have a word like "alias" for this
21:37:42 <KipIngram> Well, you could do this, I guess:
21:37:58 <KipIngram> : \n [ ' WORD ] COMPILE ;
21:38:02 <KipIngram> Or something along those lines.
21:38:06 <KipIngram> I probably blew that one big time.
21:38:23 <KipIngram> Lots of complications there.
21:38:51 <KipIngram> It would need to be immediate so it ran at compile time, and then it would have to figure out if it was compile time or not so it would know whether to run or compile, etc.
21:38:54 <KipIngram> But it could be done.
21:39:22 <KipIngram> Best just to use WORD.  To quote Neil Diamond, "that's what it's there for."
21:40:56 * Deformative ponders.
21:41:25 <Deformative> I am having a hard time figuring out how to implement IMMEDIATE stuff.
21:42:38 --- quit: tgunr (Quit: Leaving...)
21:44:05 <Deformative> I suppose i need a flag for it...
21:44:14 <scj> have you looked at jonesforth.s.txt?
21:47:13 <Deformative> Yeah, that is what I am basing mine off.
21:48:17 <KipIngram> Yes, you need a flag.
21:48:36 <KipIngram> Historically that was stored in the sign bit of the count byte for the name length.
21:48:49 <KipIngram> But it's simple with a flag.  If that bit is set, you execute it, even if you're compiling.
21:48:51 <KipIngram> Done.
21:49:38 <Deformative> But can't some words be both immediate and non?
21:49:45 <KipIngram> No.
21:49:49 <Deformative> What about if?
21:50:02 * crc doesn't use flags :)
21:50:07 <Deformative> crc: How do you do it?
21:50:21 <crc> Deformative: normally if can only be used inside a definition
21:50:26 <crc> Deformative: word classes
21:50:33 <KipIngram> IF executes at compile time.  It's action is to do some things right then to provide for compile time error checking and to *compile* a "jump on zero" command with an unfilled-in address.
21:50:42 <crc> http://rx-core.org/pages/?TheListener and http://rx-core.org/pages/?WordClass
21:50:45 <KipIngram> THEN or ELSE will fill in the appropriate address.
21:51:04 <KipIngram> So IF itself doesn't have a run time component, but it does compile something different that will run at run time.
21:51:06 <KipIngram> Make sense?
21:51:10 <KipIngram> buffer 3
21:52:53 * Deformative ponders.
21:53:15 <Deformative> Well, all my characters are utf-16
21:53:18 <Deformative> Sooo...
21:53:35 <Deformative> I can just put the flag in the first character if I need to.
21:53:43 <Deformative> Or somewhere.
21:55:54 <KipIngram> Exactly.  Anywhere will do.  If you really wanted to generalize this you could have two CFA pointers for every word - one for runtime and one for compile time.  STATE would tell you which to use.  Immediate words would have the pointers both point to the same place.
21:56:26 <KipIngram> Then a custom defining word would have the compile time pointer point to the defining behavior and the run time pointer point to the run time behavior.
21:56:54 <KipIngram> All non-immediate word would have the compile time behavior point to a word that compiled a pointer to the word.
21:57:25 <KipIngram> I don't know if that would really be worth anything, but it would work.
21:57:27 <KipIngram> buffer 3
21:57:35 <KipIngram> Sorry -- reading two channels right now.
21:58:15 <Deformative> crc: Your listener is interesting.
21:58:27 <crc> my forth is quite non-standard
22:00:57 <Deformative> So...
22:01:01 <Deformative> Your forth never compiles?
22:01:24 <crc> it does compile, but compilation is handled by the word classes
22:02:23 <crc> I can define new classes without altering listener ;)
22:04:04 * Deformative is confused.
22:04:41 <crc> every word has a corresponding class (a word that takes the xt and does something with it)
22:05:00 <crc> the interpreter just passes control to the class words
22:05:35 <crc> http://bespin.org/~nef/logs/retro/10.02.05 has some discussion on this
22:05:53 * crc has to go (1am), but will be back later
22:05:54 <Deformative> Isn't that how all forths do it?
22:05:56 <Deformative> THe "codeword"
22:05:57 <crc> no
22:06:22 <Deformative> My processing power is lowered because I have gotten so much sleep today.
22:06:22 <crc> i only know of three forths that use this approach
22:06:38 <Deformative> Is jonesforth one?
22:06:48 <crc> no
22:06:57 <Deformative> Have you read jonesforth?
22:07:01 <crc> yes
22:07:06 <Deformative> Hmm.
22:09:28 <Deformative> Could I have different definitions for compile and runtime.
22:09:30 <crc> the interpret loop in jonesforth does the check for compiler state and lays down code
22:09:32 <Deformative> Like use colon for runtime
22:09:39 <Deformative> And some other punctuation for compiletime.
22:09:58 <crc> if you want to
22:10:10 <crc> forth tends to be pretty flexible with what is allowed :)
22:10:27 <Deformative> Does forth ahve a standard way?
22:10:35 <Deformative> What am I supposed to use?
22:10:48 <crc> some forths ([cmforth comes to mind]) have two linked lists, one for compile time words, one for normal words
22:10:59 <crc> Deformative: most forths use an immediate flag in the header
22:11:06 <crc> and have the interpreter loop lay down code
22:11:21 <Deformative> I mean, int he code itself.
22:11:31 <Deformative> I know colon is for runtime code.
22:12:19 <Deformative> Forth is so simple, but the documentation makes it complicated sometimes...
22:16:46 <KipIngram> crc just said it - the traditional approach is this:
22:17:12 <Deformative> crc: I had considered that.
22:17:18 <Deformative> I think I will gow itht hat.
22:17:38 <KipIngram> The interpreter uses a variable called STATE to keep up with whether it's compiling or not.  : switches into compile mode, ; back out.  Other words tinker with STATE too, but those are the really important ones.
22:18:31 <KipIngram> Then, when the interpreter plucks a word from theinput stream, it says "if I am not compiling, or if this word is immedate, then execute it.  If I am compiling and the word is not immediate, then compile it."
22:18:32 <KipIngram> That's it.
22:20:57 <Deformative> That clears things up.
22:21:19 * Deformative added a STATE register.
22:21:28 <KipIngram> :-)
22:22:43 <Deformative> Is there a list of standard forth words somehwere?  Starting forth has them at the end of each chapter, not sure if those are the best option though.
22:24:52 <Deformative> So.. : COMPILEDEF : IMMEDIATE ; would be a colon for defining compile time functions?
22:25:55 <KipIngram> That doesn't look right.
22:26:32 <KipIngram> Oh, well, hang on...
22:26:51 <KipIngram> But this word itself (COMPILEDEF) wouldn't be immediate.
22:27:35 <KipIngram> So if you said COMPILEDEF ALPHA the : would execute first and would start a colan defintion called ALPHA.  Then IMMEDIATE would execute and mark ALPHA's header as immediate.
22:27:46 <KipIngram> And you'd finish up in compile mode, just as if you'd run :. 
22:27:51 <KipIngram> Is that what you had in mind?
22:27:54 <KipIngram> So 
22:28:04 <KipIngram> COMPILEDEF ALPHA ... ;
22:28:21 <KipIngram> Would create an immediate word called ALPHA with ... as its run time action?
22:28:26 <KipIngram> Why wouldn't you just do this:
22:28:33 <KipIngram> : ALPHA ... ; IMMEDIATE
22:28:38 <KipIngram> That's the conventional way.
22:29:48 <KipIngram> I think the last one or two questions you've asked have more to do with what you *use* these tools for and less to do with how you make them work in your implementation.
22:29:59 <Deformative> COMPILEDEF would be immediate because it would not be within a : when called.
22:30:27 <KipIngram> That doesn't make it immediate.  It *runs immediately*, but doesn't have its immediate flag set.
22:30:41 <KipIngram> "immediate" means that the word runs even if you encounter it inside a : definition.
22:31:11 <Deformative> I understand.
22:31:23 <Deformative> But anything defined with COMPILEDEF would be an immediate word.
22:31:29 <KipIngram> Correct.
22:31:37 <KipIngram> That's my reading of it.
22:31:41 <Deformative> Cool.
22:31:48 <Deformative> DId you say :. was the raditional way to do that?
22:32:24 <KipIngram> The traditional way define an immedate word is just to define it, and after you close the definition out with a ; you then run IMMEDIATE.
22:32:46 <KipIngram> : <name of immediate word> <definition of immediate word> ; IMMEDIATE
22:33:05 * Deformative ponders...
22:33:09 <Deformative> I do not understand how that works.
22:33:10 <KipIngram> IMMEDIATE just sets the immediate flag of the most recently defined word.
22:33:31 <KipIngram> Or rather of the most recently defined *header*.
22:33:32 <Deformative> I thought IMMEDIATE changed the state to immediate.
22:33:44 <KipIngram> No, it changes the flag of a header.
22:33:57 <Deformative> Oooooh.
22:34:12 <KipIngram> The variable STATE is affected by (I think this is a complete list)  :  ;  [  ]
22:35:16 <KipIngram> It doesn't matter if the definition associated with the header is complete; as long as the header is there IMMEDIATE will act on it.  That's why your COMPILEDEF word works; when it runs IMMEDIATE only the header is there.  The rest of the definition isn't.
22:35:39 <Deformative> I see.
22:35:58 <Deformative> Seems as though it would be easier to have two different definition types than have the IMMEDIATE word.
22:36:05 <Deformative> Colon and something else
22:36:16 <Deformative> More intuative. 
22:36:42 <Deformative> Is there some reasoning for IMMEDIATE rhter than a different defintion type?  Just so that it can be used after a definition, or?
22:37:46 <Deformative> Is :. a word?
22:38:13 <KipIngram> Did you really mean to type a colan followed by a period:   :.
22:38:18 <KipIngram> No, :. isn't a word.
22:38:20 <Deformative> Oh.
22:38:47 <Deformative> I think I will add .: or :. to my forth for defining immediate words.
22:38:49 <Deformative> I like that idea.
22:38:54 <Deformative> Or i:
22:38:57 <KipIngram> Well, there aren't many immediate words.
22:39:05 <Deformative> i: seems intuative.
22:39:39 <KipIngram> So having some mechanism that required you to define run and compile time actions for all words (like my dual CFA idea above) probably adds more complexity that it saves.
22:39:53 <KipIngram> IMMEDIATE is simple.  When it's run it just sets that flag.
22:40:29 <Deformative> Hm, I am not seeing how that is more simple.
22:40:38 <KipIngram> And it doesn't combine the function of setting the immediate flag with the function of starting a colan definition.
22:41:41 <KipIngram> I don't recall ever needing IMMEDIATE for anything other than a colan definition, so in that case your idea will work fine, but you are giving up the ability to simply IMMEDIATE a word with no further todo.
22:42:17 <KipIngram> What if for some reason you wanted an immediate variable?
22:42:25 <KipIngram> Are you going to also define iVARIABLE?
22:42:29 <KipIngram> iCONSTANT?
22:43:05 <KipIngram> I don't know if you'd ever need that ability, but with the conventional approach you can say VARIABLE ALPHA IMMEDIATE
22:44:03 <Deformative> Interesting...
22:44:13 * Deformative ponders.
22:45:14 <KipIngram> Geez - Keystone Light is hardly more than water.
22:46:11 <Deformative> Well.. variables are just definitions... But...
22:46:22 <KipIngram> See here - do it like this.  Define IMMEDIATE i the usual way.  Then define i: as   : i; IMMEDIATE ;
22:46:40 <KipIngram> Then use them both and see which one you like.  Or use i: and then if you ever need IMMEDIATE it's there.
22:46:54 <KipIngram> You're going to have to have code to set that flag; giving it a header isn't that big a deal.
22:47:46 <Deformative> Perhaps I will have iCREATE.
22:47:57 <Deformative> Because I really like the idea of having different dictionaries.
22:48:39 <KipIngram> I don't.  Remember that will further sectionalize your memory, and you have relatively limited memory.  You will have to decide, in advance, how much space to allocate for each one.
22:48:50 <KipIngram> Every time you add more of those decisions it's harder to get it right.
22:49:07 <Deformative> And moving something from one dictionary to another seems like a hassle.
22:49:09 <KipIngram> If you had scads of memory it would be different; you could just throw RAM at every section.
22:49:14 <Deformative> Dictonary is linked list, they occupy the same memory.
22:49:18 <KipIngram> Right, whereas flipping the flag is easy.
22:49:34 <KipIngram> Oh, ok.
22:50:03 <KipIngram> Fair enough.  And moving from one to the other would still be a hassle, but at least you could do it by changing only pointers; you wouldn't have to physically copy anything.
22:50:24 <KipIngram> So not a huge hassle, just a small one.
22:50:38 <Deformative> Exactly.
22:51:38 <Deformative> Ok, I will use the IMMEDIATE keyword.
22:51:45 <Deformative> Your variable example really made me understand.
22:51:46 <Deformative> Thankyou.
22:52:27 <KipIngram> Happy I could shine a light.  I like it that you're scrutinizing this stuff so carefully; it's good.
22:52:33 <KipIngram> Kick the tires hard.
22:53:09 <Deformative> :)
22:53:27 <Deformative> I feel like I could never understand htis without coding it myself.
22:53:49 <Deformative> Well, not from starting forth anyway.
22:54:14 <Deformative> Perhaps if I had a more logical explanation of it.
22:54:19 <KipIngram> I agree completely -- Forth is simple enough that it's feasible to code it yourself without it being a huge ordeal.  And it really does drive home a lot of points.
22:54:48 <KipIngram> Well, Forth Fundamentals really does explain these internals quite well, at least from a FIG Forth perspective.
22:54:59 <Deformative> I feel like starting forth focused way too much on the parameter stack despite that being a relatively small hunk of the system.
22:55:57 <KipIngram> There are many other ideas out there.  For instance, in the system I'm building now I'm deliberately allowing (but not requiring) definitions to live remote from headers, so that I can compile the code for application words to my target RAM without having to put the headers there.
22:56:11 <KipIngram> That's a departure from the FIG structure we've been discussing, but not a very major one.
22:56:31 <KipIngram> It just means that the CFA doesn't follow the name.  A pointer to the CFA follows the name.
22:56:48 <KipIngram> Or maybe comes before the name, since ASau advises that all fixed length stuff comes first.  I see some merit in that.
22:57:29 <KipIngram> But that's a very minor structural change.  If I really want to be able to go from CFA/PFA to NFA then I'll need a pointer back from the target memory range, but that's just a couple of bytes per word.
22:58:12 <Deformative> I have all the fixed lenght stuff come first.
22:58:24 <KipIngram> Or I could search the dictionary for a word that poined to the spot I'm trying to backtrack from.  More time consuming, but requires no precious target RAM.
22:58:49 <KipIngram> And target RAM is quite precious to me.
22:59:21 <KipIngram> To me this is one of the best reasons in the world to know Forth.  If you need to do a *lot* with a very, very small amount of memory, Forth is your answer.
22:59:41 <Deformative> FIRST really confused me as far as immediate goes.
22:59:46 <Deformative> Jonesforth is much more correct.
23:00:12 <Deformative> Memory is so slow.
23:00:23 <Deformative> I would like to keep everything in the cache. :D
23:00:26 <KipIngram> I expect to be able to build entire reservoir inspection apps in just a few hundred bytes of memory.
23:01:13 <KipIngram> Same here.  When I refer to "target RAM" I'm referring to the block RAM that's *in the FPGA*.  I'd like to never need external RAM chips unless I need it for data storage.
23:02:20 <Deformative> Even for a laptop, it would be nice to keep near everything in the cache.
23:04:04 <KipIngram> Yes it would.
23:09:22 <Deformative> I wish I had syntax highlighting for this assembly I am programming in.
23:09:25 <Deformative> But it isn'
23:09:39 <Deformative> t worth the time to write a config file.
23:11:50 <Deformative> Ooh, [] are the words I was looking for earlier.
23:11:55 <Deformative> Ok, that helps a lot.
23:13:08 <KipIngram> Yeah, those are cool words.  I remember building cooperative multitasking into a Forth app that I built once.  I used pforth for that and built my stuff on top of it.
23:13:21 <KipIngram> The phrase [ ... ] appeared commonly there.
23:13:33 <KipIngram> Where ... was a word of my own creation that drove the cooperative multitasking.
23:14:23 <KipIngram> I can't even remember exactly how that worked now.  It was all about running a surface mount pick and place machine.
23:14:51 <KipIngram> Lots of different hardware elements that ran at different rates.  You had to start anyone who was ready, etc. etc.
23:14:53 <Deformative> Jonesforth defines : in forth at the end.
23:14:57 <Deformative> I wish it did it at the beginning.
23:15:08 <Deformative> It would have made me understand things better from the beginning.
23:15:19 <KipIngram> You're there now, though.
23:15:35 <Deformative> Yeah.
23:15:40 <KipIngram> Basically that system started a loop that said "run until everyone is done".
23:15:54 <Deformative> [ does what I thought IMMEDIATE does.
23:16:00 <KipIngram> Each word in the loop handled one device, or maybe even one component placement on the target pcb.
23:16:02 <Deformative> That makes so much more sense now.
23:16:27 <KipIngram> Each word said "if I have everything I need to run, then let me start my hardware and then exit.  If not, let me just exit."
23:16:41 <KipIngram> So whatever got ready to go first got first attention, and so on.
23:16:50 <KipIngram> When everything was done the whole loop exited.
23:17:17 <Deformative> Somewhat like extending the compiler to support a threadpool natively.
23:17:20 <KipIngram> I used CREATE ... DOES> and my ... word so that the top level forth read very nicely as a scripting language for managing the system.
23:17:27 <KipIngram> Yes, exactly.
23:18:14 <Deformative> I have a list of grad courses I can already take, and would like to, but if I take them before I enroll, they won't count toward my graduate degree.
23:18:17 <Deformative> So I have to wait until I take them.
23:18:24 <KipIngram> The end user was insulated from the "cooperative" requirement; my words made all that work.  The end user just defined the feeders, the PCB fiducials and placements, and so on.
23:18:58 <KipIngram> Because if you take them now they'll count toward your undergraduate degree instead?
23:19:17 <Deformative> Things like, "Programming languages, advanced programming languages, and parallel Computing"
23:19:30 <Deformative> Yes, precisely.
23:19:58 <Deformative> I can dual enroll in both the undergrad school and the grad school, but that costs a LOT Of money.
23:19:59 <KipIngram> Yeah, they're darn well going to make sure they don't let you count a course toward two degrees.  They get less money from you that way. ;-)
23:20:06 <Deformative> So I need to hold it for my last term as an undergrad.
23:20:23 <Deformative> I can count 8 credits for 2 degrees if my GPA is above a 3.6
23:20:27 <Deformative> But it costs a mint.
23:20:41 <KipIngram> Like I said - they will make sure they get your money.
23:20:49 <Deformative> Yep, but it saves me a LOT of time.
23:20:55 <Deformative> And like I said, time is the most valuable. :)
23:20:57 <KipIngram> Does it cost more than it would cost doing the same work separately?
23:21:15 <Deformative> I think it is less, though I am not positive.
23:21:26 <KipIngram> Then there you go.  
23:21:38 <Deformative> Because if you qualify then you are an exceptional student, so it is a "scholarhip" of sorts.
23:21:51 <KipIngram> But look, you can't expect a lot of sympathy when you're 18 and complaining to a guy pushing 50 that you're short on time.
23:22:01 <KipIngram> You have all the time in the world.
23:22:40 <Deformative> Arguably.
23:23:07 <KipIngram> :-)  On that note, I'm out for the night.  Catch you all tomorrow.
23:23:20 <Deformative> Yep, thanks for all the help and conversation.
23:23:21 <Deformative> Goodnight.
23:46:41 <Deformative> I don't know if I am going to support the hidden flag.
23:59:59 --- log: ended forth/10.02.20