00:00:00 --- log: started forth/05.08.28 00:26:24 --- join: virsys (n=virsys@or-65-40-182-104.dyn.sprint-hsd.net) joined #forth 00:28:08 --- quit: virsys (Client Quit) 00:29:39 --- join: virsys (n=virsys@or-65-40-182-104.dyn.sprint-hsd.net) joined #forth 01:22:55 virl, while i have many guns. none are built and none are under my pillow, wanna test that by breaking in someday :) 01:22:55 --- quit: LOOP-HOG (Read error: 104 (Connection reset by peer)) 01:30:24 --- quit: amca ("d34d") 02:18:12 --- quit: ianp (Read error: 110 (Connection timed out)) 02:19:44 --- join: binaryguy (n=binarygu@host86-131-187-90.range86-131.btcentralplus.com) joined #forth 02:23:42 --- quit: YoyoFreeBSD_ (Read error: 110 (Connection timed out)) 02:30:58 --- join: ianp (n=ian@inpuj.com) joined #forth 02:41:14 --- quit: binaryguy ("Leaving") 02:53:53 Raystm2, no I don't want to test that. 03:37:05 hehe, I got all my guns as gifts, i've never bought a single one, and I always disassemble them and spread the parts around or otherwise disable them. :) I hate them. 03:37:33 kids and guns, cars, alcohol, drugs dont mix 04:18:28 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 04:21:17 --- join: crc (i=crc@pool-70-110-194-247.phil.east.verizon.net) joined #forth 04:25:11 --- mode: ChanServ set +o crc 04:41:55 guns as gifts? how crazy is the USA? 06:06:49 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 06:06:49 --- mode: ChanServ set +o JasonWoof 06:08:41 --- join: snowrichard (n=richard@adsl-69-155-177-155.dsl.lgvwtx.swbell.net) joined #forth 06:12:36 --- quit: snowrichard (Remote closed the connection) 06:17:31 --- quit: warpzero ("Lost terminal") 06:17:48 --- join: warpzero (n=warpzero@wza.us) joined #forth 06:20:46 --- quit: warpzero (Client Quit) 06:21:23 --- join: warpzero (n=warpzero@wza.us) joined #forth 06:48:16 --- join: PoppaVic (n=pete@0-1pool66-178.nas22.chicago4.il.us.da.qwest.net) joined #forth 06:48:36 Mornin' 06:49:57 Hi 06:50:40 How's by you? 06:51:09 I'm pretty good. 06:51:36 got yer email - reviewing now 06:52:22 yah, I got a C version mostly written. 06:53:23 Personally, I love bitfields ;-) 06:53:54 :) 06:56:11 So far, I either agree with the info, or it's a step beyond me on the first reading... 06:57:52 ok,yer using 6-bit opcodes... Are the other 2 bits "reserved" for something? 06:58:14 no, we squeeze in an extra opcode if it fits in 2 bits 06:58:33 umm... That seems weird 06:58:36 otherwise...opcode 0 means "fetch next instruction word" 06:58:52 I'd use zero as NOP 06:58:54 --- quit: ayrnieu (Read error: 110 (Connection timed out)) 06:58:56 yeah, well, it's how chuck does it, and it simplifies the "emulator" a bit 06:59:50 hmm, is there a reason for NOT using a byte/char of 0...255? Are you folding in regs,r/w? 07:00:13 sorry? 07:01:20 well, you note a uint32 (I agree, it could be more flexible - maybe) & a byte/char opcode - but only 6 bits. 07:01:54 or.. are you suggesting 6 bits OF opcode and 26 bits of "other info"? 07:02:32 Oh. Knew I should have put in a diagram. 07:02:48 oh, wait. hmm. 07:03:02 we're packing 5+ 6-bit opcodes into the 32-bit word. 07:03:34 (5, plus a 6th if it's DUP, CALL, or LIT) 07:04:24 And yeah, for portability it would make much more sense to just use a byte for each opcode. 07:04:54 Am I making sense here? 07:05:32 just a sec - had to visit the other side of the basement ;-) 07:05:38 ok 07:06:12 OK, so the current mess is the prototype and you are reassessing 07:07:02 well, I think we'll use it as-is for herkforth 07:07:06 as we'd discussed herein a month or so ago, yeah - I'd use the byte and as an index into the opcode-array 07:08:23 What happens if you have more than one LIT in a single 32-bit word? 07:08:23 I'd even consider if it was possible/sensible to codify a few bits as marking "subgroup of type"- which COULD matter. 07:08:51 Quartus: basically we have the current word in a variable, and IP points to the next word. 07:08:52 you mean folded? 07:09:01 right, I would as well 07:09:08 LIT just fetches from IP and pushes that value, then increments IP. 07:09:18 tathi: ah. 07:09:47 Quartus: you can put 6 lit opcodes in one instruction word if you like 07:09:55 lit values follow in succeeding words 07:10:01 So you've got a maximum of 64 opcodes? 07:10:09 Yeah, and I am 100% sure nowadays that the vm and support should be the synthetic-cpu 07:10:23 Quartus: at the mo he does 07:10:53 If I'm speaking out of ignorance, let me know -- but if you used a byte per opcode, you'd have four times the instruction space. If you didn't use it, user-defined words could. 07:11:08 yeppers 07:11:23 true 07:11:39 but it's more fun this way :P 07:11:50 I always liked the 8-bit and array-idea, it's akin to func-vec/deferred-words. 07:12:14 weird how everybody pushes for 8-bit opcodes 07:12:24 64 is more than enough opcodes 07:12:24 Strikes me that it'd be faster, too. 07:12:28 particularly if there is a closed-call to use for set/reset of those vectors 07:12:43 Quartus: I don't think it is, actually. 07:12:47 JasonWoof, 8-bit opcodes are more human-readable, too. 07:12:47 JasonWoof: I heard that about 64K and 640K ;-) 07:12:53 we could easily lose 1/4 of the opcodes we have now 07:12:58 Quartus: this is the same number of instructions (on PPC at least) 07:13:33 and...presumably with the opcodes being 25% smaller, you don't have to fetch from memory as often 07:13:39 (though that may never be an issue) 07:13:49 there are serious advantages to a smaller system: 07:13:52 well, 6 is an odd number - 8 is easy. Unless, (of course), there can be a good reason to use those 2-bits as someother marker(s) 07:13:53 1) easier to implement 07:14:03 2) easier to write an optomized compiler (jit sort of thing) for 07:14:16 3) simple simple simple 07:14:54 for instance - and this is off the wall - you might use bit #6 to mark 'registerID' 07:15:05 registerID meaning...? 07:15:08 JasonWoof: simple is nice. 07:15:34 I'm very curious as to what ratio I'll get with herkforth between memory used for opcodes, and memory used for lits 07:15:40 tathi oh, I was thinking of opcode-byte and the #6 bit meaning "the opcode is a register ID" 07:16:10 what's a register id? 07:16:24 tathi: this would then allow for a 100% synthetic-assembler, overlaid on a host-reality. 07:17:06 JasonWoof: oh, like BP and eas and whatever on 86's and the weird ppc regs 07:17:21 PoppaVic: huh? 07:17:29 PoppaVic: I don't know x86 asm 07:17:40 JasonWoof: it's an odd idea I've been baking in the hindbrain 07:18:18 hmm.. I'd have to see the opcode-list you guys use now. 07:19:04 http://josh.qualdan.com:3/svn/fovium/opcodes 07:19:06 not sure I follow, but... 07:19:18 JasonWoof: lemme' try it this way... ppc uses similar id-letters, and different numbers to "name regs", right? 07:19:34 I'd rather write a compiler back-end, rather than somehow integrate processor registers into the VM 07:19:38 PoppaVic: um... r1 r2 r3 r4 r5 07:19:44 right 07:19:53 especially since this is a stack-based VM; we don't HAVE registers, mostly. 07:20:09 with gas you actually have to pass -mregnames so you can do this, otherwise only 1 2 3 4 5 is allowed 07:20:21 tathi: yeah, I'm sorta' "downshifting" to place the vm sorta' NEAR the silicon and interceeding with the stack-based forthish 07:20:36 PoppaVic: that's not helpful 07:20:49 PoppaVic: that makes it way harder to write a good optomizing vm implementation 07:20:57 not really 07:21:07 if you hive the guest system access to your registers, than you can't use them in your native JIT stuff 07:21:10 PoppaVic: have you read Peter Knaggs' PHd thesis? It's pretty simple to translate from stack code to register-based. 07:21:16 jas: tathi already has mentioned his C porting is working 07:21:18 I don't see any point to letting the user hard-code them. 07:21:29 tathi: no, sorry never heard of it 07:21:29 (them = processor registers) 07:21:59 ahh, ok - so you have some docs around to consider the conversion? 07:22:07 besides, there's no god way (afaik) to get at a register who's number is only known at runtime 07:22:35 JasonWoof: heh - THERE you are thinking of local/host and configuration ;-) 07:22:57 NSTHSOENTU 07:23:06 eruh? 07:23:06 http://dec.bournemouth.ac.uk/staff/pknaggs/thesis/index.html 07:23:10 it's a freaking VM for god's sake 07:23:13 chapter 5 is the interesting one from my point of view 07:23:42 yeah, I'd like to point out that this isn't intended to be some silver bullet of portability. 07:23:45 the whole point is to isolate 07:24:01 to make a box that works exactly the same way from the inside 07:24:11 no matter what you're running it on 07:24:18 JasonWoof: I'm not arguing that, of course. What I'm doing is throwing spin at it and considering if the ideas would help in synthesizing a cpu and assembler as well, ok? I'm not trying to ruin yer Wa, dude 07:24:19 tathi, why make a vm if you don't intend to be portable? 07:24:39 my Wa? 07:24:59 yer "center of calm", peace, mood, mojo 07:25:13 Quartus: we do intend to have the vm implemented on many platforms 07:25:21 Quartus: that's the main reason for the C version 07:25:46 tathi wrote the ppc asm version first because it's just cool 07:25:56 Quartus: the main point is to make it easier to run herkforth on 32-bit x86 machines than having to build and configure qemu 07:25:57 and that's what we'll use personally 07:26:16 and so it'll run on windoze 07:26:56 Well, yes, I'd have thought portability would be the key reason. I was responding to tathi's comment about it not intended to be 'some silver bullet of portability'. 07:27:20 Quartus: I just meant I don't have the scope of PoppaVic's project in mind here. 07:27:28 Ah ok. 07:27:42 I'm completely ignoring everything but 32-bit machines, for instance. 07:27:53 tathi: yeah, my ideas mostly keep churning madly around vm's and C-cores. 07:29:35 PoppaVic: I'm coming to think that, long term, it makes more sense to have some kind of generic compiler infrastructure (than a VM). 07:29:44 yeppers 07:29:54 if you want to consider a specific target 07:29:58 though... you need some kind of intermediate representation, so maybe compiled code for a fairly portable VM would work well there. 07:30:14 right, I agree 07:30:44 On the whole, I really think C's inline-asm was a doorway to doom. 07:31:03 ..at least, the way it ended up implemented. 07:31:28 It lets in all the non-portability demons 07:31:56 well, I think it was intended to help out OS implementors -- let them do everything straight through the C compiler. 07:31:58 soccer :) bbl 07:32:23 although... it's hard to read, so even for that purpose... 07:32:27 right, tathi - it certainly was, but damn.. It sure left us in the lerch 07:32:30 lurch 07:33:24 Nobody with a goal of portability uses inline assembler. 07:33:24 I don't really see it as a problem -- not that many people use it, in my experience. 07:33:38 tathi: to behonest, there is no compile-time support for ID for proper use of the asm. 07:34:01 anyway, forget that.. I think I see where you guys are headed 07:34:12 true 07:34:52 My feeling would be that you'd merely need a decent vm-header and perhaps an asm-source module to link in. 07:35:05 something like that 07:35:46 I'm still totally confused about if/how one would add an asm-voc to the language, but I suppose it could be perverted. 07:36:18 I don't really plan to. 07:36:35 I don't blame you 07:37:04 Well, I've been doing a lot of thinking about a forth-to-native compiler, written in forth. 07:37:22 otoh, if I have a vm-cpu layer under the forth-vm layer, then yeah - it's a non-issue 07:37:37 And... I think most of the machine-dependent stuff can be kept to a small layer, and not affect other stuff much. 07:37:38 tathi: yes, I've thought and wished for those for decades 07:38:02 I have a fair amount of it written out in forth pseudo-code. 07:38:14 even better if it generates source for C or asm or something. 07:38:17 Once I get this VM thing up and debugged, I'm going back to working on that. 07:38:37 Yeah, I think the actual output layer can be almost totally isolated. 07:38:45 I agree 07:38:52 Don't know if I want to think about generating C 07:39:08 But generating asm source instead of machine code would be trivial, and I definitely plan to do that. 07:39:15 well, what is generated is pretty well open. 07:39:18 yeah 07:40:09 hell, with a proper system, you could prolly generate lisp or perl or sh. 07:42:25 I really look forward to further code-perusal and discussion, I think some of these ideas are pretty damned tasty. 08:01:13 tathi: what was the 'latch' for again? 08:01:56 the instruction? fetches the next instruction word. 08:02:25 latch is a fetch?? 08:03:04 yeah, I'm calling it 'next' now. 08:03:09 guess I didn't change it everywhere 08:03:14 ahhhhhh 08:03:29 ok, THAT changes matters ;-) 08:03:44 hrm, 'next' isn't great either though. should be 'next-word' or something. 08:03:58 step 08:04:34 basically, the vm is a stepper-interpreter ;-) 08:05:01 that's the thing, it's NOT step. It doesn't process the next opcode, it fetches ("latches") the next word of opcodes. 08:05:04 PoppaVic: yup. 08:05:44 no, I understand - it does "take a step", but sure - the interpreting would follow ;-) 08:05:49 yeah. 08:06:10 I did this in my commonforth efforts. 08:39:57 Just for fun.. I may twiddle that opcode-list. Do you have explanations for what each mean? Some are familiar, others are very weird-looking 08:47:33 hmm, hang on, I'll add them to the list. 08:53:28 ok, updated 08:53:43 url again, please? 08:54:04 http://josh.qualdan.com:3/svn/fovium/opcodes 08:54:15 let me know if something needs more work 08:54:24 loading 08:54:47 ahh, b is branch - what is 'h'? 08:55:25 it's a prefix for 'half-word' (16-bit), probably 08:55:43 oh, I see - it's columnar-shorthand 08:56:21 call isexternal? Or starts a new colon-word? 08:57:08 call is like branch, but saves IP to the return stack so you can return ';' 08:57:26 ok, so internal and used to nest/branch 08:57:30 err... (with ';') 08:57:31 yeah 08:58:13 ok, I'll cogitate and diddle this a 'bit' ;-) 08:58:23 have fun 08:58:37 could be interesting 09:01:56 Other than zero, is there some reason for the order that is intristic? 09:03:25 well, I chose 0-3 as what I thought were most common (they fit into 2 bits) 09:03:30 other than that, none whatsoever 09:03:38 No noop. 09:03:44 ok, why does the 2-bits matter? 09:04:14 Quartus: I don't understand the need for a noop in software... 09:04:16 yeah, NOP - an issue,if minor right now 09:04:31 PoppaVic: those ones will fit in the high (6th) slot. 09:04:35 only useful for padding and a guarenteed place-holder 09:05:00 tathi, for patching code primarily. 09:05:08 tathi: ok, but.. I'm still confused about why the bit-field "end" matters? 09:05:44 tathi: are you "sometimes" checking bits instead of the overall index? 09:05:58 PoppaVic: it doesn't, really, but it's only 2 bits (high bits will be filled with zeros). So it can only fit the first 4 opcodes. 09:06:05 seemed like it made sense to try and pick the most common ones 09:06:07 hmm 09:06:14 humph 09:06:41 I think it's overkill back-bending to consider under 8-bit. 09:07:02 Quartus: Ah. I think I only ever patch branch addresses, not opcodes. 09:07:09 I'd sorta'-kinda' understand some 4-bit fixation for pics and such 09:07:42 yeah, I can see that. 09:07:43 but.. It seems like an iffy proposition, I'll take it into consideration, though 09:08:07 2 four-bit 'fields' may be doable 09:08:16 But... it's enough space for me. I went ahead and filled it up, but there's plenty of stuff you could lose. 09:08:27 sure, lemme contemplate it. 09:08:52 I presume that, almost universally, you just use it as an indice into the vtable, right? 09:08:58 the flag stack could go, as could the conditional return words. You don't need most of the rstack words...etc. 09:09:03 yeah. 09:10:23 well, the fl-stack is an interesting idea.. I don't mind considering this as a sythetic-cpu. 09:10:55 it'd be internal, humans would have no direct access anyway, that I can imagine 09:14:17 --- join: ayrnieu (n=julian@ip68-13-110-105.om.om.cox.net) joined #forth 09:20:46 soccer was fun. didn't fall once 09:20:51 heh 09:21:17 JasonWoof: tathi went ahead and posted a commented opcodes, anythingyou care to rename/change? 09:22:17 tathi: btw, is there a similar list/struct for "regs/ptrs" for the vm? 09:23:18 fwiw in my notes I called the latch/next opcode nexti 09:23:32 cool 09:23:48 JasonWoof: registers used? can you specify them? 09:25:50 JasonWoof: mind you, I mean for the VM/forth 09:25:59 the next thing works as a noop and placeholder 09:26:32 well, based on the name - I'd expect nexti to increment IP only. 09:27:40 I'd presume, but that's dangerous. Seems likely you have rp,sp,dp,ip - but what else/others? 09:28:16 are we going to have to write a 5 page paper on the concept of splitting 32 bits into 5 6-bit fields, and a 2-bit field at the end? 09:28:27 no. 09:28:36 you got it now? 09:28:43 I'm going to twiddle/juggle some of these is all. 09:29:17 JasonWoof: no, man - I was told the spare 2 were pretty much non sequitur. Did I miss something significant? 09:29:24 the vm implementation grabs the low 6 bits for the opcode, then shifts the word down, then branches into the branch-table for the implementations of the core words (using the opcode as the index) 09:29:58 after the 5th shift, the 2 high bits from the instruction word are the low bits 09:30:14 ok, why all this twiddling? 09:30:23 the vm implementation reads them in, and has _no idea_ that there's only two bits from the original word 09:30:34 the value is 0, 1, 2 or 3 09:30:53 0 is the next-instruction-word fetcher 09:30:59 umm, ok. ANd? 09:31:21 this (using the high bits) adds no complexity to the vm implementation whatsoever 09:32:12 ok. I can hear what you say and even envision all this shifting foo-foo. Just trying to ascertain why. 09:32:39 YZou already have a vtable. So, what does the shifting accomplish? 09:32:50 speed 09:32:52 simplicity 09:32:56 umm.. 09:33:09 as opposed to fetch/mask/index?? 09:33:23 yes 09:33:32 that sounds fairly insane. 09:33:47 http://josh.qualdan.com:3/svn/fovium/fovium.c - there's a list near the top of what you might call "registers" 09:33:56 ok, thanks tathi 09:34:00 bah, it's just shift/mask/index instead of fetch/mask/index 09:34:22 it's about the same either way. 09:34:23 umm... you still need a fetch to mask, afaik 09:34:33 grrr 09:34:38 NO YOU DON't 09:34:42 oh. I'm assuming you already have it in a register 09:34:45 stop hollering man 09:34:53 one of the opcodes loads the instruction word 09:34:57 next-iword 09:34:57 tathi: yeah, I was trying to ascertain where 09:35:05 we've been talking about that for a freaking hour 09:35:23 oh. fetches opcode, ok. Fine. Great - so wht are you now shifting? 09:35:23 opcode 0 09:35:47 "word of opcodes" confuzzled me a mo 09:35:57 32-bit word 09:36:06 containing 6 opcodes 09:36:15 ahhhhhh 09:36:15 packed 5 bits each, except the highest which is only 2 09:36:16 ok 09:36:24 I see, shifts now make "sense" 09:36:38 sorry, I was thinking padding and bytes. 09:36:51 yer thinking padded-"opcodes" 09:37:00 we're not padding anything 09:37:07 heh 09:37:30 sure you are, 2 bits you 'X' and loading 6-per 09:37:54 if you loaded six, then either unused are trash, or you voodoo the packing 09:37:54 the main loop in the vm implementation is 4 ppc instructions, including 2 to branch 09:38:07 (ppc you can't just branch to an address in any register, you have to move it to a special register first) 09:38:18 yeah, I figured it was odd 09:38:34 I have no idea what you're talking about 09:38:42 I don't know about x86... it MIGHT be one extra instruction to do it this way, but I doubt it. 09:38:44 that's ok, I think I now do 09:38:58 but trust me, there's no padding, unless you have to allign to a word boundary so it can be the target of a branch/call 09:39:16 JasonWoof: yer making basic, cpu-based assumptions before you ever get to the vm. I was unaware of this, and it explains some of it 09:39:44 PoppaVic: could you please be specific? 09:39:47 no, he's not. on any RISC cpu it should be the same speed to do it this way as with bytes 09:39:57 In C it looks about the same, may even be shorter this way. 09:40:05 as I said, I think it's the same on x86 as well. 09:40:16 about the branching and fetching and such. tathi sure, I can see where it all leads now 09:40:26 there may be some processors where this way is slower, but in general, its's pretty much the same speed. 09:40:36 anyway, I'm out for lunch 09:40:38 it should be, eventually 09:40:42 lates, tathi 09:41:39 I think 2 ppc instructions to get the next opcode and calculate the address within the branch table that you need to branch to is not possible to beat 09:42:52 you _might_ be able to get it down to 2 instructions with 8-bit opcodes 09:43:20 but unless I'm missing something, that makes the vm implementation more complex 09:43:48 considerably in fact 09:43:54 ok, maybe not that much 09:44:13 on ppc anyway 09:44:13 hehe 09:44:40 ain't it fun? viewpoint and backoff/rotate-review can do a number on yah 09:44:41 to fetch a 8-bit opcode, and update the instruction pointer in one instruction on ppc you have to do a pre-increment fetch 09:44:46 (as there is no post-increment) 09:45:09 which means that you always need to keep the instruction pointer one byte before the next available instruction 09:45:41 Seems likely to me that his last url's "machine" and the (basic) vtable-entries iscurrently the key - the shifting/packing is a local-issue 09:45:57 yeah, I did similar for commonforth 09:46:47 ok, now can you follow the logic to where this makes it rather tricky at best to get the litterals out of the instruction stream? 09:46:54 the actual code-mechanisms underlying the "VM fetch/do" is always the kicker 09:47:22 yes, it's not "neat" delineation, so it sure would slow it down for "exceptions" 09:47:26 here's a diagram of a few instruction words. one byte per character: AAAABBBBCCCCDDDD 09:47:38 yeppers 09:48:02 so the interpreter is now loading the seccond A byte, it's a lit. as it fetchish it updates the instuction pointer to point to the seccond A. 09:48:13 better is to see: XX1111,XX1111,XX1111,XX1111 09:48:22 (or reverse) 09:48:27 so now we have to calculate the address of the litter value (BBBB) 09:48:35 so we mask of the low bits of the IP and add 4 09:48:40 fetch the whole word BBBB 09:48:49 yeah, I would suspect that itself is slower than using a byte. I really would. 09:49:07 now... how we can't update the IP to skip BBBB because we haven't finished the last two A opcodes 09:49:23 I have to diddle-poke this for a day or so, but yeah. 09:49:40 another option is to screw allignment 09:49:46 ahh... wait 09:49:50 and put it as: AABBBBAACCCCDDDD 09:49:58 but you can't fetch words out of allignment on ppc 09:50:04 so now the routine would be: 09:50:05 I think I see a concept-flaw I endran once.. 09:50:18 fetch seccond A opcode, which updates the IP to point to the seccond A 09:50:34 yeah, that 'fetching' is clever, but complicates shit 09:50:44 now to fetch the literal you have to do 4 incrementing byte-fetches and shift and or them together 09:50:45 I believe I added a vm-reg 09:51:17 http://www.hypercon.net/~pfv/commonForth.tar.gz 09:51:25 neither of these options are appealing to me _at all_ 09:52:10 or we can do it the way we are, where the main interpret is two instructions and a branch 09:52:18 dude, it's nice yer so cozy with the ppc and forth, but in many ways backing off a ways and examining structures/code/concepts is useful. 09:52:28 1) mask into vtable pointer 2) shift remaining bits down 09:52:33 lemme' cogitate a sec. 09:52:45 yeah 09:52:47 all fetches from the code are full 32-bit word incrementing fetches 09:53:32 ok, who is fetching? the vm or the underlying code? 09:53:44 vm implementation 09:53:51 there should be no reason to obsess over the ppc itself. 09:54:00 although the above would presumably be true of the guest system too 09:54:11 sure, host versus target 09:54:15 PoppaVic: you're being really insulting 09:54:21 * PoppaVic sighs 09:54:33 you just told me I'm obsessing 09:54:53 You're really getting to me 09:55:04 you've been arguing against the way we're doing this without understanding it 09:55:05 I don't mean to be insulting... I'm trying to slow you down a trifle and comprehend several views and a whole new imp atop a cpu that makes my head spin, ok? 09:56:00 by all means take your time 09:56:04 now, doggone it - fine, if I am bugging you that much, then fine. I'll drop it and not bother you It's not going to make me cry. 09:56:04 read what I wrote 8 times if you like 09:56:11 if you have questions fire away 09:56:36 I ain't even had time to REVIEW this stuff, so my questions are certainly broken right now. 09:56:37 it's just pointless for you to sit there and tell us that we should do 8-bit instructions 09:56:42 we considered it believe me. 09:56:53 it's more complex _and_ slower 09:56:56 I have never,EVER TOLD you to use 8-bit. 09:57:04 I think in bytes, however 09:57:13 bytes are 8-bit 09:57:21 that's what a byte is 09:57:22 most places ;-> 09:57:23 8 bits 09:57:28 no, everywhere 09:57:32 everywhere 09:57:49 oh, I'm sorry 09:57:55 sorry, the C folks would disagree I don't, but they might. Meanwhile, I never insisted you use 8 09:58:17 I thought it specifically meant 8 bits 09:58:33 just calm.. maintain-yer-maintains.. I'm still trying to read tathi's email and posts 09:58:33 well, maybe you were just completely ignoring the context of this conversation 09:58:51 we have said many times that we are only interested, talking about, and implementing for 32-bit machines 09:59:03 in which context a byte is most definitely 8 bits 09:59:25 yeah, yeah, yeah - heard that.. Then 4-bits where mentioned, and 6 and long fetches and - well, just relax. 09:59:48 far as I know, I can't even try to build and run the stuff. 09:59:58 ..but, I'm just reviewing 10:04:38 hmm 10:12:32 --- quit: virsys (Read error: 110 (Connection timed out)) 10:17:45 --- quit: PoppaVic ("recycles the ISP") 10:19:10 --- join: PoppaVic (n=pete@0-1pool46-166.nas30.chicago4.il.us.da.qwest.net) joined #forth 10:19:37 OK. Sorry. Did an isp-recycle 10:20:48 JasonWoof: out of curiousity, how well does the flag-stack work out? 32-bits seems pretty short. 10:23:16 any data on it? 10:24:37 man.. 10:25:45 in our implementation the flag stack is 32 deep 10:25:51 right 10:26:11 I'm guessing that's far more that we'll ever use 10:26:17 it's a 32-bit word, but I presume ANY flag - just wondering if there are depth issues? 10:26:47 each flag is just true/false 10:27:10 are you then presuming as a fact that flags are on/off switchs? Ahh. So, they sorta' parallel using values as flags? 10:27:27 flag stack just stores true/false 10:27:31 you can't put a value on it 10:28:14 I know, I meant "as is typical". Who emplaces the value? Since any value can act as a flag. 10:28:48 emplaces? 10:28:54