00:00:00 --- log: started forth/00.12.06 02:08:49 --- join: MrReach (mrreach@209.181.43.190) joined #forth 02:09:01 something about break on carry? 02:09:03 u understand the question MrReach? 02:09:04 yes 02:09:15 not really ... can you rephrase? 02:09:17 lets say ive set a breakpoint to break on any write to the special function register 02:09:38 WARNING: I've been drinking screwdrivers all night, so probably not at my best cognition 02:09:39 the clear carry instruciton or ANY other instruction that affects the carry should cause a break 02:09:41 BUT 02:09:48 what if im clearing an already clear carry 02:09:53 should i break ? 02:10:20 like if i do an add instruction that doesnt generate a carry it will clear the carry 02:10:30 but if the carry is already clear should i break 02:10:46 you're not going to like my answer 02:10:57 would the microcontroler write a zero to an already cleared carry 02:11:34 would you like to hear it anyway? 02:11:37 eys 02:11:39 yes 02:12:00 ok, lemme paraphrase your question to make sure I understand it ... 02:12:01 if ive got a breakpoint of this type set 02:12:20 you have breakpoints on changes in the status register ... 02:12:22 then an addition or a subtraction will ALWAYS cause a break 02:12:25 and your wondering ... 02:12:27 yes 02:12:33 is a no change still a change 02:12:50 it would have changed if it wasnt already set to where it would change to 02:12:55 that if an instruction _could_ change a bit, but doesn't, whether it should cause a break, right? 02:12:55 should i break 02:13:03 add is guaranteed to either set or clear the carry 02:13:20 you have breakpoints on changes in the status register ... 02:13:21 and your wondering ... 02:13:22 that if an instruction _could_ change a bit, but doesn't, whether it should cause a break, right? 02:13:24 should the add instructoin always break if i have a write break on the sfr ? 02:13:34 yes 02:13:35 what is the sfr? 02:13:41 status register? 02:13:51 special function registers 02:13:55 the psw is an sfr 02:14:01 i meant psw 02:14:21 ok, can it be written to aside from instructions that alter it as a side-efect of their operation? 02:14:35 yes 02:14:43 add will always have an affect on the carry bit 02:14:55 if no carry is generated the carry is cleared 02:15:04 what if the add sets an already set carry 02:15:07 * MrReach slurps his Vodka, "OK ..." 02:15:10 what if it clears an already cleared carry 02:15:17 hehe vodka ??? 02:15:20 yukk 02:15:24 puh puh 02:15:28 heh 02:15:30 screwdriver = vodka + orange juice 02:15:39 have you been reading what I've been typing? 02:15:40 yea i know... 02:15:47 anyway ... 02:16:03 i can write to the psw any value i want 02:16:10 move psw,0 shud work 02:16:17 because the psw has a direct address 02:16:26 i just write to that address 02:16:30 *IF* the instruction to specifically read from or write to the status register is execuated, you MIGHT want that to cause a break 02:16:53 if i have a break on psw write 02:17:02 and the clear carry instruciton is executed 02:17:05 however, to cause a break where a bit (or any bit) is changed seems of limited utility to me 02:17:06 it SHOULD break 02:17:13 even if its clearing an already clear carry 02:17:19 no 02:17:30 im not going down to the bit level 02:17:32 for example ... 02:17:33 just psw 02:17:42 im just using carry as an example 02:18:02 when was the last time you wished that a status bit was not set right, and you wanted to see each time it changed? 02:18:28 that would driver the coder nutz (and prob the debugger, too) 02:18:31 erm im thinking more along the lines of if THIS memory address changes then break 02:18:46 and im thinking about what would happen if the memory address specified is the psw 02:18:54 right, if you consider the status reg a memory location ... 02:19:13 it is 02:19:13 then it should break ONLY when it is read from or written to 02:19:29 but ADD always has an effect on carry 02:19:33 ALWAYS 02:19:43 unless the effect is to change it to what it already is 02:19:46 carry is clear 02:19:54 otherwise, it should be considred an I/O port that seems to automagically change with program execution 02:19:54 you do an add of zero to somewhere 02:20:00 the add would normally clear carry 02:20:04 should i break 02:20:35 I would say "no" 02:20:44 since you seem to require a yes/no answer 02:20:45 its a delema 02:20:52 i should ONLY break if it actually changes 02:20:53 ok 02:21:01 then part of my code needs to be changed 02:21:02 ok, to use your example of carry 02:21:32 see ADD will specifically write either a zero or a 1 to carry depending on weather a carry was generated 02:21:32 *IF* the coder set a watch on a change (or potential change) of the carry bit ... 02:21:41 thats the problem 02:21:57 psw didnt change but would have if it wasnt already there 02:21:59 the breakpoint would be activated in bazzillions of different places 02:22:05 yea 02:22:15 the coder doesn't WANT that 02:22:20 actually almost any change on the a register will cause a change in the psw 02:22:36 in fact 50% of the time the a reg chages psw changes too hehe 02:22:44 there is a parity bit in the psw 02:22:59 there is a distction betwen which reg and the psw? 02:23:06 so should a write to the a register cause a break on psw ? 02:23:20 psw is a special function register 02:23:40 I know that if you break on changes to status bits, you're not going to get anywhere fast ... so better not to do that 02:23:58 psw changes the modes of the MPU? 02:24:12 im not going to disallow the setting of a breakpoint on the address of the psw within the sfr 02:24:24 agreed 02:24:32 and if the user sets that breakpoint tehre are HUNDREDS of places i need to test for a change 02:24:49 which means that my breakpoint code has to be psw aware 02:24:55 if you write/read the register EXplicitly, like a memory address, then it should be breakable 02:25:00 if add doesnt change the carry it shouldnt break 02:25:18 and i also want to break BEFORE the instruction executes 02:25:21 even if add *DOES* set the carry, then it should break 02:25:26 break at the instruction that will cause the change 02:25:33 sorry, WRONG 02:25:37 even if add *DOES* set the carry, then it should NOT break 02:25:40 if it sets an already set carry it shouldnt 02:25:55 if the user has set a break on psw change 02:25:56 even if add *DOES* toggle the carry, then it should NOT break 02:26:07 and an add executes and it affects the carry i think i should break 02:26:15 but if it doesnt change it it should not break 02:26:15 ok, then why ask me? 02:26:27 im saying thats what i think 02:26:30 ok 02:26:34 i wanted your rational 02:26:50 ok, it depends on what, exactly, psw is 02:27:17 if it's the status register that is changed as the side-effect of machine instructions ... 02:27:22 program status word 02:27:23 carry 02:27:25 auxillary carry 02:27:28 overlfow 02:27:29 then it should NOT break 02:27:30 parity 02:27:35 y 02:27:52 because many portions of the prog will change it 02:27:59 yes 02:28:03 actually 02:28:10 in a complex prog, it will _seem_ random 02:28:13 most instructions have NO affect on psw 02:28:15 that is useless info 02:28:29 read what i just said 02:28:50 the only instructions that affect the psw are add subb addc div ab and mul ab 02:28:50 ok, does add (for instance) change the psw sometimes? 02:28:57 always 02:29:03 ok, in that case ... 02:29:05 unless it changes it to what its already set to 02:29:22 there are BAZZILLIONs of place where it will be changed by an ADD 02:29:23 and any operation on the a register has the potential of affecing the parity bit 02:29:31 yes 02:29:49 so having break on a change is a useless function 02:29:52 what if the user wants to see what happens when the carry is set after an add instruction 02:29:59 because noone will really want to know 02:30:10 i just cant see changing the rules specifically for psw tho 02:30:17 ok ... that's a different story altogether 02:30:34 but a breakpoint on that is not really the proper solution 02:30:56 no 02:30:57 instead, put a breakpoint in the specific ADD that you want to examine 02:31:54 but if the user sets a break on the address of psw then any change should cause a break 02:31:54 and then watch the status bits change as you single-step 02:31:54 which would prolly be operator error 02:31:54 i would never set a break on the psw 02:31:54 yes, 9 times out of ten, it will break in a place the user is not interested in 02:32:01 but just because i dont see a practical use for it..... 02:32:25 it's a bunch of effort, put it off until someone actually asks for it. 02:33:01 you might actually end up coaching the user how to properly use a single-step debugger 02:33:39 hehe 02:33:39 now, if it were changing some fundamental mode of MPU operation, THEN I could see putting a break on it 02:33:40 im always of the opinion that you should give the user enough rope to hang himself with 02:33:48 like switching a '386 from real to vertual mode 02:33:55 that way he will have enough to pull himself out of a hole if he needs it heh 02:34:16 put on your list of to-do, but don't make it at all important 02:34:30 and certainly don't make it a require for first-release 02:34:41 thers another solution 02:35:07 disallow breakpoints on the address of the psw but have special breakpoints on each bit therein 02:35:19 i.e. allow break on change of psw.7 02:35:21 which is carry 02:35:32 or psw.1 which is parity <-- stupid realy heh 02:35:41 MOST instructions wont affect carry 02:35:49 if you wish, but I think your efforts, at least in the beginning, would be better spent elsewhere 02:35:53 but there could be a use for breaking on that 02:36:13 im at the point where i need to decide how im going to handle this 02:36:13 heh, you not really getting it ... 02:36:21 pretend I'm a coder .. 02:36:27 i either write code to make psw a non breakable address 02:36:32 and I wrote this super-duper routine 02:36:34 or add code to cover breaking on it 02:36:58 but it don't work, and after carefully rereading the source, I can't see why 02:37:39 so I single step through it, but I'm *NOT* interested in whenever the carry bit changes, I'm only interested in ... 02:37:51 *MY* broken routine changes it 02:38:33 you have a real-time display of the current status bits, right? 02:38:54 like the A86 debugger? 02:38:55 yes 02:39:12 ok, that is what the user NEEDs to see why his code isn't working 02:39:39 now, you *MIGHT* find some really wierd user that needs to break on carry re/set 02:39:45 (like Chuck Moore) 02:39:54 hehe 02:39:57 exactly 02:40:07 but the likelihood of such a user is VERY remote 02:40:10 someone smarter than just about everyone else combined :P 02:40:14 yes 02:40:41 ok, so the cost of dimishing return says to ignore it until someone specifically asks for it 02:40:52 not worth the effort 02:41:39 I _could_ fly a helicoptor every time I need to go to the grocery store, but ... 02:42:28 now taht would be fun :))) 02:42:39 the cost of the 'copter, the time in licensing, routine maintenance, hell even the brearing wear in simply starting the thing up, dictates that I use a car like everyone else 02:45:01 have you ever used a wiki? 02:45:05 wiki ? 02:45:16 as in WikiWikiWeb? 02:45:41 never heared of it 02:46:46 want to do a bit of exploring? try http://c2.com/cgi/wiki 02:47:00 it allows anyone to edit any webpage 02:47:32 it would allow you to edit my web page ? 02:47:40 or anyone to edit any wiki web page 02:47:58 no, to edit any wiki page 02:48:02 hhe 02:48:03 you read a page ... 02:48:04 phew :P 02:48:16 at the bottom there is an "edit" link 02:48:28 it brings up a form with the raw source in it 02:48:44 most wikis understand a very primitive markup 02:49:40 :) 02:50:13 wanted your thoughts on what the most easily grasped and most efficient markup might be 02:50:41 erm 02:50:48 i hardly even know html hehe 02:50:58 ok 03:02:37 my vision is getting blurry, which means it's time to go to bed 03:02:44 good night to you. 03:03:35 --- quit: MrReach () 11:26:34 --- quit: ult (Hey! Where'd my controlling terminal go?) 15:59:00 --- join: tcn (Tom@207.198.30.104) joined #forth 15:59:00 --- mode: ChanServ set mode: +o tcn 17:04:06 tcn!!! 17:04:08 hi dood 17:04:20 hey 17:04:29 what up? 17:04:37 not much 17:04:47 my simulator is goming along now :) 17:04:59 im adding break on read of address and break on write of address 17:05:28 heh.. that's cheating :) 17:05:32 which is more complicated than it sounds but only because it raises some interesting questions :) 17:05:47 what if some memory address is getting mashed on 17:05:56 u can set a breakpoint on writes to taht address 17:05:59 run at full speed 17:06:08 and STOP rite where it gets mashed on 17:06:13 hehe 17:06:15 --- mode: I440r set mode: +o aaronl 17:07:00 gawd its cold.. 17:07:04 its actually snowing here hehe 17:07:12 where are you again? 17:07:15 not that its REAL snoe 17:07:18 lafayette indiana 17:07:26 its hardly snowing at all 17:07:35 then i'll get it in a day or two 17:07:36 less than 1/1892746592783402384916524936785 of an inch :P 17:07:50 christ. it's already below 20 17:07:50 but its making the locals paranoid ehhe 17:07:53 oh no!!!!!!!!!1 17:08:00 oh no!!!!!!!!!!1 SNOW!!!!!!!!!!!!! 17:08:06 P A N I C !!!!!!!!!!!!!!! 17:08:10 heh 17:08:32 oh yeah, i've experienced that once when I was in Carolina in january 17:08:50 u were in carolina during that ice storm they had ? 17:08:54 where in carolina ? 17:08:58 i was in charlotte then!!!! 17:09:00 nah, just a little snow 17:09:35 but they closed everything.. ahha.. people were driving 15 mph, the few who were brave enough.. we went 50 or 60 like usual :) 17:10:59 yea 17:11:00 i know 17:11:00 it was realy realy realy bad..... 17:11:00 a whole inch of snow!!!! 17:11:00 hehe 17:12:06 so what was this ice storm? 17:12:15 a little sleet? 17:12:43 no they had ice all over the trees 17:12:56 not realy an ice storm but powr lines came down 17:13:13 and ppl were without power for ages beccause the state isnt prepared for this sort of weather 17:13:59 hi 17:14:16 hey aaron 17:18:07 tcn do you code 8051 at all ? 17:18:17 ill need someone to beta test my sim soon 17:19:35 nope.. never touched one.. you want someone who has.. 17:19:59 isn't there a Camel Forth for the 8051? you could try that 17:24:01 no thanx 17:24:18 ive got an 8051 forth here 17:24:22 and im writing my own :) 17:25:30 heh.. camel forth is slooooooooooooowwwwwwwwwwww 17:25:30 it sux 17:25:30 subroutine threaded isnt it ? 17:25:30 i forget 17:25:30 it varies 17:26:01 but I know it uses linear searches 17:26:30 so will my compiler 17:26:35 dont care about hashing 17:26:40 that only affects compile time 17:26:52 my execution time will be fair.,.. 17:26:54 not FASTTTTTTTTTTTT 17:26:56 on a fast PC it's fine 17:27:06 because ive heavilly optimized it for size 17:27:25 whoile kernel and possibly assembler too within the 3k of internal rom 18:03:27 --- nick: aaronl -> | 18:03:58 --- nick: | -> aaronl 18:16:57 --- join: TheBlueWizard (TheBlueWiz@216.25.203.23) joined #forth 18:16:57 --- mode: ChanServ set mode: +o TheBlueWizard 18:17:00 hiya all 18:17:13 tbw :) 18:17:25 hiya I440r :) 18:17:49 :) 18:20:13 whassup dude? 18:20:52 not much 18:21:02 :) 18:21:09 sorry for delay, needed a coffee refill :) 18:21:10 hehe 18:21:13 and a cookie :P~ 18:21:21 hehe 18:21:51 slerp/munch! 18:21:56 or do i mean munch/slerp 18:21:57 hehe 18:22:05 i can never decide :P 18:22:55 lol 18:23:06 the big questions in life.... 18:23:06 hehe 18:24:12 * TheBlueWizard nods oh so solemnly hehe 18:24:18 hehehe 18:24:48 makes questions like "will al gore ever wake up and smell the coffe" pail in comparison :P 18:26:07 hehe 18:26:29 :P 18:26:48 basically because gore is too stupid to realise its breakfast time already :P 18:26:58 he is still trying to sneek a midnight snack :P 18:27:01 I still remember you still rant against Gore lol 18:27:14 ALWAYS 18:27:28 * TheBlueWizard doesn't care for either Gore or Bush 18:27:55 i dont trust gore as far as an ant could throw him 18:28:01 bush i trust 18:28:20 --- join: hcf (nef@207-172-225-229.s229.tnt1.pld.me.dialup.rcn.com) joined #forth 18:28:21 I don't trust either 18:28:46 :) 18:28:58 well ur a north of the border neway :P 18:28:59 hehe 18:29:25 I'm surprised that you're so willingto trust Bush....he just doesn't have any oomph in him 18:29:40 I'm an American! 18:29:45 and gore does ? 18:29:47 u r ? 18:29:51 oh hehe 18:30:08 i phorget thingz u know... 18:30:12 its old age... 18:30:26 lol 18:30:37 hiya hcf 18:30:45 --- mode: I440r set mode: +o hcf 18:30:46 hi dood 18:30:50 hcf(12,28) = 4 :) 18:31:00 ???? 18:31:02 hi, heh 18:31:15 hcf == highest common factor 18:31:19 aha 18:31:20 hehe 18:31:22 aka gcd 18:31:54 anyone in here know of a test for divisible by 3 ??? 18:31:58 also, health care foundation, halt and catch fire, and numerous others 18:32:08 i like that last one... 18:32:15 ive seen some controlers do that 18:32:36 yes....similar to test for divisibility by 9 18:32:49 but in binary format? dunno.... 18:32:52 if its divisible by 9 its divisible by 3 18:33:03 yea i was wondering if it could be done easilly in binary :) 18:33:20 split it up into 2 bit chunks ? 18:33:24 and add them up ? 18:33:52 lets test that 11010011 18:33:54 example: 243 is divisible by 3....2+4+3 = 9, which is divisible by 3 18:34:04 digit sum 18:34:05 div 3 ; or edx,edx ; jz... 18:34:07 won't work for binary, I think 18:34:25 split it up into 2 bit digits 18:34:55 "FITS, an attempt to implement ITS using FORTH"--http://vip.hex.net/~cbbrowne/compobscure.html 18:34:56 ill haft work this out, see if it works hehe 18:35:05 whats its ? 18:35:06 anyone know of FITS? hi tcn any clue? 18:35:16 hcf: heh.. that guy just email me last week :) 18:35:17 I440r: ask tcn about ITS 18:35:24 odd 18:35:26 tcn what is its :) 18:35:38 its ITS not its 18:35:39 ;) 18:35:41 an old asm-based OS at MIT 18:35:48 aha 18:35:48 real old 18:35:51 sounds interesting :) 18:35:59 60's-80's 18:36:07 the reason why the divisibility by 3 works is that the x^n-1 is divisible by x-1, and let x=10....hence this method works...the proof for 3 is a bit more involved.....now, x=4...x-1 = 3....maybe works! 18:36:14 pretty long lifespan for an OS 18:36:45 tcn: so whats up w/ fits? 18:37:31 hcf: unfinished but there's talk of reviving it.. 18:39:20 any links? 18:39:28 who's involved 18:39:43 flori DUH!!!!!!!!!!!! 18:39:47 ok, it's.. http://www.lysator.liu.se/~mc/oldhacks.html 18:39:50 i heard someone say taht to day hehehe 18:39:53 11010011 --> 11 + 01 + 00 + 11 --> 11 + 100 --> 111 --> 1 + 11 --> 00...so 11010011 would be divisible by 3...but it doesn't work...hmm...time to work more on math proof stuff :) 18:40:34 try with 3 bits hehe 18:40:41 what's the smallest power of 2 that's divisible by 3? 18:40:49 6 18:41:02 tcn: thx 4 the nfo 18:41:05 2 4 6 8 16 ... 18:41:12 I mean, no 6 ;) 18:41:20 unless ur working with negative numbers :) 18:41:27 in that case its infinity :) 18:41:42 tcn: there is no pwers of 2 that is divisible by 3.... 18:41:59 tbw yes there is 18:42:10 2 to the power of 3 is divisible by 3 18:42:44 no it's not 18:43:52 * TheBlueWizard bonks I440r...2^3 == 8....8 is NOT divisible by 3 18:43:52 oh oopts 18:43:52 hehe 18:43:52 duh 18:43:52 get some sleep dude ;) 18:43:52 hehe 18:43:52