00:00:00 --- log: started forth/05.03.15 00:01:14 --- nick: arke -> EIGHT_EQUALS_D 00:02:49 --- nick: EIGHT_EQUALS_D -> arke 01:12:28 --- join: Topaz (~top@cerberus.saywell.net) joined #forth 02:00:51 --- join: aum (b7a124c5ec@60-234-138-239.bitstream.orcon.net.nz) joined #forth 03:32:00 hm, i'm so silly 03:32:15 for some reason i made my FORTH use the return stack as the parameter stack too 03:32:18 no wonder it doesn't work :D 04:20:43 hmm, fixed 04:39:28 --- quit: cmeme ("Client terminated by server") 04:40:13 --- join: cmeme (~cmeme@216.184.11.2) joined #forth 05:06:56 --- quit: Frek ("Client exiting") 05:07:22 --- join: Frek (12182-iden@h89n2fls31o815.telia.com) joined #forth 06:07:29 --- quit: aum () 06:30:51 --- quit: Topaz (Remote closed the connection) 06:34:45 --- join: docl (~docl@dpcbw098083.direcpc.com) joined #forth 06:41:38 --- quit: docl (Read error: 104 (Connection reset by peer)) 06:44:17 --- join: docl (~docl@dpcbw098083.direcpc.com) joined #forth 07:30:34 --- quit: I440r_ ("Leaving") 07:42:11 --- join: I440r_ (~mark4@216-110-82-203.gen.twtelecom.net) joined #forth 08:04:37 --- join: TheBlueWizard (TheBlueWiz@ts001d0841.wdc-dc.xod.concentric.net) joined #forth 08:18:39 --- join: Topaz (~top@cerberus.saywell.net) joined #forth 08:57:15 --- quit: cmeme (zelazny.freenode.net irc.freenode.net) 08:57:16 --- quit: warpzero (zelazny.freenode.net irc.freenode.net) 08:58:17 --- join: cmeme (~cmeme@216.184.11.2) joined #forth 09:06:03 --- join: warpzero (~warpzero@wza.us) joined #forth 09:07:54 good morning 09:08:17 hiya docl 09:10:27 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 09:10:27 --- mode: ChanServ set +o Herkamire 09:11:33 we finally got a working echo server in retroforth :) 09:12:27 docl: working over the net? 09:13:06 haven't tried that yet 09:13:14 it works on localhost though 09:13:20 cool 09:13:33 does it support multiple connections? 09:13:35 http://forthology.com/echoserv.rf 09:13:41 not yet 09:14:06 we're working on that though. I kind of have a general idea how to do it. 09:16:30 good work :) 09:17:17 thanks :) thinfu did most of it, I just tried to keep him motivated 09:18:32 I guess I helped a bit on the research :) 09:18:35 need polling stuff to support multiple connections 09:18:54 yeah, we're going to go with select 09:19:19 oh :) 09:19:28 my accumulated research: http://forthology.com/index.php?wiki=LinuxSockets 09:20:11 actually it's outdated come to think of it 09:20:14 oh, poll is the one I used 09:20:28 --- join: Serg[GPRS] (~z@193.201.231.126) joined #forth 09:21:06 my socketcall funcs were purely hypothetical, turns out you have to make buffer variables with the args and call them. 09:23:26 I remember socket stuff being a mess of little structs 09:23:35 you also have to create a buffer array for select, which holds the timeout in seconds and microseconds... seems silly but that's how it's done. 09:23:41 yeah that's right 09:23:53 yeah, I think that's why I ended up using poll. 09:24:19 isn't poll a cpu hog? 09:24:31 but poll only does one fd at a time I think 09:24:41 oh 09:24:52 but I was doing UDP, so I only had one fd 09:24:58 well select takes a whole set of them 09:25:31 sleeps when there's no data, sends back any data that comes in 09:30:35 well, it doesn't send back the data. it tells you which ones are ready for reading/writing 09:31:23 oh yeah. so then you access them using recv, right? 09:31:57 or read, if you want to 09:32:37 yeah 09:32:52 in C looks like you use macros to deal with the silly arrays 09:33:09 yeah I think so. 09:37:15 * Serg[GPRS] just bought 0ver 20 hours of RU history in TV recurds (4 2-side DVD) 09:38:09 196x1992, one disk missing: from 1992 - till mayhem of independent TV 09:38:21 196x - 1992 09:41:24 bye all 09:42:10 bye 09:43:35 --- part: TheBlueWizard left #forth 10:08:52 --- quit: Serg[GPRS] () 10:20:54 --- quit: Quartus (zelazny.freenode.net irc.freenode.net) 10:20:54 --- quit: crc (zelazny.freenode.net irc.freenode.net) 10:20:54 --- quit: juhammed (zelazny.freenode.net irc.freenode.net) 10:20:54 --- quit: eiz (zelazny.freenode.net irc.freenode.net) 10:23:13 --- join: juhammed_ (~o@dsl-olugw3p33.dial.inet.fi) joined #forth 10:26:20 --- join: crc (~crc@pool-70-16-146-220.phil.east.verizon.net) joined #forth 10:26:20 --- join: Quartus (~trailer@ansuz.pair.com) joined #forth 10:26:20 --- join: eiz (d5bcbfb5f8@c-67-164-190-9.client.comcast.net) joined #forth 10:26:20 --- join: juhammed (~o@dsl-olugw3p33.dial.inet.fi) joined #forth 10:26:20 --- mode: irc.freenode.net set +o crc 10:29:24 --- quit: Quartus (zelazny.freenode.net irc.freenode.net) 10:29:24 --- quit: juhammed (zelazny.freenode.net irc.freenode.net) 10:29:24 --- quit: eiz (zelazny.freenode.net irc.freenode.net) 10:29:24 --- quit: crc (zelazny.freenode.net irc.freenode.net) 10:29:49 --- join: crc (~crc@pool-70-16-146-220.phil.east.verizon.net) joined #forth 10:29:49 --- join: Quartus (~trailer@ansuz.pair.com) joined #forth 10:29:49 --- join: eiz (d5bcbfb5f8@c-67-164-190-9.client.comcast.net) joined #forth 10:29:49 --- mode: irc.freenode.net set +o crc 10:39:05 --- quit: Quartus (zelazny.freenode.net irc.freenode.net) 10:39:05 --- quit: eiz (zelazny.freenode.net irc.freenode.net) 10:39:05 --- quit: crc (zelazny.freenode.net irc.freenode.net) 10:39:49 --- join: crc (~crc@pool-70-16-146-220.phil.east.verizon.net) joined #forth 10:39:49 --- join: Quartus (~trailer@ansuz.pair.com) joined #forth 10:39:49 --- join: eiz (d5bcbfb5f8@c-67-164-190-9.client.comcast.net) joined #forth 10:39:49 --- mode: irc.freenode.net set +o crc 10:59:48 --- quit: Quartus (zelazny.freenode.net irc.freenode.net) 10:59:48 --- quit: eiz (zelazny.freenode.net irc.freenode.net) 10:59:48 --- quit: crc (zelazny.freenode.net irc.freenode.net) 11:11:01 * Herkamire netsplits around the room 11:19:43 --- quit: docl ("Leaving") 11:28:49 --- nick: juhammed_ -> ooo 11:40:01 --- join: tathi (~josh@pcp01375108pcs.milfrd01.pa.comcast.net) joined #forth 12:11:51 --- join: tkb (~tkb@63.163.164.6) joined #forth 12:12:32 --- part: tkb left #forth 12:42:32 --- join: docl (~docl@dpcbw098083.direcpc.com) joined #forth 13:13:33 weird stuff 13:13:44 there's and amulance and police car parked in the middle of main street 13:14:20 right accross one of the biggest cross walks 13:14:30 cars are cautiously going by on either side 13:19:54 --- join: `eiz (11162344fc@c-67-164-190-9.client.comcast.net) joined #forth 13:20:26 --- nick: `eiz -> eiz 13:31:47 --- join: aum (5042d553ca@60-234-138-239.bitstream.orcon.net.nz) joined #forth 13:42:46 --- quit: Topaz (Read error: 113 (No route to host)) 13:51:26 --- quit: eiz ("!") 14:19:01 --- join: slava (~slava@CPE00096ba44261-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 14:19:08 how do i jump to an address held in a register on powerpc? 14:20:02 move it to the count or link register, then branch to that. 14:20:06 e.g. 14:20:08 mtctr r3 14:20:17 bctr 14:20:33 what i'm really trying to figure out is how to jump to an address that's further than 64mb away 14:20:36 (or bctrl if you want to be able to return, of course) 14:20:44 is there a way to build the address in the link register straight away? 14:20:52 no. 14:21:25 that is the standard way to do it -- the C compiler puts in stubs like that for dynamically-linked library calls, for instance. 14:22:25 so its a whopping 4 instructions to call a C function? 14:23:18 'fraid so. :( 14:23:35 PPC Linux isn't exactly space-efficient. 14:24:59 well...it could be only 3 if you have the address in memory somewhere that you can load from with one instruction. 14:25:29 heh 14:25:52 like, say, within +/- 32KB of a stack pointer register, that sort of thing 14:26:30 never mind. 14:26:41 you still have to get the value there in the first place. 14:27:24 earlier versions of Mac OS have a bunch of things which are accessible as offsets from a ToC register ofor just this reason... 14:29:53 but yeah, get used to it. RISC code density is far lower than x86. 14:32:53 --- join: crc (~crc@pool-70-16-146-220.phil.east.verizon.net) joined #forth 14:32:53 --- mode: ChanServ set +o crc 14:45:46 --- quit: x2Sx (Read error: 113 (No route to host)) 14:56:43 yes only way to save instructions is to build a table of addresses then load that value 14:57:07 i presume the CPU optimizes this though :) 14:57:16 the simple instruction format should allow very fast prefetching and such 14:57:39 slava: most simple instructions are 1 cycle instructions, so yes it don't cost that much usually 14:58:11 is r1 the C stack by convention? 14:58:15 what you should avoid however is instructions directly dependent on the previous instruction cause it hurts pipelining alot 14:58:25 yes r1 is stack in most PPC runtime conventions 14:58:38 r2 is TOC if the convention supports it 14:58:50 Frek, i cannot do such optimization at this stage. later i'll allocate registers properly and schedule instructions etc 14:59:06 slava: yes that's fine 14:59:26 --- join: Quartus (~trailer@209.68.1.162) joined #forth 14:59:53 tathi, what STC prologue/epilogue does your forth use? 15:01:02 mflr r0; stwu r0,-4(sp) 15:01:20 mflr stores link register in r0? 15:01:26 is this one of those cases where r0 is actually r0? :) 15:01:32 mflr stores the link register in r0 in that case, yes 15:01:39 ok, thanks 15:01:45 as I said the other day, first parameter is always destination / source for an operation 15:01:51 :) 15:01:53 lwz r0,0(sp); addi sp,sp,4; mtlr r0; blr 15:01:57 mflr = move from link register 15:02:01 Frek, yup 15:02:14 you guys rock 15:02:21 (which is also a simplified memonic, the extended instruction is something like mfspr LR,r0) 15:02:26 err 15:02:28 r0,LR 15:02:34 i already added mflr and mtlr to my assembler 15:02:45 : MFSPR 5 shift 339 xfx-form 31 insn ; 15:02:45 : MFLR 8 MFSPR ; 15:02:50 ah 15:03:06 bah. we're just happy you're adding a PPC compiler ;) 15:03:20 :) 15:03:41 slava: just don't count on me once you get started with the FPU :P 15:04:24 heh. I don't think there's much different about the FPU stuff. 15:04:25 heh 15:04:35 if you plan to support that; cause FPU land is lawless; every convention differ it seems 15:04:51 i don't have any special compilation for FP math... its pretty slow on x86 right now too 15:05:11 slava: otherwise the FPU is traditionally where the PowerPC been extra strong 15:05:21 yes 15:05:27 Frek: oh, you mean it's different from x86. gotcha. 15:05:54 tathi: I'm totally clueless on the x86 in general, so I donno 15:06:18 but I just haven't worked alot with the FPU. 15:06:26 x86 has a stack fpu 15:06:30 ah 15:06:44 but in the pentium 4, the fpu runs at half clock speed, you're supposed to use SSE2, etc 15:06:50 the PPC FPU works like it does in Integer mode 15:07:04 - it does 15:07:06 are there powerpc's without an fpu? 15:07:08 yes 15:07:15 4xx are all FPU less afaik 15:07:33 embedded? 15:07:36 yes 15:07:54 I think all PPCs with a model number less than 600 are stripped from a FPU 15:08:55 does SSE2 has its own FPU ? 15:09:07 SSE2 is a SIMD unit 15:09:22 or you mean the x86 FPU can work directly on SSE2 registers ? 15:09:31 i'm not sure how its designed 15:09:40 slava: yea; I thought of "[00:07] but in the pentium 4, the fpu runs at half clock speed, you're supposed to use SSE2, etc" 15:09:46 but there is an FP stack, and a set of 128 bit wide SIMD registers 15:10:01 anything using the FP stack runs at half clock 15:10:07 ok, I just took a quick look through the instruction set. 15:10:23 ok just thought; on the PPC the vector instruction set shares the FPU, which is a bummer... but... 15:10:28 some of the SIMD registers overlap with the FP stack; you cannot use the integer SIMD unit and the FP stack at the same time. 15:10:40 but the FP SIMD registers are independent of the FP stack. 15:10:41 I see 15:10:42 r0 means lit(0) only in addi, addis, and loads/stores. 15:10:48 tathi, thanks for the tip 15:10:51 tathi: yes r0 is special 15:10:57 i think tathi knows :) 15:11:01 i'm the n00b here 15:11:11 :) 15:11:32 yah, I was just trying to give a rule for *when* it's special. 15:12:06 as I recall it virtually any instruction that do not move a value 15:13:28 like it's valid for; m[t|f]lr (and variants) and mr, but other than that I can't think of any right now 15:13:40 or rather mtspr and mr 15:14:41 it's also valid for stores of course 15:14:56 and loads 15:15:34 err... 15:15:35 and I believe it's valid as a destination parameter for add,sub,or etc 15:15:42 but not as a parameter 15:15:58 but I don't remember this exactly of the top of my head. 15:16:06 that's what I'm saying, I just checked. 15:16:36 * slava cheers 15:16:37 tathi: ok I got you wrong then 15:16:42 li rA,SIMM = addi rA,r0,SIMM 15:16:46 ditto for lis 15:17:02 ya; I didn't assume you meant "parameter" use only 15:17:13 and in loads/stores, like so: lwz r3,0(r0) loads r3 from address 0. 15:17:33 ditto lwzx r3,r0,r4 loads r3 from address in r4. 15:17:43 y 15:18:01 other than that, looks like r0 always actually means r0. 15:18:05 thought you meant things like addi r0,r3,r4 was invalid too. 15:18:28 well...that is invalid. :P 15:18:38 yes :) 15:18:41 remove -i 15:18:50 or, at least, under GAS will assemble addi r0,r3,4 without a warning or anything. 15:19:03 addi r0,r3,4 is supposed to be valid 15:19:09 yup. 15:19:15 my assembler gives no warnings at all :) 15:19:31 * tathi can't remember how many times he has typed addi when he meant add... :( 15:19:32 and things like xoris r0,r5,35 15:19:33 etc 15:19:41 right 15:20:29 anyway best is just avoid r0 as much as possible; just mflr r0; stw r0,xxxx(xx) and don't use it after that and you avoid potential hard resolved problems. 15:21:19 I do tend to use it as a temporary value, but...that's just me. 15:21:35 I think the PowerPC generally has enough registers anyway 15:22:00 yeah. 15:22:15 but of course it can be used as a temporary value; but it's easy to start feeding it to add or whatever and suddenly you have a bug you just can't find :) 15:22:45 especially like in this case; having automated register allocation 15:23:36 yup. 15:27:29 --- quit: I440r_ ("Leaving") 15:51:25 x86 integer division is floored (rounds quotient towards negative infinity) 15:51:37 ppc integer division is symmetric (rounds quotient towards zero) 15:51:52 just thought I'd mention that; most code doesn't care, but... 15:57:30 --- quit: tathi ("volleyball :)") 16:26:00 --- join: Sonarman (~snofs@adsl-67-113-234-111.dsl.snfc21.pacbell.net) joined #forth 17:49:23 --- quit: swalters (Read error: 104 (Connection reset by peer)) 18:29:06 --- part: aum left #forth 18:33:10 --- join: zardon (~zardon@S0106000d6151238b.gv.shawcable.net) joined #forth 18:35:02 --- join: TheBlueWizard (TheBlueWiz@ts001d0547.wdc-dc.xod.concentric.net) joined #forth 19:10:27 --- join: saon_ (1000@c-24-129-90-197.se.client2.attbi.com) joined #forth 19:10:27 --- quit: saon (Read error: 104 (Connection reset by peer)) 19:25:13 --- quit: Sonarman (Read error: 104 (Connection reset by peer)) 19:48:38 bye all 19:48:47 --- part: TheBlueWizard left #forth 20:14:08 --- join: swalters (~swalters@2416457hfc118.tampabay.res.rr.com) joined #forth 20:34:39 --- join: Sonarman (~snofs@ppp-66-124-254-111.dsl.snfc21.pacbell.net) joined #forth 22:04:00 --- quit: zardon (Read error: 60 (Operation timed out)) 22:12:29 --- quit: Sonarman ("leaving") 22:14:13 --- quit: Quartus (Remote closed the connection) 22:17:30 --- join: Rockford (~trailer@ansuz.pair.com) joined #forth 22:18:16 --- quit: Rockford (Remote closed the connection) 22:18:53 --- join: Rockford (~trailer@ansuz.pair.com) joined #forth 22:18:57 --- nick: Rockford -> Quartus 22:36:45 --- join: tkb (~tkb@dhcp-69-43-1-059.pitbpama-max5.dialup.citynet.net) joined #forth 22:48:20 --- part: tkb left #forth 22:52:03 --- join: zardon (~zardon@S0106000d6151238b.gv.shawcable.net) joined #forth 23:56:06 --- quit: Herkamire ("off to bed") 23:59:59 --- log: ended forth/05.03.15