Back
[08:24:06] <jepler> andypugh: if you're back to needing s64 division and modulo, may I remind you I posted some code for it recently when we were discussing it
[08:24:11] <jepler> still untested :-P
[09:00:54] <jepler> http://emergent.unpythonic.net/files/sandbox/0001-rtapi_math64-signed-versions-untested.patch
[09:01:47] <jepler> afk
[09:27:01] <andypugh> Ah, I shuld have looked sooner, I just did that. :-)
[09:29:12] <andypugh> The main difference in approach being that you documented it ;-)
[10:24:32] <jepler> andypugh: oh well, it was mostly a cut&paste job
[10:25:04] <andypugh> I am somewhat gratified to find that I was on the right track.
[10:26:08] <andypugh> Though I am a bit puzzled as to why we need library functions for simple arithmetic operations.
[10:27:35] <Tom_itx> i doubt many platforms do 64bit math natively
[10:28:43] <Tom_itx> most µC don't anyway
[10:30:27] <archivist> and languages have just assumed platform register size
[10:41:07] <andypugh> Hi Pavel
[10:43:28] <jepler> andypugh: the x86 doesn't have an instruction that performs s64/s64 division or s64%s64 modulo, so gcc compiles in a call to a special internal function such as __moddi3 and all userspace programs are implicitly linked against a library which includes the implementation of __moddi3
[10:43:39] <jepler> the kernel doesn't link against this library
[10:44:32] <andypugh> I suppose all data types are a construct of the compiler, really.
[10:44:45] <jepler> instead it requires you to call a function where this arithmetic is required
[10:46:01] <andypugh> It has been an instructive few hours :-)
[10:46:36] <andypugh> And I may have found a bug in the LCD driver code in the process.
[10:46:51] <jepler> another detail is that the kernel functions actually perform math with a 32-bit denominator: s64/s32. in C, if you have an expression where the types are s64 and s32 and you do arithmetic on them, the s32 is promoted to s64. the function version doesn't force this promotion, so it can actually be a smidge more efficient than __divdi3 which has to assume that the denominator could have its high bits set
[10:47:23] <jepler> (in practice that overhead is unimportant--a single test-and-branch--but you know how kernel people are about efficiency)
[10:48:50] <andypugh> Efficiency seems like it should be considered in RT code too.
[10:49:15] <andypugh> Can you have a look at line 500 of src/hal/components/lcd.c ?
[10:49:50] <andypugh> I think it doesn't do what I meant it to do. (It is meant to count decimal digits in a number, I think)
[10:49:53] <jepler> 500 for (c = m + 1 + s; (do_div(tmp, 10)) > 0 ; c++){} //don't have a log10
[10:51:18] <andypugh> I think I have since learned that do_div does a divide-in-place (which is fine here) but returns the remainder, whereas thar code looks to be assuming that the result is returned.
[10:51:29] <jepler> do_div is a macro provided by the kernel. it modifies its first argument, dividing it in-place by the second argument and returning the remainder
[10:51:34] <jepler> http://lxr.free-electrons.com/source/arch/x86/include/asm/div64.h#L10
[10:51:44] <andypugh> for (c = m + 1 + s; do_div(tmp, 10), tmp > 0 ; c++){} //don't have a log10
[10:51:58] <andypugh> Is probably what I wanted
[10:52:55] <andypugh> And I suspect that I never noticed the bug as my typical test numbers were 1.23456789, so it worked.
[10:53:48] <jepler> so you really want c += ilog10_ceil(tmp)?
[10:54:02] <jepler> i.e., add 1 for tmp=9, 2 for tmp=10?
[10:54:16] <andypugh> And, in fact, that is just a really perverse way to write: for (c = m + 1 + s; tmp > 0 ; c++){do_div(tmp, 10)} //don't have a log10
[10:54:22] <jepler> (add 1 for tmp=0?)
[10:54:47] <andypugh> Yes.
[10:56:10] <andypugh> Are you saying that there is a log10?
[10:56:19] <jepler> no
[10:56:48] <andypugh> And it is likely that that loop is faster than finding the log too.
[10:58:58] <andypugh> Anyway, I am just checking that the code is wrong in the way i think it is. I am pretty sure that my plan wasn't to find the first zero digit.
[10:59:10] <jepler> yeah
[10:59:21] <jepler> I'm working on writing ilog10_ceil so you can just incorporate it and call it..
[10:59:24] <jepler> but so far I've got it wrong :-P
[10:59:30] <jepler> ilog10_ceil(9) -> 64
[11:00:15] <andypugh> Is there any point making it into a function call? It doesn't look like anyone else has ever wanted it.
[11:01:12] <jepler> when I get stuck I like to assume there's a function that does what I want and just write a call to it
[11:01:30] <jepler> ilog10_ceil is such a function; I can even imagine what its implementation might look like
[11:01:31] <andypugh> (and note that it needs to work with u64
[11:01:52] <jepler> and when it is a function I can also test it
[11:02:07] <jepler> http://emergent.unpythonic.net/files/sandbox/ilog10_ceil.c
[11:03:59] <jepler> 64-bit abs is called llabs in userspace and abs64 in kernel space :-/
[11:04:15] <jepler> http://lxr.free-electrons.com/source/include/linux/kernel.h#L173
[11:05:28] <jepler> so maybe we want rtapi_abs64, which could also go in rtapi_math64.h if you wanted
[11:05:29] <andypugh> while(v >= c) { c *= 10; r++; } is closer to what I think I wanted.
[11:06:00] <jepler> yeah you're right
[11:06:12] <jepler> I didn't get around to writing the part where I actually checked that the result was what I thought it should be
[11:06:23] <jepler> so it's not exactly _ceil is it
[11:06:35] <jepler> isn't it 1 + ilog10_floor then?
[11:06:47] <andypugh> Maybe :-)
[11:06:53] <jepler> call it ndigits and forget it
[11:06:58] <andypugh> Quite.
[11:07:15] <andypugh> ndigits(value, base)
[11:08:07] <andypugh> I will make a note of the fact there is a bug to fix, but I am in the middle of other stuffs at the moment.
[11:10:27] <jepler> OK
[11:10:39] <jepler> yeah, you could generalize it to other bases if you wanted
[11:11:26] <jepler> incidentally I chose to write in terms of * because usually integer * is faster than /
[11:15:54] <andypugh> Yes, I saw that and recognised it as a better solution.
[11:16:33] <andypugh> Also no pesky __divdi3 I suspect?
[11:26:54] <jepler> it looks like x86 assembles u64*u32 inline
[11:27:59] <jepler> it looks like the kernel provides __muldi3 for architectures where it's needed, e.g.,
http://lxr.free-electrons.com/source/arch/microblaze/lib/muldi3.c#L46
[11:29:07] <andypugh> It seems wrong that it is all in terms of the vaguely ambiguous "long" "short" and "long long"
[11:29:58] <Tom_itx> long is different on different platforms too
[11:30:43] <andypugh> That's my point.
[11:30:59] <Tom_itx> welcome to c
[11:31:51] <jepler> if you mean that specific implementation of __muldi3, that is platform specific and on that platform "long long" is dimode
[11:32:12] <jepler> http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
[11:33:18] <jepler> DImode
[11:33:18] <jepler> “Double Integer” mode represents an eight-byte integer.
[11:33:21] <jepler> http://gcc.gnu.org/onlinedocs/gccint/Machine-Modes.html#Machine-Modes
[11:34:07] <andypugh> "Please sir, can I be excused? My brain is full"
[11:52:18] <norbert_> darumist
[15:25:39] <KGB-linuxcnc> 03nieson 05master af387dd 06linuxcnc 10(109 files in 12 dirs) * gmoccapy_0_9_7_1 - reordered all files to follow the new gscreen structure
[15:25:39] <KGB-linuxcnc> 03nieson 05master 125f811 06linuxcnc 10(11 files in 2 dirs) * gmoccapy 0.9.7.1 - New file structure according to gscreen needs
[16:00:48] <KGB-linuxcnc> 03jepler 05master 6018a79 06linuxcnc 10docs/man/man3/rtapi_div_u64.3rtapi 10src/rtapi/rtapi_math64.h * rtapi_math64: signed versions. (Seem to work, ap)
[16:00:48] <KGB-linuxcnc> 03andypugh 05master 68fab3f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ 10hostmot2.h 10sserial.c 10sserial.h
[16:00:49] <KGB-linuxcnc> Add index, reset and scaled position to the smart-serial encoders.
[16:00:52] <KGB-linuxcnc> The encoders on the 7i73 HMI card are different from the standard counters
[16:00:55] <KGB-linuxcnc> and report a count back to the FPGA card directly. In this sense they
[16:00:57] <KGB-linuxcnc> look more like an absolute encoder.
[16:01:00] <KGB-linuxcnc> So much like an absolute encoder that this change is part of using this
[16:01:02] <KGB-linuxcnc> code to handle the BISS / SSI encoder modules.
[16:01:05] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[16:49:34] <KGB-linuxcnc> 03chrisinnanaimo 05master e83ee8c 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py * gscreen -add audio_available to the data array
[16:49:34] <KGB-linuxcnc> 03chrisinnanaimo 05master 28d31c2 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py * gscreen -add paths to data vatiable
[16:49:38] <KGB-linuxcnc> 03chrisinnanaimo 05master c8783c5 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py * gscreen -fix a spelling mistake no other changes intended
[17:16:04] <linuxcnc-build> build #1307 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/1307 blamelist: Jeff Epler <jepler@unpythonic.net>, Andy Pugh <andypugh@dn2800.(none)>
[17:47:42] <linuxcnc-build> build #1305 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1305 blamelist: Jeff Epler <jepler@unpythonic.net>, Andy Pugh <andypugh@dn2800.(none)>
[17:50:51] <andypugh> Where do I look in the buildbot logs to find out what I have done wrong this time?
[17:59:32] <linuxcnc-build> build #1308 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/1308 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[18:27:49] <linuxcnc-build> build #1306 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1306 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[18:31:26] <Tom_itx> andypugh, change #21737?
[18:32:01] <Tom_itx> further down.. changed files
[18:32:29] <andypugh> Yes, but I meant to change them.
[18:32:41] <andypugh> I was hoping there was some hint what the failure was.
[18:32:45] <Tom_itx> i've not used an open build system
[18:32:49] <Tom_itx> can't help you there
[18:33:03] <Tom_itx> there should be a hint somewhere
[18:34:10] <Tom_itx> you'll have to find which one is your error
[18:34:35] <Tom_itx> under steps and log files i presume
[18:36:21] <Tom_itx> since there were 2 edits you'll have to find the one that relates to yours
[18:38:57] <Tom_itx> it could also be the rtapi_math64.h edit that caused the fail
[18:39:46] <Tom_itx> does this system compile for several platforms at once?
[18:39:53] <Tom_itx> appears that it does
[18:40:05] <andypugh> Yes, it is all quite spooky
[18:40:06] <Tom_itx> hardy, lucid, precise
[18:40:35] <Tom_itx> and 32/64 bit
[18:41:14] <Tom_itx> follow one of the log files in 'Steps and Logfiles' see if it relates to your work or his
[18:41:30] <andypugh> Yeah, the problem is with Hardy which doesn't have math64.h it appears..
[18:41:34] <Tom_itx> not being an expert, that's where i'd start
[18:43:49] <Tom_itx> tbl:fatal error: can't open `man1/linuxcnc.1': No such file or directory
[18:43:55] <Tom_itx> stands out in one of them
[18:45:44] <Tom_itx> from 2. lucid-i386
[21:19:31] <jepler> andypugh: following th elink from build #1307 to stdio of the build step,
[21:19:35] <jepler> /home/farmer/emc2-buildbot/hardy-rtai-i386/hardy-i386-realtime-rip/build/src/rtapi/rtapi_math64.h:5:26: error: linux/math64.h: No such file or directory
[21:19:45] <jepler> apparently this header didn't exist in the days of ubuntu hardy :-/
[21:20:38] <jepler> oh wait I see you figured that out hours ago
[21:20:39] <jepler> :-P
[21:21:16] <Tom_itx> well he found it, i was guessing :)
[21:23:48] <jepler> so it looks like for kernel 2.6.24 we would have to write the functions we want in terms of do_div
[21:38:34] <Tom_itx> guess i was looking in the wrong file
[21:38:41] <Tom_itx> should have looked at stdio first
[21:40:49] <Tom_itx> i presume master has limited access anyway
[22:08:00] <KGB-linuxcnc> 03jepler 05master 0159801 06linuxcnc 10src/rtapi/rtapi_math64.h * math64: version for hardy kernel
[22:08:00] <KGB-linuxcnc> 03jepler 05master 6810705 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ 10setsserial.c 10sserial.c * hostmot2: Use z modifier to print size_t
[22:08:04] <KGB-linuxcnc> 03jepler 05master 64aed89 06linuxcnc 10src/hal/drivers/mesa-hostmot2/setsserial.c * hostmot2: correctly return success from sslbp_read_long
[22:08:16] <jepler> andypugh: this at least compiles on hardy now ^^^
[22:08:41] <jepler> and my test harness makes me think maybe I got it right:
http://emergent.unpythonic.net/files/sandbox/divvy.c
[22:08:45] <jepler> goodnight