00:00:00 --- log: started forth/04.08.06 00:13:41 back 00:13:48 Sorry, I had to help my roommate with some stuff. 00:23:55 Well, I'm going to be going to bed. 00:24:40 Please send your opinions regarding the OpenRISC-vs-Custom-TTA processor to kc5tja (at) arrl (dot) net if you're interested. 00:24:43 Thanks. 00:25:21 Though, personally, I am getting very impatient with Kestrel right now. The design is ballooning, and I need to bring it back in check, desperately. 00:25:30 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 00:37:28 --- join: mur_ (~mur@uiah.fi) joined #forth 00:49:59 --- quit: mur (Read error: 110 (Connection timed out)) 01:05:11 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth 01:22:08 --- nick: Tomasu -> TomasuDlrrp 01:22:12 * TomasuDlrrp is away: night 01:23:04 --- quit: mur_ (Remote closed the connection) 01:23:39 --- join: mur (~mur@kyberias.uiah.fi) joined #forth 02:24:15 --- join: mur_ (~mur@smtp.uiah.fi) joined #forth 02:35:14 --- quit: mur (Read error: 110 (Connection timed out)) 03:37:29 --- nick: mur_ -> mur 03:52:53 --- join: crc (crc@0-1pool128-2.nas58.philadelphia1.pa.us.da.qwest.net) joined #forth 04:02:15 --- join: mur_ (~mur@mgw2.uiah.fi) joined #forth 04:14:49 --- quit: mur (Read error: 110 (Connection timed out)) 04:15:35 --- nick: mur_ -> Mur 04:57:56 --- quit: proteusguy (Connection timed out) 05:00:07 --- quit: Mur (Remote closed the connection) 05:00:43 --- join: Mur (~mur@uiah.fi) joined #forth 05:00:57 --- join: Topaz (jonny@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 05:19:20 --- quit: crc ("Time for bed... Goodnight all!") 05:20:28 --- join: Mur_ (~mur@uiah.fi) joined #forth 05:31:46 --- quit: Mur (Read error: 110 (Connection timed out)) 06:33:45 --- join: warpzero (~warpzero@mi098.dn188.umontana.edu) joined #forth 06:43:07 --- quit: Mur_ (Remote closed the connection) 06:43:42 --- join: Mur (~mur@uiah.fi) joined #forth 07:51:21 --- quit: ChanServ (ACK! SIGSEGV!) 07:52:57 --- join: ChanServ (ChanServ@services.) joined #forth 07:52:57 --- mode: irc.freenode.net set +o ChanServ 07:53:26 --- quit: ChanServ (ACK! SIGSEGV!) 07:54:46 --- join: ChanServ (ChanServ@services.) joined #forth 07:54:46 --- mode: irc.freenode.net set +o ChanServ 07:56:47 --- quit: ChanServ (ACK! SIGSEGV!) 07:57:14 --- join: ChanServ (ChanServ@services.) joined #forth 07:57:14 --- mode: irc.freenode.net set +o ChanServ 07:59:28 Yay, I'm so happy my EVALUATE is finally working properly. Glee! 08:05:48 --- quit: warpzero ("Tried to warn you about Chino and Daddy Gee, but I can't seem to get to you through the U.S. Mail.") 08:17:49 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth 08:17:57 --- mode: ChanServ set +o kc5tja 08:30:31 Howdy 08:30:50 * kc5tja just realized something rather important, and I guess I was just plain too tired to think of it last night. 08:31:14 If I use the OpenRISC 1200, I can edit the source and add my own features to it. In particular, I can rework its register set to be a stack unit. 08:31:43 Sounds good to me. 08:31:59 So what would basically happen is I'd have a RISC processor with 32 GRPs, and consequently, a 32-deep data stack. :) 08:32:22 I could also implement the "link register" as the top of the return stack (which, out of symmetry, I'd also make 32 deep). 08:33:29 General Register Purposes? 08:33:39 Many of the instructions on the CPU has several unused bits. I can use these bits as a push and/or pop control bit. 08:33:42 Yes. 08:33:46 oops 08:33:50 you know what I mean. 08:33:52 :) 08:34:13 push/pop control bit... cool. 08:34:32 What's the "link register?" 08:34:36 Maybe two bits. 08:34:40 One for push, one for pop. 08:35:16 The OR1200 has split instruction and data caches, AND, it has split instruction and data MMUs. :) 08:35:38 So I can *strongly* consider implementing the orthogonally persistant run-time environment in all its glory too. 08:35:43 What would 11 be then? PushPop? That's a kind of crazy sucker that my kid likes to eat. :) 08:35:45 The C64 never had THAT. :D 08:36:09 Cool stuff. 08:36:11 If both push and pop bits are set, I would quite likely have it throw an illegal instruction exception. 08:36:53 Could 11 be swap, or some other common primitive? 08:37:07 No -- too complex. 08:38:28 Does anyone have a funky example of EVALUATE that I can try out for testing? 08:40:54 I do not, unfortunately. 08:41:18 Just trying to think of something not-so-obvious that could cause a problem. 08:41:47 But since it's not-so-obvious what the problem could be, I can't think of it. ;) 08:43:05 Hehe 08:44:57 Actually, since evaluate just pushes the input and enters a new interpreter, I can't see how there can be any gotchas unless it's a fundamental interpreter/outer loop issue. 08:45:01 Hmmm....it appears that the folks responsible for OpenRISC are defining a "common platform" environment for the OpenRISC processor. 08:45:09 You folks think I should strive to be compatible with that? 08:45:09 Oh no! 08:45:45 Well, depends on what exactly that means for you. 08:45:58 Well, YOU'RE going to be the customer (eventually). 08:45:59 :) 08:46:22 I'm not sure how mature the reference platform specifications are yet, so it's a toss-up at this point. 08:46:31 But I'll have to review the specs in detail. 08:51:42 What's a common way to set a breakpoint in forth... change the code field of the target word from ENTER to BREAKPOINT or somesuch? 08:53:18 Win32Forth seems to indicate so: 08:53:18 debug dup 08:53:18 Must be a :, DEFER or DOES> definition ok 08:53:22 --- join: Mur_ (~mur@uiah.fi) joined #forth 08:54:30 Sounds reasonable to me. 08:59:32 It seems to be that going OpenRISC may prove the most beneficial. It can be made superscalar in the future, and given enough cash, can be committed to real silicon at speeds up to 250MHz. 08:59:56 Which really is NOT that bad! According to the data sheet, it HAS been commited to Si and achieved 1W of power draw at 250MHz. That is damn low power! 09:00:00 250MHz C64... nice! 09:00:33 I seriously think that, for a lot of people in the future, the OpenRISC will become the new 6502. 09:01:21 Also, although it does seem to fit in smallish (3100-slice) FPGAs, a lot of the features need to be removed to get it to fit in (e.g., no MMUs, no caches, etc). 09:02:03 But since I'm probably going to go with a Spartan III FPGA for the processor (not sure which one yet), I can hopefully fit in the data and instruction caches. 09:02:21 kc5tja: anything can be implemented in FGPAs right ? 09:02:31 Frek: Anything *digital*, yes. 09:02:34 Or, nearly so. 09:03:03 kc5tja: yeah; but could I thoretically convert a C program/algorithm into "hardwired" FPGA ? 09:03:04 The trick is in how you optimize your design to fit the FPGA. 09:03:16 --- quit: Mur (Read error: 110 (Connection timed out)) 09:03:18 yes. 09:03:21 (I have no FPGA experience at all, but I guess that's obvious) 09:03:38 There would be some limitations, and you might have to re-write parts of the C code, but it is doable. 09:03:55 kc5tja: would the FPGA performance be equalent to "manually hardwired" ? 09:04:03 Not necessarily. 09:04:26 kc5tja: ok; I just though about something like a neural network 09:04:26 The fastest solution will *always* be the case when you have direct control over each transistor you lay down. 09:04:52 But FPGAs are cool nonetheless because they are relatively cheap and have readily available tools (albeit mostly for Windows). 09:05:37 kc5tja: what do you mean "direct control over each transistor you lay down" ? can FPGAs be analogue as well ? (transistors aren't digital by nature) (and excuse my stupidness on this subject :) 09:05:38 The FPGA version of the OpenRISC tops out at approximately 33MHz with all its features compiled, it seems. 09:05:47 The same CPU in ASIC form runs at 250MHz. 09:05:56 No. 09:06:08 ok 09:06:20 so FPGAs are strictly digital chips 09:06:36 An FPGA is a gate array -- the gates and logic are already on the chip, and you can't do anything about it. The only thing you can do is adjust what gate wire goes where. 09:06:44 (more or less; there is more to it than that, but the idea is the same.) 09:06:58 Hence, the biggest issue with speed in an FPGA is propegation delays. 09:07:26 With an ASIC, you have full control over what transistors go where, how big they are, what drive currents they use, what voltages you use for the supply rails, etc. 09:07:32 kc5tja: ah yeah; I never thought about it that far :P, but I can see it now "Field Programmable Gate Array" wheras Gate is AND , OR etc 09:07:37 ASICs are the best possible option IF you have the money for them. 09:08:09 Frek: FPGAs also use RAM-based look-up tables to compute more complex logic functions as well. 09:08:38 kc5tja: ah ok; but basically FPGAs are small processors with configurable input/output pins ? 09:08:54 Frek: No, just a raw collection of gates. 09:09:09 If you want to form those gates as a processor, you're free to do so (as OpenRISC clearly demonstrates). 09:09:09 how does it choice between gates at "burn" time ? 09:09:31 FPGAs have RAM bits which controls which wires are routed where. 09:10:10 hmm ok this is obviously way above my head in my current state 09:10:21 The RAM bits are programmed from an E(E)PROM at power-on time. 09:10:47 but what logic "wires" the RAM bits ? 09:10:51 Each FPGA has its own ROM chip associated with it, which the FPGA reads at power-on time. 09:11:00 What do you mean? 09:11:15 that make it sound like an FPGA is a tiny CPU non the less 09:11:18 Obviously there has to be some kind of boiler-plate, fixed logic on the chip to deal with programming. 09:11:48 No, there are no CPUs on most FPGAs (some Xilinx parts do have embedded PowerPC processors, but it's not used to control th FPGA's internal programming). 09:11:56 kc5tja: ok final question, what decides the (max) operating speed of the FPGA ? 09:12:05 Too many things to list here. 09:13:19 But the biggest two things are transistor feature size (0.18u is going to be faster than 1.2u by quite a lot), and actually *how* you lay your circuit out on the FPGA (longer wires means more capacitance AND resistance, and so therefore, it takes longer for a single transistor to load a wire with a given voltage. Hence, it increases propegation time, and therefore, slows the circuit down along that path). 09:14:09 kc5tja: I do have some experience with digital circuiting from the college, but that was years ago, but I never got the experience that a "physical" gate was speed limited, but rather it depended on the oscillator in the whole circuit (and yes i'm slightly drunk so I'm a bit slow right now:) 09:15:42 kc5tja: how is ASIC compared to FPGA then ? (I guess ASIC is similar ?) 09:15:52 Frek: Well, remember that gates have "propegation times" associated with them. A typical TTL gate will have around 4ns of propegation delays in modern technologies. That means you can never, ever supply a signal faster than 250MHz to it. The gate will do more or less "analog" things, and that will cause misbehavior of the circuit. 09:17:07 If programming an FPGA is programming for SQL databases, then ASIC is like programming raw 1s and 0s into a front-end console of a computer whose circuit you built entirely from scratch with duct tape, chewing gum, lemons, and a little cardboard to hold it all together. 09:17:10 kc5tja: pardon me, is there anyway to calculate the maximum frequency out of the delay propagation ? 09:17:25 ASIC is just a flat piece of silicon. You can do whatever you want with it. You control all. 09:17:51 kc5tja: so ASIC is the name of what they use when the design / manufacture processors etC ? 09:18:23 Frek: Take the slowest propegation time you have in the system. If necessary, especially for combinatorial circuits, you'll want to add up several times. Then take the reciprocal (since frequency and period are inversely related: f = 1/p and p = 1/f). That determines maximum frequency. 09:18:55 kc5tja: but that assumes the propegation delay will be called in serial ? if you get what I mean ? 09:18:56 HIHIHI 09:18:58 :) 09:18:58 Frek: Anything. ASIC can also support analog electronics, since you have ultimate control over individual components on the chip. 09:19:06 kc5tja: ever considered ARM? 09:19:14 arke: ARM costs money, and isn't open source. 09:19:22 arke: ARM7THMI is nice 09:20:03 Frek: There is ALWAYS some kind of combinatorial logic. It is the combinatorial logic of a flip flop that determines its setup and hold times, for example. 09:20:09 kc5tja: ah ok; I wont waste more of your time now :) thank you 09:20:18 :/ 09:20:58 Besides, OpenRISC must be good -- both ARM and MIPS have warned OpenCores to not produce a MIPS or ARM clone or risk serious legal complications. 09:21:20 heh 09:21:37 i though openrisc was a MIPS extension../? 09:21:42 No. 09:21:45 how does OpenRISC compare to the PowerPC ? 09:21:52 Frek: Depends on the PowerPC. 09:22:09 The first thing you'll notice is the OpenRISC 1200 will be, clock for clock, MINIMUM, 1/2 the speed of a PowerPC. 09:22:09 kc5tja: compared to a 750 for example 09:22:21 This is because the OR1200 is a single-issue (e.g., scalar) processor. 09:22:30 That means, one clock cycle, one instruction. Period. 09:22:32 kc5tja: yes; but speed a side, I thought more of register, instruction set features 09:22:39 Oh. 09:22:47 There are 32 *combined* registers. 09:22:55 combined for float / integer ? 09:23:01 That is to say, a single register can hold either integer OR floating point OR vector values. 09:23:36 is there any overhead when storing another type than previously been stored ? 09:23:42 I believe that a 32-bit implementation can only hold 32-bit floating point values; thus, if you want full precision, you'll want to implement the OR1200 as a 64-bit processor. 09:23:59 and you have to keep track of which :) 09:24:10 arke: that's up to the programmer ? 09:24:15 arke: Yes, the compiler is responsible for keeping track of which registers hold what values. 09:24:36 ok that's relatively ok though 09:24:40 Yes. Why should it be otherwise? The hardware treats the integer registers as just a big bag of bits. 09:24:40 ..or the programmer :) 09:25:06 Otherwise, it's closest to the MIPS series of CPUs. 09:25:25 kc5tja: one more question btw; does "OpenRisc" have complex prediction and name registers etc ? or is it just like "interpretive" ? 09:25:26 Although it does have a MAC feature for DSP-like work, I consider it broken compared to PowerPC. 09:25:58 Frek: Well, this is why I said you have to compare apples to apples above. 09:26:11 kc5tja: oh ok, soryr 09:26:12 The PowerPC 750 is so damn fast precisely because of that complex prediction logic and register renaming. 09:26:51 That's because the CPU is trying hard to keep all of its execution units running as fast as it possibly can. 09:27:07 The branches of the CPU all have a branch delay slot, so there is little need for branch prediction. 09:27:19 (which I LIKE, BTW -- branch prediction is a mess) 09:28:06 kc5tja: I don't know exactly how the branch prediction works, but on the PowerPC you can supply hints in your application 09:28:18 But superscalar implementations of the CPU are theoretically possible, and there are two approaches to this: statically assign RISC instructions to each functional unit (which works well up to a point), or dynamically dispatch them (which works well BEYOND that point). Intel and PowerPCs take the latter approach, since it offers the best possible performance. 09:28:32 Hints are only part of the equation. 09:28:36 You can't even hint in OpenRISC. 09:28:39 No need for it. 09:28:51 I guess history records are the most important to branch prediction 09:29:05 kc5tja: does the openRISC have delayed single executes? 09:29:14 but I think the hint plays a great role in the initial branch 09:29:16 Because the 5-stage pipeline is more or less exposed to the programmer in the form of that branch delay slot, branch delays are very predictable and can be dealt with via the compiler software. 09:29:47 kc5tja: but basically the OpenRISC is not pipelined at all ? 09:29:54 No, it is pipelined. 09:29:56 5 stages. 09:30:09 ah i see I got it wrong 09:30:22 Instruction fetch, instruction decode, instruction execute, memory access, and register write-back. 09:30:58 I thought more of pipelining in the sense of different execution units (multipipelined ?) 09:31:00 That's OK 09:31:16 Single execution unit == single pipeline == "scalar." 09:31:25 Multiple execution units == multiple pipelines == "superscalar." 09:31:26 ah ok 09:31:55 gotca 09:31:58 gotcha even 09:32:17 either way; thanks for the enlightenment 09:32:22 no problem. 09:33:22 There is one disadvantage to using the OpenRISC, though it is hardly a major issue: the basic unit of memory is now the 8-bit byte. 09:33:44 Oh, and memory accesses MUST!! be aligned. Failure to do so WILL cause an unaligned access exception. 09:34:16 (e.g., this isn't really an issue for me, having had extensive experience with the Motorola 68000 CPUs, but for those who are used to the x86 architecture, it will be a never-ending source of problems, guaranteed!) 09:47:06 --- quit: Mur_ (Remote closed the connection) 09:47:39 --- join: Mur (~mur@kyberias.uiah.fi) joined #forth 10:04:50 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 10:10:13 --- quit: Frek (Remote closed the connection) 10:14:06 --- join: Fractal (jah@selling.kernels.to.linus.torvalds.at.hcsw.org) joined #forth 10:20:35 yay, got an email from frank seargent 10:59:12 --- join: Mur_ (~mur@uiah.fi) joined #forth 11:09:56 --- quit: Mur (Read error: 110 (Connection timed out)) 11:33:23 --- quit: Topaz (Read error: 60 (Operation timed out)) 11:33:35 --- join: Topaz (jonny@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 11:48:39 --- join: warpzero (~warpzero@mi225.dn180.umontana.edu) joined #forth 11:56:10 * TomasuDlrrp is back (gone 10:33:57) 11:56:13 --- nick: TomasuDlrrp -> Tomasu 12:05:46 --- join: Frek (anvil@h87n2fls31o815.telia.com) joined #forth 12:26:36 hi 12:27:59 hi 12:29:46 arke, i'm making a jedit plugin for factor. there will be full two way integration -- you can press a shortcut in jedit to run a source file in factor, and use "some-word" edit in factor to open that word's source file in jedit 12:30:06 :) 12:30:09 arke, this is in the spirit of pygmyforth which had an integrated block editor and VIEW word instead of SEE 12:30:14 arke, but much more bloated :) 12:30:20 :D 12:30:21 arke, and color :) 12:30:24 pygmy is the best 12:30:27 :D 12:30:37 i printed out its source 12:30:44 4 blocks per page :) 12:30:52 double sided 12:30:59 25 sheets of paper 12:31:03 since its 200 blocks :) 12:31:35 heh 12:32:29 brb 12:32:34 i updated kde to a new release, log out/log in time. 12:32:36 --- quit: slava ("Leaving") 12:55:28 --- join: slava (~slava@CPE00096ba44261-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 12:59:28 --- join: OrngeTide (orange@rm-f.net) joined #forth 13:11:52 --- join: I440r_ (~mark4@216-110-82-203.gen.twtelecom.net) joined #forth 13:40:21 --- quit: warpzero ("Tried to warn you about Chino and Daddy Gee, but I can't seem to get to you through the U.S. Mail.") 13:59:46 --- quit: tgunr ("Leaving") 15:22:46 aerfghfldlkblbs 15:22:50 :/ 15:22:57 normal car part stores dont have the part I need 15:23:07 i'd need to go to a junk yard or dealership to get the part 15:23:11 :'(( 15:53:39 --- join: Mur (~mur@uiah.fi) joined #forth 15:54:55 hi Mur 15:56:02 hi 15:58:03 i'm recompiling lyx with kde support :) 15:58:14 and installing latex2html. 15:58:30 :) 15:58:32 :( 15:58:35 that doesnt help my car though 15:59:05 arke, i could write some professional letters in latex to help your car :) 15:59:07 it will cost you :) 16:00:32 --- quit: Topaz ("Leaving") 16:04:29 slava do you use subversion ? 16:04:35 I440rcvs 16:04:40 doh! 16:04:50 hush now 16:04:53 lol 16:05:18 i have a subversion server now. i cant get WebSvn working tho (used to have it working but i changed things and have to fix it) 16:05:24 i just did the initial import for isforth 16:05:34 cool 16:05:45 and the svn server is on a machine on my internal private network at home :) 16:05:55 so when you do an svn checkin it gets routed to the right box 16:06:03 --- quit: Mur_ (Read error: 110 (Connection timed out)) 16:10:25 awesome. i just did TWO seprate imports into my reposatories from two different boxes 16:10:36 isn't that redundant? 16:10:42 one useing the dos command line svn stuff the other one using tortoise-svn 16:10:49 no. different projects 16:11:10 windows freka 16:11:55 heh 16:12:01 this is a WORK box :) 16:12:12 i have a better version control server than they do here lol 16:12:24 and theirs costs them 8 thousand dollars for the server software 16:12:40 plus 2 thousand per seat 16:14:00 neway its friday :P 16:14:04 time to go home!!! 16:40:58 back all 16:41:09 i have to drive to the dealership sunday or monday 16:41:13 to get that part 16:41:20 and they're likely gonna have to special order it 16:41:33 which means that i have to pay MORE money :/ 16:47:54 --- join: Mur_ (~mur@uiah.fi) joined #forth 16:55:45 arke, listening to Vital Signs? 16:55:58 no 16:56:06 bought a new red hot chilil peppers cd :) 16:57:04 There's a new one? 16:57:24 We had the last one, but it got stolen along with a bunch of other stuff, including Rush. >B[ 16:59:15 --- quit: Mur (Read error: 110 (Connection timed out)) 17:00:11 :/ 17:00:14 no, not a new one 17:00:22 its their transition CD 17:00:37 between their 80s style (kinda suck) and their 90s style (FUCKING AWESOME) 17:00:41 its called Mother's Milk 17:01:12 Ahh yea, good album. 17:02:26 :) 17:02:35 not as good as blood sugar sex magik 17:03:36 Well... just different. 18:04:24 --- quit: fridge ("rock out with your cock out") 18:17:53 --- join: Mur (~mur@uiah.fi) joined #forth 18:29:03 --- quit: Mur_ (Read error: 110 (Connection timed out)) 18:57:18 argh whers tathi :) 19:36:35 --- join: Mur_ (~mur@smtp.uiah.fi) joined #forth 19:39:07 --- quit: Mur (Read error: 60 (Operation timed out)) 20:41:29 --- quit: Mur_ (Remote closed the connection) 20:42:10 --- join: Mur (~mur@uiah.fi) joined #forth 21:41:51 immediate vocabularies are the shiznit. 21:42:16 --- join: I4404__ (~mark4@216-110-82-205.gen.twtelecom.net) joined #forth 21:46:36 --- join: fridge (~fridge@dsl-203-33-167-9.NSW.netspace.net.au) joined #forth 21:52:43 --- join: Mur_ (~mur@smtp.uiah.fi) joined #forth 21:53:09 Come, join the brotherhood of Immediate Vocabularies! 21:55:11 hhi 21:55:12 hi 21:55:12 hi 21:55:12 hi 21:55:13 hi 21:55:15 hi 21:55:17 hi 21:55:20 hi 21:55:22 hi 21:55:25 i agree 21:55:33 immediate vocabs are better than immediate flag bytes 21:55:42 Er, that's not actually what I meant. ;) 21:55:46 But... sure! If you say so. 21:55:49 :) 21:55:51 I KNOW SO 21:55:57 YOU KNOW YOU SAY SO 21:56:52 So, describe to me how one uses immediate/compile vocabularies... IF that is what they REALLY are... 21:57:25 easy 21:57:32 two vocabs 21:57:37 MACRO/COMPILER and FORTH 21:57:49 immediate only searches FORTH and calls it 21:58:12 compiler searches MACRO/COMPILER first. if found, calls it. If not, searches FORTH and compiles if found. 21:58:44 --- quit: I440r_ (Connection timed out) 21:58:50 Let's see some examples! 21:59:53 okies 22:00:34 for example, an IF implementation that works in both modes 22:00:40 COMPILER 22:01:01 : IF COMPILE 0BRANCH HERE ; 22:01:37 : ELSE HERE SWAP @ HERE'fm'dkga'dkga' 22:01:38 'llkna;ag 22:01:40 ok 22:01:41 whatever 22:01:43 you get the gist 22:01:49 the interpretive one is in FORTH 22:01:55 the compiled one is in COMPILER 22:01:56 :) 22:02:21 Sure. 22:02:50 OK, but not convinced it's really any better than an IMMEDIATE flag. :) 22:03:03 it is 22:03:12 immediate is ugly, space-consuming 22:03:22 and you can't do neat tricks like described above 22:03:58 --- quit: Mur (Read error: 110 (Connection timed out)) 22:04:07 "immediate only searches FORTH and calls it"... did you mean to say COMPILER, not FORTH? 22:04:19 no 22:04:22 immediate mode 22:04:25 :) 22:04:33 like at the interactive prompt 22:04:35 or between [ ] 22:04:36 Ahh, OK. 22:04:46 I thought you meant like an immediate word. 22:04:50 :P 22:05:40 But sure, it makes sense. How is immediate space-consuming? Are you talking source code? 22:06:12 not only that 22:06:21 but also you need a byte for flags 22:06:34 because normally you wont have flags except for that one 22:06:41 so thats one byte more EVERY WORD 22:07:05 thats 500 bytes in chucks VLSI suite 22:07:09 and he codes TINY 22:07:16 Sure. 22:07:53 just one example 22:11:40 I could fake out something similar... 22:11:40 vocabulary compiler also compiler definitions 22:11:40 : ; postpone ; immediate ; immediate 22:13:29 BTW, a Forthy word's header is 52 bytes. ;P 22:28:09 woah 22:28:10 wtf 22:28:11 you are lame 22:28:15 cut down 22:28:16 wtf 22:28:19 post 22:28:31 I may trim it a bit. 22:28:36 paste 22:28:36 paste 22:28:46 hehe 22:28:49 But remember, this is a C Forth, for scripting/extension. 22:28:52 paste 22:28:52 paste 22:28:52 paste 22:28:52 paste 22:28:55 grr 22:28:57 ill help you trim 22:29:00 !? 22:29:02 ?! 22:29:04 !! 22:29:06 ?? 22:29:07 JUST PASTE THE DAM Oh, I see... 22:29:13 Jussec. 22:29:44 struct FSYMREC 22:29:44 { 22:29:44 FCFUNC exec; // Code Field 22:29:44 char *name; // Name Field 22:29:44 int flags; // FS_IMMEDIATE, FS_COMPILE 22:29:45 FVALUE data; // Parameter Field -- Make as a pointer? 22:29:47 void **code; // Code data array for compiled words 22:29:49 22:29:51 // char *user // USER var, for source code or whatever 22:29:53 22:29:55 FSYMREC *prev; 22:29:57 FSYMREC *next; // Link Field 22:29:59 22:30:01 FSYMREC *vocab; // Vocabulary ID for this word 22:30:03 FDICT *dict; // Parent dictionary 22:30:05 22:30:07 FREF *back_ref; // References to this word 22:30:09 }; 22:30:34 FVALUE is my "cell", it's 16 bytes. 22:31:38 god 22:31:44 you're such a typical C programmer 22:31:47 grrr 22:31:50 haha 22:31:51 Oh? 22:32:05 first of all, you do not need a parameter field AND code array 22:32:07 only one 22:32:10 thats your first trim 22:32:14 Nope, can't. 22:32:18 secondly, implement immediate vocabularies 22:32:24 trim the flags 22:32:32 link fieds are okay 22:32:41 although i do not see the use for the prev 22:32:44 :/ 22:33:10 It has to do with what I allow the user to access, and what I don't. 22:33:39 And, if I had combined code and data, the code would be pretty bloated... at 16 bytes per cell. 22:33:57 So, I've "optimized" them into seperate things. 22:37:04 :// 22:37:07 Also, my system is more protective than a real Forth is. Requires more interfaces and bloat. Again, scripting purposes. Plus, a CELL is a crappy way to handle scripted values. 22:37:44 I'll eventually write a optimized bytecode Forth with different philosophies in play. 22:38:16 wait wait wait wait wat 22:38:20 16 bytes per cell? 22:38:23 what the hell are you thinking? 22:38:34 It's not a cell, dude. 22:38:37 It's a VALUE. 22:38:41 Totally different. 22:38:56 So, put your Forth purism away. 22:38:57 :P 22:39:47 If I want to interface to C code, I sure as hell don't want to use CELLs. 22:41:56 It's crash-proof, easy to hook into other programs, and uses weakly-typed values which are a pleasure to work with for extension purposes. 22:42:08 And at the end of the day... 22:42:15 : namespace 22:42:16 32 word 22:42:16 "{" $cat $create last last >body ! immediate 22:42:16 does> @ dup voc.push current! 22:42:16 ; 22:42:22 : } 22:42:23 voc.pop drop 22:42:23 voc.depth if voc.pop dup current! voc.push 22:42:24 else current.clear then 22:42:26 ; immediate 22:42:32 ...is still pretty damn Forthy. :P 22:46:05 hi madgarden! 22:46:16 Hi slava! 22:46:22 madgarden, i hope you write forthy docs in latex or lyx :) 22:46:26