**** BEGIN LOGGING AT Mon Nov 27 03:00:01 2017 Nov 27 07:31:27 DocScrutinizer05: if i may ask n900 what type of simlock have? Nov 27 07:54:59 it usually comes sim-unlocked Nov 27 07:56:42 and since it has bb5 modem, all rules apply Nov 27 11:22:31 Why does my N900 have camera's videos mixed with all other films in Media Player, and not placed into category of "Recorded by device camera"? Nov 27 13:31:07 I think because it doesn't filter subgroups out form "all" group Nov 27 13:31:45 beauty of fracker err tracker Nov 27 13:32:14 the tracker concept is broken by design, in my book Nov 27 13:54:40 is it ok if I mirror http://repository.maemo.org/ ? Nov 27 13:54:46 that is, recursive wget or rsync Nov 27 13:55:04 don't want to be that guy which hogs bandwidth without permission Nov 27 13:56:57 if anything, you should probably use apt-mirror Nov 27 13:57:03 (or something close to it) Nov 27 13:58:10 first sync will take ages, but then on it should be fine Nov 27 14:01:18 generally it's ok to mirror repos and whatever you like Nov 27 14:01:34 but listen to advice regarding best way to do so Nov 27 14:18:10 new cssu in cssu testing it seems, cool. can't upgrade to it due some conflict with curl though (on cssu thumb) Nov 27 14:54:15 Wizzup: hrrm somebody else whad some crazy dependency mess too Nov 27 14:54:35 15:23 * DocScrutinizer05 feels massive headache http://paste.opensuse.org/86359988 - prolly getting too old for such shit Nov 27 14:55:54 ok maye that wasn't the rpoblem Nov 27 15:04:50 enyc: I think there needs to be a new curl build for thumb Nov 27 15:04:56 so it might just take a bit more time Nov 27 21:02:38 hey DocScrutinizer05 Nov 27 21:03:10 you mentioned softfloat is not 'that' much slower than hardfloat Nov 27 21:03:33 how would it hold against something like DSP Nov 27 21:04:34 say, a multichannel softsynth Nov 27 21:04:58 CatButts: softFP uses whatever available, DSP or arithmetic coprocessor or even software implementation of float math Nov 27 21:05:37 softfp is hardfp wrapped into a library call ABI Nov 27 21:05:51 if the platform has a hw accel for FP Nov 27 21:06:13 so your question doesn't make much sense to me Nov 27 21:06:18 so it still ends up in hardware, but there is a capability check at runtime? Nov 27 21:06:32 not at runtime, at compile time Nov 27 21:07:38 at least for maemo, that's not done at runtime afaik Nov 27 21:08:08 so on the n900, I still benefit from hardware floats? Nov 27 21:08:15 softfp is a library, the implementation of that library may differ with target platform, the API stays the same Nov 27 21:08:23 ah, I see meow Nov 27 21:08:24 yes Nov 27 21:09:01 hardfp directly calls the float hw from your code, without any library in between Nov 27 21:09:25 (simplified picture) Nov 27 21:09:57 I initially thought that softfp meant software emulated float calculations Nov 27 21:10:01 strictly Nov 27 21:10:02 the overhead of softfp over hardfp is basically the library wrapper code, for maemo Nov 27 21:10:05 not a lib call Nov 27 21:10:14 afaik Nov 27 21:10:47 now it's clear in my head Nov 27 21:11:15 or let me put it that way: your maemo osftfp library is built using hardfp code Nov 27 21:11:28 softfp* Nov 27 21:12:56 guys, it is not like that Nov 27 21:13:04 it is about the calling convention Nov 27 21:13:30 softfp means float args are passed through int registers Nov 27 21:13:52 hardfp means float args are passed through FP registers Nov 27 21:13:54 yes, you call a copoc directly with parameters in coproc registers, for hardfp. You call a library with parameters on stack or whatever, for softfp Nov 27 21:14:38 no, you call a library (or a local function) both ways Nov 27 21:15:16 https://wiki.debian.org/ArmHardFloatPort/VfpComparison Nov 27 21:15:20 just that function parameters are put in CPU for softfp or FPU for hardfp registers Nov 27 21:15:55 with softfp you can emulate FP in software Nov 27 21:16:12 but you can use HW FPU if it is available as well Nov 27 21:16:22 "soft" vs "softfp" vs "hard" Nov 27 21:16:49 DocScrutinizer05: remember how was 8087 emulated? Nov 27 21:16:54 back then Nov 27 21:17:25 wasn't that softirq Nov 27 21:17:40 software interrupt Nov 27 21:18:27 no, it was generatin "illegal instruction" interrupt, whatever it was called :) Nov 27 21:18:49 that irq was handled by FPU emulation lib Nov 27 21:18:50 hmm, pretty much a sowtware interrupt Nov 27 21:19:21 an instruction causing an interupt Nov 27 21:20:01 however, soft(fp) vs hardfp in terms of cortex a8 is just about where FP parameters are passed Nov 27 21:20:13 :-) Nov 27 21:20:35 so not as huge a difference as the uneduicated user might expect Nov 27 21:20:43 well, it was a prefix at a start of every FPU instruction, 0x0F or somesuch Nov 27 21:21:08 there is a huge diff for FPU intense function calls Nov 27 21:21:24 some 20% iirc Nov 27 21:21:35 but no difference for most of the system Nov 27 21:21:47 yeah, probably you need 30 instead 8 instructions for a complete FP op Nov 27 21:22:30 no 1000 instructions though Nov 27 21:22:44 like you'd need for software emulation Nov 27 21:22:50 it is not the instructions themselves, but the memory access Nov 27 21:22:58 :nod: Nov 27 21:24:29 I am not sure you can copy from integer reg to FPU reg directly, without going through memory, however, even if it is possible, it takes time Nov 27 21:24:38 and leads to pipeline stalls Nov 27 21:25:48 I'd give ballpark estimations of "soft":1000; "softfp":1000 or 30 (depending if hw accel available);"hard" (only when available): 8 Nov 27 21:25:49 CatButts: the last ~20 lines is a kind of an answer to your question Nov 27 21:25:54 whatever time unit Nov 27 21:26:32 according to you it's rather "soft":1000; "softfp":1000 or 12 (depending if hw accel available);"hard" (only when available): 10 Nov 27 21:26:35 DocScrutinizer05: well, keep in mind that for bug FP functions penalty is relatively small comapred to function execution time Nov 27 21:26:43 *big Nov 27 21:26:48 so it's a tad bit slowe, but no tragedy Nov 27 21:26:50 r Nov 27 21:26:56 yes Nov 27 21:27:09 even with intensive float calculations? Nov 27 21:27:37 float calculations themselves are not affected Nov 27 21:27:43 that's *only* looking at the float instructions Nov 27 21:27:46 just the function calls Nov 27 21:28:11 the rest of the system doesn't care what your float does Nov 27 21:28:38 a program that doesn't use floats will not run any fatser on a hardfp system, Nov 27 21:28:46 correct Nov 27 21:29:28 CatButts: so yes, *only* "with intensive float calculations" (100% intensity) Nov 27 21:32:19 * DocScrutinizer05 idly wonders if you could wrap the softfp functions with an IRQ-lock and save all FP registers and restore them before leavinbg the softfp function, so hardfp and softfp code could coexist Nov 27 21:33:07 sucks big time, but would make coexistence possible Nov 27 21:33:55 * CatButts plays with cubic interpolation and manages to turn it into ear-raping noise Nov 27 21:34:41 wait, wouldn't an IRQ either not touch FP registers at all, or (in case it's the schedukler) save the FP registers as well and restore them for the newly scheduled process? Nov 27 21:35:57 so except for shared libs, is there *anything* that comflicts between softfp-processes and hard(fp)-processes? Nov 27 21:37:03 and even for shared libs, would the ABI change for soft/hard? Nov 27 21:37:51 freemangordon: ^^^ Nov 27 21:38:53 there is nothing that conflicts Nov 27 21:38:57 HAHAH >>FPU instructions could be emulated by the kernel so that FPU-less systems could run with this ABI but as far as we know this does not exist<< Nov 27 21:39:23 not exactly true iirc, there are "some" instructions emulated in the kernel Nov 27 21:39:42 ooh, this direction of "not true" :-D Nov 27 21:40:18 oooh, "pipeline stalls" Nov 27 21:40:20 hmmm Nov 27 21:40:26 iirc, some vfpv3 instructions are emulated if hw is vfpv2 Nov 27 21:41:00 but don;t quote me on that one, it was a while I looked at kernel FP support code Nov 27 21:50:01 CatButts: (at runtime) I stand corrected: >>The GCC -mfloat-abi=softfp flag allows use of VFP while remaining compatible with soft-float code. This allows selection of appropriate routines at runtime based on the availability of VFP hardware.<< Nov 27 21:51:38 >>The runtime linker, ld.so, supports a mechanism for selecting runtime libraries based on features reported by the kernel. For instance, it's possible to provide two versions of libm, one in /lib and another one in /lib/vfp, and ld.so will select the /lib/vfp one on systems with VFP.<< Nov 27 21:53:19 BUT... >>...the ARM EABI and ELF specification has no way to tell which of soft, softfp, hard is used to build it<< Nov 27 21:56:42 HMMPH >>This needs to be looked into.. is it only a part of the version 5 EABI and not implemented? Could there possibly be scope for a GNU EABI extension for this, or a fix for the linker?<< Nov 27 22:08:53 (( there is nothing that conflicts)) so you could run softfp programs on a hardfp platform/system, provided there are all necessary "softfp" lib.so available? Nov 27 22:10:09 s/programs/binaries/ Nov 27 22:10:09 DocScrutinizer05 meant: (( there is nothing that conflicts)) so you could run softfp binaries on a hardfp platform/system, provided there are all necessary "softfp" lib.so available? Nov 27 22:13:40 hmm, isn't that already answered by >>...but dynamic linking of an executable to a library will not know that it is a bad idea to link a softfp libc or libm to a hardfp executable and vice-versa.<< **** ENDING LOGGING AT Tue Nov 28 03:00:01 2017