00:00:00 --- log: started forth/10.04.25
00:26:19 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth
01:42:02 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
02:32:50 <ASau> If you're interested so much in ILP and Forth, find Tarasov's papers on TTA-stack hybrid architecture.
04:00:18 --- quit: kar8nga (Remote host closed the connection)
04:56:33 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
05:44:21 --- join: arquebus (~na@201.139.156.133.cable.dyn.cableonline.com.mx) joined #forth
06:02:25 --- quit: arquebus (Remote host closed the connection)
06:03:19 --- quit: foxes (Ping timeout: 260 seconds)
06:18:39 --- join: foxes (~flash@123.113.219.95) joined #forth
06:39:30 --- quit: kar8nga (Remote host closed the connection)
07:43:11 --- quit: crc (Ping timeout: 260 seconds)
07:44:42 --- join: crc (~charlesch@184.77.185.20) joined #forth
07:52:35 --- quit: crc (Ping timeout: 245 seconds)
07:54:22 --- join: crc (~charlesch@184.77.185.20) joined #forth
07:56:17 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
08:24:01 --- quit: ASau (Remote host closed the connection)
08:26:35 --- join: ASau (~user@83.69.227.32) joined #forth
09:04:03 --- join: alex4nder (~alexander@dsl093-145-168.sba1.dsl.speakeasy.net) joined #forth
09:27:57 --- quit: mathrick (Read error: Operation timed out)
09:31:05 --- quit: ygrek (Remote host closed the connection)
09:32:18 --- join: mathrick (~mathrick@users177.kollegienet.dk) joined #forth
09:33:37 --- quit: ASau (Quit: reboot)
09:34:11 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
09:39:56 --- join: ASau (~user@83.69.227.32) joined #forth
09:59:15 --- quit: ASau (Quit: reboot once again)
10:04:38 --- join: ASau (~user@83.69.227.32) joined #forth
10:25:10 --- quit: alex4nder (Quit: leaving)
10:49:55 --- quit: crc (Ping timeout: 248 seconds)
10:51:52 --- join: crc (~charlesch@184.77.185.20) joined #forth
10:57:10 --- join: segher (~segher@84-105-60-153.cable.quicknet.nl) joined #forth
11:47:01 <Deformative> KipIngram: What does your co opcode do?
11:48:10 <Deformative> ASau: I cannot ifnd them in my library
11:49:22 <Deformative> Is there another name?\
11:49:38 <ASau> Then look at RuFIG or find his company site.
11:50:05 <ASau> Hm.
11:50:24 <ASau> Maybe that wasn't Tarasov, some other person from RuFIG rather.
11:51:59 <ASau> http://www.google.com/search?q=forth+transport+triggered+architecture
11:52:12 <ASau> Chapyzhenka on the first page.
11:55:14 --- join: Snoopy_1611 (Snoopy_161@dslb-084-059-196-041.pools.arcor-ip.net) joined #forth
11:56:02 <Deformative> ASau: It isn't in my library for some reason.
11:56:17 <Deformative> Oh, there is a download there.
11:56:18 <Deformative> Cool.
11:58:45 --- quit: kar8nga (Remote host closed the connection)
12:19:53 --- quit: gogonkt (Ping timeout: 246 seconds)
12:21:50 --- join: gogonkt (~info@218.13.55.68) joined #forth
12:27:17 --- join: Quartus (~neal@CPE0022b0b24a15-CM001947482b20.cpe.net.cable.rogers.com) joined #forth
12:27:17 --- mode: ChanServ set +o Quartus
12:52:46 <Deformative> KipIngram: Currious, how come you don't have hardware multipliers? 
13:05:36 --- join: tathi (~josh@dsl-216-227-91-166.fairpoint.net) joined #forth
13:57:34 --- quit: qFox (Quit: Time for cookies!)
13:59:44 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
14:17:48 --- quit: Snoopy_1611 (Ping timeout: 276 seconds)
14:23:21 --- quit: kar8nga (Read error: Connection reset by peer)
14:23:48 --- join: Snoopy_1611 (Snoopy_161@dslb-088-068-211-240.pools.arcor-ip.net) joined #forth
14:33:25 --- quit: ygrek (Ping timeout: 245 seconds)
14:34:49 <KipIngram> Deformative: ... yet.  I just haven't studied the Spartan families mulitplier features enough to support them.
14:34:56 <KipIngram> That's on my long-term roadmap.
14:35:02 <Deformative> Oh I see.
14:35:06 <Deformative> What does the co opcode do?
14:35:14 <KipIngram> The co opcode exchanges the IP with the top of the return stack.
14:35:20 <KipIngram> Switches between two coroutines.
14:35:32 <KipIngram> I'm unsure about whether to keep that one.
14:35:44 <Deformative> Oh, yeah.
14:35:49 <Deformative> I am not putting htat one in.
14:36:13 <KipIngram> It's just that it's so damn easy.  The only real cost is that it takes one of the 32 opcodes.
14:36:23 <KipIngram> Hardware-wise is just as simple as it can be.
14:36:49 <Deformative> Also, why do you only have a unit shift?
14:36:55 <Deformative> Why not variable shift?
14:37:23 <KipIngram> Yeah - hardware complexity; that's all.
14:37:36 <KipIngram> Someone here also uses split and join as their primitives; I thought about that as well.
14:37:53 <Deformative> What do split and join do?
14:37:58 <KipIngram> Really though I just wanted to move forward and decided that the unit shifts were "good enough for now."
14:38:20 <KipIngram> Split separates a word into two words, split on a given bit line.
14:38:31 <KipIngram> Join takes to values, shifts one by a given amount, and ORs them.
14:38:46 <Deformative> Oh, I see.
14:39:02 <Deformative> I think the only bitwise logic I will implement is nand.
14:39:22 <Deformative> Bitwise logic is so easy to implement, but really, they are not used very often.
14:39:41 <ASau> Yeah, we know how to write addition with and, eor and shifts. :D
14:39:59 <KipIngram> I have others in there now but that would be easy to tweak later if I chose to.
14:40:12 <Deformative> So I am comfortable with requiring compounding them since I save opcodes.
14:40:29 <KipIngram> The opcodes that are most interesting to me right now is the control flow stuff asnd the memory access stuff.  I've sweated those pretty hard.
14:40:37 <Deformative> Same.
14:40:45 <Deformative> Those are the ones that are bottlenecks in most code.
14:40:50 <Deformative> Forth code anyway.
14:42:03 <Deformative> I am going to implement opcodes for vga and rand.
14:42:06 <Deformative> :D
14:42:42 <KipIngram> How will the vga opcode work?  What will it do?
14:43:13 <Deformative> I am thinking I will need at least 2 opcodes.
14:43:30 <Deformative> A few for setting registers, one for carrying out ops.
14:44:14 <Deformative> I could do it all on the stack, but I would like to keep my stack so that I pop at most two values at a time.
14:44:22 <Deformative> Makes it a bit simpler.
14:44:38 <KipIngram> Even popping two will complicate your hardware.
14:44:42 <KipIngram> Popping one is much better.
14:44:58 <Deformative> Popping 2 isn't that bad.
14:45:05 <KipIngram> Popping three is no harder than popping two.
14:45:17 <Deformative> I just need to add an additional line to my mux.
14:45:25 <KipIngram> Once you go beyond an element needing two possible inputs (above, below), the next logical cut is at four.
14:45:36 <KipIngram> Yes, but that line takes you from two inputs to three.
14:45:46 <KipIngram> In a Spartan 3 that can no longer be done in one LUT.
14:45:57 <Deformative> True.
14:46:01 <Deformative> But the verilog is simple.
14:46:12 <KipIngram> So you will double the amount of logic required for your stack.
14:46:34 <Deformative> I could actually make my vga opcode work on literals.
14:46:44 <Deformative> And dereference that address.
14:47:16 <Deformative> Well, I need to walk to a different room, I will be back on in like 15 minutes I  think.
14:47:17 <KipIngram> Ok.  But what will they *do* to get you your video stream?
14:47:25 <KipIngram> Ok; catch you soon.
14:47:44 <KipIngram> I need to make pizza dough anyway.  Hard to type with dough on my fingers.
14:51:37 --- quit: Deformative (Read error: Operation timed out)
15:06:45 --- join: Deformative (~8dd435b6@gateway/web/freenode/x-xoopemldcmvwfuul) joined #forth
15:07:02 <Deformative> Ok.
15:07:47 <KipIngram> Hey.  Still kneading.  But tell me your VGA signal flow will work.
15:09:17 <Deformative> I am not entirely sure yet. 
15:09:29 <Deformative> I am thinking that it will behave like literal does.
15:09:46 <Deformative> And it will take operands like x1, y1, x2, y2, color.
15:10:09 <Deformative> The operands will be contained in their own cell, potentially two.
15:11:53 <KipIngram> It will draw a line?
15:12:26 <Deformative> Not diagnally.
15:12:28 <KipIngram> Or paint a rectangle?
15:12:33 <Deformative> Rectangle.
15:12:45 <Deformative> I was thinking of only doing pixel by pixel.
15:12:56 <Deformative> Because most of what i do is pixel by pixel.
15:13:02 <Deformative> I might enable blanking the screen.
15:13:56 <KipIngram> So do you intend to have your processor take these parameters and generate actual RGB vs. time values, or do you expect there to be graphics hardware at a higher level and you're interfacing that?
15:16:43 <Deformative> I haven't looked too deeply into the interface yet.
15:16:54 <Deformative> I just KNOW I will have extra opcodes.
15:17:27 <Deformative> I will be able to talk more in depth tonight, I am dividing attention between exam review right now.
15:17:47 <KipIngram> So I think what you're talking about doing is manipulating the pixel data in a frame buffer using special-purpose opcodes.
15:17:57 <KipIngram> How that frame buffer data gets out to the display is still an open question.
15:18:19 <Deformative> Yes, precisely.
15:18:35 <Deformative> I know vga is analog, so the vga controller will need to operate concurrently with the cpu.
15:19:41 <KipIngram> Ok.  It's the other end of the process (frame buffer to DAC inputs) that interests me.  I'd enjoy seeing how well I could program my processor in Forth to serve as such a graphics controller.
15:21:01 <KipIngram> I'd enjoy trying to do an Ethernet controller the same way.  Present a socket interface on one side, and manage the analog interface to the the cable on the other.
15:21:18 <KipIngram> Or maybe not just a socket - maybe a whole TCP/IP stack.
15:21:49 <KipIngram> In my mind if you can interface a display, an ethernet cable, a mouse, and a keyboard you have a stand-alone system capable of surfing the web.
15:22:46 <KipIngram> Since my processor is small I could put an array of them in a decent-size FPGA; have one for each of those purposes (maybe one would share the keyboard and mouse) would let me have my own fully-programmable network machine.
15:23:21 <Deformative> Yeah, but you would need to interface a different controller, or really up the number of opcodes you have in your application specific cpu.
15:23:50 <Deformative> Or make several application specifics, each with their own extra opcodes.
15:24:07 <KipIngram> No - just memory map the interface to analog / digital conversion chips and rock and roll.
15:24:08 <Deformative> Basically, what you said, yeah.
15:24:22 <Deformative> Oh, memory mapping.
15:24:24 <Deformative> Interesting.
15:24:30 <Deformative> I had not considered that.
15:25:29 <KipIngram> I've presumed all along that my primary interface to the outside world would be via memory-mapped I/O ports.
15:25:46 * Deformative ponders.
15:25:57 <Deformative> It makes your memory io verilog more complex.
15:26:42 <KipIngram> For output you have a bunch of registers feeding output pins, and the "address" will get decoded into a load enable for each of them.
15:26:54 <KipIngram> For inputs you have to have a big ugly mux tree, but there's just no other way in an FPGA.
15:27:24 <Deformative> I like my specialized opcodes better.
15:27:39 <Deformative> More interesting for me.
15:27:46 <KipIngram> If you pipeline the mux tree (and you do have a register at every level because of how the CLBs work) then it can run really fast; just takes time to percolate in.
15:27:54 <KipIngram> It's your baby.
15:28:04 <KipIngram> Raise her the way you think is right.
15:28:23 <Deformative> Heh.
15:28:36 <KipIngram> Dad. ;-)
15:29:33 <KipIngram> I think the other thing I'd want on my "web machine" would be a SD memory card interface.
15:29:49 <Deformative> Earlier, when you were talking about the possibility of doubling the size of words fetched from memory, how is that done on an fpga?
15:30:23 <Deformative> Altera DE0 has everything except ethernet, but there are plenty of expansion pins to add that.
15:30:25 <KipIngram> The block memory is organized not as one big memory but as a bunch of small ones.
15:30:33 <KipIngram> Just wire them up side by side with a shared address.
15:30:51 <KipIngram> You have some flexibility in that regard when you declare the memory in Verilog.
15:30:59 <Deformative> Ok, I need to look up more information about how to write the block memory controller.
15:31:09 <Deformative> I think my board comes with a demo.
15:31:15 <KipIngram> Have you gotten hold of the Xilinx document that gives you the Verilog and VHDL instantiations for all the primitive features?
15:31:27 <Deformative> I kinda want to make my chip have a 32 bit word size.
15:31:40 <Deformative> I have an altera board, remember?
15:31:41 <Deformative> But yes.
15:31:57 <KipIngram> There really isn't a controller; you just declare the memory primitive and it has data in, data out, address, and control signals.  Wire it up to whatever you plan to have driving it.
15:32:05 <KipIngram> Oh, no, I thought you had a Xilinx.
15:32:12 <KipIngram> Ok - everything is different but probably similar.
15:32:16 <Deformative> If I get 32 bit word size, I can get 5 words per loop.
15:32:24 <Deformative> Easily.
15:32:30 <Deformative> Which would be rather optimal.
15:32:46 <KipIngram> Very easily; that leaves you seven bits to do some of the stuff I've done (conditionals, etc.) if you want to.
15:33:01 <Deformative> This is my board: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=364
15:33:19 <KipIngram> But as compact as Forth code is having 25 bits or so for an address is pretty generous.
15:33:47 <Deformative> I am trying to decide if I should write comparitor opcodes, they are much simpler, but also introduce an extra cycle when doing branches.
15:33:57 <Deformative> Rather than hardwiring them in the conditional branches.
15:34:29 <KipIngram> Oh, maybe not an SD memory card interface - maybe a USB stick interface would be better.
15:35:05 <Deformative> There is no possibility of me having enough time over the summer to get all that.
15:35:17 <Deformative> I even cut my stochastic algorithm playing.
15:35:27 <Deformative> I will just have time for the cpu, and a vga controller.
15:35:33 <Deformative> And an assembler.
15:35:37 <Deformative> At most.
15:35:50 <KipIngram> Well, that's a great start.  Absolutely fantastic.
15:36:16 <KipIngram> Don't forget to plan a little social time in there somewhere.  You're only in school once - enjoy it too.
15:36:39 <Deformative> Well, it is summer.
15:36:52 <Deformative> And I am only working for 9 weeks of it.
15:36:59 <Deformative> So I have 9 weeks to play with my fpga.
15:37:52 <Deformative> I mean, it won't be 9 weeks straight, there will be social time.
15:38:10 <Deformative> But I will have a ton of free time during the day when my friends are working and such.
15:39:05 <KipIngram> Sounds perfect.
15:39:39 <KipIngram> Before you start developing this code I presume you'll write a proper Forth "outer interpreter" that lets you manage source code on disk somehow?
15:39:49 <KipIngram> How do you intend to build your development environment?
15:40:14 <Deformative> A simple assembler in C.
15:40:52 <Deformative> Should only take a couple of days.
15:41:52 <KipIngram> Is it going to support colon definitions and a proper dictionary?
15:42:03 <KipIngram> Or just primitive operation assembly?
15:42:57 <Deformative> Well, colon definitions are more or less built into the assembly really.  Except there is no immediate/compile state, all colon definitions are manually compiled basically.
15:43:22 <Deformative> Dictionary isn't needed at runtime, just a bunch of labels.
15:43:40 <Deformative> I wasn't planning on making the device self programming.
15:43:43 <Deformative> I won't have time.
15:44:57 <KipIngram> Ok.  But you won't be writing Forth until you can write Forth. :-)  Ok, I guess it can "be Forth" if you write it that way and then translate it, but wow, having the environment manage all that for you is really nice.
15:45:52 <Deformative> Well, this isn't truely a forth, just a very forth-like stack machine.
15:46:06 <KipIngram> Here's where that First FIRST, then THIRD article might give you quick access to something usable.
15:46:09 <KipIngram> Yes, I see that.
15:46:40 <Deformative> I am not going to have a b and p registers I don't think.
15:46:43 <KipIngram> I think the key thing as to whether it's Forth or not has to do with how you do subroutine calls.
15:46:48 <Deformative> I think I work around them.
15:46:59 <KipIngram> In my processor I can put a full call and its address into a cell.
15:47:07 <KipIngram> Rather than requiring "call" opcodes.
15:47:17 <Deformative> Mine is a hybrid of sorts.
15:47:17 <KipIngram> I think that makes my processor "closer to real Forth" than one that used a call opcode.
15:47:31 <KipIngram> Essentially my hardware knows how to thread.
15:48:01 <Deformative> Makes sense, but if you want to go with such purity, why not memory map opcodes?
15:48:16 <Deformative> And then it can be true threading.
15:49:00 <KipIngram> You mean treat them as subroutine calls?  With return stack overhead and everything?
15:49:47 <Deformative> No, no stack overhead, colon words would have "push"
15:50:06 <Deformative> It would just have a huge overhead for strings of opcodes.
15:50:16 <Deformative> In terms of memory usage for the program itself.
15:50:20 <Deformative> And prefetching speed.
15:51:15 <Deformative> Well actually, yours basically already does it.
15:51:30 <Deformative> It just encodes opcodes so they take less space.
15:51:32 <Deformative> Nevermind. :)
15:52:09 <Deformative> Yours is much more forth inspired than mine. 
15:52:46 <KipIngram> I hope so, because that was my goal from the very outset. - to cast Forth into hardware as directly as I possibly could.
15:53:06 <Deformative> Mine is direct threaded, yours is indirect threaded.
15:53:25 <KipIngram> No, mine is direct threaded.
15:53:44 <Deformative> O.o
15:53:51 <Deformative> I am not so sure, gimmi a few seconds to think.
15:54:25 <KipIngram> When I compile a colon definition the cell content is a pointer that points straight at the definition itself, which might be primitive opcodes.
15:54:32 <KipIngram> There is no intervening extra pointer.
15:54:49 <Deformative> Right.
15:54:55 <Deformative> Mine doesn't either though..
15:55:04 <KipIngram> So they are both direct threaded.
15:55:12 <Deformative> Right.
15:55:15 <Deformative> Makes sense now.
15:56:48 <Deformative> I am trying to figure out what makes mine less forth like.
15:57:01 <Deformative> I have explicit calls, but so you do,  your's are just different.
15:57:26 <KipIngram> My call fits in the same cell as the target address.  I think that's the difference.
15:57:39 <KipIngram> But that's just a quantitative difference, so if you disagree I'm cool with that.
15:57:53 <Deformative> That is the difference.
15:58:05 <Deformative> But I don't see how that makes it less/more forthy.
15:58:17 <KipIngram> I'm cool with that.
15:58:49 <KipIngram> I'm starting on my third beer, so I'm cool with most anything at the moment. :-)
15:58:59 <Deformative> Heh.
15:59:16 <KipIngram> Keystone Light, though, so that's really like about one real beer, I think.
15:59:37 <Deformative> I don't know.  I don't drink yet.
15:59:59 <KipIngram> It's only about 4% alcohol by volume - pretty tame stuff.
16:00:31 <Deformative> Well, the name 'light' would imply that I think.
16:00:52 <KipIngram> True.
16:01:21 <KipIngram> It's cheap, so when I'm not brewing my own I keep a supply of it around.
16:01:54 <KipIngram> When I brew my own I wind up with similarly light beer that tastes better and approaches $1 for a six pack. :-)
16:01:59 <Deformative> Brewing beer seems interesting.  But only because I am fascinated by micro-organism culture.
16:02:13 <KipIngram> Yes, I culture my own yeast sometimes.  When I have time.
16:02:24 <KipIngram> Yeast is very cool.
16:02:45 <Deformative> Yeah, I culture yeasts, bacteria, phytoplankton, and plenty of zooplanktons for my aquarium.
16:02:55 <KipIngram> You can harvest yeast from certain beers (that sell with live yeast in them - like Sierra Nevada) and culture it up and then use it for your own beer.
16:03:09 <Deformative> I had considered trying out sourdough yeast cultures, never got around to it.
16:03:35 <KipIngram> I've made several runs at a sourdough process - it goes great for a while and then I get to busy to bake with it and it dies.
16:03:52 <KipIngram> Always fun to see how my wife wrinkles her nose at how it looks in there.
16:04:10 <Deformative> Heh.
16:04:27 <Deformative> Plankton cultures are fun if you manage to get them self sustaining.
16:04:31 <Deformative> Very difficult though.
16:04:35 <Deformative> Most people get constant crashes.
16:04:38 <KipIngram> Baking bread interests me and all, but in the end bread is so cheap that you don't gain a whole lot by making your own.  So I wind up doing it only occasionally when I just feel like it.
16:04:58 <KipIngram> Do you do anything with plankton other than aquarium work?
16:05:36 <Deformative> Not really.
16:05:52 <Deformative> It is useful for raising baby fish and feeding coral mostly.
16:06:48 <KipIngram> Interesting.  What do they eat?  The plankton.  Are they photosynthetic?
16:07:31 <Deformative> Phytoplankton are photosynthetic, bacterioplankton eat organics, zooplankton eats phytoplankton and/or bacterioplankton and/or organics.
16:08:11 <Deformative> Most people end up with crached phytoplankton cultures, because they get contaminated by bacteria or zooplankton.
16:08:40 <Deformative> But I have isolated a strain of phyto so strong that it is very difficult to crash.
16:09:12 <Deformative> I got too much of it in my aquarium once, and it boomed, so my aquarium was green for months before I got it to crash.
16:10:03 <KipIngram> I've given thought to raising tilapia in a tank - for personal consumption.  I've read about filtering the water through the soil of a vegetable garden - it cleans the water for the fish and fertilizes the soil for the veggies.
16:10:13 <KipIngram> The main thing stopping me has been "what would I feed the fish?"
16:10:27 <KipIngram> Could plankton get me there?
16:10:38 <KipIngram> What sort of scale can this be done on?
16:11:02 <Deformative> Nope, it is only useful for fry(babies)
16:11:05 <KipIngram> I love the phytoplankton idea - that way the energy ultimately comes from the sun.
16:11:07 <Deformative> For adult fish, it won't work.
16:11:23 <KipIngram> Ok, so could I raise fry of some sort tha the bigger fish then ate?
16:11:26 <Deformative> You would need to culture phytoplankton -> zooplankton -> small fish -> big fish.
16:11:30 <Deformative> Unlikely at best.
16:11:39 <KipIngram> Yes, sounds involved.
16:11:53 <Deformative> I don't know off hand what tilapia eat.
16:11:58 <KipIngram> Especially when this isn't "what I do"; it would be an entertainment thing at best.
16:12:04 <Deformative> But culturing mollies or guppies is trivial.
16:12:10 <KipIngram> Neither do I - I've never delved very far into this.
16:12:33 <Deformative> If I remember correctly, tilapia are detrivores.
16:12:49 <KipIngram> :-)  I don't even know what that means.
16:13:12 <Deformative> "primarily vegetarian diet"
16:13:13 <Deformative> Easy
16:13:25 <Deformative> You can do that without any plankton.
16:13:29 <KipIngram> Oh.  Ok.  So maybe I just chop up some of my vegetables and feed them that.
16:13:29 <Deformative> Just seaweed and such.
16:13:33 <KipIngram> That's certainly simple.
16:13:35 <Deformative> Yesh.
16:13:41 <KipIngram> Hmmm.
16:13:44 <KipIngram> Interesting.
16:13:47 <Deformative> I thought they were detrivores or carnivores.
16:13:55 <Deformative> Detrivores eat waste material.
16:14:01 <KipIngram> Ok - time to go for a run.  I'll be back later.
16:14:12 <Deformative> Yep, my battery is running low anyway.
16:14:19 <Deformative> Talk to you later.
16:14:23 <KipIngram> I did 6 miles yesterday - I think I'll try to do that again today.
16:14:36 <Deformative> Sounds just aweful.
16:14:51 <Deformative> I hate physical most activity other than wakeboarding.
16:14:55 <KipIngram> Not really.
16:15:05 <Deformative> Wakeboarding I actually enjoy.
16:15:21 <KipIngram> You're young and you can get away with murder at this point.  Just know that at some point (10-12 years out or so) you will need to work your body to keep it healthy.
16:15:36 <KipIngram> Otherwise it just gets weaker and weaker all the time.
16:15:44 <Deformative> :/
16:15:50 <Deformative> I am not coordinated.
16:15:56 <KipIngram> The "candle of youth" burns out in the early 30's.
16:16:09 <KipIngram> After that you have to work for your good health.
16:16:15 <Deformative> Well, it is not uncommon to live past 90 in my family.
16:16:24 <Deformative> I think I will be ok.
16:16:46 <Deformative> Then again, my family used to be dairy farmers.. So they had a lot of work to do.
16:17:34 <KipIngram> Well - I'm going now to do my work for the day.  Catch you later.
16:17:41 <Deformative> Yep. o/
16:20:30 --- quit: Quartus ()
16:22:00 --- quit: Deformative (Ping timeout: 252 seconds)
17:26:28 --- join: Deformative (~joe@bursley-185022.reshall.umich.edu) joined #forth
17:33:27 --- quit: Snoopy_1611 (Ping timeout: 276 seconds)
17:56:55 <KipIngram> Back now.
17:58:12 <Deformative> Me too.
17:58:34 <tathi> Hi guys
17:58:39 <Deformative> Hi tathi.
17:59:41 <tathi> Deformative: get your Forth project done?
17:59:47 <Deformative> Yep.
17:59:56 <Deformative> I don't know what grade I got.
18:00:00 <Deformative> But I think I did well.
18:00:09 <tathi> Cool.
18:00:45 <Deformative> ^^
18:01:31 * tathi has just been hanging out with a guy juggling clubs for the first time in about four years.
18:01:37 <tathi> Amazing how much I suck. :)
18:01:56 <Deformative> Weird.
18:02:06 <Deformative> Like literally juggling?
18:02:20 <tathi> Yup.
18:03:05 <tathi> My one uncle is an entertainer, and his son is just my age, so I've always messed around with that sort of stuff.
18:03:18 <tathi> Juggle, unicycle, stilt-walk, and so on.
18:03:31 <Deformative> I see.
18:04:29 <tathi> None of it is at all useful, but it's fun. :)
18:05:30 <tathi> Actually, the unicycle was nice at college.  Faster than walking, but you don't have to lock it up like a bicycle.
18:05:51 <tathi> Almost nobody will steal a unicycle. :)
18:06:07 <Deformative> xD
18:12:40 <KipIngram> tathi: That had to have been a great conversation starter with the opposite gender too.
18:12:53 <Deformative> Haha.
18:13:13 <tathi> True that.
18:13:18 <crc> unicycles are fun :)
18:18:53 <Deformative> So far, here are the opcodes I have decided on:
18:18:55 <Deformative> nop rand unext 
18:18:57 <Deformative> call ret literal 0branch
18:18:58 <Deformative> >r r> @ !
18:19:00 <Deformative> dup drop swap over 
18:19:01 <Deformative> + * / - 
18:19:03 <Deformative> << >> nand <
18:21:07 <tathi> rand?
18:21:12 <Deformative> Random. :)
18:21:22 <Deformative> (--random)
18:21:28 <Deformative> I want a hardware random number generator.
18:22:07 <tathi> Gotcha.
18:23:12 <Deformative> I wish I could find a way to eliminate nop...
18:23:19 <Deformative> It just kills me to require nop.
18:23:30 <Deformative> "Taking up time" is equivalent to "wasting time"
18:23:42 <tathi> Why do you need nop?
18:23:52 <tathi> Oh, because you're packing instructions into words
18:23:57 <Deformative> Yes.
18:24:07 <tathi> And you need to be able to pad things out so you can branch to a particular point.
18:24:11 <Deformative> I might make nop run some prefetches and flush buffers.
18:24:43 <Deformative> If I implement sub-word jumps, then I can get rid of nop.
18:24:45 <Deformative> Which I may do.
18:25:32 <tathi> Would you sacrifice range, or make your jump instruction take up more space?
18:25:57 <Deformative> Requires "literal >r ret" rather than "branch" but it enables more fetching.
18:26:15 <Deformative> Because literal, >r, and ret all prefetch.
18:26:58 <Deformative> But now unext is rendered almost useless. D:
18:27:21 <tathi> What's unext again?
18:27:32 <Deformative> Used for microloops.
18:27:58 <Deformative> Basically eliminates need for duffs device.
18:28:08 <tathi> There's a need for duff's device? :)
18:28:43 <Deformative> Well, loop unrolling.
18:28:54 <Deformative> A microloop is faster than an unrolled loop.
18:28:54 <tathi> yeah, I see.
18:31:43 <Deformative> Hmm...
18:31:44 <KipIngram> It's easy to make the hardware skip execution of those nops.
18:31:51 <KipIngram> So they take up space only but not time.
18:32:12 <Deformative> I am not so sure.
18:32:30 <KipIngram> In my hardware I do this, as I mentioned last night:
18:32:38 <Deformative> I know.
18:32:50 <Deformative> I haven't thought about it with prefetching yet.
18:32:55 <Deformative> I feel like it might kill prefetching.
18:33:06 <KipIngram> If the last slot is a nop, for instance, just don't go from state 2 to state 3 - go from state 2 to state 0.
18:33:17 <KipIngram> If the last two are nop then go from S1 to S0.
18:33:53 <Deformative> Yeah, you're right.
18:33:56 <Deformative> Not too difficult.
18:34:03 <Deformative> My unexts are always infinite loops.
18:34:11 <Deformative> They must be escaped with a 0branch.
18:34:53 <ASau> I doubt Duff's device optimization is relevant at all.
18:35:03 <ASau> It isn't met frequently enough.
18:35:13 <KipIngram> So that's really a ubranch, then.  
18:35:26 <KipIngram> NEXT is the tail end of a for ... next structure; it's a counted thing.
18:35:30 <Deformative> Yeah, but the 0branch takes an extra cycle anyway.
18:35:33 <Deformative> So it is pointless.
18:35:39 * Deformative removes unext.
18:35:41 <Deformative> :/
18:35:49 * KipIngram keeps unext.
18:35:55 <KipIngram> :-)
18:35:57 <Deformative> Heh.
18:37:11 <KipIngram> Ah - just pulled my pizza out of the oven.
18:37:11 <Deformative> unext makes life difficult for the assembly programmer.
18:37:27 <KipIngram> Why?
18:37:50 <Deformative> They need to keep track of what is packed in a cell.
18:38:10 <KipIngram> Oh, yes, I do expect the programmer (or the compiler) to keep track of cell boundaries.
18:38:22 <Deformative> Mine is transparent.
18:38:31 <Deformative> But less optimal for such things. :/
18:38:34 <KipIngram> You already have to do that to know how to pack to a cell boundary for jump targeting purposes.
18:38:51 <KipIngram> I write my assembly three opcodes per line.
18:39:13 <Deformative> Makes sense.
18:39:25 <KipIngram> And I imagine when I get a full compiler working I will still write my code in "three primitive phrases"
18:39:40 <KipIngram> : word   blah blah blah     blah blah blah     blah blah blah  ;
18:39:43 <KipIngram> and so on.
18:40:19 <KipIngram> Waltz time. ;-)
18:40:41 <Deformative> Heh.
18:40:52 <Deformative> I am trying to make it scalable to words larger than 16.
18:41:32 <KipIngram> Are Altera block RAM structures dual-ported?  Xilinx block rams are.
18:41:39 <Deformative> That is what fundamentally drives my design in a different direction than yours.
18:41:49 <KipIngram> This means I can use one port for the instruction fetching and the other for word-driven memory accesses.
18:41:54 <KipIngram> And those don't have to have the same width.
18:42:10 <KipIngram> So my instruction fetches can be 16 bits, but if I wanted a 32-bit data path I could have that on the other port.
18:43:03 <Deformative> I haven't looked into the internals in that much depth yet.
19:00:15 <Deformative> KipIngram: What is the name of the block memory, it isn't the sdram is it?
19:00:32 <Deformative> I thought that most fpgas came with a faster hunk of memory for making caches and things.
19:23:10 <Deformative> Wait.. unext is still useful.
19:23:18 <Deformative> If it doesn't branch out, it still is optimal.
19:23:39 <Deformative> Though... Branches are slow.
19:23:49 <Deformative> Since I don't have A B or P registers.
19:24:07 --- quit: TR2N (Ping timeout: 260 seconds)
19:25:24 --- join: ContraSF (email@89-180-229-37.net.novis.pt) joined #forth
19:30:09 --- join: nighty__ (~nighty@210.188.173.245) joined #forth
19:30:37 <Deformative> Crap.
19:30:41 <Deformative> I just thought of a problem.
19:31:02 <Deformative> KipIngram: If you have if literal then litera
19:31:04 <Deformative> l
19:31:10 <Deformative> How dos that compile for you?
19:31:39 --- quit: tathi (Quit: leaving)
19:34:56 --- quit: mathrick (Ping timeout: 246 seconds)
19:35:34 --- quit: ContraSF (Ping timeout: 264 seconds)
19:40:50 --- join: ContraSF (email@89.180.196.239) joined #forth
19:53:26 <KipIngram> In my architecture if literal-A then literal-B would best be done like so:
19:53:36 <KipIngram> : litA literal-A ;
19:53:56 <KipIngram> And then do a !0 conditional compilation of litA in the higher level definition.
19:54:49 <KipIngram> That would take just one cycle when the if failed and three cycles when it succeeded.
19:55:18 <KipIngram> I'm a bit busy right now, but I'll be back later.
20:00:28 <Deformative> Ok.
20:00:45 <Deformative> Kills my model.
20:00:49 <Deformative> Talk to you later.
20:27:14 <KipIngram> Kills your model how?
20:28:29 <KipIngram> I've removed conditional opcodes from my instruction set.  But, I could also do it like this.
20:28:37 <KipIngram> One second while I get it straight in my head.
20:30:15 <KipIngram> I do conditional jumps with a full cell, conditionals set, no push of the return address.  So:
20:30:37 <KipIngram> x+0: jz x+4
20:30:47 <KipIngram> x+2: nop nop @p+
20:30:51 <KipIngram> sorry.
20:30:57 <KipIngram> x+0: jz x+6
20:31:03 <KipIngram> x+2: nop nop @p+
20:31:08 <KipIngram> x+4: literal-A
20:31:27 <KipIngram> x+6: @p+ <something 1> <something 2>
20:31:33 <KipIngram> x+8: literal-B
20:31:38 <KipIngram> and so on.
20:31:58 <KipIngram> <something 1> and <something 2> would just be whatever opcodes came after all of this.
20:33:11 <KipIngram> So it doesn't have to use a separate colon definition; I can put what would have been in that separate definition inline and jump around it on zero instead of call to it on nonzero.
20:33:27 <Deformative> It would be difficult for the opcodes to associate with literals.
20:33:37 <KipIngram> What do you mean?
20:34:51 <Deformative> Because everything but opcodes needs it's own word.  So it would be [ifcode, litcode, litcode] [branchaddr] [litnum] [litnum]
20:35:41 <Deformative> It would be difficult for each litcode to associate with the proper litnum.
20:35:49 <KipIngram> That wouldn't work.
20:36:11 <Deformative> Indeed.
20:36:25 <Deformative> Well... It's possible..
20:36:27 <Deformative> Just difficult.
20:36:46 <KipIngram> I think you'd have to have [ifcode litcode nop] [branchaddr] [literal-a] [litcode <something> <something>] [literal-b]
20:37:04 <Deformative> Would need to check each opcode in a word and check if it is a opcode which has trailing operands.
20:37:05 <KipIngram> You have to move the second litcode out of the area affected by the if.
20:37:45 <Deformative> See, I wanted to bring my wordsize up to 32, so I would have a TON of nops.
20:37:48 <Deformative> Which kills the model for me.
20:37:50 <KipIngram> Yep.
20:37:52 <KipIngram> I see now.
20:38:11 <KipIngram> Yes, I contemplated a 32-bit machine as well and settled on a 16.  Not exactly the same thought process as you, but many of the same issues.
20:42:35 <Deformative> But yes, I can just count opcodes with operands.
20:42:43 <Deformative> Not the best solution, but it works.
20:42:56 <Deformative> Also hurts prefetching a ton.
20:43:59 <KipIngram> Explain what you mean - are you proposing that you don't need the nop in my version of your code?
20:44:15 <KipIngram> That second litcode has to be targetable by the jump instruction.
20:44:25 <KipIngram> So it has to be in a new cell.
20:44:50 <KipIngram> If the ifcode takes the branch then it will skip the first litcode, which you want, but it also skips the second, which youd on't want.
20:46:05 <Deformative> Yeah.
20:46:42 <Deformative> I can analize each opcode in the word, and check if it is one of the opcodes with operands.
20:46:54 <Deformative> So the second litcode would see that there is one litcode before it.
20:46:58 <Deformative> So it knows to use the second word.
20:47:47 <KipIngram> You're talking about having the compiler figure all this out, right?  Sure - that would work.
20:48:00 <KipIngram> I plan to keep up with my three code phrases and put nops in myself when I need to.
20:48:05 <Deformative> But then I need to prefetch wordsize/4 words after the current word.
20:48:16 <KipIngram> ?
20:48:26 <KipIngram> So you are talking about some kind of runtime process.
20:48:32 <Deformative> Yes.
20:48:48 <Deformative> Prefetching that many words is not pratical.
20:48:49 <KipIngram> Actually I probably will have the compiler do it.
20:48:54 <KipIngram> The above code would look like this:
20:49:11 <Deformative> How is that possible?
20:49:17 <KipIngram> <... flag computation ...> IF <literal value> THEN <literal value> 
20:49:54 <KipIngram> the IF will compile the 0branch with a currently unknown address, and will save the address that needs backpatching with the address on the stack.
20:50:38 <KipIngram> The first literal value will just compile as normal - it will compile a @p+, put the value on the stack to compilation after the ongoing cell is complete, and continue.
20:50:42 <KipIngram> But then we see THEN.
20:51:22 <KipIngram> The compiler says "hey, I've compiled one slot of a cell and I have a literal waiting to go after that.  So I need to 1) finish the cell by compiling nop nop, 2) tick the waiting literal into the dictionary, and 3) backpatch the jump address.
20:51:41 <Deformative> Yeah, your model is solid.
20:51:43 <Deformative> Mine has holes.
20:53:39 <KipIngram> Mine has had many holes along the way.  You've just started thinking about some of these things.
20:54:48 <Deformative> Well...
20:55:21 <KipIngram> Hmmm.  I don't think my conditional jumps and calls currently pop the stack.  I'd want them to drop the flag after using it for the jump/call decision, wouldn't I?
20:56:10 <Deformative> I can put an extra couple of bits after opcodes which have operands.
20:56:19 <Deformative> The index of the operand.
20:56:32 <Deformative> That... "works"
20:56:34 <KipIngram> I think that's easy - if I see that it's an EA cell (bit 15 set) and that it's a conditional cell, then I trigger a stack pop, whether I make the control transfer or not.
20:56:56 <KipIngram> I don't think I understand the problem you think you have.
20:57:36 <KipIngram> These opcodes that have operands just move the IP over the operand when they execute.  You don't need to know anything in advance about upcoming opcodes that have operands.
20:58:05 <KipIngram> That's actually not true.  I do look one opcode into the future all the time.
20:58:28 <KipIngram> If I see that the *next* opcode has an operand then I go ahead and fetch the cell IP is pointing to and bump IP forward.
20:58:36 <Deformative> No, but I need to know about earlier opcodes with operands.
20:58:48 <Deformative> Because my operands are not always the word immediately after.
20:58:52 <KipIngram> Then on the following cycle when that opcode actually executes the necessary operand is on the memory output lines.
20:59:20 <KipIngram> But if they're not it's because there was another operand in the way associated with an earlier opcode, right?
20:59:22 <KipIngram> Like this:
20:59:41 <KipIngram> [ @p+ @p+ @p+ ] [ literal 1 ] [ literal 2 ] [ literal 3 ]
20:59:52 <KipIngram> literal 3 is associated with the third @p+.
20:59:57 <Deformative> Yes.
20:59:57 <KipIngram> So there are two intervening cells.
21:00:01 <Deformative> Yes.
21:00:09 <KipIngram> But to get to the third @p+ you had to pass the first two, and each of them moved IP forward.
21:00:18 <KipIngram> By the time you come to the third one IP is pointing to the third operand.
21:00:23 <KipIngram> It "just works."
21:00:27 <KipIngram> Very nicely, in fact.
21:00:43 <Deformative> It does not work if there is a branch within the list.
21:00:49 <Deformative> Unless I keep that in the return stack.
21:00:50 <KipIngram> I don't have such branches.
21:00:51 <Deformative> Which I might do.
21:00:55 <Deformative> I do.
21:01:15 <KipIngram> Then you will need to break the offending sequences by inserting nops.
21:01:35 <Deformative> I.. I don't think so.
21:02:01 <KipIngram> So if you had this:
21:02:09 <Deformative> I have the opcode index included in labels.
21:02:29 <KipIngram> [ @p+ 0branch @p+ ] [literal 1] [ branch target ] [literal 2 ]
21:02:34 <KipIngram> Is that the kind of sequence you mean?
21:02:46 <KipIngram> I don't see why that wouldn't work.
21:03:02 <Deformative> No, I mean if if something branches to where that 0branch is.
21:03:08 <KipIngram> Whether the branch is taken or not IP still moves over the branch target and points to literal 2.
21:03:10 <Deformative> If that is on the recieving end of the branch.
21:03:12 <Deformative> Not the sending end.
21:03:29 <KipIngram> Oh.  You're still trying to figure out how to branch into the middle of a cell.
21:03:34 <Deformative> I am determined ot have word calls within microloops.
21:03:35 <Deformative> Yes.
21:03:52 <KipIngram> So you want to be able to return to the middle of a cell.
21:03:58 <Deformative> Yes.
21:04:05 <Deformative> But it breaks the literal stuff.
21:04:26 <Deformative> But I just figured out I can put extra information in the return stack.
21:04:28 <Deformative> So it should work.
21:04:31 <KipIngram> Look, you're going to have to think of your memory as a collection of opcode-size words, then.
21:04:38 <KipIngram> With each one having its own address.
21:04:45 <Deformative> Yep.
21:05:04 <KipIngram> How many bits per opcode?
21:05:07 <Deformative> 4
21:05:13 <Deformative> I am thinking 32 per word.
21:05:23 <KipIngram> So you plan to have seven opcodes packed per word, then?
21:05:37 <Deformative> Erm, 5 bits per opcode.
21:05:38 <Deformative> Sorry.
21:05:46 <KipIngram> Six opcodes per word?
21:05:47 <Deformative> So 6 opcodes per word.
21:05:49 <Deformative> Yes.
21:06:24 <KipIngram> Ok.  So I think you need to think of it that way.  Think of your 32 bit cell as occupying six consecutive addresses.
21:07:04 <KipIngram> So if a cell isn't opcodes but rather is an EA cell it will have 30 bits for the EA?
21:07:08 <KipIngram> That's a gorgeous plenty.
21:07:19 <KipIngram> Even if what you're addressing is five bit slugs.
21:07:36 <KipIngram> In fact you could take some more bits for conditional flags, etc.
21:07:41 <KipIngram> You've got way more than enough.
21:08:09 <KipIngram> One of the two leftover bits [31:30] will tell you whether it's an opcode word or an EA word.  Right?
21:08:49 <Deformative> There is no reason for using those two extra bits.
21:09:04 <Deformative> Word calls do not have their own cells.
21:09:18 <Deformative> They are an opcode, then the addr is in it's own word as an operand.
21:09:22 --- join: cataska (~cataska@210.64.6.233) joined #forth
21:10:09 <KipIngram> You're giving up a big space savign opportunity then.
21:10:16 <KipIngram> Let's say you have a series of colon definition calls.
21:10:19 <KipIngram> You will have this:
21:10:24 <KipIngram> [ call nop nop nop np ]
21:10:29 <KipIngram> [ address ]
21:10:35 <KipIngram> [ call nop nop nop nop ]
21:10:36 <Deformative> No.
21:10:38 <KipIngram> [address]
21:10:44 <KipIngram> ok - what will you have, then?
21:11:04 <Deformative> I will have [call call call call call call] [addr0] [addr1] [addr2] etc etc
21:11:23 <KipIngram> Oh, because you can return to the middle of a cell.
21:11:28 <Deformative> Yes.
21:11:39 <KipIngram> Wow - you've got a lot to manage there.  That's going to get complex.
21:11:56 <Deformative> ...yeah...
21:12:02 <KipIngram> Because your IP will no longer reference the word you're actually returning to.
21:12:14 <KipIngram> You've effectively got two things to keep up with: a control point and an operand point.
21:12:18 <Deformative> It might be easier to just have variable length opcodes.
21:12:28 <Deformative> And account for operands in the opcode.
21:12:32 <Deformative> But I wanted to avoid that.
21:12:34 <KipIngram> But see, if you *use* those extra bits you get this:
21:12:41 <KipIngram> [ call to addro0 ]
21:12:47 <KipIngram> [ call to addr1 ]
21:12:49 <KipIngram>  etc.
21:12:56 <KipIngram> Very tidy and very easy to keep up with.
21:13:03 <Deformative> But you cannot micro loop over those calls.
21:13:31 <KipIngram> How is your microloop going to know how to restore the IP that's looping over the address list?
21:13:42 <Deformative> It is 0.
21:14:01 <KipIngram> So it will just go back to the code cell address plus one?
21:14:02 <KipIngram> Ok.
21:14:11 <Deformative> Yep.
21:14:14 <KipIngram> That seems like it might work.
21:14:32 <KipIngram> So your unext will set the slot back to slot 0 of the current code word.
21:14:43 <KipIngram> And the operand IP back to the address of the current code word + 1.
21:14:45 <KipIngram> Very nice.
21:14:48 <Deformative> Correct.
21:15:00 <Deformative> I will not call it unext though.
21:15:02 <KipIngram> That's starting to have a nice feel to it.
21:15:08 <KipIngram> No, not if it's not counted.
21:15:22 <Deformative> It will have condition on the return stack.
21:15:25 <Deformative> I decided I liked that. :)
21:15:47 <Deformative> But I will have 2 microwords, one for jumping to next word and another for jumping back to beginning of this word.
21:15:56 <Deformative> I don't know what to call them though.
21:16:04 <Deformative> ucurrent unext maybe.
21:16:07 <KipIngram> Call the second one break.
21:16:08 <Deformative> But that is kinda ugly.
21:16:14 <Deformative> I like that!
21:16:17 <Deformative> Break is fantastic.
21:16:20 <Deformative> ubreak ulook
21:16:21 <Deformative> I like that.
21:16:23 <KipIngram> Call the first one back.
21:16:27 <Deformative> ubreak uloop
21:16:32 <Deformative> I like loop.
21:16:37 <KipIngram> Ok, loop is better.
21:16:57 <KipIngram> And you're going to make uloop unconditional?
21:17:22 <Deformative> I think I will make them both conditional.
21:17:35 <Deformative> Either both conditional, or just ubreak will be conditional.
21:17:39 <Deformative> I haven't decided yet.
21:17:39 <KipIngram> How many cells will this work over?
21:18:11 <Deformative> One cell, so 5 opcodes not including the ucode itself.
21:18:31 <KipIngram> Where will the ucode go then?
21:18:46 <Deformative> Wherever you want the branch to occur.
21:19:01 <KipIngram> Oh, right, you have six opcodes per word.
21:19:03 <Deformative> [ ... uloop ]  Or [ ... ubreak ... ]
21:19:08 <Deformative> Correct.
21:19:15 <KipIngram> And you have to update a condition flag as part of those five opcodes?  On the return stack??
21:19:25 <Deformative> ubreak makes small conditional loops very easy.
21:19:26 <KipIngram> I don't know that you're going to have any opcodes left to do useful work.
21:19:55 <Deformative> Well word calls are also only one opcode remember.
21:19:59 <KipIngram> You probably want the condition code on the data stack.
21:20:06 <KipIngram> Saves you from having to spend an opcode on >r.
21:20:07 <Deformative> So the word calls have the potential of updating the condition.
21:20:14 <KipIngram> Oh, true.
21:20:19 <Deformative> Yes, that too.
21:20:20 <KipIngram> Alright.
21:20:22 <Deformative> I can use the data stack.
21:20:33 <KipIngram> Especially since your word calls need the return stack.
21:20:43 <Deformative> It gets more useful in 64 bit, but 64 bit takes WAY too much logic.
21:20:56 <Deformative> 32 will probably be pushing it.
21:22:12 --- nick: ContraSF -> TR2N
21:22:22 <Deformative> Just saying "forget it" and making an 8 bit architeture is also a possibility.
21:22:30 <Deformative> Then forget about opcode packing all together.
21:22:38 <Deformative> But I am rather fond of this 32 bit plan.
21:22:44 <Deformative> So I will see where this takes me.
21:23:23 <KipIngram> Now I will hand you back the food for thought you gave me the other night.
21:23:58 <KipIngram> Using your microloop scheme, how fast can you 1) fill a block of RAM with zero or some other literal value, and 2) copy one block of RAM to another location?
21:24:30 <KipIngram> I got that down to one cycle per cell on fill and two cycles per cell on copy.
21:24:37 <KipIngram> Which is hardware optimum.
21:25:00 <KipIngram> That's neglecting the little bits at the beginning and end, which become negligible if the blocks are large enough.
21:25:32 <Deformative> Hmm.. 1+@swap 1+!swap uloop
21:25:43 <Deformative> Where 1+@swap are word calls.
21:26:02 <Deformative> So it takes uhh, 11 cycles per word copied. :(
21:26:08 <KipIngram> ;-)
21:26:27 <KipIngram> The counted loop approach really worked well for this.
21:26:48 <Deformative> Yeah, but it is just so difficult to program using.
21:26:58 <Deformative> Those words are very non-general.
21:28:10 <Deformative> And I think that those specific words would make writing a compiler difficult.
21:28:29 <KipIngram> But they're not.  Let's say that uloop (which you might rename to unext if it's counted) decrements the top of return stack and then jumps back if the count is >= 0.
21:28:45 <KipIngram> So if you want to force this to be the last pass through the loop just zero the top of return stack.
21:28:55 <KipIngram> You can still treat it as a flag, even though unext will treat it as a counter.
21:29:01 <KipIngram> You can do it either way.
21:29:16 <KipIngram> If you set it to 1 the loop will repeat.
21:29:21 <KipIngram> If you set it to 0 the loop won't repeat.
21:29:33 <KipIngram> If you don't touch it it will function as a counter.
21:29:37 <KipIngram> You get it all.
21:29:55 <KipIngram> Mine will work this way now, though I hadn't thought of it that way until now.
21:30:39 <Deformative> Yeah, I realized that.
21:30:55 <Deformative> How many cycles does your if statement take?
21:30:58 <Deformative> Mine takes 1.
21:31:46 <KipIngram> Well, one cycle is required to fetch the cell.  During that cycle the hardware will see that 1) this is an EA cell, 2) no return address push is called for, and 3) it's conditional.
21:32:02 <KipIngram> The condition will be evaluated at that time, and on the next cycle the target address will be fetched.
21:32:06 <KipIngram> So I guess that's one cycle.
21:32:23 <Deformative> Hmm...
21:32:58 <KipIngram> And that could be a conditional call as well, just by allowing a return address push and reversing the polarity of the condition.
21:33:12 <Deformative> Looks like I am restarting my design.
21:33:15 <KipIngram> So one cycle for an untaken IF WORD THEN,.
21:33:46 <KipIngram> I've really liked some of what you've mentioned.
21:34:00 <KipIngram> On a 32-bit machine I think that your idea of addressing individual slots is the right one.
21:34:05 <KipIngram> I can't do that on my 16-bit machine.
21:34:12 <KipIngram> I wind up with too little code space.
21:34:27 <Deformative> Hmm, yeah, maybe I will stick with it, even if memcpy is so slow.
21:34:30 <KipIngram> But with your wider cells you have lots of room, and some of those concepts start to look really cool.
21:34:36 <KipIngram> You can fix that.
21:35:06 <KipIngram> Just let your microloop be counted in addition to flagged, and add address registers like my a and b registers.
21:35:28 <Deformative> Yeah, I can add a and b registers I suppose.
21:35:53 <Deformative> Well, mine is more efficient if you need to compute during the memcpy.
21:35:55 <Deformative> I think.
21:35:58 <Deformative> So maybe mine isn't all bad.
21:36:06 <KipIngram> The !a+) opcode was key - I added it after you brought this up the other night.
21:36:15 <KipIngram> No, I don't think it's all bad at all.
21:36:24 <KipIngram> I've been impressed with a good bit of it.
21:36:55 <KipIngram> The !a+) opcode lets you write the memory output directly back to a new address.
21:37:41 <KipIngram> Anyway, some minor nuances are necessary to get those fill and copy operations all the way down to 1 and 2, but address registers and counted microloops get you most of the way.
21:37:44 <Deformative> Yeah, I still have plenty of registers to add optimizations for.
21:38:21 <KipIngram> I like the idea of you getting ideas from what I've done but I don't like the idea of you tossing yours and making something almost exactly like mine - that kills too many good ideas you've had.
21:38:54 <KipIngram> And having ideas is what this is all about for you right now - you're immersed in your education.
21:38:57 <Deformative> I was going to go to 8 bit actually.
21:39:16 <KipIngram> Oh - one opcode per byte?
21:39:22 <Deformative> Yes.
21:39:56 <Deformative> And I would have plenty of extra logic to play with.
21:40:46 <Deformative> I still have time to decide.
21:41:03 <Deformative> I have a lot to implement.
21:42:47 <KipIngram> Hmmm.
21:43:01 <KipIngram> I think you'll have some interesting mental gyrations over this.
21:43:24 <KipIngram> I'm liking your approach to 32 bits a lot.  If you go a different direction be sure to keep your notes on the 32 so you can come back to it later.
21:44:26 <Deformative> Yep.
21:45:01 <KipIngram> You know, here we are airing all of these nice ideas in a public forum.  I wonder if the public logs of this channel would constitute legally meaningful "inventor's rights" material?
21:45:33 <Deformative> I don't know what that means.
21:45:34 <KipIngram> I think that when you first present something in public you then have a year to patent it, if it is patentable.
21:45:37 <KipIngram> Keep that in mind.
21:46:00 <Deformative> These things haven't been done before?
21:46:10 <KipIngram> We're presenting our ideas in public.  I think that means that if any of them are worthy of patents whoever presents has one year to move on it.
21:46:38 <KipIngram> Yes, most of them have, and probably all of them.  But you have to wonder if perhaps the occasional gem pops up.
21:47:05 <Deformative> I see.
21:47:08 <KipIngram> There are probably patent trolls watching all these channels for things that might be new, setting their clocks for one year from now, etc.
21:47:36 <Deformative> Well, if I succeed, I will probably try presenting to to a professor to see what they think.
21:47:36 <KipIngram> For instance, I don't know if anyone has done a 32-bit Forth processor that's addressable at the 5-bit opcode level.
21:47:47 <Deformative> But professors are rarely interested in an undergraduate's hobby.
21:47:49 <KipIngram> My own processor is so close to CM
21:48:05 <KipIngram> CM's (not precisely, but close) that I doubt anything there is patent worthy.
21:48:13 <KipIngram> But you've mentioned some sort of new-ish looking things.
21:48:28 <Deformative> One of my professor's is interested in the fact that I do all these projects on my own under my own motivation and wants me to work for him doing research.
21:48:36 <Deformative> But I don't think he cares about my actual projects.
21:49:06 <KipIngram> Well, university professors always have an interest in hard working students, who consitute the last remaining form of indentured servitude.
21:50:48 <Deformative> Heh.
21:51:03 <Deformative> Well, I am interested in doing research because he is respected in the community I think.
21:51:10 <Deformative> And it would look good on my resume.
21:51:13 <KipIngram> Here's what I like about your 32-bit concept.  You could combine that with some of my features.  Use bit 31 to specify "opcode vs. EA."  If it's an EA, then use bit 30 to specify "jump vs. call" (i.e., do you push a return address).  Then use the next several bits (as many as you want) to specify conditions, so you can do conditional jumps and calls.
21:51:48 <KipIngram> Then you have lots of bits, like 24-27 depending on your condition count, to specify the target address to the slot level.
21:52:05 <KipIngram> No need to use memory banking - you have direct access to plenty of RAM.
21:52:37 <KipIngram> Combine that with your "prefetch the address referenced by the top of return stack" idea.
21:52:47 <Deformative> Yeahh... I can merge call and branch into one opcode then.
21:52:49 <Deformative> I like that.
21:52:51 <Deformative> And literal!
21:52:51 <KipIngram> This starts to get very sweet looking.
21:54:09 <Deformative> I am getting more fond of fork and join.
21:54:28 <KipIngram> Fork?
21:54:32 <Deformative> I might add those opcodes.
21:54:36 <KipIngram> Did you mean split?
21:54:40 <Deformative> Yes, I mean split.
21:54:41 <Deformative> Sorry.
21:56:07 <KipIngram> You might also consider my original idea for literals, which was to have LIT word that pushes a zero to the stack and sets a literal mode.  Then each subsequent "opcode" will shift the stack top to the left four bits and OR in the bottom four bits of the opcode.  That keeps happening as long as the "opcode" MSB is 0. 
21:56:22 <KipIngram> When the "opcode" MSB is one it shift/ORs one last time but then returns to normal opcode mode.
21:56:52 <KipIngram> This lets you push small literals (0-15 take 10 bits, 16-255 take 15, etc.) without having to have an entire 32 bit literal cell.
21:57:10 <KipIngram> You get this for just one extra opcode (LIT).
21:57:40 <KipIngram> This is a bit slower but it's more compact.
21:58:25 <Deformative> Hmm.
21:58:27 <Deformative> Interesting.
21:58:37 <KipIngram> With your current approach every literal takes 37 bits.  32 for the data and 5 for the opcode.
21:59:14 <Deformative> Yes.
21:59:24 <Deformative> I can just have 4 opcodes, one for each literal size.
21:59:33 <Deformative> I have PLENTY of opcodes to throw around.
21:59:55 <Deformative> I am ony using 24 so far.
22:00:28 <KipIngram> They can go awfully fast, though.
22:00:40 <KipIngram> I'm pretty stingy with them.
22:01:29 <Deformative> Yeah.
22:01:42 <Deformative> I will hold that decision till later.
22:03:39 <Deformative> Only 3 more days!
22:03:44 <Deformative> Until summer.
22:04:31 <KipIngram> With a 32 bit wide word you also have options of five 6-bit or four 7-bit opcodes.
22:04:38 <KipIngram> Then you really would have opcodes to burn.
22:05:28 <Deformative> Yeah.
22:08:23 <Deformative> I might extend my alu for or, xor, xnor, and, etc etc.
22:08:26 <Deformative> Heh.
22:08:32 <Deformative> But probably not.
22:08:35 <Deformative> nand is neough.
22:10:20 <KipIngram> Time for me to sleep.
22:10:23 <KipIngram> Have a good night.
22:10:27 <Deformative> Yep, goodnight.
22:10:34 --- nick: KipIngram -> KipIngram-zzz
23:02:36 <Deformative> KipIngram-zzz: I am considering making all branch/calls/whatever use the return stack.
23:02:52 <Deformative> Then only literal is used.
23:02:57 <Deformative> And ret/conditional rets.
23:03:08 <Deformative> Less opcodes.
23:03:12 <Deformative> Maybe more elegant.
23:03:24 <Deformative> Oh wait, literal puts onto the parameter stack, not return stack.
23:03:26 <Deformative> Nevermind.
23:46:04 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
23:49:48 --- join: mathrick (~mathrick@users177.kollegienet.dk) joined #forth
23:59:59 --- log: ended forth/10.04.25