Back
[00:10:49] -!- rob__H has quit [Ping timeout: 246 seconds]
[00:14:07] -!- phantoxeD has quit [Read error: Connection reset by peer]
[00:20:18] -!- Valen has quit [Quit: Leaving.]
[00:35:26] -!- Servos4ever has quit [Quit: ChatZilla 0.9.90 [SeaMonkey 2.14.1/20121129191050]]
[00:46:32] -!- Laremere has quit [Read error: Connection reset by peer]
[00:56:08] -!- andypugh has quit [Quit: andypugh]
[00:56:39] -!- maximilian_h [maximilian_h!~bonsai@g228000245.adsl.alicedsl.de] has joined #linuxcnc-devel
[00:56:42] -!- maximilian_h has quit [Client Quit]
[01:06:48] -!- adb_ has quit [Remote host closed the connection]
[01:21:37] -!- c-bob|| has quit [Ping timeout: 248 seconds]
[01:21:57] -!- ravenlock has quit [Read error: Operation timed out]
[01:33:11] -!- firephoto_ has quit [Quit: ZNC - http://znc.in]
[01:52:32] -!- atom1 has quit [Client Quit]
[01:56:00] -!- Laremere has quit [Ping timeout: 240 seconds]
[02:11:53] Bojangle1 is now known as Bojangles
[02:23:37] -!- Felix29 [Felix29!Felix@c-71-193-105-131.hsd1.in.comcast.net] has joined #linuxcnc-devel
[02:32:19] -!- fiesh has quit [Ping timeout: 256 seconds]
[02:34:12] -!- Felix29 has quit []
[02:42:16] -!- zzolo has quit [Quit: zzolo]
[02:47:04] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[03:04:15] -!- atom1 has quit [Changing host]
[03:08:41] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[03:08:55] -!- atom1 has quit [Client Quit]
[03:09:00] -!- Tom_L has quit [Changing host]
[03:09:23] -!- ve7it has quit [Client Quit]
[03:09:35] -!- Tom_L has quit [Client Quit]
[03:22:29] -!- velcrow has quit [Ping timeout: 240 seconds]
[03:25:46] -!- geo01005 has quit [Ping timeout: 246 seconds]
[03:27:39] -!- skunkworks- [skunkworks-!~yaaic@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:27:47] -!- mrsun has quit [Ping timeout: 260 seconds]
[03:30:34] -!- BJfreeman has quit [Quit: had a good time]
[03:33:42] -!- zzolo has quit [Ping timeout: 252 seconds]
[03:51:48] -!- Keknom has quit [Quit: Leaving.]
[03:58:02] -!- mhaberler [mhaberler!~mhaberler@extern-186.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[04:05:36] -!- skunkworks- has quit [Ping timeout: 252 seconds]
[04:08:06] -!- FinboySlick has quit [Quit: Leaving.]
[04:59:39] -!- WalterN has quit [Disconnected by services]
[04:59:43] H264 is now known as WalterN
[05:01:25] -!- Fox_Muldr has quit [Ping timeout: 248 seconds]
[05:02:04] -!- Laremere has quit [Ping timeout: 260 seconds]
[05:06:11] -!- Valen has quit [Quit: Leaving.]
[05:08:58] -!- dgarr has quit [Quit: Leaving.]
[05:28:58] -!- dhoovie has quit [Ping timeout: 246 seconds]
[05:39:40] Cylly is now known as Loetmichel
[05:58:10] -!- stsydow has quit [Client Quit]
[06:01:46] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[12:55:23] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[13:03:07] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[13:35:26] -!- geo01005 has quit [Read error: Connection reset by peer]
[13:40:32] -!- Simooon has quit [Remote host closed the connection]
[13:53:02] -!- odogono has quit [Ping timeout: 252 seconds]
[13:55:45] -!- maximilian_h has quit [Quit: Leaving.]
[13:56:20] -!- DJ9DJ has quit [Ping timeout: 245 seconds]
[14:05:30] -!- ravenlock has quit [Ping timeout: 264 seconds]
[14:08:55] -!- Valen has quit [Quit: Leaving.]
[14:13:53] -!- LeelooMinai has quit [Ping timeout: 248 seconds]
[14:33:13] -!- grummund has quit [Ping timeout: 246 seconds]
[14:44:04] -!- geo01005 has quit [Ping timeout: 246 seconds]
[14:50:02] -!- carper64_lb [carper64_lb!~quassel@2.221.70.137] has joined #linuxcnc-devel
[14:50:30] Bojangle1 is now known as Bojangles
[15:24:18] -!- joe9 has quit [Ping timeout: 245 seconds]
[15:28:02] _BJfreeman is now known as BJfreeman
[15:39:37] circ-user-cFNAq is now known as ColinWaddell
[15:40:11] -!- Patang has quit [Read error: Connection reset by peer]
[15:46:13] -!- servos4ever has quit [Ping timeout: 252 seconds]
[15:50:59] -!- capricorn_1 has quit [Quit: Konversation terminated!]
[15:51:49] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[15:57:42] -!- Bojangles has quit [Ping timeout: 264 seconds]
[16:13:43] -!- ColinWaddell has quit [Remote host closed the connection]
[16:20:47] -!- zzolo has quit [Quit: zzolo]
[16:22:46] -!- Kup has quit [Read error: Connection reset by peer]
[16:25:46] <KimK_2> mhaberler: I am working on your RT install, it was going very well until "runtests" did not return:
http://imagebin.org/260056 I'll be back on later. Thanks!
[16:27:10] <mhaberler> please post information - crystal ball is off today
[16:27:20] <mhaberler> include dmesg, distro, config.log
[16:27:34] <mhaberler> branch
[16:29:27] -!- mhaberler has quit [Quit: mhaberler]
[16:33:40] -!- BJfreeman has quit [Quit: had a good time]
[16:33:51] -!- mackerski has quit [Quit: mackerski]
[16:38:13] -!- jfire has quit [Quit: Leaving.]
[16:48:37] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[16:52:36] _BJfreeman is now known as BJfreeman
[16:56:44] -!- ingsoc has quit [Read error: Connection reset by peer]
[17:03:42] -!- odogono has quit [Read error: Connection reset by peer]
[17:06:42] -!- Simooon has quit [Quit: Leaving]
[17:15:29] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[17:32:20] -!- syyl_ws has quit [Remote host closed the connection]
[17:32:27] -!- gimpswork has quit []
[17:38:09] -!- toudi_ [toudi_!~toudi@user-46-112-59-228.play-internet.pl] has joined #linuxcnc-devel
[17:42:25] toudi_ is now known as micges
[17:52:01] -!- geo01005 has quit [Ping timeout: 246 seconds]
[17:53:20] -!- micges has quit [Quit: Wychodzi]
[18:16:33] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[18:23:05] -!- odogono has quit [Ping timeout: 252 seconds]
[18:24:33] <mhaberler> jepler: around?
[18:24:44] <jepler> mhaberler: yeah
[18:25:04] <mhaberler> could be there's a major error in my bitops
[18:25:43] <jepler> uh oh :-/
[18:25:44] <jepler> discovered by reading or by testing?
[18:25:44] <mhaberler> the code assumes say set_bit can work on 'bitmaps' (ie array of longs)
[18:25:45] <mhaberler> rtai_rtapi.c: set_bit(module_id, shmem->bitmap)
[18:25:45] <mhaberler> reading
[18:26:11] <mhaberler> the functions I have work on a single unsigned in that case, methinks
[18:26:44] <mhaberler> actually the test_bit gets it right
[18:26:55] <mhaberler> because it indexes the bitmap array
[18:27:09] <jepler> I saw that this capability was in your new code; I wasn't sure whether we were using it yet in master or if it was a new thing to be used by your branch
[18:27:28] <mhaberler> that line above is from v2.5_branch ..
[18:27:56] <mhaberler> unsigned long bitmap[(RTAPI_MAX_SHMEMS / 8) + 1]; /* which modules are
[18:28:14] <jepler> huh ok
[18:29:49] <mhaberler> it seems to me I've have to make those inline funcs so I can enforce argtype unsigned long
[18:29:50] <jepler> so it looks like this code assumes module_id is a small positive integer (less than RTAPI_MAX_SHMEMS) but I think we broke that invariant long ago
[18:30:22] <mhaberler> I cant decode the assembly
[18:30:26] <jepler> no, module_id is compared to RTAPI_MAX_MODULES right in there
[18:30:26] <mhaberler> not sure what it does
[18:30:44] <mhaberler> I _think_ the reason why it never triggered:
[18:30:52] <mhaberler> there's no config with more than 32shmems
[18:30:57] <jepler> hm and the size of bitmap is funky too (the intent is to get at least RTAPI_MAX_SHMEM bits, but it gets typically 4x that)
[18:31:27] <mhaberler> well that is corrected in a master patch, yes - talked to jmk about it and he agreed thats wrong
[18:32:10] <mhaberler> can you read the assembly good enough to tell if it works on an array of longs or just the first word?
[18:32:12] <jepler> anyway yes it quite looks like the current set_bit implementation (btsl instruction) can only set one of the first 32 bits
[18:32:19] <mhaberler> ha!
[18:32:30] <mhaberler> I'm bug compatible then
[18:32:36] <jepler> great :-/
[18:33:20] <mhaberler> ok, what I'll do is.. let me pull that
[18:33:49] <jepler> src/rtapi/rtapi_common.h:#define RTAPI_MAX_SHMEMS 32
[18:34:22] <mhaberler> lucky punch ;)
[18:35:13] <mhaberler> well standing back I think larger bitmaps make sense, so we could just as well fix that while we're here
[18:35:24] <jepler> in the old code, clear_bit is also affected, constant_test_bit is also affected, variable_test_bit is not
[18:35:36] <mhaberler> what I'll do is (lifted from linux kernel):
[18:35:36] <mhaberler> http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/rtapi/rtapi_bitops.h;h=cd0991639ce0d897a81c7b0038074044604fa9a9;hb=refs/heads/dynload-rtapi-common-shm-ub-wip
[18:35:44] <mhaberler> lines 6-24
[18:36:10] <jepler> do we have any information about whether we need support for gcc so old it doesn't have the intrinsics you want to use?
[18:36:15] <mhaberler> and define that static inlines in terms of these macros, and the __atomic_xxx__yy ops on the resulting word
[18:36:21] <mhaberler> very good question..
[18:36:30] <mhaberler> what do we have on hardy?
[18:36:31] <jepler> I have a 10.04 machine handy...
[18:36:45] <mhaberler> that'd be 4.3 or so
[18:37:01] <mhaberler> 4.4.3
[18:37:04] <jepler> 4.4.3 (ubuntu 10.04) has __sync_fetch_and_add but not __atomic_*
[18:37:29] <mhaberler> but one could test with builtin_p
[18:37:40] <jepler> gcc 4.2.4 (ubuntu 8.04) is the same
[18:38:16] <mhaberler> ok, I guess theres a way to test for a builtin
[18:38:23] <mhaberler> oh, we need to check llvm too
[18:38:30] <jepler> ah and reading the old code answers one of the questions I had about constant_test_bit / variable_test_bit: you copied the form of the old code
[18:38:44] <mhaberler> right.. ahem
[18:39:51] <mhaberler> (what I'd _really_ like to do is to lift the kernel lib/bitmap.c code, but I guess thats a license issue)
[18:40:36] <mhaberler> gpl2, so stuck when relicensing :-/
[18:42:13] <jepler> best not to knowingly make it worse
[18:42:55] -!- i_tarzan has quit [Ping timeout: 260 seconds]
[18:43:13] <mhaberler> this might be an option:
https://trac.mcs.anl.gov/projects/openpa/wiki/FAQ
[18:44:03] <jepler> gross, there's something wrong with the original constant_test_bit or else with my harness
[18:44:08] <jepler> long l;
[18:44:08] <jepler> int f() {
[18:44:08] <jepler> constant_test_bit(7, &l);
[18:44:20] <jepler> this is compiling into the sequence mov l, %eax / ret, in otherwords 'return l;'
[18:44:50] <mhaberler> cellar door open, stench coming up
[18:45:40] -!- |1li has quit [Ping timeout: 252 seconds]
[18:48:37] <jepler> I don't spot the problem yet, but having confirmed I get the same assembly from 4.2.4, 4.4.3 and 4.7.2, it seems all the less likely it's a compiler bug
[18:49:32] <jepler> oh now I spotted the problem. I need to 'return constant_test_bit(7, &l)'
[18:50:11] <jepler> the earlier code was: well, gotta read l (since it was read via a volatile pointer), might as well use %eax to do it (oh by the way the return value is undefined)
[18:50:24] <jepler> .. since it could determine that otherwise the result of that expression was unused
[18:51:44] <mhaberler> afacit the use is only on int sized bitmaps
[18:52:13] <mhaberler> we could do this two-level: use the int-size basic ops and define the bitmap ops ontop of them
[18:54:24] <jepler> oh what a surprise: this code is my fault
[18:54:42] <mhaberler> the test_and* variety is used in one place only
[18:55:20] <mhaberler> why exactly did it occur to me to ask _you_ for review ..
[18:56:20] <jepler> as you can see from the header my *intent* was to provide a userspace implementation of a kernel API
[18:56:33] <jepler> so I'd look to the kernel API documentation and see what they offer
[18:57:22] <mhaberler> the openpa library doesnt sport the __atomic_* ops yet either, still __sync_*
[18:58:07] -!- micges [micges!~micges@epg173.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[18:58:12] <cradek> (does this mean locking has been broken all along?)
[18:58:44] <jepler> cradek: it looks like by happy circumstance we are not hitting the buggy code
[18:58:56] <cradek> whee!
[18:59:04] <mhaberler> you resize to > 32 shmems - bum
[18:59:26] <mhaberler> llvm does have the __atomic_* ops:
http://searchcode.com/codesearch/view/25438103
[19:00:06] <mhaberler> clang has __has_builtin()
[19:00:11] <mhaberler> gcc dont
[19:00:40] <mhaberler> well that'd be a configure compile test
[19:01:26] <mhaberler> so that's ticked, we'll inspect config.h for a symbol
[19:01:45] <jepler> #if clang #define use_atomic __hash_builtin(atomic) # elif gnuc && version >= 7.2 #define use_atomic #else #define use_sync #endif
[19:02:04] <jepler> err 4.7 not 7.2
[19:02:19] <jepler> I guess I'm proposing that it can be a compile-time test
[19:02:26] <mhaberler> right
[19:02:41] <mhaberler> ok, one work item less
[19:02:43] <jepler> we just have to hardcode a gcc version that we know has atomic
[19:03:19] <jepler> anyway, it's pretty clear from a linux 2.6 x86/include/asm/bitops.h that I just copied their code
[19:03:43] <jepler> so oddly their constant_test_bit handles multiple-long bitmaps and their variable_test_bit doesn't
[19:04:03] <mhaberler> oh really.. one more twist
[19:04:25] <mhaberler> now what do we actually need? I think it's both, bitop within word boundary, and bitop within word array; layered ontop
[19:04:41] <mhaberler> the few ones which operate on maps > 1 word will be renamed
[19:05:01] <jepler> well since we know we want more than the kernel APIs provide
[19:05:07] <jepler> I think we should tack on the rtapi prefix
[19:05:34] <mhaberler> fine
[19:05:49] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[19:05:52] <mhaberler> we need to syntactically distinguish the word from the map ops
[19:06:11] <jepler> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/bitops.h#n318
[19:06:13] <mhaberler> rtapi_set_bit is guesswork
[19:06:28] <jepler> it's already on the caller to make sure nr is in range
[19:07:21] <jepler> oh wait there's another wrinkle coming up
[19:07:24] <mhaberler> is that variable test_bit on a single word or a map?
[19:07:56] <mhaberler> x86 assembly wasnt included in my mba program ;)
[19:07:58] <jepler> ok, I didn't bother reading what the bt instruction does
[19:07:59] -!- ler_hydra has quit [Remote host closed the connection]
[19:08:15] <jepler> http://www.fermimn.gov.it/linux/quarta/x86/bt.htm
[19:08:47] <jepler> it actually is computing an effective address using what that page denotes as BitOffset DIV 32
[19:08:52] <jepler> so it's fine
[19:09:52] -!- wboykinm has quit [Remote host closed the connection]
[19:10:15] <jepler> when I thought I wrote it it was easy to imagine it was wrong .. when I found out the kernel wrote it and hasn't changed it in years, it becomes more likely it's right
[19:11:01] <jepler> but the __{atomic,sync}_ versions *probably* have to manually account for the int (or long) within the bitmap which is being accessed
[19:11:16] <mhaberler> yes
[19:11:19] -!- morfic has quit [Remote host closed the connection]
[19:11:26] <mhaberler> so the breakage is mine, all mine
[19:12:12] <mhaberler> actually I had already switched to these ops for proper bitmaps in the rtos branch:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/rtapi/rtapi_bitops.h;h=cd0991639ce0d897a81c7b0038074044604fa9a9;hb=refs/heads/dynload-rtapi-common-shm-ub-wip
[19:12:21] <mhaberler> I dumbed it down.. duh.
[19:12:56] <mhaberler> (but not atomic bitmaps, but while we're here we could just as well use the atomic ops)
[19:13:26] <jepler> the remaining part of my own curiosity is why constant_test_bit
[19:14:02] <jepler> it compiles to a greater number of instructions (movl / shrl / andl vs btl / sbbl)
[19:14:13] <jepler> btl must be inefficient on some CPUs
[19:16:06] <mhaberler> I feel a runtest coming in my direction
[19:19:10] <mhaberler> fair enough, I'll give it an iteration - thanks for supervising bug reinjection ;)
[19:19:59] <jepler> apparently bt was once slower than equivalent code, possibly until intel's core2 generation:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00539.html
[19:24:41] <mhaberler> q: do you see any reason to use cpp macros, when static inlines give you the same effect with full type checking?
[19:25:23] <jepler> no
[19:25:34] <mhaberler> (assuming its just linear expansion, no conditionals etc)
[19:25:37] <mhaberler> I never understood that
[19:27:02] <jepler> the world has not always been only gcc
[19:27:46] <mhaberler> is there anything gcc-specific to static inlines?
[19:29:33] <jepler> http://www.greenend.org.uk/rjk/tech/inline.html
[19:29:50] <jepler> they were developed before inline was added to C
[19:29:56] <mhaberler> just reading that
[19:30:36] <jepler> oh you must be using the same google as me
[19:32:46] <jepler> it appears to be that constant shrl+mask is faster than bt is faster than variable shrl+mash
[19:33:03] <jepler> at least on some specific past CPUs
[19:33:12] <jepler> that's the only way to make sense of how the kernel macros are structured anyway
[19:33:20] <jepler> mash=mask
[19:33:45] <jepler> what that page (greenend) doesn't go into is C++ inlining which is yet another different beast :-/
[19:34:13] <mhaberler> well we could switch everything to c++11, and we get grandiose atomics
[19:34:24] <jepler> ummmm well err
[19:34:28] <jepler> let's defer that for now
[19:35:18] <jepler> anyway for your implementation I would ditch the constant / variable implementations and just have a single implementation
[19:35:35] <mhaberler> it was you who brought me on this 'no legacy builtins' bandwagon, so why stop here
[19:35:36] <mhaberler> probably
[19:35:37] <mhaberler> and separate ones for word and map ops
[19:36:02] <jepler> I have still not grasped why you see separate word vs map ops as important
[19:36:28] <mhaberler> make them all map ops you mean?
[19:36:31] <jepler> right
[19:36:38] <jepler> you either pass map or &word as the parameter
[19:36:53] <mhaberler> valid point
[19:36:56] <jepler> at least I think it's how the current one works
[19:37:12] <mhaberler> ok, well then its full circle
[19:37:23] <mhaberler> fine
[19:37:33] <jepler> 90 minutes, that's 4 degrees a minute that we turned
[19:38:48] <jepler> if longs are used internally then I imagine the maps and words must be long-aligned for systems with alignment faults
[19:39:15] <mhaberler> right, all unsigned longs
[19:39:25] <jepler> yes unsigned is good too
[19:39:57] <mhaberler> I didnt understand the int result in the test_bit to start with
[19:40:04] <jepler> hm, do we have a LONG_BIT type define yet?
[19:40:48] <mhaberler> that be warranted; I use explicit ulongs here:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/rtapi/rtapi_bitops.h;h=cd0991639ce0d897a81c7b0038074044604fa9a9;hb=refs/heads/dynload-rtapi-common-shm-ub-wip
[19:40:55] <mhaberler> which isnt that great
[19:43:57] <jepler> I like DECLARE_BITMAP fwiw
[19:45:04] <jepler> as for when to use the new implementation based on the gcc intrinsics, what about: #if MODULE use asm/bitops.h #else use intrinsics #endif
[19:45:44] <jepler> since gcc 4.2 (2007) already has __sync_* we don't think we need to support any compilers that don't have one of __sync_ or __atomic_
[19:46:08] <jepler> and that lets you delete the code I copied from a gpl2only header file in the kernel
[19:46:27] -!- Daywalker198454 has quit [Remote host closed the connection]
[19:46:42] <mhaberler> right, DECLARE_BITMAP I introduced after I discovered these oversized maps
[19:48:25] -!- micges has quit [Read error: Connection reset by peer]
[19:48:33] -!- micges [micges!~micges@epg173.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[19:50:02] <jepler> gcc 4.1.0 (2006) has __sync_ as well. gcc 4.0 (Ubuntu 6.06 Dapper Drake) did not.
[19:50:18] <jepler> but dapper has long since been put to bed
[19:50:31] <mhaberler> what would be the proper return type? I think a long_bit; a bool dont convey the previous value properly I think
[19:50:51] <jepler> return type of which function?
[19:51:13] <mhaberler> well for instance test_and_set_bit
[19:52:05] <jepler> assuming I'm not reading the asm wrong again
[19:52:21] <jepler> I am pretty sure it does what the comment says: returns zero if the old value of the bit was zero, nonzero otherwise
[19:52:35] <jepler> and in fact it returns either 0 or -1
[19:53:12] <jepler> btsl sets the bit in memory and sets the carry flag to equal the old value of the bit. sbbl is computing %0-%0-carry_bit, so you get either 0 or -1
[19:53:23] -!- i_tarzan_ has quit [Ping timeout: 260 seconds]
[19:53:32] <jepler> (sbb mnemonic for subtract with borrow)
[19:53:59] <jepler> so you don't want to return the old value of the long, you want to return the correct bit of the old value of the ling
[19:54:04] <jepler> ling=long ding=dong
[19:54:57] <mhaberler> but then the dingdong return type is a long_bit because thats a bitvector, not a bool
[19:56:16] <mhaberler> and thats what the __atomics return too
[19:56:45] <jepler> long x = 1; y = test_and_set_bit(31, &x);
[19:57:11] <jepler> I'm pretty sure that y gets 0 (because the high bit isn't set before the operation) under the old code
[19:57:22] <mhaberler> y = 0x800000
[19:57:31] <jepler> while you're saying it would get 1, which is the old value of the unsigned long at that location
[19:57:59] <jepler> here's where a test written to the old code would be valuable, because I'm not entirely sure of my reading of the code + comments
[19:59:20] <mhaberler> nonsense the retval should be 0 because thats the previous value of bit 31
[20:00:03] <mhaberler> you are right
[20:00:46] <jepler> http://pastebin.com/b1qeGnF4
[20:00:57] <jepler> this "test" doesn't assert in v2.5_branch
[20:01:32] <jepler> but now I think you've understood what I was saying
[20:01:57] -!- WalterN has quit [Disconnected by services]
[20:02:01] H264 is now known as WalterN
[20:02:11] <jepler> so that'd make the macro version more like #define test_and_set_bit(bit, value) (__sync_fetch_and_or(value, _BIT(bit)) & _BIT(bit))
[20:02:23] <jepler> or maybe adding a != 0
[20:02:52] <mhaberler> { tmp = *ptr; *ptr |= val; return tmp; }
[20:03:14] <mhaberler> thats the __atomic_fetch_or
[20:03:20] -!- thesisb has quit [Quit: Leaving...]
[20:03:51] <mhaberler> or sync_fetch_and_or, same thing
[20:04:05] <KGB-linuxcnc> 03jthornton 05v2.5_branch 4e0b4b7 06linuxcnc 10docs/src/examples/gs2_example.txt * Docs: fix typo option number
[20:04:16] <mhaberler> meaning it returns the full word worth of previous value
[20:04:55] <mhaberler> right, we need to and it with the mask to return exactly this bits previous value
[20:05:35] <jepler> right, boiling it down to a program,
http://pastebin.com/hE1Sqr6X asserts on line 26
[20:06:05] <mhaberler> uhum
[20:07:46] <mhaberler> so we have: and the bitmask, and value must become &value[_BIT_WORD(nr)]
[20:09:59] <jepler> I need to think about the second part of that statement for a moment
[20:10:24] <jepler> in the macro version you don't know the type of value
[20:10:42] <mhaberler> I assume static inline already, its all long_bit's
[20:12:14] <jepler> OK, if the type of value is right then I think the pointer arithmetic is right
[20:12:37] <jepler> it's the same as (value + _BIT_WORD(nr)) which is a more natural way for me to think of it
[20:12:53] <mhaberler> ok
[20:13:10] <jepler> (not saying you need to write it different)
[20:13:14] <jepler> be back in 20 or so
[20:13:18] <mhaberler> sure
[20:13:46] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:24:58] frewsxcv94040 is now known as frewsxcv
[20:32:27] -!- stsy has quit [Quit: Leaving]
[20:33:01] <jepler> (<span class="atnight">00:18</span> -0600)
[20:33:23] <jepler> what a silly gitweb feature: it shows in red commit times it thinks are "at night"
[20:33:44] <alex_joni> at night for whom?
[20:34:42] <jepler> the author and committer fields of a git commit have a GMT offset in minutes, so "local to the committer/author" appears to be the answer
[20:37:03] <cradek> how odd
[20:40:21] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:41:07] -!- syyl has quit [Quit: Leaving]
[20:58:34] -!- stsydow has quit [Remote host closed the connection]
[20:58:46] -!- ravenlock has quit [Remote host closed the connection]
[21:00:53] <seb_kuzminsky> makes perfect sense, local committer night means "watch out for sleepy coders"
[21:02:21] -!- FinboySlick has quit [Quit: Leaving.]
[21:03:07] <jepler> but who says committers are tired when it's dark?
[21:03:14] <jepler> I know I am, but I've seen the hours the rest of you keep
[21:05:16] <alex_joni> heh
[21:05:25] <jepler> oooh quitting time
[21:07:41] <seb_kuzminsky> ugh i still have two hours
[21:07:47] * seb_kuzminsky should move east
[21:07:50] <seb_kuzminsky> oh wait
[21:08:35] <alex_joni> try the other way
[21:09:23] -!- DJ9DJ has quit [Quit: bye]
[21:11:52] -!- thesisb has quit [Ping timeout: 246 seconds]
[21:13:58] <seb_kuzminsky> alex_joni: are you coming to the hackfest at stuart's?
[21:14:17] <alex_joni> seb_kuzminsky: unfortunately no
[21:17:56] <KGB-linuxcnc> 03git 05rtapi-bitops-gcc-intrinsics 5b9519d 06linuxcnc 10src/rtapi/rtapi_bitops.h * rtapi_bitops.h: remove blunder, use newer intrinsics
[21:21:01] -!- jerryitt has quit [Ping timeout: 252 seconds]
[21:24:11] <linuxcnc-build> build #248 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/248 blamelist: Michael Haberler <git@mah.priv.at>
[21:26:29] -!- chillly has quit [Quit: Leaving]
[21:27:51] <jepler> no good deed
[21:27:53] * jepler goes to look
[21:29:21] <linuxcnc-build> build #1046 of lucid-rtai-i386-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1046 blamelist: Michael Haberler <git@mah.priv.at>
[21:29:22] <jepler> oh somehow it picked up both the kernel and local defs of test_and_set_bit
[21:30:39] -!- louis____ has quit [Remote host closed the connection]
[21:32:57] <seb_kuzminsky> alex_joni: bummer! maybe next time
[21:33:06] <alex_joni> seb_kuzminsky: I keep telling myself that
[21:40:21] -!- fatpandas has quit [Quit: leaving]
[21:43:04] -!- arconquit has quit [Quit: Page closed]
[21:49:40] -!- mhaberler has quit [Quit: mhaberler]
[21:52:54] -!- ve7it has quit [Remote host closed the connection]
[22:00:59] <linuxcnc-build> build #1047 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1047 blamelist: Michael Haberler <git@mah.priv.at>
[22:01:23] -!- vladimirek has quit [Remote host closed the connection]
[22:07:37] <linuxcnc-build> build #1047 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1047 blamelist: Michael Haberler <git@mah.priv.at>
[22:08:17] -!- Nick001-Shop has quit [Remote host closed the connection]
[22:12:05] -!- thesisb has quit [Read error: Connection reset by peer]
[22:13:48] -!- nikola_ has quit [Quit: Page closed]
[22:15:31] -!- chopper79 has quit [Ping timeout: 264 seconds]
[22:23:34] -!- ronson has quit [Quit: Leaving...]
[22:30:51] -!- Mjolinor has quit [Quit: Leaving]
[22:33:26] <linuxcnc-build> build #1045 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1045 blamelist: Michael Haberler <git@mah.priv.at>
[22:35:05] -!- largecheesepuff has quit [Ping timeout: 245 seconds]
[22:38:05] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[22:39:59] -!- zzolo has quit [Quit: zzolo]
[22:44:20] -!- ve7it has quit [Remote host closed the connection]
[22:46:29] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[22:52:04] -!- tmcw has quit [Remote host closed the connection]
[22:57:11] -!- odogono has quit [Quit: odogono]
[23:08:58] -!- rob_h has quit [Ping timeout: 240 seconds]
[23:17:12] -!- Patang has quit [Ping timeout: 240 seconds]
[23:18:43] -!- asdfasd has quit [Ping timeout: 252 seconds]
[23:32:13] -!- geo01005 has quit [Ping timeout: 246 seconds]
[23:34:44] -!- micges has quit [Quit: Leaving]
[23:36:19] -!- Jymmm has quit [Ping timeout: 252 seconds]
[23:37:37] -!- Farthen has quit [Ping timeout: 248 seconds]
[23:39:14] * KimK_2 is posting this test results link here for mhaberler: http://pastebin.com/TnHZ6AGN
[23:39:54] -!- Loetmichel has quit [Ping timeout: 252 seconds]
[23:40:59] -!- KimK_2 has quit [Quit: Leaving]
[23:44:22] -!- KimK_2 [KimK_2!~kkirwan@ip68-102-65-151.ks.ok.cox.net] has joined #linuxcnc-devel
[23:44:31] -!- KimK__2 [KimK__2!~kkirwan@ip68-102-65-151.ks.ok.cox.net] has joined #linuxcnc-devel
[23:44:59] -!- KimK__2 has quit [Client Quit]