00:00:00 --- log: started forth/06.04.02 00:31:51 * Robert is watching one of the videos from ultratechnology.com 00:32:18 CM talking about insane hacks on a flash drive. 00:50:48 hi Robert 00:51:28 Hi, virl. 00:54:42 I'm allways fascinated about myself to make other people angry, like slava, maybe I shouldn't be so emotionally, but on the other part that's me. 00:56:58 Just try to be a bit more diplomatic. If you disagree with someone, don't just publicly call him an idiot or something. 00:59:29 Robert, do you have experience with CPUs where no exernal memory is attached and all the action happens in it's registers? if yes then could you say me some uses for such CPUs? I'm asking that because I need to specify a minimum set for xell, so that's also possible to run it on that CPUs. 01:01:37 Hmm... I've worked with microcontrollers with combined "register banks"/RAM. Maybe 64 bytes of addressable registers. Does that count as "registers" or memory to you? 01:07:23 everything which is ON the CPU is ok. 01:07:50 Sure, I've even implemented a Forth system with a compiler on a system like that. 01:08:10 You need amazingly little RAM to do that. 01:08:55 yeah, I tried something similiar on such a system, but it I haven't finished it yet. 01:09:40 I don't think there's anything special to consider. Forth scales very well. 01:09:41 but you need space for the dictionary entries 01:09:49 Yeah, I kept that in Flash memory. 01:09:56 ok. 01:11:02 yes, forth scales well. I hope that Xell also scales well, it's my target to have it scaling well. 01:13:09 how much registers had the C64 CPU? 01:13:25 Three 8-bit registers: A, X, Y 01:13:31 (not counting the stack pointer) 01:13:45 And 256 bytes in a zero page, which was faster and easier to use. 01:14:15 puh.. 01:14:19 You could perhaps count those as "sort of registers". 01:15:21 well, my current plan of a xell minimal system uses six registers 01:16:03 Why six+ 01:18:00 two registers for a minimal stack, one for the current bytecode/byte from input, one for the current output byte, one for the current input register and finally one for the current output register. 01:19:37 I think I'll implement a test system for the x86 in assembler, with a cell size of 16bit, so I can have 8 registers. 01:21:46 Oh, I see. I thought you mean that the user code inside xell would see six registers. 01:28:57 I think the purpose for such cpus which have such a configuration would be reading bytecodes from their input, computing them and writing the result to output, so a subprocessor. 01:29:55 And store all the code in RAM? 01:30:06 or ROM 01:30:34 I mean the bytecode you transfer to the "co-processor". 01:31:41 it could be stored in an external ROM or it could be written in a memory area on the cpu if it's a RISC cpu 01:31:58 a harvard cpu 01:32:03 sorry 03:00:13 for what exactly is the x86 byte swap instruction? should swap it two 16bit values in a 32bit register? 03:00:45 no, two 8 bit values in a 16 bit word 03:00:45 No, it will reverse the byte order. 03:01:07 So if you have 0x01234567 and byte swap it, you'll get 0x67452301. 03:01:18 yes, it reverses the byte order, but for what? 03:01:56 htonl() perhaps? I'm not sure where it's used most. 03:02:47 hmm htonl() yes, there it could be useful. 03:03:13 well, it's a sick cpu :-P 03:04:11 Perversions are good. 03:06:33 theres worse :D 03:06:55 on the virtual CPU we had for class you could do something like add 3 numbers, and completely ignore the result, in just one instruction 03:07:37 among other things 03:07:59 you had a compare instruction that would set a zero and a negative flag 03:08:18 theen there were a few conditional jumps 03:08:36 there waas also another flag, which could only be set using test, and could only be used to jump by using "branch" 03:08:48 ad ht would jump if it was not zero 03:08:54 and it* 03:09:19 then you had a stack, except that you couldnt index into it at all 03:09:55 oh, and we had to work on the internals 03:09:56 ugly :) 03:13:23 I'm asking myself if the guys who did this, where on drugs. 03:13:25 I was watching this video of Chuck Moore demonstrating the old OKAD system, and it was rather slow (by absolute standards). Does anyone have experience with distributed circuit simulators? 03:13:48 which video is that Robert? 03:16:18 well, he says his current OKAD can emulate his chips at at least full speed 03:21:31 virl: It's here, http://www.ultratechnology.com/ -- the second one. 03:24:58 it's fascinating that all of chucks videos are recorded really bad 03:25:15 Yeaoh. 03:25:20 And end in the middle of something. 03:28:11 ok, the 2005 video is 'acceptable'. but whoever filmed him, he thought that it's cool to see him in the middle of the screen with a zoom of 400% or something like that. 03:28:36 Oh well... at least the contents is cool. 03:30:50 yeah, the okad presentation was cool. I think okad was/is the first really big use of forth. 03:31:04 virl: ...... 03:31:08 i cannot believe you just said that :D 03:31:20 those old nokia celphones? forth. 03:31:29 How old? 03:31:42 not sure, quite a few years though 03:31:51 also, lots of microcontrollers in general, forth 03:32:07 OKAD isn't exactly new. 03:32:33 true 03:32:41 but there was plenty of frth 20-30 years ago 03:33:09 How about really big and complex applications? 03:33:21 NASA 03:33:23 :) 03:33:53 I don't know how big their forth systems were. 03:34:13 arke, well I don't know much big complex applications which use forth. I know okad and that is pretty complex, I mean a CAD system, nice. 03:35:03 well, hows this 03:35:07 OKAD is only 25 blocks of CF 03:35:20 pygmyforth itself is 100 blocks, which could only store about half so lets say 50 03:36:04 I also know that there was a adventure kit in forth on the C64 and there was also somewhere a word processor which was written in forth. 03:36:41 * Robert has quite a few Forths for his C128D system. 03:36:59 C128D system? 03:37:58 Commodore 128D (C64 compatible, but larger and fancier). 03:39:46 well, I mean I love forth, I love it really, but I would be happy when I could say that I know uncountable complex forth programs, you know something like an office suite, or games or scientific graphs drawer and so on. 03:40:15 12:15:57 < arke> well, he says his current OKAD can emulate his chips at at 03:40:15 least full speed 03:40:19 That's crazy. 03:40:20 that's for me big and complex, I don't mean with it's size 03:40:47 If you're refering to the physical chip simulation, it's just insane. 03:41:03 He did mention a software-only simulator though, in case that's what you mean. 03:45:32 Hmm.. does Jeff Fox still have the essays/inteviews on his web site? 04:11:34 oh, my god. I just compared the 1024 x printing helloworld benchmark with java, it's in console(no xterm) and writing it's output to /dev/null takes really 0m0.510s! well, wow. 04:12:08 Including the Java VM loading? 04:16:17 yes, I tested it like the other programs 04:16:33 time > /dev/null 04:22:59 well, that's sick 04:25:23 I hope that xell with all it's overhead won't be compareable in it's slowness to Suns Java vm, if yes then I'm really devastated 04:29:07 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 04:29:17 Hi, tathi. 04:29:58 hi tathi 04:30:42 0.510ms for 1024 printing helloworld in java, I'm so shocked. 04:31:19 I'd say it's 1ms for the printing and 509ms for launching the VM. ;) 04:32:11 nah, I think it takes longer. 04:36:38 is there a way to access the upper 16bits of a x86 32bit register? 04:36:57 eax accesses the whole register, right? 04:37:51 Yeah. You'll have to mask the bits out, or shift them right and use ax. 04:38:14 Hmm... maybe there's some word swap instruction. Can't remember. 04:45:05 hey all 04:55:00 virl: how long does java take to print 2048 helloworlds? 04:55:47 or to print just one? 04:59:00 to print only one it takes ~ 350ms 05:00:00 so java needs about 200ms to print 1024 helloworlds 05:02:14 huh. I thought the startup time would be longer. 05:02:36 since everybody seems to say that java is so bad about that 05:20:56 ahh.. I hate little endian. mv eax, ebx and I want to set the lower 16bit to zero. so I do and eax, 0x00ff? 05:21:19 eh, and eax, 0x0000ffff? 05:31:39 yes 05:31:46 that would be the same on big-endian 05:32:36 you always write the most significant bits to the left in a literal 05:32:44 endianness only affects the organization in memory 05:33:46 as long as you're not writing something to memory as one size and reading it back as another, you don't have to care 05:35:09 well, I'm only getting a headache of it 05:58:56 when I write into memory one byte at ibyte db 0x0,0x0,0x0,0x0 then it should be ibyte db 0xvalue,0x0,0x0,0x0 and when I read that into one register how does it look like? 05:59:57 0x000000value 06:00:09 On x86, that is. 06:00:54 ah, ok.. 06:01:40 why are you writing it as a byte and reading it as a 32-bit value? 06:03:00 well, the read syscall I need only one byte 06:06:36 oh, right, x86 has no sign-extending loads 06:08:21 Really? 06:08:35 movsx ? 06:09:43 ah, does it? 06:11:00 oh, so it does 06:14:18 Don't think I've used it, but I vaguely rememered a sibling of "movzx". :) 06:16:21 movzx zero-extends? 06:16:31 that's what I was really thinking of 06:16:53 I thought byte loads always just loaded that part of the register, leaving the rest alone 06:24:46 they usually do 06:24:54 movzx doesnt :) 06:25:48 yeah, I didn't realize movzx existed. 06:25:53 x86 makes perfect sense if you have lots of imagination and a history book reaching back 30 years. 06:26:01 :) 06:26:10 :) 06:26:10 --- join: segher_ (n=segher@dslb-084-056-158-044.pools.arcor-ip.net) joined #forth 06:26:17 Hmm... 30 years exactly, actually. 06:27:24 O RLY? 06:27:30 Er, wait. 06:27:38 That'll be in two years. 06:27:47 the 8088 came out 178 06:27:53 the 008 came out 72 06:27:56 8008* 06:28:39 * Robert must have confused x86 with some other ancient microprocessor. 06:31:01 Z80 came out 76 i think 06:31:55 yeah, the z80 camee out 76 06:31:56 Yes, among with a bunch of other chips. 06:33:22 RCA 1802 for example. Got a bunch of those on a flea market. 06:33:32 Look it up on wikipedia, they even link to a Forth for it. 06:34:22 --- quit: segher (Read error: 110 (Connection timed out)) 06:40:47 --- join: JasonWoof (n=jason@c-71-192-33-206.hsd1.ma.comcast.net) joined #forth 06:40:47 --- mode: ChanServ set +o JasonWoof 06:46:29 hi JasonWoof 06:47:06 how fast do you guess is a java program which writes 1024 times hello world? 06:47:58 dunno 06:48:10 java startup always takes ages 06:48:39 I've never had a good java implementation in my life though 06:49:08 I'd guess that printing "Hello, World!" once in java would take depressingly long. 06:49:31 and that printing it 1024 would not take any considerable amount of time longer 06:51:00 in fact it takes about 200ms longer than printing one helloworld 06:51:48 wow 06:52:00 wait... 06:52:07 are you testing >/dev/null ? 06:52:16 yes sir, and on console. 06:52:20 --- join: PoppaVic (n=pete@0-1pool47-44.nas30.chicago4.il.us.da.qwest.net) joined #forth 06:52:21 oh good 06:52:22 not xterm 06:52:35 well, that's depressing 06:52:43 Mornin' 06:52:49 I don't see why it should take so long to call the same syscall 1024 times 06:53:19 whatever, not my problem 06:53:25 I avoid java like the plague 06:53:44 Hi, PoppaVic. 06:53:49 And JasonWoof. 06:53:54 hey, Rob 06:53:59 hi Robert :) 06:54:24 Well, I'm short on time this morning because I didn't know about the time change (ie my alarm clock didn't know about it.) 06:54:31 ouch 07:13:01 --- join: Lars_G (n=lars@unaffiliated/lars-g/x-000001) joined #forth 07:13:10 Hi, Lars. 07:13:26 Hi Robert 07:17:25 --- part: Lars_G left #forth 07:26:41 --- join: greenjenny (n=greenjen@phobos.asee.org) joined #forth 07:31:37 --- quit: greenjenny ("Leaving") 07:40:27 humph 07:41:41 oompah 07:42:02 swimmin' in circles... 07:42:28 a healthy workout 07:42:45 Sure enough... And, educational in a limited, painful way 07:42:58 hehe 07:43:09 Not real productive, though 07:44:22 well you'll try not to do it again, so it's indirectly productive heh 07:45:10 no, that's the circle-part... You see an issue, swim toward that; see another issue, swim toward that [repeat]... goto zero 07:46:17 I'm beginning to think there are several interrelated "issues", and there may be a solution at a step-resolve to the whole slew. 07:47:18 so take a step away from what you currently think the problem is, and look at the bigger picture 07:47:52 right... That's what I'm trying to do today.. Sorta' trying an overview with less than full-attention. 07:48:22 ..sometimes, the subconcious can churn out an answer - hearing it is difficult. 08:22:23 has nasm a problem with jz? 08:25:04 I think some versions have been alternating between the default size to use with jz and similar instructions. 08:25:29 * PoppaVic chuckles 08:25:37 Which has resulted in different code on different versions. I think that broke some things as well, can't remember any details. 08:25:47 it gives an expression syntax error 08:26:03 Probably something else. What's the code line it dislikes? 08:26:22 it's this code what it dislikes: jz add 08:27:03 "add" is reserved. 08:27:09 Use a different label name. 08:27:47 ups, that was stupid 08:28:34 * Robert nods. I've made that mistake too many times. :) 08:28:53 yeah, running into "reserved words" is a pita 08:29:16 hehehe.. "contexts" ;-) 08:49:38 the one of those that annoys me the most is the libc function 'dup'. 08:50:23 hehehe 08:51:09 especially since I've never seen it used 08:51:17 I have 08:51:49 It's all handles/io and replacement... But, I get peeved in general 08:51:56 ah. maybe you can explain to me why it exists then? 08:52:23 I've been unable to think of any reason to use it 08:52:32 generally, predicates piping - it's like a primitive 08:53:42 suppose you want to save stdin, but have a load of work you'd want to fork into and TREAT as stdin 08:53:55 ..same with stdin/out/err 08:54:26 ah 08:54:46 that makes sense 08:55:26 Unfortunate namespace issues 08:57:16 C is (sadly) a lot like most Forths in that namespaces are a "we can ignore this" idea. 08:58:40 it wouldn't bother me much, except that my linker searches the standard library first 08:59:14 so it will silently give unexpected behavior if you accidentally overlap something. 08:59:45 in Forth, you get the most recent definition, so it's not a problem unless you actually want to use both. 08:59:50 right, and that can be "fixed" with apropos comline inputs, but it's a pita 09:00:07 right... security disarray 09:00:26 huh? 09:00:47 I've been cogitating thus for several years.. I see the forth and the C views... 09:01:17 C wants to ensure that root-installed libs get preference, forth sees the universe as it's user and playground. 09:02:28 I didn't think it was that intentional 09:03:04 I believe it is droppings/drivel from the whole issue of embedded versus shared. 09:03:35 Too many cases of both context-oriented and global 09:03:42 whatever :) 09:03:46 they get all snarfled. 09:04:07 I've never run into most of the issues you seem to have, and I never intend to. 09:04:38 I wish you fantastic luck, but I don't plan to sweat too much. 09:05:02 Forths have their own issues that are related. 09:05:06 sweat too much over what? 09:05:32 solutions; I just pray you never see a need. 09:05:51 tathi: hows the rewrite coming, btw? 09:06:27 I started working on stuff for names 09:07:26 I'm going to keep it very simple for now. 09:07:43 internal? RAM? 09:08:09 ? 09:08:17 I'm pondering similar, thinking of it as "keywords" 09:09:34 I'm beginning to think it's an issue of "extensibility" in relation to lookups: contexts, modes, states, etc. 09:10:41 For example.... Your VM wants to comma-in "bytecodes", from what I saw 09:10:56 yes 09:11:19 Isn't this like "compile-mode" and "immediate" and such? 09:12:47 I don't think I understand the question 09:13:34 Yeah, not your fault.. I don't believe we are working in the same terms... OK, yer VM is eval/interp/executed, right? 09:14:03 the VM just executes bytecode 09:14:30 Does it not add new codes - nor names? 09:14:31 I will, of course, be building a forth interpret/compile loop as well 09:14:51 ahhhh 09:15:10 OK, yer still in the fixed-array, (one of) stage. 09:15:19 I'm not planning to add new bytecodes from code the VM is running. 09:15:29 It would be simple enough to add, but I don't have a need for it. 09:15:31 [when] 09:15:37 right. 09:16:12 OK.. You'll need it, but not today. I begin to see "it" 09:16:28 the new_system() function does take a pointer to the primitives array, so you can certainly instantiate separate systems with different bytecodes. 09:16:40 ahhh 09:16:45 step one ;-) 09:17:18 I plan to use static arrays of primitives that are constructed when you compile your C code. 09:18:06 You could construct them at runtime with C code, but without FFI that doesn't make sense. 09:18:56 hrm. No, I won't need it. 09:18:59 right. Understood 09:20:04 *IF* you can codify all potential funcs as an index into an array of pointers, and the index is a byte or less: yer golden. 09:20:28 it doesn't have to fit in a byte 09:20:55 whatever the size is.. I presumed byte for 0..255 funcs total. 09:21:29 and, unless you have something that compiles native code, all functions that you use are known by the C compiler anyway 09:21:46 so you have to "codify" all the functions that you want to use in any case. 09:22:02 wait. there is no size limit. 09:22:03 "bytecode" and "byte"... Otherwise, yer talking about something larger and that too is fine, if you can deal in those issues at multiple levels ;-) 09:22:30 oh, sorr. 09:23:05 by "bytecode", I'm just trying to indicate something that is generally more compact than direct or indirect threaded, which need a whole cell per "opcode". 09:23:14 btw, no: the C compiler deals in C to generate objects; you can't take them right back in w/o the linker... It's a mess, but at least we know it. 09:23:25 tathi: right 09:23:59 yes, but it's still an edit/compile/run type of thing. 09:24:05 you can't pull new functions out of the air at runtime 09:24:06 sorta' like .o are supposed to relate symbols to integers and link them all to a resolution pt 09:24:26 right, I thought so... groovy 09:24:56 oh. I guess if you know their type at compile time, that's enough. 09:25:11 yep - and the support for "type" 09:26:26 so... if all primitives for your forth are "void foo(Forth *);", then folks can compile modules and you can dynamically load them. 09:26:34 instead of having to recompile the whole deal 09:26:54 but that's not hard to deal with. 09:27:11 yes, if the bases are portable, and the other data is supported - the "interpretation" 09:27:44 Assume for a moment... 09:28:41 That not one ASM capability is "portable". That even ".o" portability is not the goal. 09:29:04 yes 09:29:42 I have no argument with either of those 09:29:43 From source, we need to be able to load/use/run "whatever" - and the .o and .S or .a are NOT more than a baseline. 09:30:10 the latter 3 are platform-specific. 09:30:20 from _forth_ source, you mean? 09:30:31 or _into_ 09:30:54 if it's in C, presumably you'd compile it to .o 09:31:03 we don't CARE: we generate a baseline we ALL agree upon, the rest - C or asm - is dross 09:31:34 we already both agree C should form the core, so... asm is not even an issue. 09:32:34 we want to interactively write code, extract it and objectify it, and link more source or the objectified code. 09:33:25 ok, but when you say, "From source, we need to be able to load/use/run whatever", you're talking about whatever this hypothetical language, not the C that composes the core, right? 09:33:39 s/whatever/source in/ 09:33:41 basically, the core is C - or our own source - or, our own "objects" 09:34:34 No, go ahead and let C be "portable assembler" - I can live with that. 09:35:06 I'm just trying to understand clearly what you're talking about here. 09:35:23 ..you do inherit all the oddities and calling-conventions, but you also get access to so many libs it ain't funny. 09:37:35 tathi: I'm mostly thinking that we've translators - to/from C and to/from some new objective-format, partial to our primitives. The former is core/binary, the latter can be source or "objects" - we'd still need to "interpret"... Either in RAM or text. 09:37:57 ...std forths expect text to "recompile" over and over. 09:38:35 ok 09:40:35 hmm.. 09:40:55 Here's where it gets even worse... 09:41:34 1) Forth really doesn't understand "macro"; 09:41:58 no; it has something better and more integrated 09:42:00 2) Forth doesn't understand "it ain't 'the machine' - or users/security" 09:42:10 no, tathi - follow me 09:42:21 ok, I'll shut up until you're finished 09:42:52 3) Forth does expect to integrate context, names, namespace, vocs and... 09:43:10 4) every word has "a handler" 09:43:41 5) forth wants to use the Dstack INSTEAD OR ARGUMENT-LISTS and RETURN-VAL. 09:43:51 ..ok, go for it 09:44:39 how is any of that a problem? 09:45:01 Only when you want bcode and portability. 09:45:16 ..or, (the worst case), FFI 09:45:25 I still don't see that it's a problem. 09:45:57 OK. np. Keep plugging.. Any news on the latest fovium? 09:46:22 fovium doesn't change much 09:46:39 Just heading into a "namespace" issue? 09:46:50 no, not at all 09:47:02 I was thinking "headers" 09:47:09 oh, you mean my new thing 09:47:18 headers are 100% "namespace" 09:47:44 Yeah, but as I said, I don't understand why you see all these problems. It seems pretty straightforward to me. 09:47:50 formats, under context, under lookup/add 09:48:40 ..and the original FIG-forth could "forget". No longer that simple, since forth is not the os (embedded) 09:50:03 I've thought awhile about your bytecode stuff, and how it relates to C and posix/*nix. 09:51:12 I think we merely need a VM that has some 'words' that are aware of "plugins" and a structure and types. 09:51:51 Remember, I still think "forget" is not a bad idea 09:51:54 yeah, sure, you can add whatever 09:52:40 I'm mainly interested in providing a core execution environment that can be easily extended to do whatever. 09:52:50 right, it has to do with states and contexts. I already am pretty sure we can't deal with the world of objects and .a libs 09:52:52 yeah, I have no problems with forget. 09:53:14 tathi: yeah, I know - hence, why I discuss with you. 09:53:34 Although a mark/empty style can also restore other state, so if you need that, it can be better 09:53:43 I think we can both agree we do NOT want to dip down into "asm" 09:54:08 tathi: yeah, I'm debating it... I'd seen early uses that made sense. 09:54:23 mark/release was what I recall 09:54:31 I think whether or not anyone uses asm is an orthogonal issue. 09:54:50 well, it does NOT belong in the vm is all.. 09:55:05 folks can't understand that even C is a form of VM 09:55:06 ANS has "MARKER foo". Then running foo forgets everything back to and including foo. 09:55:13 right 09:55:31 I never much liked that form of "release" 09:55:42 too easy to end up screaming 09:56:15 brb... let me give bro the phone 09:56:18 --- quit: PoppaVic ("Pulls the pin...") 09:57:10 what's exactly a vm which has redefineable instruction set? 09:57:34 I mean how is that type of vms called? 09:58:32 dunno 09:59:04 is that technique common? 10:00:14 you might call it more of a bytecode interpreter rather than a virtual machine, I guess. 10:00:39 aha.. 10:01:29 Python and Ruby and whatnot allow people to build extensions separately from the core interpreter 10:01:37 I'm not sure exactly what technique they use 10:02:53 --- join: TheBlueWizard (i=TheBlueW@ts001d0655.wdc-dc.xod.concentric.net) joined #forth 10:03:00 Hi, TheBlueWizard. 10:04:05 whatever, xell uses that technique. 10:06:36 hiya Robert 10:19:14 --- join: PoppaVic (n=pete@0-1pool47-57.nas30.chicago4.il.us.da.qwest.net) joined #forth 10:19:46 sorry, tathi - Matt wanted to check his [incredible] mail 10:23:37 fine by me :) 10:24:01 He checked, he logged out, and then the noise started *sigh* 10:24:43 As younger brothers go, he's interesting - I just can't too much "together time"/ 10:24:57 can't [take] too... 10:25:50 Meanwhile... Yeah, it seems pretty obvious we are talking the same sorta' code, tathi - just differing in goals. 10:26:40 yeah 10:26:43 I think that's where a lot of "solutions" start to bust 10:26:55 java and perl being the worst examples. 10:27:06 oh, predicate .Net 10:27:11 I just don't see that your goals present problems for this sort of setup, as far as I understand them 10:27:48 I try to "see" where "thinks" might lead... It can become irksome. 10:28:48 Stuff like FICL wants to pretend to 'A solution" - and then mixes metaphors/contexts 10:30:09 Right now, I am still concentrating on CHAR_BIT, and sizeof - trying to ignore padded structs - and cogitating "universal stack" versus "typed-stacks" 10:31:02 I've been reading around and realize now that there are "arithetic types" and "other" 10:31:04 * virl votes for normal forth stack 10:31:38 virl: no prob with The Stack.... the prob is , The Stack is up for interpretations. 10:32:37 ..and all interp is based on C, sizeof, casting, and CONTEXT 10:33:18 ..Forth comments already suggest this 10:34:27 I'd say "ABI" instead of "C" - but they are _not_ interchangeable. 10:34:47 ..all they do is codify "calling conventions" 10:35:30 Folks spouting "use 'Asm'" suffer similar issues, btw 10:43:06 I think interpretations are good, fix things are bad. 10:44:49 virl: somewhere down the line, the interp becomes binary and local. That's all folks need to remember... The *HOW* becomes an issue. 10:45:33 I don't understand. down the line? interp becomes binary and local? what? 10:45:50 oh... above and "do you really think you are assembling?" 10:46:08 virl: THAT is why you drive me nuts. 10:46:42 MC is interpreted: by the cpu; asm is SUPPOSED to generate MC.. and so on. 10:47:31 and you drive me nuts 10:48:31 I bet I do: I'm your "hairshirt" - deal with it. 10:49:19 hairshirt? 10:49:38 look it the hell up 10:49:44 * PoppaVic sighs 10:50:52 you're both a royal pain in the ass ;) 10:51:16 hehe 10:51:34