00:00:00 --- log: started forth/02.07.30 00:10:55 --- quit: proteusguy (Connection timed out) 00:23:17 --- join: Soap- (~flop@202.0.42.22) joined #forth 00:23:18 --- quit: Soap` (Read error: 104 (Connection reset by peer)) 01:52:29 --- join: proteusguy (~irc@24-197-147-197.charterga.net) joined #forth 01:54:03 --- quit: Robert (Read error: 113 (No route to host)) 02:08:01 --- join: Robert (~Robert@robost86.tsps1.freenet6.net) joined #forth 03:10:15 --- quit: proteusguy (Read error: 110 (Connection timed out)) 03:22:12 --- join: Soap` (~flop@202.0.42.22) joined #forth 03:22:13 --- quit: Soap- (Read error: 104 (Connection reset by peer)) 04:52:35 --- join: proteusguy (~irc@24-197-147-197.charterga.net) joined #forth 05:06:53 --- join: dsmith (~dsmith@cherry7.comerica.com) joined #forth 06:10:37 --- quit: proteusguy (Read error: 110 (Connection timed out)) 06:32:28 --- join: Stepan (~stepan@Charybdis.suse.de) joined #forth 06:32:48 hi :-) 06:39:28 is there something like C's "continue" in Forth? 06:39:51 (skipping the current loop cycle in a begin..while..repeat construct 07:17:55 --- join: proteusguy (~irc@209.134.176.22) joined #forth 07:24:16 --- join: cleverdra (jfondren@0-1pool37-238.nas2.florence1.sc.us.da.qwest.net) joined #forth 08:19:15 --- join: tathi (~josh@wsip68-15-54-54.ri.ri.cox.net) joined #forth 08:21:43 --- quit: Stepan ("Do you think it is air you are breathing? Hmm?") 09:14:40 --- join: kc5tja (~kc5tja@ip68-8-206-226.sd.sd.cox.net) joined #forth 09:26:41 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 09:28:16 --- join: futhin (~thin@h24-64-175-61.cg.shawcable.net) joined #forth 09:28:48 good morning all.. 09:46:13 morning 09:53:21 --- quit: cleverdra ("Leaving") 09:55:42 howdy tathi 09:56:07 what's new ? 09:56:30 how's your colorforth doing? 09:56:49 have you or herkamire coded a text editor yet? 10:07:23 Q: What is the colorforth supposed to highlight for you? Is it context sensitive to the stack or something? I've heard of it but don't know how its supposed to work. 10:09:20 no it doesn't highlight 10:09:28 you do the coloring 10:09:36 like for example 10:09:45 : helloworld ." hello world ; 10:10:05 the : doesn't exist anymore, what you do is you give HELLOWORD a color 10:10:15 like red or something, i forget the specific color 10:10:23 and then you give the rest of the code yellow 10:10:41 the colorforth editor imbeds a tag in the code 10:10:59 the red tag says "this is the name of the word" 10:11:04 and the yellow tag says "this is the code" 10:11:13 and the white tag says "this is a comment, ignore this" 10:11:39 I give it a color or forth does? 10:12:10 you select the color tag while you are coding.. 10:12:20 like you turn on RED 10:12:22 and then type 10:12:24 HELLOWORLD 10:12:29 and then you turn on yellow 10:12:36 and then type ." HELLO WORLD!" ; 10:13:05 ok - this just sounds like extra work. How will it help me later? 10:13:21 it's not really extra work 10:13:23 you type less 10:13:27 or the same 10:13:27 futhin: nope, still no editor :) I got sidetracked again, this time by rewriting the engine in forth 10:13:36 instead of typing : you hit f3 for RED 10:14:12 proteusguy: a whole bunch of really cool optimizations and tricks have appeared from the different direction chuck moore is going in. for example, you can have multiple ";" in one word 10:14:22 now I'm coding with function keys? 10:14:44 the function keys select the mode the text you type next is going to be in 10:14:55 yeah, I don't like function keys 10:15:08 it could easily be ctrl keys 10:15:13 ctrl-r ctrl-y etc 10:15:15 I'm mostly using keys that make sense in forth, actually 10:15:32 ':' makes the next word red 10:15:33 personally i would convert the color into italics, bold, underlined, etc.. 10:15:37 i don't care for color 10:15:48 you could do whatever 10:15:54 the color's not the point 10:15:58 exactly 10:16:17 the point is to visually distinguish the syntax so that part of your brain can deal with it 10:16:21 I'd be curious to know what kind of optimizations you get from this. It seems like you're just pre-lexing the code for forth. 10:16:41 yeah the editor does a lot more work in colorforth i think 10:16:51 that's pretty much all you're doing 10:17:43 hmm... ok - too bad. I was hoping that Chuck had "done it again"... :-) 10:17:47 only real speed advantage is for compiling -- you just have to do one 32-bit compare to check if a dictionary entry matches the word you're looking for 10:17:52 rather than comparing two strings 10:18:09 which also simplifies the implementation a bit 10:18:11 proteusguy: yes, he has "done it again" 10:18:19 he has taken forth to a WHOLE new level! 10:18:22 how's that? 10:18:30 I don't see it. 10:18:33 i dunno, go read stuff on ultratechnology :P 10:18:47 colorforth is a lot different 10:18:50 Nah, I think Chuck's main motivation for colorForth is his visual problems 10:18:51 a lot simpler 10:18:52 and stuff 10:18:55 s/visual/vision/ 10:19:05 sure, but it's also simpler :P 10:19:10 futhin - nothing you've told me is at all compelling. 10:19:13 sorry 10:19:22 protuesguy: that's cause i don't know a whole lot at all 10:19:27 heh, it's pretty controversial 10:19:27 about colorforth 10:19:46 proteusguy: seriously, read some of the colorforth articles on ultratechnology.com 10:19:51 oh ok. well I hope someone will clue me in. "I wanna believe" :-) 10:19:56 they'll explain it better than me 10:20:02 I did - they didn't give me much. 10:20:35 I'm still of two minds about it 10:20:56 On the one hand, I like pushing all the text handling off into the editor, so the compile/interpret engine doesn't need to deal with text 10:21:16 tathi: you know better than me the advantages of color forth.. what are the advantages? (besides color :P) 10:21:33 and I really like the two dictionaries idea -- I never liked POSTPONE or COMPILE, or IMMEDIATE 10:21:38 they always seemed a bit kludgy 10:22:38 what's the two dictionaries? 10:23:07 immediate was always very important for my use (late 80s). Didn't have full compiler so everything was in interpreter. 10:23:09 tathi: and it's a lot simpler isn't it.. with more tricks and shit, like multiple ; and such 10:23:17 and I like being able to scan through code and have the start of definitions stick out like a sore thumb, but you could do that with either VIM or Emacs, so that's not a big deal 10:23:51 futhin: multiple entry points doesn't work well on PPC, so I left it out, I do like having just ; instead of ; and EXIT or whatever 10:24:05 yeah - it sounds like it comes down to programmer editor taste which is always a religious issue. 10:24:24 proteusguy: he has a regular dictionary (which I've been referring to as the "forth" dictionary), and a "macro" dictionary 10:24:44 the words "forth" and "macro" determine which dictionary you're compiling into 10:25:27 then (to use his colors), if you type a word in yellow, it searches the forth dictionary. If it finds the word, it executes it, otherwise you get a word not found error or something 10:26:04 if you type a word in green, it first searches the macro dictionary. If it finds one, it _executes_ the macro. If not, then it searches the forth dictionary, and _compiles_ a call to the word if found. 10:26:26 and if you do the word in cyan, it searches only the macro dictionary, and compiles a call to the word 10:27:43 so if you want an "immediate" word, you compile it into the macro dictionary 10:27:47 ok - that's interesting I gus... 10:28:15 and if you want to compile an immediate word, you just put it in cyan instead of green 10:28:22 ok 10:28:50 I'm finding it works rather nicely, though I haven't done a hell of a lot of programming with it yet 10:29:34 thanx for the info - I'll have to think about it... 10:29:43 One other interesting addition he's made (this is from his forth chip designs) is an 'a' register 10:29:47 address register 10:30:12 tathi: _what_ part of colorforth is controversial ?? 10:30:18 it can't be the color part 10:30:21 you can fetch and store from it, and there's a @+ which fetches and then increments 10:30:48 futhin: I don't know, it's just fairly different, and some people just think it's weird and don't like it 10:30:52 as far as I can tell 10:31:20 I'm having fun with it, but I can't say I'd recommend that everyone switch over to it 10:31:51 the name length restrictions are a total pain in the ass, and I don't see any way around that without making the interpret/compile loop way more complicated 10:32:49 name length restriction? 10:33:24 I haven't looked over the source to colorforth all that carefully, so I could be misinterpreting this, but I don't think so 10:33:33 each word goes into 32 bits 10:33:52 the top 4 (or sometimes 5?) are the color, the lower 28 are the huffman-encoded name 10:34:16 if you overflow that, the editor will put it into an extension word and show it to you 10:34:29 but the dictionary only gets the first 28 bits 10:34:49 so your names have to differ within the first 4-7 characters 10:35:15 turns out to work fairly well with standard forth-y names 10:35:36 some of the ppc asssembly language mnemonics don't fit into a word 10:35:42 and they have suffixes 10:35:45 so that doesn't work well 10:38:21 ohhhh yeah, that is lame 10:38:44 i remember reading starting forth and it was talking about how some dictionaries only saved the first 4 characters or something like that 10:39:01 and the length of the name 10:39:10 but that's stupid.. 10:39:15 7 characters is okay i suppose 10:39:16 but not 4 10:39:57 yeah 10:40:24 that's my biggest objection -- otherwise I'm really liking it 10:40:43 though I've made a few changes; my colorforth isn't compatible with Chuck's 10:41:18 and I can't think of any way around it without making the compile/interpret loop much more complicated 10:41:51 throw out the huffman encoding stuff out the window 10:42:20 yeah, I thought maybe you could do an MD5 encode or something on the names instead 10:42:26 but I don't really know much about that kind of stuff 10:43:11 I don't want to just throw it out, because that's one of the nice things, you can compare two names in one operation, rather than having to do string compares all over the place 10:43:30 naw, i wouldn't encode the names or something :P 10:43:58 string compares in one operation? hmmm 10:44:13 yeah, you kind of need to be able to get the original name back out ;) 10:44:39 dictionary search is about 8 lines of PPC assembly language, it's great 10:44:43 you use string compares to get the name out? 10:45:00 no, that was in response to your "naw, I wouldn't encode the names or something" 10:45:06 yeah 10:45:54 --- join: CrowKiller (Vapo_Rulez@24.212.5.233) joined #forth 10:46:59 howdy crowkiller 10:47:05 we were just talking about colorforth 10:47:14 > 10:47:15 >Michael 10:47:15 > 10:47:15 >----- Original Message ----- 10:47:15 >From: "Michael Isaacs" 10:47:17 >To: "Josh Grams" 10:47:19 >Sent: Tuesday, July 30, 2002 12:04 PM 10:47:22 >Subject: R2STracking Points 10:47:25 > 10:47:27 > 10:47:30 >> Josh, 10:47:32 >> Take a look at the points statement for Montegari,Donald ssn:050709405. 10:47:35 >> He has a negative balance and I can't figure out what happened. 10:47:37 >> 10:47:40 >> Thanks, 10:47:42 >> Michael 10:47:45 >> 10:47:47 >> 10:47:50 > 10:47:53 > 10:47:55 dammit 10:47:58 clear 10:48:00 grrrrrrr 10:48:03 I really really hate this mouse 10:48:12 ouch, accidental paste? 10:48:47 maybe I just need a window border that's bigger than one pixel :P 10:48:57 nahhh :P 10:50:34 ok, let's try that again 10:50:37 http://tathi.homeip.net:5000/svn/fpos/trunk/fpos/fpos.s 10:51:07 the dictionary search routine is pretty much right at the top 10:51:32 so do you have a 1 button mouse? 10:53:28 yes 10:53:40 one of Apple's really stupid round iMac mice 10:54:24 I have one of there newer optical mice, but Herk took it home so he could play Unreal Tournament or something with two mice 10:54:33 and I keep forgetting to bring it back 10:54:47 sorry, was afk ordering internet acces for next year 10:55:33 its powerpc assembly? arrg i will have to learn that 10:55:42 heh :) 10:56:04 takes a little getting used to, I think the operand order is different than the normal x86 order 10:56:18 i have made a x86 compiler à la Jeff Fox aha 387 bytes long 10:56:40 wow 10:56:42 that's small 10:56:42 also the endianness is different 10:57:01 little endian make handling byte word and dword values easier 10:57:23 I don't remember that being a problem when I switched 10:57:29 i only need an editor and the system is complete 10:57:38 can I see it? 10:57:45 yes its commented in english 10:58:43 I send you the listing 10:59:25 sorry, had to go look up help for how to accept that 10:59:36 I've never really bothered figuring out how to use this IRC client :) 10:59:55 no problem 11:00:21 no, I got it 11:00:30 kk 11:00:44 if its unreadable i can send you the .asm 11:01:14 no, looks ok 11:03:21 I haven't really looked at aha at all 11:03:37 ok ill explain it really fast 11:03:50 the token array is made of 8 bits token 11:04:25 up to 4 bits are used as token infoirmation and the 4 least significants bits are used as count argument 11:04:49 so if i have a comment token, it starts with 1111 and can skip up to 16 chars in the source code 11:05:06 cool 11:05:12 each new word is defined like a redword in colorforth 11:05:28 i have a defining token with the length of the defining word, the computer skip this string also 11:05:54 ok 11:06:32 the user word start with 0 and is followed by a 7 bits count that indicates a previously defined word (by the defining token) 11:07:01 so i can have 128 "bookmarks" or entry points into the compiled code; colorforth works this way 11:07:08 after i have function class token 11:07:43 I can call each of the CompileXXXXXX function, like CompileDup, CompileDrop, etc 11:07:48 using a single byte 11:08:05 about 3 to 8:1 compression 11:08:14 right 11:08:29 anyway i love this system lol 11:08:40 its easy to adapt, only need to change the table after the Index mark 11:09:02 to have a compiler tuned for speed vs size, or size vs speed, or a cross compiler 11:09:36 i only need an editor to parse text into tokens managable by this compiler 11:10:28 yeah :) 11:13:00 I want my programs to be under the 512 bytes cluster size, so the editor with scancodes to ASCII is a harder challenge 11:14:17 scancode set 2 is really a mess, scancode set 3 is way better but many keyboard dont implement it 100%, from what I've read on the net 11:14:24 what's this "C18 without B register" comment about? Did Chuck add another register to his chip? 11:15:28 the c18 on his website is from july 2001 11:15:34 a paper is somewhere on the net 11:15:37 dated november 2001 11:15:46 ill give you the link 11:16:08 http://dec.bournemouth.ac.uk/forth/euro/ef01/moore01a.pdf 11:16:22 he uses a b register for fetch in slower memory or something like that 11:16:37 very "Chuckish" 11:16:39 ;pp 11:18:17 hmm 11:20:58 i think after all that his B register is used as another A register, much like EDI and ESI on x86 architecure for string operations 11:21:12 makes sense 11:21:32 seems like there would be a lot of times that you'd want two addresses for something 11:23:04 on powerpc would it be easy to implement a scheme like that? 11:23:28 --- quit: dsmith ("later..") 11:25:00 if there's one thing you're not short on in PPC, it's registers :) 11:26:17 it's a kind of RISC-like architecture, 32 general-purpose integer registers, 32 floating-point registers 11:26:24 --- join: kc5tja (~kc5tja@user-24-214-86-42.knology.net) joined #forth 11:26:32 hi 11:26:58 i will learn PowerPC as soon as there's homemade dev possible on the gamcube 11:27:05 most of the stuff in my colorforth is in registers, just because they're there 11:27:06 GameCube 11:27:31 yeah, I was wondering if anyone had ported linux to that yet 11:27:56 hey kc5tja 11:27:57 at Assembly 2002 theres a contest for console dev, including the GC, I hope someone will do something using it 11:28:34 kc5tja: you were doing a machine forth layer on which fs/forth was going to be written but now you've discarded that ? 11:28:37 would be great, there's a lot of embedded memory on that system,s chip 11:29:20 what chip? 11:29:33 (I really don't keep up with console stuff...) 11:30:36 the powerpc into the GC 11:30:44 the Gekko as they call it 11:31:08 Yes, I did. 11:33:10 I felt I didn't have enough control over the machine. Besides, writing a full assembler isn't that hard, just somewhat tedious. I'm just walking through the IA-32 Software Reference Manual, and adding x86 instruction forms to the assembler in alphabetical order. I recently completed the conditional jumps. :) 11:34:01 Although it has a lot of special forms, it also has a lot of symmetry too. Many of the instructions I can add by just writing a single line of Forth code. 11:35:30 um, when you had the machineforth thingie as part of fs/forth did that mean it could run on a forthchip without any trouble ? 11:35:43 No. 11:36:04 It was built to expose x86's architecture, not to hide it. 11:37:08 because a machien forth layer on top of x86 would slow down fs/forth too much? 11:37:12 But, it got too complex for its britches. It got to the point where I was adding a new MF primitive for each x86 feature I wanted to use. 11:37:28 So, I ditched it and decided to open up the whole chip -- I'm writing an assembler for it. :) 11:37:45 what made you decide to do the MF thing in the first place? 11:37:52 what was the advantagE? 11:37:55 Just to try it, to see how it worked. 11:37:58 ah 11:38:23 It looked like it would be easier than just using the assembler -- less code to write and all that. 11:38:29 It turns out that it wasn't the case. 11:38:46 I deliberately stayed away from Chuck's MF implementation, too; I don't like being a copycat. 11:39:42 heh 11:40:10 I'm building my instruction set on top of his c18 most recent instruction set now, ill try to suit it to my taste 11:40:50 I'm also going to implement multitasking in my Forth environment as well. 11:41:38 Cooperative in the DOS and Linux versions, and preemptive on raw hardware. 11:41:45 * futhin is going to try to get back into the basics with forth.. figure out the smallest core of forth primitives, and then go from there expanding into new vocabularies... 11:41:53 * kc5tja nods 11:41:59 the vocabularies should be encapsulated too 11:41:59 Well, that's where I was bitten, actually. 11:42:06 like "graphics" "text handling" etc 11:42:34 I needed to implement .S, and that required I implement ., and that meant I needed U/MOD. And every time I dug down a layer, I had to introduce no less than two new MF primitives to support them. 11:42:56 I started with MUF and it was simple, and there was only 50 primitives or whatever.. and then i go into FPC and i'm overwhelmed by 6000 forth words :P 11:43:00 Already having some 80 primitives, I couldn't take it anymore -- maintanence of the code was becoming very complicated. 11:43:22 futhin: A word isn't necessarily a primitive, even in FPC. 11:43:27 i know 11:43:46 but there's a ton of forth words/primitives with ansi forth and stuff 11:43:51 and there's a lot of words that i don't know 11:44:12 * kc5tja nods 11:44:15 i need a more controlled approach to forth 11:44:20 ANSI's "primitives" are overkill. 11:44:34 Really, the best way to learn Forth is to try and write one yourself. 11:44:51 Even if it's a crude hack, written in BASIC, it's still the best way. 11:45:00 I can only agree with that 11:45:15 its very challenging and entertaining at the same time 11:45:31 i'm thinking of creating a better forth introduction that introduces newcomers to the basic primitives, and then they can learn new vocabularies as needed.. instead of being overwhelmed .. 11:46:12 dont only think, try ;o) 11:46:14 (my thoughts are tied into the forth os and different levels of abstraction of forth, and breaking down forth into simple learnable components) 11:46:15 heh 11:46:33 That's how I started to learn Forth actually. I looked at it, and said, "Oh, this is EASY!" I wrote only two (utterly useless) Forths for DOS in the past, based loosely on Pygmy. Those Forths are, fortunately, long since dead. Now, the third version, FS/Forth 1.3, will be written and it'll actually be useful enough to allow me to retire Pygmy Forth. :) 11:48:06 im now rewriting my compiler so taht each register dont change roles; the code size can only decrease 11:48:12 * futhin is going afk 11:51:35 If you want something done your way, do it yourself. If you want something done right, do it twice. :) 11:52:09 arrrg i cant do that 11:52:18 i use the lodsd instruction for drop 11:52:22 and it uses the esi register 11:52:26 duh 11:52:43 i wanted to use ebx for the data stack pointer 11:52:53 and ebp as trash register 11:53:31 aaa ill post my system once its finished and ill optimize it further afterwards 11:55:30 Actually, third time is a charm, almost unilaterally. This is my third Forth, and unlike my previous two attempts, it's working out quite nice. 11:56:24 CrowKiller: If you are basing your code on Chuck's examples, note that he already uses the CPU registers for a single purpose. 11:56:48 Sometimes there are exceptions; ECX is sometimes used for multiplication as well as a loop counter -- this is because it's hardwired for that purpose in the CPU itself. 11:56:55 i want to use x86's string registers for string operations 11:57:07 Oh, I see. I forgot about those. 11:59:18 i like lodsd and all that stuff into the compiler, its a little slower but a lot less smaller 12:00:51 on the AMD processors each cisc instruction is decomposed into RISC instructions, so i think on recent AMDs the speed should be the same 12:02:50 AMD is the only company I know of that optimizes those string instructions. 12:03:02 They're quite fast on Athlons. 12:04:33 great, I'll try to buy a AMD powered laptop then next year ;ppppp 12:15:47 BRB -- rebooting. 12:19:45 back 12:20:24 That's another reason why I want to implement Forth on my box and especially my laptop -- I do not want to have to reboot after every couple weeks because it gets slow or bogged down. 12:20:51 "That's just not cricket, baby, yeah..." as Austin Powers would say. 12:23:32 i have to see the new AP movie 12:31:47 Hmm... My laptop's harddrive is 237MB in size. I figure a 10MB FAT partition to put the Forth kernel on so that GRUB can load it, and 227MB remaining for Forth's use. Sound good? :) 12:32:43 That's over 220,000 blocks that'll be available to me. 12:33:06 Of which, over 4000 will be cached in RAM. 12:33:40 as chuck said, 1.44mb is enough to old a lifetime of good written code 12:33:57 Sure, but I also need data storage. 12:34:04 * kc5tja wants to play MP3s and view pictures too. 12:34:33 Even edit pictures, and that takes a *LOT* of memory, even though the code to do it is small. 12:34:44 I won't even begin to get into circuit simulation. 12:34:52 yes, lot of ram 12:34:53 And PC Board layout. 12:35:17 But I want it to be persistent too. So the 227MB partition will give my Forth environment, basically, 227MB of virtual memory. 12:36:50 i really hope MRAM will live its expectations 12:37:04 no more need for harddrives ;p 12:37:11 I have no hope for MRAM. 12:37:38 I read the article; it's still very much research, and you'll *never* compete with harddrive's storage densities. 12:38:08 If IBM can fit 1GB onto a 2cm diameter, single-platter harddrive that fits in a PCMCIA card (I've seen it), there's no way an MRAM chip will compete. 12:38:15 Even DRAMs have a hard time with that. 12:39:09 MRAMs will fill a niche, but it won't be offline storage. It'll probably be for storing configuration settings, replacing the battery-backed CMOS RAM in most PCs today. 12:39:38 Or it'll replace the compact flash storage devices, giving them higher density and larger number of write cycles. 12:39:43 But it won't replace the harddrive. 12:40:32 harddrives for storage can't be beat, they hope by getting individual bits isolated on the platter at a nanoscale level to get between 30 and 40 gb per square centimeter 12:41:00 and that technology of isolating individual bits can theorically be expanded to 150gb per square centimeter 12:41:37 the article is inthe same magazine I talked about the other time, MIT technology review< 12:43:28 but in the couple of hundred MB range, mram will find its way im sure, especially on small systems becuase of its power consumption 12:49:35 --- nick: CrowKiller -> CrowKillerAFK 13:00:42 --- join: dsmith (firewall-u@cherry7.comerica.com) joined #forth 13:45:43 --- nick: CrowKillerAFK -> CrowKiller 13:49:57 --- join: Kitanin (~clark@209.91.66.234) joined #forth 13:59:15 --- nick: kc5tja -> kc-meeting 14:00:49 :q 14:00:54 heh 14:01:08 my fingers are still in VIM mode 14:01:12 iHello :) 14:01:39 well, I'm done working for the day, later all 14:01:44 --- quit: tathi ("leaving") 14:01:44 Bye. 14:11:44 --- quit: proteusguy () 14:24:32 --- nick: kc-meeting -> kc5tja 14:25:15 Back 15:00:18 Man, of all the Intel opcodes to implement in an assembler, MOV is arguably the hardest!! 15:00:31 It should be broken down into 6 sub-instructions. 15:05:50 Hmm... I would imagine there is an executable (probably called kpsk) that you just type in a console window under X. 15:05:56 * kc5tja personally doesn't know much about it. 15:06:29 ?? 15:06:50 Whoops. Wrong channel. Thanks. 15:06:58 That was supposed to go to a person in #hamradio 15:08:07 ha ok ok 15:14:37 --- quit: dsmith (Remote closed the connection) 15:25:44 --- join: I440r (~foo@1Cust149.tnt2.bloomington.in.da.uu.net) joined #forth 15:26:14 --- quit: I440r (Client Quit) 15:26:25 --- join: I440r (~foo@1Cust149.tnt2.bloomington.in.da.uu.net) joined #forth 15:28:36 hi 15:29:29 hi 15:29:48 still not done the next release, been way too busy 15:29:52 with PAID work heh 15:30:18 where do you work? 15:30:54 AT HOME!! :P 15:31:12 for now 15:31:28 im reverse engineering some 8051 roms that the post office lost the source code for heh 15:31:31 duh! 15:31:46 duh? :~~~~( 15:31:47 heh 15:31:51 I440r: I have a question for you. Does x86's MOV sreg,reg instruction form reverse the meaning of the reg and r/m fields in the modr/m byte? 15:32:11 * futhin gonna take a nappy or something 15:32:21 err ive no idea 15:32:25 why ? 15:32:36 kc5tja: appendix B of intel second pdf file 15:32:53 Because according to the IA-32 instruction manual, it says the reg field of a modr/m byte is used to hold the sreg field. 15:32:58 "Instruction formats and encodings" 15:33:15 Yet, when I assemble an instruction and disassemble it, the operands come out BACKWARDS in the disassembler. 15:33:35 disassemble the same instructions assembled by nasm 15:33:39 The funny thing is, NOWHERE in the IA-32 manual does it specify the proper ordering, except that "reg" is considered the right way of doing it. 15:33:40 do they STILl come out backwards ? 15:34:49 Yes. 15:35:08 But how in the world did they learn of this? And why is this not documented anywhere? 15:35:15 it still comes out backwards? - then the bug is in the disassembler, not the assembler 15:35:24 1000 1100 : 11 sreg3 reg thats the encoding for segment register to register 15:35:53 CrowKiller: That's what I thought, but it doesn't appear to behave that way. 15:35:56 proof! proof that intel used an unholy synthesis of alien dna and vanilla coca cola to create their chips! 15:36:04 hang on ill look in the a386 opcode doc 15:36:06 and what's scary is they didn't have vanilla coca cola in those days 15:36:10 time travel! 15:36:54 the sreg3 field use 3 bits to encode in order es, cs, ss, ds, fs and gs, the other two being reserved 15:36:54 I'm using DEBUG.COM to disassemble the code. 15:37:07 CrowKiller: I have the IA-32 manual sitting right in front of me. 15:37:49 CrowKiller: But the field orderings for the reg and r/m fields of the modr/m byte appear to be backwards, but *ONLY* with respect to MOV r16,sreg or MOV sreg,r16 instruction forms. 15:38:14 It's not just DEBUG.COM either -- Pygmy's assembler also generates the fields in backwards order. 15:39:17 a86 shows 8c /r for move rw,segreg 15:39:18 and 15:39:29 8e /r for mov sreg,rw 15:39:40 Then it *IS* backwards. 15:39:55 My reference says that the sreg field is the reg field, not the r/m field. 15:39:57 lol 15:40:15 (And this is coming right from Intel too) 15:40:27 why dont you write to intel and ask them about it ? 15:40:34 "why are you lying.... AGAIN!!!" 15:40:39 heh 15:41:32 Oh, wait a minute.... 15:43:38 No, it has to be the reg field, because otherwise instructions like MOV [BX+SI],DS wouldn't be valid. 15:45:27 now i seriously doubt i can include all of my editor functionality into 512 bytes, it will be quite hard 15:53:45 OK, the meaning of the "D" bit in the opcode is reversed. When 0 normally, reg is the destination. When 0 with a segment register instruction, r/m is destination. 15:53:46 back 16:20:37 --- quit: Kitanin ("PHP: At least the books are good for propping up your feet while you code in a REAL language...") 16:21:14 lol 16:21:32 Hmm... I'm going to have to rework the ModR/M handling of this assembler now... It is decidedly overly simplistic for what the hardware actually expects. 16:22:04 better than over complecated :) 16:22:08 one is easier to fix :) 16:22:23 But is it easy to fix though? That's the question that cannot be answered. 16:22:51 Actually, I think I have an idea. 16:22:58 * I440r ducks 16:23:05 Any addressing mode always appears in the r/m portion of the modr/m byte. 16:23:13 cops just went by at 60 mph past my house heh 16:23:16 Thus, it can just overwrite that field whenever it's encountered. 16:23:44 i.e assume one thing then adjust as needed 16:23:56 Registers, however, can appear in any of the two fields. Thus, when encountering a register, we basically execute reg @ r/m ! reg ! with the new value. 16:24:18 Shoot, that won't work either. 16:24:52 I have to keep flags indicating what fields have been loaded and which haven't. 16:25:04 Which sucks because of those instructions that use the reg field as an extension to the opcode. 16:25:37 Then there are forms like ax es mov,, where ax fills reg first, then es (since es MUST appear in the reg field). 16:50:20 I think i'll try something really weird with my editor 16:51:00 each "beahvior" or small program will not be simply executed staticly 16:51:13 it will be recompiled on the lfy each time the user need it 16:51:15 lol 16:51:24 it struck me like a thunderstorm 16:51:44 each behavior can be made of source compilable in realtime 16:53:32 each keypress' code will be compiled and run in realtime! I have to try that 16:54:19 that will make editing source files very slow heh 16:56:25 my compiler is almost the fastest I can think of 16:56:45 it will surely work on 200mhz systems and up 16:58:11 jeff fox aha's can compile millions of forth words per second 16:58:20 on f21 16:58:30 so on x86 i think it should be near that 17:08:02 so my compiler's structure is: | main infinite loop | function table | 128*4 bytes dictionary structure | compiled code array growing towards positive infinity (positive end of memory ;o)| 17:09:05 cool 17:09:08 so can isforth heh 17:09:22 Yes, and isforth isn't nearly as weird as Aha's system. :) 17:09:56 CrowKiller: re: each keypress executing code at run-time, that's how my text editor more or less works. 17:10:23 me is compiling code and then running it in real time so a change in source directly and immediately affect the system 17:10:41 its not, nut i'm working on it 17:10:42 lol 17:10:50 but* 17:14:49 kc5 you said something POSATIVE about isforth!!!!!!!!! 17:14:53 musta been an axident heh 17:15:14 I'm not completely negative about isForth. 17:15:32 Just because it's not the Forth I'd use doesn't mean it's "bad". 17:15:51 :) 17:22:22 * CrowKiller has just realized he hasn't tried any Forth system in his whole life 17:23:02 eep! 17:23:55 i've come across a lot of text files and even vieo presentations on ultratechnology about it, i printed a lot of stuff but I must say i'm a total newbie programming a computer 17:24:52 i never programmed anything on a pc in my whole life, aside from a bootloader and some cracks in two windows programs 17:24:59 One learns by doing. That's why I'm undertaking a retrofitting of my assembler as I write this. I learned that the old architecture wasn't general purpose enough for x86's weirded out instruction set, so I'm reimplementing the modr/m code. Hopefully it will fix a number of weird, quirky code generation bugs. 17:25:40 It's substantially more general purpose than it was before, too, so the overall architecture is much simpler. 17:30:31 i'll try to learn also about Forth-Linda, or parallel forth in general 17:32:03 it looks fascinating, from what i've read the application dont have to know about how many processors there's in the network 17:32:47 Well, that's all well and good, but neither does beowulf or mosix code. 17:32:51 and i've came across an article in Linux Journal talking about the "one floppy needed per node" beowulf 2 17:33:06 this stuff looks really fascinating 17:33:50 Ya, my linux group just got about 100 free 486/low end pentiums and we wanna build a cluster of some sort. 17:34:16 beowulf 2, look really easier to implement than the previous generation 17:35:03 one floppy needed by station, the kernel is then dowloaded at each bootup by the nodes from the master 17:35:43 wnats the next letter in the sequence 17:35:49 nvbdiz 17:36:39 r 17:36:45 nope :) 17:36:54 i was trying my luck 17:38:04 hehe 17:41:20 --- join: TheBlueWizard (TheBlueWiz@ip-216-25-202-177.vienna.va.fcc.net) joined #forth 17:41:25 hiya all 17:43:40 hi 17:43:52 hiya CrowKiller 17:44:12 re TheBlueWizard 17:44:50 I440r: hiya....well, I wonder what is your thought on my question about writing an x86 assembler in IsForth....a dumb idea? 17:44:55 hiya kc5tja :) 17:45:07 oh 17:45:17 any assembler for isforth HAS to be coded 100% in forth 17:45:17 thebluewizard, i finished my aha-like forth compiler for pentiums, 387 bytes. 17:45:22 cant use any assembler itself 17:45:32 no chicken/egg problem that way 17:46:45 So far my assembler is written completely in Forth too. 17:46:57 * TheBlueWizard nods 17:47:34 of course IsForth has to be expressive enough that an x86 assembler doesn't have to use some assembly code directly 17:47:50 CrowKiller: cool! 17:48:16 brb 17:50:21 * kc5tja is writing his assembler in Pygmy Forth to start with. So far it's going quite well. 17:50:48 * kc5tja is retrofitting it though, as the modr/m handling hasn't been too flexible. It broke when I tried to implement mov sreg,r16 and mov r16,sreg instruction forms. 17:53:18 well thas doggie one taken out - now for doggie 2 :P 17:53:18 brb 17:55:23 I was discussing the x86 assembly stuff with I440r....he doesn't want a Forth-ish style assembly syntax; just want a more traditional syntax...I am thinking maybe making the first word of each line executable word (of course those words have to reside in a separate vocabulary) with the pattern matching of sorts.... 17:57:36 Actually, it's not strictly necessary to do that. 17:58:10 You can still get by with a "mostly" Intel syntax for it by pushing tokens onto the data stack during the assembly. 17:58:38 But I don't like doing that. I really prefer a reverse polish notation syntax, because it really does simplify the assembler. 17:59:23 hmm? how so? I'm thinking of things like MOV EAX,5 and MOV [EBX+0x400+silly_offset],CL.... 18:00:10 Because I don't have to do forward parsing. 18:00:19 The same examples above would be simply this: 18:00:19 I agree with you that RPN syntax does simplify the writing of an x86 assembler, and does exploit the power of Forth very well.... 18:00:46 5 eax mov, and $0400 silly_offset + [ebx] cl mov, 18:03:04 * TheBlueWizard nods, and knows all about RPN assembly syntax...in fact has done some 6502 and x86 programming in Forth (RPN style, of course) 18:03:37 I had played with Pygmy Forth, with assembly programming there...been a long while since then :) 18:04:08 My assembler syntax looks similar to Pygmy's, but it's implementation is worlds different. 18:04:32 For starters, it shouldn't be too difficult to get it to support 32-bit code. 18:04:38 --- quit: CrowKiller (Read error: 104 (Connection reset by peer)) 18:05:09 And I440r will be pleased to note that I do distinguish between AL, AX, and EAX -- register names also carry implicit operand sizes with them. :) 18:05:33 cool! 18:05:51 I also provide manual 8bit: and 16bit: prefixes to allow the programmer precise control. 18:06:09 This is especially important as my assembler, unlike Pygmy's, defaults to 16-bit operations when it's left unspecified. 18:06:33 it is a pain to have to "shout" to the opcode words that it is a byte, a word, whatever operation every time I code that 18:06:40 So given the following instruction: $DEAD #: $BEEF [bx+si] mov,, ... 18:07:00 ... Pygmy produces MOV BYTE PTR [BX+SI+0BEEFh], 0DEADh 18:07:07 while my assembler produces: 18:07:18 MOV WORD PTR [BX+SI+0BEEFh], 0DEADh 18:08:15 I see 18:08:18 This is probably what the programmer would expect, especially considering he's working inside a Forth environment where the "cell" is the natural wordsize, and not the byte. 18:08:40 If you really want to move a byte, do this: 18:08:53 $DEAD #: $BEEF [bx+si] 8bit: mov, 18:09:00 (note the addition of 8bit:) 18:09:09 * TheBlueWizard nods 18:09:16 makes sense 18:09:33 And, frankly, you generally shouldn't be using a MOV like that anyway; it's actually faster to waste a register, and it turns out to be more convenient for the programmer in typing too: 18:09:47 $DEAD #: eax mov, eax $BEEF [bx+si] mov, 18:24:26 --- quit: I440r ("brb") 18:28:52 gotta go...bye all 18:29:14 --- part: TheBlueWizard left #forth 19:18:11 so much hype about the DEAD BEEF 19:42:52 Cool. I spent, quite literally, all day implementing mov, in my assembler, and now it finally works. 19:43:44 I'm also very much happy with the new modr/m byte processing mechanism. I'm still not yet sure how well it'll deal with SIB bytes yet, but I'll cross that bridge when I get there. 19:43:55 At any rate, I need to get going. I have to visit a friend. 19:44:02 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 20:35:27 --- join: kp2 (kp2@salm-m2-36.wvi.com) joined #forth 20:37:49 hi kp2 20:39:06 hey 20:39:14 I'm writing a native forth processor 20:40:21 cool 20:40:53 native as in written in asm? or native as in... (i forget the other native definition..) 20:42:04 native as in the processor has a call stack, two data stacks and a return stack 20:46:02 processor 20:46:23 you are coding a forth processor? 20:46:28 it will support all forth primitives, such as + * - swap dup rot 20:46:30 or designing a real processor? :P 20:46:37 a real processor 20:46:39 as in hardware 20:46:49 hmm 20:47:00 what is the processor for? 20:47:33 robots 20:47:34 and won't it cost a lot of money to manufacture your processor? 20:48:19 or you are using some programmable chip ? 20:52:00 using a Xilinx FPGA 20:52:05 oh 20:54:21 it's all good fun 20:54:32 yup :) 20:54:38 probably good experience! 20:55:24 i think i may do something similar 20:55:35 boil down forth into the absolute basics 20:55:46 and implement it in asm or concept or whatever 20:55:47 yeah 20:55:51 It's pretty easy to do 20:55:57 i really need to do something like that, it would give me a firmer grasp of forth 20:56:07 yes, it should be easy :) 20:56:21 forth is a good language 20:56:29 :) 20:56:43 it's appeal to me is that it's not just a language :) 20:56:54 er.. it's not just a _programming_ language 20:57:47 it can be a VHDL (virtual hardware definition language) and it can be a design language, design your program and then fill in the blanks 20:58:21 kp2: how long have you known about forth? 20:58:28 about four years 21:00:39 cool 21:01:08 yeah... I like it 21:07:41 --- quit: Soap` () 21:25:05 --- join: Soap` (~flop@202-0-42-22.cable.paradise.net.nz) joined #forth 21:25:08 --- join: Soap- (~flop@202.0.42.22) joined #forth 21:35:30 --- join: MrReach (~mrreach@209.181.43.190) joined #forth 21:36:48 --- quit: Soap- () 21:41:12 --- part: MrReach left #forth 22:28:35 --- quit: futhin ("sleep") 22:29:19 --- quit: kp2 (Read error: 113 (No route to host)) 23:25:27 --- join: kc5tja (~kc5tja@ip68-8-206-226.sd.sd.cox.net) joined #forth 23:59:59 --- log: ended forth/02.07.30