00:00:00 --- log: started forth/03.12.18 01:07:37 --- join: junk___ (~junk@njd.paradise.net.nz) joined #forth 01:08:13 --- nick: junk___ -> njd 01:14:19 --- join: schihei (~schihei@pD9548CEB.dip.t-dialin.net) joined #forth 01:26:07 --- quit: junk__ (Read error: 110 (Connection timed out)) 01:30:04 --- quit: Serg_Penguin () 01:54:34 anybody awake? 02:16:31 Yes 02:33:42 sup Robert? 02:34:16 I'm...awake. 02:34:18 And away 02:34:57 away? 02:37:30 Away. In bed, reading. 02:38:47 thats what laptops are for. 04:33:21 --- quit: fridge (Remote closed the connection) 06:18:24 --- join: I440r (~mark4@saturn.vcsd.com) joined #forth 06:22:57 --- join: oooo__ (o@virgo.bombsquad.org) joined #forth 06:25:33 --- quit: oooo_ (orwell.freenode.net irc.freenode.net) 06:25:33 --- quit: mur (orwell.freenode.net irc.freenode.net) 06:25:46 --- join: oooo_ (o@virgo.bombsquad.org) joined #forth 06:25:46 --- join: mur (~mur@uiah.fi) joined #forth 06:26:13 --- join: mur_ (~mur@uiah.fi) joined #forth 06:35:37 hi 06:35:43 hmmm 06:35:58 --- quit: oooo_ (Read error: 104 (Connection reset by peer)) 06:40:16 --- quit: mur (Read error: 110 (Connection timed out)) 06:40:27 --- nick: mur_ -> mutr 06:40:30 --- nick: mutr -> mur 07:58:50 brb 07:58:52 --- quit: I440r ("Leaving") 08:06:28 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 08:06:28 --- mode: ChanServ set +o kc5tja 08:12:53 --- join: I440r (~mark4@saturn.vcsd.com) joined #forth 08:27:08 --- quit: clog (^C) 08:27:08 --- log: stopped forth/03.12.18 08:27:23 --- log: started forth/03.12.18 08:27:23 --- join: clog (nef@bespin.org) joined #forth 08:27:23 --- topic: 'A channel dedicated to the Forth programming language, its implementation, its application, and its philosophy.' 08:27:23 --- topic: set by kc5tja on [Fri Dec 12 07:57:32 2003] 08:27:23 --- names: list (clog I440r @kc5tja mur oooo__ Robert hovil tathi schihei njd Herkamire onetom OrngeTide wUoNrFk ianp chandler warp0x00 madgarden skylan @ChanServ TreyB MysticOne) 09:18:52 --- join: MrReach (~mrreach@209.181.43.190) joined #forth 09:18:52 --- mode: ChanServ set +o MrReach 09:18:52 --- quit: Herkamire (Read error: 54 (Connection reset by peer)) 09:19:06 hihi! 09:19:40 hey 09:24:19 hi mrreach! 09:24:22 lol 09:24:25 ltns :) 09:24:32 greets, no so long 09:24:36 you testin yer clients ctcp :)O 09:24:53 how goes it 09:24:58 just wondering if you were even in the building where your client was idle 09:25:05 quite well 09:25:19 im at work trying to fix a stack error :P 09:25:32 stack undreflow and im not seeing it :/ 09:25:44 ill put some dummy values on the stack and see who eats one 09:25:49 I finally bit the bullet and started writing a P4 dis/assembler w/ linker 09:25:55 yea ? 09:26:01 thought you'd like to know 09:26:09 eax #1 mov or "mov eax, #1" 09:26:17 or "either" 09:26:21 reverse polish, of course 09:26:24 lol 09:26:29 1 # EAX MOV 09:26:41 ill be able to fix that and maybe use it :) 09:26:47 withy full credits and permission that is 09:26:54 did i send you my 8051 assembler ? 09:26:54 ' someword >DFA [] EAX MOV 09:27:04 dfa ? 09:27:11 data field address 09:27:19 ' >body ? 09:27:32 i thinbk dfa is more inline wiht nfa cfa etc :) 09:27:40 lots of segments, so have to move around (in the target environment i'm planning to use this for) 09:27:40 pfa ? 09:27:52 exactly why I used that name 09:28:20 can you accept dcc ? 09:28:32 NFA = dictionary, CFA = machine code, DFA = memory loc of CREATEd word 09:28:41 not sure, go ahead and try 09:29:04 offering... 09:29:16 accepted 09:29:34 doesnt seem to be moving :/ 09:29:47 failed ... mrreach@bigfoot.com 09:29:51 ok 09:30:28 I'm writing one directly compilable for both windoze and linux 09:31:00 STC with code-copying and primitive peephole optimising 09:31:36 I'm betting that you'll LOVE working on the optimiser 09:31:46 (if I ever get that far) 09:32:54 sent it - might get it twice 09:33:01 ok, thanks 09:33:22 it would be an interesting experiment - but i wouldnt want it for a production run :)\ 09:33:31 why is that? 09:33:59 you lose SEE - i point you in the direction of swiftforth/swiftx for a classic example 09:34:08 you lose the 1:1 corelation between source and object 09:34:21 thus losing the predictability of the compiler 09:34:22 yep, I remember you making that observation last year 09:34:41 it makes it impossible to do certain things in the code - i.e. it restricts what you can and cant do 09:34:54 hmmm ... like what? 09:35:36 heh, you can always turn the optimiser off, or use a CODE or INLINE definition 09:36:56 correct 09:37:27 but i would disagree with anyone using no optimizations during develop turning them on for production if they said the two ran identcally 09:37:42 oh, quite so 09:37:55 however some day i may make an optimizer for isforth 09:37:57 most software houses use test suites 09:38:01 so my users have that option 09:38:33 heh, if you go to Intel site, they have "VTune" ... 09:38:54 lol, ya 09:38:58 which is supposed to exercise every single control flow branch in C and C++ programs 09:39:25 an impressive bit of software, but can't imagine how it would work effectively 09:40:37 or usefully :P 09:41:11 anyway, today I'm fighting with myself about the assembler syntax 09:41:31 make it as close to intel syntax as you can :P 09:41:35 thats my take on it :) 09:41:45 yep 09:41:56 been reviewing NASM syntax 09:42:19 much cleaner than MASM/TASM 09:42:47 heh, there's a "Dr. Dement" who does sleep studies ... how ironic 09:43:13 lol 09:44:37 you're writing for 8051 now? 09:44:54 on a PC host? 09:45:39 the assembler is mine - im developing an umbilical 8051 compiler for thge Cygnal line of controllers 09:45:41 its almost done 09:45:54 i have a non umbilical version of it already where the target itself does the compiling 09:45:56 cool 09:46:12 what does it use for mass storage? 09:46:13 cygnal is awesome, you can run code out of flash while erasing or programming flash 09:46:21 flash - they all have flash 09:46:26 ok 09:46:32 100 thousand writes typical 09:46:39 20k minimum 100k typical 09:46:53 yep, got a flash card for my PDA 09:46:59 quite amazing 09:47:23 PDA sucks, the flash card is awesome 09:47:31 lol 09:48:34 what p[rocessor in the pda ? 09:48:52 SH3, runing at 10Mhz (I think) 09:49:03 do a forth for it :) 09:49:05 I don't have probs with the mup 09:49:11 been thinking about it 09:49:39 it's getting data into/outof the damn thing that is the problem 09:49:44 if i ever got a pda it would be to do a forth 09:49:57 code on pc - put code on flash 09:50:02 put flas in pda.... 09:50:09 oh, it syncs ok 09:50:24 next I'll get one with a keyboard 09:50:38 (I bought a floding keyboard for this one ... it's so-so) 09:50:58 floding = folding 09:51:06 Hey MrReach :) 09:51:12 greets, Robert 09:52:08 My Forth already produces native code via subroutine threading and peephole optimizing. 09:52:28 And it has a 1:1 source to object code mapping. 09:52:30 kc5tja: I'm interested ... what platform? 09:52:41 There is precisely one object code sequence for one source code sequence. 09:53:00 Linux 09:53:13 does it meta-compile? 09:54:18 kc5 the object for "dup tuck blah" depends on the optimizer 09:54:39 thats a bad example 09:54:40 MrReach: Not yet. FS/Forth itself doesn't exist; only its bootstrapping target compiler. 09:55:02 I440r: Your whole argument is invalid. 09:55:28 I440r: I use Chuck's code production engine, which he himself asserts there is a precise, 1:1 code to object code relationship. 09:55:33 kc5 i dont think it is - any time ive worked with code thats compiled with an optimizing compiler its been way more difficult to debug 09:55:45 almost impossible to decompile for a start 09:55:50 And as far as using more sophisticated optimizations on program code and saying they don't run identically, that's correct; the latter runs better. 09:55:51 use see in swiftx 09:55:53 useless 09:56:00 I have, and I had no problems iwth it. 09:56:14 I don't **WANT** the system to store the source code. 09:56:17 I want it to store the executable. 09:56:22 SOurce code is the job of source files/blocks. 09:56:23 erm try using see on a word that has a ." in it - it disassembles the text 09:56:37 it doesnt heven have the smarts to know where the compiler inserts a dotquote 09:56:39 I440r: No kidding. 09:56:52 isforth doesnt have that problem 09:56:55 It doesn't have to have the smarts. 09:56:59 It's a nonproblem. 09:57:00 see WORKS in isforth 09:57:05 i disagree 09:57:07 See this. 09:57:08 See that. 09:57:09 See what? 09:57:11 who cares? 09:57:14 It's a non-issue. 09:57:18 being unable to see something is very annoying 09:57:25 its a usefull tool except in swiftx 09:57:36 I disagree. 09:57:40 fine 09:57:41 whatever 09:57:47 When I want to know the source fo XYZ, I look at the block that contains XYZ. 09:57:49 It's not an issue. 09:58:14 Criminey, I paid $1000 for my computer when I got it. I want to *use* it. 09:59:12 err say again in english ? 09:59:27 heh 10:00:22 I paid $1000 for a CPU that runs very fast. But without optimization, I can't use that performance. 10:01:15 erm that really does sound like a weak arguement - optimizing CODE does almost NOTHING - optimize your algorithms 10:01:23 write me a compiler to optimize my algorithms 10:01:30 then ill agree with you 10:02:12 while we're making unrealistic demands of people, give me $10,000 while you're at it. 10:02:23 NOW 10:02:39 I440r: Optimizing algorithms are important. 10:02:53 thats the only way your going to get significant gains in your code 10:02:54 But when you've already optimized your algorithms, and there's nothing left to optimize, code is all you have. 10:03:02 I440r: No shit, sherlock. 10:03:13 not the ONLY way 10:03:15 a heavilly optimized bubble sort is going to be out performed by a totally crap shell sort 10:03:15 I didn't invest 15+ years of my life to not figure that out by now. 10:03:20 and shell is but ONE up from bubble 10:03:44 Now you're blowing the argument so far out of reality that you're showing just how horrifyingly ignorant of the situation you really are. 10:04:05 * MrReach laughs 10:04:06 If I were implementing a sort routine, NO SHIT I wouldn't use Bubble. DUHH! 10:04:13 ok well your resorting to personal flames 10:04:27 Because you're insulting my intelligence. 10:04:29 ok you use quick sort and optimize it to hell and back 10:04:36 cry me a river 10:04:44 ill use a radix counting and do 100 milluonh sorts on the same data in the time it takes you to do it once 10:05:02 Umm...yeah. Right. 10:05:07 no - just your opinion 10:05:22 your taking my opinion as a personal insult 10:05:25 thats NOT my fucking problem 10:05:47 I440r: No. You're claiming that I'm so stupid that I'd favor code optimization over algorithm optimization as a first step. And that's patently wrong. Despite claims to the contrary you continue to stick to that argument, over and over and over again. 10:06:04 All just because I favor the use of code optimization. 10:06:05 i personally do NOT want #forth to turn into just another clf where if anyone expresses an opinion they get PERSONALLOY flamed 10:06:22 thats like a c coder taking forth code as a personal insult 10:06:24 duh 10:06:33 * kc5tja notes I440r is way off on yet another tangent. 10:06:46 If you can't stick to the core of the argument, don't argue at all. 10:06:50 your the one using smoke and mirror arguements not i 10:06:58 I440r: no, you're the one missing the point 10:07:11 Smoke and mirror? I invite you to prove me wrong on **ONE** thing I said. 10:07:21 the point is i dislike optimizing compilers and i think a non optimizing compiler is easier to use 10:07:27 Obviously the first step is to choose the right algorithm for the job. 10:07:30 kc5 turned that into a flame war 10:07:44 tathi pick an algorithm to solve a problem 10:07:45 But _after_ you do that, there's still plenty of room for _code_ optimization to speed things up. 10:07:52 thers ALWAYS a better one 10:08:11 and for a sort i would never personally pick quicksort 10:08:15 I440r: Look back in the logs. You argue that optimizing compilers are inappropriate for production code, on the sole basis that it won't let you SEE the code you put in. I claimed it was a non-issue, because you have original source to begin with. 10:08:35 no. i said "i would never use one" not" nobody should" 10:08:44 your the one twisting the4 arguement and redirecting it 10:08:46 not me 10:08:52 mmhmm. 10:09:08 ahh. whatever. 10:09:37 actually, I440r, you said you wouldn't trust it for suddenly turning on before shipping out the door 10:09:52 not 100-% 10:10:22 i wouldnt trust it to work absolutely identical to the unoptimized code 10:10:28 He also hinted at the fact that optimized code didn't run "the same" as non-optimized code. 10:10:34 that'fine 10:10:52 it supposed to, but sometimes doesn't 10:10:56 kc5 has obviously never seen code that works when not optimized but breaks when it is or vice versa 10:10:58 i have 10:11:08 But in fact, optimized code does run "the same" -- if it takes the same inputs (of which I consider the state of all memory an input), and produces the same outputs, then by definition, it must run the same. 10:11:18 but then, you can always develop/test with the optimiser on 10:11:39 I440r: I absolutely have. And that proves the optimizer is broken. But that does **NOT** prove that optimized code is not equivalent to unoptimized code. 10:11:43 and that make development time testing more difficult 10:11:58 because I have **ALSO** seen code that **DOES** run the same between optimized and unoptimized code. 10:12:09 kc5 ALL optimizers will exhibit this behaviour with the right (wrong?) code 10:12:18 I440r: Nope. Not in my experience. 10:12:32 I've put basic and really gnarley code through C optimizers, and they all produce proper code. 10:12:36 kc5 has tested all optimizers he has ever used for every possible condition 10:12:40 ok i stand corrected 10:12:51 I440r: You are twisting the argument. I never said that and you know it. 10:13:16 But here's the deal: you cannot prove that optimized code is bad on the basis that the optimized code runs differently than the unoptimized code. 10:13:21 i stand by my statement. any optimizer will be broken for some given source 10:13:21 -O3 in gcc has produced incorrect code for me. but -O3 is known to be experimental. 10:13:27 you said not in your experience 10:13:32 Just because you had ONE bad instance of ONE buggy optimizer does NOT mean that the whole concept is condemned to hell for eternity. 10:13:56 lol thats not my only objection to optimizers 10:14:02 in fact its the LESSER objection 10:14:22 i trust compiler writeres have advanced since then 10:14:24 So far as I've read, that's **THE** crux, the sole driving point, to your whole argument. 10:14:31 but optimized code is more difficult to debug 10:14:39 noooo 10:14:41 read again 10:14:43 Again, I haven't suffered this liability. 10:14:46 but optimized code is more difficult to debug <-- that is 10:14:52 -O2 on 2.95.3 has never produced bad code for me. and I've gigabytes of code through it. 10:15:00 You trust code by building from first concepts. 10:15:14 nbeway its lunch time 10:15:15 Once you've established the correctness of lower-level code, you work on towards higher level code. 10:15:17 neway 10:15:32 back in half an hour 10:15:36 As long as you stick to that, you can't go wrong. Debugging becomes trivial then. 10:15:52 oh - DO scroll back, you will see i DID say that someday i will MAYBE write an optimizer for isforht 10:15:54 buggy optimizers don't bother me. because they will get noticed if you have a *complete* test plan. which you should. 10:15:57 I've never, ever, ever had -O3 produce bad code for me. 10:15:59 for YOU to use if YOU so chose 10:16:02 (on x86 platform, 2.95 or 3.2) 10:16:28 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 10:16:35 kc5tja: yea. I have. it's pretty rare but -O3 can fail. at taht point I go on bugzilla and submit a bug:) 10:16:44 the price I pay for using open source. 10:16:48 I've never, ever been in a situation where a program ran so poorly I considered using -O3 10:17:14 hovil: I rarely use -O3. I only use -O3 on code that iterates through lots of data, processing as it goes. 10:17:14 hovil: I run -Os a lot. which is everything in -O3 except things that make it bigger. it produces some pretty tight executables. 10:17:29 really if the compiler can optimize you might as wel take advantage of it, it's free 10:17:42 E.g., I'll use -O3 -fomit-frame-pointer -march=athlonxp for my box, when building multimedia applications, for example. 10:17:46 -O0 (no optimization, the default) produces pretty sad code. 10:18:05 * kc5tja is happy to point out that FS/Forth's software runs subtly faster than -O0. :D 10:18:13 Using nothing but subroutine threading. 10:18:22 (and primitive inlining, but no peephole optimization) 10:18:24 I build with -march=i486 (or better) on all applications. It important to have access to instructions like bswap and cmpxchg 10:18:38 kc5tja: how does/will fs/forth spit out executables? 10:18:40 Pentium has bswap and cmpxchg. 10:18:57 hovil: I ripped the idea of generating a statically linked ELF header for I440r's isforth. 10:18:58 kc5tja: i486 has bswap. pentium has cmpxchg 10:19:06 but i ment to type i586 :) 10:19:11 s/ment/meant 10:19:14 geez I can't type 10:19:15 FS/Forth and isForth represent two diametric opposites of philosophies. (As you probably already got) 10:19:52 OrngeTide: Well, Athlon is Pentium compatible. :D But I find there is a noticable performance difference when I compile -i686 and -march=athlon. 10:20:14 kc5tja: yea. i'm not using athlon though. :) 10:20:42 * kc5tja knows. I'm just saying that mere instruction ordering and register allocation techniques can make or break an application's real-time performance requirements. 10:20:58 sure. well there is -mtune as well. 10:21:11 ? I wasn't aware of that. I'll have to read up on that. 10:21:23 I *would* like to figure out how to use its profiling support though. I tried several times in the past, and failed every time. 10:21:33 It'd compile, it'd run, but it wouldn't generate any useful reports. 10:21:34 -march=i386 -mtune=athlon is good for making linux distros. then they still run on some old 386. 10:21:45 * kc5tja nods 10:22:34 optimizers are complex and full of blackmagic. i really wouldn't like to write one. :P 10:23:05 I would. 10:23:18 i'd rather do some real work. 10:23:19 me too 10:23:20 Because I feel that optimizations are, contrary to what Intel and AMD both think, *NOT* black magic. 10:23:38 peephole optimizers aren't blackmagic. 10:23:43 I patently and firmly and vehemently disagree with the whole concept of documentation too large and too complex for public consumption. 10:24:14 * kc5tja has intentions to explore global optimization of Forth code, similar to what RAFTS has done, but employing dataflow analysis and maybe even a bit of type inferencing to help out. 10:24:30 now more optimizing forths would be nice. 10:24:55 sometimes i feel like forth is stuck in the 80s. 10:24:56 bigForth uses RAFTS as its optimization engine, and it routinely falls in the same ballpark as gcc -O3. I'd say that's a nice treat!! 10:25:18 I just don't like bigForth because it's ... big. :) 10:25:19 tell me about the optimiser, OrngeTide, been thinking about it for a week 10:25:45 MrReach: it's kc's optimizer. 10:26:03 My optimizer works by agglutination. 10:26:22 When the compiler sees 56, it compiles the code for DUP, then loads EAX with 56. 10:26:44 OrngeTide: that was in regard to your "I'd rather do real work" statement 10:26:45 When it sees +, it realizes, "Hey, I just pushed a literal on the stack," so it ALLOTs by a negative amount, and re-compiles "ADD EAX,56". 10:27:05 When it sees @, it realizes, "Oops! I know I just emitted an ADD instruction," so it recompiles "MOV EAX,[EAX+56]" 10:27:06 etc. 10:27:21 me nods 10:27:30 The end result is that it collapses large series of instructions into a single CPU instruction. 10:27:46 that's close to what I'm planning, but I'm not gonna be as high-level 10:28:01 MrReach: well I don't believe writing compilers, optimizers, etc. is for me. I'd rather write something that directly affects real people. rather than something that could only be appreciated by other programmers. 10:28:17 This technique is of course self-limiting. There are ways to generate code that the optimizer can't agglutinate. 5 + dup drop @ will defeat the optimizer easily. 10:28:32 But probabalistically, it'll produce very nice code. 10:28:53 colon starts compiling JSRs, if the target word is small enough, it copies its code into the current def (unless the 'no-inline' bit for that word is set in the dictionary) 10:28:56 I know that the code my target Forth produces is easily already at half the speed of gcc's *best possible* output by employing this technique. 10:29:23 semicolon finishes up the def, then calls the optimiser on it 10:29:57 My RAFTS-inspired optimizer will work by building a complete dataflow graph of the software in memory first. 10:30:22 It won't actually compile anything to code until a word is actually needed, whereby a global analysis is performed to optimize everything as much as it possibly can. 10:30:24 kc5tja: yea. i've been thinking about optimizing pushing literals (especially CONSTANTs). if you keep the top stack element in a register (which isn't hard). you should be able to notice a PUSH and a POP nearby one another and remove them, leaving the code to set the top stack register. *shrug* 10:30:29 the optimiser steps one instruction at a time, running a series of rules, like "if-looking-at ... then do ..." 10:31:23 OrngeTide: simply removing a PUSH/POP will cause errors 10:31:24 OrngeTide: Yep. It's a very simple optimization trick. It's still not the best possible code, but it does make a huge impact on performance. I know my code is at least three times faster than gforth's best possible configuration in most cases, and much, much faster in other cases. 10:31:33 ooops 10:31:35 Exact numbers will be forthcoming as the compiler is completed though. 10:31:45 well good forth code has a lot of factoring. so i'm not so sure optimizing at the scope of : to ; would yield very good results 10:31:47 OrngeTide: simply removing a POP/PUSH will cause errors 10:31:56 MrReach: no. it won't cause errors. 10:32:03 OrngeTide: Precisely why my RAFTS-inspired optimizer will do global optimizations. 10:32:23 yes, it needs to change to MOV EAX, [EBX] 0 10:32:27 yes, it needs to change to MOV EAX, [EBP] 0 10:32:49 so that the TOS register is changed 10:33:03 It'll examine data flow from everything. Words that are used relatively infrequently AND which are obscured by later definitions, will almost certainly be inlined. :) 10:33:10 5 6 + .. that will look like PUSH T ; MOV T, 5 ; PUSH T ; MOV T, 6; POP X ; ... 10:33:21 (and in the case where your definitions are short, one-line definitions, that's usually the case) 10:33:21 that was a pretty serious error in Tom Almy's TCOM for a long time 10:33:25 the PUSH T ; MOV T, x ; POP .. is the key. 10:34:22 I'd read the RAFTS papers ... very impressive 10:34:35 Yep. 10:34:35 more than i want to get into right now 10:34:39 * kc5tja nods 10:34:40 Ditto here. 10:35:03 brb (food) 10:35:25 * kc5tja also wants to explore an even deeper machineForth implementation for x86 Linux, where all data stack elements are kept in registers (since 6 are available, this imples a 6-deep data stack). 10:35:35 Just for fun and research more than anything else. 10:35:42 And who knows? It might yield some interesting surprises. 10:36:17 Words like SWAP and OVER become compiler state changes at this point, as no real register manipulations need occur in emitted object code. 10:36:27 How would that be implemented? 10:36:27 Without having to move tons of registers every time. 10:36:27 Should prove useful for words that operate on vectors. 10:36:46 You only canonicalize the registers on basic-block boundaries. 10:37:07 A basic block is defined as the longest contiguous series of instructions that (a) is not the target of a branch, and (b) does not itself branch. 10:37:16 6 available? 10:37:24 EAX, ECX, EDX, EBX, ESI and EDI. 10:37:34 ah! 10:37:36 EBP would be data stack, and ESP the return stack, so those are "in use" at all times. 10:38:01 Well, in my Forth, I use ESI as the data stack pointer, so I would instead use EAX, ECX, EDX, EBX, EBP, and EDI. :D 10:38:08 But you get the idea. 10:38:09 Robert: http://dec.bournemouth.ac.uk/staff/pknaggs/thesis/chap-5.ps 10:38:26 tathi: What is that? 10:38:34 Robert: the 4 top stack items are kept in registers ... 10:38:39 but ... 10:38:54 each item is not assigned a specific register 10:38:55 you could probably do most of it by simply tracking which register is the "top" statically, at compile time. 10:38:58 thing about keeping stack items in registers 10:39:04 Oh. 10:39:11 when a register expires, it is filled with new stack item 10:39:12 OrngeTide: Precisely. 10:39:13 there would be cases that wouldn't work. and then things get complex. 10:39:23 Though, it's better to let each register have its own stack binding. 10:39:36 but for nearly all your "normal" stuff it'd work out quite nicely. 10:39:53 OrngeTide: and when calling a subroutine, when the registers need to be dumped to stack o(or somewhere) 10:40:02 * kc5tja notes that this kind of optimization is the core of most Forth native code optimizers anyway, so it's useful research for me no matter how you look at it. :) 10:40:26 but you'd want to do some pretty heavy inlining. since there could be up to 6 possible permutations of the compiled version of every word. 10:40:41 peephole can use registers pretty effiently 10:40:50 my forth sucks, it doesn't do any of this. :P 10:41:06 OrngeTide: Even so, looping within the word still requires canonicalization fo registers. 10:41:16 --- quit: Herkamire (Read error: 104 (Connection reset by peer)) 10:41:26 but it has problems in scheduling the multi-execution pipelines 10:41:46 MrReach: All Forths except thsoe that use dataflow graphs to optimize have this problem. 10:41:54 s/thsoe/those/ 10:41:54 kc5tja: yea. you usually don't enter a loop with more than a couple items on your stack. so saving them wouldn't hurt you that much. 10:41:57 Hmm.. seems like a neat idea. But not as good as getting a real machineforth CPU. :) 10:42:16 Robert: Well, of course. That's a given. But we can only work with the tools we're given. 10:42:25 Unlike Chuck, we don't have $100K to fab a new chip whenever we wnat. 10:42:26 want 10:42:29 and pieces within the loop that have 0 difference between stack-in and stack-out could use the register trick. 10:42:31 Damn, I can't type today either. 10:42:32 kc5tja: Exactly :) 10:42:36 kc5tja: Heh 10:42:53 just buy an F21 :) 10:43:17 OrngeTide: No. Not only are they no longer in production, Jeff Fox is charging an immense amount for an F21 to help recover costs. 10:43:20 is anyone selling F21s? I know MuP21 is available.. but i wouldn't want that 10:43:25 Last price he quoted me for one was something like $250. 10:43:31 yow 10:43:33 yeah, with the 2000MIPS video card, and the 5.1 surround sound, etc 10:43:56 Is the MuP21 still in actual production? 10:44:00 I don't think that is either. 10:44:21 for $250 i could get a xess.com board and put a stack computer in an FPGA. the board has PS/2 keyboard and VGA jacks too so it could actually be fun:) 10:44:25 according to MPE, they just brough back the RTX2000+ this last month 10:44:46 you can still order MuP21 afaik. but it's not being produced anymore. 10:44:54 Yeah, I've always wanted to build a stack CPU in an FPGA. 10:45:01 * kc5tja is pretty sure he could get some good performance out of it. 10:45:08 my friend got one a couple years ago. it took him forever for it to work. there are a lot of undocumented fixes you need to do to it. 10:45:14 hell with that ... I'm writing for PC hardware 10:45:29 I'll write for Macintosh if someone wants to give me one 10:45:29 PC hardware sucks. 10:45:45 Mac hardware is the same as PC hardware now-a-days. 10:45:46 write it for a gameboy advance. arm7tdmi :) 10:45:57 * kc5tja notes that PowerPC motherboards are 90% ATX motherboards. :( 10:46:06 gah. Another bug in the GNU assembler... 10:46:26 What I'd like is a truely up to date version of the Linux system call API. 10:46:33 tathi: oh i had to wrestle with tons of bugs in gas at my last job. they wouldn't let me upgrade binutils to a less buggy version either. 10:46:36 but i was doing weird stuff. 10:46:37 I have one that's dated for 2.2 kernels, and frankly, it's all I really need. But still.... 10:46:39 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 10:46:42 tathi: Heh. I found a new one in NASM the other day... 10:47:06 have you folks played with YASM yet? 10:47:07 OrngeTide: I've only found stuff in the macro processor 10:47:23