Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
Hoolxi has joined #qi-hardware
Hoolxi has quit [Remote host closed the connection]
megha has quit [Ping timeout: 264 seconds]
megha has joined #qi-hardware
rz2k has quit [Read error: Connection reset by peer]
<wpwrak>
if 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 due
<wpwrak>
a radically different approach would be just recording the error but proceeding, then handling it when all is done
<wpwrak>
if that doesn't work, you don't seem to have much hope, though, if your language has destructors
<wpwrak>
(C's longjmp is kinda nice in terms of efficiency. but of course, it has its own set of issues.)
<whitequark>
wpwrak: oh, you don't know yet
<whitequark>
longjmp unwinds the stack too
<wpwrak>
in C, it just sets the stack :)
<whitequark>
my language doesn't have RAII, because it doesn't make sense
<whitequark>
it has closures. wanna free some resource, use a closure and `ensure' (ie finally)
<whitequark>
(well, technically I have finalizers, but they're more a special case than a common pattern)
<whitequark>
all this decreases the amount of cruft to do quite a bit.
<wpwrak>
your problem is that you have implicit dynamic allocation. that's where all the messiness comes from.
<whitequark>
wpwrak: to begin with, I also have a concurrent, lock-free heap
<whitequark>
which means that I never do cli;alloc;sti.
<wpwrak>
in 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.
<whitequark>
you are right here indeed; most of the dynamic allocations will be resolved to stack ones at compile-time.
<whitequark>
so this is exactly what I do
<wpwrak>
now just change "most" to "all" :)
<whitequark>
oh I'd be happy to. currently I see two places where it's hard.
<whitequark>
first, strings, and to a lesser extent arrays
<whitequark>
well, hm
<whitequark>
actually no, I can predict at compile-time what the maximal length for, e.g. a %d substitution will be
<wpwrak>
maybe have something along the lines of global variables that are only conditionally visible. then "enable" them dynamically.
emeb has quit [Quit: Leaving.]
<whitequark>
this is kind of how I'll do the exceptions
<wpwrak>
if the call chains of paths that enable them could cross, it's an error
<whitequark>
because allocating exceptions on stack is not an option
<whitequark>
wpwrak: (call chains) this is theoretically possible, but a) requires an exponentially bounded analysis b) is way too hard to debug when it goes wrong
<whitequark>
I avoid such stuff :)
<wpwrak>
in C, you do of course have a means to do such things (through unions), but the compiler won't check it for you
<whitequark>
I do have union types, through for reasons unrelated
<wpwrak>
and the next step, making it possible to let such pseudo-dynamic allocations live on for a while would even be more difficult
<whitequark>
I'd say it is Turing-undecidable in the general case
<wpwrak>
of course
<wpwrak>
but the compiler could still detect clearly correct, clearly incorrect, and dubious cases
<wpwrak>
maybe it's best to think in terms of usage scenarios
<whitequark>
wpwrak: the problem is what should the programmer do when (not if) the compiler does not what she wants.
<whitequark>
this is something I consider first before adding any feature
<whitequark>
*does not do
<wpwrak>
for example, i ran into this with my "antorcha". it has several relatively complex subsystems that each handle message sequences
<wpwrak>
so 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 away
<wpwrak>
i 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 things
<wpwrak>
maybe you could structure the language such that only things the compiler can handle can be expressed
<whitequark>
this is not quite a good way to make a systems programming language :)
<whitequark>
let me make a small overview of different allocation cases.
<wpwrak>
depends. as long as you don't exclude things people actually need, why not ?
<whitequark>
first, 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.
<whitequark>
scalars are scalars. Int64 is a 64-bit machine int and nothing else to stay in the way.
<wpwrak>
it 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 wants
<wpwrak>
in embedded, many programs are small enough that a modern PC can handle this anyway
<whitequark>
almost everything (to be precise, everything except scalars) is passed by reference; there are no "copy constructors" or "move semantics"
<whitequark>
wpwrak: (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.
<wpwrak>
;-))
<wpwrak>
seems there's still some room for improvement :)
<whitequark>
so, each time I allocate something non-scalar, I have to consider allocating it either on stack or on heap.
<whitequark>
I already perform bidirectional dataflow analysis for unrelated reasons, so checking if a value escapes its scope is almost trivial
<wpwrak>
or static (allocation)
<whitequark>
(not quite trivial with virtual calls, but still manageable)
<wpwrak>
heap is dangerous. heap is basically static allocation where you don't know what you're actually doing.
<whitequark>
kind of. if you want static allocation, just allocate a value globally
<whitequark>
and capture the reference somewhere.
<whitequark>
a constant probably.
<wpwrak>
what i mean is that, in order to avoid bad surprises, the compiler should always be able to reduce things to static allocation
<wpwrak>
with the option of overlapping allocations, of course
<whitequark>
wait a bit :)
<wpwrak>
also stack allocation should be bounded for the same reason
<whitequark>
there are generally two kinds of allocations; first, there are objects.
<whitequark>
objects have a fixed size, which is known at compile time.
<whitequark>
second, there are buffers, which these objects allocate. buffer size can be either known or unknown at compile time.
<whitequark>
allocating an unbounded buffer on stack is so bad I think it should be simply forbidden
<whitequark>
bounded buffers can sometimes be allocated on stack or statically.
<wpwrak>
well, if your embedded system has a nice way of handling an out of memory condition ... ;-)
<whitequark>
now, there's one case which C++ doesn't play quite well
<whitequark>
what if I try to return an aggregate?
<wpwrak>
you could still have global variables that need stack allocation. then figure out the maximum stack size via call chain analysis.
<wpwrak>
disallow recursive functions ;-)
<whitequark>
non-tail-recursive functions, but yes, of course there'll be such an option
<wpwrak>
aggregates are scalars :)
<whitequark>
afaik it is a general guideline in embedded anyway :)
valhalla has quit [Ping timeout: 276 seconds]
<whitequark>
global vars that need stack allocation -- not sure here
<whitequark>
why would globals need stack allocation?
<wpwrak>
because 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 memory
<whitequark>
I guess in this case you could simply allocate it as a local?
<whitequark>
or a part of a local
<whitequark>
that would be clear from the source itself and easily controllable
<whitequark>
eg pack your work into classes WorkA and WorkB. then from the dispatcher, WorkA.new.work or WorkB.new.work
<whitequark>
and the memory would be shared implicitly via the stack; also the compiler will statically check for stack overflows for you in this case.
<wpwrak>
the domain of A and the domain of B may have a common ancestor (in the call chain)
<wpwrak>
like in my networking example
<wpwrak>
of course, you could disallow that way of expressing my example
<wpwrak>
but then you have to deal with several instances of the message dispatcher
<whitequark>
if they simply have a common ancestor in the call chain, that's not a problem
<whitequark>
if they intersect, they is
<whitequark>
*that is
<wpwrak>
they intersect in the ancestor as far as locals are concerned
<whitequark>
ahh
<wpwrak>
so you'd need a away to tell the ancestor that this apparent intersection in fact isn't an intersection
<whitequark>
DFA has no problems figuring out this :)
<wpwrak>
here's no "clean" resource management there
<wpwrak>
that 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)
<wpwrak>
instead of the image mode, you make have a continuous measurement mode (there's an acceleration sensor in the system)
<whitequark>
yup, got it
<wpwrak>
and there are more modes
<whitequark>
neat design btw
<wpwrak>
some of them set up secret keys for authentication. (the "crypto" there is all fake but in theory you could make it work better)
<wpwrak>
thanks :)
<wpwrak>
those crypto keys are expensive in relation to total memory of that chip. and so are the network buffers.
<whitequark>
buf[1] is sequence number?
<wpwrak>
well, crypto contexts. the keys actually aren't so bad. but checking them is.
<wpwrak>
(payload sizes are per packet. an image would have multiple packets.)
<wpwrak>
the underlying crypto concept are shared secret keys. then you send a hash of key+salt+data
<wpwrak>
of course, the actual hash function is everything but secure ;-)
<wpwrak>
i'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.
<whitequark>
you would have a chance to use Foundry ;)
<wpwrak>
foundry .. make my own arm chips ?
<whitequark>
meh. no, that's the name of my compiler
<whitequark>
btw how are you going to flash the firmware if it doesn't fit in RAM?
<whitequark>
or rather, how are you going to verify it prior to flashing?
<whitequark>
key word is prior :)
<wpwrak>
i have a separate boot loader. and i can't verify.
<wpwrak>
well, maybe i could. but that would be over-engineering :)
<whitequark>
I think that CBC is what you effectively want
<whitequark>
but that'd require some crypto magic
<wpwrak>
i think i sized things for md5 or sha1
<whitequark>
you could append sha1 after each block and extend it with the next one
<whitequark>
sha1 is Merkle-Damgard chainable
<wpwrak>
not meant to be super-hard. just discourage any bastards from trying anything
<wpwrak>
naw, i have an "unlock" step and then a content verification.
<whitequark>
yeah, would work too
<whitequark>
unlock, that is
<wpwrak>
that's of course not bullet-proof, but the idea is that one would never send the unlock in an unsafe environment
<wpwrak>
or, rather, hostile environment
<whitequark>
I don't quite get why you need content verification, or how would you prevent malicious code to be flashed even partially
wolfspraul has quit [Quit: leaving]
wolfspraul has joined #qi-hardware
<wpwrak>
so you have "safe" (which doesn't exist), "unsafe" (you trust but you also check), and "hostile" (you assume that you will be attacked)
<whitequark>
that sounds rather silly to me, to be sincere
<whitequark>
you either protect yourself from attacks, or not
<whitequark>
there is no half-way security.
<wpwrak>
of course, the enemy would first have to figure out there's something worth attacking :)
<wpwrak>
naw, it's a matter of procedure
<whitequark>
given that you don't need encryption but only authentication, you can trivially chain sha1
<whitequark>
over a known secret and all the following firmware blocks
<wpwrak>
in "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.
<whitequark>
you don't need unlock with chained sha1
<wpwrak>
(chain) yes, that's the idea
<whitequark>
at all
<wpwrak>
i don't have storage for a tentative copy
<whitequark>
see, you don't _end_ the transmission with salt and then verify
<whitequark>
you first hash a known secret, then append firmware blocks to that hash
<whitequark>
if a particular hash compares equal, that means that every previous one was good as well.
<whitequark>
*shared secret.
<whitequark>
that's the whole point of Merkle-Damgard
<wpwrak>
yes, i could send a hash after each block
<wpwrak>
but then, the bad guys could just jam me, giving me the same sort of DoS ;-)
<whitequark>
sha1(a+b) is (omitting some details) sha1extend(sha1extend("", a), b)
<whitequark>
so it is composable
<whitequark>
wpwrak: (jamming) but you're not immune to it in any case
<whitequark>
so it doesn't exactly matter
<wpwrak>
exactly. so i can't ensure transactional semantics, no matter what i do
<wpwrak>
i.e., there's no rollback if things turn sour
<wpwrak>
but yes, i could avoid the unlock
<wpwrak>
one key less to manage :)
<whitequark>
and more clear crypto.
<wpwrak>
yeah, fewer states
<wpwrak>
but 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)
<wpwrak>
so it's more security theater than anything properly done
<whitequark>
well, you can disable flash reading, no?
<whitequark>
won't make a problem for someone with an UV and some black duct tape, though
<wpwrak>
oh, i assume i have control of the device at all times
<whitequark>
then how could the keys be compromised?
<wpwrak>
since i don't have proper crypto in place, they're pretty much sent over the air :)
<whitequark>
ahhh
<whitequark>
add something lightweight
<whitequark>
Rijndael?
<whitequark>
aka AES
<whitequark>
this would fit very nicely in that chained scheme
<wpwrak>
but 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 protocol
<whitequark>
that is basically how AES is generally authenticated
<whitequark>
well, yeah
<wpwrak>
i designed for SHA1, which is pretty much the most light-weight without being silly
<wpwrak>
but anyway, this design isn't going anywhere. the next one will have different parameters. even RF will be optional there.
<wpwrak>
i.e., a little uSD card goes a long way ;-)
<whitequark>
wpwrak: well, what I'd do with that code is simply factor out the nested message parsing loops to, well, nested loops
<whitequark>
would solve everything *and* make it more clear :)
<wpwrak>
you mean get rid of the protocol handlers ? yes, that would work. less modular, though.
<whitequark>
no, why do that?
<wpwrak>
to help the compiler :)
<whitequark>
ok, I'll just open my editor...
megha has quit [Quit: WeeChat 0.4.0]
<wpwrak>
the infinite jukebox works really well, 05:20 and counting :) (still bug powder dust)
xiangfu has joined #qi-hardware
<wpwrak>
the only things missing are some female vocals and something like the "I can and shall obey" of "blue monday"
<whitequark>
line 52 should be: class FirmwareFlashHandler < Handler
<wpwrak>
yes, but you lose the central event loop this way. so that would have to be restructured as well.
<wpwrak>
not impossible, though
<whitequark>
wpwrak: you can restructure this code as well
<whitequark>
in numerous ways. closures and lightweight coroutines would work here, with coroutines being probably the best option
<wpwrak>
the limitation is that you need to be able to call the message getter instead of being called by the message getter
<wpwrak>
and you need this to be able to "own" the mode-specific state
<wpwrak>
you could have objects with mutually exclusive lifetimes instead, but then you'd need a way to communicate that to the compiler
<wpwrak>
(that is, unless it can figure it out by execution flow analysis)
<whitequark>
compilers seldom analyze memory
<whitequark>
nonlocal memory, that is.
<wpwrak>
to make everything static in a language that is inherently dynamic, it has to analyze everything :)
<whitequark>
hehe
<whitequark>
wpwrak: well, there's a way
<whitequark>
you just wrap this in a Fiber.
<wpwrak>
fiber ?
<whitequark>
a coroutine.
<whitequark>
in this particular case it won't be lightweight, but the maximal stack size is still known precisely
<wpwrak>
then you need to ensure coroutines don't coexist
<whitequark>
nay
<whitequark>
all of the stuff which cannot coexist is in *one* fiber
<whitequark>
but Message.get gets replaced by a Fiber.yield.
<whitequark>
then, event loop yields the message to the fiber when it's available.
<whitequark>
you can schedule concurrent tasks in a similar way, and still be sure that you'll fit into RAM
<whitequark>
well, basically this is a way of telling compilers which lifetimes can intersect and which ones cannot :)
<whitequark>
*compiler
<wpwrak>
that seems to just add an unnecessary extra layer. isn't the code in your example already single-threaded ?
<whitequark>
wpwrak: no, that's just rearranging exactly same code in a more structured way
<wpwrak>
hmm. i sense extra allocations :)
<whitequark>
*if* you need an external event loop, which means that an incoming message is not the only event
<whitequark>
then you probably need to handle another ones
<whitequark>
extra allocations? nay
<whitequark>
you simply split the stacks
<whitequark>
the default Fiber has everything which was below `dispatch', the communication fiber has `dispatch' and everything above
<whitequark>
there's nothing inside a Fiber except its stack, so... :)
<whitequark>
of course, if you don't need to process those other events, you can as well leave Message.get where it is
<whitequark>
the advantage of Fibers is that you don't need to refactor almost anything.
<wpwrak>
so you pass messages by reference between threads ?
<whitequark>
coroutines. they're not threads; they cannot execute in parallel
<whitequark>
so, yes
<whitequark>
code with coroutines is directly equivalent to corresponding evented code
<whitequark>
it's just another way of representing the same thing
<wpwrak>
i see. yes, that may work. compiler still needs to be able to figure out how coroutines are nested, though
<whitequark>
that is trivial, given my bidiDFA and EA
<wpwrak>
so they're just like functions
<whitequark>
functions which can return from a random point and return to that point, yeah
<whitequark>
if you write it evented way, you have to track all that manually
<wpwrak>
(functions) i mean to the compiler
<whitequark>
oh. no, of course. they're values.
<whitequark>
first and foremost.
<whitequark>
and I can trivially check if a value is only referenced in the main dispatch loop
<whitequark>
besides, it doesn't even matter if they call each other or not
<whitequark>
coroutine calls never grow the call stack
<whitequark>
it *does* matter that you do not create them without bounds. but see above.
<wpwrak>
hmm yes, you'd have to track their life time, not whether they call each other
<whitequark>
yup
<whitequark>
note that if your call graph is a tree, you can allocate Fibers on stack
<whitequark>
fiberception!
<whitequark>
and specialization and aggressive constant propagation and inlining greatly simplifies the call graph, which also helps quite a bit
<whitequark>
*simplify
<wpwrak>
not too different from objects. common ancestor owns them, they call each other's methods.
<whitequark>
yeah, kind of
<wpwrak>
where "owns" means "determines lifetime"
<whitequark>
as I've said, it is a structured way to alter control flow
<whitequark>
also lightweight coroutines are an excellent tool for writing highly concurrent code
DocScrutinizer05 has quit [Read error: Operation timed out]
<whitequark>
eg Hoare/Communicating Sequental Processes; what Go is based on.
<wpwrak>
yes, where you "call" to return and are "returned to" to be called
<whitequark>
wpwrak: there's a thing called "continuation"
<wpwrak>
making the local state a little less clunky
<whitequark>
simplified, a captured continuation represents all the computation which will happen *after* your method returns
DocScrutinizer05 has joined #qi-hardware
<wpwrak>
you can hide it all in message passing. as long as there's no buffer, you get the same semantics
<whitequark>
here, you basically capture exchange continuations between functions
<whitequark>
yeah
<wpwrak>
e.g., SPIN does that
<wpwrak>
well, Promela (SPIN is the implementation)
<whitequark>
yup, Prolema looks like it was modelled after CSP
<wpwrak>
ah, you know it. good :) few enough people do
<wpwrak>
lovely system. about the only way to get the bugs out of non-trivial protocols.
<whitequark>
wpwrak: not exactly Promela, never seen it before. but I did look at enough CSP-related code
<whitequark>
it's hardly the only example :)
<whitequark>
see, there's something I do better than C ;)
<wpwrak>
heh, well the purpose of promela is to add non-determinism, so ... :)
<whitequark>
oh 8AM
<whitequark>
this was sudden
<wpwrak>
that sneaky sun ;-)
<whitequark>
sun?
<whitequark>
what's that?
<whitequark>
it'll be not until 10AM or maybe even 12AM that it'd begin to dawn
<wpwrak>
the position of the evil day star is what commonly determines the day time, in some areas with +/- 1 h or similar
<wpwrak>
oh. what's why they called it the dark age :)
<whitequark>
besides, I've caught a cold and really need to sleep. so, bbl.
<wpwrak>
interesting fever dreams then !
<whitequark>
thanks:)
pcercuei has joined #qi-hardware
Jay7 has joined #qi-hardware
pcercuei has quit [Quit: Bye]
jluis has joined #qi-hardware
jekhor has joined #qi-hardware
valhalla has joined #qi-hardware
<DocScrutinizer05>
hey guys, anybody good with ssh(d)?
<DocScrutinizer05>
why 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?
<DocScrutinizer05>
some *strict*-fu* I guess
<DocScrutinizer05>
and is there any friggin way to make ssh output meaningful diagnostics regarding all that? -vv doesn't help at all
<DocScrutinizer05>
ooh, i maybe should mention that ssh-agent is involved
<DocScrutinizer05>
to forward local private key to second hop: local->A->B
<mth>
I'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 744
jekhor has quit [Ping timeout: 256 seconds]
<lindi->
wpwrak: spin is the closed source implementation, nips is the open source implementation
wej has joined #qi-hardware
<DocScrutinizer05>
mth: depending on my *local* config the *remote* machine needs 700 .ssh/ (on remote) or not
<DocScrutinizer05>
and remote A rejects with 744 while remote B doesn't, with same local config
<mth>
that second line is what I expected, the first isn't
<mth>
maybe both the server and the client check and only if both approve you can login?
dandon_ has joined #qi-hardware
dandon has quit [Ping timeout: 257 seconds]
dandon_ is now known as dandon
megha has joined #qi-hardware
xiangfu has quit [Ping timeout: 264 seconds]
xiangfu has joined #qi-hardware
qwebirc83678 has joined #qi-hardware
<qwebirc83678>
Hi everyone! Anybody has recovered a "bricked" ATUSB ?
<qwebirc83678>
I 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 assembled
qwebirc83678 has quit [Ping timeout: 245 seconds]
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #qi-hardware
xiangfu has quit [Client Quit]
xiangfu has joined #qi-hardware
dandon has quit [Ping timeout: 246 seconds]
dandon_ has joined #qi-hardware
dandon_ is now known as dandon
megha has quit [Read error: Connection reset by peer]
pcercuei has joined #qi-hardware
<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/5733b60
<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/3800125
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
kyak has joined #qi-hardware
emeb has joined #qi-hardware
wej has quit [Ping timeout: 245 seconds]
megha is now known as firewall
jluis has quit [Ping timeout: 246 seconds]
viric_ is now known as viric
pcercuei has joined #qi-hardware
wej has joined #qi-hardware
kilae has joined #qi-hardware
pcercuei has quit [Ping timeout: 248 seconds]
bzb has joined #qi-hardware
pcercuei has joined #qi-hardware
pcercuei has quit [Remote host closed the connection]
<whitequark>
damn, it's night again :S
<whitequark>
wpwrak: 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");
<wpwrak>
nice :)
<wpwrak>
can it also figure out printf("%s\n", blah); ?
<whitequark>
wpwrak: yeah
<whitequark>
it has builtin knowledge of all of the C stdlib, including prototypes, printf/scanf format specifiers, and whatnot
<whitequark>
converts exit() in main() to return;
<whitequark>
verifies that you didn't suddenly decided to overwrite a .rodata string
<whitequark>
etc etc
<whitequark>
converts loops to memset/memcpy
<whitequark>
figures out that in a loop like for(int i = 0; i < 10; i++) printf("
<whitequark>
err
<whitequark>
figures 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'
<whitequark>
it is quite certainly more clever than me in a lot of cases.
<larsc>
only so long until the machines will take over ;)
<larsc>
I think the last optimization is pretty standard though
<whitequark>
larsc: I'm not sure gcc does it
<whitequark>
LLVM in fact does it becaise autovectorizer needs it :)
<larsc>
I would be scared if it didn't
<whitequark>
larsc: I'm scared of GCC since I looked into its sources and seen lisp, c and asm in one file
<larsc>
just tried it: "add $0x4,%rbx" and "cmp $0x28,%rbx"
kilae has quit [Quit: ChatZilla 0.9.89 [Firefox 18.0.1/20130116073211]]
<whitequark>
hm, LLVM is able to retain correct debug info through all optimizations, and it retains it at all for most of them
<whitequark>
eg stacktraces include inlined functions
<whitequark>
and it doesn't screw your mind with <value optimized out>.
<lindi->
wpwrak: gcc also converts printf to puts
<lindi->
wpwrak: llvm copied that idea from there :)
<whitequark>
lindi-: might be the other way around
<whitequark>
gcc is now C++-compatible to allow for more easy incorporation of LLVM passes :)
<lindi->
wpwrak: my impression is that gcc got it first, I fixed a bug in that part in llvm
<lindi->
wpwrak: the optimization is incorrect if you use the return values of the printf in your program
<wpwrak>
heh :)
jekhor has joined #qi-hardware
<larsc>
whitequark: yea, <value optimized out> is a major annoyance. but how does llvm make sure that this doesn't happen?
<whitequark>
larsc: I guess just better tracking of values and better DWARF generation
<whitequark>
as in, your value could be moved to register from memory, but DWARF can still handle it
<whitequark>
or optimized to constant, but see above
<larsc>
whitequark: 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?
<whitequark>
larsc: hm this is interesting
<whitequark>
I should check this case
<larsc>
anybody coming to fosdem?
<viric>
ah
<viric>
I was about to ask that!
<viric>
I go.
<larsc>
cool
<larsc>
going to the beer event?
<viric>
uhm I haven't looked at the program :D
<viric>
I discovered only yesterday that I could go to it
<viric>
Ah I see
<viric>
I arrive on saturday, 16:00!
<larsc>
so you are going to miss the best part ;)
<viric>
yes, I imagine so
<viric>
But my boss forbid me to move on friday
<larsc>
:/
<viric>
Yes, because we promised to give support to one customer on full friday
<viric>
but now the customer says that he won't be ready. A hell.
firewall is now known as megha
wej has quit [Ping timeout: 264 seconds]
wej has joined #qi-hardware
jekhor has quit [Read error: Operation timed out]
jekhor has joined #qi-hardware
Guo has joined #qi-hardware
Guo has quit [Client Quit]
jekhor has quit [Ping timeout: 252 seconds]
jekhor has joined #qi-hardware
<viric>
larsc: I'd be pleased to meet you at fosdem
<viric>
are you giving a talk?
jekhor has quit [Ping timeout: 264 seconds]
<larsc>
no, I decided to late that I'd come to fosdem.
<larsc>
if you don't have any other plans we could maybe go for a beer on saturday evening
<viric>
I'm not sure I have other plans :)
<viric>
I plan to meet people
<wpwrak>
larsc: i approve of your priorities :)
<wpwrak>
viric: the best meetings are over some beers ;-)
<viric>
I don't oppose the beers! :)
<viric>
I just don't know if I may meet with 20 more people for beers
<viric>
it may be that I join the people around 'nix', maybe some around 'gnu'
<viric>
but I don't want to miss larsc !
<viric>
larsc: do other people from mipslinux come?
<larsc>
I know that nbd will be there, haven't heard from anybody else