#qi-hardware IRC log for Wednesday, 2013-01-30

wpwrakif you want to outdo C++, you'll probably have to make it at least 4-5 passes. if they're already at two, they'll certainly add another one in C++14 or whenever the next abomination is due01:44
wpwraka radically different approach would be just recording the error but proceeding, then handling it when all is done01:46
wpwrakif that doesn't work, you don't seem to have much hope, though, if your language has destructors01:46
wpwrak(C's longjmp is kinda nice in terms of efficiency. but of course, it has its own set of issues.)01:47
whitequarkwpwrak: oh, you don't know yet01:47
whitequarklongjmp unwinds the stack too01:47
wpwrakin C, it just sets the stack :)01:48
whitequarkmy language doesn't have RAII, because it doesn't make sense01:48
whitequarkit has closures. wanna free some resource, use a closure and `ensure' (ie finally)01:48
whitequark(well, technically I have finalizers, but they're more a special case than a common pattern)01:49
whitequarkall this decreases the amount of cruft to do quite a bit.01:49
whitequarkmutexes, similarly: @mutex.synchronize { do_your_work_here }01:49
wpwrakyour problem is that you have implicit dynamic allocation. that's where all the messiness comes from.01:49
whitequarkwpwrak: to begin with, I also have a concurrent, lock-free heap01:50
whitequarkwhich means that I never do cli;alloc;sti.01:50
wpwrakin embedded, you rarely need such things. you may still keep them at a semantic level, but you may want to try to come up with usage rules that allow the compiler to always de-dynamize them.01:50
whitequarkyou are right here indeed; most of the dynamic allocations will be resolved to stack ones at compile-time.01:51
whitequarkso this is exactly what I do01:51
wpwraknow just change "most" to "all" :)01:51
whitequarkoh I'd be happy to. currently I see two places where it's hard.01:52
whitequarkfirst, strings, and to a lesser extent arrays01:52
whitequarkwell, hm01:53
whitequarkactually no, I can predict at compile-time what the maximal length for, e.g. a %d substitution will be01:53
wpwrakmaybe have something along the lines of global variables that are only conditionally visible. then "enable" them dynamically.01:54
whitequarkthis is kind of how I'll do the exceptions01:54
wpwrakif the call chains of paths that enable them could cross, it's an error01:54
whitequarkbecause allocating exceptions on stack is not an option01:54
whitequarkwpwrak: (call chains) this is theoretically possible, but a) requires an exponentially bounded analysis b) is way too hard to debug when it goes wrong01:55
whitequarkI avoid such stuff :)01:55
wpwrakin C, you do of course have a means to do such things (through unions), but the compiler won't check it for you01:55
whitequarkI do have union types, through for reasons unrelated01:56
wpwrakand the next step, making it possible to let such pseudo-dynamic allocations live on for a while would even be more difficult01:56
whitequarkI'd say it is Turing-undecidable in the general case01:56
wpwrakof course01:57
wpwrakbut the compiler could still detect clearly correct, clearly incorrect, and dubious cases01:57
wpwrakmaybe it's best to think in terms of usage scenarios01:58
whitequarkwpwrak: the problem is what should the programmer do when (not if) the compiler does not what she wants.01:58
whitequarkthis is something I consider first before adding any feature01:58
whitequark*does not do01:58
wpwrakfor example, i ran into this with my "antorcha". it has several relatively complex subsystems that each handle message sequences01:59
wpwrakso the message dispatcher calls X1, X2, etc., where X1 initializes some resource, then X2 and so on use it, but if an Y1 would arrive, the resource would have to be taken away02:00
wpwraki didn't really implement such a scheme, though. so most of it is individual allocation (of static items or stack), with a small number of manually managed shared things02:00
wpwrakmaybe you could structure the language such that only things the compiler can handle can be expressed02:01
whitequarkthis is not quite a good way to make a systems programming language :)02:02
whitequarklet me make a small overview of different allocation cases.02:02
wpwrakdepends. as long as you don't exclude things people actually need, why not ?02:02
whitequarkfirst, I of course do not have boxed objects. The memory layout of an object is just its fields and alignment, plus maybe a pointer to vtable if it can have virtual dispatch.02:03
whitequarkscalars are scalars. Int64 is a 64-bit machine int and nothing else to stay in the way.02:03
wpwrakit may also help to exclude linking at the beginning. assume the compiler sees the entire source, libraries included. that way, it can keep as much information as it wants02:04
wpwrakin embedded, many programs are small enough that a modern PC can handle this anyway02:04
whitequarkalmost everything (to be precise, everything except scalars) is passed by reference; there are no "copy constructors" or "move semantics"02:04
whitequarkwpwrak: (entire source) of course, ruby kind of forces this. also LTO is mandatory. don't underestimate modern PCs; webkit links for 8 hours @ modern i7 and gigabytes of RAM with LTO, but it builds.02:05
wpwrak;-))02:05
wpwrakseems there's still some room for improvement :)02:06
whitequarkso, each time I allocate something non-scalar, I have to consider allocating it either on stack or on heap.02:06
whitequarkI already perform bidirectional dataflow analysis for unrelated reasons, so checking if a value escapes its scope is almost trivial02:06
wpwrakor static (allocation)02:06
whitequark(not quite trivial with virtual calls, but still manageable)02:07
wpwrakheap is dangerous. heap is basically static allocation where you don't know what you're actually doing.02:07
whitequarkkind of. if you want static allocation, just allocate a value globally02:07
whitequarkand capture the reference somewhere.02:08
whitequarka constant probably.02:08
wpwrakwhat i mean is that, in order to avoid bad surprises, the compiler should always be able to reduce things to static allocation02:08
wpwrakwith the option of overlapping allocations, of course02:08
whitequarkwait a bit :)02:08
wpwrakalso stack allocation should be bounded for the same reason02:08
whitequarkthere are generally two kinds of allocations; first, there are objects.02:09
whitequarkobjects have a fixed size, which is known at compile time.02:09
whitequarksecond, there are buffers, which these objects allocate. buffer size can be either known or unknown at compile time.02:09
whitequarkallocating an unbounded buffer on stack is so bad I think it should be simply forbidden02:10
whitequarkbounded buffers can sometimes be allocated on stack or statically.02:10
wpwrakwell, if your embedded system has a nice way of handling an out of memory condition ... ;-)02:10
whitequarknow, there's one case which C++ doesn't play quite well02:11
whitequarkwhat if I try to return an aggregate?02:11
wpwrakyou could still have global variables that need stack allocation. then figure out the maximum stack size via call chain analysis.02:11
wpwrakdisallow recursive functions ;-)02:11
whitequarknon-tail-recursive functions, but yes, of course there'll be such an option02:12
wpwrakaggregates are scalars :)02:12
whitequarkafaik it is a general guideline in embedded anyway :)02:12
whitequarkglobal vars that need stack allocation -- not sure here02:12
whitequarkwhy would globals need stack allocation?02:12
wpwrakbecause part of the code may use global A and another part may use global B. but if the life time of A ends before B is used and vice versa, you can share the memory02:13
whitequarkI guess in this case you could simply allocate it as a local?02:14
whitequarkor a part of a local02:15
whitequarkthat would be clear from the source itself and easily controllable02:15
whitequarkeg pack your work into classes WorkA and WorkB. then from the dispatcher, WorkA.new.work or WorkB.new.work02:16
whitequarkand the memory would be shared implicitly via the stack; also the compiler will statically check for stack overflows for you in this case.02:16
wpwrakthe domain of A and the domain of B may have a common ancestor (in the call chain)02:16
wpwraklike in my networking example02:16
wpwrakof course, you could disallow that way of expressing my example02:17
wpwrakbut then you have to deal with several instances of the message dispatcher02:17
whitequarkif they simply have a common ancestor in the call chain, that's not a problem02:18
whitequarkif they intersect, they is02:18
whitequark*that is02:18
wpwrakthey intersect in the ancestor as far as locals are concerned02:18
whitequarkahh02:19
wpwrakso you'd need a away to tell the ancestor that this apparent intersection in fact isn't an intersection02:19
whitequarkDFA has no problems figuring out this :)02:19
wpwrak... and make sure that is enforced :)02:19
whitequarkyou mean this case? http://pastie.org/595238002:20
whitequarkso the domains would intersect in a 'temporary local'?02:20
wpwraklet there be several foo messages. foo1, foo2, foo302:20
wpwrakall begin with foo1. then you can have foo* for as long as you wish. but if you have a bar, then you need to do a foo1 or it's an error02:21
whitequarkso it's an FSM?02:21
wpwrakso foo1 creates the potentially large context (and of course, foo1 may in turn be a set of messages)02:22
wpwrakwell, everything is an FSM ;-)02:22
whitequarkheh02:22
whitequarkI don't quite get the nesting in your example02:22
whitequarkmaybe a snippet would be a better explanation?02:22
whitequarkpseudocode, whatever02:22
wpwrakwell, i have code but that may be too convoluted to help: http://projects.qi-hardware.com/index.php/p/antorcha/source/tree/master/fw/dispatch.c and http://projects.qi-hardware.com/index.php/p/antorcha/source/tree/master/fw/dispatch.h for the packet handlers02:24
wpwrakhere's no "clean" resource management there02:24
wpwrakthat protocol has several "modes". you enter a mode, e.g., an image upload, with a start message, then a number of image-specific messages, and you eventually exit it (be it by success, failure, or a switch to another mode)02:26
wpwrakinstead of the image mode, you make have a continuous measurement mode (there's an acceleration sensor in the system)02:26
whitequarkyup, got it02:26
wpwrakand there are more modes02:26
whitequarkneat design btw02:27
wpwraksome of them set up secret keys for authentication. (the "crypto" there is all fake but in theory you could make it work better)02:27
wpwrakthanks :)02:27
wpwrakthose crypto keys are expensive in relation to total memory of that chip. and so are the network buffers.02:28
whitequarkbuf[1] is sequence number?02:29
wpwrakwell, crypto contexts. the keys actually aren't so bad. but checking them is.02:29
wpwrakyes: http://projects.qi-hardware.com/index.php/p/antorcha/source/tree/master/doc/PROTOCOL02:29
wpwrak(payload sizes are per packet. an image would have multiple packets.)02:31
wpwrakthe underlying crypto concept are shared secret keys. then you send a hash of key+salt+data02:32
wpwrakof course, the actual hash function is everything but secure ;-)02:33
wpwraki'm not even sure i would have enough space in that chip for it. but this is an obsolete design anyway. the designated successor will abandon AVR for ARM cortex. still constrained, though. just not as badly.02:34
whitequarkyou would have a chance to use Foundry ;)02:34
wpwrakfoundry .. make my own arm chips ?02:36
whitequarkmeh. no, that's the name of my compiler02:37
wpwrakah :)02:37
whitequarkhttp://foundry-lang.org/ etc.02:37
wpwraknaw, in C i trust :)02:37
wpwrak;-))02:37
whitequarkbtw how are you going to flash the firmware if it doesn't fit in RAM?02:38
whitequarkor rather, how are you going to verify it prior to flashing?02:38
whitequarkkey word is prior :)02:38
wpwraki have a separate boot loader. and i can't verify.02:38
wpwrakwell, maybe i could. but that would be over-engineering :)02:39
whitequarkI think that CBC is what you effectively want02:39
whitequarkbut that'd require some crypto magic02:39
wpwraki think i sized things for md5 or sha102:39
whitequarkyou could append sha1 after each block and extend it with the next one02:40
whitequarksha1 is Merkle-Damgard chainable02:40
wpwraknot meant to be super-hard. just discourage any bastards from trying anything02:40
wpwraknaw, i have an "unlock" step and then a content verification.02:41
whitequarkyeah, would work too02:41
whitequarkunlock, that is02:41
wpwrakthat's of course not bullet-proof, but the idea is that one would never send the unlock in an unsafe environment02:41
wpwrakor, rather, hostile environment02:42
whitequarkI don't quite get why you need content verification, or how would you prevent malicious code to be flashed even partially02:42
wpwrakso you have "safe" (which doesn't exist), "unsafe" (you trust but you also check), and "hostile" (you assume that you will be attacked)02:42
whitequarkthat sounds rather silly to me, to be sincere02:43
whitequarkyou either protect yourself from attacks, or not02:43
whitequarkthere is no half-way security.02:43
wpwrakof course, the enemy would first have to figure out there's something worth attacking :)02:43
wpwraknaw, it's a matter of procedure02:43
whitequarkgiven that you don't need encryption but only authentication, you can trivially chain sha102:44
whitequarkover a known secret and all the following firmware blocks02:44
wpwrakin "hostile", you don't do an unlock. in "unsafe", you do. but you may end up with a denial of service if an enemy sneaks in at the right moment.02:44
whitequarkyou don't need unlock with chained sha102:44
wpwrak(chain) yes, that's the idea02:44
whitequarkat all02:44
wpwraki don't have storage for a tentative copy02:45
whitequarksee, you don't _end_ the transmission with salt and then verify02:45
whitequarkyou first hash a known secret, then append firmware blocks to that hash02:45
whitequarkif a particular hash compares equal, that means that every previous one was good as well.02:46
whitequark*shared secret.02:46
whitequarkthat's the whole point of Merkle-Damgard02:46
wpwrakyes, i could send a hash after each block02:46
wpwrakbut then, the bad guys could just jam me, giving me the same sort of DoS ;-)02:47
whitequarksha1(a+b) is (omitting some details) sha1extend(sha1extend("", a), b)02:47
whitequarkso it is composable02:47
whitequarkwpwrak: (jamming) but you're not immune to it in any case02:47
whitequarkso it doesn't exactly matter02:47
wpwrakexactly. so i can't ensure transactional semantics, no matter what i do02:48
wpwraki.e., there's no rollback if things turn sour02:48
wpwrakbut yes, i could avoid the unlock02:48
wpwrakone key less to manage :)02:48
whitequarkand more clear crypto.02:48
wpwrakyeah, fewer states02:49
wpwrakbut as i said, the "crypto" in this implementation sucks. it's pretty much a foul compromise that acknowledges that "secret" keys can be compromised. (due to implementation restrictions)02:51
wpwrakso it's more security theater than anything properly done02:51
whitequarkwell, you can disable flash reading, no?02:52
whitequarkwon't make a problem for someone with an UV and some black duct tape, though02:52
wpwrakoh, i assume i have control of the device at all times02:52
whitequarkthen how could the keys be compromised?02:52
wpwraksince i don't have proper crypto in place, they're pretty much sent over the air :)02:53
whitequarkahhh02:53
whitequarkadd something lightweight02:53
whitequarkRijndael?02:53
whitequarkaka AES02:53
whitequarkthis would fit very nicely in that chained scheme02:53
wpwrakbut this still needs 1) the enemy to even be aware of me, 2) care, 3) find a way to be RF-compatible, 4) implement the protocol02:53
whitequarkthat is basically how AES is generally authenticated 02:53
whitequarkwell, yeah02:53
wpwraki designed for SHA1, which is pretty much the most light-weight without being silly02:55
wpwrakbut anyway, this design isn't going anywhere. the next one will have different parameters. even RF will be optional there.02:56
wpwraki.e., a little uSD card goes a long way ;-)02:56
whitequarkwpwrak: well, what I'd do with that code is simply factor out the nested message parsing loops to, well, nested loops02:58
whitequarkwould solve everything *and* make it more clear :)02:58
wpwrakyou mean get rid of the protocol handlers ? yes, that would work. less modular, though.02:59
whitequarkno, why do that?02:59
wpwrakto help the compiler :)02:59
whitequarkok, I'll just open my editor...02:59
wpwrakthe infinite jukebox works really well, 05:20 and counting :) (still bug powder dust)03:01
wpwrakthe only things missing are some female vocals and something like the "I can and shall obey" of "blue monday"03:04
whitequarkwpwrak: I guess this is pretty close: http://pastie.org/595309503:24
whitequarkline 52 should be: class FirmwareFlashHandler < Handler03:25
wpwrakyes, but you lose the central event loop this way. so that would have to be restructured as well.03:29
wpwraknot impossible, though03:29
whitequarkwpwrak: you can restructure this code as well03:30
whitequarkin numerous ways. closures and lightweight coroutines would work here, with coroutines being probably the best option03:31
wpwrakthe limitation is that you need to be able to call the message getter instead of being called by the message getter03:31
wpwrakand you need this to be able to "own" the mode-specific state03:32
wpwrakyou could have objects with mutually exclusive lifetimes instead, but then you'd need a way to communicate that to the compiler03:33
wpwrak(that is, unless it can figure it out by execution flow analysis)03:33
whitequarkcompilers seldom analyze memory03:34
whitequarknonlocal memory, that is.03:34
wpwrakto make everything static in a language that is inherently dynamic, it has to analyze everything :)03:35
whitequarkhehe03:35
whitequarkwpwrak: well, there's a way03:38
whitequarkyou just wrap this in a Fiber.03:38
wpwrakfiber ?03:39
whitequarka coroutine.03:39
whitequarkin this particular case it won't be lightweight, but the maximal stack size is still known precisely03:39
wpwrakthen you need to ensure coroutines don't coexist03:39
whitequarknay03:39
whitequarkall of the stuff which cannot coexist is in *one* fiber03:39
whitequarkbut Message.get gets replaced by a Fiber.yield.03:39
whitequarkthen, event loop yields the message to the fiber when it's available.03:40
whitequarkyou can schedule concurrent tasks in a similar way, and still be sure that you'll fit into RAM03:41
whitequarkwell, basically this is a way of telling compilers which lifetimes can intersect and which ones cannot :)03:41
whitequark*compiler03:41
wpwrakthat seems to just add an unnecessary extra layer. isn't the code in your example already single-threaded ?03:42
whitequarkwpwrak: no, that's just rearranging exactly same code in a more structured way03:42
wpwrakhmm. i sense extra allocations :)03:43
whitequark*if* you need an external event loop, which means that an incoming message is not the only event03:43
whitequarkthen you probably need to handle another ones03:43
whitequarkextra allocations? nay03:43
whitequarkyou simply split the stacks03:44
whitequarkthe default Fiber has everything which was below `dispatch', the communication fiber has `dispatch' and everything above03:44
whitequarkthere's nothing inside a Fiber except its stack, so... :)03:44
whitequarkof course, if you don't need to process those other events, you can as well leave Message.get where it is03:45
whitequarkthe advantage of Fibers is that you don't need to refactor almost anything.03:45
wpwrakso you pass messages by reference between threads ?03:45
whitequarkcoroutines. they're not threads; they cannot execute in parallel03:45
whitequarkso, yes03:45
whitequarkcode with coroutines is directly equivalent to corresponding evented code03:47
whitequarkit's just another way of representing the same thing03:47
wpwraki see. yes, that may work. compiler still needs to be able to figure out how coroutines are nested, though03:49
whitequarkthat is trivial, given my bidiDFA and EA03:49
wpwrakso they're just like functions03:49
whitequarkfunctions which can return from a random point and return to that point, yeah03:50
whitequarkif you write it evented way, you have to track all that manually03:50
wpwrak(functions) i mean to the compiler03:51
whitequarkoh. no, of course. they're values.03:51
whitequarkfirst and foremost.03:51
whitequarkand I can trivially check if a value is only referenced in the main dispatch loop03:52
whitequarkbesides, it doesn't even matter if they call each other or not03:52
whitequarkcoroutine calls never grow the call stack03:52
whitequarkit *does* matter that you do not create them without bounds. but see above.03:53
wpwrakhmm yes, you'd have to track their life time, not whether they call each other03:55
whitequarkyup03:56
whitequarknote that if your call graph is a tree, you can allocate Fibers on stack03:57
whitequarkfiberception!03:57
whitequarkand specialization and aggressive constant propagation and inlining greatly simplifies the call graph, which also helps quite a bit03:59
whitequark*simplify03:59
wpwraknot too different from objects. common ancestor owns them, they call each other's methods.04:00
whitequarkyeah, kind of04:00
wpwrakwhere "owns" means "determines lifetime"04:00
whitequarkas I've said, it is a structured way to alter control flow04:00
whitequarkalso lightweight coroutines are an excellent tool for writing highly concurrent code04:02
whitequarkeg Hoare/Communicating Sequental Processes; what Go is based on.04:02
wpwrakyes, where you "call" to return and are "returned to" to be called04:02
whitequarkwpwrak: there's a thing called "continuation"04:02
wpwrakmaking the local state a little less clunky04:02
whitequarksimplified, a captured continuation represents all the computation which will happen *after* your method returns04:03
wpwrakyou can hide it all in message passing. as long as there's no buffer, you get the same semantics04:03
whitequarkhere, you basically capture exchange continuations between functions04:03
whitequarkyeah04:03
wpwrake.g., SPIN does that04:03
wpwrakwell, Promela (SPIN is the implementation)04:04
whitequarkyup, Prolema looks like it was modelled after CSP04:05
wpwrakah, you know it. good :) few enough people do04:05
wpwraklovely system. about the only way to get the bugs out of non-trivial protocols.04:06
whitequarkwpwrak: not exactly Promela, never seen it before. but I did look at enough CSP-related code04:06
whitequarkit's hardly the only example :)04:06
whitequarksee, there's something I do better than C ;)04:06
wpwrakheh, well the purpose of promela is to add non-determinism, so ... :)04:10
whitequarkoh 8AM04:12
whitequarkthis was sudden04:12
wpwrakthat sneaky sun ;-)04:12
whitequarksun?04:14
whitequarkwhat's that?04:14
whitequarkit'll be not until 10AM or maybe even 12AM that it'd begin to dawn04:15
wpwrakthe position of the evil day star is what commonly determines the day time, in some areas with +/- 1 h or similar04:15
wpwrakoh. what's why they called it the dark age :)04:15
whitequarkbesides, I've caught a cold and really need to sleep. so, bbl.04:16
wpwrakinteresting fever dreams then !04:16
whitequarkthanks:)04:16
DocScrutinizer05hey guys, anybody good with ssh(d)?08:48
DocScrutinizer05why can I log in with one local ssh setting while not with another to a machine where .ssh/ is 744? Why can same local ssh setting that refuses to log in to machine A with 744 nevertheless log in fine to another machine that also has .ssh/ = 744?08:50
DocScrutinizer05some *strict*-fu* I guess08:51
DocScrutinizer05and is there any friggin way to make ssh output meaningful diagnostics regarding all that? -vv doesn't help at all08:53
DocScrutinizer05ooh, i maybe should mention that ssh-agent is involved08:56
DocScrutinizer05to forward local private key to second hop: local->A->B08:57
mthI'd guess that the sshd on the machine you're logging in to would decide whether or not to reject that machine's ~/.ssh/ with 74409:10
lindi-wpwrak: spin is the closed source implementation, nips is the open source implementation09:40
DocScrutinizer05mth: depending on my *local* config the *remote* machine needs 700 .ssh/ (on remote) or not10:22
DocScrutinizer05and remote A rejects with 744 while remote B doesn't, with same local config10:24
mththat second line is what I expected, the first isn't10:33
mthmaybe both the server and the client check and only if both approve you can login?10:34
qwebirc83678Hi everyone! Anybody has recovered a "bricked" ATUSB ?12:03
qwebirc83678I have two ATUSBs and when I plug one it appears in the lspci and the other one not, so I suppose it is bricked or directly no correctly assembled12:04
qi-bot[commit] Werner Almesberger: prod/doc/figfilt: script to filter portions of a FIG file based on keys in comments (master) http://qi-hw.com/p/ben-wpan/5733b6013:23
qi-bot[commit] Werner Almesberger: prod/doc/Makefile: add missing dependencies on at{ben,usb}-{front,back}.png (master) http://qi-hw.com/p/ben-wpan/380012513:23
qi-bot[commit] Werner Almesberger: prod/doc/test.hmac: fix unterminated IMG tag (master) http://qi-hw.com/p/ben-wpan/ee870b513:23
whitequarkdamn, it's night again :S18:19
whitequarkwpwrak: you'll like this: I've just compiled a file, LLVM decided it's more clever than me and rewrote printf("foo\n"); to puts("foo");18:19
wpwraknice :)18:27
wpwrakcan it also figure out printf("%s\n", blah); ?18:28
whitequarkwpwrak: yeah18:31
whitequarkit has builtin knowledge of all of the C stdlib, including prototypes, printf/scanf format specifiers, and whatnot18:32
whitequarkconverts exit() in main() to return;18:33
whitequarkverifies that you didn't suddenly decided to overwrite a .rodata string18:34
whitequarketc etc18:34
whitequarkconverts loops to memset/memcpy18:34
whitequarkfigures out that in a loop like for(int i = 0; i < 10; i++) printf("18:36
whitequarkerr18:36
whitequarkfigures out that in a loop like for(int i = 0; i < 10; i++) printf("%d\n", ints[i]); it would be beneficial to convert the induction variable to be incremented by word size and begin at the `ints'18:36
whitequarkit is quite certainly more clever than me in a lot of cases.18:37
larsconly so long until the machines will take over ;)18:42
larscI think the last optimization is pretty standard though18:42
whitequarklarsc: I'm not sure gcc does it18:42
whitequarkLLVM in fact does it becaise autovectorizer needs it :)18:42
larscI would be scared if it didn't18:42
whitequarklarsc: I'm scared of GCC since I looked into its sources and seen lisp, c and asm in one file18:43
larscjust tried it: "add    $0x4,%rbx" and "cmp    $0x28,%rbx"18:45
whitequarkhm, LLVM is able to retain correct debug info through all optimizations, and it retains it at all for most of them19:26
whitequarkeg stacktraces include inlined functions19:27
whitequarkand it doesn't screw your mind with <value optimized out>.19:27
lindi-wpwrak: gcc also converts printf to puts19:27
lindi-wpwrak: llvm copied that idea from there :)19:27
whitequarklindi-: might be the other way around19:28
whitequarkgcc is now C++-compatible to allow for more easy incorporation of LLVM passes :)19:28
lindi-wpwrak: my impression is that gcc got it first, I fixed a bug in that part in llvm19:28
lindi-wpwrak: the optimization is incorrect if you use the return values of the printf in your program19:28
wpwrakheh :)19:32
larscwhitequark: yea, <value optimized out> is a major annoyance. but how does llvm make sure that this doesn't happen?20:11
whitequarklarsc: I guess just better tracking of values and better DWARF generation20:13
whitequarkas in, your value could be moved to register from memory, but DWARF can still handle it20:13
whitequarkor optimized to constant, but see above20:14
larscwhitequark: yeay, but if you have something like foo(int x) { int t = abs(x); ... } and the compiler decides to put x and t in the same register, how does it get to know x?20:24
whitequarklarsc: hm this is interesting20:27
whitequarkI should check this case20:27
larscanybody coming to fosdem?21:14
viricah21:20
viricI was about to ask that!21:20
viricI go.21:20
larsccool21:20
larscgoing to the beer event?21:20
viricuhm I haven't looked at the program :D21:44
viricI discovered only yesterday that I could go to it21:44
viricAh I see21:44
viricI arrive on saturday, 16:00!21:45
larscso you are going to miss the best part ;)21:45
viricyes, I imagine so21:47
viricBut my boss forbid me to move on friday21:47
larsc:/21:47
viricYes, because we promised to give support to one customer on full friday21:49
viricbut now the customer says that he won't be ready. A hell.21:49
viriclarsc: I'd be pleased to meet you at fosdem22:53
viricare you giving a talk?22:55
larscno, I decided to late that I'd come to fosdem.22:58
larscif you don't have any other plans we could maybe go for a beer on saturday evening22:58
viricI'm not sure I have other plans :)23:04
viricI plan to meet people23:04
wpwraklarsc: i approve of your priorities :)23:04
wpwrakviric: the best meetings are over some beers ;-)23:05
viricI don't oppose the beers! :)23:06
viricI just don't know if I may meet with 20 more people for beers23:06
viricit may be that I join the people around 'nix', maybe some around 'gnu'23:09
viricbut I don't want to miss larsc !23:09
viriclarsc: do other people from mipslinux come?23:09
larscI know that nbd will be there, haven't heard from anybody else23:12
viricok23:37
qi-bot[commit] Werner Almesberger: ubb-la/ubb-la.c: raise MMC bus clock to 84 MHz during overhead (master) http://qi-hw.com/p/ben-blinkenlights/bf62b2023:40
qi-bot[commit] Werner Almesberger: ubb-la/ubb-la. (xfers): re-optimize the start bit (master) http://qi-hw.com/p/ben-blinkenlights/3b007eb23:40
qi-bot[commit] Werner Almesberger: ubb-la/ubb-la.c (xfers): revert to "safe" end-of-command synchronization (master) http://qi-hw.com/p/ben-blinkenlights/760e8a823:40
qi-bot[commit] Werner Almesberger: ubb-la/ubb-la.c: add more section titles (master) http://qi-hw.com/p/ben-blinkenlights/b7688f323:40
qi-bot[commit] Werner Almesberger: ubb-la/gui.c: experimental GUI code (WIP) (master) http://qi-hw.com/p/ben-blinkenlights/94e099e23:40
qi-bot[commit] Werner Almesberger: ubb-la/gui.c: use powers of two for zoom and integer arithmetic (WIP) (master) http://qi-hw.com/p/ben-blinkenlights/1b0a2cf23:40
qi-bot[commit] Werner Almesberger: ubb-la/gui.c (gui): fix the event loop to properly ignore unrecognized events (master) http://qi-hw.com/p/ben-blinkenlights/12a180823:40
--- Thu Jan 31 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!