00:00:00 --- log: started forth/10.04.24
00:01:46 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
00:36:44 --- quit: kar8nga (Remote host closed the connection)
01:45:36 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth
02:25:27 --- quit: qFox (Read error: Connection reset by peer)
03:15:42 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
03:28:20 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth
04:16:44 --- quit: ygrek (Ping timeout: 245 seconds)
04:54:08 --- quit: tathi (Quit: leaving)
05:01:08 --- quit: ASau (Quit: reboot)
05:12:00 --- join: ASau (~user@83.69.227.32) joined #forth
06:09:06 --- quit: mathrick (Remote host closed the connection)
06:10:46 --- join: mathrick (~mathrick@users177.kollegienet.dk) joined #forth
06:36:01 --- quit: qFox (Read error: Connection reset by peer)
06:55:39 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
07:04:51 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth
07:30:45 --- quit: gogonkt (Ping timeout: 264 seconds)
07:32:22 --- join: gogonkt (~info@113.69.46.126) joined #forth
09:07:14 --- join: beretta (~beretta@c-24-3-44-28.hsd1.oh.comcast.net) joined #forth
09:09:52 --- quit: beretta (Client Quit)
09:12:06 --- join: beretta (~beretta@c-24-3-44-28.hsd1.oh.comcast.net) joined #forth
09:58:49 --- join: GoNoGo (~GoNoGo@2a01:e35:2ec5:dd70:646c:9f17:87b2:b018) joined #forth
10:48:22 --- quit: crc (Ping timeout: 258 seconds)
10:50:02 --- join: crc (~charlesch@184.77.185.20) joined #forth
10:53:41 --- join: alex4nder (~alexander@173-147-207-68.pools.spcsdns.net) joined #forth
10:54:01 <alex4nder> hey
11:02:11 <beretta> ping!
11:03:26 <schme> ping
11:17:24 <beretta> pong
11:17:26 <alex4nder> beretta: hey
11:18:24 <beretta> ahoy!
11:18:37 <beretta> sorry I'm getting carried away...
11:19:29 <alex4nder> anyone been hacking on anything from greenarrays recently?
11:22:52 <beretta> they look interesting
11:24:39 <Pusdesris> They have "product" now?
11:26:00 <schme> aren't they just producing something like the intellasys things?
11:27:00 <schme> oh man. their website is messed up.
11:27:11 <schme> I like how they put a ; and have it go back in history.
11:27:41 <beretta> heh
11:28:32 <Pusdesris> Chuck moore's companies never have product.
11:28:43 <Pusdesris> They just put specs up on the website, but never ship anything.
11:28:56 <alex4nder> Pusdesris: I have an older S24 dev kit.
11:29:04 <schme> From intellasys.. not a chuck moore company ;)
11:29:07 <alex4nder> but nothing from Greenarrays, officially.
11:29:35 <Pusdesris> Even intellasys.
11:29:44 <Pusdesris> I tried getting myself a forth drive, never happened though.
11:29:55 <schme> I got a intellasys dev kit.
11:30:06 <alex4nder> yup.  I have a Forth drive as well.
11:30:24 <schme> the whole 40C18 eval kit or what it is called.
11:30:36 <alex4nder> yah
11:30:54 <schme> I ordered it not directly from intellasys but from somewhere else.. they had a link I think.
11:31:32 <alex4nder> I was trying to build a product based on the S24, instead of using an FPGA.. but of course, that wasn't going to happen.
11:31:45 <schme> Why didn't it happen?
11:32:54 <alex4nder> because they couldn't even offer a low-production volume of S24s, in any reliable way.
11:33:23 <schme> Hoh.. I think I read something about that.. They were wanting to ship just single eval kits or huge amounts.
11:33:53 <Pusdesris> How did you get the forthdrive?
11:33:53 <alex4nder> yup
11:33:58 <alex4nder> I asked.
11:34:03 <alex4nder> and they sent me one.
11:34:13 <schme> They used to have a link to a site that sold their products.. I can-t find it now.
11:34:27 <Pusdesris> I asked too.
11:34:29 <Pusdesris> They sent me nothing.
11:34:40 <schme> Did they reply?
11:34:46 <Pusdesris> Yes.
11:34:54 <Pusdesris> Just said something like, "We ran out."
11:34:55 <alex4nder> what did you say you were going to use it for?
11:35:16 <Pusdesris> Academic purposes. 
11:35:31 <Pusdesris> Or I may have said hobby.
11:35:33 <Pusdesris> I don't remember
11:35:44 <schme> Running out of this forthdrive seems.. I dunno.  I can see how they were not making any money. But how to make money if they don't ship free products to have people play with and get hooked?
11:36:14 <alex4nder> I ordered one to write a high-speed sensor decoder
11:36:22 <alex4nder> i.e. decoding the crank position of an engine
11:36:25 <beretta> schme: startup capital
11:36:42 <schme> Didn't they have like some competition and just the neat ones got the drive?
11:36:54 <schme> beretta: Just saying.. theey should be handing those things out like candy :)
11:37:21 <Pusdesris> Agreed.
11:37:25 <beretta> haha...mmmm forth candy mmmmm...
11:37:50 <schme> once you pop, you can't stop.
11:38:44 <alex4nder> unfortunately greenarrays isn't going to go anywhere
11:39:15 <alex4nder> cmoore should just release all of his implementations to the public, and earn off of his patents.
11:42:34 <beretta> "We recommend that you keep cats and small children away from your keyboard when colorForth is running." -- Chuck
11:48:01 <schme> alex4nder: He could then make a living as a webdesigner.
11:48:19 <alex4nder> schme: hahaha
12:02:45 --- nick: Pusdesris -> Deformative
12:11:56 --- quit: Snoopy_1611 (Ping timeout: 276 seconds)
12:52:17 --- quit: GoNoGo (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
13:09:39 --- quit: ygrek (Ping timeout: 245 seconds)
13:30:29 --- quit: alex4nder (Ping timeout: 245 seconds)
14:25:36 --- quit: kar8nga (Remote host closed the connection)
15:33:28 --- quit: qFox (Quit: Time for cookies!)
15:38:56 --- quit: ASau (Ping timeout: 258 seconds)
15:40:56 --- join: ASau (~user@83.69.227.32) joined #forth
18:07:48 <KipIngram> alex4nder: That just doesn't seem to be the mindset of the elite Forth guys, though - they are "close hold" in the extreme.
18:08:56 <KipIngram> Man, it's nuts here tonight.  My 4th grade daughter is having a birthday slumber party.  The place is covered up in kids.
18:18:17 --- quit: crc (Quit: http://retroforth.org)
18:33:38 --- join: crc (~charlesch@184.77.185.20) joined #forth
19:19:28 <Deformative> Hey kip.
19:32:28 <KipIngram> Hey.
19:32:30 <KipIngram> How goes.
19:36:27 <Deformative> Spent the day relaxing.
19:36:32 <Deformative> Waiting for more exams.
19:36:39 <Deformative> To screw up on.
19:38:31 <Deformative> Been trying to get this research thing all worked out.
19:38:41 <Deformative> Trying to figure out how to get academic credits and such.
19:38:46 <Deformative> How abotu yourself?
19:44:14 <KipIngram> Noisy house.  My daughter's having a sleepover.  Driving me crazy.
19:44:24 <KipIngram> I just retreated to the bedroom.
19:44:31 <KipIngram> Hopefully they will go upstairs soon.
19:48:22 <Deformative> Heh.
19:53:27 <KipIngram> I changed !b+) to !a+).  The a and b registers load as a chain, first a and then b.  It made sense to put the one with the most features first in line.
19:53:40 <KipIngram> Shortens the instruction sequence required to set up for that feature.
19:54:20 <KipIngram> I'm also thinking of making the thing generally see nop opcodes coming and skip over them in time.  So they would take up space (which is what they are for - code alignment), but they would never take up time.
19:54:23 <KipIngram> What do you think?
19:55:42 <Deformative> It's over my head. I think/
19:56:46 <KipIngram> Well, I guess what I'm asking is what do you think of giving up nop instructions as a way of "killing time" on the processor?
19:58:16 <Deformative> Seems valid.  The only usefulness I can think of for killing time is something like "pausing" or whatever, but it can probably be implemented better with an onboard clock and loop.
20:00:20 <Deformative> You are not using nop for synchronization or anything are you?
20:00:47 <KipIngram> Or with a sequences like "dup drop" or "dup swap drop" (that one would take an even cell).  So I don't really have to have nop for that.
20:00:52 <KipIngram> No.
20:00:55 <KipIngram> Just to align code.
20:01:20 <KipIngram> Like if a ret falls on the first slot of a cell I have to put two nop codes so that I can start the next routine on an addressable cell boundary.
20:02:38 <Deformative> Can those opcodes ever be reached?
20:03:08 <Deformative> I mean, is it manditory that they really have no operation?
20:03:16 <Deformative> You could always fill with arbitrary bits.
20:05:13 <Deformative> I think I am going to build the vga controller and instructions right into my cpu.
20:05:25 <Deformative> I will have extra opcodes to do whatever I want with, and well, why not.
20:05:33 <KipIngram> That's a damn good point.
20:05:42 <KipIngram> Maybe I don't even need that opcode at all.
20:06:30 <Deformative> :)
20:06:32 <KipIngram> Ok, I'm going to watch some TV with my wife. I'll have to ponder on whether I really *need* a nop.
20:07:28 <KipIngram> Let's talk some more soon about a VGA controller - I've had some thoughts (very preliminary ones) about that.  I think a chat would be fun.
20:07:35 <KipIngram> Maybe later tonight or tomorrow.
20:09:48 <Deformative> Well.
20:10:04 <Deformative> THe problem with not having nop is that nop is really useful for ILP.
20:10:22 <Deformative> But the fact that you are using a stack machine, really makes ILP minimally useful.
20:10:34 <Deformative> Ok, talk to you later.
20:10:36 <Deformative> o/
20:19:09 --- quit: beretta (Quit: Poof!)
20:31:04 <Deformative> ...Wait.
20:31:10 <Deformative> Is nop useful for ILP?
20:31:15 * Deformative ponders.
20:34:40 <Deformative> Forget I said that.
20:34:48 <Deformative> I don't think it is useful for that now that I think of it.
20:54:48 --- quit: gnomon (Ping timeout: 258 seconds)
20:55:08 --- join: gnomon (~gnomon@CPE0022158a8221-CM000f9f776f96.cpe.net.cable.rogers.com) joined #forth
21:06:14 <KipIngram> I don't know what ILP stands for.
21:06:26 <Deformative> Instruction level parallelism.
21:06:52 <KipIngram> Ok.
21:07:11 <KipIngram> My processor does a few things via look-ahead, but makes no general attempt at that.
21:07:18 <Deformative> I have no idea why I thought nop was useful for that.
21:07:21 * Deformative shrugs.
21:07:54 <KipIngram> If you had a multi-processor system and were trying to line up (in time) streams of code on different proccessors it might be useful.
21:08:15 <Deformative> I was thinking, and it wouldn't be terribly difficult to implement huffman encoding right into the instruction set.
21:09:04 <Deformative> One would just need to know the frequency which each instruction is commonly used.
21:09:31 <Deformative> In forth, CALL is probably the most common, so that could be reduced to a single bit.
21:09:41 * Deformative shrugs.
21:11:56 <Deformative> Another idea I had.
21:12:28 <Deformative> What do you think of seprate pipelines for instructions and data on a forth chip?
21:12:38 <Deformative> Actually, nevermind.
21:12:59 <Deformative> It probably wouldn't be useful, since there is so much brancing and forth can easily prefetched.
21:15:38 <Deformative> Well, there is potential benefit I suppose in store and fetch.
21:15:42 <Deformative> Not sure though.
21:18:01 <Deformative> It would be more difficult to write an assembler/compiler for.
21:18:23 <Deformative> If you wanted to put literals and stuff on their own pipeline.  Lol.
21:18:34 <Deformative> Ok, I am just getting stupid now.
21:18:36 <Deformative> I should stop.
21:43:05 <KipIngram> My CALL is a single bit, in fact.  But CM had that idea years ago, so it's nothing new.
21:44:14 <KipIngram> That's the whole MSB thing - if the MSB of a cell is zero then the other 15 bits are three five bit opcodes.  If it's 1 then the other 15 bits are used to compute an effective address and conditional info for a possible control transfer.
21:44:30 <KipIngram> I don't know if CM had any conditional stuff in his.
21:44:46 <KipIngram> Or the ability to do jump as well as call.
21:45:41 <KipIngram> In my processor if bit 15 is 1 then bit 14 tells you whether to push the return address (call) or not (jump), and bits 12 and 13 specify one of four conditional possibilities.
21:47:47 <KipIngram> Finally, if bit 11 is 0 then the 11 bit effective address (which can specify 2k cells) lies in the address range 0 - 2k.  But if bit 11 is 1 then the upper five bits of the effective address is specified by a "bank register".
21:48:07 <KipIngram> That way I can have up to 64k cells of code, in 2k cell banks.
21:48:54 <KipIngram> The effective address is fully resolved to a 16-bit cell address at call time, and the return address that's pushed is always a full 16-bit address.  So returns always work properly and go back to the proper place.
21:50:57 <Deformative> I see.
21:51:42 <Deformative> So you cannot put calls within your instruction cells.
21:51:48 <Deformative> I suppose that is a good thing.
21:51:48 <KipIngram> Right now I hand code everything to specific addresses, in machine code.  I find that getting the addresses specified right is quite difficult.
21:52:00 <KipIngram> Once I write a compiler, though, it will do all that for me.
21:52:20 <KipIngram> I do plan to add a call opcode.
21:52:42 <KipIngram> It will pull a literal from the following cell (a 16-bit one) and will transfer control to that address, with no mapping.
21:52:59 <KipIngram> Right now I push the literal to the return stack and then do a ret.
21:53:22 <KipIngram> But that takes several opcodes and several cycles; I think consolidating it all to a special purpose opcodee is worth it.
21:54:28 <Deformative> I agree.
21:54:33 <Deformative> You have plenty to spare.
21:55:31 <Deformative> I was planning on call, branch, and 0branch.
21:55:45 <Deformative> I will remove branch from the list if I need an extra opcode.
22:02:28 <KipIngram> Once I added the ability to either jump or call with a effective address cell, and once I added conditions, I needed none of those opcodes.  I can call or jump, unconditionally or per three conditions, with a single 16-bit cell and no extra opcodes.
22:02:48 <KipIngram> The only reason I'm adding a special opcode is to allow a "far call" that  will go to a new mapped memory page.
22:03:14 <KipIngram> I imagine that's what I'll replace the nop opcode with.
22:04:48 <KipIngram> Here's my reasoning.  Let's say you have call, branch, and 0branch opcodes.
22:05:03 <KipIngram> And 16-bit address cells.
22:05:18 <KipIngram> That means that a call takes 16+(opcode size) bits.
22:05:22 <KipIngram> As do the other two.
22:05:52 <KipIngram> A conditional *call* takes a lot of bits - the 16+(opcode size) for the call as well as the opcode for the conditional jump, the bits for the target address, etc.
22:06:00 <KipIngram> I can put all of these things into a 16-bit cell.
22:06:18 <KipIngram> The cost is that I require the mapping process to get full addressing range.
22:06:50 <KipIngram> But if far calls and jumps are rare compared to short ones then this will pay off in code space in in the time required to fetch that code.
22:07:30 --- quit: segher (Quit: This computer has gone to sleep)
22:08:10 <Deformative> Hmm.
22:08:23 <Deformative> Is there any reason to pack instructions into cells other than for unext?
22:08:51 <KipIngram> Code space.
22:08:58 <Deformative> I do not understand.
22:09:24 <KipIngram> Plus memory access time - if you can fetch three opcodes in one read then you can run instructions at three time the memory access rate.
22:09:30 <KipIngram> I'm not doing that yet, but I intend to.
22:09:34 <KipIngram> Future version.
22:10:03 <Deformative> So, you can still fetch 3 at a time... Why do you need to be restricted to these cells?
22:10:28 <Deformative> You can left shift by opcode size every instruction.
22:10:55 <KipIngram> I don't understand - "restricted to these cells"?
22:11:22 <KipIngram> You mean why can't I do a wider fetch?
22:11:33 <Deformative> Ok, say you fetch 16 bits at a time.
22:11:39 <KipIngram> That's right.
22:11:43 <Deformative> And you have 32 opcodes.
22:11:45 <KipIngram> I could fetch more if I wanted to.
22:11:46 <Deformative> So each take 4 bits.
22:11:53 <KipIngram> Each takes five bits.
22:12:03 <Deformative> Oh, right.
22:12:11 <Deformative> Ok.
22:12:11 <KipIngram> The one left over is the one that specifies whether it's three opcodes or an effective address / conditional.
22:12:35 <KipIngram> Let's just call them opcode cells and EA cells from now on.
22:12:58 <Deformative> Hmm.
22:13:28 <Deformative> Ok, hypathetically, let's say that there were only 16 instrutions.
22:13:53 <Deformative> You fetch 4 at a time.
22:14:13 <Deformative> But you always have 4 extra prefetched.
22:15:05 <Deformative> So, let's just store them in a 32 bit register.
22:15:21 <KipIngram> Until you branch before you need them, and then you haven't prefetched the ones you need.
22:15:36 <KipIngram> I've been all down this road.
22:15:53 <Deformative> Makes sense.
22:15:54 <Deformative> Ok.
22:16:15 <KipIngram> And then if you don't have that one leftover bit for the EA specification you have to have a call opcode.
22:16:26 <KipIngram> So a series of colan definitions becomes this:
22:16:29 <KipIngram> nop nop nop call
22:16:30 <KipIngram> EA
22:16:33 <KipIngram> nop nop nop call
22:16:35 <KipIngram> EA
22:16:41 <KipIngram> So you waste a bunch of slots on nops.
22:17:08 <KipIngram> Essentially each colan definition becomes a 32-bit thing.
22:17:12 <Deformative> Makes sense.
22:17:41 <Deformative> Would it be possible to make it so you can fetch 32 bits at a time?
22:18:38 <Deformative> I suppose that is a lot of extra fetching if you branch quickly.
22:19:38 <KipIngram> In an fpga yes, almost anything is possible.  Put your memory banks in parallel.  But yes, you are seeing the problems.
22:20:29 <KipIngram> For tightly wound code with lots of calls and branches 32-bit fetches are wasteful.
22:20:36 <KipIngram> And besides, code space counts in an fpga. 
22:20:55 <KipIngram> Your internal memory is *much* faster than external memory, and smaller fpgas have only modest memory.  You don't want to waste it.
22:21:18 * Deformative ponders.
22:27:22 <Deformative> How do your calls work again?
22:27:28 <Deformative> With your cell packing method?
22:29:24 <KipIngram> If the MSB of a cell is 1, then the lower 15 bits specify an EA and conditions.
22:29:39 <KipIngram> Bit 15 specifies call vs. jump (do I push the return address).
22:29:47 <KipIngram> I'm sorry - bit 14.
22:30:03 <Deformative> Ok, you have "+ USER_DEFINED_WORD"
22:30:05 <KipIngram> Bits 12 and 13 specify unconditional or one of three conditions.
22:30:07 <Deformative> What does that compile to?
22:30:29 <KipIngram> Bit 11 specifies hard reference to lowest order block vs. block specified by map register.
22:30:49 <KipIngram> I don't know what you mean by that.
22:31:46 <Deformative> If someone were to type : foo * - ;  : bar + foo ; what is generated?
22:32:56 --- join: alex4nder (~alexander@dsl093-145-168.sba1.dsl.speakeasy.net) joined #forth
22:33:19 <Deformative> In the bar definition, what does + foo look like?
22:38:21 <Deformative> KipIngram: ?
22:44:50 <KipIngram> Sorry; distracted for a minute.
22:44:58 <Deformative> No worries.
22:45:20 <KipIngram> At the target address for foo you get this:
22:45:30 <KipIngram> * - ret
22:45:34 <KipIngram> So that's just one cell.
22:45:54 <KipIngram> At the target address for bar you get this:
22:45:59 <Deformative> Ok, lets represent cells as [] So [*, -, ret, x]
22:46:01 <KipIngram> + nop nop
22:46:03 <Deformative> Where x is don't care.
22:46:15 <KipIngram> EA cell with call to foo
22:46:18 <Deformative> Oh yeah, 3 words per cell.
22:46:20 <KipIngram> ret nop nop
22:46:20 <Deformative> I forgot.
22:46:23 --- join: forther (~62d2faca@gateway/web/freenode/x-ftebgrwsdbhxfxdi) joined #forth
22:46:26 <KipIngram> No, wait.
22:46:27 <KipIngram> Better.
22:46:40 <KipIngram> at the address for bar you get this:
22:46:54 <KipIngram> nop nop +
22:46:55 <forther> hi
22:47:00 <KipIngram> ea for jump to foo
22:47:03 <KipIngram> and that's it.
22:47:20 <KipIngram> Since you jump to foo the ret takes you back to bar's caller.
22:47:55 <Deformative> Hi forther.
22:49:19 <Deformative> Ok, I see.
22:50:13 <Deformative> It seems like most of the time if you use an opcall somewhere in a defintion, you will most of the cell.
22:50:47 <KipIngram> If you need just one opcall then it's inefficient.
22:51:01 <KipIngram> This is the biggest reason I pushed so hard to get calls, jumps, conditionals, etc. into the EA cells.
22:51:02 <Deformative> I think that is most of the time.
22:51:15 <KipIngram> So that I didn't need isolated jmp, jz, call, etc. opcodes.
22:52:11 <KipIngram> I don't know - I think it would vary.
22:52:34 <KipIngram> I imagine that it would be close to 1/3 of the time for each case (one slot used, two slots used, three slots used).
22:52:43 --- part: a3i left #forth
22:52:44 <KipIngram> Or maybe 1/2, 1/4, 1/4.
22:52:54 <KipIngram> But not 0.9, 0.05, 0.05
22:53:17 <KipIngram> I won't know for sure until I can write and profile a fairly substantial body of code.
22:53:52 <Deformative> I am wondering if it is possible to put jump opcodes in cells as well, then use the same sort of style you used for literals.
22:54:02 <Deformative> It just makes return extremely difficult.
22:54:14 <Deformative> Actually! Not too difficult!
22:54:56 <KipIngram> Sure; jump opcodes are easy to implement.
22:55:06 <KipIngram> I did it that way in my early drafts.
22:55:13 <Deformative> No, not the way I am thinking.
22:55:29 <Deformative> You need to reload the offset when returning.
22:55:50 <KipIngram> Oh, you mean return to a slot within a cell instead of to the cell itself?
22:55:54 <Deformative> But yu can store that in the return stack, or you could do some analysis of the cell when you return.
22:56:11 <KipIngram> I haven't even looked into that.
22:56:35 <KipIngram> Yes, you could store two extra bits to specify the state (which specifies the slot).
22:57:04 <KipIngram> But are you going to refetch the cell, and then go to the right slot (which means going to state 0 and then to state <whatever>)?
22:57:24 <KipIngram> Or are you going to push the cell contents onto the return stack as well (now you have a 34 bit wide return stack).
22:57:29 <KipIngram> Issues...
22:58:26 <Deformative> Hmm.
22:58:39 <Deformative> Pushing cell contents would be fascinating.
22:58:44 <Deformative> You could exploit that hack like crazy.
22:58:49 <KipIngram> I decided not to.
22:58:58 <KipIngram> But yes, I did find it an interesting idea.
22:59:35 <Deformative> But like I said, it would make return very complicated.
22:59:46 <KipIngram> No, that's what would make returning easy.
23:00:07 <Deformative> I think it is much more difficult than your current plan.
23:00:12 <KipIngram> The address lets you restore IP, the contents let you restore IW, and the two bit state let you go to the right slot in IW.
23:00:14 <KipIngram> You're back.
23:00:34 <KipIngram> Yes, it is more difficult and more than doubles the resources required for the return stack.
23:01:08 <KipIngram> That was the real kicker for me - I couldn't bear the resource cost.
23:01:16 <alex4nder> re..
23:01:27 * Deformative ponders.
23:01:40 <KipIngram> Deformative and I are discussing my FPGA processor architecture, which runs Forth native.
23:01:55 <KipIngram> He's going to be doing one, and we're using aspects of mine as talking points.
23:02:13 <KipIngram> Actually we've touched on a number of others as well, like some of Seaforth's stuff and so on.
23:02:51 <KipIngram> Right now we're dealing with issues related to opcode packing, how to encode calls, jumps, etc.
23:06:38 <Deformative> It leads to problems with prefetching.
23:07:24 <KipIngram> Yeah, lots of things can cause prefeching problems.
23:07:44 <KipIngram> Prefetching can speed you up so much, but then as soon as a control flow issue makes it "wrong" you have to deal with that.
23:08:14 <Deformative> I was thinking about having two pipelines.
23:08:27 <Deformative> One for literals and one for instructions.
23:08:48 <KipIngram> You mentioned that earlier.  I'm not sure what it buys you.
23:08:50 <Deformative> They would each need their own counters though.
23:09:25 <Deformative> Yeah, you're right, it buys nothing.
23:09:29 <Deformative> Nevermin.d
23:10:05 <Deformative> I was thinking you might be able to hold the same prefetch, but you would need to branch in both.
23:10:11 <Deformative> So it doesn't help.
23:10:31 <KipIngram> These thoughts are like drugs.
23:10:56 <KipIngram> I spent months trying to find the golden path through it all, and finally gave up.
23:11:13 <KipIngram> Of course, these are standard problems that face all processor designers.
23:13:04 <KipIngram> You know, I'll tell you where you need a nop.
23:13:27 <KipIngram> When you finish a code stream that runs up to a jump target and you're not on a cell boundary.
23:13:34 <KipIngram> You need a way to pad.
23:13:39 <Deformative> Yeah.
23:13:55 <KipIngram> And besides, if nop could be done away with Chuck Moore would have figured that out.
23:14:09 <KipIngram> I think that's a blind alley.
23:14:26 <Deformative> If there is a way to get call working in a cell as well, then you don't need it.
23:14:43 <Deformative> Erm, I mean packed into a cell.
23:14:51 <Deformative> Branch is easy.
23:14:55 <KipIngram> Once again you're talking about transferring control into the middle of a cell?
23:15:14 <Deformative> Yeah...
23:15:18 <KipIngram> Remember you have to specify those bits in your target address.
23:15:28 <KipIngram> Makes your addresses wider.
23:15:47 <Deformative> No, target can always branch to front of a cell.
23:15:52 <Deformative> Oh, you would still need nops.
23:15:54 <Deformative> Hmm.
23:16:49 <Deformative> So you would need to both branch from and to middle of cell.
23:16:56 <Deformative> I was thinking it was only from.
23:18:08 <KipIngram> Branching from the middle of a cell takes an opcode.  In my processor if you've used slot one for something and then need to branch, you nop slots two and three and put the jump as a cell after that.
23:18:29 <KipIngram> The alternative is to have the same use for slot one, put a jump instruction in slot two, and then the target goes in the following cell.
23:18:33 <KipIngram> You didn't really gain anything.
23:18:57 <KipIngram> The target address goes in the same place either way, and you have one nop whereas I have two.
23:20:55 <Deformative> I just feel like the advantage of packing is minimal, it is only useful for auto-implementing extremely trivial examples of duffs device and for very simple words which use a lot of machine calls.
23:22:23 <KipIngram> In a speed-optimized processor, which mine isn't right now, the execution speed of most opcodes (the ones that don't access memory) is much faster than a memory access.
23:22:42 <KipIngram> So getting several opcodes per memory access makes sense.  Otherwise you will be limited by your memory access speed.
23:22:47 <Deformative> I don't want to implement branch predictors.
23:22:49 <KipIngram> Your hardware will be waiting for data.
23:22:56 <Deformative> But I don't see another way to get prefetching working well.
23:22:57 <KipIngram> I don't either.
23:23:18 <KipIngram> I don't really mean prefetching future opcodes.
23:23:23 <KipIngram> My processor does this:
23:23:26 <KipIngram> S0: Fetch a cell
23:23:31 <KipIngram> S1: execute opcode 1
23:23:36 <KipIngram> S2 execute opcode 2
23:23:42 <KipIngram> S3 execute opcode 3
23:24:03 <KipIngram> When I optimize it S1, S2, and S3 can be much shorter than S0.
23:24:05 <Deformative> Don't you fetch one cell in the future?
23:24:24 <Deformative> For things like literal?
23:24:39 <KipIngram> The literal cell isn't fetched until the literal opcode is executed.
23:24:55 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
23:25:08 <KipIngram> So for those opcodes the execution state couldn't be shorter.
23:25:14 <Deformative> Oh.
23:25:16 <KipIngram> That's why this optimization will be less than trivial.
23:25:18 <Deformative> I thought you had tht fetched.
23:25:28 <KipIngram> Nope.
23:25:39 <KipIngram> IP points to it, so it's easy to do when I need it.
23:26:02 <Deformative> Ok, branching to the middle of a cell isn't bad at all then.
23:26:06 <KipIngram> And I *could* fetch it and store it somewhere if I wanted to, which might speed up certain things, like literal loads in slot 3.
23:26:34 <KipIngram> You still have to store in the target address the spot in the cell you want to branch to.
23:26:47 <KipIngram> This doesn't all fit in a 16-bit architecture anymore.
23:26:49 <Deformative> Return stack cells are 20 bits the way I am currently thinking.
23:26:57 <Deformative> Though, Iw oudl like a way to prefetch a little extra.
23:27:05 <KipIngram> You will have to have wider addresses in your code, wider return stack, etc. etc.
23:27:09 <Deformative> Oh!!
23:27:10 <Deformative> Idea.
23:27:24 <Deformative> You can always keep the top of the stack prefetched at all times.
23:27:32 <Deformative> That is trivial!
23:27:41 <KipIngram> My stack is a hardware stack - it's not in memory.
23:27:48 <Deformative> Mine too.
23:27:54 <KipIngram> Every stack element (data and return) are registers.
23:27:58 <Deformative> I am saying prefetch the address at that location.
23:28:00 <KipIngram> Then what do you mean by prefetching TOS?
23:28:13 <KipIngram> Oh.
23:28:29 <Deformative> Keep that instruction cell prefetched.
23:28:43 <KipIngram> You mean the return stack?
23:29:13 <Deformative> Ok. return stack holds addresses of instruction cells.
23:29:22 <Deformative> Keep the tos instruction cell prefetched.
23:29:40 <KipIngram> Yes, I can see some merit in that.
23:29:43 <KipIngram> Interesting idea.
23:29:43 <Deformative> Overwrite when you push to return stack, and ret can re-fetch it.
23:29:56 <Deformative> Only takes 18 extra bits to do.
23:30:27 <Deformative> Maybe 20.
23:30:29 <KipIngram> Most importantly, this shaves a cycle from return operations.
23:30:34 <Deformative> Yes.
23:30:43 <KipIngram> You don't need S0 for the fetch immediately following return.
23:31:26 <KipIngram> You're saying 16 bits for the cell content and then 2 more for the slot to return to?
23:31:44 <KipIngram> You'd need those two bits for every element of the return stack.
23:31:45 <Deformative> Yes, and potentially 2 more for the PC offset.
23:31:52 <Deformative> Indeed.
23:31:53 <KipIngram> Not just once.
23:31:58 <Deformative> I understand.
23:32:12 <Deformative> I was planning on having 20 bit return stack elements anyway.
23:32:28 <KipIngram> And this is only useful if you can call from the middle of a cell, which requires opcodes and a slot.
23:32:55 --- quit: forther (Ping timeout: 252 seconds)
23:32:59 <Deformative> It is still useful if you return to the beginning of a cell.
23:33:01 <KipIngram> I'm not seeing a code space win here.
23:33:14 <KipIngram> Yes, I do like the idea of prefetching the target content.
23:33:22 <KipIngram> Just not the extra bits for storing the return slots.
23:33:38 <Deformative> Well, it is still applicable for your model.
23:34:01 <Deformative> I am currently leaning toward return slots for mine.
23:34:03 <KipIngram> It might not always buy me anything.  If ret is in slot 1, then I see it when I'm in S0.
23:34:25 <KipIngram> In S0 I'm busy fetching the cell that contains the ret.
23:34:42 <KipIngram> And on the next cycle I'm "back" and fetching from the return address.
23:35:00 <KipIngram> So only if ret is in slot 2 or 3 does it help me.  But that's probably 2/3 of the time.
23:35:10 <Deformative> OH yeah, I keep forgetting that the next cell isn't prefetched.
23:35:18 <KipIngram> So that saves an average of 2/3 of a cycle per return operation.
23:36:08 <Deformative> I like the in-cell model because it is easily scalable to larger word sizes.
23:36:34 <Deformative> Still benifits if you scale to 32 and 64 bit words.
23:36:52 <KipIngram> I need to go to bed - I want to either run or cycle tomorrow morning.  Let's pick this up tomorrow.
23:37:13 <Deformative> Ok, maybe we will talk about the vga controller then as well.
23:37:15 <Deformative> Goodnight.
23:37:21 <KipIngram> Yes - that too.
23:37:22 <KipIngram> Night.
23:46:01 --- quit: alex4nder (Ping timeout: 240 seconds)
23:59:59 --- log: ended forth/10.04.24