00:00:00 --- log: started forth/09.11.12 00:59:01 --- join: GeDaMo (n=gedamo@212.225.108.57) joined #forth 01:07:34 --- part: crink left #forth 01:12:42 There're no changes there. 01:19:53 --- quit: nighty__ (Remote closed the connection) 01:28:26 --- join: maht (n=maht__@85-189-31-174.proweb.managedbroadband.co.uk) joined #forth 01:40:52 --- join: foxLaptop (i=flash@222.131.172.47) joined #forth 04:10:24 --- join: sunwukong (n=vukung@business-80-99-161-225.business.broadband.hu) joined #forth 04:18:09 --- quit: ASau (Read error: 104 (Connection reset by peer)) 04:28:35 --- join: ASau (n=user@host183-231-msk.microtest.ru) joined #forth 04:46:51 --- join: DrunkTomato (n=DEDULO@ext-gw.wellcom.tomsk.ru) joined #forth 05:15:00 --- quit: GeDaMo ("Leaving.") 05:25:05 --- join: Al2O3 (n=Al2O3@12.44.145.42) joined #forth 05:42:08 I didn't see anything new on the colorForth page. 05:43:23 I've wished for years that Chuck (or anyone, for that matter) could get something like that to take flight. It just doesn't seem to be happening though. It's as though the world has gotten so committed to having everything complicated that it can't even consider the idea that simplicity and elegance is the better path. 06:22:12 --- join: ASau` (n=user@host183-231-msk.microtest.ru) joined #forth 06:37:47 --- quit: DrunkTomato () 06:38:10 --- quit: ASau (Read error: 110 (Connection timed out)) 06:42:30 --- join: xjrn (n=jim@astound-69-42-10-25.ca.astound.net) joined #forth 06:47:39 --- quit: Raystm2 ("User pushed the X - because it's Xtra, baby") 06:50:18 KipIngram: path dependency is normal. 06:55:24 Hey, I'm thinking more today about that FPGA-based Forth processor. Question: Forth provides >R and R>, of course. But is it required by the standard that those actually affect the return stack, or is it merely required that >R "put" the TOS somewhere such that R> will bring it back? Adding logic pathways between the data stack and the real return stack is going to impact my maximum clock speed. 06:55:36 Requires additional muxes in the pathways. 06:56:38 I've played evil games with the return stack myself, to skip words and stuff like that. But I don't know if the standard requires that such things work. 06:56:57 It seems like the kind of thing the standard might *not* want you to do. 06:59:00 --- join: DrunkTomato (n=DEDULO@217.18.135.36) joined #forth 06:59:15 If allowed I could speed things up by providing a "scratch stack" that >R and R> affected. 07:00:58 I guess I'll have a similar question about loop counters. I'd prefer to keep them on the scratch stack too. Basically I'd like to have the return stack do nothing at all except store return addresses until they are needed for the return. 07:02:24 There would be no explicit user access to the return stack at all. 07:03:34 Although I could probably arrange a readable copy of it - so the real restriction would be "no user modification." 07:06:36 Heck - it's my processor, isn't it. I'll do it how I like. 07:06:50 Which means the way that runs fastest. 07:12:55 This thing is going to have 5-bit primitive opcodes. I plan to use two instructions for "return"; that lets me recognize a return instruction by looking at only four bits instead of five. That eliminates a level of logic in the decision pathway. So, in addition to "return" I have 30 possible primitive operations. Suggestions? 07:13:29 --- quit: sunwukong ("bye") 07:13:31 No opcode required for "call"; that's encoded in the 16th bit of the code words. 07:16:02 My understanding of standard is that "R" is scratch stach. 07:16:08 stack 07:16:16 That's good. :-) 07:16:56 OTOH, it is really nice to have access to return points. 07:17:12 So lets see, the first eight primitives I wrote down were swap, drop, over, +, -, LIT, @, and !. 07:17:37 Well, like I said, I can arrange to read return stack content. Is that good enough, or do you really really want to modify them? 07:17:51 It's a creepy road to go down, though I've done it. 07:18:18 Oh, and I guess >R and R> will be primitives. 07:18:29 Yes, I need to modify them. 07:18:31 So that's ten. 07:18:48 Ok. In my current design you can't. Maybe something clever will occur to me. 07:18:50 KipIngram: Who cares about the standard, eh? 07:19:08 schme: everyone except marginals. 07:19:09 That sort of is my sentiment. Like I said, it's my processor. :-) 07:19:52 What's the name of that really minimal Forth, with like 27 primitives? I need to look at that list of operations. 07:20:12 1+, 1-. That makes 12. 07:21:47 I guess negate should probably be a primitive too, shouldn't it? Then if I get into trouble I could forego - as a primitive and implement it as NEGATE +, though I'd hate to do that. 07:22:13 I'm putting them both on the list for now. 07:23:15 The F21 instruction set is the one, I think. 07:24:22 Wow; this is interesting: http://www.rdrop.com/~cary/html/minimal_instruction_set.html. 07:24:38 Three bit opcodes, so I could have five in a 16 bit word. 07:24:42 Thoughts? 07:25:56 Although they have ! backwards; they describe it as ( a d -- ) instead of ( d a -- ) 07:26:16 --- join: GeDaMo (n=gedamo@212.225.108.57) joined #forth 07:27:35 Ugh. I hate how they handle literals. Build them up bit by bit, more or less. 07:28:20 You don't need to be that extreme. 07:30:47 There is an instruction in the list of eight to call a routine at a data stack specified address. That's nice - jump tables, etc. But there isn't an instruction for return. That's a show stopper. 07:36:05 --- join: qFox (n=C00K13S@5356B263.cable.casema.nl) joined #forth 07:37:21 --- quit: ygrek (Remote closed the connection) 07:37:23 You know, maybe building up literals isn't such an awful idea. In my original scheme I had three 5-bit opcodes packed per code word. If one of them needs to be lit, and it doesn't happen to be the last one, what do I do? Pack with noops? Try to be smart and use the remaining primitive slots anyway? Having literals show up in the code stream might compicate the instruction sequencing logic a bit, 07:37:24 slowing it down. 07:38:31 In any case, a literal would require from 21 to 31 bits (16 for the literal itself and 5 to 15 for the primitive, depending on where it fell and how I handled it). 07:39:12 In the build-up scheme it would require 51, always. 48 for the 16 "bit buildup" operations and the final 3 for an operation to transfer it to the stack. 07:39:39 Well, small literals would require less I guess, if I cleared the build-up register to zero every time I finished with it. Then I'd only have to shift in the low order bits. 07:39:46 I'm starting to like it instead of hate it. 07:56:26 --- quit: Al2O3 () 08:02:28 Nah, I don't think so. I will stay with five-bit opcodes and pack three per word. 08:02:35 That was fun, though. :-) 08:08:02 --- quit: ASau` ("off") 08:10:08 --- part: GeDaMo left #forth 09:03:04 --- quit: I440r ("Leaving") 09:30:30 --- join: ASau (n=user@83.69.227.32) joined #forth 09:54:55 --- join: ygrek (i=user@gateway/gpg-tor/key-0x708D5A0C) joined #forth 10:20:54 --- join: kar8nga (n=kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth 10:28:15 --- join: TR2N (i=email@89.180.140.144) joined #forth 10:29:37 Wow - the Xilinx Spartan 6 family is fast, fast, fast. 10:58:56 --- join: Judofyr (n=Judofyr@cC694BF51.dhcp.bluecom.no) joined #forth 11:04:35 --- quit: Judofyr (Remote closed the connection) 11:07:52 The Spartan 6 parts have lots of distributed RAM on board, too - with nanosecond or so access. It looks like more than enough to handle a wide range of applications, given how compact Forth code can be. 11:08:06 I think external memory would be needed for data only. 11:18:36 --- join: Judofyr (n=Judofyr@cC694BF51.dhcp.bluecom.no) joined #forth 11:49:02 --- quit: Judofyr (Remote closed the connection) 12:34:54 --- join: forther (i=cf2f2264@gateway/web/freenode/x-pxtupowuzhessfse) joined #forth 12:35:03 hi 12:50:42 --- quit: forther ("Page closed") 12:59:39 It looks like this Spartan 6 family, in the medium speed grade, could run at a basic clock rate of 500 MHz. 13:18:47 --- join: Judofyr (n=Judofyr@cC694BF51.dhcp.bluecom.no) joined #forth 13:28:50 Ok, maybe 400 MHz. Flip flops havea nasty 790 ps setup time requirement. 14:18:48 --- quit: ygrek (Remote closed the connection) 14:29:51 --- join: tathi (n=josh@dsl-216-227-91-166.fairpoint.net) joined #forth 14:34:00 KipIngram: I had the impression (could be completely wrong though) that on Chuck's chips, the lit instruction fetched the cell and advanced the IP without affecting the cached word of opcodes... 14:35:07 --- quit: qFox (Read error: 104 (Connection reset by peer)) 14:39:50 --- quit: nighty^ ("Disappears in a puff of smoke") 14:48:39 --- quit: kar8nga (Remote closed the connection) 14:49:39 --- quit: Judofyr (Remote closed the connection) 14:54:55 --- quit: DrunkTomato () 15:03:30 --- quit: madgarden ("Leaving") 15:46:25 --- quit: TR2N (Read error: 145 (Connection timed out)) 15:46:43 --- join: TR2N (i=email@89-180-204-132.net.novis.pt) joined #forth 16:50:36 --- join: madgarden (n=madgarde@CPE001d7e527f89-CM00159a65a870.cpe.net.cable.rogers.com) joined #forth 16:54:36 --- join: nighty^ (n=nighty@210.188.173.245) joined #forth 17:03:04 --- join: Snoopy_1711 (i=Snoopy_1@dslb-084-059-223-240.pools.arcor-ip.net) joined #forth 17:09:57 --- quit: Snoopy_1611 (Read error: 60 (Operation timed out)) 17:15:31 --- join: PoppaVic (n=pops@adsl-99-35-30-22.dsl.sfldmi.sbcglobal.net) joined #forth 17:48:54 --- quit: foxLaptop (Read error: 104 (Connection reset by peer)) 18:25:49 tathi: Yes, I think you're right. That occurred to me as I considered it more fully. Literals, variables, and constants should all be fairly straightforward. 18:30:08 The thought process did lead me to identifying a couple of useful primitives. Variables require the ability to push the IP onto the data stack; constants the ability to push the data stroed at the IP. With literals you just advance the IP, but with contants and variables you do a return. 18:31:12 It's nice that three opcodes can pack into a word; that means one increment of the IP does the job for variables and constants. 18:38:55 which imp is this? 19:43:58 --- join: foxLaptop (i=flash@222.131.172.47) joined #forth 20:06:58 --- quit: tathi ("leaving") 20:48:15 --- join: Al2O3 (n=Al2O3@71-214-171-153.tcso.qwest.net) joined #forth 21:53:48 --- part: PoppaVic left #forth 22:08:06 --- join: flash__ (i=flash@222.131.163.19) joined #forth 22:09:52 --- quit: ASau ("off") 22:17:13 --- quit: foxLaptop (Read error: 110 (Connection timed out)) 22:17:54 --- quit: foxes (Read error: 110 (Connection timed out)) 22:58:44 --- join: ygrek (i=user@gateway/gpg-tor/key-0x708D5A0C) joined #forth 23:14:15 --- join: ASau (n=user@host92-230-msk.microtest.ru) joined #forth 23:16:24 --- join: qFox (n=C00K13S@5356B263.cable.casema.nl) joined #forth 23:24:00 --- quit: kleinjt (Remote closed the connection) 23:39:00 --- join: kleinjt (n=kleinjt@tarsonis.dhcp.rose-hulman.edu) joined #forth 23:52:21 --- join: foxLaptop (i=flash@222.131.163.19) joined #forth 23:59:59 --- log: ended forth/09.11.12