00:00:00 --- log: started forth/03.10.15 01:53:11 --- quit: onetom (Remote closed the connection) 03:51:44 --- join: andreou (~panx@195.130.107.55) joined #forth 04:24:52 * andreou bye 04:24:53 --- quit: andreou ("ta kanonika paidia pai8ainoyn kanonika. ta diaforetika paidia pe8ainoyn eley8era. (A)") 05:26:30 --- join: augur (~hulla@200.217.158.174) joined #forth 05:26:41 --- nick: augur -> augur-off 05:57:50 --- quit: augur-off (Read error: 54 (Connection reset by peer)) 07:24:20 --- join: Urm-the-Malevole (~Urm@80.122.33.114) joined #forth 07:48:12 --- join: XeF4 (xef4@lowfidelity.org) joined #forth 08:30:09 --- quit: XeF4 ("täytyy keskittyä") 09:13:28 --- join: mur (~mur@smtp.uiah.fi) joined #forth 10:03:26 --- part: Urm-the-Malevole left #forth 10:28:19 --- join: a7r (~a7r@206.72.82.135) joined #forth 10:28:24 hey 10:48:27 --- join: thin (thin@bespin.org) joined #forth 10:49:03 --- topic: set to 'where people get together to talk about CVT, stirling engines, tesla turbines, and occasionally Forth' by thin 10:49:09 --- quit: thin (Client Quit) 11:43:35 --- quit: mur (Remote closed the connection) 11:43:36 --- quit: mmanning (Read error: 54 (Connection reset by peer)) 11:45:01 --- join: mmanning (~mmanning@saturn.vcsd.com) joined #forth 11:46:09 --- join: mur (~mur@kyberias.uiah.fi) joined #forth 12:08:50 --- quit: mmanning (Read error: 110 (Connection timed out)) 12:09:13 --- join: mmanning (~mmanning@saturn.vcsd.com) joined #forth 12:15:59 --- join: andreou (~tautology@195.130.107.55) joined #forth 12:15:59 --- quit: mmanning (Read error: 104 (Connection reset by peer)) 12:16:53 --- join: mmanning (~mmanning@saturn.vcsd.com) joined #forth 12:35:21 --- join: schihei (~schihei@pD9E5C431.dip.t-dialin.net) joined #forth 12:47:42 yoh 12:53:39 --- quit: mmanning (Read error: 110 (Connection timed out)) 12:53:47 --- join: mmanning (~mmanning@saturn.vcsd.com) joined #forth 12:59:31 --- quit: mur (Remote closed the connection) 13:06:04 --- join: mur (~mur@smtp.uiah.fi) joined #forth 13:06:36 --- quit: andreou ("-") 13:08:03 --- quit: mmanning (Read error: 60 (Operation timed out)) 13:35:18 --- join: andreou (~tautology@195.130.107.55) joined #forth 13:45:19 --- quit: andreou (Remote closed the connection) 13:55:11 --- quit: a7r (Read error: 113 (No route to host)) 14:07:32 --- quit: schihei (Client Quit) 14:34:54 --- join: aperception (~tautology@195.130.107.55) joined #forth 14:35:15 --- nick: aperception -> andreou 15:30:39 --- join: arke (~chris@ca-cmrilo-cuda1-c3b-66.vnnyca.adelphia.net) joined #forth 15:38:02 * arke is away: zZzZZzZzZzZzZ 15:38:26 * arke is back (gone 00:00:02) 15:38:40 y0 :) 16:42:39 --- quit: andreou ("-") 16:58:44 --- join: rk (~chris@ca-cmrilo-cuda1-c3b-66.vnnyca.adelphia.net) joined #forth 17:13:47 --- quit: arke (Read error: 113 (No route to host)) 17:16:45 --- nick: rk -> arke 17:20:18 --- quit: mur (Remote closed the connection) 17:21:39 hehe cool topic l0lz0r 18:02:05 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 18:02:05 --- mode: ChanServ set +o kc5tja 18:29:02 --- join: usa (~isparry@public01.syndeocorp.com) joined #forth 18:30:08 --- part: usa left #forth 18:32:32 kc5tja!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 18:32:34 :) 18:50:14 Egads! 18:50:21 We're jubilant tonight aren't we? :) 18:51:09 --- join: a7r (~a7r@206.72.82.135) joined #forth 18:51:10 hey 18:57:11 --- join: I440r_ (~nospam@12-178.lctv-a5.cablelynx.com) joined #forth 18:57:18 sup I440r 19:04:37 kc5tja: im so happy that youre here!!!!!!!!!!!!!!!!!!!!!!!!!!!!1 19:04:48 I440r: I'm so happy that YOU're here too!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1 19:04:56 SUGAR IS VERY BAD FOR ME 19:05:10 that is a lot of excalamation. 19:05:13 er excla 19:11:22 :) 19:15:26 --- quit: I440r (Read error: 110 (Connection timed out)) 19:31:06 * kc5tja grins 19:31:14 Sorry -- I'm flaming someone on a private forum. 19:32:08 heehee cool 19:32:28 whats the command for when some person was last seen on the IRC server? 19:32:30 kc5tja: yoh 19:33:09 /whowas I think 19:33:15 --- quit: I440r_ (Read error: 54 (Connection reset by peer)) 19:36:50 :) 19:36:50 ack 19:36:52 grrr 19:36:53 :) 19:37:16 the bad thing about IRC is that if someone just disappears, you wont know where they went, if they died, got arrested, whatever. 19:37:26 * kc5tja nods 19:38:31 * a7r hacks 20:26:05 .. my forth is born 20:27:12 a7r: HEY! 20:27:16 Long time no see, man! 20:34:54 :) 20:35:03 kc5tja: yeah dude. :) 20:35:20 how've you been? 20:35:28 a7r: I managed to get myself a job working at In-N-Out. :D 20:35:39 The car's tranny is really starting to act up now. 20:35:53 And I'm working to establish an electronics kit company. 20:35:58 sick. 20:36:27 I've got some prototype hardware ready for my new product, and I'm working on the software right now. 20:37:34 I'm writing a DTC/ITC Forth right now, to work on the AVR, so I can speed up development. 20:44:30 * kc5tja nods 20:44:42 * kc5tja is trying to establish a kit company. 20:44:51 what kind of kits? 20:45:01 One of the kits I intend on producing is a 6502-based single board computer equipped with FS/Forth standard. 20:45:08 werd. 20:45:11 Another kit I have planned is a headphone guitar amplifier. 20:45:50 And still another kit I have planned is a DMM (probably two models: one built around the PIC, and the other built around the 65C816 microprocessor, also running Forth) 20:45:52 hehehe 20:46:13 These are all ideas at the moment. 20:46:24 The 6502 SBC seems to be a relatively sure-fire bet because it's actually built by someone else. 20:46:31 All I have to do is provide the documentation for it. 20:48:34 elite. 20:48:35 What kits would you like to see? 20:48:56 tough call.. 20:49:25 The 6502 SBC has just a hair less than 32KB of RAM (256 bytes out of 32K are used for I/O), and 32K of EEPROM. 20:49:41 how many channels of PWM, and how many timers? 20:50:38 It has two VIA chips. No hardware PWM, but you can kinda emulate it using a VIA serial port (a true synchronous serial port with no start/stop bits to interfere with its output waveform; all you need to do is keep the shift register fed, and it'll be happy). 20:50:48 werd. 20:50:52 does it do SPI? 20:50:55 So, two VIAs makes for two PWM outputs if you're thrifty with their serial ports. 20:51:02 a7r: If you bit-bang it. 20:51:06 nod. 20:51:22 how are those 0xFF bytes used for I/O??? 20:51:30 (as in, their arragnement, etc.) 20:51:37 It has over 40 I/O lines (32 are 100% independent of each other; the remaining 8 are serial ports, control lines, etc). 20:51:49 $7F00-$7F0F = VIA 1 20:51:57 $7F10-$7F1F = VIA 2 20:52:06 $7F20-$7F2F = ACIA (UART) 20:52:17 so 20:52:21 $7F30-$7F7F = decoded, but unused -- expansion. 20:52:21 is it like a queue thing? 20:52:27 A queue thing? 20:52:41 ack, nevermind :) 20:53:01 Those are the actual memory addresses that you read/write from/to to access those hardware resources. 20:53:25 $7F80-$7FFF = unused (mirrors $7F00-$7F7F). 20:54:28 The 65816-based SBC will have a different memory layout. I/O will be divided up into 16 slots, each at their own base address. So slot 0 would be at $FFF000, slot 1 at $FFF100, etc. Each slot can have 256 bytes of I/O to itself. 20:54:37 kc5tja: does it have interrupts or such? 20:54:42 arke: Of course. 20:54:49 NMI, IRQ, and reset. 20:54:50 sweet :) 20:54:58 eck 20:55:16 i meant software-callable interrupts ... like x86 has int 0x10 or somethinh 20:55:56 nod. 20:55:59 The 6502 and 65816 CPUs have an instruction called BRK, which is used to "break" to an operating system handler of some kind. 20:56:09 cool :)_ 20:56:15 does it take a byte? or something? 20:56:25 Similar to many RISC's "SC" instruction, and quite unlike x86's INT instruction, BRK only goes to one vector. That's really all you need. 20:56:26 6502 .. lemme look up a tutorial or such on that real quick 20:56:38 arke: That requires some explanation. 20:56:42 BRK technically takes two bytes. 20:56:56 But older documentation documents it as only one byte long. 20:57:33 The idea is that BRK was originally used to set break-points in software debuggers. And since over 90% of all 6502 opcodes are 2-bytes long, it was determined that the PC that BRK pushes onto the stack would be PC+2, to make the software developer's job easier. 20:58:01 Now-a-days, BRK is used to invoke system services (especially on the 65816, which can support an external MMU capable of memory protection and multitasking!). 20:58:10 eh? 20:58:19 So modern documentation for both the 6502 and all documents for the 65816 document BRK as a two-byte instruction. 20:58:39 The opcode $00, followed by an arbitrary byte of your choosing, whose meaning depends on the operating system. 20:59:14 Forgive me, but I don't see how what I wrote can be confusing. 20:59:40 PC+2?? 20:59:47 Think. 20:59:59 When BRK executes, it's a software interrupt. 21:00:06 The program counter must be saved on the CPU's stack. 21:02:26 oh 21:02:26 aah 21:02:26 ok :) 21:02:26 duuh 21:02:26 They decided to store PC+2 (where PC is the program counter contents when BRK is executed -- eg, the address of the BRK) because most 6502 instructions are two-bytes long. 21:02:26 So, when setting a breakpoint, the instruction address on the stack would point to the next instruction to be executed with about 90% reliability. 21:02:26 In reality, that "feature" was never used. 21:02:26 And indeed, it's a bit of a waste on the 6502. 21:03:04 But it's very useful on the 65816, because the 65816 pulls an external signal, "Vector Pull" or just VP, low to let any external MMU hardware know that, "Hey, I'm going to be executing an IRQ, NMI, or BRK handler here. Turn off your protections!!" 21:03:45 This is why BRK is documented as being a two-byte opcode now -- the emphasis has moved away from debuggers, and into the realm of multitasking, memory protected, potentially even multi-CPU environments. 21:03:49 cool :) 21:04:04 Yeah. This "bug" turned into a very nice "feature" after all. :) 21:04:15 i downloaded the source for a 6502 emi 21:04:17 emu* 21:04:26 Which emulator? 21:04:33 --- join: TreyB (~trey@cpe-66-87-192-27.tx.sprintbbd.net) joined #forth 21:05:56 Anyway, the 6502 is the "RISC" of 8-bit microprocessors -- it has a single cycle memory cycle (e.g., one memory cycle takes precisely one clock cycle), and executes almost every instruction you throw at it in N cycles, where N is the number of bytes it takes up in memory. Exception is single-byte instructions, which takes 2 cycles (basically single-byte instructions introduce a bubble in its internal pipeline). 21:06:06 dunno what its called 21:06:12 its just called 6502 emulator :) 21:06:26 arke: Can you provide a URL? 21:06:36 http://www.classicgaming.com/EPR/ 21:06:38 * kc5tja really wants to see a 65816 emulator... 21:06:51 i think there might be one of those there too 21:07:02 nope, theres not 21:07:07 but theres docs on them :) 21:08:22 Yeah. Everywhere you go, there's docs, but no emulator. 21:08:33 wanna help me learn 6502? :) 21:08:33 Be that as it may, the 6502 and 65816 are not tough processors to write emulators for. 21:08:37 They're dreadfully simple. 21:08:38 I see one for MacOS X. 21:09:04 if i become familiar with them, i might write one :) 21:09:05 TreyB: Well, I have an Apple IIgs emulator here, which I used to play Spy vs Spy on. :) 21:09:16 * arke wants a mac 21:09:30 arke: Though I'd love to, all I can do is answer your questions. I can't be pro-active in your research, because I've got too much on my plate as it is already. 21:09:50 Doesn't the IIgs use the 65816? 21:09:56 I wasted tonight as it is -- I have tons of homework due, and I didn't even start it yet. :( 21:10:00 TreyB: Yes, it does. 21:10:25 But the emulator I have has CPU emulation code tightly integrated with everything else that it emulates (it's cycle-accurate for all the hardware in the IIgs, not just the CPU). 21:10:45 * kc5tja thinks it'd be easier for me to just start over from scratch or something. 21:12:47 :) 21:13:37 hrm 21:13:49 this emulator is just something you can put into your code 21:14:15 What language is it written in? 21:14:17 C? 21:14:21 yep 21:14:52 damn.. 21:15:02 NEXT on this chip is only going to be 3 instructions with DTC. 21:16:10 6 clock cycles total. 21:16:19 inline it!!! 21:16:21 * a7r inlines it for shits and giggles. 21:16:22 :) 21:16:29 lol 21:16:39 hrm ... this is quite crappy C code 21:17:08 instead of using preinitialized jump tables, you have to call a function to init it 21:18:08 Hey, nothing particularly wrong with that. :) 21:18:15 yes, there is. 21:18:17 Cuts the size of the compiled executable down. 21:18:31 Grr. 21:18:35 :) 21:18:39 its ugly C code as well. 21:18:45 well, not ugly 21:18:46 i mean 21:18:48 t 21:18:50 Well, that I can imagine. An emulator is optimized for speed. 21:19:00 At any cost. 21:19:08 it could be made much more efficient, both memory and speed-wise 21:19:31 I think I'll write a 6502 emulator in Forth. 21:19:59 i was just thinking that :) 21:20:12 I'm pretty much going to need one anyway, to emulate the SBC. 21:20:26 did i mention it keeps separate arrays for address modes and clockcycles? 21:20:33 STOOPID!!!! 21:20:34 STOOPID!!!! 21:20:34 STOOPID!!!! 21:20:35 STOOPID!!!! 21:20:36 :) 21:20:46 * arke loves making fun of other peoples C code 21:21:00 I can't pass judgement based on that. I have to understand why they use separate arrays first. 21:21:39 Well, number one, they could have used a friggin struct 21:21:49 Though, I do have to inquire as to why they have those arrays at all -- why don't they just have a single look-up table, mapping all 256 opcodes to executable routines? 21:21:58 arke: whoa whoa whoa. 21:22:00 Stop right there. 21:22:09 ..? 21:22:13 I use multiple parallel arrays in some of my speed-critical programs myself. 21:22:24 Why? Because it's hhhhhhhhhhhhhhhhhhhhhhhhhhhhella faster for the CPU to work with. 21:22:44 When optimizing for speed, you must not only consider the software size, or instruction execution times, but you MUST also consider cache utilization too. 21:22:50 you know whats even faster than that? :) 21:22:55 Structs are "convenient," but almost universally, arrays are WAY faster. 21:23:03 true 21:23:17 but you know whats even faster than several separate multiple arrays? 21:23:26 one sequential array :) 21:23:28 but anyway 21:23:36 Ummm...sorry...but no. :) 21:23:44 yep 21:23:46 i did the test 21:23:53 P200MMX, running linux 2.4.19 21:23:58 gcc something 21:24:00 My name look-up implementation for FS/Forth uses split arrays, and it's way faster (by a factor of 3). 21:24:03 i did the test 21:24:24 GCC doesn't know SHIT about tight code optimization. 21:24:37 didnt matter in that case. 21:24:39 It gets its speed by loop unrolling, not data structure design. 21:25:00 it used ONE array for several things, and data1 went into the first part of the array, data2 into the second part 21:25:09 it was faster :) 21:25:18 You're not explaining it in a way that makes sense. 21:25:19 Start over. 21:25:22 OK 21:25:31 Because to me, the above just screams multiple parallel arrays. 21:25:42 lets say, you have two related data items. 21:25:54 they all relate to one number 21:26:00 so, two arrays, right? 21:26:01 nope. 21:26:22 lets say theres 10 items of each 21:26:28 Well of course. 21:26:38 you declare array[20]; 21:26:54 you put the first data items 1-10 to array[0-9] 21:27:06 and second data 1-10 to array[10-19] 21:27:11 Sorry, but that is two separate arrays. 21:27:19 They just so HAPPEN to have the same label in C. 21:27:23 But in reality, they're two separate arrays. 21:27:30 hrm 21:27:31 wekk 21:27:32 well 21:27:33 true 21:27:33 But I can do one better than that... 21:27:35 :) 21:27:40 probably 21:27:59 If you have TWO items that are related by the same number, it's MUCH better to place your data so that you have array[n] and arrayp[n+1] be related. 21:28:06 It makse for MUCH better cache utilization. 21:28:16 (and for that matter, here's where a struct comes in handy) 21:28:22 But consider MY case: 21:28:29 I'm doing dictionary searches in FS/Forth. 21:28:59 99.99% of the time, when looking up a word, the length and first three characters of the word I'm looking for won't match most of the like entries in the vocabulary. 21:29:19 Now, I could use a linked list, but that'd thrash the data cache badly. 21:29:31 So I keep an array of word names and their CFAs. 21:29:39 The beginning engineer might go something like this: 21:29:57 struct vocabentry { char name[19]; void *cfa; }; 21:30:05 vocabentry vocabarray[100]; 21:30:51 But this also will cause the cache to thrash badly when looking for a name, because the most significant part of the name I'm looking for is spaced some 20 bytes apart from each other. Not only is important data density low, it's on non-trivial cache alignments! 21:30:55 So I do this: 21:31:03 uint32 length[100]; 21:31:22 struct vocabentry { char name[12]; void *cfa; }; 21:31:30 vocabentry name[100]; 21:31:48 The idea is that each element of the length array contains the length of the word I'm looking for plus the first three characters. 21:32:17 This lets me find (DAMN fast, I might add) the index into the name[] array so that I can verify a potential match, and if found, read its CFA. 21:32:36 I can top that :) 21:32:42 The thing is, a single cache line can hold 16 elements of the length[] array, but can only hold *4* elements of the name[] array. 21:32:44 No you can't. 21:32:48 :) 21:32:58 yes, i can. 21:33:02 That is *the* fastest solution on AMD Athlon and Intel Pentium III processors. 21:33:17 what about older ones? :) 21:33:24 Who cares about older ones? 21:33:25 on older ones, i can think of a better one. 21:33:28 I do. 21:33:30 :) 21:33:35 OK, what's your solution? 21:34:20 long get_index(char *); 21:34:26 Stop 21:34:36 End. 21:34:37 :) 21:34:45 thats hint enough :) 21:35:04 I need to see data structures. Just saying "let there exist some function get_index()" won't work, because more likely than not, THAT is the most time-consuming operation. 21:35:20 It is. 21:35:49 So what data structure are you looking to use? 21:36:45 typedef struct { char * name; void * location } entry; 21:37:03 MAJOR cache thrash already. 21:37:06 entry dict[DICT_SIZE]; 21:37:26 I know where you're going with this. 21:37:35 Yep. 21:37:39 I'm sure you do :) 21:37:52 And I believe its the way to go on older procs 21:37:52 The idea is to atomize the Forth name, and then look up the name by comparing string addresses instead of whole strings. 21:38:11 ack 21:38:12 Problem is, you have to look up previous instances of the word's name (e.g., do string comparisons anyway). 21:38:28 damn it 21:38:32 I'm not convinced this is a faster solution. 21:38:34 this harvard architecture shit is really chapping my ass. 21:39:04 a7r: :) Yep, I don't like it very much either. Especially in the PIC processors. :/ 21:39:16 kc5tja: theres very efficient ways of compressing x bytes into 32 bits 21:39:26 I can't run code from SRAM, and I can only do indirect loads using 2 registers, and I need those 2 registers for my word execution. 21:39:46 so the bottom line is I need colon definitions to be in RAM. 21:39:51 arke: If you can find one that maintains 16 character precision in the process, I'm all ears. 21:39:53 or I need to do a bunch of tapdancing. 21:40:13 kc5tja: i'd have to find it, but i have a good one somewhere 21:41:00 kc5tja: basically, it turns out a unique token into that thing, mods it, entry, if its there, redefine and.or read it, if not, make it and/or create error 21:41:10 arke: Because every approach I've seen ultimately either: (a) depends on base n>=36, which doesn't maintain 16 character precision, (b) huffman encoding/shannon encoding, same problem, or (c) relies on string comparisons in a name history table, that records every name ever used. 21:41:36 base n >=36 ????????????? 21:41:49 Jeeezz, dude!! That's way overkill, and guaranteed to be slower than my approach. Absolutely guaranteed. 21:41:54 I'll lay money on it. 21:42:19 on faster procs, where theres all kinds of crazy cache stuff :P 21:42:19 arke: Type this in GForth: "36 base ! foo . bar . decimal" 21:42:32 arke: No, on virtually everything. 21:42:47 You're talking about a highly adaptive hashing algorithm completely with feedback loops. 21:42:52 That's computationally expensive. 21:43:03 And hashing also loses character precision. 21:43:10 AND runs the risk of collissions to boot. 21:43:29 In short, it's not pretty. :) 21:43:51 * arke looks to find his nice little encoding algo 21:43:52 * kc5tja notes that the 6502/65816 don't have/need caches, so a simple linked list solution is more than adequate for those processors. 21:44:09 Usually one ends up doing a reasonable hash to get "close" and then compares actual strings for collisions. 21:44:28 Either way you look at it, it's going to be slower than my approach. 21:44:37 For the sizes of the data set that I'm working with at least. 21:45:16 * TreyB loves the atomization approach. He used it in a PDF viewer to great effect. 21:45:31 Maybe if you had millions of entries to look up, hashing will undoubtedly be faster (but then, a B-tree or similar data structure would be faster still) 21:45:32 AAAAAAAAAAAAAARRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH 21:45:46 FUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCK 21:45:50 FUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCK 21:45:54 Uh, ok. 21:46:29 OK, I don't know what to make of that. 21:46:37 i am gonna KILL thunderbird 21:46:48 i didnt tell it to DELETE IT FROM THE SERVER!!! 21:46:49 Use mutt. 21:46:50 I don't know if I just pissed arke right the hell off, or if I did something else wrong. 21:46:54 i didnt even tell it to delete it THERE 21:47:00 kc5tja: not your fault 21:47:05 The tbird Email client nuked his messages. 21:47:09 i think i might have lost my encryption thing 21:47:35 --- topic: set to 'where people get together to talk about CVT, stirling engines, tesla turbines, data structure and algorithm design, and occasionally Forth' by kc5tja 21:47:46 * kc5tja somehow found it appropriate. :) 21:47:55 FUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUC 21:47:58 KFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUC 21:48:04 You can stop that now. 21:48:04 KFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUC 21:48:08 Really. 21:48:09 KFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCKFUCK 21:48:13 im sorry 21:48:16 but 21:48:17 GAH!!! 21:48:19 i am soo pissed off 21:48:21 grrr 21:48:24 * arke deletes tbird 21:48:31 fscking --- p.---o---s-----grrr 21:48:35 *sigh* 21:48:56 I've used mutt for years. I don't anticipate switching any time soon. 21:49:01 kc5tja: well, the way it worked is by using some prime number that factored itself in or such 21:49:03 damn it. 21:49:07 Forth on this chip is getting lamer and lamer. 21:49:29 Readers of the log for this channel will be mildly amused at the sheer volume of explatives given in just the span of a few minutes. :) 21:49:38 lol 21:49:40 really 21:49:43 i am pissed off 21:50:46 * arke cries 21:51:06 its GONE 21:51:07 arggh 21:51:18 In the end, it boils down to operator error. Take responsibility now and do what you can to fix it. 21:51:19 And I take it, not just that message, but everything... 21:51:29 nope 21:51:37 several messages 21:51:42 apparently random ones] 21:51:44 grrrr 21:51:47 Do you control the server? 21:51:54 Yahoo 21:52:00 Hmmm. 21:52:25 Customer Service? 21:52:42 Pfft! Yahoo isn't called Yahoo for nothing. :) 21:52:45 bah. they wouldnt be able to restore it by now. 21:52:51 They're a bunch of Yahoo's over there. 21:52:58 Local caches? 21:53:21 this probably happened a few days ago 21:53:47 So much for that idea. 21:54:19 *sigh* 21:54:42 kc5tja: the method I had gave at least 12 char precision 21:54:59 the method i HAD 21:55:05 Was this the hashing algorithm? 21:55:22 no, it was a way of making 32-ints out of chars 21:55:39 well, hashing, yes 21:55:41 TreyB: The problem with atomizing names is that once internalized, you can't un-internalize them without effectively rebooting, or periodically garbage collecting. 21:56:23 TreyB: GC is expensive, as you need to walk the whole dictionary to see which names are referenced and which ones are able to be freed. 21:57:05 well 21:57:27 I've thought a lot about that. My solution in the Forth realm revolves around the notion of always using an umbilical system where you can afford the CPU. 21:57:31 TreyB: It may work for PDFs, but I'm not convinced it'd be useful for scanning a Forth dictionary quickly. 21:57:33 the method took the char values, and did something with them using a prime, then factored it out, ... it was really weird 21:58:18 arke: Right. Heavy discrete math stuff -- definitely a form of hashing. :) 21:58:19 kc5tja: in practice, how often do you have dictionaries with tens of thousands of entries where this becomes a problem? 21:58:33 kc5tja: well, it was more weird than heavy 21:58:59 TreyB: You typically won't; but the dictionary size and atom buffer size are not related. :) 21:59:31 Although........ 21:59:41 kc5tja: It very much depends on the lifetime of the atomized objects. 21:59:44 Internalization might be the approach to take with the 6502 because of its limited memory space. 22:00:15 And when searching for a word, if the word you're looking to compare does not exist in the atom buffer, then it's guaranteed not to exist in the dictionary either. 22:00:23 kc5tja: whats the maximum size of hash index you would find feasible? 22:00:36 kc5tja: exactly. 22:00:43 arke: My dictionary currently supports 1024 Forth words, and 512 compiler words. 22:01:03 kc5tja: er 22:01:05 i meant 22:01:05 Each word can support any length name, but only 16 characters are significant for comparison purposes. 22:01:13 16 chars ... 22:01:24 * arke thinks 22:01:33 does it HAVE to be 16 chars? not 12 maybe?" 22:01:49 arke: I find 12 too limiting for my programming style. 22:02:20 Well, let me rephrase that. 22:03:11 I find 12 too limiting when considering my desire to interface FS/Forth for Linux to external libraries written in C, many of which have names like ZSetFontPathForPrinting or some such. 22:03:28 I'm all for long, self-descriptive names. But I had to draw the line for efficiency sake in FS/Forth. 22:03:37 tr00 22:03:38 I found 16 characters a nice compromise. 22:04:32 For the 6502 version of FS/Forth, I'm thinking of dropping that to only 7 characters plus one length byte. Most of my Forth words will definitely be unique within that range. 22:05:03 In fact, most of my Forth words are 5 or fewer characters. Which is why atomization looks attractive to me in the 6502 version. 22:05:39 The only time I lose economy is when the word I'm looking for is only one character long. 22:05:55 At two characters, I break even, and starting at 3 characters, I gain economy. 22:06:00 Sub-string matches would work too. 22:06:48 Well, actually, I lose for 1 and 2 characters, break even for 3, and gain economy at 4 or more -- I forgot to include the length byte in the word's header. :) 22:06:51 Even at one character, you have to store the length somewhere. 22:06:57 * kc5tja nods 22:06:58 Ok :-) 22:07:29 struct WordHeader { uint8 length; uint16 name; WordHeader *previousWord; }; 22:07:48 So, 5 bytes per header, plus any internalized word name in the buffer. 22:08:24 If you 0-terminate atom entries, you can reuse the tails of existing names. 22:08:57 I wasn't going to 0-terminate anything; I believe firmly in the (c-addr u) form of strings in Forth. 22:09:04 I find they're more flexible. 22:09:21 Plus, that can allow head- or tail-matching. 22:10:35 I've always used the memory address for the token, which prevented head-matching. 22:20:28 Well, I'll cross that bridge when I get there. :) 22:20:33 In the mean time, I think I'm going to get to bed. 22:20:38 G'night. 22:20:42 * kc5tja is pissed with himself for not doing homework tonight. >:( 22:20:45 * kc5tja sighs 22:20:49 * TreyB hits the hay, too. 22:20:57 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 22:24:48 --- quit: arke (Read error: 110 (Connection timed out)) 23:59:59 --- log: ended forth/03.10.15