00:00:00 --- log: started forth/04.09.20 01:11:57 --- join: mur_ (~mur@smtp.uiah.fi) joined #forth 01:22:24 --- quit: mur (Read error: 110 (Connection timed out)) 01:23:20 --- quit: Herkamire ("bed") 02:47:21 --- join: crc (crc@88-pool1.ras11.nynyc-t.alerondial.net) joined #forth 02:50:18 --- quit: mur_ (Remote closed the connection) 02:50:54 --- join: mur (~mur@uiah.fi) joined #forth 03:04:29 --- quit: Serg_penguin (Read error: 104 (Connection reset by peer)) 04:07:56 --- join: mur_ (~mur@uiah.fi) joined #forth 04:09:28 --- quit: mur (Read error: 60 (Operation timed out)) 04:09:45 --- nick: mur_ -> mur 04:53:55 --- join: crc_ (crc@158-pool1.ras11.nynyc-t.alerondial.net) joined #forth 04:54:20 --- quit: crc (Nick collision from services.) 04:54:24 --- nick: crc_ -> crc 04:54:29 --- quit: mur (Remote closed the connection) 04:55:44 --- join: mur (~mur@mgw2.uiah.fi) joined #forth 05:09:26 --- join: saon (Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 05:31:49 --- quit: saon ("Leaving") 06:08:11 hi for a bit :) 06:08:17 --- nick: arke|sleep -> arke 06:08:21 arke: how was work? 06:08:27 kc5tja: how was work? 06:09:26 hello arke 06:11:44 --- join: I440r_ (~mark4@216-110-82-203.gen.twtelecom.net) joined #forth 06:11:49 Hey 06:12:37 arke: Work is kind of sucking today. 06:12:49 kc5tja: yeah, just read the backlog of the other channel 06:12:50 hi crc 06:19:10 * crc is working on a VESA driver now 06:19:58 crc: noooo! :) 06:20:05 crc: my driver would be better. :) 06:20:39 Then write it and send it to me :-) 06:20:55 crc: have to go to school, and got another project. 06:20:57 Mine's limited to 8-bit color 06:20:58 :-) 06:21:04 hehe 06:21:05 lamer 06:21:06 :) 06:21:14 I don't need anything more 06:21:34 ....lamer! :) 06:21:49 * crc also has no way to use anything more; my video chipset can't create a linear framebuffer with higher color depths 06:22:10 hehe 06:22:32 arke: I lived with 8-bit color until I got this laptop; I don't need more for anything other than editing photos 06:23:17 * crc seldom uses more than 16 colors at a time anyway 06:23:54 :) 06:24:19 brb, shower etc. 06:24:42 ok 06:36:06 --- join: qFox (C00K13S@82-169-140-229-mx.xdsl.tiscali.nl) joined #forth 06:40:53 back 06:40:59 hi c00k13s 06:43:03 I just fixed two bugs in the serial port driver 06:43:18 Now it will work properly :-) 06:43:24 :) 06:44:21 --- quit: mur (leguin.freenode.net irc.freenode.net) 06:45:01 5 words, 5 constants, and 6 lines of initialization code 06:45:10 --- join: mur (~mur@uiah.fi) joined #forth 06:45:51 I could reduce that a little if I was willing to hard code the port address... 06:46:44 I also rewrote half of my block editor this morning 06:46:49 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 06:46:49 --- mode: ChanServ set +o Herkamire 06:47:05 * crc has made a lot of progress on RetroForth over the weekend 06:47:15 hi Herkamire 06:47:23 Herkamire: I'll try when I get back from school today 06:48:05 arke: cool. thanks. 06:48:34 arke: you got the links? 06:49:12 Herkamire: yeah. 06:50:10 --- join: saon (Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 06:52:22 gotta catch a buss. bbiab 06:55:41 --- nick: arke -> arke|school 06:57:55 Well folks, I'm on my way home. Good morning. 07:05:30 Heh, good afternoon. 07:16:41 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 07:21:41 Back home. 07:21:56 :) 07:24:19 --- join: madwork_ (~madgarden@derby.metrics.com) joined #forth 08:01:56 --- quit: crc (Read error: 110 (Connection timed out)) 08:06:22 --- join: ianp (ian@inpuj.net) joined #forth 08:08:20 --- join: juhammed (~o@dsl-olugw3p33.dial.inet.fi) joined #forth 08:08:59 Hej. 08:09:44 hej 08:12:21 :) 08:14:24 --- quit: Robert ("brb") 08:32:16 --- join: Robert (~snofs@c-bf5a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 08:35:01 arke|school> i dont have a highlight on cookies you know :) 08:42:22 --- quit: Robert ("brb (grrr...)") 08:56:00 --- join: Robert (~snofs@c-bf5a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 09:09:06 --- join: arke (apache@11.198.216.81.dre.siw.siwnet.net) joined #forth 09:10:02 hi 09:10:46 Hi 09:11:09 how was school? 09:11:17 aha! 09:11:20 Not too bad. 09:11:34 found the bug!!! 09:11:44 window stuff works in isForth/PPC now :) 09:12:34 tathi: yay :) 09:12:47 another case of I440r using +! on a word-sized value...grrr... 09:25:59 :) 09:28:01 --- quit: tathi ("lunch") 09:45:10 tathi lol 09:45:12 --- join: jdrake (~jdrake@CPE00045afdd0e8-CM014410113717.cpe.net.cable.rogers.com) joined #forth 09:45:21 tathi awesome 09:48:47 Regarding that patent thing with kestrel - Is it possible to actually make anything that does not infringe on a patent? 09:49:15 babies 09:49:34 afaik, anyway 09:52:26 --- join: warp0b00 (~warpzero@mi065.dn185.umontana.edu) joined #forth 09:55:03 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 10:05:22 --- quit: arke ("CGI:IRC 0.5.4 (2004/01/29)") 10:21:27 --- quit: tathi ("yardwork") 10:49:17 --- join: wossname (~wossname@rn-v1w5a06.uwaterloo.ca) joined #forth 11:12:32 --- quit: saon ("Leaving") 11:30:19 --- quit: jdrake (Read error: 110 (Connection timed out)) 11:32:34 fridge: LOL! 12:15:31 --- quit: wossname (Read error: 110 (Connection timed out)) 12:27:16 --- join: saon (Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 12:28:12 --- join: jdrake (~jdrake@CPE00045afdd0e8-CM014410113717.cpe.net.cable.rogers.com) joined #forth 12:30:05 --- quit: saon (Read error: 104 (Connection reset by peer)) 12:48:01 --- join: mark_s (mark@pcp04088066pcs.wbrmfd01.mi.comcast.net) joined #forth 13:01:20 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 13:07:16 --- join: arke (apache@11.198.216.81.dre.siw.siwnet.net) joined #forth 13:34:32 --- quit: Frag-101 (Remote closed the connection) 13:38:33 --- join: wossname (~wossname@rn-v1w5a06.uwaterloo.ca) joined #forth 13:40:33 --- quit: qFox ("this quit is sponsored by somebody!") 14:01:56 --- quit: arke ("CGI:IRC (EOF)") 14:13:53 --- nick: proteusguy -> python-dinner 14:14:11 --- join: Frag-101 (XINU@12-222-128-22.client.insightBB.com) joined #forth 14:31:11 --- nick: python-dinner -> proteusguy 14:39:49 --- join: crc (crc@198-pool1.ras11.nynyc-t.alerondial.net) joined #forth 14:49:05 --- join: Topaz (jonny@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 15:17:04 --- quit: crc (Client Quit) 15:18:21 hi 15:28:53 --- join: das (~das@adsl-64-219-100-33.dsl.lgvwtx.swbell.net) joined #forth 15:36:21 --- nick: arke|school -> arke 15:55:13 hi das, arke 15:55:22 hi slava 15:55:31 hello slava 15:55:40 das, ever done graphics in forth? 15:56:22 --- quit: Topaz ("Leaving") 15:57:08 slava: some. I've done line drawing, and did a spectral display, and some simple bitmap displayers. 15:57:45 Also did some bitmapped font rendering 15:58:30 arke, i just realized that my c library interface was generating code that looked like gcc without -fomit-frame-pointer :) 15:58:39 arke, i'm pushing and popping the stack frame for no benefit :) 15:59:24 yeah 15:59:26 hey das.. im at work but about to leave :) 15:59:33 I always -fomit-frame-pointer 15:59:39 brb from home :) 15:59:46 ok I440r 15:59:51 alright 15:59:52 arke, i don't if i need to use gdb :) but for auto-genreated code you can't use gdb anyway 16:00:45 code compiled without -fomit-frame-pointer is bad. 16:01:19 yeah 16:01:25 its just bloat : 16:01:26 :) 16:01:40 any idea why gcc generates this sequence 16:01:41 subl $12,%esp 16:01:41 addl $-12,%esp 16:01:56 even with -O! 16:02:06 when I was doing forth primitives in C, that was one of the first things I ran into. 16:02:25 das, i'm making a forth with types ;)_ 16:02:33 slava: thats weird.... :) 16:02:54 arke, you'd think subl $24,%esp would be better :) 16:02:56 slava: with compile time type checking? hehe... :) 16:02:59 das, runtime 16:03:11 slava: :) 16:04:10 slava: runtime is easy. I'd like to see a forth compiler enforce stack comments (provided the stack comments follow the AnsForth standard) 16:04:42 not really serious though about that, as there is no substitute for complete unit testing of all words 16:05:08 das, its hard to deduce stack effects in the presence of immediate words 16:05:21 das, since they can affect the compiled code in an undefined way 16:06:27 das, my main goal with runtime checking is safety (or the illusion thereof); when pointer types and bounds etc are checked, its easier to write secure network code. 16:08:44 for code exposed to the network, I agree there must be strict enforcement. Once data is trusted however, I see no need for a lot of runtime checks that should never find anything wrong. Provided the code has been properly tested, and all data from unknown/untrusted sources has been validated. 16:14:15 --- nick: arke -> bent_penis_rk 16:15:03 arke, we don't want to know 16:15:06 das, ever used lisp? 16:15:46 slava: don't ask ;) 16:18:41 played around with it a little bit. It has been a while. 16:41:52 --- nick: bent_penis_rk -> arke 16:46:46 --- quit: wossname (Read error: 60 (Operation timed out)) 16:58:43 --- join: imaginator (~George@georgeps.dsl.xmission.com) joined #forth 17:00:50 hi imaginator 17:01:45 --- join: Sonarman (~matt@adsl-64-160-167-8.dsl.snfc21.pacbell.net) joined #forth 17:02:10 Sonarman: MY LOVE 17:02:35 how my heart pines for thee 17:02:37 o 17:02:45 Hi slava 17:06:34 --- quit: tathi ("*poof*") 17:11:56 --- join: wossname (~wossname@rn-v1w5a06.uwaterloo.ca) joined #forth 17:19:30 wossname! 17:19:32 :) 17:25:31 ~:") 17:25:31 hi arke 17:25:35 hack any planets recently? 17:25:45 --- nick: das -> das-away 17:25:54 naah 17:26:00 just some old asteroid belt 17:26:02 wasnt even worth it 17:26:05 ;( 17:26:10 how's F2? 17:27:38 on hold 17:27:42 working on kc5tja's forth 17:28:05 ah? writing which bitties!? 17:30:35 BLOCK words for the cross compiler 17:31:36 arke!!! i have a quesiton 17:31:44 arke, even when passing bytes and shorts, we still use pushl? 17:31:51 arke, so its as if everything was really 32-bit? 17:31:55 arke, to C functions I mean 17:32:16 --- quit: madgarden ("*frotz*") 17:33:04 slava: yeah. Its for performance reasons, and to make things less likely to segfaults 17:35:57 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3575833.sympatico.ca) joined #forth 17:37:06 Do not fear, for I have returned. I was gone but a moment... stop your crying, woman! 17:37:24 hi 17:37:31 Oh, hi there. 17:46:56 hi madgarden 17:47:04 hi arke 17:48:01 * arke is now known as bent_penis_rk 17:50:41 [arke] (f2@bespin.org) : - 17:50:41 --- [arke] #asm @#BDSM #forth @#gay_sauna #pr0n 17:51:04 --- [arke] irc.freenode.net :http://freenode.net/ 17:51:04 --- [arke] idle 00:01:51, signon: Sun Sep 19 17:03:21 17:51:30 17:51 [freenode] -!- slava [~slava@CPE00096ba44261-CM000e5cdfda14.cpe.net.cable.rogers.com] 17:51:34 17:51 [freenode] -!- ircname : Slava 17:52:16 17:51 [freenode] -!- channels : #c #sdl #lisp @#jedit #factor #forth #java #asm @#kiddiepr0n #forth-haters #azncock 17:52:24 17:51 [freenode] -!- server : irc.freenode.net [http://freenode.net/] 17:52:24 17:51 [freenode] -!- : is an identified user 17:52:24 17:51 [freenode] -!- idle : 0 days 0 hours 0 mins 15 secs [signon: Mon Sep 13 08:18:50 2004] 17:52:27 17:51 [freenode] -!- End of WHOIS 17:52:28 lol 17:52:35 #azncock? 17:52:36 lol 17:53:40 re 17:55:25 slava: Also, x86 has no facility to push anything less than a natural word size onto the stack. So 32-bits is all you get. 17:55:57 kc5tja: hi 18:00:50 Isn't there an MMX stack? 18:00:59 With 128-bit words? 18:01:14 the on-cpu fp stack has 80-bit wide words 18:01:19 MMX is registers not stack 18:02:27 --- join: madgarden_ (~madgarden@Toronto-HSE-ppp3706485.sympatico.ca) joined #forth 18:03:05 --- quit: madgarden (Nick collision from services.) 18:03:11 umm 18:03:21 -kiddiepr0n-??! 18:03:37 ugh. 18:03:38 --- nick: madgarden_ -> madgarden 18:04:34 jim, arke is ops there 18:04:53 as are you 18:04:54 --- join: madgarden_ (~madgarden@Toronto-HSE-ppp3706485.sympatico.ca) joined #forth 18:04:54 --- quit: madgarden (Nick collision from services.) 18:04:56 --- nick: madgarden_ -> madgarden 18:05:08 --- part: madgarden left #forth 18:05:10 jim, i got kickbanned by arke 18:05:39 why did either of you join? 18:05:43 --- join: madgarden (~madgarden@Toronto-HSE-ppp3706485.sympatico.ca) joined #forth 18:05:43 --- quit: madgarden (Nick collision from services.) 18:05:50 --- join: madgarden (~madgarden@Toronto-HSE-ppp3706485.sympatico.ca) joined #forth 18:05:50 --- quit: madgarden (Nick collision from services.) 18:05:58 --- join: madgarden (~madgarden@Toronto-HSE-ppp3706485.sympatico.ca) joined #forth 18:05:58 --- quit: madgarden (Nick collision from services.) 18:06:04 Now that is rather interesting... 18:06:14 It seems madgarden is having some rather interesting "issues." 18:06:51 nuthin to say to that question? 18:07:02 jim, you're one to talk 18:07:05 /whois jim 18:07:05 [jim] (~jim@cpe-24-143-141-183.cable.alamedanet.net) : Jim Lynch 18:07:05 --- [jim] #arch @#beastiality @#buttplugs #tcl #forth #h4x0r-cr3w 18:07:05 --- [jim] irc.freenode.net :http://freenode.net/ 18:07:05 --- [jim] is an identified user 18:07:06 --- [jim] idle 00:00:36, signon: Thu Sep 16 15:52:37 18:07:12 --- [jim] End of WHOIS list. 18:07:17 --- join: madgarden (~madgarden@Toronto-HSE-ppp3706485.sympatico.ca) joined #forth 18:07:30 Gah. 18:07:44 but I'm not on either of those channels 18:07:52 jim, /whois says you are 18:07:58 jim, maybe you have a virus? 18:08:38 maybe this should become a server-op issue 18:08:58 maybe you should /msg dmwaters or lilo about it. 18:09:05 jim, i think you got hacked 18:09:13 :o 18:09:14 jim, did you just offer me a DCC transfer of TittySuck.mpg? 18:09:14 a hacker? 18:11:34 jim, you do know that they exploited that version of xchat to do spoof IRC requests? 18:11:34 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 18:12:01 no, I wasn't aware of that 18:12:02 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576207.sympatico.ca) joined #forth 18:12:05 jim, i know a few people who got rootkits through xchat 18:12:16 jim, latest version too 18:12:49 how (approx :P ) is it accomplished 18:12:50 ? 18:13:16 jim: its a buffer overflow in Xchat's IRC parsing code, which can be exploited with an illegal IRC request 18:13:44 jim: it basically enables an attacker to perform any IRC action, without it being visible to the user 18:14:08 such as causing him to join channels? 18:14:20 jim, also using your machine as a spam relay 18:14:49 for email spam? or what kind of spam? 18:14:57 jim, email and instant messaging 18:15:26 ok... fine... I'm looking for a different client :P 18:15:59 --- join: madgarden_ (~madgarden@Kitchener-HSE-ppp3576798.sympatico.ca) joined #forth 18:16:00 maybe I'll go back to ircII, but that thing looks horrible in an xterm 18:16:03 jim: I suggest IRSSI 18:16:23 jim: its console, and similar, but veryu secure, modular, extenbsible, and l33t 18:16:43 that last one doesn't do much for me :P 18:16:55 :) 18:17:00 I definetely recommend it. 18:17:08 jim, we fooled you pretty good didn't we 18:17:14 well 18:17:17 hehehe 18:17:19 yeah 18:17:27 HAHA 18:17:27 :) 18:17:28 jim, none of those channels existed 18:17:45 and no, xchat is not vulnerable :) 18:17:49 SMILE! YOU'RE ON CANDID CAMERA!! :) 18:17:51 ask kc5tja, he did investigations even 18:17:55 Please tell me you're joking with him. My investigations show he's definitely not on #bestiality. 18:18:08 haha 18:18:15 that is such good bash material right there :) 18:18:23 slava: Only in the last 45 seconds or so though; I was afk for most of this. 18:18:32 I probably would have blown the whistle earlier if I'd been here. 18:20:23 What an odd series of conversations I see here. 18:20:49 :) 18:21:31 yeah, kinda dumb of all of us if you ask me 18:21:44 jim, the only one who was fooled was you :) 18:21:45 this is the bit I thought would suit bash.org: 18:21:46 12:48 < jdrake> Regarding that patent thing with kestrel - Is it possible to actually make anything that does not infringe on a 18:21:49 patent? 18:21:52 12:49 < fridge> babies 18:21:54 12:49 < fridge> afaik, anyway 18:21:55 arke, is there a limit of 7 paramters in the C calling convention? 18:22:04 slava: uum, no... :) 18:22:06 slava: no 18:22:11 then i'm confused 18:22:33 I'm not aware of any limitation on the number of parameters to C functions, but it's certainly more than 10 18:22:40 who does calling a C function that takes 1 arg cause gcc to emit 18:22:42 24 ESP R-I 18:22:45 i mean 18:22:50 subl %esp,$24 18:22:58 before pushing 18:23:12 right now i generate this sequence and it works but i don't understand what it does 18:23:19 the c func probably has lotsa local vars 18:23:31 it depends on the number of local vars of the func? i don't think so... 18:23:35 the C func allocates those, not the caller 18:23:36 or returns a struct 18:23:37 since adding new locals doesn't break anything 18:23:43 no, returns an int 18:23:45 in EAX 18:23:54 is it just odd padding generated by gcc? 18:23:59 maybe it tries to align the stack for performance? 18:24:13 There are no maximum argument list sizes in C. 18:24:14 24 seems an odd alignment tho... 18:24:33 slava: Are you passing the item by value or by reference? 18:24:39 unless it's trying to align to something like 64 or larger 18:24:40 kc5tja, ints by value 18:24:55 And the subl instruction is *inside* the function being called? 18:25:01 If so, it'd be for its own local variables. 18:25:19 no 18:25:21 kc5tja, its like this 18:25:24 subl %esp,$24 18:25:26 call foo 18:25:32 i mean 18:25:34 subl %esp,$24 18:25:37 pushl $123 18:25:39 call foo 18:25:44 addl %esp,$28 18:25:51 so its like... wasted stack space 18:25:53 in fact 18:25:59 Whoa, that's actually a pretty bad bug. 18:25:59 it works without the wasted space 18:26:01 seems that way 18:26:11 no i think gcc is trying to be clever 18:26:17 like an optimization gone wrong 18:26:21 Wasted stack space be damned, the fact that you're adding 4 more than you're subtracting means that stack space is being anti-leaked. :) 18:26:27 kc5tja, no 18:26:31 kc5tja, you see there's a pushl 18:26:40 Oh, oops. 18:26:45 kc5tja: no, the push is there too 18:26:56 l == 4 bytes, hence 28 18:26:57 That makes sense then. 18:27:05 jim: I know it's a 32-bit architecture. 18:27:16 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 18:27:35 --- quit: wossname (Read error: 60 (Operation timed out)) 18:27:57 The called function: does it return a structure by value by any chance? 18:28:17 kc5tja, int SDL_Init(int) 18:29:33 I'm wondering if the extra space is used for exception-handling purposes -- a possibility if libSDL is written in C++. 18:30:08 its a C library 18:30:49 OK, next question: in the function that you're calling SDL_Init() from, do you have any local variables at all? 18:31:06 Because, technically, EBP (not ESP) is used as the frame pointer. There should usually be something like: 18:31:11 movl %esp,%ebp 18:31:17 subl $someValue,%esp 18:31:18 ..etc.. 18:31:27 kc5tja, i'm generating code like -fomit-frame-pointer 18:31:35 OK. 18:31:52 Still, you get the idea. 18:32:00 It has to still allocate space for local variables. 18:33:13 god the people in #c are dumb 18:33:20 ya 18:33:22 they're like 'why do you care if there's wasted space on the stack, are you doing embedded or something'? 18:33:24 anal too 18:33:43 The only other thing I can think of is that the C compiler is trying to allocate new stack elements on an even cache-line boundary (which it cannot guarantee it's doing, of course). 18:36:05 i like the way i developed by C interface. 18:36:14 I started by writing assembly wrappers for a few SDL functions, tested them, they worked 18:36:22 then I refactored them into a set of assembler macros 18:36:44 now its nice and high level, you pretty much just specify the C function prototype 18:36:48 but really its just assembler macros 18:37:08 slava: Since I'm interested in eventually doing the same for FTS/Forth, I was wondering if you can provide some sample syntax for that? 18:38:10 slava, are you calling C functions from Forth? 18:39:51 mark_s: hi mark, whats new? :) 18:40:04 hi arke 18:41:29 Thinking of changing some things in XcolorForth, maybe creating some applications. 18:47:03 does any one know elf? 18:47:16 heh, you've come to the right place :) 18:47:28 would anybody here try herkforthos under PearPC for me? 18:47:49 I want to know if the frame buffer stuff works on pearpc on x86 18:48:32 kc5tja, "surface*" "SDL_SetVideoMode" [ "int" "int" "int" "int" ] 18:48:42 mark_s, if you consider factor as a forth, which I don't :) 18:51:00 crap 18:51:20 slava, what is factor? 18:51:22 I set up output buffering 18:51:37 I made it so that herkforth sends all the characters for the display in one write() 18:51:50 and still pearpc displays them slow as hell 18:52:07 mark_s, similar to forth but with data types and automatic memory management 18:52:43 takes it about two secconds to update the screen. 18:52:53 that's not emulating anything. 18:53:02 well, it's a terminal emulator... 18:53:28 but it's not emulating PPC, it's just displaying the ~900 characters I sent. 18:53:41 2 secconds! 18:54:07 how the hell am I supposed to make a decent user interface if it takes 2 secconds to update that puny screen? 18:54:17 run it native ;) 18:54:28 it runs just fine native 18:54:39 native, the screen updates can keep up with the keyboard repeat rate 18:54:41 do you intend people to use it in pearpc normally? 18:54:59 I intended for peoply to try it out in pearpc 18:56:02 slava, do you do your own linking or do you use the C linker? 18:56:54 mark_s, i dlopen() libraries, then get the addresses of their symbols with dlsym(), and compile words that call these functions with parameters from factor's stack 18:58:34 slava, ok, that is probably how I would do it. 18:58:52 mark_s, its not exactly portable, but... 18:59:07 what about ffcall? 18:59:25 i'm not sure that would help me with anything 18:59:31 i'd still need to write code to box/unbox my types 18:59:54 my integers are shifted by 3, strings are unicode with a length prefix, floats are heap allocated, etc. 18:59:55 that part is true 19:00:21 with the current scheme i get equivalent performance for C functions and hand-coded primitives 19:00:25 shifted? 19:00:38 jim, in factor, a 32-bit 'cell' consists of 29-bit data field and 3 bit tag 19:00:48 jim, tag 0 means the 29 bits is an integer 19:00:55 jim, other tags mean its a pointer to an ojbect of some time 19:00:57 s/time/type/ 19:01:14 eg, tag 1 is word, tag 2 is pair, tag 3 is variable-length (string or array, etc), etc 19:01:27 mmm, same mistake Apple made... non-clean pointers... 19:01:37 'non-clean'? 19:01:46 i allocate everything 8-aligned and mask off the low 3 bits 19:01:47 no problems there 19:02:27 they had to expend a lot of effort to get flag bits out of pointers and into their own storage 19:02:41 you're talking about the 24/32-bit fiasco right 19:02:46 yeah 19:02:48 that was a real problem since 24 bits limits you to 16mb 19:02:56 however this is not an issue for me, there are no limits 19:03:12 everything is a size that is a multiple of 8 anyway 19:03:30 no point ever heap-allocating just one 32-bit quantity! 19:03:46 there is that... 19:04:40 python for example heap-allocates integers 19:04:44 that is terrible 19:05:37 :) 19:05:40 it's probably not just the integer itself tho 19:05:50 don't they have an object system? 19:05:52 yes, python objects have huge headers 19:06:01 each object has next/prev pointer, ref count, and the data itself 19:06:03 that's 12 bytes wasted 19:06:41 perl does something like that too 19:07:17 in factor a cons cell (pair of objects, link lists are made from cons cells) uses 8 bytes in the heap total 19:07:20 no header, no bullshit :) 19:07:51 sounds like lisp 19:07:53 kc5tja: write the tests first, then write the words to fulfill the tests, right? 19:08:08 or write them together 19:08:34 arke, write the bugs, then the tests to miss the bugs, then some code that is broken 19:08:36 :) 19:08:50 decisions you make about the code in midstream could affect the tests 19:09:08 jim, it *is* like lisp, and lisp is better than python or perl :) 19:09:25 I hardly consider 12 bytes to be much waste. 19:09:25 :) 19:09:29 "better" 19:09:46 that depends on the app :) 19:09:47 kc5tja, its a waste if you have thousands of live integers 19:09:54 kc5tja, EVERY integer is boxed in python 19:10:08 in factor an integer is heap-allocated only if it grows beyond 29 bits which hardly ever happends 19:10:24 slava, what kind of collector do you have? 19:10:27 you could create a type which is a collection of integers, such as an array or matrix with one box 19:10:33 mark_s, simple copying collector 19:10:40 arke: If you're doing test-driven development, yes. 19:10:53 mark_s, allocation is incrementing 'here' pointer, gc is a copy/collect loop 19:11:00 (you'd have to do it in C or something like that) 19:11:12 jim: No. You get better software if you write your "specifications" (the tests) first. 19:11:43 jim, i already have an 'alien' type which is just an arbitrary byte array, for accessing the SDL framebuffer, and such 19:12:12 all I'm saying is the same could be done in python 19:12:17 if anyone's willing, here's the test I'd like someone with x86 linux to try in pearpc: http://herkamire.com/downloads/herkforth_pearpc_test.tar.bz2 19:12:23 bath. brb 19:12:33 jim, but it would reuqire more effort 19:12:36 yes 19:13:41 but if the app required it, or if it would be more efficient and if the programmer had the greater experience with python and the app would be better off with python, might as well use python :) 19:13:48 so that's a lot of ifs 19:14:47 s/python/insert any other language here/ 19:17:35 kc5tja: as for myself, I usually develop in oop, and I'm often looking at several classes at once, adjusting their code and interfaces to factor in an increasingly/incrementally more "natural" way 19:17:57 jim: TDD is 100% orthogonal to that. 19:18:09 what's TDD? 19:18:14 jim: Test-driven development 19:18:44 In fact, with TDD, refactoring code is made significantly safer because of the existance of repeatable unit tests to back up every change you make. 19:18:49 well, but that's not necessarily true, depending on how and what you're testing and how deeply 19:19:05 jim: I've yet to find one exception, save GUI code. 19:19:45 by "interface" I mean method names and parameters 19:20:04 And the only reason GUI code isn't "unit-testable" is because of the inherently intractable nature of GUIs (e.g., very few GUI toolkits let you construct and tear down whole windows with arrays of buttons easily and repeatably, let alone faking input events to them) 19:20:23 jim: And.....so? 19:20:35 and there are times when refactoring might cause a change in a test 19:20:43 Such as? 19:20:58 Sure it might change lower-level tests. But it should never affect higher-level tests. 19:21:26 higher-level meaning overall exposed functionality? 19:22:28 if yes, I'd agree to that 19:22:57 That's the whole premise. 19:23:06 Now repeat. Indefinitely. To all the lower layers. 19:23:20 refactoring code involves, if necessary, refactoring tests too. 19:23:40 yes... so, tests change 19:23:46 Of course they do. 19:23:51 Tests are, by definition, requirements. 19:24:02 I'm not familiar with one software product that, through its evolution, requirements don't chang.e 19:24:38 The tests are a safety net. They catch discrepencies -- either through compiler errors, or run-time verification errors. 19:24:39 well, I see tests as a way to see if the code does what it's supposed to :) 19:24:51 THAT'S REQUIREMENTS!! 19:25:04 How can you see them as two totally different things? 19:26:27 Because I have never seen requirements as anything other than a english document saying what is required 19:27:14 Well, if tests are intended to ensure conformance to requirements, then it follows the tests are merely a restating of the requirements into a computer processable form. 19:27:47 -yes-, restating being a keyword here :) 19:27:55 But why restate? 19:28:04 so that it's readable 19:28:05 That's just a waste, and opens the opportunity to bugs. 19:28:15 What? 19:28:23 I give up. 19:28:52 additionally, the programmer doesn't always write the requirements document... a non-programming manager does sometimes :) 19:29:10 the programmer would have to codify that document to get the tests 19:29:11 I can assure you that I have plenty of experience with coding in a commercial environment. 19:29:17 You are correct. 19:29:36 that would constitute a restatement of the requirements :) 19:29:47 all I'm saying is it's -possible- it could go that way 19:29:58 however, the point is, when coding software, one should maintain the tests first and foremost, since they form the scaffolding around which the remainder of the software is built. 19:31:29 as far as the gui thing, that doesn't have to be an exception to your pov, because there are tools (like expect) that could be used to perform the tests 19:31:34 In my practical experience, TDD has let me write and debug software "in real time." It has cut my use of a debugger from several times a week to maybe twice a year. 19:31:57 that's impressive 19:32:33 i only ever use a debugger for C 19:32:39 to get a backtrace when my shit crashes 19:33:17 kc5tja: what are your "twice a year" debug sessions like? 19:33:22 If this is the expect that I think you're talking about, that won't work because it won't easily integrate with lower-level unit testing. It is good for what XP calls "acceptance testing," however -- but even here, it is still limited to console I/O. 19:33:56 do you typically do XP in your work? 19:34:07 jim: In my personal work, I try to code as XP-like as I can. 19:34:31 dammit i have to figure out a way to represent unions in my FFI. 19:34:45 I use abstract state machine modeling to force a distinction between myself as a customer, and myself as a programmer. Working on the ASM model allows me to clearly think about the problem and come up with invariants and requirements in "story" form. 19:35:11 Then, as a programmer, I code up tests that implement the invariants, and THEN code the business logic. 19:35:20 As requirements change on the fly, I always make sure to update the tests *first*. 19:35:22 I take it ASM is not assembly language? 19:35:32 Abstract State Machine. 19:35:44 It's a kind of "formal method." 19:35:48 i'm going to sleep. 19:35:49 Although I don't use it as such per se. 19:36:01 slava: Night! 19:36:03 well, first i'm doing my bedtime reading; Smalltalk-80 language and implementation. ("Purple book"). 19:36:23 jim: However, if I'm working for someone else, I just completely forego the whole ASM step, and just communicate directly with the customer. 19:36:35 And yes, the customer's needs very often changes VERY rapidly. That's OK. I bill by the week. 19:36:56 (and XP is the only model I'm aware of that adequately handles someone who changes their mind on a daily basis too.) 19:37:13 I don't see how ASM gets you a separation of you as customer vs you as coder 19:38:27 Because an ASM is a formal, mathematical representation, I can look at it from an algebraic point of view at the highest level of abstraction, and work downwards from there. 19:39:00 It's a "big picture view" of what the problem entails, and therefore lets me see interactions between different components easier. 19:40:21 ASMs make ideal specification languages too, which is a characteristic trait of all formal design methods. 19:41:09 Anyway, to answer your other question about the debugging sessions, it's usually involving a non-unit-testable component of some kind. 19:41:35 ahh, such as a piece of the gui 19:41:35 For example, when writing the FTS/Forth cross compiler -- I had *no* way to unit test it, since it is a chicken/egg problem to do so. I need FTS/Forth running before I can unit test FTS/Forth components. 19:42:49 BTW, this is another *great* reason why you should always factor your code into models, views, and controllers if possible: models and views are usually rather easily unit testable. Controllers, however, not so. By factoring along the "MVC" model in a user interface, you can concentrate on hand-debugging only the (relatively few) controllers in the system. 19:42:54 The rest can be automated with ease. 19:43:10 Plus, it opens the door to external scriptability. 19:43:44 I remember when DeluxePaint IV for the AmigaOS came out -- it had an ARexx port (a long time coming, too) for the first time. Turns out that only a *small* subset of its actual capabilities were exposed via the Rexx port! I was PISSED. 19:43:54 But that's what happens when you don't factor your code well. :( 19:44:59 could you cross compile either a minimal system or a full kernel, plus a word involved in your unit test? then, the test is: "does the do loop work? does leave work out of the do loop?" etc 19:45:17 That's the other thing too. I've found that following TDD mercilessly has actually allowed my software to be WAY better factored than I normally would have made it. 19:45:55 --- nick: das-away -> das 19:45:59 jim: I've only recently gotten to the point of being able to unit test from within FTS/Forth, even though the interactive environment isn't up. 19:46:12 In GForth, my tests look like this: 19:46:24 : t1 .... abort" BLK:t1" ; t1 19:46:32 : t2 ..... abort" BLK:t2" ; t2 19:46:33 etc. 19:46:49 With FTS/Forth, because of the lack of interactive environment and no interpreter, I can only do this: 19:47:12 : t1 .... if S" BLK:t1" type bye then ; 19:47:25 : t2 .... if s" BLK:t2" type bye then ; 19:47:26 ... 19:47:32 : tests t1 t2 t3 ... tN ; 19:47:36 err, oops, 19:47:44 : tests [entrypoint] t1 t2 t3 ... tN ; 19:47:59 kc5tja: did you get TDD from a book, or did you develop the methodology yourself? 19:48:07 I have to go for awhile... but, to be continued 19:48:34 das: My methodology has been evolving since I was a teenager -- I had independently arrived at the practice of isolating my failures as a coder and learning from the experience and finding ways to never repeat the same old mistakes. 19:49:06 However, I was introduced to extreme programming from a friend, and while XP was more "extreme" a practice than what I was practicing, I couldn't be said to have been too far off myself. 19:49:29 --- join: asymptote (~weldon@bgp02689673bgs.flrdav01.dc.comcast.net) joined #forth 19:49:46 At the time I was introduced to XP, my tests were still co-resident inside functions as assertions, and required the software to be built as a "debug release." 19:49:57 This is bad, because it intrinsically changes the nature of the code. 19:50:23 In fact, the reason I was introduced to XP in the first place was a problem I was having, where the debug version of the code worked PERFECTLY, but the production build crashed every time. 19:50:25 I've been understanding everything you've been saying. I don't like debug releases either. 19:50:28 I couldn't figure out why. 19:50:44 I would rather have something external validate the code. 19:51:14 The TDD practice of maintaining unit tests eliminates that problem all-together. 19:51:14 And if forth, that is not hard. 19:51:26 Nope. Definitely not. 19:51:33 Develop tests firsts, then implement? 19:51:38 It does require a bit of thinking outside the box to properly structure the code, though. 19:51:42 Yes, always. 19:51:57 I refuse to use any other method except in extenuating circumstances. 19:53:10 Yes, I'm need to work away from being a MASH programmer. Always under the gun, always having to ship yesterday. 19:55:19 It's always been, "next project we will write the tests first". 19:55:30 Yeah. You just gotta sit down and just "do it." 19:55:38 Forth makes it hard, though, in a rather significant way. 19:55:50 Although imperative, Forth shares a *LOT* of functional language attributes. 19:55:58 One of them being the almost algebraic way you can think about code. 19:56:10 So you tend to write once, test once, and for most of the life of the program, the code "just works." 19:56:13 So you get lazy. 19:56:18 * kc5tja knows -- he's done it countless times. :D 19:56:58 However, I forced myself to use TDD this past couple of days in writing the PUBLIC: word implementation for FTS/Forth's cross compiler, and I spotted no less than four bugs *before* the first acceptance test was ever run this way. 19:57:07 It ended up saving me an estimated three days of debugging effort. 19:57:07 --- part: asymptote left #forth 19:57:13 (they all were hard to find bugs too!) 19:57:26 Which also raises the importance of running unit tests in a partially ordered manner. 19:57:41 The XP camp says, "Unit tests should be able to run in any order." Bullcrap. 19:57:47 do you just do unit testing, or do you do external interface testing as well? 19:58:23 The reality is, functions depend on other functions. If that is true, then those sub-functions must be unit tested *first* to ensure they are correct. Otherwise, how can you know for sure where a bug appears if the high-level test fails for some reason? 19:58:47 any order... well you don't want to run tests on high level code, before the low level has been proofed. 19:59:08 yes 19:59:22 das: I tend to just do unit testing. Since I partially order my unit test run order, my high-order tests tend to look more like, and behave like, acceptance tests rather than unit tests. 19:59:40 It's worked admirably well for the code I've written so far. However, I won't claim it's a perfect solution. 20:04:33 well, with the systems I work on, we need to do high level functional/operational tests as well. Those are the tests that customer wants to see. We also need to prove that interfaces are working according to specification we publish for the customer. 20:04:52 das: Those in XP are called "acceptance tests." 20:05:47 --- quit: mark_s ("Leaving") 20:06:14 In proper, commercial-grade XP, acceptance tests are mandatory. 20:06:42 I'll have to read some XP books. 20:06:54 * das is browsing http://www.extremeprogramming.org/ right now... 20:06:55 das: XP Installed is highly recommended. 20:08:56 By Ron Jeffries, Chet Hendrickson, and Ann Anderson? 20:09:01 yes. 20:09:35 It's short, to the point, and well written. 20:09:41 I wish all books could be so well written. 20:10:03 Forth Programmer's Handbook comes close to that style, but isn't intended to be a cover-to-cover read like XPI is 20:11:19 * das has not read Forth Programmers's Handbook cover to cover... It's too dry. 20:11:37 Exactly my point. :) 20:11:53 Lots of information, dense, but not designed to be *read*. XPI is. 20:11:53 There's another book that Forth Inc sells that's more enjoyable to read, and has exercises. 20:12:19 Forth Application Techniques I think. 20:13:38 I was thinking about getting it, but I figured I already know enough about coding in Forth that I didn't need the book. 20:13:57 I only got FPH because it makes a decent quick reference for some ANS Forth words that I tend to use often. 20:17:30 Well, I'm ordering Extreme Programming Installed right now. 20:17:47 You mean they don't have the pre-print PDF on their site anymore? 20:17:50 That sucks. :/ 20:18:15 Although the book is good to have around too. :) 20:18:23 Hmm... maybe they do... 20:18:44 I prefer a real book to a pdf. 20:18:49 Let me see if I have my PDF lying around. I could perhaps e-mail it to you. 20:18:52 Ahh 20:19:01 I just don't want you to order the book and then not like it, that's all. 20:19:32 I suppose you could always resell the book on Amazon.com or something. 20:20:19 There are several different books in the whole XP* series. XP Installed is the coder's book. There is a book for managers too. 20:20:23 I've not ordered it yet. 20:22:44 rrrrr 20:22:51 maybe I should just be happy that pearpc runs at all 20:25:36 pearpc-0.3.1 is a trip 20:25:40 the shift key doesn't work 20:26:01 it doesn't update the screen unless you obscure the window 20:26:07 (and then show it again 20:26:27 I had to hack it to get it to even compile 20:26:30 How in the world does it run MacOS X if it can't even use the shift key or update the screen? 20:26:50 beats the hell out of me 20:27:02 the debugger is practically worthless too 20:27:16 maybe they are endian bugs, and pearpc actually runs well on x86 20:27:26 maybe 20:27:34 Was it originally designed to run on x86? 20:27:40 yeah 20:27:45 Well, thanks kc5tja. I've got to get going, I'll be back in here tomorrow. 20:27:55 it has a JIT native compiler for x86 20:28:00 das: Laters. :) No problems. let me know what you think. 20:28:21 later all. Yes, kc5tja, I'll let you know. 20:28:34 Herkamire: Ahh, well, that would certainly do things good on the x86 side of things. :) 20:29:23 --- nick: das -> das-away 20:29:30 Hey, wow, I hadn't been severely reprimanded by my manager for reprimanding everyone else last night in my passdown. 20:29:39 version 0.2.0 does not have the above three issues for me 20:29:51 kc5tja: nice :) 20:29:58 kc5tja: you at work now? 20:30:03 Das ist guten -- it tells me I made the right decisions in handling the issue. 20:30:13 No, but I will off to work in about an hour. 20:30:18 In a half hour, I need to get ready. 20:30:35 you have time to install pearpc and try herkforth for me? 20:30:52 I want to know if the framebuffer stuff works there 20:31:00 I don't expect to get any coding effort in tonight though, since tonight is Monday night -- there'll be a lot of cases up on the board, and I'll need to get them done. It'll likely take me at least until 4AM to get them all done, and by that time, I'll be wiped. 20:31:14 Herkamire: Should I use 0.2.0 or 0.3.1? 20:31:40 kc5tja: I don't know. 20:32:15 I don't see anything on the changes list that would make much difference 20:32:38 maybe 0.2.0 would be better, as it's what I have. 20:32:54 or... what works for me. 20:33:28 I did manage to run the test with 0.3.1 with the same results 20:33:50 --- quit: jdrake ("Leaving") 20:34:03 Unpacking 0.3.0 now. 20:34:07 cool 20:34:08 0.3.1 rather 20:34:13 good :) 20:34:17 hah the cops are arresting one of my neighbours again 20:34:19 lol 20:36:54 I don't tihnk it'll compile. TONS and TONS of warnings. 20:37:49 Lots fo comparisons between signed and unsigned integers too! 20:37:51 Oh good lord. 20:37:56 This thing is segfault city! 20:38:05 which ? 20:39:36 Wow, it built! 20:39:40 * kc5tja is impressive. 20:39:42 :) 20:39:51 Herkamire: OK, where do I get your run-time image and .cfg file from? 20:39:53 kc5tja: you sure are impressive :) 20:40:08 http://herkamire.com/downloads/herkforth_pearpc_test.tar.bz2 20:40:17 instructions too :) 20:41:53 ppcconfig: '"' expected in line 15. 20:41:54 usage: ppc configfile 20:42:09 ppc ppcconfig 20:42:48 oh right 20:43:03 pearpc v0.3.1 has a different config file format. 20:43:13 GAHH! 20:43:14 :) 20:43:37 change I think all you have to do is set the start resolution to "800x600x32" (with the quotes) instead of the number. 20:44:08 OK, it booted. 20:44:12 nice 20:44:21 I don't know what I'm looking at though. 20:44:26 I'm also curious how long it takes to update the screen 20:44:51 Apparently, shift key doesn't work on 0.3.1 AT ALL -- I hit SHIFT-B, and nothing at all happens. I just get a lower-case 'b' at the bottom of the screen. 20:44:58 sc 20:45:04 huh 20:45:14 I guess 0.3.1 is totally borked 20:45:50 the changelog says "fixing some wrong/unimplemented keyboard mappings" 20:46:01 guess you'll have to do 0.2.0 20:46:06 hope you have time 20:46:13 What AM I looking at, anyway? 20:46:36 should be source code to get the address of the frame buffer 20:46:57 I shows fb-test's definition 20:47:11 But when I attempt to run it, it just says it's not compiled. 20:47:15 oh right, and fb-test to see if it worked 20:47:30 oh, this'll work 20:47:39 type ed-exec-cb and hit enter 20:47:56 (this is mapped to shift-B... but since shift doesn't work...) 20:48:38 above the def for fb-test there should be yellow words to get the frame buffer address 20:48:55 and a pink one with your cursor on it. (pink means set-constant) 20:49:15 below the astrisks is the value of the constant. 20:49:31 I just can't get used to this interface 20:49:32 :) 20:49:45 it's kinda crippled without shift 20:50:08 it's a little tough to adjust to typing enter after words not space. I may change that. 20:50:23 I have $84000000 20:50:25 space inserts into he editor 20:50:27 oh good 20:50:32 now run fb-test 20:50:38 (type fb-test then hit enter) 20:51:04 I get an endless loop of this error: JITC Warning: program exception: 00080000 00000000 20:51:08 brb 20:51:24 alright 20:52:52 that's so weird it doesn't work for you either 20:53:15 OK, I have to get ready for work now. 20:53:21 thanks so much for trying 20:53:40 oh, did you notice how long it took to redraw the screen after hitting enter? 20:55:09 ENTER from what? 20:55:16 From running ppc? 20:55:30 no, after typing words in herkforth 20:56:13 Takes about 2 seconds per refresh. 20:56:24 me too 20:56:51 bugger. I figured it'd be faster on x86. 20:57:02 I'm running the JIT too 20:57:13 it's not the emulation that's slow 20:57:45 I've since coded output buffering, and sent all the text for the screen update in one write() and it still takes two secconds. 20:58:05 is the terminal emulator that they wrote as part of pearpc that's so freakin slow 20:58:24 s/is/it is/ 20:59:00 So....you're not updating the screen directly? You're using OF's text output code? 20:59:08 yen 20:59:10 yes 20:59:16 I can't get access to the frame buffer! 20:59:40 What? Why not? That's just weird. 20:59:42 Oh well, I gotta go. 20:59:54 this test was to see if the frame buffer worked on x86 20:59:57 doesn't there either 21:00:06 it works fine when I boot it on my computer 21:00:34 I have the correct address. I know it's correct, because I checked the pearpc source code. 21:02:00 whatever. I guess I'll have to wait another year or two before I can give out a resonably usable herkforth demo with pearpc 21:19:06 --- quit: I440r (Read error: 110 (Connection timed out)) 21:34:35 Anyway, I have to get to work. I'll be back online in 30 minutes or so. 21:49:57 --- quit: Sonarman (Read error: 110 (Connection timed out)) 21:59:57 --- join: I440r (~mark4@216-110-82-59.gen.twtelecom.net) joined #forth 22:00:59 hi 22:01:01 I'm back 22:02:00 how would one write a test for a simulator for a 32-bit add function, which possibly takes a carry and supplies result, carry and overflow indications? 2s complement. 22:02:29 hrm 22:02:30 no idea 22:02:58 test adding something with 0, 1, 2, 15, 16, 65535, 65536, -1, -2, whatever, I don't know 22:03:01 :) 22:03:11 not a bad idea... 22:04:13 the only thing I came up with is to write a + type word that does the asm + and takes the carry in and pushes the overflow and carry out 23:24:25 --- nick: arke -> arke|zZzZ 23:34:05 --- quit: proteusguy ("The #python split is remarkably silly...") 23:41:10 jim: There is no point in doing an exhaustive test -- instead, test all the border cases. There are 32 bits which can produce a carry as a result, so there would be 32 tests to perform (e.g., $00000001 + $00000001, $00000002 + $00000002, $00000004 + $00000004, ... $40000000 + $40000000, $80000000 + $80000000). 23:41:21 Then repeat all these above tests again, but this time set the carry input. 23:44:15 ok... 23:46:01 by "carry as a result" you must mean at that bit position 23:48:39 Correct. 23:48:44 $40000000 + $40000000 should produce an overflow 23:48:46 And then, the carry out from bit 31 is the C flag. 23:48:52 Yes, it should. 23:49:07 Assuming your emulated hardware has support to detect overflow. 23:49:47 it's the arm7; it has an overflow bit 23:49:56 Ahh, I wasn't aware of that. 23:50:10 * kc5tja needs to learn more about the ARM. Maybe when I get a new design for the Kestrel down-pat. 23:50:33 you can look at my simulator :) 23:50:54 and there are docs available on the web 23:50:57 Sweet. 23:51:02 That will be very much appreciated too. 23:51:15 It is a real toss-up between the MIPS and the ARM, but the ARM comes in more easy-to-use packaging, I think. 23:52:19 I use arch for the version control, and it's publically available... if you use linux, arch is easy to install 23:53:40 the arm instruction set has about 15 different families of instructions; I've completed enough to get Ting's eforth's inner interpreter going. 23:54:58 as far as number of families, about 3 of the 15 are done so far. 23:56:04 cd 23:57:10 arch is good stuff. I personally use darcs now. I switched from arch because it was easier to use for my current coding requirements. 23:57:54 15 families of instructions?!?! Man, it's not quite as RISC as they say it is, now is it? 23:58:06 I'm hoping that at least half of those are the Thumb 16-bit instruction forms. 23:58:12 on the arm7TDMI flavor, there are actually two instruction sets, arm and thumb 23:58:32 one instruction, branch and exchange, switches to thumb. 23:58:34 jim: Even so, PowerPC has maybe 4 instruction forms. :) 23:59:06 --- join: mur_ (~mur@smtp.uiah.fi) joined #forth 23:59:56 lessee... there's branch/branch with link, single data transfer, data processing (those are the three families I have coded up so far), 23:59:59 --- log: ended forth/04.09.20