00:00:00 --- log: started forth/04.01.07 00:11:54 --- quit: jbj_tampa ("Leaving") 00:56:41 --- join: onetom (~tom@cab.bio.u-szeged.hu) joined #forth 01:57:37 --- quit: Robert ("brb") 02:23:26 --- join: MarkT (mark@tom.nss.udel.edu) joined #forth 03:33:04 --- part: MarkT left #forth 04:13:30 --- join: Robert (~snofs@c-7e5a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 04:31:18 --- quit: qFox (sterling.freenode.net irc.freenode.net) 04:51:33 --- join: chrisrw (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 04:51:53 --- quit: chrisrw (Read error: 54 (Connection reset by peer)) 05:00:40 --- quit: hovil ("Leaving") 05:31:24 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 05:32:34 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 05:33:31 --- quit: rO| (Read error: 60 (Operation timed out)) 06:09:11 --- quit: I440r ("Leaving") 07:07:19 --- quit: fridge (Remote closed the connection) 07:08:13 --- quit: tathi ("leaving") 07:18:13 --- join: I440r (~mark4@saturn.vcsd.com) joined #forth 07:56:32 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 08:21:50 what's the linux device name (/dev/...) for COM1? 08:22:12 /dev/ttyS0 08:23:02 thanks 08:24:44 welcome 08:34:38 --- quit: cmeme (Remote closed the connection) 09:10:52 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 09:40:18 --- join: cmeme (~cmeme@216.184.11.30.unused.swcp.com) joined #forth 10:19:13 --- join: schihei (~schihei@pD9548ED1.dip.t-dialin.net) joined #forth 11:11:18 --- join: schihei_ (~schihei@pD9548ED1.dip.t-dialin.net) joined #forth 11:11:25 --- quit: schihei (Client Quit) 11:11:28 --- quit: schihei_ (Read error: 54 (Connection reset by peer)) 11:14:42 --- quit: Herkamire (Read error: 110 (Connection timed out)) 11:33:48 --- quit: tathi ("leaving") 12:20:20 : .min.sec 60 /mod swap 0 <# #s ':' hold drop #s #> type ; 12:24:07 Hi cleverdra 12:24:11 Long time no see :) 12:54:36 Indeed. 13:35:16 --- quit: qFox ("if at first you dont succeed, quit again") 14:46:03 --- join: imaginator (~gps@166.70.196.201) joined #forth 14:46:16 Hi 14:46:26 Hello 14:49:07 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 14:49:14 * imaginator is designing a lambda word for his Forth 14:49:47 * imaginator decided he doesn't like the term ":NONAME" 14:50:20 heh, I was just about to ask how the two are different 14:50:55 To make things simpler to integrate with my existing Perpheon_compile() I'm going to make lambda a special word name. 14:51:15 At least I think that's what I'll do. I'm going over the code trying to plan it. 14:51:54 I originally was going to support words that have : in them, but it proved to be too difficult for me to design. 14:53:02 ( words like: : foo.bar do.something 'name' : blah ; ; ) 14:54:09 oh, and I decided to not use ; for a compile end. 14:54:24 I changed it last night to . because I don't use . 14:54:38 hmm 14:54:50 : a 1 2 . : b a 3 4 . b would push 1 2 3 4 14:55:00 COBOL nostalgy? ;) 14:55:03 * tathi hasn't really looked at Perpheon closely. 14:55:14 Prolog and Smalltalk use . 14:55:41 : and ; are too visually alike 14:56:00 ( for me that is ) 14:58:29 yeah . seems like a natural character to end things :) 15:35:30 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 15:35:31 --- mode: ChanServ set +o kc5tja 15:41:09 --- quit: I440r ("Leaving") 15:44:28 Hi kc5tja 15:48:26 imaginator - allow for anonymous dictionaries instead, and compile words to ALLOCATE'd space. 15:50:47 re imaginator 15:50:54 * kc5tja is just updating my FS/Forth wiki page. 15:53:16 anonymous dictionaries eh ... 15:53:32 My dictionary right now is a simple hash table. 15:54:29 I build an IC (instruction collection) that is basically a bunch of bytecodes stored in an array. 15:54:41 So, Perpheon_compile() takes an input string, and returns an IC. 15:54:56 Then I run the IC through Perpheon_run(). 15:55:32 Each word that isn't a core word stores an IC in the hash table. 15:56:41 So, : abc 1 2 . would store in the hash table's "abc" node WID_PUSH, 1, WID_PUSH, 2. How could I do an anonymous dictionary with this setup? 16:00:27 To further explain: Perpheon_compile() finds a ":" token and then it creates a new IC and sets it as the cur_ic (current IC). And when . is found it stores the word. So, how exactly could I do this? 16:01:14 . also restores the default_ic as the cur_ic and finally the default_ic is returned at the end of the input. 16:06:04 Here's how I was picturing my : lambda. Perpheon_compile() finds ':' and then reads a word. Instructions (operators and operands) are appended to the IC until . is found. When '.' is found it checks if "lambda" is the word name, and if so it appends to the default_ic WID_PUSH, and the address of the word for the lambda. Then when it's run the address becomes available. 16:06:49 execute would be used to run this lambda, and would pop the address off the stack to get the word and then proceed to run it. 16:08:03 cleverdra: any hints? Which Forth do you use? 16:12:41 --- join: Sonarman (~matt@adsl-64-160-166-20.dsl.snfc21.pacbell.net) joined #forth 16:15:16 --- quit: tathi ("leaving") 16:29:30 --- quit: warpzero (Read error: 110 (Connection timed out)) 16:29:41 --- join: warpzero (~warpzero@dsl.142.mt.onewest.net) joined #forth 16:35:07 --- quit: imaginator (".") 16:49:05 imaginator - when I suggested that I had in mind runtime manipulation of the dictionary stack -- probably not a very good idea, actually. 17:01:06 --- join: I440r (~mark4@12-160.lctv-a5.cablelynx.com) joined #forth 17:28:20 --- join: dubious (~marc@209.71.234.197) joined #forth 17:29:37 the URL posted by ChanServ, http://forth.bespin.org, returns a proxy error. 17:29:59 too bad, looked exciting 17:39:37 * arke is back (gone 19:40:53) 17:39:45 hiya all 17:39:53 hi sam and mark ^____^ 17:40:18 who runs that page? I440r? 17:41:35 i think thin does, but im not sure. 17:49:49 arke must give good head 17:50:48 Yes I do. 17:50:52 erm 17:50:54 wrong window. 17:56:36 hi 17:57:15 --- quit: dubious ("Leaving") 18:10:47 erm no not me 18:10:52 thats the tunes ppl 18:13:52 * arke is away: bbiab 18:18:15 forth.bespin.org is always having problems. 18:18:24 I've given up with it. 18:18:41 I am currently concentrating my efforts on my own wiki dedicated solely to FS/Forth. 18:20:11 cool 18:34:45 Schwweeet! 18:35:08 * kc5tja just came up with a slick way of handling subroutine calls in a MISC-like architecture. I think even Chuck Moore would be proud. 18:36:57 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 18:37:37 --- quit: Sonarman (Read error: 110 (Connection timed out)) 18:45:04 Herkamire: http://www.falvotech.com/cgi/fsforth/StackProcessorConcept -- let me know what you think. :) 19:07:46 --- join: Sonarman (~matt@adsl-64-169-93-163.dsl.snfc21.pacbell.net) joined #forth 19:08:44 --- join: Sonarman_ (~matt@adsl-64-169-93-163.dsl.snfc21.pacbell.net) joined #forth 19:09:03 --- quit: Sonarman (Client Quit) 19:09:15 --- quit: Sonarman_ (Client Quit) 19:09:21 --- join: Sonarman (~matt@adsl-64-169-93-163.dsl.snfc21.pacbell.net) joined #forth 19:29:22 kc5tja, started work on your forth yet? 19:30:02 slava: It's been started. 19:30:32 cool. so you think yours will be much faster than gforth? 19:30:41 I'm hoping to finally settle on an interpreter design tomorrow, and hopefully will actually code it. 19:30:55 Definitely, yes. 19:30:57 * slava picked up a copy of the java virtual machine spec. 19:31:05 i want to try compiling my language to jvm bytecode. 19:34:42 the jvm is a very crude stack machine. 19:39:59 Anyone here familiar with old transistors from around 1980? 19:43:59 madgarden: They haven't changed much since then. :) 19:44:16 slava: Yep. However, jvm really doesn't interest me all that much. 19:44:47 kc5jta: I'm sure they haven't... problem is, I have an old/weird part number, and I don't know what the modern equivalent is. 19:45:18 Wanting to replace a blown transistor in an old Coleco "Alien Attack" handheld game. 19:47:17 Well, if you find a replacement, don't let the aliens hit your handheld next time. :D 19:47:24 What part number is it? 19:47:29 kc5tja, well, i'll use your forth instead of jvm if it is better :) 19:48:25 kc5tja: C1959 19:48:37 2SC1959 19:48:56 madgarden: Try googling for 2SC1959 to see if there is an alternative part. 19:49:05 slava: I don't have a virtual machine. 19:49:14 slava: I compile direct from source to machine language code. 19:49:23 Heh. :P The problem is that I took the game to school one day, and was running it off of a power supply in the lab, and another student went to play without checking the voltage level when he turned the supply on. Poofers. 19:50:07 kc5tja, are there (good) garbage collectors for forth? 19:51:18 slava: To date, Forth systems haven't needed a garbage collector because Forth code periodically recycles memory by FORGET'ing, MARKER'ing, or otherwise EMPTY-ing the dictionary. 19:51:57 Modern ANSI Forth systems have ALLOCATE and FREE, which are used to explicitly manage heap-allocated memory where appropriate. 19:52:29 well you need a gc if you want to do lispish code with lots of cons cells and such. i like doing this :) 19:52:45 kc5tja: Cool, lots of hits for that part number. thanks. 19:53:40 slava: I don't do LISPish code in Forth. I do Forthish code in Forth. :) 19:54:04 Forth's two primary data structures are stacks and vectors. 19:54:18 (and, really, a stack is just a type of vector at the machine language level, so...) 19:58:14 * kc5tja was shocked to find out that Cray supercomputers (before relying on Intel CPUs) do not support segmentation or paging. I thought they did. But they actually have absolutely zero virtual memory support what-so-ever in hardware. 19:58:39 Cray preferred explicit, software-managed memory hierarchies. 19:58:54 * kc5tja is distinctly reminded of Forth blocks in this context. 19:59:22 so no security on a cray box? 19:59:26 Nope. 19:59:28 None. 19:59:32 i guess its not needed 19:59:43 But I nonetheless have seen Unix OSes running on Crays. 20:00:00 but i remember my m68k mac running mac os 7 -- frequent reboots due to program bugs sucked. 20:00:19 AmigaOS lacked MMU capabilities too. 20:00:36 But I rarely ever had to reboot it except for when my own software borked out. 20:01:41 And the funny thing was, the Cray supercomputers only had eight integer registers, eight address registers, and 8 vector registers. 20:07:34 whats funny about that? 20:20:22 Well, eight integer registers aren't a whole lot. :) 20:20:34 And the vector registers were the only way to do any kind of floating point on the machines. 20:21:07 Each vector register could hold 64 floating point values, though a bitmask was used to determine which elements of the vector to use. 20:23:24 Especially when the machine had something like 16 independent execution units. 20:26:00 slava - /names 20:26:08 also, bah. 20:26:24 * madgarden thinks that kc5tja's crazy robot brain has more than 8 registers. 20:27:10 The less registers you have, the more you have. In a way, this is how the 65816/6502 works; zero-page addressing mode basically gave the CPU 256 8-bit wide "registers", 128 16-bit 'registers', etc. 20:27:40 Though the Cray machines were RISC-like, in that everything you did was between registers. No CISC addressing modes or whatnot. 20:28:05 : dec>time 10 /mod 10 /mod 60 * swap 6 * + + ; : time>dec 6 /mod 10 * + ; decimal 2134 dec>time 1930 dec>time - time>dec . \ prints: 204 20:28:23 kc5tja: just had a chance to read about your chip design ideas 20:29:04 kc5tja: your flow control words cannot branch over any 64KB boundry right? 20:29:34 slava - http://www.complang.tuwien.ac.at/forth/garbage-collection.zip 20:30:01 hiya 20:30:01 Herkamire: ?? My flow control words can handle branching to any address within a 16MB code page, if used in slot 0. 64 bytes if used in slot 4. 20:30:04 * arke is back (gone 02:16:12) 20:31:12 Herkamire: Actually, be more specific; you mention words -- do you mean instructions in the Forth CPU idea, or in FS/Forth under Linux? 20:31:34 also, oops, bad definition for TIME>DEC 20:31:37 whats up everybody!? 20:32:07 kc5tja: oops. I meant instruction 20:33:00 Herkamire: I suppose I should put some more explanation on the site. Give me 45 seconds... 20:33:03 Well, 1 minute. :) 20:33:21 oh crap. that's 64MB 20:33:27 god I really do need to go to bed 20:34:13 kc5tja: how many bits are you using for your instructions? 20:34:55 you are doing word addressing for intructions right? 20:35:58 No, byte addressing. 20:36:10 Though word addressing is a possibility. I've been considering it. 20:36:24 is each instruction a byte then? 20:37:25 No. Each instruction is 6 bits in length. But they're packed 5-wide in a single 32-bit instruction word. 20:37:39 So a single memory fetch returns up to 6 instructions. 20:37:43 err 20:37:49 So a single memory fetch returns up to 5 instructions. 20:38:34 that allows up to 64 instructions. 20:38:37 One clock per memory cycle, plus one clock per instruction, yields a total of six clocks per instruction word; thus, each instruction takes 1.16 clocks to execute, average. 20:38:49 arke: Yes, although I only have 30 defined. 20:38:54 but it leaves two unused bytes! 20:39:01 arke: Two unused bits. 20:39:07 er, thats what I meant. 20:39:10 thats bad. 20:39:14 No it isn't. 20:39:19 yeah.. 20:39:25 Plenty of commercial RISC CPUs have unused bits in their instructions, including PowerPC. 20:39:30 They seem to get along just fine. 20:39:39 yeah, but this is a Forth CPU, right? 20:39:40 arke - also, GC tagging =) 20:39:49 arke: Yeah, so? 20:40:01 Hrm. 20:40:05 Just ... I don't know. 20:40:07 ^_^ 20:40:22 kc5 - perhaps arke wants to know why you don't just have a 30-bit instruction word. 20:40:28 I have a question ... would it be acceptable for a RISC instruction to claim a second instruction fetch? 20:40:33 The last two bits I can possibly use to encode a RET, #, or NOP instruction. No other combination makes sense. 20:41:13 you could do a 24-bit fetch, which allows 4 instructions in 3 bytes. 20:41:21 Erm, yeah. 20:41:31 arke: RAM sticks don't come in 24-bit widths. 20:41:45 thats true. 6-bits is an odd thing to use. 20:41:56 because they're not even.. 20:42:10 I have a question ... would it be acceptable for a RISC instruction to claim a second instruction fetch? 20:42:16 Those two unused bits are not a liability. 20:42:35 arke: I don't understand the question. 20:42:44 --- join: hovil (~hovil@CommSecureAustPtyLtd.sb1.optus.net.au) joined #forth 20:43:03 Herkamire: The refined explanation is on the site now. Does it help? 20:43:08 arke - if you had asked the question I suggested, I suggest that kc5 would've answered with a reference to the difficultly of getting RAM sticks in 30-bit widths. 20:43:13 kc5tja: like, lets say I got some random RISC CPU which has each instruction fetch as 16 bits. Could there be an instruction which claims a following 16 bits for operands? 20:43:30 cleverdra: :) 20:43:43 arke: Load Immediate would be the instruction you're looking for. 20:43:45 kc5tja: as in, would that be "acceptable" in the RISC world? 20:43:51 kc5tja: thats exactly it. 20:44:07 arke: But that requires a more complicated state machine to implement, so they don't bother. 20:44:16 arke: In practice, it's rarely needed anyway. 20:44:37 kc5tja: i got a set instruction, which sets a certain byte in a register to a literal, encoded in the instruction fetch. 20:44:55 * kc5tja nods 20:45:13 So it takes up to four clocks to load a 32-bit value? For 16-bit instruction widths, that's a reasonable tradeoff. 20:45:50 Well, actually, I kinda lied there ^__^ 20:46:13 When you think about it, for 16-bit instruction widths, that's basically how long it'd take to load a 32-bit value into a register anyway. 20:46:15 set register (6-bit, 0-63), position(3-bit, 0-7) 20:46:33 but instruction widths are actually 32 bits ^__^ 20:46:39 Hrm. 20:46:44 changed my mind, actually. 20:47:03 64 registers, 64-bits each. Nice architecture. :D 20:47:21 Yep ^__^ 20:47:22 * kc5tja is still undecided on whether to add character/byte-accessor instructions in his stack CPU design though. 20:47:38 kc5tja: not strictly necessary if you add AND 20:47:40 But in a programmable logic device, I do wonder if it would be possible to synthesize the logic in an affordable, hacker-friendly chip. 20:48:15 setm = Set with Mask 20:48:27 thats the new set word now. 20:48:57 * kc5tja nods 20:49:02 basically, it takes 3 operands. 20:49:04 Well, I'm particularly proud of my stack CPU design. 20:49:08 register to set: 6 bits 20:49:25 kc5tja: ^__^ 20:49:42 kc5tja: well, i haven't seen too much, if you get a dedicated wiki page, i'll take a look. 20:49:55 hrm. 20:49:56 wait. 20:49:59 The reason I proposed this CPU is because of http://www.falvotech.com/cgi/fsforth/ForthBoxComputer 20:50:00 changed my mind again. 20:50:22 arke: Get a dedicated Wiki page? What do you think http://www.falvotech.com/cgi/fsforth is?? 20:50:27 :) 20:51:28 i meant add a page to the wiki dedicated completely to the architecture ^__^ 20:52:29 32 bit instruction fetch. 6-bit register select + 2-bit location = 8-bit, add the actual literal, you got 24-bits. That leaves a byte to do whatever. 20:52:36 * arke doesn't like wasted bits 20:54:07 I could add a mask register, leaving me with 2 bits of instruction specifier 20:54:18 but i already have an instruction like that (rlwm) 20:54:24 that might complicate things. 20:54:34 arke: Well, the architecture doesn't exist. It can't exist, not until i actually start coding for a chip. 20:54:58 kc5tja: well, but you have plans, so submit the plans to the wiki ^__^ 20:55:12 And I won't do that until either (a) someone lends me the $250 to get an FPGA package for my computer, plus another $200 to purchase Windows XP to run it on, or (b) someone works the design up for me on their system. 20:55:19 arke: I DID!!!! 20:55:23 kc5tja: so do you think i should just have an instruction decode, or add the mask, or something else you might think of? 20:55:37 arke: I don't know. 20:55:52 kc5tja: oh, you can steal windows 2000, shouldnt it run on that too? and personally, i think 2k is better than XP anyway 20:56:13 arke: Perhaps, but perhaps not. It depends on the vender's software. 20:56:29 Hrm. 20:56:36 Well, find a decent vendor then ^__6 20:57:16 Oh, I got it! 20:57:24 arke: Xilinx, Amtel, or Cypress. Those are your choices. Don't like it? Tough. 20:57:38 er, nevermind, once agian. 20:57:40 ACK 20:57:46 this is a very hard choice :( 20:57:51 * kc5tja nods. :) 20:58:03 what would _you_ do? 20:58:08 * kc5tja thought long and hard about the XOR-masks used in CALL/JMP instructions in his stack CPU. 20:58:15 arke: What is your goal? 20:58:34 kc5tja: Well, I'm trying to make it efficient, nice, powerful, and not waste bits. 20:58:55 Nice. Now what is your actual goal? :D 20:58:59 arke: efficient for what task? 20:59:05 kc5tja: 24 bits are already given away. All I need to do now is add the instruction specifier (how many bits?), and maybe something else. 20:59:07 What are you trying to do, load a register with an immediate value? 20:59:12 TreyB: just ... efficient ^__^ 20:59:17 kc5tja: yes. 20:59:24 How big are the instructions? 20:59:29 If you have no baseline, you can't measure efficiency. 20:59:34 I got 32 bit instructions. 21:00:01 as of now, i got 16 bits literal, 2 bits location specifier, 6 bits target register. that adds up to 24 bits 21:00:08 so I have exactly 1 byte left. 21:01:56 i still need to specify that its actually a set instruction, and i wanna possibly squeeze in something else. 21:02:17 * cleverdra notices that isforth does not define <= or =< 21:03:00 I was thinking another register (6 bits) which would provide a mask in the same place as it is in the specifier to what is actually set. 21:03:06 you think I should do that? 21:03:33 No. 21:03:37 One instruction, one task. 21:03:38 (btw, register $0 = 0x0000000000000000 and $63 = 0xFFFFFFFFFFFFFFFF and they are unchangeable ^_^) 21:03:41 Sometimes you have to waste bits. 21:03:51 * kc5tja nods 21:03:59 does that mean you don't like rlwm? 21:04:36 rlwm is one instruction which completely eliminates the need for shl, shr, rotl, rotr, and and 21:04:46 I didn't say that. Looking at the dataflow through the ALU for that instruction, it follows that masking and shifting go together. 21:04:53 But setting a register's contents . . . I'm not sure. 21:05:01 (from an immediate value, I mean) 21:05:44 that behaviour would be quite complicated to understand, albeit relatively simple to implement... 21:05:53 I don't know. 21:06:00 All I know is that i'm hungry, and I'm about to head otu to get some food. 21:06:47 Ok. 21:06:55 I think I'll go without the mask, for now. 21:13:28 --- quit: arke (Read error: 104 (Connection reset by peer)) 21:15:55 kc5tja: what if you're at slot 0 and you want to NOPs? 21:16:06 kc5tja: or do you think you'd never want that? 21:17:34 kc5tja: I like the instructions for the most part, and I like how you've noted the ones that are unnessesary (just there for optomization) 21:22:54 oops, that should read "and you want _two_ NOPs" 21:22:55 --- quit: Sonarman (Read error: 104 (Connection reset by peer)) 21:25:59 --- join: arke (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 21:38:50 If I put a NOP in slot 0, there's a very, very high likelyhood that I'll also have one in slot 1. 21:39:00 I can just use DUP DROP to get the same effect. 21:39:05 I think I'm going to make a little brother version of the CPU, which is basically the same thing but 32-bit with 32 registers. 21:39:14 kc5tja: can you explain the whole slot jump xor thing? 21:39:27 Otherwise, if a whole word is $00000000 (e.g., jump to IP XOR 0, or jump to next instruction :) ), then that whole word is one big NOP. 21:39:59 kc5tja: right. that's pretty cool 21:40:05 I wonder if I could make a fully fleshed RISC CPU with only 16 instructions.. 21:40:13 kc5tja: do you ever want/need to have every other instruction be NOP? 21:40:24 Herkamire: Not personally. 21:40:41 However, it might be nice to have NOP NOP NOP + to give suitable time for the ripple-carry adder to work its magic. 21:41:05 do you use NOP for timing? or just to take up some bits to get stuff in the right allignment? 21:41:15 But if I'm coding for an FPGA or CPLD, the adder isn't going to be ripple-carry; it'll have full look-ahead carry generation, and it'll always work to one execution cycle. 21:41:17 Just for timing. 21:41:26 Well, and sometimes debugging too. 21:41:39 It is nice to use NOPs to patch existing code or something. 21:42:00 But I haven't done something like that in years and years and years. 21:42:09 So I place relatively low priority on that. 21:42:14 right 21:42:33 arke: You have to understand how the CPU fetches and executes instructions first. 21:42:50 Each instruction cell has five instructions packed into it. 21:42:53 Well, 5 instructions, 6 bits each, in 32 bits 21:42:54 one thing to consider is that 0x00000000 as a 0 branch NOP is just one NOP, where as if you have a NOP instruction, it's 5 NOPs. 21:43:18 The CPU only executes the instruction in slot 0; the rest are merely queued up so to speak. 21:43:34 After slot 0's instruction is executed, the instruction register is shifted to the left by 6 bits. 21:44:01 Herkamire: Right. 21:44:30 I think branches should use word addressing 21:44:46 and you should use the spare 2 bits as part of the branch addresses and literals 21:45:35 Maybe. 21:45:36 We'll see. 21:46:00 It's just a design concept right now. Since I don't have actual hardware to play with, nor a VHDL simulation environment, etc., all I can do is daydream. 21:46:11 :) 21:46:34 the xor thing seemed scary at first, but the more I think the more I'm warming up to it 21:46:49 arke: Therefore, when the JMP/CALL is executed, the CPU always sees it as a slot 0 instruction, even though it could have appeared in slot 4. 21:47:18 If it makes people feel scary, then it can't possibly be a bad thing. :D 21:47:30 hehe :) 21:47:56 it seems a bit trickier to compile instructions for the xor branch method 21:48:00 * arke doesn't understand. 21:48:20 arke: If you don't understand this much, then you'll never understand. 21:48:32 arke: the chip shifts the word it's executing up 6 bits after each instruction 21:48:33 Consider the case of DUP DROP CALL $DEAD. 21:48:42 Since DUP is in slot 0, it's the next instruction to execute. 21:48:57 Once it's executed, the instruction register is shifted left, six bits, so that what remains is DROP CALL $DEAD. 21:49:21 Now that DROP is in slot 0, it is executed, and the instruction register is shifted once more to the left, six bits, yeilding CALL $DEAD. 21:49:28 Now CALL is executed. 21:49:31 Problem: 21:49:45 CALL $DE is very, very different from CALL $DE0000. 21:49:55 How can we make those two refer to the same actual address? 21:50:20 why by using it backwards! 21:50:24 The answer is to re-arrange the address bits, so that the least significant address bits are closest to the CALL instruction. 21:51:01 Ok. 21:51:05 *BUT*, even here, we're limited to calling a location in lower memory, not necessarily the same page of memory. How do we leave bits of the IP register that we know won't change at compile-time, unmodified? XOR. 21:51:26 Combien the two, and you have a XOR-masked, field-reversed branching system that I propose. 21:51:26 :) 21:51:34 hrm. 21:51:45 so, er, oh, i get it. 21:51:59 the address is just a mask to the current IP, in little endian order? 21:52:07 * arke is having trouble grasping this 21:52:16 yes 21:52:46 The idea is that as the instruction register shifts, we always want the target address to always be a (a) valid address, and (b) the correct address. 21:52:55 Regardless of where in the instruction register it appears. 21:53:11 the number of bits of address included as part of the jump/call instruction, is the number of bits of the IP that it can change. 21:53:58 As it is right now, a MISC chip needs to what slot its CALL instruction or JMP instruction is in, so it can get the correct behavior. 21:54:12 This requires logic, and that logic adds up in an FPGA really fast. 21:54:16 My goal was to eliminate the logic. 21:54:46 Odd concept, but it makes sense ^_^ 21:54:48 this if you put the branch instrucion first in a word, you can have a 24 bit xor mask. so you could change the IP to anywhere in the current 16MB mem block (or 64MB if he does word addressing) 21:55:03 arke: Most things in strongly optimized hardware designs are odd concepts. 21:55:21 You're just jaded by the old way of doing things, that's all. :) 21:55:26 :) 21:56:22 you could have your spare 2 bits be the least significant bits in the branches and literals without much trouble right? 21:56:46 moderately, yes. 21:57:02 With careful instruction selection, it can serve as a sixth instruction slot. 21:57:16 * arke is away: zZzZ 21:57:18 But the instructions it could hold would be only 000000, 010000, 100000, or 110000. :) 21:57:27 right. 21:57:32 as long as one is NOP that's fine :) 21:57:39 * kc5tja nods 21:57:44 hehe :) 21:57:55 What's cool about using JMP for NOP like this is the following: 21:58:18 When all instructions are executed in the instruction word, the "next instruction" is always a JMP instruction. 21:58:37 coooooooool 21:58:42 Thus not only have I solved the slot-awareness problem, I've utterly eliminated the instruction fetch hardware too. 21:58:44 :D 21:59:04 so then your hardware doesn't have to keep track of when to fetch the next word of instructions :) :) 21:59:11 right. :) 21:59:15 awesome :) 21:59:30 ok, that settles it. branch is 000000 21:59:36 :) 21:59:43 --- quit: slava (sterling.freenode.net irc.freenode.net) 21:59:49 kc5tja: this is sooo col 21:59:59 cool that is :) 22:00:04 :) 22:00:24 --- join: slava (~slava@CPE0080ad77a020-CM.cpe.net.cable.rogers.com) joined #forth 22:01:03 I should put that up on the website, so I can be reminded of that. :D 22:01:05 hehe's an instruction you might want to add as optomization: shift left by 6 or 8 bits 22:01:26 kc5tja: yeah, and so other people can see the glory 22:01:38 Hehe :D 22:02:04 * kc5tja was thinking of having 2* 4* 16* and 256* (and their / variants) to permit "software barrel shifting," so to speak. 22:02:05 oops I still can't type. s/hehe's/here's/ 22:02:17 you could name the instruction "hehe" just to make fun of me ;) 22:02:38 :) 22:02:42 Nahh, I don't hold grudges. 22:02:43 :D 22:02:59 I did write to Chuck Moore. I wonder what he'll think of the idea. 22:03:37 if you can shift up 8 bits in one or two instructions, you can load 32 bits in two words + one instruction 22:04:47 I can do that in one instruction as it is. 22:04:52 The # instruction does that. 22:05:09 It treats the next instruction word as a literal to push onto the stack. 22:05:23 [ ... # ... ] 22:05:28 [ literal ] 22:05:32 [ ...etc... ] 22:05:48 oh. I thought # took the rest of the current word as a literal 22:05:57 nope. 22:06:18 that wouldn't work to well I suppose 22:06:57 the hardware wouldn't know how many bit's to shift the literal down 22:07:28 Well, if # appears in slot 0, it'd have 24/26 bits to play with. 22:07:38 I'd have it be a signed load at that point. 22:08:02 I really really like the idea that you could use the last 2 bits as an istruction (if it's one of the Holy 4) 22:08:10 The problem is that the instruction shifter shifts in 0s -- it doesn't know about the sign of an #'s literal, because it can't tell what is and is not an operand. :) 22:09:52 I was thinking that the literal would use the rest of the instruction, but it has the problem you discussed with the branches: the hardware doesn't know what slot the lit instruction was in, so it would have to have the least significant bits near the instruction 22:10:26 And that's fine as long as you're interested only in an unsigned value. :D 22:10:30 negative numbers might be a problem though 22:10:39 :) 22:10:47 But I deal with signed values about as much as I deal with unsigned, so, I think the way # is implemented right now is a slightly better solution. 22:10:54 It's also easier to implement in hardware, I think. 22:11:45 --- join: Serg (~z@212.34.52.140) joined #forth 22:11:52 hi ! 22:12:07 * Serg is trying to buy old military SW radio ;)) 22:12:23 :) 22:13:28 really, I don't use negative literals much. it was quite a long time before I bothered making my parser handle negative numbers on my last forth 22:14:12 for the longest time I only used -1 -2 and -4 (and only occationally) and I just made constants for those. 22:14:23 just lazy I guess... wasn't that hard 22:14:39 ok, now I'm babbling 22:14:46 time for bed! 22:14:55 kc5tja: awesome design! 22:14:57 goodnight 22:15:24 Thanks, and goodnight. 22:16:38 --- quit: Herkamire ("InstaBed! Just add self!") 22:36:08 * Serg wanna make regen/autodyne on IC for one-chip superhet 22:36:23 ;( they lack control for RF amp 22:41:13 * kc5tja thinks a discrete component regen has significant romantic appeal. :) 22:41:53 yes, it does ;)) 22:42:09 tube one w/ low plate voltage ;)) 22:43:13 the Polyakov designs what i promised is told to have 0.5mkV sensitivity w/ _one_ bipolar transistor ! 22:43:24 not counting audio amp, sure 22:57:34 : neg: bl parse over c@ '-' = if 1 /string do-normal-thing negate exit then do-normal-thing ; 23:00:58 that looks isforthish loil 23:01:16 not many forths allow 'x' for char input - they are all ghey and want [char] x these days 23:01:54 indeed, I've used isforth for the last few days. 23:02:28 isforth seems to compile fast enough to afford a little bit of conciseness with character literals =) 23:02:46 :) 23:03:13 its specifically BECAUSE its more consise that i do it that way 23:03:32 [longassedforthnametomakethenexttokenacharacterliteral] x 23:10:01 --- quit: onetom ("Lost terminal") 23:16:53 --- join: onetom (~tom@cab.bio.u-szeged.hu) joined #forth 23:35:12 I440r: That's not "Ghey." That's the Forth way. 23:36:14 There is no need to place special-case code in the definition of NUMBER (or whatever your Forth happens to call it). It may be nice to have, but no real need, when the Forth interpreter/compiler has sufficient infrastructure to take care of the situation by just defining a forward-parsing word. 23:36:29 kc5tja, no. thats the ANS forth way 23:36:42 I440r: Don't let Chuck hear you say that. 23:36:48 prior to ans it was ASCII X 23:37:03 it was never char x or [char] x 23:37:04 I440r: Yes, where ASCII is a forward-parsing word. Duhh. 23:37:05 it was ascii x 23:37:31 thers NOTHING wrong with forward parsing. not ONE thing 23:37:32 I440r: Ummm................no. 23:37:34 its a tool 23:37:44 DUDE READ WHAT THE CHRIST I"M WRITING> PLEASE!! 23:38:01 You're violently agreeing with me on 90% of what I'm writing. 23:38:09 lol 23:38:10 Violent agreement is a bad sign of miscomprehension. 23:38:50 i dont see myself disagreeing with you, you were implying that char and [char] have always been 23:38:56 There is nothing wrong with [CHAR] versus CHAR either, for that matter. The same rules apply for COMPILE and [COMPILE], again, something Chuck used in cmForth. 23:38:58 and i said no it was ascii prior to that 23:39:22 compile and [compile] are preferable to "postpone" BIG time 23:39:39 but char and [char] are overly verbose 23:39:43 'x' works better 23:39:48 And I would personally and overwhelmingly prefer CHAR and [CHAR] over ASCII anyday. 23:39:57 the only think you cant do with 'char' is ' ' 23:40:10 ik dont have any of the three defined 23:40:39 i think single quoting of a character is MUCH neater. and less verbose too 23:40:48 I define $ as a forward-parsing word in FS/Forth that treats the subsequent word as a hex literal. 23:40:58 So instead of $DEADBEEF, I would write $ DEADBEEF. 23:40:59 so you have $ xx 23:41:08 right ive seen that before 23:41:11 chipforth ? 23:41:28 isforth uses $xxxxx 23:41:33 %xxxxx 23:41:34 I decided to go this way because writing NUMBER to handle hex literals, character literals, and regular numbers, all just got so complicated. 23:41:40 and /xxxxx 23:42:05 well you can borrow my code if you ever change yer mind 23:42:11 HAH! 23:42:18 i know youy have deliberatly avoided looking at isforth 23:42:31 Son, I've written FS/Forth 1.0, which mimicked Pygmy's exact numerical conversion code back in the mid 80s. :D 23:42:31 the same way ive avoided looking at other forths 23:42:35 for th esame reason too 23:42:53 i440r - what reason? 23:42:56 I've been there, done that, got the T-shirt, and now I'm donating it to Salvation Army for someone else to use. 23:43:16 cleverdra, ive used FPC and F86 as my ONLY sources of information 23:43:29 i440r - OK, but why? 23:43:35 * kc5tja has looked at other Forths all the time for FS/Forth. 23:43:45 ive avoided all other forths simply because i dont want people saying "you stole that from me" or the like 23:43:50 cmForth, PygmyForth, and ColorForth are the three systems I'm drawing the most influence from, though. 23:43:58 i wanted isforth to be 99.99999% all mine 23:44:27 ive "copied" very kittle from FPC and F83, ive just used them as sources for "how did they do it" 23:45:31 isforth refills from within word - thats an isforthism 23:45:35 --- part: cleverdra left #forth 23:45:39 --- join: cleverdra (~julian@206.61.132.131) joined #forth 23:45:39 I believe in Moore's approach to software libraries. I wanted to know how cmForth or Pygmy did things, and once I learned how they did them, I then re-implemented them myself in my own system. 23:45:46 grr, client error. 23:45:49 my vocabulary words are isforth-isms too 23:45:55 Libraries are good things . . . as long as you treat them as libraries. 23:45:58 so is my headerless creating stuff 23:46:30 kc5 ive written alot of libraries but ive been TRYING to NOT make x dependant on y dependant on z add infinitum 23:46:33 fpc was like that 23:46:42 i440r - but surely having UNLOOP to go along with DO ... LOOP wouldn't hurt anything. 23:46:46 You're not understanding. 23:46:47 no 23:46:56 UNLOOP is a STUPID word 23:47:00 its DO and UNDO 23:47:03 also, isforth has bizarrely wrong interactions with GNU screen. Strange. 23:47:18 UNDO is a horrible word. 23:47:29 "Reverse what I just did" is not a suitable looping word. 23:47:30 cleverdra, thats because SCREEN does NOT have a terminfo file 23:47:35 I440r - OK, so you call 'UNLOOP' 'UNDO'? You should document that somewhere, since nobody will ever expect that. 23:47:37 its SCREEN thats broken not isforth 23:47:41 I440r - ah! OK. 23:47:49 it was always undo in every single forth i ever used 23:47:51 i440r - easy to fix, then. 23:47:52 it was do and undo 23:48:11 cleverdra, just export DISPLAY=Eterm 23:48:15 and you will be fine 23:48:19 Indeed. 23:48:21 isforth does not need fixing here 23:48:30 SCREEN and terminfo do 23:48:44 terminfo is seriously deficient 23:48:57 theres another word that came to mind a second ago thats just totally WRONGLY named 23:48:59 sm/rem 23:49:01 that seems insufficient. hm. 23:49:11 um/mod is unsigned mixed slash mod 23:49:27 sm/rem is SIGNED mixerd / ghey-dumgass-lets-do-soemthing-different 23:49:39 it should have been called sm/mod 23:49:42 not sm/rem 23:50:10 I440r: I'm not sure you groked what I said about libraries. I look to see what other folks have done. I then re-implement what they've doen in my own context. Or, if I have a body of text from a library, I include only those parts that I need (something not easily done in a file-based system, I might add, but is no-brainer in blocks. Just one more reason......) 23:50:57 kc5 i groked it and agreed with it 100% 23:51:12 unfortunatly im having difficulty not making pieces interdependant 23:51:15 I440r: Your response clearly didn't indicate that. :) 23:51:27 Things will always be interdependent. 23:51:29 It's a fact of life. 23:51:36 i appologise - i assure you im agreeing :) 23:51:45 i know - but im trying to minimize that 23:51:45 Anyway, I ahve to get to bed. 23:51:57 so that people who want X but dont want Y can still have X :) 23:52:01 yea -= me 2 23:52:05 * kc5tja agrees with the minimization of interdependencies. 23:52:26 E.g., FS/Forth will not have KEY defined, because I've given up trying to code character-level interactivity under Linux console. 23:52:35 If I want character-level interactivity, I'll have SDL-specific words to do that. 23:52:39 you have ? 23:52:42 err dood thats easy :) 23:52:52 It's easy, but it's complexity I don't need. 23:53:10 And I don't want to have to reset the damn terminal every time FS/Forth crashes. 23:53:19 oooh - thats not acceptable for isforth tho - cuz isforhts absolute PRIME directive is to be totally totally disassociated with ALL external libraries :) 23:53:20 (and I know it'll crash the first few times) 23:53:22 for now 23:53:43 yea - thats fscking annoying 23:53:52 If I need KEY, then I'll reference SDL and open a framebuffer to draw graphics/text into, etc. 23:53:56 but isforth doesnt seem to crash much for me lol 23:54:16 I440r: Well, I'm still developing FS/Forth, remember? :D 23:54:16 accessing frame buffer isnt trivial 23:54:26 I440r: SDL makes it trivial. 23:54:29 kct i DID say "for isforth" 23:54:30 hjeh 23:54:47 isforth will have frame buffer support eventually 23:54:48 and X too 23:54:54 And when FS/Forth runs on raw hardware in the future, it'll be just as trivial. 23:55:07 * kc5tja has no immediate plans to use the X11 libraries. 23:55:14 Though I could, I just don't have a need to. 23:55:16 Too complex. 23:55:21 ill be writing my own xlib code 23:55:22 Too complex for the payoff, I meant to say. 23:55:35 i like the challenge heh 23:55:44 My challenge is elsewhere. 23:56:01 and an x toolkit in forth would kinda PROVE forth to some non believers 23:56:03 My goals for FS/Forth are listed on http://www.falvotech.com/cgi/fsforth/SamuelFalvo -- those are my challenges. 23:56:13 :) 23:57:33 btw cleverdra you are right on one thing. isforth DOES need some documentation :/ 23:57:37 LOTS of it 23:57:44 its on the todo list lol 23:58:04 No worries, then. 23:58:13 right now i want to get a release of my 8051 forht out there - its free for non commercial use 23:58:22 but the umbilical version of it will be commercial 23:58:32 if/when i finish it 23:59:59 --- log: ended forth/04.01.07