00:00:00 --- log: started forth/10.04.26
00:04:15 --- join: ASau` (~user@77.246.230.238) joined #forth
00:07:20 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth
01:00:42 --- join: maht (~maht__@85-189-31-174.proweb.managedbroadband.co.uk) joined #forth
01:21:00 --- quit: gogonkt (Read error: Connection reset by peer)
01:23:47 --- join: gogonkt (~info@218.13.44.125) joined #forth
04:21:41 --- join: dinya_ (~Denis@92.255.128.235) joined #forth
04:45:07 --- quit: nighty__ (Quit: Disappears in a puff of smoke)
05:19:56 --- nick: KipIngram-zzz -> KipIngram
05:20:03 <KipIngram> Morning all.
05:36:19 <gogonkt> evening~
06:51:30 --- quit: foxes (Remote host closed the connection)
07:25:57 <KipIngram> Deformative: I thought about some things like that.  You could do it if you had a separate "literal like" opcode that targeted the return stack.  Then jump would be <return stack literal> ret and call would be (in my instruction set) <return stack literal> co.
07:27:04 <KipIngram> But would your conditional return pop the return stack even if it didn't transfer control?  You'd want it to if you were using it for conditional jumps, but a conditional return is interesting in its own right and for general use you'd probably not want it to pop.
07:27:14 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
07:51:45 --- join: TR2N` (email@89-180-143-148.net.novis.pt) joined #forth
07:51:45 --- quit: TR2N (Ping timeout: 276 seconds)
07:53:30 --- nick: TR2N` -> TR2N
08:02:00 --- quit: ASau` (Quit: off)
08:41:54 --- quit: crc (*.net *.split)
08:41:54 --- quit: gogonkt (*.net *.split)
08:41:54 --- quit: maht (*.net *.split)
08:41:54 --- quit: segher (*.net *.split)
08:41:54 --- quit: nighty^ (*.net *.split)
08:41:54 --- quit: nottwo (*.net *.split)
08:41:55 --- quit: madwork (*.net *.split)
08:41:55 --- quit: schme (*.net *.split)
08:41:55 --- quit: TreyB (*.net *.split)
08:41:55 --- quit: saper (*.net *.split)
08:41:55 --- quit: johnlunney (*.net *.split)
08:41:55 --- quit: kar8nga (*.net *.split)
08:41:55 --- quit: qFox (*.net *.split)
08:41:56 --- quit: scj (*.net *.split)
08:41:56 --- quit: TR2N (*.net *.split)
08:41:56 --- quit: cataska (*.net *.split)
08:41:56 --- quit: jeremy_c (*.net *.split)
08:41:57 --- quit: mathrick (*.net *.split)
08:41:57 --- quit: dinya_ (*.net *.split)
08:41:57 --- quit: uiu (*.net *.split)
08:41:58 --- quit: twobitsprite (*.net *.split)
08:41:58 --- quit: nighty_ (*.net *.split)
08:41:58 --- quit: Deformative (*.net *.split)
08:41:58 --- quit: ygrek (*.net *.split)
08:41:59 --- quit: gnomon (*.net *.split)
08:41:59 --- quit: probonono (*.net *.split)
08:41:59 --- quit: tmitt (*.net *.split)
08:41:59 --- quit: crcx (*.net *.split)
08:42:00 --- quit: ASau (*.net *.split)
08:42:00 --- quit: KipIngram (*.net *.split)
08:42:00 --- quit: malyn (*.net *.split)
08:42:00 --- quit: madgarden (*.net *.split)
08:42:01 --- quit: yiyus (*.net *.split)
08:43:11 --- join: TR2N (email@89-180-143-148.net.novis.pt) joined #forth
08:43:11 --- join: kar8nga (~kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth
08:43:11 --- join: dinya_ (~Denis@92.255.128.235) joined #forth
08:43:11 --- join: gogonkt (~info@218.13.44.125) joined #forth
08:43:11 --- join: maht (~maht__@85-189-31-174.proweb.managedbroadband.co.uk) joined #forth
08:43:11 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth
08:43:11 --- join: mathrick (~mathrick@users177.kollegienet.dk) joined #forth
08:43:11 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
08:43:11 --- join: cataska (~cataska@210.64.6.233) joined #forth
08:43:11 --- join: Deformative (~joe@bursley-185022.reshall.umich.edu) joined #forth
08:43:11 --- join: segher (~segher@84-105-60-153.cable.quicknet.nl) joined #forth
08:43:11 --- join: crc (~charlesch@184.77.185.20) joined #forth
08:43:11 --- join: ASau (~user@83.69.227.32) joined #forth
08:43:11 --- join: gnomon (~gnomon@CPE0022158a8221-CM000f9f776f96.cpe.net.cable.rogers.com) joined #forth
08:43:11 --- join: madgarden (~madgarden@CPE001d7e527f89-CM00159a65a870.cpe.net.cable.rogers.com) joined #forth
08:43:11 --- join: nottwo (~trannie@designvox-gw.iserv.net) joined #forth
08:43:11 --- join: nighty^ (~nighty@x122091.ppp.asahi-net.or.jp) joined #forth
08:43:11 --- join: madwork (~madgarden@204.138.110.15) joined #forth
08:43:11 --- join: schme (~marcus@sxemacs/devel/schme) joined #forth
08:43:11 --- join: TreyB (~trey@adsl-76-247-244-138.dsl.hstntx.sbcglobal.net) joined #forth
08:43:11 --- join: johnlunney (~johnl@217.78.4.44) joined #forth
08:43:11 --- join: saper (saper@wikipedia/saper) joined #forth
08:43:11 --- join: KipIngram (~kip@173-11-138-177-houston.txt.hfc.comcastbusiness.net) joined #forth
08:43:11 --- join: uiu (~ian@HSI-KBW-078-043-251-113.hsi4.kabel-badenwuerttemberg.de) joined #forth
08:43:11 --- join: probonono (~User@unaffiliated/probonono) joined #forth
08:43:11 --- join: scj (syljo361@static-ip-62-75-255-125.inaddr.server4you.de) joined #forth
08:43:11 --- join: nighty_ (~nighty@x122091.ppp.asahi-net.or.jp) joined #forth
08:43:11 --- join: tmitt (seg@wizardly.us) joined #forth
08:43:11 --- join: jeremy_c (jeremy@cowgar.com) joined #forth
08:43:11 --- join: crcx (~crc@69.164.210.93) joined #forth
08:43:11 --- join: twobitsprite (~isaac@75.127.97.165) joined #forth
08:43:11 --- join: malyn (~malyn@unaffiliated/malyn) joined #forth
08:43:11 --- join: yiyus (1242712427@je.je.je) joined #forth
09:43:54 --- quit: ASau (Ping timeout: 276 seconds)
10:07:35 --- join: ASau (~user@83.69.227.32) joined #forth
10:50:57 <Deformative> KipIngram: Yeah, I was thinking that too.
10:51:32 <Deformative> It would be interesting to remove all branches other tham microbranches and just rely on the return stack.
10:51:35 <Deformative> I think I will do that.
10:51:48 <Deformative> It will be a little more general, but more opcodes needed.
10:52:55 <Deformative> Hmm... I can use co then.
10:52:58 <Deformative> And remove call.
10:53:12 <Deformative> fascinating
10:57:06 --- quit: crc (Ping timeout: 276 seconds)
10:58:07 --- join: crc (~charlesch@184.77.185.20) joined #forth
11:06:27 <KipIngram> Yes, I've found these thought processes vastly entertaining.
11:28:57 <KipIngram> For "backwards brances" you can push the target address as you execute past that point; then you can branch back with a return instruction.
11:29:19 <KipIngram> That's more compact and faster than encoding the branch target as a literal just before the ret instruction.
11:30:33 <KipIngram> This sort of mechanism would get you do ... until style loops, but not while loops.  Doesn't work for if then else structures either - nothing that requires forward transfers.
11:41:06 <Deformative> Those loops are better achieved with the microstuff anyway.
11:41:18 <Deformative> Slows the speed of a call though.
11:41:20 <Deformative> Which I do not like.
11:41:29 <Deformative> Considering how many calls there are in forth.
11:42:32 <KipIngram> Yes - I was very obsessive over making calls and returns run as quickly as possible.  That's why I like your idea of having the contents of the cell at the return address constantly prefetched; I think that will save one cycle on every return.
11:44:04 <Deformative> Yeah.
11:46:50 <KipIngram> I already execute return in parallel with the opcode before it, unless that opcode is >r, r>, next, or unext (i.e., unless the opcode before ret affects the return stack).
11:46:57 <KipIngram> So in most cases the return operation is "free."
11:47:48 <Deformative> Neat.
11:48:05 <Deformative> I am really trying to make my architecture simple, but it keeps getting more complex. xD
11:50:35 <Deformative> Doing all this is making me appreciate both register and stack models more.
11:50:57 <Deformative> I can see why register models are the standard.
11:50:59 <KipIngram> I think you'll find that it bounces back and forth between simple and complex as you first solve problems "the wrong way" and then later "the right way."  Finally, at the end, you'll see what I will call "brazen opportunities" to squeeze out extra performance for very low hardware cost - you will probably indulge in a few of those.
11:51:40 <KipIngram> Yes - I even gave in and put a couple of registers in my machine (a and b).  The fact that CM had done the same did make that a lot easier to swallow for me.
11:52:39 <Deformative> Why can't a and b be mapped to the top two elements of the stack?
11:52:53 <Deformative> a being the top, b being second.
11:54:17 <KipIngram> Because then when you store data from the stack or read data to the stack everything moves.
11:54:41 <KipIngram> My a and b autoincrement and can be used over and over again regardless of what's going on on the stack.
11:54:49 <Deformative> Ok.
11:55:32 <Deformative> But like, the memory copy deal, you can wrap that all into one opcall.
11:55:45 <Deformative> Copy from second element of stack to second, increment both.
11:55:58 <KipIngram> That's not a one cycle operation.
11:56:08 <Deformative> Good point.
11:56:09 <KipIngram> All of my opcodes, every one, execute in one cycle.
11:56:52 <Deformative> copy from second element and increment / copy to second element and incrememnt
11:57:16 <KipIngram> Yes, you could do that.
11:57:29 <Deformative> I probably will.
11:57:45 <Deformative> Or add a 3rd stack.
11:57:52 <Deformative> Not sure what I would use the 3rd stack for yet.
11:58:08 <Deformative> I am just trying to get a true stack machine.
11:58:18 <KipIngram> My a and b registers behave "halfway" like a third stack.  I load b via a.
11:58:31 <KipIngram> I have a >a operation that moves the stack top to a, but it also moves the previous contents of a to b.
11:58:32 <Deformative> Yeah.
11:58:36 <KipIngram> Kept me from needing a >b.
11:58:59 <KipIngram> I have a meeting; catch you later.
11:59:14 <Deformative> Yep.
11:59:15 <Deformative> o/
12:06:13 --- join: Snoopy_1611 (Snoopy_161@dslb-084-059-127-022.pools.arcor-ip.net) joined #forth
13:03:50 --- quit: ygrek (Ping timeout: 245 seconds)
13:09:26 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
13:09:28 --- quit: qFox (Quit: Time for cookies!)
13:13:08 --- quit: ygrek (Remote host closed the connection)
13:19:36 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
13:22:22 --- join: GoNoGo (~GoNoGo@2a01:e35:2ec5:dd70:4cf7:4894:feca:dcce) joined #forth
14:04:40 --- quit: ygrek (Ping timeout: 245 seconds)
14:05:12 --- quit: Snoopy_1611 (Ping timeout: 276 seconds)
14:10:18 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
14:18:27 --- quit: GoNoGo (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
14:18:50 --- quit: ygrek (Ping timeout: 245 seconds)
14:21:38 --- join: Snoopy_1611 (Snoopy_161@dslb-088-068-209-238.pools.arcor-ip.net) joined #forth
14:37:42 --- quit: Snoopy_1611 (Ping timeout: 276 seconds)
14:51:48 --- join: Snoopy_1611 (Snoopy_161@dslb-088-068-209-015.pools.arcor-ip.net) joined #forth
14:52:08 <Deformative> Any idea what the acronym NOS stands for?  http://www.microcore.org/
14:52:13 <Deformative> TOS is top of stack.
14:58:09 --- quit: kar8nga (Remote host closed the connection)
15:14:50 <yiyus> Deformative: i always supossed it was Next On Stack
15:14:56 <yiyus> but i could be wrong
15:16:58 <KipIngram> I think "Next On Stack" is correct.
15:17:06 <Deformative> Oh, ok.
15:17:57 <Deformative> I like that diagram.
15:18:01 <Deformative> I need to try drawing one of those.
15:18:18 <Deformative> Too bad I don't have a copy of visio on my laptop.
15:18:24 <Deformative> Does anyone know an open source tool I can use?
15:19:50 --- join: Snoopy_1711 (Snoopy_161@dslb-084-059-100-085.pools.arcor-ip.net) joined #forth
15:20:41 <KipIngram> Do you run Linux?
15:21:51 <KipIngram> If you run Windows go to www.portableapps.com, select the "graphics and pictures" application category, and check out Portable Dia.
15:21:51 <Deformative> Yes.
15:22:08 <Deformative> I have an installation of vista I can boot into.
15:22:11 <Deformative> But i like to avoid it.
15:22:19 <KipIngram> If you run Linux you should be able to find something in your package manager.  What distro do you use?
15:22:56 <Deformative> Archlinux/ubuntu
15:23:03 <Deformative> I have used dia before.
15:23:09 <Deformative> Never very fond of it though.
15:23:16 <KipIngram> Run synaptic package manager and search for visio, diagramming, etc.
15:23:21 <Deformative> I used to like kivio a lot, but they stopped shipping that kde for some reason.
15:23:51 --- quit: Snoopy_1611 (Ping timeout: 276 seconds)
15:23:56 --- join: Snoopy_1611 (Snoopy_161@dslb-088-068-201-167.pools.arcor-ip.net) joined #forth
15:24:01 <Deformative> Oh, ubuntu still has kivio.
15:24:03 <Deformative> I will try that.
15:24:10 <Deformative> Seems only archlinux dropped kivio.
15:25:23 <KipIngram> I drew mine by hand.
15:25:25 --- quit: Snoopy_1711 (Ping timeout: 268 seconds)
15:25:30 <KipIngram> I'm lazy about learning software packages.
15:26:38 <Deformative> Heh.
15:27:37 <Deformative> Ugh...
15:27:42 <Deformative> I got a C+ in calv IV.
15:27:47 <Deformative> That is the worst I have ever done on anything.
15:28:31 <Deformative> I blame all the people who put effort in..
15:29:28 <Deformative> Not really.
15:29:31 <Deformative> I am just not good at it...
15:34:59 <KipIngram> Sorry, man.  I got a 56 on a statics exam once.  Overconfidence - I figured if I knew F = ma I knew it all. :-|
15:35:22 <KipIngram> And in a way I was right - I probably could have solved every problem correctly.  I just couldn't solve them fast enough to finish the exam.
15:35:46 <Deformative> :/
15:35:56 <KipIngram> I made a A in the course, though.
15:37:28 <Deformative> No, I got a C+ in the course.
15:37:31 <Deformative> That's the problem.
15:40:46 <Deformative> Hopefully my EECS courses offset it so I can still get a 3.6
15:40:48 <Deformative> But we will see.
15:58:05 --- join: |dinya_| (~Denis@92.255.128.235) joined #forth
15:58:34 --- quit: dinya_ (Ping timeout: 252 seconds)
16:37:35 --- quit: |dinya_| (Ping timeout: 245 seconds)
17:01:44 --- join: guest (~cebc241d@gateway/web/freenode/x-frmkfiyvunhngdgg) joined #forth
17:09:00 <guest> All hail Forth the great language of telescopes and robots.
17:09:28 <Deformative> Heh.
17:09:35 <guest> Quartus, wherefore art thou?
17:09:56 <guest> Whois Deformative -- where and why?
17:10:39 <guest> oops -=- only 3+ minutes left on this wavelength!
17:10:48 <Deformative> O.o
17:11:37 <guest> OK - Niow that I know how to get here, I SHALL RETURN. Bye!
17:11:51 --- quit: guest (Quit: Page closed)
17:43:00 <KipIngram> That was... different.
18:02:32 <KipIngram> So, what exactly does that O.o thing mean?
18:06:26 <crc> shocked/disturbed/raised eyebrow (per wikipedia)
18:06:36 <Deformative> Yep.
18:07:03 <KipIngram> Ah.  I see it now.
18:09:17 <Deformative> Three more days. :F
18:09:19 <Deformative> :D rather
18:10:11 <Deformative> I decided I should sit and figure out what the performance cirtical parts of my forth will be, then work from there, rather than working from nothing and seeing what would be interesting to implement.
18:11:16 <KipIngram> Subroutine calls and returns.
18:11:27 <Deformative> Well, yes of course.
18:11:36 <Deformative> But there must be more.
18:14:05 <Deformative> I also need to think about domain specific instructions.
18:14:12 <Deformative> What domain do I want to make my cpu fit.
18:14:29 <KipIngram> Yes - mine is pretty oriented toward embedded processing.
18:14:53 <Deformative> Forth CPU are generally slow for anything relating to DSP.
18:15:00 <Deformative> Perhaps I can add some dsp specific instructions.
18:15:12 <Deformative> Problem is that I know nothing about dsp.
18:15:54 <Deformative> (I can be wrong about the slow for dsp stuff, I just read that in a article I was reading a few minutes ago)
18:19:26 <KipIngram> Maybe matrix specific instructions?  Not only address registers like mine, that step one cell at a time, but ones that you could cause to step a full row at a time?  So a per-register programmable autoincrement.
18:19:44 <KipIngram> That could lead to a really fast matrix multiply capability.
18:20:20 <Deformative> To do this, I would need to fetch many words a time, right?
18:20:45 <KipIngram> No; you'd do @r+ @c+ * !p+ in a microloop.
18:20:57 <Deformative> Oh I see.
18:21:08 <KipIngram> Wait.
18:21:17 <KipIngram> @r+ @c+ +
18:21:26 <Deformative> Yeah, I got what you meant.
18:21:28 <KipIngram> Then outside the microloop you'd store that with !p+
18:21:37 <KipIngram> Nested microloops?
18:22:13 <Deformative> Not difficult.
18:22:40 <Deformative> If they both have the same entry, it can be done in one cell, if not, a call would be required.
18:23:44 <KipIngram> I hate to see you introduce call overhead into the microloop.
18:24:20 <Deformative> Well, virtually all of my loops are microloops.
18:24:47 <Deformative> Since I can return into a cell.
18:25:30 <Deformative> I may even remove the non-micro branch.
18:25:35 <Deformative> There really is no reason for it.
18:26:53 <KipIngram> Ok, that's interesting.  I'll have to ponder that.  Like I said, I really like your slot-addressable concept.
18:26:55 <Deformative> If it is ever needed, it can be achieved with: call r> drop
18:27:15 <Deformative> Well, r> drop would need to be in the calleee.
18:30:04 <KipIngram> Watching some TV - back in a bit.
18:30:10 <Deformative> Ok.
19:01:21 --- join: nighty__ (~nighty@210.188.173.245) joined #forth
19:16:01 --- quit: twobitsprite (Ping timeout: 252 seconds)
19:17:58 --- join: twobitsprite (~isaac@li24-165.members.linode.com) joined #forth
19:48:06 --- quit: TR2N (Ping timeout: 258 seconds)
20:13:45 <KipIngram> I'm back.  
20:15:42 <Deformative> Okie.
20:24:10 --- quit: saper (Ping timeout: 264 seconds)
20:24:27 --- join: saper (saper@wikipedia/saper) joined #forth
20:30:17 <KipIngram> Hey, did you decide you could dispense with nop since you can transfer control to any slot?
20:30:34 <Deformative> Yep.
20:30:52 <Deformative> Only because of ubreak.
20:31:04 <Deformative> Couldn't be done without ubreak.
20:33:40 <KipIngram> Ok.  So you can put unext (or uloop or whatever you call it) anywhere in the cell, right?
20:34:17 <Deformative> Yes.
20:34:24 <Deformative> ubreak or uloop can go anywhere in a cell.
20:35:33 <KipIngram> Then why is ubreak required to eliminate nop?
20:36:19 <Deformative> Pretend you wanted to write * begin 3 again
20:37:02 <Deformative> Your model would be: * nop nop literal unext
20:37:27 <Deformative> Erm, let me represent that better: [* nop nop] [literal unext]
20:37:44 <Deformative> Mine is [* ubreak] [literal uloop]
20:40:34 <KipIngram> Oh, of course - I see.
20:40:50 --- join: Snoopy_1711 (Snoopy_161@dslb-088-068-201-167.pools.arcor-ip.net) joined #forth
20:40:58 <KipIngram> Because uloop always transfers to the beginning of a cell.  A jump or call can go to any slot, but uloop still goes to a cell boundary.
20:40:59 <KipIngram> Got it.
20:41:29 <Deformative> Yep.
20:41:43 <Deformative> I couldn't get the words right, so I had to give an example.
20:43:08 --- quit: Snoopy_1611 (Ping timeout: 240 seconds)
20:43:42 <Deformative> I am trying to decide if I should have conditiona call/rets or not.
20:43:49 <Deformative> Maybe just conditionsal ubreak/uloops
20:44:53 <KipIngram> With 32-bit cells I *definitely* think you should have conditional calls and jumps.
20:45:32 <Deformative> I don't have jumps.
20:45:36 <KipIngram> I still think you should consider the "in the cell call / jump / conditional" parts of my processor - their only downsize is that they reduce the size of the effective address, and you have bits to spare.
20:45:48 <KipIngram> Those ideas will work better for you than they do for me.
20:46:59 <Deformative> Can you explain them again?
20:47:02 <Deformative> I don't remember.
20:47:44 <KipIngram> Ok.  I'll explain them with your 32-bit cell size.
20:48:17 <KipIngram> So, bit 31 of a cell tells you whether the cell contains primitive opcodes or a jump / call to an effective address.
20:48:38 <Deformative> Oh that.
20:48:50 <KipIngram> If that bits tells you the cell contains opcodes, then those opcodes are in bits [29:0].
20:49:02 <Deformative> Then it defeats the purpose of in-cell jumps, doesn't it?
20:49:13 <Deformative> If calls have their own cell.
20:49:32 <KipIngram> Wait till I'm done.
20:50:03 <KipIngram> If the cell is an EA cell, then bit 30 tells you whether it's a jump or a call (i.e., it tells the hardware whether to push the return address or not when transferring control).
20:50:19 <Deformative> Oh I see.
20:50:35 <Deformative> Yeah, I had considered that as well. ^^
20:50:42 <KipIngram> Then bits [29:<whatever>] specify conditions.  Three or four bits is probably a gorgeous plenty for every condition you could ever think of.
20:51:05 <Deformative> Yeah, but branches are almost entirely useless to me.
20:51:08 <KipIngram> Then the remaining bits ([26:0], [25:0], or whatever) specify the slot EA.
20:51:12 <Deformative> In fact, they encourage bad style.
20:51:20 <KipIngram> Ok, then maybe you drop bit 30 and just do this for calls.
20:51:43 <KipIngram> Well, I wouldn't expect you to expose raw branches at the source code level, actually.
20:51:47 <KipIngram> But whatever.
20:52:16 <Deformative> By bad style, I mean by having them, there is no possible optimality.
20:52:32 <Deformative> Well, maybe by one cycle in a very rare occasion.
20:52:38 <Deformative> But I don't think it is worth while.
20:52:45 <Deformative> But please continue.
20:53:04 <KipIngram> Well, that's really it.  That's how it works.
20:53:22 <KipIngram> By the time I've spent all those bits I have so few left that I felt the need to bank my memory to get enough code space.
20:53:25 <KipIngram> You wouldn't have that problem.
20:54:56 <KipIngram> In fact, this leaves you with a really marvelous number of bits left.  Let's say you have bits [25:0] for the EA.  That's 32M slots.  Rounding down to a power of 2 that's 4MB, which is a great amount of RAM to have in a Forth system.
20:55:11 <KipIngram> Wait, I'm off by a power of 2.
20:55:13 <KipIngram> 8MB.
20:58:04 --- nick: Snoopy_1711 -> Snoopy_1611
20:58:24 <Deformative> I have an idea.
20:58:47 <Deformative> Perhaps I can have one word to encapulate literal, call, and randliteral.
20:59:04 <Deformative> The flags can tell the system what to do with the operand.
20:59:09 <Deformative> And then just have one opcall.
20:59:12 <Deformative> opcode I mean
20:59:23 <Deformative> Sorry if I say opcall, opcall is something used in D all over the place.
20:59:41 <Deformative> s/rand/ret
20:59:48 <Deformative> I mean I can put literals on the return stack.
21:00:07 <Deformative> The only problem is that it effectively reduces the size of my words.
21:03:50 <Deformative> I go from a 32 bit arch to fewer
21:04:23 <segher> almost all calls are to things not far back, you might want to optimise for that
21:04:47 <Deformative> Huh?
21:05:21 <segher> in average code
21:05:34 <Deformative> Oh.
21:06:57 <KipIngram> That keeps you from having a 32-bit literal.
21:07:09 <Deformative> Yes, that is what I mean.
21:07:18 <KipIngram> Yes, I responded before reading all of your posts.
21:08:18 <KipIngram> segher: I think that he's intending to make all loops fit in a microloop, using calls if the required code is larger than a cell will hold.
21:08:25 <KipIngram> Deformative: Is that right?
21:08:51 <Deformative> That is correct.
21:09:42 <segher> ah, "outlining" the loop body automatically
21:10:08 <Deformative> I think I might implement a colorforth assembler for my cpu.
21:10:12 <Deformative> Rather than a traditional one.
21:10:19 <Deformative> It would make many things quite simple.
21:10:39 <KipIngram> I haven't studied colorForth enough to comment.
21:11:07 <segher> not sure how that assembler is, but in my current cross compiler i do things like:
21:11:08 <KipIngram> I am such huge fan of traditional text interfaces - colorForth alarms me a bit.
21:11:10 <segher> CODE <   48dd , ae02 , 6841 , ee01 , 9840 , END-CODE
21:11:29 <segher> who needs assemblers ;-)
21:11:35 <KipIngram> heh
21:11:56 <segher> (i did write an assembler -- and then promptly didn't use it)
21:14:16 <Deformative> Well, I need to signify if each word is call, literal, opcode, whatever.
21:14:21 <Deformative> Color seems like the best way.
21:14:25 <Deformative> Oh, I forgot label in there.
21:15:27 <Deformative> opcodes would be the same color as calls of course.
21:20:29 <KipIngram> But the system determines what the word is via dictionary search.
21:21:08 <Deformative> Yes.
21:22:19 <Deformative> My assembler would be able to do forward calls though.
21:22:27 <Deformative> Unlike most forths.
21:24:21 <KipIngram> Oh.  That's not Forthy at all.
21:24:31 <KipIngram> So you'd make two passes over your source?
21:24:47 <Deformative> It is an asembler, not a forth.
21:24:49 <Deformative> Just forth-like.
21:24:59 <KipIngram> Ok.
21:25:01 <Deformative> Well it isn't a shell.
21:25:14 <KipIngram> So this is something you'd use to build the ultimate environment?
21:25:35 <Deformative> This is just for the assembler written in C.
21:25:42 <Deformative> For compiling programs to run on my chip.
21:25:55 <Deformative> It would be easy to make a forth, I just wanted to do it this way.
21:25:58 <KipIngram> An important part of Forth to me is the incremental "compile-test-FORGET-repeat" nature of development.
21:26:08 <KipIngram> Build up functionality in small bits, testing along the way.
21:26:26 <Deformative> Yeah, that is important for a forth, not an assembly.
21:26:39 <KipIngram> I'm ok with that.
21:26:51 <KipIngram> Do you plan to eventually have an incremental environment, though?
21:27:13 <Deformative> If the cpu is actually sucessful, yes. 
21:28:29 <Deformative> This is just quicker and more useful for now.
21:28:34 <Deformative> Making tests/demos.
21:28:44 <KipIngram> Oh, I'm sure it will be.  If you mean by that "will it work."  I think you'll get it there.
21:28:55 <KipIngram> I can tell you're on a good path.
21:29:19 <Deformative> If it works well, I might patent it like you said.
21:29:23 <Deformative> Does that cost money to do?
21:29:27 <KipIngram> Oh yeah.
21:29:31 <KipIngram> But your university might help you.
21:29:46 <KipIngram> And I doubt it would be a patent on the whole thing, but there may be some patentable bits.
21:30:12 <KipIngram> Most universities expect a slice of the royalties for helping with patents, but unlike employers they share.
21:30:22 <Deformative> Or maybe I will just write an article about it and try to get it published.
21:30:30 <Deformative> That would be cool.
21:30:32 <KipIngram> That might do you more long-term good.
21:31:12 <KipIngram> And doesn't preclude patents.
21:31:26 <KipIngram> It just starts the one year clock, and you may have already started that by discussing it here.
21:31:39 --- quit: segher (Quit: This computer has gone to sleep)
21:32:12 <ASau> KipIngram: ForthCMP did that and it did that in one pass (as usual one-pass assembler).
21:32:14 <KipIngram> That part of your ideas that stands out for me is the slot level addressibility.
21:32:16 <Deformative> Well, I need to get a functional prototype before I think about this stuff.
21:32:35 <KipIngram> But a devil's advocate might say "Hey, that's just five-bit (or six, or whatever) words.  Nothing new."
21:32:53 <KipIngram> If you pursue it your university probably has someone who could help you know if it would "take."
21:33:18 <KipIngram> For instance, lots of processors are "32-bit" but let you address bytes.
21:33:27 <KipIngram> In some sense that's what you're doing here, just with a different bit count.
21:35:08 <Deformative> Well, I have operands that are not immediately after the opcode.
21:35:13 <Deformative> Which might be different.
21:45:43 <KipIngram> Yes, that's true, and that is an interesting feature.  I have that as well, though, and discussed it here before you did.
21:46:24 <KipIngram> I don't know that I've ever read about ubreak anywhere else.
21:46:55 <Deformative> But mine can be compounded out of order.
21:46:59 <KipIngram> uloop probably won't qualify; I'd be surprised if CM doesn't have that one locked up with general wording around his unext op.
21:47:02 <Deformative> Yours can't.
21:47:16 <KipIngram> Explain.
21:47:35 <KipIngram> But the CM processors I've read about don't have ubreak.
21:48:22 <Deformative> My pc keeps track of the operand position and operator position.  That way you can do what we talked about before:  if literal then literal
21:48:50 <Deformative> he second literal needs to know that one literal has already elapsed if the if has been executed and has not if it hasn't.
21:49:18 <KipIngram> Oh, yes.
21:49:29 <KipIngram> That dual pointer approach is very, *very* interesting.
21:49:36 <KipIngram> That stands out more than anything else.
21:49:40 <KipIngram> Definitely.
21:49:45 <Deformative> Yeah, that is what I figured.
21:50:07 <KipIngram> You should certainly discuss that with someone at your school.  Or even with an attorney of your own if you can find a way to finance it.
21:50:23 <KipIngram> Read about your school's invention policy - often they're very fair.
21:50:39 <Deformative> I am in tons of debth. I cannot afford an attorney.
21:50:44 <KipIngram> After all, the school foots the whole bill and takes all the financial risk, so they should get something out of it if it's successful.
21:50:53 <Deformative> Well, not tons.
21:50:56 <Deformative> But 16k
21:51:01 <Deformative> I will be in more next year.
21:51:49 <KipIngram> That's manageable, but yes, it's hurtful when you haven't got a true income started yet.  Check your school's IP policy and if you feel comfortable go talk to someone.
21:52:07 <KipIngram> That truly is an interesting idea and I don't know if it's "out there" yet.
21:52:17 <KipIngram> Though it's amazing how many ideas are "out there" already.
21:52:45 <KipIngram> But even if it is you still thought of it on your own, and that's cool.
21:53:22 <Deformative> Thanks.
21:53:41 <Deformative> I know that if I invent something while I am a student, I own it.
21:53:46 <Deformative> But that's all I know about the IP rules.
21:55:02 <Deformative> This could be generalized further and i can put operands and operators in different memories.
21:55:08 <Deformative> It would make prefetching easier.
21:55:11 <Deformative> Potentially.
21:55:20 <Deformative> But it would make ip and jumps take more space.
21:55:43 <Deformative> Well, I could fit it in the same number of bits.
21:55:52 <Deformative> But it would make it a little more complicated.
21:56:38 <Deformative> A couple of years ago I think I invented a programming paradigm.
21:56:56 <Deformative> Though, it was virtually useless.
21:57:02 <Deformative> So I just called it an esolang.
22:00:45 <KipIngram> ?  Go ahead, I'm interested.
22:01:17 <Deformative> Well, it was a paradigm centric around continuation passing style.
22:01:32 <Deformative> Where the only control structures were what I called a "shuffle" and a "closure"
22:01:52 <Deformative> Closure isn't the right word, it is really a self unpacking abstract data typle, but I couldn't come up with a good name.
22:02:23 <KipIngram> God, I can't follow that - to far out.  I don't have formal CS training and you just left me in the dust.
22:02:29 <KipIngram> too
22:02:50 <Deformative> Sec, I have a dumbed down report.
22:02:52 <KipIngram> Though I think you meant tuple instead of typle, right?
22:03:08 <KipIngram> Christ - you just called me dumb.
22:03:12 <KipIngram> :-)
22:03:14 <KipIngram> Wow.
22:03:17 <Deformative> Not a tuple, no.
22:03:21 <Deformative> I didn't call you dumb at all.
22:03:25 <Deformative> Just the report is terrible.
22:03:29 <KipIngram> Joking with you.
22:03:35 <KipIngram> So there's such a thing as a typle?
22:03:44 <KipIngram> Oh, you meant type.
22:03:51 <Deformative> I had to modify the report to fit their aweful formatting for a competition I entered.
22:04:30 <KipIngram> I don't think I'm the smartest guy around, but I get by fairly well so I'm not insecure.
22:04:40 <Deformative> It was like 30 pages long and had great depth. but I had to slim it down to 18 and only keep the less in depth parts.
22:04:54 <KipIngram> I'd love to read it.  I'll pm you my email.
22:05:03 <Deformative> http://demented.no-ip.org/~feep/challenging_the_return_address.pdf
22:05:05 <Deformative> THat works.
22:05:08 <KipIngram> Oh, ok.
22:05:28 <Deformative> Or here, if you want the full source: http://pusdesris.googlecode.com/files/returnless.zip
22:06:08 <KipIngram> Ok - I've loaded the first one; I'll fetch that one from the log later if I need to.  Very nice.
22:06:17 <KipIngram> So I will read it tomorrow - I should get to bed now.
22:06:21 <KipIngram> Have a good night.
22:06:29 <Deformative> Ok.
22:06:40 <Deformative> It is quite fun.
22:06:57 <Deformative> Really forces you to contort your brain to understand it.
22:07:07 <Deformative> And yes, a tuple is a data type in a lot of languages.
22:07:18 <Deformative> It has many different overloads of it's meaning.
22:07:33 <Deformative> But it is typically just an anonymous structure.
22:07:39 <Deformative> Have a good night, talk to you later.
22:14:47 <Deformative> Also, the formatting looked a lot better before I rendered it as a pdf, but I don't have the origional document anymore unfortunately. 
22:35:58 <Deformative> Wow... Reading over this report two years from when I wrote it, I should have done a MUCH better job..  Well I suppose the fact that I could do a better job now means I am improving.
22:38:34 --- join: foxes (~flash@123.115.211.123) joined #forth
22:50:29 --- join: dinya_ (~Denis@92.255.128.235) joined #forth
23:06:26 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth
23:11:38 --- join: ASau` (~user@77.246.231.80) joined #forth
23:36:01 --- quit: dinya_ (Read error: Connection reset by peer)
23:37:34 --- join: dinya_ (~Denis@92.255.128.235) joined #forth
23:42:42 --- quit: dinya_ (Ping timeout: 276 seconds)
23:59:59 --- log: ended forth/10.04.26