00:00:00 --- log: started forth/05.10.04
00:18:02 --- quit: zoly (Remote closed the connection)
01:50:35 --- join: binaryguy (n=binarygu@host86-131-192-107.range86-131.btcentralplus.com) joined #forth
02:10:52 --- join: [1]binaryguy (n=binarygu@host86-131-192-107.range86-131.btcentralplus.com) joined #forth
02:26:37 --- quit: binaryguy (Read error: 110 (Connection timed out))
02:26:43 --- quit: [1]binaryguy (Client Quit)
02:28:13 --- join: Amanita_Virosa (n=jenni@CPE0000e812679b-CM000a7362da55.cpe.net.cable.rogers.com) joined #forth
02:32:05 <Quartus> Morning.
02:32:30 * Amanita_Virosa nods
03:16:03 --- join: aum (n=aum@60-234-156-82.bitstream.orcon.net.nz) joined #forth
04:09:08 --- join: Robert (n=robert@unaffiliated/robert) joined #forth
04:09:45 <Robert> Has anyone ever tried to make a token-threaded Forth where the inner interpreter decodes huffman symbols on the fly? 
04:10:19 <Robert> Obviously not something you want to factor primes with, but combined with suitable factoring it sounds like something that could save a lot of RAM.
04:10:34 <Robert> (on some embedded systems, of course, not on a PC)
04:12:51 <Robert> Also - has anyone tried to write an auto-factoring system?  (designed for size reduction, not increased readability)
04:14:42 --- quit: Amanita_Virosa ("Whoops.")
04:16:37 <Robert> My ideas are stupid enough to scare away people. I'm proud.
04:19:34 <Quartus> Robert, factoring is already a kind of compression.  I'm not sure you'd gain much space in trying to compress tokens, and you'd definitely lose speed, which is generally far more expensive than RAM.
04:23:13 <Robert> Yes, I know it's a sort of compression, that's why I asked if you knew of any auto-factoring tools.
04:23:38 <Robert> And I totally agree - this would be a toy project. Probably for a PIC or something with 64 or so bytes of RAM.
04:25:12 <Quartus> With that little RAM, you'd get in your own way just trying to decompress the tokens.  If I'm writing an app in 64 bytes, I daresay can manage to assemble it by hand with far greater efficiency in terms of both size and speed than I'd achieve from any other method.
04:25:43 <Robert> Probably, yes. 
04:26:03 <Robert> I never said it's a good idea, merely an interesting one.
04:26:21 <Robert> (if you're into...those kind of things)
04:32:40 <Quartus> Auto-factoring (common code elimination) is something I played with a while ago.  It didn't produce significant cost savings in my system, and was extremely expensive at compile-time.  Depending on how it's implemented, it might replace a repeated sequence with a subroutine call, which runs counter to inlining; if you want both you have to have some way to mark inlined sequences to be retained, and it gets complicated.
04:34:12 <Robert> The compile-time issue isn't a big one here, since I'm working with small programs. I guess I could try to write down some brute-force search (since the program will be < 100 instructions anyway).
04:35:29 <Quartus> The compile-time issue can be a big one if you're running the Forth on the target system.  But for 100 instructions or less, you shouldn't be able to easily improve over what even a mediocre programmer can achieve.
04:36:58 <Robert> Hmm.... you're right about that - I wasn't thinking about running the compiler on the target system first. But if I didn't do that, this wouldn't save make much sense. Or rather, even less sense.
04:47:21 <Quartus> I'm not sure how you can run a Forth on a target system with only 64 bytes of RAM.  Not a conducive environment, even for Forth.
04:47:48 <Quartus> Just the input buffer would run longer than that.
04:51:11 <Robert> True, I'd have to make some (OK, quite a few) sacrifices. Maybe input one word at the time, maybe even pretokenized.
04:52:06 <Quartus> You're in the realm of the extremely impractical, where alternate better solutions exist.
04:52:36 <Quartus> An umbilical target compiler, for instance.
04:54:22 <Robert> It's a toy - don't expect too much from it. :)
04:55:09 <Robert> I guess that using a serial eeprom would be a better solution, though.
04:57:08 <Quartus> Probably.
05:15:56 --- join: rob_ert (n=robert@unaffiliated/robert) joined #forth
05:19:26 --- join: PoppaVic (n=pete@0-1pool66-29.nas22.chicago4.il.us.da.qwest.net) joined #forth
05:19:45 <PoppaVic> Mornin'
05:20:32 <rob_ert> Hi.
05:21:03 --- quit: Robert (Nick collision from services.)
05:21:06 --- nick: rob_ert -> Robert
05:21:24 <PoppaVic> incoming...
05:22:04 <PoppaVic> Splash
05:22:06 <Robert> The power went down. :(
05:22:24 <PoppaVic> Huh? Yesterday?
05:23:06 <PoppaVic> You should get email shortly
05:23:08 <Robert> No, right now. That's why I had to ghost Robert now.
05:23:14 <PoppaVic> ahhh
05:23:23 <Robert> Ah, got it. Thanks.
05:24:55 <PoppaVic> I think I'll plan to study-up some on Loeligers book, and plan to write an optable for the "pseudo-cpu" (vm).
05:26:26 <PoppaVic> The more I screw around with the opcodes and dither over "registers" in the VM, the more I believe that the lowest-level should reflect cpu-essentials.
05:37:56 --- nick: Raystm2 -> nanstm
05:55:40 * PoppaVic chortles
05:55:54 <Ray_work>  Good morning
05:56:00 <PoppaVic> ho-boy.. Getting together pseudoasm-opcodes is gonna' be amusing
05:56:06 <PoppaVic> mornin'
05:59:03 --- quit: aum ()
06:02:15 <PoppaVic> Trying to visualize/lay-out "asm" to use 8 bits for everything is gonna' be futile.
07:23:43 --- join: sproingie (i=foobar@64-121-2-59.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth
07:54:11 <PoppaVic> gah
07:54:38 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
07:54:50 <PoppaVic> Hi tathi 
07:54:58 <tathi> Hi
07:55:57 <PoppaVic> I'm trying to work-up a pseudo-assembler set of opcodes ;-)
07:57:13 <tathi> What do you mean?
07:57:59 <Robert> Hi.
07:58:07 <tathi> Hi Robert
07:58:38 <Quartus> Hi tathi.
07:58:56 <tathi> hail, hail, the gang's all here :)
07:59:37 <PoppaVic> tathi: well, I've about concluded we need to run a "universal CPU emulator" - and we will never give a damn who ports it where or how.
08:00:29 <sproingie> universal CPU emulator sounds like a VM
08:00:41 <sproingie> and back around we go to LLVM :)
08:00:48 <tathi> :)
08:00:50 <PoppaVic> thus, the users can write "asm" - and it never means more than our VM, right. What a compiler does here or there doesn't matter to us
08:01:38 <PoppaVic> Yeah, I know... *sigh* I was trying to skip the whole step - to satisfy everybody - and it just doesn't seem likely.
08:02:01 <tathi> You can never satisfy everybody.
08:02:12 <sproingie> there will always be mutant architectures that some instruction set doesn't map well to
08:02:15 <PoppaVic> Any other solutions either lead to a shitload of primitives, or a boarload of slow-secondaries
08:02:27 <PoppaVic> boar/boat
08:02:32 <sproingie> tho commodity cpu's aren't really so different
08:02:58 <tathi> Wait, an assembler is a program that runs on *top* of a processor.  You can't build it *into* your VM.
08:03:02 <sproingie> except for itanic.  VLIW.  that's a weird design.
08:03:07 <PoppaVic> sure I can
08:03:16 <PoppaVic> think about it...
08:03:34 <PoppaVic> yer "assembling" or "compiling" to a vaporCPU
08:03:54 <PoppaVic> all we care is that the codes are underwritten by the target
08:04:13 <sproingie> your terminology is confusing
08:04:27 <tathi> That doesn't make any sense to me.
08:04:35 <sproingie> if you have a vm, you have at least two program translators.  one targeting the vm, one targeting the cpu
08:04:40 <PoppaVic> sproingie: I'm sorry. I wish I knew how to clear it up - the whole thing is sorta' messy
08:04:52 <PoppaVic> right
08:05:16 <sproingie> what you call that translator is up to you, but usually it will be either a compiler or an interpreter.  in the case of forth that line is often very blurred
08:05:22 <PoppaVic> the pseudo-asm is just the "forget forth, think asm" opcodes-layer
08:05:49 * sproingie would tend to call forth interpreted for the most part
08:05:49 <tathi> so...you're adding opcodes that take their operands from registers, rather than from a stack?
08:05:52 <PoppaVic> we want the forthish layer to be able to dip into the pseudo-asm
08:05:57 <PoppaVic> right.
08:06:11 <PoppaVic> or "our registers", anyway
08:06:28 <tathi> right, registers of the VM.
08:06:33 <PoppaVic> exactly
08:06:44 <sproingie> this is something machine forth does with the A register
08:06:45 <PoppaVic> we have no interest in the underlying implementation
08:06:49 <sproingie> i think it's mforth anyway
08:06:57 <tathi> using "asm" for that is very confusing.
08:06:58 <sproingie> retro has it as well now
08:07:15 <PoppaVic> tathi: I agree, but "pseduoasm" is no better
08:07:24 <tathi> "assembly language" (to me at least) just means a human-readable (e.g. text) representation of the opcodes.
08:07:29 <sproingie> now retro uses every single visible register on ia32
08:07:38 <tathi> You can have asm for a forth chip as well as for a register-based chip.
08:07:52 <PoppaVic> right
08:08:25 <PoppaVic> translate our source or bytecode, and you can get a native-code source.
08:08:57 <sproingie> if it doesn't map 1-1 with the target, calling it asm is rather confusing.  IL or bytecode is probably a better term
08:09:07 <PoppaVic> And, it seems almost certain that xlating the bytecode is more efficient.
08:09:36 <sproingie> if you're looking for register based bytecode, you could try parrot
08:10:05 <PoppaVic> because we can RUN the bytecode, and folks can recompile or compile-native as required.
08:10:12 <tathi> And if you go to register-based, your instructions have to get bigger, because you have to encode operands as well as opcodes.
08:10:21 <sproingie> tho parrot rather exemplifies the second-system effect, being stuffed chock full of every idea they ever thought of
08:10:23 <PoppaVic> yep
08:10:43 <tathi> sproingie: yeah, parrot seems pretty crazy. :)
08:10:44 <PoppaVic> THis is why I'm hammering the 'opcodes'
08:11:02 <sproingie> at this point you're not really talking about a "universal glue abi" like before, you're talking about a VM
08:11:17 <sproingie> the VM is more an end of its own, the CPU is merely an implementation detail
08:11:24 <PoppaVic> I'm limiting us to 7 "registers", and not sure if any should be larger than a CELL
08:12:00 <tathi> I don't see why you want registers in the first place.
08:12:07 <sproingie> i guess i'm still trying to get a handle on what you're trying to actually do
08:12:22 <tathi> so is he :)
08:12:26 <PoppaVic> sproingie: well, from what I've been seeing: the prob is there is no optable/asm that deals directly with the VM - so the vm optables were ending up a mishmash of forthish and asmish
08:13:04 <PoppaVic> tathi: usually, that'd depress me. However, it seems to be so common it's sickening.
08:13:05 <sproingie> tathi: nothing wrong with a register VM.  personally i'd love to see what a forth-like language for a register machine looked like.  i remember running into a reason it was probably impossible though
08:13:29 <sproingie> tathi: something about not having any clear boundaries to determine the extent of a register's lifetime
08:13:50 <PoppaVic> I keep thinking that we want to EMULATE a cpu - so our forth can get above and below.
08:14:27 <PoppaVic> Most instances of forth seem to take at least as much work to port as C
08:14:28 <sproingie> PoppaVic: i mean overall, what are you trying to do?  write a VM, a universal FFI, a new forth?
08:14:35 <PoppaVic> "yes"
08:14:50 <sproingie> start somewhere.  a vm isn't a bad place to start
08:15:08 <PoppaVic> sproingie: I've run into so many issues over the decades, that I am trying to ascertain where the hell we can shove in a solution
08:15:27 <sproingie> solution to what problem exactly?
08:15:48 <PoppaVic> almost all of it is access/portable.
08:16:34 <PoppaVic> so, if we emulate a CPU and affect only that, then runtime or compiler: all they need is to interface the pseudo to actual - for real nativecode compiles.
08:16:56 <sproingie> a retargetable VM is a nice thing to have, yes
08:17:02 <PoppaVic> right
08:17:21 <PoppaVic> ANd, it would work for apps, shells, makes - whatever.
08:17:26 <sproingie> also good for writing languages themselves.  sometimes you don't need a full VM, just some abstract ops
08:17:34 <PoppaVic> Exactly.
08:17:39 <sproingie> e.g. almost all prolog implementations target a WAM
08:17:57 <sproingie> haskell targets an abstract virtual machine itself
08:18:22 <sproingie> neither of those get implemented as bytecode tho
08:18:35 <PoppaVic> prolly.. I can't see that the idea is unique. Just the bytecode/forth twists
08:18:46 <sproingie> so you don't necessarily need a fully blown standalone VM if all you want is to target a few portable concepts
08:19:00 <PoppaVic> right: link the lib and rock
08:19:51 <sproingie> for extreme portability, sure.  otherwise it's more like writing a DSL
08:19:55 <tathi> sproingie: yeah, I tried forth-like for register machine when I was about 16...it didn't work out so well.
08:20:03 <PoppaVic> Codify the meanings and xlates, let porters tweak the C or asm.
08:20:27 <tathi> but it isn't difficult to *compile* forth-like to register code.
08:20:35 <sproingie> tathi: damn ... when i was 16 i was just playing warezed games on my c64
08:21:19 <sproingie> tathi: yah, there's the rub, register machines don't lend themselves to ad hoc code generation
08:21:32 <tathi> sproingie: well, that was 1992, and we had an old 286-10MHz, which wouldn't run most of the games then.  So I didn't have much to do with it but program. :)
08:21:44 <sproingie> JIT sure, but callers and receivers aren't orthogonal anymore, they gotta agree on register allocation
08:22:23 <tathi> yup.
08:22:56 * PoppaVic goggles some
08:23:09 <PoppaVic> "callers"? "receivers"?
08:23:26 <tathi> callers/callees ?
08:23:36 <sproingie> pretty much.  loose terminology there
08:23:39 <PoppaVic> functions?
08:23:44 <tathi> the routine doing the calling/the routine being called
08:23:48 <PoppaVic> procedures?
08:23:49 <sproingie> what he said
08:23:53 <PoppaVic> ahh
08:24:20 <sproingie> one of forth's biggest strengths is how orthogonal its words are.  or can be anyway
08:24:29 <sproingie> at its best, it's a system of combinators
08:24:42 <PoppaVic> Yeah, the minute your code is no longer isolated - like dos/cpm - you are playing in a very large, dangerous pond.
08:24:55 <sproingie> or in the case of DOS, a very small pond
08:25:02 <sproingie> i guess cpm would be even smaller
08:25:16 <PoppaVic> well, I was thinking interrupts and reg-save/resore
08:25:36 <sproingie> well, that's the OS's job
08:25:50 <PoppaVic> they were more forgiving, but you HAD to understand stack-frames/abi
08:26:02 <sproingie> not to mention NEAR and FAR models
08:26:04 <PoppaVic> they were also a lot more limited
08:26:15 <PoppaVic> sproingie: for dos, not cp/m
08:26:19 <sproingie> i guess rf still has problems with "near jumps" vs "far jumps"
08:26:41 <sproingie> i.e. it doesn't do far jumps.  so if you have a loop inside a word that's more than 28 words long, You Are Screwed
08:26:47 <sproingie> lesson being to use recursion i guess :)
08:26:58 <sproingie> loop or a branch that is
08:27:10 <PoppaVic> I'm basically of the opinion that folks need to respect the underlying layers/system.
08:27:15 <tathi> anyway, I'm just skeptical about the value of a hybrid stack-/register-based VM.
08:27:27 <sproingie> eh.  that's what CPU's are
08:27:33 <PoppaVic> yep
08:27:45 <tathi> well, sure, you're not going to be totally pure.
08:27:46 <PoppaVic> Yer just adding one interface-layer to "hardware"
08:27:47 <sproingie> tho for a forth, having a bunch of regs doesn't count for much
08:28:33 <PoppaVic> right, for this effort I'm thinking of no more than 7 regs visible of CELL size, and maybe 1 inaccessible reg
08:28:49 <sproingie> what would you do with the inaccessible reg?
08:28:58 <tathi> seems like if you add registers, you lose some of the advantages of stack-based, specifically small instruction size and no "calling convention".
08:29:09 <PoppaVic> although "inaccessible" is a misnomer - it's for goto/jmp PC reg
08:29:52 <sproingie> gotta get going
08:29:54 <sproingie> later all
08:30:02 <tathi> later
08:30:29 <PoppaVic> tathi: there is no way in hell I can visualize a purely-stack CPU (or pseudo CPU), unless the stack is always frames-of-regs+locals
08:30:38 <PoppaVic> stay well, sproingie 
08:31:40 <PoppaVic> you need SOME regs. At least for tests/math
08:31:44 <PoppaVic> and flags
08:32:02 <tathi> in Forth, the flags usually go on the data stack.
08:32:12 <tathi> I admit you need a PC register.
08:32:23 <PoppaVic> oy
08:32:39 <PoppaVic> conditions
08:32:40 <tathi> Though if you really wanted to try, you *might* be able to get away with using the top of the rstack for that.
08:32:49 <PoppaVic> no,
08:33:13 <PoppaVic> I don't like bollixing the rs internally. It's bad enough we use it for gymnastics
08:34:06 <tathi> OK, so when you say registers, you're talking about things like the PC, condition register, etc.?
08:35:14 <tathi> Rather than general-purpose registers like most normal CPUs have?
08:35:30 <PoppaVic> right. I've concluded we need to just plain-old emulate a minimal CPU, to facilitate hard-ports. So, my regs are mostly (now) "our use", but we need one or 2 that are not DIRECTLY screwable.
08:36:42 <PoppaVic> I'm thinking of maybe seven "registers" that are 100% emulated. and treated just like asm would, although we'd save/restore our own porpoises
08:37:26 <tathi> and then your "asm opcodes" would be things like >reg reg> to copy them to the stack so that you can do things with them?
08:37:29 <tathi> or...?
08:37:31 <PoppaVic> I'm quite open to "registers" and "usage" - provided we are emulating.
08:37:39 <PoppaVic> right
08:38:07 <PoppaVic> wait a sec...
08:38:26 <tathi> ok.  you should probably just refer to them as "register" opcodes then... when you say "asm opcodes", I start thinking "add r3,r3,r4" and similar.
08:38:52 <PoppaVic> http://rafb.net/paste/results/EJnu9n61.html
08:39:10 <PoppaVic> see above, JUST the comment with binary-masking
08:39:31 <PoppaVic> starts on line 12
08:40:12 <tathi> I swear, one of these days I'm going to rewrite Lynx to support basic CSS...
08:40:21 <PoppaVic> hehe
08:40:45 * Robert usually uses links. Does that support css?
08:40:46 <PoppaVic> Let's get a good engine done, first ;->
08:41:06 <tathi> dunno.  It does tables though :)
08:41:26 <PoppaVic> links and w3m are tolerable
08:41:42 <PoppaVic> ..I prefer cranking safari or mozilla up
08:41:45 <Robert> Hmm...
08:41:51 <Robert> My page looks good in links
08:43:26 <PoppaVic> I already know my mapping breaks on the second section - double-byte codes
08:47:42 <PoppaVic> All we care about, today, is the binary-tables w/i the comment. I think we are cool therein
08:49:16 <PoppaVic> btw, {push,pop}iXXX would imply "indirect"
09:02:41 <PoppaVic> grocery-sidetracked
09:02:45 <PoppaVic> brb...
09:02:47 --- quit: PoppaVic ("Pulls the pin...")
09:04:16 --- join: PoppaVic (n=pete@0-2pool198-70.nas30.chicago4.il.us.da.qwest.net) joined #forth
09:04:35 <PoppaVic> Shwing!
09:17:40 --- join: virl (n=hmpf@chello062178085149.1.12.vie.surfer.at) joined #forth
09:19:15 <Robert> Hi.
09:20:45 <PoppaVic> howdy
10:32:10 --- join: snoopy_17 (i=snoopy_1@dslb-084-058-148-180.pools.arcor-ip.net) joined #forth
10:32:55 --- quit: Snoopy42 (Nick collision from services.)
10:33:04 --- nick: snoopy_17 -> snoopy42
11:05:37 <PoppaVic> OK, sans useless-snoops, tis time to cogitate dinner and a snooze. Laters
11:05:46 --- quit: PoppaVic ("Pulls the pin...")
12:10:15 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth
12:10:15 --- mode: ChanServ set +o JasonWoof
12:10:19 <Robert> Hi.
12:11:35 <JasonWoof> hi
12:21:32 <Quartus> Hey all.
12:22:04 <Quartus> Anybody know how Gforth handles return addresses?  I can't seem to do obvious return-stack manipulation with 0.6.2.
12:24:18 <Quartus> particularly,  : later  r> r> swap >r >r ;  is apparently a no-op.
12:27:21 <Robert> Works for me.
12:27:32 <Robert> I'm using 0.6.2 too.
12:28:37 <Robert> How are you testing it, and are you running the normal gforth binary?
12:29:03 <Quartus> I've tried all four gforth binaries.
12:29:14 <Quartus> Win32 version.
12:29:53 <Quartus> : later r> r> swap >r >r ; 
12:30:02 <Quartus> : (p ." <p>" later ." </p>" ; 
12:30:19 <Quartus> (p .( hello) later  -->  <p></p>hello ok
12:30:24 <Quartus> Not the desired effect.
12:31:03 <Quartus> Same under 0.6.1 on FreeBSD.
12:33:27 <tathi> weird.
12:33:40 <Quartus> And 'later' entered at the console does nothing whatsoever.
12:33:47 <tathi> AFAICT from a quick glance through the source, it looks like it does things normally...
12:34:18 <Quartus> tathi, is it not working for you too?
12:34:24 <tathi> testing now.
12:34:36 --- quit: virsys (Read error: 110 (Connection timed out))
12:35:22 <tathi> I'm getting the same result you are.
12:35:29 <Quartus> Robert, how about you?
12:35:59 <Robert> Yes, same here. But that seems normal.
12:36:15 <Quartus> It's not.  It should be producing  <p>hello</p>
12:36:24 <Robert> : foo (p ." hello" ;   ok 
12:36:24 <Robert> foo <p>hello</p> ok
12:36:38 <Robert> Yes, but not when interpreted.
12:36:53 <Quartus> Why not?
12:37:12 <Quartus> It works when interpreted in Quartus Forth, and in rf, as far as I can see.
12:37:36 <Robert> I think that depends on the implementation of the interpreter.
12:37:53 <Robert> But... I need to think about it.
12:38:33 <Quartus> It does indeed work in Gforth when compiled, as you say, but that restricts its usefulness quite a bit for me.
12:39:35 <tathi> Quartus: so the theory is, you call "(p", whose "later" returns to the interpreter, which handles ".( hello)", and then the final "later" goes back to finish "(p" ?
12:39:45 <Robert> How about creating a nameless word and executing right away?
12:39:52 <Quartus> tathi, Yes.  Works like a charm in Quartus Forth.
12:40:16 <Quartus> Robert, sure, but that's clumsy as hell.  I'll have to give up on the charm of 'later' and build a small tag stack instead.
12:41:06 <Robert> Hm, I bet it could be done cleaner.
12:41:15 <Quartus> Cleaner how?
12:42:07 <Robert> Maybe if you define   (p  as {p,  and also make it create a noname: definition, and then you make  }  equivalent to  "; execute", so you'll get something like   p{ b{ ." bold" } ." nonbold" }
12:42:26 <Robert> I admit that's just giving it a better syntax, but if it works...
12:42:31 <Quartus> Robert, maybe. Fills the dictionary and adds to the overhead, and you have to remember you're compiling and not interpreting.
12:43:13 <Quartus> A tag stack will let me work while interpreting, just as 'later' does under rf and Quartus Forth.  I wonder what odd thing Gforth does that prevents it.
12:44:48 <Quartus> Maybe it's the whole 'separate wordlists for compiling and interpreting' thing.
12:45:27 <Quartus> Though I can't think how that would mess it up, really.
12:45:55 <Quartus> Maybe every EXECUTE in the Gforth interpreter is actually a CATCH?
12:46:51 <Robert> I guess an easier thing in this case would be to not use "later" at all, if you want to keep interpreting.
12:46:53 <tathi> hrm, I don't understand how it would work in the interpreter.
12:47:02 <Robert> Or use MARKER to clean up the headers.
12:47:43 <tathi> if the interpreter does (basically) ' (p EXECUTE
12:48:08 <tathi> argh, hang on, now I'm confused. :)
12:48:46 <Quartus> Robert, using MARKER adds still more overhead, of course.  It's ok, I can exactly duplicate the functionality with a tag stack, but I kind of liked 'later'.
12:49:35 <Quartus> Tathi, it works like a champ in rf8.
12:50:10 <tathi> ok, here's what I don't understand.
12:50:21 <tathi> later simply swaps the top two rstack elements.
12:50:38 <tathi> so if anything returns twice, the second return will go back to (p, won't it?
12:51:03 <Quartus> Remember calling later puts a new return address on the stack, first.  That's what later swaps with the earlier one.
12:51:32 <tathi> right.
12:52:19 <tathi> but say the interpreter does ' (p EXECUTE.
12:52:41 <tathi> then when we get to later, the return stack has an address in (p and an address in EXECUTE.
12:52:56 <tathi> later swaps them, and returns to the end of EXECUTE
12:53:04 <tathi> which immediately returns again, to (p
12:53:11 <tathi> or am I missing something?
12:53:43 <Quartus> You're assuming EXECUTE is a subroutine, and not a couple of inline instructions in the interpreter loop. That's probably the whole difference here.  In Quartus Forth  the interpreter's EXECUTE  jumps to the address, so there isn't an extra address on the return stack.
12:54:08 <Quartus> At a guess, Gforth's interpreter EXECUTE is being called as a subroutine, so it nests.
12:54:19 <tathi> yeah, that's what it looks like from the gforth source.
12:54:49 <Quartus> Sloppy and unnecessary; if you jump instead of call you save a step.  I guess optimizing the interpreter wasn't high on the list.
12:55:15 <Quartus> rf must jump, too.
12:55:29 <tathi> but still, more generally - LATER only works at interpret-time if words are executed from the top level of the interpret loop.
12:55:37 <Quartus> Right. Which I'd expect.
12:55:37 <tathi> if they're executed from a subroutine for whatever reason, it will fail.
12:55:51 <tathi> hmm.
12:56:02 * tathi goes to look at his forths and see how they work...
12:56:13 <Quartus> Maybe with this in mind I can code up an interpreting-later that will work with the other one.
13:02:21 <Quartus> I'm getting confusing results as I experiment with Gforth. The theory may not be correct.
13:03:05 <tathi> quite possibly :)
13:03:54 <Quartus> I think there's a CATCH frame in the way.
13:06:29 <Quartus> Ok, that's what it is.  If I write my own interpreter loop that uses EXECUTE, it works properly.
13:06:55 <Quartus> In fact there's the CATCH lurking in QUIT.
13:07:57 <Quartus> That strikes me as a bizarre implementation.  I'd expect one CATCH outside the whole interpreter loop.
13:15:11 <Quartus> Ok, it is one CATCH outside the whole loop.  Something else is... looks like the EXECUTE is at least two levels down.  God, I hate poking through other people's undocumented code.
13:16:19 <Quartus> It's one CATCH outside 'quit, which is called in a loop by QUIT, so I think there's a CATCH frame in the way *and* more than one nesting before you get to EXECUTE.
13:16:37 <Quartus> But don't quote me. :)
13:23:05 <Quartus> Ay carumba! Time to stop trying to read that source.
13:41:59 <Pepe_Le_Pew> caramba
13:42:07 <Pepe_Le_Pew> aya caramba ! madre de dios !
13:58:10 <Ray_work> Quartus: I didn't mean it. I didn't intend your frustration, but I'm glad you like the word. I also liked it instantly.
14:34:38 <Quartus> It's a neat solution, but unworkable in Gforth thus far for me.
15:47:45 --- nick: nanstm -> Raystm2
15:48:37 <Raystm2> I havn't tried it in Gforth and will soonest.
15:50:09 <Quartus> If you read the above, it only works inside a definition.  I've done an end-run and built a small tag stack, it's just as useful for this.
15:55:25 <Raystm2> Excellent!
16:30:33 --- quit: crc ()
16:31:46 --- join: crc (i=crc@pool-70-110-221-244.phil.east.verizon.net) joined #forth
18:00:51 --- quit: tathi ("leaving")
19:06:53 --- join: slava (n=slava@24.43.80.35) joined #forth
19:27:59 <Raystm2> Quartus I have tested later in gforth and it works. 
19:28:25 <Raystm2> I wonder what test you used?
19:28:57 <Raystm2> : later r> r> swap >r >r ;
19:29:06 <Raystm2> : foo 1 . later 3 . ;
19:29:21 <Raystm2> : bar foo 2 . later 4 . ; 
19:29:29 <Raystm2> bar
19:29:33 <Raystm2> 1 2 3 4 ok
19:39:54 <Quartus> Try it interpreting.
19:40:19 <Quartus> : (p ." <p>" later ." </p>" ;
19:40:26 <Quartus> (p ." hello" later
19:40:35 <Quartus> Under Quartus & rf, that displays       <p>hello</p>
19:50:21 <Quartus> Under gforth,         <p></p>hello
20:29:22 --- part: slava left #forth
21:58:19 --- quit: sproingie (Remote closed the connection)
22:27:47 --- quit: virl (Remote closed the connection)
22:53:43 --- join: neceve (n=Clau@unaffiliated/neceve) joined #forth
23:02:55 --- quit: JasonWoof ("off to bed")
23:59:59 --- log: ended forth/05.10.04