Back
[02:19:24] <jepler> jmkasunich: do you have any notes from the time when you were determining that 'doubles' were not stored or read atomically? my experimentation on modern systems (Pentium-M, Pentium 4, AMD Athlon) indicates that the floating-point load/store (fldl / fstl) and 64-bit integer load/store using the fpu (fildq / fistq) *are* atomic, though you have to use gcc __asm__ macros to ensure that only those instructions are used and not any other alternatives
[02:19:43] <jepler> jmkasunich: I suspect this is true for any pentium-or-later CPU; they have 64-bit data buses
[02:20:02] <jmkasunich> no notes or anything
[02:20:40] <jmkasunich> I do know that I wasn't doing any magic, so it might have been transferring the data using ordinary moves
[02:20:42] <jepler> the problem with this bright idea of mine is that every load or store of what would be hal_double, hal_s64, or hal_u64 would have to use these macros instead of "=".
[02:21:06] <jmkasunich> s64 and u64?
[02:21:16] <jepler> I know that occasionally gcc will do a floating-point stores with two 32-bit 'movl's, and will always do 64-bit integer stores that way.
[02:21:24] <jepler> yes, wider integral types
[02:21:37] <jmkasunich> what needs a 64 bit integer?
[02:23:33] <jepler> admittedly, wider integral types are less compelling than 'double' is
[02:23:35] <SWPadnos> big fixed point values
[02:23:42] <SWPadnos> like a 32.24 stepgen or something
[02:23:53] <SWPadnos> or 16.24 or 24.16 for that matter (> 32)
[02:23:57] <jmkasunich> thats internal to the stepgen
[02:24:04] <jepler> but e.g., a 16-bit resolver would otherwise overflow at around 32k revolutions
[02:24:06] <SWPadnos> true
[02:24:21] <jmkasunich> you sure don't want to be passing fixed point stuff around between hal comps, that would be a nightmare
[02:24:22] <jepler> it's true that these macros would also make for easier transfer within a component; stepgen could use it
[02:25:04] <jmkasunich> another detail - currently comps that use only integers can be used in threads that don't support FP
[02:25:07] <SWPadnos> I don't see an FSTL or FLDL instruction in my ia32 reference book
[02:25:27] <jepler> those are gas mnemonics
[02:25:30] <SWPadnos> ok
[02:26:06] <jepler> I think the intel mnemonics are fld/fst mem64 (and fstp), and fild / fist / fistp mem64
[02:26:15] <jepler> ("p" alsp pops from the register stack)
[02:26:16] <SWPadnos> ok - I see those
[02:26:29] <jepler> http://emergent.unpy.net/files/sandbox/atomic64.h
[02:26:31] <SWPadnos> I didn't see any clock cycle listing or mentions of atomicity
[02:29:02] <jepler> SWPadnos: I agree; I haven't found anything in datasheets that explicitly says that these instructions are not interruptible after only part of the data has been transferred
[02:39:52] <jepler> aha --
http://download.intel.com/design/processor/manuals/253668.pdf pdf page 279, aka page 7-3
[02:40:12] <jepler> reading or writing a quadword aligned on a 64-bit boundary is guaranteed atomic
[02:40:45] <SWPadnos> what's the title of that manual?
[02:41:06] <SWPadnos> oh, volume 3a
[02:41:35] <jepler> Intel® 64 and IA-32 Architectures
[02:41:35] <jepler> Software Developer's Manual
[02:41:35] <jepler> Volume 3A:
[02:41:36] <jepler> System Programming Guide, Part 1
[02:42:36] <SWPadnos> hmmm
[02:42:41] <jepler> it would completely suck to try to change emc from floats to doubles piecemeal, and it would also completely suck to have to change it all at once to use these macros
[02:43:38] <jmkasunich> the HAL float type would have to change in one fell swoop
[02:44:06] <jmkasunich> and I'd rather not even rename it - the signals and pins would still be "float" to the users, only the internals would change
[02:44:10] <jepler> it would be easy to change the typedef, but if anything of the form 'x = y' has to change ...
[02:44:18] <SWPadnos> well, as long as everyone is using hal_float, that's a single typedef :)
[02:44:42] <SWPadnos> that page is just about identical to the one in my printed ia32 manual
[02:45:02] <fenn> how about: if you need 64 bit ints, use a 64 bit computer
[02:45:04] <SWPadnos> but it's actually less confusing in the one you linked
[02:45:19] <SWPadnos> I wouldn't change ints, I'd add s64
[02:45:21] <jepler> if x is a 64-bit hal_float and y is a value computed locally, under my proposal you'd have to write ATOMIC_DOUBLE_STORE(x, y)
[02:45:29] <jepler> ;
[02:45:30] <jepler> not x=y;
[02:45:45] <jepler> it doesn't matter how "easy" it is to change the typedef
[02:46:02] <jepler> now, if only our modules were in C++; in that case, the classes a little further down atomic64.h actually make this transparent; you can still write 'x=y;'
[02:46:58] <SWPadnos> hmmm. I guess pages are always quadword aligned
[02:47:11] <SWPadnos> so as long as the offset is also, that should be fine
[02:47:39] <jepler> yeah, I don't think that meeting the alignment requirement is hard, but it might sometimes increase hal shared memory area usage by 150% compared to just having 32-bit floats
[02:47:56] <jepler> (4 bytes padding plus 8 bytes data, instead of 0 bytes padding plus 4 bytes data)
[02:48:24] <SWPadnos> I don't think so actually - a halpin/param is a struct that contains a lot more than just the value
[02:51:04] <jmkasunich> pins are pointers, they won't change at all
[02:51:17] <jmkasunich> pins contain a dummy data element, that will get bigger
[02:51:25] <jmkasunich> params contain data, that will get bigger
[02:51:32] <jmkasunich> sigs contain data too
[02:52:04] <jmkasunich> but in all cases, the struct is much larger than 8 bytes - the name is part of it
[02:52:07] <SWPadnos> among other things, was my point
[02:52:09] <SWPadnos> yep
[02:52:16] <jmkasunich> s a few more bytes of padding isn't horrible
[02:52:27] <jmkasunich> so
[02:52:54] <jmkasunich> as jepler says, its the math operations that will suck
[02:53:12] <jepler> it really kills the proposal IMO
[02:53:46] <jmkasunich> instead of ATOMIC_DOUBLE_STORE(foo, bar), I'd be inclined to write hal_pin_get(pin), and hal_pin_set(pin, value)
[02:54:02] <jepler> those sure would be useful wrappers
[02:54:38] <jepler> the other thing to do, as I've blogged before, is to enlarge hal_float to double on 64-bit machines only, then just wait for the 32-bit machines to die off
[02:54:54] <jmkasunich> two problems
[02:55:18] <jmkasunich> 1) they die slowly, especially for cheapskates - and many of our users are cheapskates (me included)
[02:55:24] <cradek> me me me
[02:55:35] <jmkasunich> 2) for every problem, we'd have one more question to ask the user: 32 or 64?
[02:56:19] <jepler> that'll be true as soon as we ship an official 64-bit binary, which I'd like to do for hardy heron anyway
[02:56:42] <jmkasunich> number 2 you mean?
[02:57:19] <jmkasunich> float will still be 32 bits on a 64-bit machine, right? (if we don't change it)
[02:57:20] <SWPadnos> I'm not sure I get the problem here. floats are used because we thought doubles couldn't be atomically loaded/stored. if that's untrue, then sed s/float/double/ hal/* would just about make everything work, assuming HAL_FLOAT is cahnged to double
[02:57:47] <jmkasunich> SWPadnos: we have no proof that doubles will be atomically loaded or stored
[02:58:00] <jepler> SWPadnos: because gcc will occasionally generate a pair of movl (32-bit moves using the integer unit) when the destination is 'volatile double'
[02:58:10] <jmkasunich> the compiler is free to (and does) use a pair of 32 bit integer moves to transfer a 64 bit FP value
[02:58:31] <jepler> imo it shouldn't be when the type is volatile, but apparently the gcc people have a different opinion
[02:58:39] <SWPadnos> I wonder if it does that when the dest isn't known to be aligned
[02:59:31] <SWPadnos> at least now I get the problem ;)
[03:01:02] <jepler> here's an example: void f(volatile double *d) { *d = 1.0; } // gcc -march=i386 -O -S -o- this.c
[03:03:05] <jepler> (two 32-bit moves for -march=pentium and below, one 64-bit move for -march=pentium2, -march=athlon and above)
[03:03:47] <SWPadnos> is there a pentium-mmx arch?
[03:04:03] <jmkasunich> seems thats not SMP safe either, and although the gcc guys may not care about RT, they ought to care about SMP
[03:04:20] <SWPadnos> those instructions are guaranteed atomic in MP systems as well
[03:04:41] <jmkasunich> the two 32 bit moves don't guarantee an atomic 64 bit result
[03:04:46] <SWPadnos> no
[03:04:46] <jepler> SWPadnos: 32-bit stores for pentium-mmx; 64-bit store for pentiumpro
[03:04:48] <SWPadnos> oh, right
[03:04:58] <SWPadnos> interesting
[03:05:26] <SWPadnos> I wonder if there was a bug in the core, or if gcc has a < rather than <= problem
[03:05:46] <jepler> it might be faster, who knows
[03:07:47] <SWPadnos> http://www.nabble.com/atomic-accesses-td15817599.html
[03:13:43] <jmkasunich> somebody in that thread wrote: "volatile has nothing to do with atomic access."
[03:13:48] <jmkasunich> which I think is odd
[03:13:59] <SWPadnos> they're separate concepts
[03:14:41] <jmkasunich> volatile tells the compiler "something/someone other than you might be modifying this"
[03:14:53] <jmkasunich> implied in that is "you damn well better read it atomically"
[03:15:05] <SWPadnos> right. so atomic reads / writes would be very good in that situation
[03:15:36] <SWPadnos> volatile means more though, in a sense it's a superset of atomic
[03:15:52] <SWPadnos> but you can still have volatiles that don't need atomic access
[03:16:04] <jmkasunich> how?
[03:16:40] <SWPadnos> for example, on the AVR, you read a timer with two instructions. reading the low value latches the high value into a temp register, which is then read when you read the high register
[03:16:42] <jmkasunich> I certainly agree that volatile is a superset of atomic, but I say that as a superset, volatile _requires_ atomic
[03:16:55] <SWPadnos> not atomic, but the hardware gives you a process to get a consistent read
[03:17:26] <SWPadnos> remember - gcc works for many targets, so they need to keep things non-x86-centric, especially when talking about concepts
[03:17:31] <jmkasunich> so, how would you declare that to make the compiler do the right thing?
[03:17:37] <jmkasunich> I don't think you can
[03:17:47] <SWPadnos> dunno
[03:18:00] <jmkasunich> declaring it as a pair of volatile bytes won't work - it doesn't convey the ordering requirement
[03:18:19] <SWPadnos> but you can make the emitted code do the right thing by default - all you have to do is read low then high instead of high then low
[03:18:48] <SWPadnos> that's a pattern on the AVR, so doing that will make it work for all register pairs like that
[03:18:53] <jepler> 'night guys
[03:18:54] <jmkasunich> as long as the AVR people are consistent - ALL 16 bit entities use that mechanism
[03:18:59] <SWPadnos> see you
[03:19:12] <SWPadnos> yes, they do afaik
[03:19:27] <jmkasunich> anyway, I fail to see how that is an example of a volatile variable that doesn't need atomic access (at some level)
[03:20:00] <jmkasunich> the mechanism for achieving the atomic access is "access in this order" rather than say "disable ints, then access, then enable ints"
[03:20:08] <SWPadnos> volatile is a separate concept, that's all. you can do double-reads to get a consistent value in other cases (not that the compiler will do that for you automatically)
[03:20:20] <jepler> I haven't found all the occurrences of 'volatile' in the C standard, but it appears to *not* guarantee this notion of an atomic store
[03:20:36] <jmkasunich> although to be safe you need to either disable ints, or you might have someone else come in and steal your high byte and release the lock
[03:20:42] <SWPadnos> I think all it guarantees is that any accesses to the variable will not be optimized away
[03:20:48] <jepler> Intel® 64 and IA-32 Architectures
[03:20:48] <jepler> Software Developer's Manual
[03:20:48] <jepler> Volume 3A:
[03:20:49] <jepler> System Programming Guide, Part 1
[03:20:50] <jepler> argh
[03:21:21] <SWPadnos> well, the worse thing would be for someone to come in and read the low byte again - that would re-latch the high byte with the new value :)
[03:21:26] <jepler> at every sequence point the value last stored in the
[03:21:26] <jepler> object shall agree with that prescribed by the abstract machine, except as modified by the
[03:21:29] <jepler> unknown factors mentioned previously
[03:21:35] <SWPadnos> heh
[03:21:38] <jmkasunich> jepler: yeah, what I was really arguing is that "GCC doesn't implement my interpretation of 'volatile'"
[03:21:41] <jmkasunich> which means nothing
[03:21:46] <SWPadnos> we know exactly what it is (unless it's changed)
[03:21:55] <jepler> I think that your interpretation of volatile might be different than the standard's...
[03:21:59] <jepler> but, goodnight
[03:22:13] <jmkasunich> it is - thats the point, my interpretation doesn't mean squat
[03:22:17] <SWPadnos> heh
[03:22:59] <jmkasunich> anyway, my program ran (without the drill bit installed)
[03:23:11] <SWPadnos> cool - with the lower Z accel?
[03:23:14] <jmkasunich> I'm not brave enough to do the first real run this late - tomorrow
[03:23:16] <jmkasunich> yes
[03:23:18] <SWPadnos> heh
[03:23:36] <jmkasunich> I'm probably gonna change the program every time I run it - working up the speeds and feeds
[03:23:55] <SWPadnos> so by the last part, you'll know the optimum rates :)
[03:24:20] <jmkasunich> yeah
[03:24:33] <jmkasunich> I just found an internal threading tool that might work for M12
[03:24:44] <jmkasunich> I'm so tempted to threadcut the holes instead of tapping them
[03:25:19] <jmkasunich> another thing to screw up (bad thread fit), but it completely eliminates the need to tap on the drill press
[03:25:29] <SWPadnos> yeah, that is a plus
[03:25:29] <jmkasunich> thru holes are easy on the drill press
[03:25:35] <jmkasunich> blind ones, not so much
[03:25:50] <jmkasunich> threading to a consistent depth is easy on the lathe
[03:26:34] <jmkasunich> I'm worried about chip extraction though
[03:27:16] <SWPadnos> how much extra depth can you have on the hole?
[03:27:21] <SWPadnos> in
[03:28:00] <jmkasunich> not a lot - the tip of the hole is gonna be about 0.9" deep, full diameter about 0.8", and the thread will be about 0.6"
[03:28:17] <SWPadnos> ok, so 0.3 or so past the thread (33%)
[03:28:29] <SWPadnos> or is that the very tip of the drill point?
[03:28:34] <jmkasunich> the tip
[03:28:40] <jmkasunich> full diameter about 0.8"
[03:28:48] <SWPadnos> hmm
[03:29:04] <jmkasunich> more like 0.77
[03:29:11] <SWPadnos> if you do a cycle that comes pretty far back, you may be able to blow out the crap between passes
[03:29:20] <jmkasunich> otoh, 0.6 deep isn't very deep
[03:29:21] <SWPadnos> or a dwell
[03:29:25] <jmkasunich> the hole is 0.4
[03:29:31] <jmkasunich> diameter
[03:30:31] <jmkasunich> if I'm doing the 29.5 degree infeed right, the chip will come off the tool heading for the open end of the hole
[03:30:47] <jmkasunich> and its 12L14, which I think breaks chips pretty well
[03:31:29] <SWPadnos> you can choose spindle direction to be sure the chip gets pulled toward the opening (assuming the thread cycle can cut on either the front or back side of the hole)
[03:31:30] <jmkasunich> I guess I gotta at least try it ;-)
[03:31:32] <SWPadnos> heh
[03:31:41] <SWPadnos> it's not 00:* yet ;)
[03:31:43] <jmkasunich> I can't choose spindle direction
[03:31:47] <SWPadnos> oh
[03:32:03] <jmkasunich> 1) drilling has to go forward, and I don't want to reverse mid part
[03:32:13] <SWPadnos> can you choose threading side though?
[03:32:34] <SWPadnos> hmmm. does it matter? I should think about it :)
[03:32:36] <jmkasunich> 2) I can't reverse, mid part or otherwise - one of the compromizes I made for contactor control of the motors is no reversing - that will be fixed eventually when I do the VFD
[03:32:55] <jmkasunich> threading side? you mean which way the 29.5 degree infeed goes?
[03:33:08] <jmkasunich> yes, I can choose that - and that determines which way the chip flows off the tool
[03:33:14] <SWPadnos> nevermind. I think I'm being geometrically challenged
[03:33:32] <jmkasunich> what I can't choose is to start the threading passes inside the hole and come out - that would be a left hand thread, or a reversed spindle
[03:33:51] <SWPadnos> right - that's what I was thinking of
[03:34:19] <SWPadnos> I thought at first that changing the side you thread on would change that, but it only changes the phase in the thread, not the direction
[03:34:59] <jmkasunich> I wonder if having the tool upside down and threading on the back would improve chip flow
[03:35:26] <jmkasunich> or is it better to keep the chip on top of the tool as long as possible, to keep it out of the newly cut threads
[03:35:26] <SWPadnos> the spindle will be turning counterclockwise, so that would put the chips unnderthe tool
[03:36:18] <jmkasunich> I could do most of the threading passes, then poke the drill back down the hole to clean it out, then come back and finish
[03:36:39] <jmkasunich> sounds too complicated - I'll just try threading it and see what happens
[03:36:47] <SWPadnos> heh
[03:37:38] <jmkasunich> I need an air nozzle mounted to the threading tool
[03:38:02] <SWPadnos> yeah - and an aux output :)
[03:38:08] <jmkasunich> and a compressor
[03:38:17] <SWPadnos> use a shop-vac and a tiny nozzle
[03:38:39] <jmkasunich> actually, I was just thinking about that - what I really need is some lube in there
[03:38:43] <SWPadnos> we used to do that with plastic parts - turn on the vacuum just before a piece gets broken off
[03:39:02] <SWPadnos> (like the inside of a hole cutout)
[03:39:17] <jmkasunich> suck the broken part up before it causes grief?
[03:39:28] <jmkasunich> or blow it away?
[03:39:32] <SWPadnos> suck
[03:39:43] <SWPadnos> cleans up chips and the floater
[03:39:50] <jmkasunich> for chips I'd be more inclined to blow
[03:39:59] <SWPadnos> well, plastic worked well that way
[03:40:12] <SWPadnos> metal, especially lubed metal maybe not
[03:40:13] <jmkasunich> a nozzle small enough to fit in the hole (along with the cutter) would be small enough to be clogged by chips that try to go down sideways
[03:40:39] <jmkasunich> but if I put air in the bottom of a blind hole, it will come out, and it will take the chips with it
[03:41:30] <SWPadnos> you don't need the nozzle in the hole, just near it
[03:41:43] <SWPadnos> as things break free, there's a general trend toward the vacuum nozzle
[03:41:59] <SWPadnos> but with a blind hole it may not help, because the air's got to come from somewhere
[03:42:00] <jmkasunich> not 1.5 diameters down a blind hole
[03:42:24] <SWPadnos> so yes, you need a compressor :) (or a solenoid and a can of compressed air)
[03:42:37] <SWPadnos> automatic EZ-duster!
[03:42:38] <jmkasunich> or a shopvac on "blow"
[03:42:44] <SWPadnos> oh, that could work
[03:42:52] <jmkasunich> loud and annoying, but doable
[03:42:57] <SWPadnos> though you will get much better performance with a small nozzle
[03:43:12] <SWPadnos> like the 1" or so round, or the small flat one
[03:43:12] <jmkasunich> I also have a vane type vacuum pump that can blow - dunno what pressure and velocity it can do
[03:43:24] <jmkasunich> I would use a piece of small tube
[03:43:28] <jmkasunich> like 1/8"
[03:43:34] <SWPadnos> I guess you should see how much ofa problem it's going to be :)
[03:43:38] <jmkasunich> yes
[03:43:40] <jmkasunich> tomorrow
[03:43:48] <jmkasunich> gotta walk Mr. Dog now
[03:43:52] <jmkasunich> goodnight
[03:43:54] <SWPadnos> but - but - it's still quarter-to :)
[03:43:56] <SWPadnos> see you
[03:44:04] <jmkasunich> won't be by the time I get back from walkies
[03:44:07] <SWPadnos> heh
[07:32:34] <fenn_> fenn_ is now known as fenn
[10:01:30] <steve_stallings> steve_stallings is now known as steves_logging
[11:24:23] <BigJohnT> IN_AXIS = os.environ.has_key("AXIS_PROGRESS_BAR") no longer returns true in my python scripts since 2.4.4, did something change?
[11:39:28] <BigJohnT> nevermind, it's too early to think and when I ran stepconf I forgot that it doesn't put the [FILTER] section in
[12:03:36] <BigJohnT> I'm sure glad no one is up yet
[12:07:53] <micges> hehe I'm up :) here is 1 pm :)
[12:08:31] <micges> going to lunch, bbl
[12:16:32] <alex_joni> 14:07 < micges> hehe I'm up :) here is 1 pm :)
[12:18:34] <skunkworks_> morning alex
[12:21:08] <skunkworks_> logger_dev: bookmark
[12:21:08] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-24.txt
[12:38:05] <micges> morning alex
[12:44:11] <BigJohnT> as soon as I posted that I was waiting for someone to say "dumass you gotta put it in the INI file... another smak on the forhead moment
[12:44:53] <BigJohnT> * BigJohnT is going for a walk in the woods with his dog
[13:38:32] <jepler> hm, several of the gcode tests are failing on my amd64 machine
[13:39:15] <cradek_> how badly?
[13:39:22] <cradek_> cradek_ is now known as cradek
[13:40:14] <jepler> Runtest: 24 tests run, 20 successful, 3 failed + 1 expected
[13:40:15] <jepler> Failed:
[13:40:15] <jepler> /home/jepler/emc2.cvs/tests/ccomp/lathe-comp
[13:40:15] <jepler> /home/jepler/emc2.cvs/tests/ccomp/mill-line-arc-entry
[13:40:15] <jepler> /home/jepler/emc2.cvs/tests/interp/cam-nisley
[13:40:40] <jepler> I'm not sure yet
[13:40:42] <skunkworks_> Hardy?
[13:40:44] <alex_joni> hmm.. isn't that related to TLO on W ?
[13:42:04] <jepler> R i j k words all missing for arc
[13:42:12] <cradek> uh-oh
[13:42:13] <jepler> cam-nisley terminates early with this message
[13:42:30] <alex_joni> huh, that's really odd
[13:42:35] <cradek> here's a thought, maybe after I make big changes to the interp, I should run the tests
[13:42:37] <alex_joni> isn't it a checkout issue?
[13:42:54] <cradek> no, surely it's my fault
[13:42:58] <jepler> I'll update and test again
[13:43:39] <jepler> hmph -- when the difference isn't at the top, 'diff -y' isn't at all useful
[13:53:02] <cradek> ok, my hackery in enhance_block is what broke it
[13:58:19] <CIA-22> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_internal.cc: this recognized completely empty blocks as arcs which then caused the "all R I J K words missing" error.
[14:23:24] <cradek> http://timeguy.com/cradek-files/emc/lucky2.png
[14:24:39] <alex_joni> do you feel lucky punk?
[14:26:45] <skunkworks_> 16 proccessors?
[14:26:54] <cradek> yes
[14:27:54] <alex_joni> 16 cores :P
[14:27:57] <alex_joni> cradek: way nice
[14:34:17] <skunkworks_> most we have right now is a duel quad core
[14:34:22] <skunkworks_> dual?
[14:34:51] <skunkworks_> How does that run emc ;)
[14:40:03] <alex_joni> skunkworks_: same as a regular dual core
[14:40:09] <alex_joni> but it compiles it waaay faster
[14:40:19] <skunkworks_> heh
[15:08:52] <cradek> does anyone else remember a bug report about the XY words incorrectly being required for full circles? I could have sworn someone filed it.
[15:09:02] <cradek> well I guess it would have been a feature request
[15:09:31] <skunkworks_> cradek: what kind of hardware is that? (motherboard)
[15:10:10] <cradek> it's a dell poweredge r900
[15:10:43] <skunkworks_> Nice. We just got a poweredge 2900
[15:10:57] <cradek> 16x Xeon x7350 (2.93GHz) 4MB cache each
[15:11:33] <skunkworks_> nesat
[15:11:34] <skunkworks_> neat
[15:11:36] <skunkworks_> running?
[15:11:44] <cradek> ubuntu of course
[15:11:48] <skunkworks_> nice.
[15:12:17] <skunkworks_> I didn't know if you used a different flavor at work.
[15:12:39] <cradek> it's running ubuntu hardly
[15:13:09] <cradek> the machine's not quite in production yet
[15:13:11] <cradek> sure is fast.
[15:14:05] <skunkworks_> I bet
[15:15:43] <skunkworks_> is it mainly for source managment/ compiling?
[15:15:55] <cradek> compiling
[15:19:42] <alex_joni> cradek: we should get one for emc2 too :)
[15:20:05] <SWPadnos> I have some space here :)
[15:22:17] <alex_joni> whee.. SWPadnos volunteers
[15:29:54] <alex_joni> SWPadnos: maybe you missed me earlier in #emc ;)
[15:30:06] <alex_joni> what's your advice? Q6600 or Q9450 ?
[15:30:08] <SWPadnos> hmmm. could be
[15:30:21] <SWPadnos> oh - the 9xxx - it's gota bigger number ;)
[15:30:33] <alex_joni> ok, the Q9450 it is then
[15:30:46] <alex_joni> I think the Q9350 is equivalent of the Q6600
[15:30:56] <SWPadnos> of course, I haven't seen benchmarks from either, so don't listen to me
[15:51:35] <SWPadnos> wow - CPUs are expensive again
[15:52:07] <SWPadnos> the Opteron 8347HE is a pretty amazing beast: 1.9GHz quad core, 55W(!)
[15:54:04] <skunkworks_> Benchmarks are overrated.. And skewed.. conspiracy I tell you - Conspiracy!
[15:54:28] <SWPadnos> I'm just surprised that they can get 4 cores to run on 55 watts
[15:54:43] <alex_joni> the Q9450 is 45W I think
[15:54:55] <SWPadnos> even cooler ;)
[15:55:30] <SWPadnos> but remember - the Opteron includes the southbridge (or whatever is the memory controller)
[15:55:48] <skunkworks_> amd? they still around? ;)
[15:56:09] <SWPadnos> 45nm, 95W
[15:56:14] <SWPadnos> for the Q9450
[15:56:23] <skunkworks_> guy at work has stock in the company - it has been falling for a while. He had mentioned that IBM might be thinking about buying them out.
[15:56:48] <SWPadnos> I think they've been sliding a bit after the ATI buyout
[15:56:53] <SWPadnos> still make great chips
[15:58:26] <alex_joni> sorry,, 90W
[15:58:38] <SWPadnos> Intel says 95, but what the hey
[16:00:41] <SWPadnos> man - if AMD could get their chips down to 45nm, they'd really have something
[16:01:13] <SWPadnos> they're at 65 now, so the power savings and die shrink would be substantial (not to mention higher clock speeds)
[16:04:26] <alex_joni> SWPadnos: yeah, but they were at 65 way before intel
[16:04:46] <alex_joni> I think they just have mixed lifespans.. probably AMD will be first at 25 or whatever
[16:04:51] <SWPadnos> I guess they lost momentum, 'cause they're still there ;)
[16:04:54] <SWPadnos> heh
[16:06:01] <alex_joni> I think it's about lifetime of the fabs
[16:06:31] <alex_joni> 65 is at the one in Dresden for AMD iirc
[16:06:40] <alex_joni> and it's 2-3 years old?
[16:07:05] <SWPadnos> but it was only $2 billion to build ...
[16:07:13] <SWPadnos> or was it 4.5 or soemthing? :)
[16:07:29] <alex_joni> hmm.. 2004, so I guess 4 years soon :)
[16:07:49] <SWPadnos> http://www.extremetech.com/article2/0,1697,2071433,00.asp
[16:08:00] <SWPadnos> looks like 45nm is in the plan for middle of this year
[16:09:12] <alex_joni> hmm.. kinda late
[16:09:24] <alex_joni> I would have expected they jump on the next train if they waited so much
[16:09:42] <SWPadnos> it takes quite a bit of time to get the tools to make the parts
[16:10:06] <SWPadnos> especially when the process is in development
[16:11:27] <alex_joni> yeah, I know.. that's why I say middle of the year is way too late :)
[16:11:31] <SWPadnos> heh
[16:14:47] <SWPadnos> http://products.amd.com/en-us/EmbeddedCPUDetail.aspx?id=35
[16:15:00] <SWPadnos> too funny - a 100MHz Athlon 64
[16:15:07] <SWPadnos> only 8W though
[16:16:51] <alex_joni> even the memory needs more than that
[16:17:17] <SWPadnos> well, it's got 512k cache - for a small embedded system, you could run from that only :)
[16:17:25] <SWPadnos> (once you load from ROM)
[16:20:09] <SWPadnos> ok, it's a typo (which I kind of thought) - it's a 1GHz chip, still 8W
[16:20:29] <alex_joni> heh
[16:20:31] <alex_joni> bbl
[17:52:18] <alex_joni> On 2008-03-06, during a routine security audit, SourceForge.net staff identified a deficiency in systems data control. We are unaware of any exploitation of this data, which was present in encrypted form. In addition to removing the data, as a preventative measure we have also forced password changes for all SourceForge.net user accounts.
[21:13:16] <cradek>
[21:13:21] <cradek> http://timeguy.com/cradek-files/emc/concave-cuttercomp.png
[21:14:14] <skunkworks_> no raduis too small error? (or am I missing it?)
[21:14:37] <cradek> allowing inside corners
[21:14:44] <SWPadnos> cool
[21:14:58] <SWPadnos> how many segments ahead does it look for gouging?
[21:15:02] <cradek> one
[21:15:06] <SWPadnos> oh :)
[21:15:27] <cradek> and no arcs yet
[21:15:30] <SWPadnos> that's probably good for 90+% of cases though, so very cool
[21:15:57] <skunkworks_> 90% of all statistics are made up on the spot ;)
[21:16:08] <SWPadnos> including those two
[21:16:52] <cradek> it lets you for instance use a diameter of -0.010 if your cam outputs nominal and you use a resharpened tool
[21:17:22] <cradek> i.e. what every other control does :-/
[21:18:53] <SWPadnos> ah - ok. now I get that
[21:18:53] <skunkworks_> very cool
[21:20:41] <jepler> cradek: I assume that adding arcs won't take long :-P
[21:20:47] <cradek> uh yeah!
[21:20:55] <cradek> and detecting all the errors too
[21:21:13] <jepler> I thought the point was to avoid detecting the errors :-P
[21:21:21] <cradek> different errors now
[21:21:34] <SWPadnos> detect them then throw them away
[21:21:45] <cradek> if the tool doesn't fit at all, it will back up until it does, even if it goes back way past the original endpoints
[21:22:09] <cradek> it's hard to say what really should be an error
[21:22:14] <skunkworks_> that sounds like a feature
[21:22:25] <skunkworks_> :)
[21:22:27] <cradek> haha
[21:22:34] <SWPadnos> "Your geometry is too small, please use a smaller tool"
[21:23:01] <SWPadnos> or E_GOT_TO_HAVE_THE_RIGHT_SIZE_TOOL
[21:23:15] <cradek> E_GIGO
[21:23:25] <SWPadnos> geometry in geometry out? :
[21:23:27] <SWPadnos> ;)
[21:23:34] <skunkworks_> E_ANTIVIAGRA
[21:23:42] <SWPadnos> geometry in gouge out
[21:23:53] <alex_joni> gouge in geometry out
[21:24:01] <cradek> garbage in, gouges out
[21:24:18] <alex_joni> g-code in, garbage out?
[21:24:24] <alex_joni> * alex_joni hides
[21:24:29] <cradek> ha
[21:24:34] <SWPadnos> "quit while you're ahead"
[21:24:46] <cradek> garbage gcode in, gouged garbage out
[21:24:59] <cradek> (surely I win?)
[21:25:00] <alex_joni> SWPadnos: that's why I hid
[21:25:07] <SWPadnos> indeed :)
[21:25:44] <jepler> the "g" *stands for* gouge
[21:25:51] <cradek> http://timeguy.com/cradek-files/emc/damn-sequence-numbers.png
[21:27:04] <cradek> lookahead sucks
[21:27:05] <SWPadnos> G code is just controlled gouging
[21:27:49] <cradek> I need to figure out how to save the stupid sequence number and fool it when issuing the moves "late"
[21:27:51] <SWPadnos> heh - that could be one of those phrases like "Juggling is catching"
[21:28:01] <SWPadnos> "machining is controlled gouging"
[21:29:17] <SWPadnos> ahhh - the "next line" is what actually gives you enough info to create the path, so the number ends up beong one to high
[21:46:56] <cradek> one of the regression tests says this is wrong, what do you think?
http://timeguy.com/cradek-files/emc/nope.png
[21:47:25] <alex_joni> is that a bunny?
[21:48:08] <SWPadnos> hmmm. that's an interesting set of more or less continuous segments there
[21:48:45] <cradek> could have something to do with not having implemented arcs yet :-)
[21:49:15] <alex_joni> at least it's somehow contiguous
[21:49:42] <SWPadnos> cradek, are you sure you didn't implement arcs yet? :)
[21:49:50] <cradek> let me check again
[21:49:51] <cradek> nope
[21:50:53] <cradek> maybe nobody will notice
[21:51:08] <SWPadnos> nobody that uses tkemc on sim
[21:51:31] <SWPadnos> and never looks at backplot or coordinate displays
[22:12:03] <Roguish> jepler: Thank you for adding the pivot_length to the .ini file. Especially so quickly.
[22:14:56] <jepler> For example
[22:14:57] <jepler> volatile int *dst = SOMEVALUE;
[22:14:57] <jepler> volatile int *src = SOMEOTHERVALUE;
[22:14:57] <jepler> *dst = *src;
[22:14:57] <jepler> will cause a read of the volatile object pointed to by SRC and
[22:14:59] <jepler> store the value into the volatile object pointed to by DST. There
[22:15:01] <jepler> is no guarantee that these reads and writes are atomic, especially
[22:15:04] <jepler> for objects larger than `int'.
[22:15:21] <jepler> ^^ more from 'info gcc' on volatile; it looks like they don't care about the way some volatile reads and stores might be non-atomic, even when atomic alternatives exist for the architecture in question
[22:18:53] <jmkasunich> hi guys
[22:19:51] <alex_joni> hi jmkasunich
[22:20:11] <alex_joni> jmkasunich: I read back about the branch you mentioned new teleop something
[22:20:26] <alex_joni> unfort. I already made a branch at that time (joints_axes)
[22:20:39] <jmkasunich> oh well
[22:20:47] <alex_joni> wanna join efforts?
[22:20:52] <alex_joni> or keep things separate?
[22:20:57] <jmkasunich> the new-teleop branch is really just for those control.c (and related) changes
[22:21:13] <alex_joni> I'll focus on the task/ini setting up things first
[22:21:33] <jmkasunich> well, we certainly don't want to work so independently that we wind up duplicating effort
[22:21:41] <jmkasunich> oops, dinner is done
[22:23:46] <jepler> interesting stuff in the gcc manual section "atomic builtins"; we should be able to use __sync_lock_test_and_set and __sync_loc_release as "portable" alternatives to the inline asm in rtapi_bitops.h (on compilers that support it)
[22:24:06] <jmkasunich> back for 10 mins - wasn't quite done yet, flip and put back in
[22:24:08] <jepler> not sure what gcc version these first appeared in, though -- I'm on a gutsy machine at the moment
[22:25:47] <alex_joni> skimming google it seems that post gcc-4.0
[22:26:22] <jmkasunich> cradek: can we run the compile farm VMs on your new 16-core computer?
[22:26:40] <alex_joni> hmm .. gcc 4.1.0 and newer
[22:27:05] <alex_joni> jmkasunich: I doubt that.. it's a work computer
[22:27:13] <alex_joni> and it'll probably be quite busy usually
[22:27:17] <jmkasunich> I know, I was mostly joking
[22:27:32] <alex_joni> well.. it wasn't that bad of an idea :)
[22:28:00] <jmkasunich> like I said - "mostly" ;-)
[22:41:15] <alex_joni> jmkasunich: I think I'll keep working on this branch (joints_axes) on the upper levels
[22:41:25] <alex_joni> that way we can each break things differently :P
[22:41:46] <jmkasunich> sounds like a plan
[22:41:46] <alex_joni> after a while we can merge the branches into one, then back to TRUNK
[22:41:56] <jmkasunich> food calls
[22:42:04] <alex_joni> enjoy
[22:42:14] <alex_joni> bed calls here
[23:04:34] <alex_joni> good night all
[23:05:32] <BigJohnT> night
[23:31:25] <jepler> hm, hal basically seems to work right on amd64 with 64-bit 'hal_float', but there are some problems in halscope
[23:33:32] <SWPadnos> sometihng simple like sample size calculation?
[23:35:34] <jepler> I'm not sure exactly what's wrong.
[23:35:46] <SWPadnos> what's it (not) doing?
[23:35:53] <jepler> the second and subsequent channels come up as all 0.0
[23:36:01] <SWPadnos> hmm
[23:36:22] <jepler> don't spend too many brain cells thinking about it, I'm sure it's some bonehead thing on my part
[23:36:26] <SWPadnos> have you made major changes to the scope_rt or halscope code?
[23:36:28] <SWPadnos> heh
[23:36:41] <jmkasunich> I bet there are places where I assume that float is 4 bytes
[23:36:56] <jepler> hal.h | 8 +++
[23:36:56] <jepler> hal_lib.c | 17 ++++---
[23:36:56] <jepler> utils/comp.g | 14 ++++++
[23:36:56] <jepler> utils/scope.c | 3 -
[23:36:56] <jepler> utils/scope_rt.c | 124 +++++++++++++++++++++++++++++++++++-------------------
[23:36:59] <jepler> utils/scope_shm.h | 8 ++-
[23:37:02] <jepler> 6 files changed, 121 insertions(+), 53 deletions(-)
[23:37:04] <jepler> (the comp.g changes are unrelated)
[23:37:09] <SWPadnos> case HAL_FLOAT in scope_rt, for example
[23:37:14] <jepler> yep, I found some of those
[23:37:17] <jepler> I'm sure I didn't find them all
[23:37:36] <jepler> e.g., the integer-unit comparison of floating-point numbers
[23:37:41] <SWPadnos> yep
[23:39:39] <SWPadnos> but if it's triggering, that isn't the (only) problem
