Back
[00:20:14] <a-l-p-h-a> robin_sz, will do!
[00:23:04] <robin_sz> :)
[00:23:18] <robin_sz> oh, and post jpegs ;)
[01:16:14] <skunkworks> I so want more than 3 axis...
http://www.youtube.com/watch?v=EdWWvnrFA9k
[01:18:52] <skunkworks> I wonder how a belt drive 4,5 axis would do - with like a 10 to 1 redution and the encoders mounted directly to the cradle/chuck
[01:19:10] <skunkworks> and bigass servos
[01:30:05] <skunkworks> no comment? come on now. work with me here.
[02:55:08] <CIA-6> 03jepler 07TRUNK * 10emc2/debian/ (configure control.in): with these changes, the emc2-sim package builds and runs on edgy
[02:55:10] <CIA-6> 03jepler 07TRUNK * 10emc2/src/ (configure configure.in): with these changes, the emc2-sim package builds and runs on edgy
[04:33:52] <a-l-p-h-a_> a-l-p-h-a_ is now known as a-l-p-h-a
[06:57:30] <a-l-p-h-a> wonder what anders is building here...
http://www.anderswallin.net/
[08:27:39] <CIA-6> 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/mesa_5i2x/5i20_vhdl/Makefile: modify VHDL build system - get rid of '---include' tags, use packages, and 'use' statements instead
[08:54:26] <K`zan> http://wrlabs.shacknet.nu/~vw/MyMachineShop/tmp/BigBolsterBar1/images.html
[11:04:06] <roltek> hi alex you in
[11:10:46] <anonimasu> :)
[11:18:54] <roltek> have to leave for work now talk t you later
[12:22:20] <rafa> hello
[12:23:15] <rafa> friends where are buton or function for single step?
[12:27:42] <rafa> ?
[12:27:42] <rafa> ^
[13:02:27] <Guest613> hilston i have problem!
[13:03:07] <anonimasu> ?
[13:05:26] <Guest613> emc no have buton single step mode
[13:09:14] <anonimasu> not that I know :&
[13:14:40] <cradek_> cradek_ is now known as cradek
[13:18:29] <cradek> Guest613: emc has single step - it works when paused
[13:26:26] <jepler> good morning all
[13:29:39] <pier> morning jepler
[13:34:08] <rayh> Hi guys
[13:39:04] <rayh> I've got a small problem with EMC's way of things.
[13:39:20] <rayh> There is one tool table.
[13:39:51] <rayh> I know some controls save tool data in comments right in the gcode file.
[13:40:22] <rayh> Some save it in a different section of the gcode file. Like after an end of program block.
[13:41:18] <rayh> I'd like to be able to save tool data so that when I call up a program I get the proper tool data for that program.
[13:41:33] <rayh> Any thoughts on how I might accomplish such a thing.
[13:44:16] <jepler> at best I'm *ahem* unfamiliar with how the big machines work, but I assumed that the commonly used tools were put in carosel slots and rarely moved--that's why specifying the slot number as the T- word was chosen
[13:44:48] <jepler> when you find that a tool has worn, or want to set the length of the tool, you change it in one central place (the tool table) and all g-code programs that refer to the correct T- numbers work properly
[13:45:53] <jepler> is the change you're proposing for shops like this with tool changers, or for a different situation?
[13:46:02] <rayh> Yep that is how some machining centers work.
[13:46:19] <rayh> It is for multiple tool jobs.
[13:46:39] <rayh> Job shops tend to make up tooling for each job
[13:47:16] <rayh> and put those tool into the carousel at the start of a part run.
[13:48:13] <rayh> Then when they load the part file they also load the tool table file.
[13:49:29] <jepler> if you want to add "tools in the ngc file" without modifying the core of emc, you could write code to scan the ngc file for special tool comments, create a modified tool table, and send the "reload tool table" NML message before running
[13:49:34] <jepler> i.e., modify the GUI
[13:52:34] <jepler> otherwise, I imagine you could add a new M-code which would take the relevant tool properties as additional words. E.g., for mill tools program M6.1 T- R- Z- to set the radius R- and length offset Z- for the tool to be loaded from slot T-
[13:53:51] <jepler> you'd also need to support lathe tools, which have 2 offsets, two angles, and an integer orientation number
[13:54:04] <jepler> hm the table has diameter, but R- is radius
[13:57:09] <jepler> oh good, D- can be used instead of R- (and is already to specify a diameter that does not come from the tool table forG41/G42)
[13:57:27] <jepler> you can also program a height offset with H- different from the one in the table
[13:57:43] <jepler> so maybe this is already solved: specify the slot with T-, the height with H- and the radius with R-
[13:58:05] <jepler> er
[13:58:12] <jepler> so maybe this is already solved: specify the slot with T-, the height with H- and the diameter with D-
[13:58:37] <jepler> but you have to specify it with the G-code that turns on the corresponding feature, length or shape compensation
[13:58:55] <rayh> phone brb
[14:03:33] <jepler> that's OK, I should be doing my real job
[14:03:50] <Guest613> hei mans
[14:04:20] <Guest613> what emc have single step?
[14:08:27] <Guest613> is hard work if not single step
[14:08:51] <cradek> I told you earlier that it has single step
[14:09:06] <Guest613> ?
[14:10:24] <cradek> yes, I said that step works after pausing
[14:10:33] <cradek> so try the pause and step buttons
[14:11:42] <Guest613> where step buttons?
[14:11:51] <Guest613> in Axis or other?
[14:12:03] <cradek> on the toolbar with all the other buttons
[14:12:20] <anonimasu> jepler: the heidenhain control I use has different tooltables for different jobs..
[14:12:34] <anonimasu> jepler: but you can also use a global tool table..
[14:13:57] <rayh> How do they name the tool tables so they match up to the program?
[14:14:22] <anonimasu> you name them something.t
[14:14:35] <Guest613> please friend, but in axis i don't see this boton, only boton pause
[14:14:53] <anonimasu> I think the same as your program name, but I'd have to check..
[14:15:25] <rayh> That is what I was thinking widget.ngc and widget.tbl.
[14:15:47] <Guest613> sory friend, but in axis i don't see this boton, only boton pause
[14:16:19] <anonimasu> rayh: im looking now
[14:16:25] <anonimasu> Guest613: it appears when you pause
[14:17:21] <anonimasu> you can both define tools in your program..
[14:17:22] <anonimasu> and in tool tables..
[14:18:55] <anonimasu> no, it looks like you have a single tool talbe..
[14:18:57] <anonimasu> table..
[14:19:08] <Guest613> ok
[14:19:14] <Guest613> thanks
[14:19:36] <Guest613> but one small problem:
[14:20:43] <Guest613> when press pause buton before a function G (for exemple G4 p.25) this no start
[14:24:24] <anonimasu> eh?
[14:24:34] <Guest613> yes
[14:24:35] <Guest613> when press pause buton before a function G (for exemple G4 p.25) this no start
[14:25:23] <Guest613> no restart process when before have function G4
[14:25:57] <rayh> thanks anonimasu
[14:26:00] <xemet> hi
[14:26:58] <anonimasu> rayh: np :)
[14:27:16] <anonimasu> actually it dosent clarify if you can have multiple tool tables..
[14:27:54] <anonimasu> bbiab
[14:32:23] <anonimasu> I dont even have a tool table
[14:32:26] <anonimasu> :D
[15:27:11] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=33843
[15:28:55] <cradek> that would be neat. you could hack something together with probing (and perverse gcode) but there's no good support for it
[15:40:59] <a-l-p-h-a> okay... can someone explain to me why I my recruiter would think I know perl, if I didn't have perl on my resume?
[15:42:40] <a-l-p-h-a> q1. if your spindle bearings aren't perfect; when the spins up, the dimension changes. q2. doesn't this require a relay on the machine spindle motor? Unless you want to cut up your touch probe. :)
[15:45:55] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/user_comps/hal_input.py: get rid of some 'unexpeted event' messages. Support "device subsets", so that you can get only the LEDs of your keyboard, not 200 pins for keys that you'll never use
[15:45:54] <CIA-6> 03jepler 07TRUNK * 10emc2/docs/man/man1/hal_input.1: get rid of some 'unexpeted event' messages. Support "device subsets", so that you can get only the LEDs of your keyboard, not 200 pins for keys that you'll never use
[15:48:30] <jepler> skunkworks: I think the squence would be somethinglike: G49; G53 Z<safe>; G53 G0 X<xhome> Y<yhome>; G53 G38.2 Z0; G43 H#5063
[15:49:05] <cradek> that's not how G43 works
[15:49:15] <jepler> it's not?
[15:49:21] <jepler> oh crap, it's an index
[15:49:29] <cradek> everything works from the tool table
[15:49:57] <jepler> I guess I wasn't reading very closely earlier
[15:50:01] <jepler> I gave ray wrong advice then too
[15:50:17] <jepler> not the first time I ever did that :-P
[15:50:26] <cradek> ray will know if your advice is bogus :-)
[15:50:38] <jepler> that's true
[15:50:39] <cradek> but this sure does fit in with what he was asking doesn't it
[15:57:01] <skunkworks> thanks guys. I might play with it.. closing the new house today bbl.
[15:57:20] <jepler> see you skunkworks
[16:09:57] <CIA-6> 03jmkasunich 07TRUNK * 10emc2/configs/stepper-xyza/standard_pinout.hal: move spindle from pin 9 (already used) to pin 1
[16:12:38] <CIA-6> 03jmkasunich 07v2_1_branch * 10emc2/configs/stepper-xyza/standard_pinout.hal: backport: move spindle from pin 9 (already used) to pin 1
[17:53:14] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc:
[17:53:14] <CIA-6> Allowing the number of backplot points to grow without bound means that
[17:53:14] <CIA-6> performance (framerate) becomes extremely low, and memory usage is unbounded.
[17:53:14] <CIA-6> Limit it to 100k points -- that's at least 16 minutes milling history, but
[17:53:14] <CIA-6> generally more. The number can be adjusted later based on user feedback
[18:40:39] <Guest702> Guest702 is now known as skunkworks_
[18:41:20] <skunkworks_> I am now the owner of 2 properites ;)
[18:41:31] <SWPLinux> bummer ;)
[18:41:59] <skunkworks_> well if all goes well - we sell the original one in april - not too bad
[18:42:08] <SWPLinux> oh - that's good then
[18:42:15] <SWPLinux> congrats
[18:42:19] <skunkworks_> Thanks
[18:45:46] <owad> Has anybody used the Powerline/Homeplug bridges? I'm thinking about using a pair to get ethernet to my emc system in the garage.
[18:46:06] <SWPLinux> good luck with a machine running :)
[18:46:10] <SWPLinux> (I/ve never used them)
[18:47:42] <owad> Good point about the interference. I've never used one either. Just looking for a convenient way to run the occasional update and transfer files.
[18:50:29] <skunkworks_> I have done it with a linksys router and a access point with good results
[18:51:27] <owad> The software says it requires Windows... It's just a plain old bridge, right?
[18:55:53] <skunkworks_> what software?
[18:57:10] <owad> The system requirements for the Powerline ethernet bridge. The specs claim the bridge requires Windows. My suspicion is that it's just an ordinary bridge and doesn't require any software at all.
[19:03:53] <jepler> owad: a bit of googling found this:
https://neon1.net/prog/plconfig.html -- I haven't digested it, but maybe it would be useful to you
[19:04:09] <jepler> "Now, about the only thing that has to be configured with these is the encryption password, so your neighbor won't be able to sniff your data. A Windows program is provided for that purpose - you hook up the bridge directly to your PC, enter a 2-24 character password, and the password is saved into the bridge's EEPROM."
[19:04:40] <jepler> sounds like even if this linux software didn't work for you, you could do a one-time configuration with a windows machine
[19:04:54] <owad> that'd work
[19:04:55] <owad> thanks
[19:13:22] <jepler> I could create the worst LAN ever by hooking one of these homeplug devices to a 10 megabit hub in my bsaement, and a wireless access point in the main floor of my house
[19:14:10] <owad> Don't forget a localtalk bridge. :-)
[19:24:32] <duerz> question=> Is the homming routine controled by the emc software or plc?
[19:25:27] <lerneaen_hydra> 'lo all
[19:25:46] <SWPLinux> emc
[19:26:09] <duerz> k - what about a b axis which needs to be unclamped first?
[19:26:26] <SWPLinux> but you can use a PLC if you want - there's a probe input that emc looks at to see when the probe touches
[19:26:39] <SWPLinux> that has nothing to do with probing, it's an axis motion thing
[19:28:17] <jepler> emc assumes it can command motion on any axis at any time, so an axis with a brake or clamp that takes time to disengage will be trouble
[19:28:51] <duerz> hmmm
[19:30:43] <duerz> but if you use the plc- how to you command motion?
[19:32:19] <SWPLinux> what is "the PLC"? are you talking about an external PLC or classicladder within EMC?
[19:32:37] <SWPLinux> and do you want to use one, or are you assuming that you must/must not do so?
[19:33:27] <duerz> classicladder?
[19:33:35] <Jymmmm> duerz: and... Do you want frys with that?
[19:33:57] <duerz> no-onion rings :)
[19:34:13] <jepler> duerz: emc produces an axis.N.position-cmd, it's up to you what to do with it
[19:34:14] <SWPLinux> classicladder is the software PLC that runs in realtime within the EMC system
[19:34:18] <Jymmmm> duerz: This aint Burger King, you can't have it your way! =)
[19:35:01] <alex_joni> Jymmmm: it's a diy :P
[19:35:15] <Jymmmm> lol
[19:38:50] <Jymmmm> SWPadnos Where you at biotch?!
[19:46:00] <CIA-6> 03jepler 07TRUNK * 10emc2/docs/src/config/emc2hal.lyx: note that feed-hold is only used when M53 P1 is set
[19:48:02] <SWPLinux> Jymmmm: Sunny Vermont
[19:48:11] <Jymmmm> ah, k
[19:51:15] <Jymmmm> * Jymmmm plan to take over the world is almost complete, just need 2 hand mixers and a small diet soda!
[20:23:46] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: a movement with an angular component must be flushed right away, because combining it with a subsequent linear-only move gives incorrect results
[20:24:40] <CIA-6> 03jepler 07v2_1_branch * 10emc2/src/emc/task/emccanon.cc: merge rev 1.79: a movement with an angular component must be flushed right away, because combining it with a subsequent linear-only move gives incorrect results
[20:25:53] <CIA-6> 03jepler 07v2_1_branch * 10emc2/debian/changelog: te bug that was fixed
[21:17:54] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix incremental mode comp move bug reported by ed nisley
[21:50:28] <skunkworks_> jepler:
http://www.cnczone.com/forums/showthread.php?p=268409#post268409
[21:57:17] <jepler> skunkworks_: hmm
[21:57:24] <jepler> skunkworks_: must be something wrong with the timing in the pluto firmware
[21:57:37] <jepler> it actually sounds like a problem chris and I saw but didn't figure out, which mysteriously went away
[21:57:59] <skunkworks_> oh ewww
[21:58:18] <cradek> I don't remember that one
[21:59:09] <jepler> cradek: very early on, we saw the encoder counts "go weird"
[21:59:47] <cradek> ok
[21:59:49] <jepler> when it does that near the wrapping point you end up jumping away by thousands
[21:59:52] <jepler> from where you should be
[22:00:09] <jepler> also, if the problem is "a byte gets dropped .. sometimes", then it would affect axis 3 much more severely than axis 1
[22:00:17] <cradek> I better get mine set up so we can actually test it
[22:00:23] <jepler> which explains why the spindle had trouble that disappeared when it was moved to encoder 0
[22:00:31] <cradek> oh...... hmm
[22:01:22] <jepler> what we thought were spurious index events were actually the counts shifted 8 bits
[22:01:41] <jepler> (aha says the driver -- the index value changed, there must have been an index pulse)
[22:02:00] <cradek> hmm, ouch
[22:02:38] <cradek> add another byte to the protocol to make room for a few bits to give the byte number?
[22:03:22] <cradek> or one bit for start of packet, and ignore a packet until you see the next one (and the previous one was the right number of bytes)?
[22:03:57] <cradek> I guess you were out of gates anyway.
[22:04:00] <cradek> ok bbl
[22:08:43] <SWPLinux> is gcc really smart or would it be better to replace the lines like this:
[22:08:44] <SWPLinux> din_00 = !!(ppdata & 0x1); din_00_not = !(ppdata & 0x1);
[22:08:46] <SWPLinux> with lines like this:
[22:08:47] <SWPLinux> din_00_not = !(ppdata & 0x1); din_00 = !din_00_not;
[22:28:10] <skunkworks_> jepler: do you want me to mention that you are working on it - or not say anything at this point?
[22:28:26] <skunkworks_> He has it hooked directly to the printer port.
[22:29:44] <skunkworks_> bbl - probably later tonight.
[22:36:19] <Jymmmm> Oh man... one panel left to skin (will do that tonight at work) YES!!!
[22:38:38] <SWPLinux> err -yay?
[22:39:13] <Jymmmm> Took me 5 days to skin the frames with al screen, and 5 days to skin the clear vinyl
[22:40:22] <Jymmmm> And almost mucked up and almost forgot to install the grounding straps before skinning with viynl
[22:42:38] <Jymmmm> Never would of imagined that making a dust proof enclosure would be so much work.
[22:43:56] <robin_sz> good evening?
[22:45:21] <Jymmmm> robin_sz something like that
[22:45:36] <robin_sz> you are making an enclosure for your routing machine?
[22:45:44] <Jymmmm> Yeah
[22:46:04] <robin_sz> nice and thick to keep the noise in?
[22:46:42] <jepler> skunkworks: I don't want to promise anything for now..
[22:46:45] <Jymmmm> Nah, just dust. 4' w x 4' h x 3' t
[22:47:02] <robin_sz> * robin_sz remembers what happened to his enclosure ....
[22:47:31] <Jymmmm> robin_sz ran into it with the forklift?
[22:47:41] <robin_sz> nah ... set it on fire
[22:47:44] <Jymmmm> how?
[22:47:54] <Jymmmm> two gallons of gasoline? =)
[22:47:57] <robin_sz> chips accumulated in a back corner
[22:48:14] <robin_sz> a deep plunge on the router rubbed the collet on the workpiece
[22:48:18] <robin_sz> it smoked ...
[22:48:26] <Jymmmm> ah, gotcha
[22:48:30] <robin_sz> a sparking bit of wood ... and ...
[22:49:07] <robin_sz> well, we would have spotted it sooner ... but it was inside this dustproof enclosure ...
[22:49:27] <Jymmmm> These are 2x2 frames, then skinned with al screen, then skinned with clear vinyl, so I can see everything.
[22:49:41] <robin_sz> we could see everything ...
[22:49:45] <Jymmmm> one panel is skinned with cnavas to let it all breath.
[22:49:51] <jepler> cradek: if there are extra or lost EPP transactions, it's simply a bug, and needs to be fixed
[22:49:52] <robin_sz> but we were in another room
[22:50:13] <Jymmmm> I have smoke alarm and fire ext within 6 feet =)
[22:50:56] <Jymmmm> I ususally clean up after each job anyway.
[22:51:16] <robin_sz> I think if I did it again ... I'd build a funnel underneth and a dust extractor from the base of it .. and some grid work around the edges of the router base. then arrnage for occasional compressed air balsts to move the chips off the edge, into the funnel
[22:51:56] <Jymmmm> That work, I just use the underside of the gorilla rack for storage and rather not have sawdust in everything.
[22:52:01] <robin_sz> we clean between each job too, but you can easily make a big pile of chips in a single cut
[22:52:26] <robin_sz> anyway .. ti survived
[22:52:54] <Jymmmm> Well, the base is 1" of MDF, I could always drill a 4" hole and attach shopvac if I do excessive chips
[22:53:24] <robin_sz> shopvac extraction around the cutter with a brush ring is agood too
[22:54:08] <Jymmmm> There's a point I can attach a vac to the head, and even hose already.
[22:54:15] <robin_sz> right
[22:54:16] <Jymmmm> ^have the
[22:54:30] <robin_sz> probably a very good idea .. keeps the much down
[22:54:31] <Jymmmm> 2 * 1.5" hoses
[22:54:32] <robin_sz> muck
[22:56:00] <jepler> SWPLinux: particularly since din_00_not is a macro that expands to a dereference of pointer to a volatile value, the code is fewer bytes as written, but I doubt the efficiency of that code is of much importance compared to the time spent in 'inb's
[22:56:17] <SWPLinux> true enough
[22:56:24] <SWPLinux> I hand't really considered the macro part of it either
[22:56:30] <SWPLinux> hadn't
[22:57:04] <jepler> to my surprise, if din_00 and din_00_not are just normal global variables, your code does generate fewer bytes of instructions
[23:02:52] <jepler> int tmp = (ppdata & 0x4) != 0;
[23:02:53] <jepler> din_00 = tmp; din_00_not = !tmp;
[23:03:06] <jepler> this generates the best code
[23:03:33] <SWPLinux> interesting
[23:03:44] <jepler> I am surprised that gcc can't see all these things are equivalent!
[23:03:47] <Jymmmm> robin_sz: Maybe one of these next time =)
http://www.westmarine.com/webapp/wcs/stores/servlet/product/10001/-1/10001/243814/10001/156/155/8
[23:04:16] <SWPLinux> tmp is highly local, so it's almost guaranteed to be a register. that does all the math on a register after a single memory access, and then does two accesses for storage
[23:04:46] <jepler> oh! in the first case, the compiler doesn't know that *din_00 doesn't alias ppdata
[23:05:02] <SWPLinux> I suppose not
[23:05:12] <SWPLinux> do output pins need to be declared volatile
[23:05:24] <SWPLinux> err - nevermind - the pointer is volatile, not the pointee
[23:05:27] <jepler> no, wait -- that can't be it, because the version with 'tmp' is faster even when there are no pointers
[23:05:51] <SWPLinux> is ppdata volatile?
[23:05:59] <jepler> no; here, it's a parameter to the test function
[23:06:07] <jepler> int din_00, din_00_not;
[23:06:13] <jepler> int k(int ppdata) {
[23:06:13] <jepler> int tmp = !!(ppdata & 0x4);
[23:06:13] <jepler> din_00 = tmp; din_00_not = !tmp;
[23:06:13] <jepler> }
[23:06:34] <jepler> gcc -fomit-frame-pointer -O3 -c test.c; nm -S test.o
[23:06:46] <jepler> the second column gives the size in bytes of the function
[23:06:53] <SWPLinux> is there a difference in code size with tmp=!(ppdata&0x4) vs the double !
[23:08:13] <jepler> I get one size for an even number of ! on tmp and another size for !!
[23:08:20] <SWPLinux> ok
[23:08:43] <SWPLinux> strange - it's the opposite of what I'd expect
[23:09:06] <SWPLinux> hmm - maybe not. it's a different constant load
[23:10:05] <SWPLinux> interesting. if you swap the "polarity" of the two assignments, the code size changes
[23:10:19] <jepler> it looks like it won't re-order the stores (whether or not there's a pointer)
[23:12:16] <SWPLinux> ok -other interesting facts: there's no code size difference for longs (64-bit numbers) on x86_64
[23:13:48] <SWPLinux> saving the value of !tmp first saves one byte of code
[23:17:55] <jepler> int l(int p) { int tmp = !(p & 0x4); din_00 = tmp; din_00_not = ~tmp; }
[23:18:06] <jepler> this is even a few bytes shorter
[23:18:17] <SWPLinux> ~ isn't the same thing though
[23:18:32] <jepler> oh oops
[23:18:57] <jepler> I was thinking about the "tmp is 0" case, not the "tmp is 1" case
[23:19:51] <SWPLinux> right
[23:21:19] <jepler> tmp ^ 1 then
[23:21:48] <SWPLinux> that should be about 4 bytes longer, I think
[23:22:21] <jepler> int l(int p) { int tmp = !(p & 0x4); din_00 = tmp; din_00_not = tmp ^ 1; }
[23:22:21] <jepler> int m(int p) { int tmp = !(p & 0x4); din_00 = tmp; din_00_not = !tmp; }
[23:22:26] <jepler> 0000006e 00000017 T l
[23:22:26] <jepler> 00000085 0000001c T m
[23:22:40] <SWPLinux> strange
[23:23:12] <jepler> testl / sete / movzbl (!) vs xorl / movl (^1)
[23:23:23] <SWPLinux> this is interesting also:
[23:23:25] <SWPLinux> this code: int tmp = !!(ppdata & 0x4);
[23:23:28] <SWPLinux> generates this assembly:
[23:23:29] <SWPLinux> shrl $2, %edi
[23:23:31] <SWPLinux> andl $1, %edi
[23:23:32] <SWPLinux> sete %al
[23:24:33] <jepler> this one's 0x14 bytes: int l(int p) { int tmp = !!(p & 0x4); din_00_not = tmp; din_00 = tmp ^ 1; }
[23:25:03] <SWPLinux> interesting
[23:25:37] <jepler> I bet we've trimmed 1ns from the runtime of each of those by now
[23:26:15] <SWPLinux> it's ox16 long for me
[23:26:16] <SWPLinux> 0x16
[23:26:20] <SWPLinux> that much?
[23:26:35] <jepler> yeah I get 0x16 with -m64
[23:26:40] <SWPLinux> ah
[23:27:06] <jepler> for -m32 I tacked on -mregparm=1 which is closer to the real program since ppdata is a variable computed locally
[23:27:24] <jepler> (ppdata starts in %eax)
[23:27:36] <SWPLinux> O3 should do register params, shoudln't it?
[23:27:48] <jepler> no, it changes the ABI and these functions have external linkage
[23:27:53] <SWPLinux> ah
[23:29:06] <SWPLinux> I still get 0x16 here
[23:29:24] <jepler> /usr/bin/gcc -m32 -fomit-frame-pointer -O3
[23:29:25] <SWPLinux> ah - unless I use -m32 instead of -m64
[23:29:52] <jepler> the 64-bit ABI *does* have parameters passed in registers by default, -mregparm doesn't imprve anything there
[23:31:46] <jepler> bbl, time to start on dinner
[23:31:53] <SWPLinux> enjoy
[23:49:45] <jmkasunich> sheesh.... counting clocks?
[23:49:53] <jmkasunich> * jmkasunich goes away again
[23:50:05] <jmkasunich> back in 4 hours or so, unless I get smart and just go to sleep
[23:51:43] <SWPadnos> ok -see you
[23:55:22] <rayh> I need a dozen or so .ngc files that you've run successfully under EMC2.
[23:56:05] <SWPadnos> define "successfully"
[23:56:14] <SWPadnos> I have several that I've simulated, I think
[23:56:21] <SWPadnos> but I've never run any on actual iron
[23:57:59] <SWPadnos> oh, and they don't have "niggly bits" in them, like tool changes and that kind of thing
[23:58:12] <rayh> No problem. Send em on.
[23:58:32] <rayh> ray __ up __ net. you know how to fill that in.
[23:58:49] <SWPadnos> yep. I may send a disc - one file is multiple megabytes
[23:58:49] <rayh> If you tar em they might be more likely to get here.
[23:59:06] <rayh> Okay. email the small ones.
[23:59:28] <SWPLinux> yep -21 meg for one of them
[23:59:28] <rayh> That way I can get a jump on testing with synergy.
[23:59:33] <SWPLinux> ah
[23:59:45] <SWPLinux> I have the one I made for the turbocad review
[23:59:50] <SWPLinux> that's pretty small
[23:59:57] <rayh> Great.