#avr Logs

Mar 09 2018

01:00 AM Ameisen: why 4.8.1
01:04 AM Ameisen: avr-gcc 7.3.0 has been out for a long time
01:18 AM polprog: thats nothing
01:18 AM polprog: yesterday i installed unrar-free
01:18 AM polprog: from debian repo
01:19 AM polprog: the testing branch i think
01:19 AM polprog: version 0.0.1 from 2004
01:19 AM polprog: pmsl
01:19 AM polprog: i ended up unraring it with my phone
06:26 AM nuxil: Amadiro, idk. because of debian still lives in the 80's ?
06:26 AM nuxil: *@ Ameisen
06:43 AM nuxil: anyway- upgraded to 4.9.2 :p
06:52 AM nuxil: Ameisen, and why should i use 7.x ? isnt the latest gcc vesion just to include better support for c+11/c++14 ? and i dont do C++ code.
06:54 AM polprog: nah
06:54 AM polprog: debian testing has 7.x gcc in it
06:54 AM nuxil: i dont use deb test repos
06:58 AM polprog: oh. there kubuntu on two of the school lab pcs
06:58 AM nuxil: kde.. gosh
06:58 AM polprog: reset the password
06:59 AM polprog: yeah kde on a pentium 4
06:59 AM polprog: gj
07:00 AM nuxil: i kind of liked kde 3.x but after the total rewrite to this plasma crap i just hate it.
07:00 AM polprog: it uaed to be good
07:00 AM polprog: i hate all new interfaces
07:00 AM nuxil: yea. that the word. "Used to be" ;)
07:01 AM polprog: win10, new ubuntu . gosh. xfce or ttu
07:01 AM polprog: tty*
07:01 AM nuxil: lubuntu :p
07:02 AM nuxil: LXDE
07:11 AM polprog: at least i can play nethack w/o putty
07:18 AM day__ is now known as day
08:31 AM nuxil: polprog, install enlightenment on it :p
08:32 AM polprog: maybe on monday, lol
01:38 PM Ameisen: nuxil - I can assure you that incremental GCC versions are not just there to add support for C++
01:39 PM Ameisen: especially given the relatively hostile attitude the FSF has had towards C++, historically
01:39 PM Ameisen: the better question is - do newer GCC versions cause performance regressions in AVR
01:39 PM Ameisen: the answer is 'sometimes'
01:40 PM Ameisen: oftnetimes you can eliminate those regressions with proper compile options
01:40 PM Ameisen: disabling optimization passes that don't work for AVR, or don't have meaning for AVR
01:40 PM Ameisen: though I've found that sometimes optimization passes that _literally make no sense on AVR_... generate better code
01:41 PM Ameisen: like enabling loop vectorization optimizations, designed for CPUs that can handle vectored instructions... generated better AVR code for me
01:41 PM Ameisen: _why_ it did, I have absolutely no idea
01:41 PM Ameisen: presumably it reordered operations in such a way that the reduction passes in the optimizer were able to work better
01:42 PM nuxil: FSF ?
01:44 PM nuxil: free software foundation ?
01:44 PM Ameisen: yes
01:44 PM Ameisen: For a very long time, g++ was terrible
01:45 PM Ameisen: it's only recently that g++ has actually been OK, and sometimes I suspect that that's embarassment over Visual C++ being better than g++ for a while
01:45 PM nuxil: Richard Stallman is a crackhead.
01:46 PM Ameisen: Stallman and Torvalds both have had it out for C++
01:46 PM Ameisen: their arguments never really made sense, and doubly don't make sense these days, but it still colored a lot of work for over a decade
01:47 PM Ameisen: however, newer GCC versions generally have improvements to the optimizer, bug fixes, and suc
01:47 PM Ameisen: such
01:47 PM Ameisen: not sure if there are any C11 improvements, I don't really follow C
01:58 PM nuxil: i find their argument "c++ is a horrible language" fully valid :p
01:59 PM nuxil: besides i can understand why no c++ in kernel.
02:00 PM nuxil: in short. less surprises.
02:00 PM Ameisen: Well, Linux is in C. Adding C++ wouldn't make sense unless it was a C++ kernel
02:00 PM nuxil: as a comment said: try a combination of templates, multiple inheritance, auto generated constructors, virtual functions and mix in a bit of namespace magic and argument dependent lookup, In many cases this magic is nice, but for example in real-time systems it can really screw up your day.
02:00 PM day__ is now known as day
02:01 PM Ameisen: I'm unsure how templates are going to screw up your dat in a real-time system.
02:01 PM Ameisen: And if you don't want to use multiple inheritance, don't. Most people don't.
02:01 PM Ameisen: C++ doesn't force you to use all the features.
02:01 PM Ameisen: and what the heck is 'namespace magic'
02:01 PM Ameisen: namespaces are one of the best features of the language.
02:02 PM nuxil: like i know :p
02:02 PM nuxil: and another comment i like aswell.
02:02 PM nuxil: If you need something more feature rich or powerful then go with C#, Objective C, Java, or something else like that. Why burden yourself with the complexities of C++? If you need the degree of control C++ grants then I argue to use C. C can do anything and can do it well.
02:02 PM Ameisen: yeah, if you don't know C++, then C++ is overcomplicated and dangerous.
02:02 PM Ameisen: If you know C++, then C is too weak and not expressive enough.
02:03 PM Ameisen: I generally disregard the attitude of C programmers towards C++ _because they're C programmers and don't like C++_, so their opinions are already colored
02:03 PM Ameisen: they usually don't have a strong knowledge of the language, either
02:03 PM Ameisen: I can't tell you how many times I've heard arguments about 'template bloat' and roll my eyes
02:04 PM Ameisen: like, is it 1999?
02:04 PM nuxil: well i cant tell as you said im colored :p
02:04 PM Ameisen: Are compilers still completely ineffective any DCE?
02:04 PM nuxil: i only know a bit C :p
02:04 PM Ameisen: at*
02:05 PM Ameisen: I want to know still how templates, auto-generated constructors (which for simple structures _have no code_ and are thus elided), namespaces, or ADL have an impact on 'real time systems'
02:06 PM Ameisen: Sounds to me like he just decided to throw out a lot of fancy feature words without actually thinking about what they were
02:06 PM Ameisen: because 'more is bad'
02:06 PM nuxil: well, "more" is likely to go wrong 1st and harder to track down ?
02:06 PM Ameisen: If you're using virtuals, you'd likely be using function tables in C and the performance is at worst the same, and at best better. Same with multiple inheritance.
02:07 PM Ameisen: The purpose of the vast majority of C++ code is to minimize duplication of logic and code.
02:07 PM Ameisen: thus, _easier_ to prevent bugs
02:07 PM Ameisen: Most C programmers either don't recognize that, or don't understand it, and start fabricating odd circumstances where you could potentially use those features and generate terrible code.
02:08 PM Ameisen: I could make really, really bad code in C, too
02:08 PM nuxil: i do that all the time :D
02:09 PM Ameisen: For instance, autogenerating constraint values from a table in C... since it has no metaprogramming capabilities at all, you'd have to write a SEPARATE program to parse your table (meaning it has to parse C as well, or has to generate a new C file for you), then generate the data, and so forth
02:09 PM Ameisen: C++? Templates and constexpr. Built into the language.
02:09 PM Ameisen: Less to maintain, less complexity.
02:11 PM Ameisen: the second comment isn't even accurate
02:11 PM Ameisen: as said, there are things C++ can do that C _cannot_
02:11 PM Ameisen: C requires third-party programs to do anything that requires introspection of the code.
02:11 PM nuxil: im the wrong guy to debate C/C++ with. try linux-kernel or some channel :p , c++ is just to complex for me to bother with.
02:12 PM Ameisen: I'm just saying
02:12 PM Ameisen: those are the sorts of comments that bug me because they leave me with a strong impression that the people who wrote them had no knowledge of what they were talking about.
02:13 PM Ameisen: the first one is just "let's make a list of scary-sounding features and roll with it."
02:21 PM twnqx: C++ has quite some features i'd like to have in c
02:22 PM twnqx: namespaces, templates, custom operators...
02:26 PM Ameisen: If you take all the good features of C++ and put them into C... you have C++ :|
02:26 PM Ameisen: maybe trimmed down a little
02:26 PM Ameisen: A lot of the needless complexity in C++ is actually due to an attempt to maximize backwards compatibility with C, which has generated a lot of complaints towards the standards committee
02:27 PM Ameisen: ackward syntax and such that exists because otherwise it woudl be ambiguous for C
02:28 PM bss36504: Damn, I missed a C/C++ flame war on #avr :(
02:30 PM bss36504: I'll toss in that the products I work on are very much "real-time" systems and our codebase is probably 95% C++.
02:30 PM nuxil: Ameisen, is a missionary.. his religion C++ which is tries to convince the "C" none beliver is the right religion :p
02:31 PM nuxil: just kidding :p
02:31 PM bss36504: And templates can actually, demonstrably, generate more efficient code in certain circumstances.
02:31 PM bss36504: Of course, that depends on your definition of efficient. In my case, speed is the goal, because memory is more or less unlimited
02:32 PM bss36504: Ameisen provided sane arguments. Its the C folks who can't see the light.
02:32 PM nuxil: lol
02:32 PM bss36504: I started as a C programmer, but grew my knowledge of languages to include C#, Java, and C++.
02:33 PM bss36504: As a programmer or engineer (software or otherwise), your languages are your tools. If you want a sparse toolbox, that's on you, but don't say that the guy with the fuller toolbox is wrong and shouldn't have all those things
02:34 PM nuxil: is it not more like the right tool for the right job. ? if all you need is a "screwdriver" you dont even need the toolbox
02:35 PM bss36504: Yes, that's exactly the point
02:36 PM bss36504: But if you don't know how to use my tools, its not MY problem. I'm not responsible for correcting ignorant arguments from other people
02:38 PM Emil: bss36504: you take it back
02:38 PM bss36504: No way buddy ;)
02:38 PM bss36504: Long time no talk
02:39 PM Ameisen: bss36504 - I've actually shown that with templates
02:39 PM Ameisen: surprisingly, people who "don't like C++" were very good at dismissing the results as aberrations :|
02:39 PM Ameisen: I've seen templates generate faster _and_ smaller code
02:40 PM bss36504: Yeah I did a FIR filter loop unrolling example with templates. Code was larger, but the speed was literally as fast as possible
02:40 PM Ameisen: Need LTO to do it well, though.
02:40 PM bss36504: True. Unfortunately the codebase I'm in doesnt use templates as much as I'd like....yet
02:40 PM bss36504: I've only worked here since oct. though
02:41 PM Ameisen: I rewrote the thermal manager in this firmware using templates and constexpr
02:41 PM bss36504: I'll bend my coworkers to my wicked C++ ways with enough time
02:41 PM Ameisen: so it could branch on algorithms based upon compile-time derived constraint values
02:41 PM bss36504: sexy :P
02:41 PM Ameisen: it was... weird trying to derive those values from an array in program memory, though
02:41 PM Ameisen: really wish g++ had __flash
02:42 PM Ameisen: had to write a bunch of helpers to make objects in program memory be type-modified
02:42 PM bss36504: Ive been blessed with IAR at this job
02:42 PM bss36504: It's quite nice, and the debugging is hands down the best i've used.
02:42 PM Ameisen: What spec does it support to?
02:42 PM bss36504: Like language standard?
02:43 PM Ameisen: yeah
02:43 PM bss36504: C++14
02:43 PM Ameisen: There's a few very very very useful things in 17
02:43 PM Ameisen: Mainly extended constexpr
02:43 PM bss36504: I have mixed feelings on constexpr.
02:43 PM Ameisen: It's a hack. A useful hack, but a hack.
02:43 PM bss36504: It can't be a replacement for templates, but it is much simpler to use
02:44 PM bss36504: It's just one of those "this is a suggestion to the compiler" type things
02:44 PM Ameisen: You end up using templates _with_ constexpr. Simplifies things a lot.
02:44 PM bss36504: Oh definitely.
02:44 PM Ameisen: well, sometimes constexpr is not a suggestion, but a requirement
02:44 PM Ameisen: as with 'if constexpr'
02:44 PM bss36504: Lets you mix the functional paradigm with the traditional c++ paradigm
02:44 PM Ameisen: you can also require constexpr evaluation of functions by assigning the return value to a constexpr value.
02:45 PM bss36504: Hmm interesting.
02:45 PM Ameisen: or using it in a constexpr context, like as an argument to a template
02:45 PM bss36504: I'll admit im not an expert on constexpr
02:45 PM bss36504: I need more use cases to get a feel for when/how to use it
02:45 PM Ameisen: there's no way, officially, though to determine if the current evaluation of a function is constexpr or not.
02:45 PM Ameisen: which makes some stuff difficult
02:45 PM Ameisen: You can 'force' it in g++, using __builtin_constant_p cleverly
02:46 PM Ameisen: doesn't work in clang though
02:46 PM Ameisen: vc++ has no equivalent builtin
02:46 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/thermistors/thermistortable_1.h
02:46 PM Ameisen: messy but that's heavily templated and constexpr'd
02:46 PM Ameisen: a LOT of value-type derivation going on to minimize type sizes
02:47 PM bss36504: What architecture is this for?
02:47 PM Ameisen: AVR
02:48 PM Ameisen: my ARM code isn't nearly as complex, as type-constraining like that isn't useful there. Value constraining is, though.
02:48 PM bss36504: That's what I was wondering
02:48 PM bss36504: I haven't fooled with AVRs in a while, but I like this channel :)
02:48 PM Ameisen: I will still use type wrappers that wrap __assume to give value constraints for the optimizer
02:48 PM Ameisen: but if you jam around uint8/uint16, ARM is slower
02:49 PM bss36504: I've been using STM32 Cortex-M4/M7 and Silicon Labs EFR32MG at work
02:49 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/tunalib/flash.hpp#L228-L239
02:49 PM Ameisen: that's what I wrote to branch a constexpr function on evaluation type
02:50 PM Ameisen: I have some STM32s, haven't tinkered with them much
02:50 PM Ameisen: been working with Teensys though
02:50 PM twnqx: does c++ work without the stdlibc++?
02:50 PM Ameisen: which are NXP Kinetis CPUs
02:51 PM bss36504: The STM32s are pretty cool
02:51 PM Ameisen: twnqx - as much as C works without libc
02:51 PM twnqx: so, perfectly
02:51 PM bss36504: I've worked with the KL25Z
02:51 PM Ameisen: the main thing C++ sort of 'requires' from stdlibc++ is std::initializer_list
02:51 PM bss36504: I don't like it much
02:51 PM Ameisen: which has no overhead, but it generally has to be there
02:51 PM bss36504: We use no STL stuff in our code at work
02:51 PM twnqx: just thinking about those 256byte flash µCs
02:52 PM twnqx: perfectly usable in C :P
02:52 PM Ameisen: I use STL stuff where appropriate. Depends on the project and requirements
02:52 PM bss36504: It's just not necessary for us most of the time
02:52 PM Ameisen: my main gripe with things like std::vector is that std::allocator lacks resize
02:52 PM Ameisen: so enlarging the vector is _always_ alloc/copy/free
02:53 PM Ameisen: twnqx - properly written C++ can end up smaller than C, with the right compiler flags
02:53 PM Ameisen: though you are certainly going to need to write it with size in mind
02:57 PM Ameisen: If you know how to do it, C++ is very good at generating value- and type-constrained code
02:57 PM Ameisen: which minimizes size if used right
02:58 PM Ameisen: you can _somewhat_ do it in C, but you cannot autoconstrain as much, only explicitly
02:58 PM twnqx: why would i bother constraining
02:58 PM Ameisen: compiler can generate better code based upon constraints.
02:59 PM Ameisen: AVR it happens a lot. Based upon constraints, compiler can determine it doesn't need to operate on the final byte of a uint32, and so discards it instead of emitting code to shift or such.
02:59 PM Ameisen: AVR usually does so based upon constants and type-validation. You can add additional constraints as well.
02:59 PM Ameisen: err, GCC*
02:59 PM twnqx: C does that perfectly fine if i assign to an u8
03:00 PM Ameisen: and you could constrain that further and tell GCC that the u8's value is <=127
03:00 PM Ameisen: so the upper nibble is always zero and can be ignored
03:00 PM Ameisen: which is relevant for AVR
03:00 PM Ameisen: since it has nibble-based ops
03:01 PM twnqx: if it would ignore the upper nibble for <127 i'd burn it with fire.
03:01 PM Ameisen: err
03:01 PM Ameisen: not 127, sorry
03:01 PM Ameisen: brain is slow right now
03:01 PM Ameisen: 15
03:02 PM Ameisen: either way, comes up even with 127. If you were shifting the value, and it knows its < 127, it can generate a different set of opcodes for shifting the value.
03:02 PM Ameisen: since it doesn't have to retain the highest bit
03:03 PM Ameisen: One function in this codebase I ended up rewriting with a lot of constraints was 'multiply uint24 by uint24, return high 16-bits of results.'
03:05 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/stepper.cpp#L139-L149
03:05 PM Ameisen: which replaced a mess of inline assembly which was larger and slower than what g++ puts out. Without the __assumes, it generates much worse code.
03:06 PM Ameisen: Another one I found was they used an int8 to determine the direction the stepper was moving. Was always -1 or 1. Added an __assume(val == -1 || val == 1);. Changed the codegen considerably for when it was adding the direction value to the step count.
03:07 PM twnqx: is that even correct... 24*24 yields 48bits theoretically, shited right by 24 is still 24 bit results, then truncated to 16 bits?
03:07 PM twnqx: doesn't that ignore the top 8 bits?
03:08 PM Ameisen: their name is incorrect and I always recite it
03:08 PM Ameisen: was one of the reasons it took me a while to rewrite the function, because I kept getting the wrong values.
03:09 PM twnqx: well, you throw away the top 8 bit of the multiplication
03:09 PM twnqx: so i would be surprised if you got the right results.
03:09 PM Ameisen: Their original inline asm does, as well
03:09 PM twnqx: unless 24_u8 is defined to 32.
03:09 PM Ameisen: the name is wrong.
03:09 PM Ameisen: not my fault.
03:10 PM Ameisen: my original code returned the upper 16 bytes (shifting by 32), and it was the wrong value.
03:10 PM Ameisen: I'm guessing they weren't able to describe clearly what they meant to be returning so just went with 'H16'
03:11 PM * Ameisen shrugs
03:12 PM Ameisen: https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/stepper.cpp#L129-L168
03:12 PM Ameisen: that was the original code
03:12 PM twnqx: according to the comment you can still get different results :P
03:12 PM Ameisen: intRes = longIn1 * longIn2 >> 24
03:12 PM Ameisen: the codebase I was operating off of had different comments there
03:12 PM Ameisen: not sure which is 'current'
03:12 PM twnqx: ofc i have to wonder, if they didn't caclculate the lower bytes, and thus ignored an off-by-one
03:12 PM Ameisen: there's like 50 branches of Marlin
03:12 PM Ameisen: and by 50, it's closer ot 1000
03:13 PM twnqx: why don't you just implement it by shifting shwon first?
03:13 PM twnqx: down*
03:13 PM twnqx: should produce smaller code than calculating everything and be correct, but different :P
03:13 PM Ameisen: The compiler is likely doing that as it is.
03:13 PM twnqx: wtf, microchip now bought microsemi, too?
03:13 PM Ameisen: I prefer my code to be readable and understandable
03:14 PM Ameisen: It's hard to get the actual asm it's generating, since it's inlined
03:14 PM Ameisen: :|
03:15 PM twnqx: 'm not sure if your code is understandable if the name is obviously not what it does
03:15 PM Ameisen: I 'spose I could change it to no inline though
03:15 PM twnqx: though that's not your fault :P
03:15 PM Ameisen: I didn't change the name. Not entirely sure what to call it, either
03:17 PM Ameisen: my point though is additional constraints can let the compiler optimize further, as it can enable further reductions in the optimizer.
03:51 PM Ameisen: now I need to figure out how I want to design this USB input buffer for ARM
03:51 PM Ameisen: either going to go with a raw ringbuffer (not a real one since still no MMU) or a per-line ringbuffer.
03:52 PM Ameisen: latter is likely faster/simpler, but former wastes less RAM
04:30 PM pwillard_ is now known as pwillard
06:14 PM dev1990_: Ameisen++
06:41 PM Ameisen: I still want an MMU :(
07:51 PM day__ is now known as day
07:57 PM day__ is now known as day
08:19 PM Ameisen: Probably going to implement some USB/Stream output functions so I can strip the ones that are left over from Arduino code
08:19 PM Ameisen: haven't decided if I want to get rid of the 'ARM-optimized memcpy' that's in it
08:19 PM Ameisen: I have a sneaking suspicion that GCC will do better
08:34 PM day__ is now known as day
08:41 PM Tom_itx is now known as Tom_L
11:22 PM day__ is now known as day
11:44 PM rue_: uh, artn't you using the DMA?