| 00:33:37 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:16:34 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
| 01:21:18 | | Quit ZincAlloy (Ping timeout: 260 seconds) |
| 01:29:29 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:c436:684b:28bf:595a) |
| 01:34:11 | | Quit ZincAlloy (Ping timeout: 272 seconds) |
| 01:36:30 | _bilgus__ | not sure why I hadn't thought to paste a sentinel on the buffers lua allocs from before this point |
| 02:00 |
| 02:07:14 | braewoods | _bilgus__: you mean like prepending magic bytes to know what allocated it? |
| 02:07:35 | _bilgus__ | yeah like we do to check stack depth |
| 02:07:49 | braewoods | so make it part of the stack frame then? |
| 02:08:00 | braewoods | though i can't see that being relevant there |
| 02:08:20 | braewoods | stack and dynamic memory are different beasts... |
| 02:08:26 | _bilgus__ | no just filling the buffer with a sentinel and later grab how much is still clean |
| 02:09:09 | braewoods | i see. so C string style sentinel? |
| 02:09:23 | braewoods | where 0 denotes the end |
| 02:09:39 | _bilgus__ | lua doesn't do a very good job of letting you know how much memory you have free just what it has allocd currently |
| 02:10:00 | _bilgus__ | nah no point in that just deadbeefdeadbeefdeadbeef |
| 02:10:34 | braewoods | wouldn't that be rather slow, requiring you to manually scan it every time? |
| 02:11:31 | braewoods | IOW it sounds like you'd be setting every 4 bytes to that pattern or so |
| 02:11:44 | braewoods | since i assume most of these targets have 4 byte pointers |
| 02:12:18 | braewoods | i can't see most of them using 64 bit pointers |
| 02:12:21 | braewoods | or arithmetic even |
| 02:12:40 | _bilgus__ | its not much slower than querying the lua garbage collector about its status especially since we are doing it from c |
| 02:12:48 | braewoods | I see. |
| 02:13:19 | _bilgus__ | that c/lua line has a lot of overhead |
| 02:13:31 | braewoods | if the maximum memory available to lua is fixed, couldn't you just find it from basic subtraction? |
| 02:13:52 | _bilgus__ | sorta |
| 02:14:04 | braewoods | but that's not accurate enough? |
| 02:14:20 | _bilgus__ | only problem is you don't know what lua has done with the buffer |
| 02:14:44 | braewoods | so why does that matter? |
| 02:14:46 | _bilgus__ | it might say it has 100kb allocated but it shit on 150 kb and left blocks too small to use |
| 02:14:55 | braewoods | Oh. |
| 02:14:57 | braewoods | Fragmentation. |
| 02:15:17 | braewoods | the perils of dynamic allocatin |
| 02:15:21 | _bilgus__ | yes lua is terrible for fragging the whole thing |
| 02:15:32 | braewoods | so you're trying to devise a method of defragging your free memory? |
| 02:15:34 | _bilgus__ | thats why a high watermark is useful |
| 02:16:11 | _bilgus__ | nah I've tried stuff like that but the overhead is such you are better off off loading your data and restarting lua |
| 02:16:41 | braewoods | yea. dynamic memory is a pain. |
| 02:16:56 | braewoods | convenient to use but... |
| 02:17:44 | braewoods | _bilgus__: i wonder if pool allocators could be useful |
| 02:18:04 | braewoods | though i don't know if lua is compatible with hybrid allocation strategies |
| 02:18:17 | _bilgus__ | thats what our alloc is doing on the back end |
| 02:19:18 | _bilgus__ | tlsf |
| 02:19:25 | braewoods | tlsf? |
| 02:19:32 | braewoods | thread local ... ? |
| 02:19:54 | _bilgus__ | two level segregated fit |
| 02:20:02 | braewoods | ah. never heard of it. |
| 02:20:11 | _bilgus__ | its pretty good |
| 02:20:22 | _bilgus__ | not great but pretty good |
| 02:20:25 | braewoods | i only know of 2 things starting ith TLS |
| 02:20:27 | braewoods | with* |
| 02:20:35 | braewoods | thread local storage |
| 02:20:41 | braewoods | transport layer security |
| 02:20:42 | braewoods | lol |
| 02:20:44 | _bilgus__ | http://www.gii.upv.es/tlsf/ |
| 02:22:01 | braewoods | i've always tried to minimize reliance on heap memory because it's better to use stack or static allocations if appropriate |
| 02:22:23 | braewoods | because of the potentially unbounded size and such |
| 02:22:28 | braewoods | err time |
| 02:22:30 | braewoods | rather |
| 02:22:46 | braewoods | but i sometimes am stuck with it because of the nature of data structures |
| 02:24:31 | _bilgus__ | well on embedded you kinda get stuck with that but damn if it doesn't make the code so much better |
| 02:33:41 | *** | Saving seen data "./dancer.seen" |
| 02:51:13 | braewoods | _bilgus__: heh. of course if you got a shitload of RAM available... these concerns seem rather moot. |
| 02:51:27 | braewoods | i usually forget about fragmentation when i have gigabytes of RAM |
| 02:51:51 | _bilgus__ | yeah it does seem that way a lot now a days and I'm like 1GB for a text editor WTF |
| 02:52:03 | braewoods | ah, that's because of JS. |
| 02:52:21 | _bilgus__ | no thats because of 1993 :p |
| 02:53:09 | _bilgus__ | I just remember when a 4 megs was very expensiver |
| 03:00 |
| 03:53:03 | | Quit livvy (Ping timeout: 240 seconds) |
| 04:00 |
| 04:01:11 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 04:12:22 | | Quit pamaury (Ping timeout: 246 seconds) |
| 04:33:43 | *** | Saving seen data "./dancer.seen" |
| 04:59:50 | | Join pamaury [0] (~pamaury@maths.r-prg.net.univ-paris7.fr) |
| 04:59:50 | | Quit pamaury (Changing host) |
| 04:59:50 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 06:00 |
| 06:33:44 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:26:10 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 07:36:55 | speachy | does its internal malloc() combine adjaent freed areas? |
| 07:37:07 | speachy | lua, I mean |
| 07:52:40 | | Quit sakax (Remote host closed the connection) |
| 08:00 |
| 08:08:53 | braewoods | one thing i learned awhile ago of interest about heap allocations... |
| 08:09:04 | braewoods | the minimum allocation unit is the alignment size |
| 08:09:13 | braewoods | for most systems i use that's 8 bytes so |
| 08:09:24 | braewoods | anything less than that is wasting space |
| 08:09:39 | braewoods | the closer to a multiple of this you get the less waste |
| 08:10:46 | braewoods | also was useful when analyzing whether to store strings inline or externally |
| 08:11:09 | braewoods | really short C strings may be better off being inline to their struct if they're small |
| 08:11:34 | braewoods | <= 8 bytes |
| 08:12:01 | braewoods | otherwise... you need to allocate at least 16 bytes. 8 for the pointer and a min of 8 for the actual array |
| 08:12:14 | braewoods | so i guess it's more like length of 15 |
| 08:12:56 | braewoods | assuming each string is not referenced more than once |
| 08:18:31 | braewoods | just how malloc works since it has to guarantee what it returns it suitably aligned for anything |
| 08:18:46 | braewoods | whether it's for pointers, doubles, or w/e |
| 08:30:36 | speachy | it's worse than that, actually −− you also have the internal heap allocator per-allocation overhead. |
| 08:33:09 | speachy | so you're really looking at a minimum of two pointers+length for overhead. |
| 08:33:33 | | Join tbaxter [0] (~Adium@pool-100-34-20-58.phlapa.fios.verizon.net) |
| 08:33:45 | *** | Saving seen data "./dancer.seen" |
| 08:43:18 | speachy | _bilgus__: Ingenic fixed the DMA engine in the X1000 series; it does per-descriptor interrupts so circular, double-buffered audio operation will work. |
| 08:45:13 | speachy | its newer mips32r2 core also has an actual priority-driven interrupt controller. Nowhere near as awesome as the ARM Cortex-M NVIC, but a vast improvement over its predecessor |
| 08:51:30 | braewoods | speachy: ah i was just looking at from the application POV. |
| 08:51:50 | braewoods | about how best to utilize available storage |
| 08:52:03 | braewoods | whether to use an array or pointer to store it |
| 08:52:11 | speachy | rockbox is the application and the operating system, so we try to optimize the overall usage. :) |
| 08:52:36 | braewoods | for small allocations it can make more sense to inline them with a larger one |
| 08:52:42 | braewoods | is something i noticed |
| 08:52:58 | speachy | Since I got my start in the days dinosaurs walked the earth and men wore onions on their belts (as was the fashion at the time) I've written more allocators than I care to count |
| 08:53:51 | speachy | yep. when you have known, fixed allocation needs that don't need to beyond the scope of the immediate function... |
| 09:00 |
| 09:15:44 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:32:16 | | Join amiconn_ [0] (jens@rockbox/developer/amiconn) |
| 09:32:17 | | Nick amiconn is now known as Guest85356 (jens@rockbox/developer/amiconn) |
| 09:32:17 | | Quit Guest85356 (Killed (wolfe.freenode.net (Nickname regained by services))) |
| 09:32:17 | | Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) |
| 09:33:23 | | Join pixelma_ [0] (marianne@rockbox/staff/pixelma) |
| 09:33:24 | | Nick pixelma is now known as Guest56388 (marianne@rockbox/staff/pixelma) |
| 09:33:24 | | Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) |
| 09:33:55 | | Quit Guest56388 (Ping timeout: 240 seconds) |
| 09:46:03 | | Nick Oksana_ is now known as Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 09:48:55 | braewoods | speachy: the only allocators i've written were for dynamic structs. |
| 09:49:14 | braewoods | speachy: have you ever found a use for C99 FAMs? |
| 09:49:19 | braewoods | flexible array members |
| 09:49:32 | braewoods | where the last field is an array with no specified size. |
| 09:49:45 | braewoods | it has to be dynamically allocated due to being an incomplete type |
| 09:50:02 | speachy | I use that construct a lot, but I don't think it's commonly found in Rockbox. |
| 09:50:21 | braewoods | ok. |
| 09:50:53 | braewoods | i've rarely used it since it made resizes more expensive to perform |
| 09:51:02 | | Join amiconn_ [0] (jens@rockbox/developer/amiconn) |
| 09:51:02 | | Nick amiconn is now known as Guest5204 (jens@rockbox/developer/amiconn) |
| 09:51:02 | | Quit Guest5204 (Killed (rajaniemi.freenode.net (Nickname regained by services))) |
| 09:51:02 | | Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) |
| 09:51:06 | braewoods | it only really made sense for fixed-size but variable allocations |
| 09:51:14 | braewoods | allocate once and don't resize. |
| 09:51:56 | braewoods | at least that was my theory anyway... |
| 09:52:03 | | Join pixelma_ [0] (marianne@rockbox/staff/pixelma) |
| 09:52:04 | | Nick pixelma is now known as Guest48385 (marianne@rockbox/staff/pixelma) |
| 09:52:04 | | Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) |
| 09:52:14 | braewoods | if i kept the array separate the amount to resize would be less but with large enough arrays it may be enough to be irrelevant |
| 09:52:23 | speachy | (oh, when I say "allocators" I'm referring to the likes of a malloc() implementation) |
| 09:52:25 | | Quit Guest48385 (Ping timeout: 240 seconds) |
| 09:52:34 | braewoods | speachy: oh. i guess i meant constructors then. |
| 09:52:43 | braewoods | malloc wrappers or so |
| 09:53:06 | speachy | FAMs pretty much reuqire use of dynamic allocation when they're instantiated/constructed |
| 09:53:39 | braewoods | speachy: "pretty much"? try always. they can't be used any other way. lol |
| 09:53:39 | speachy | but the FAM structure is quite useful as an abstraction as part of an API where you don't necessarily know how many elements are in the array. |
| 09:54:05 | braewoods | the only way i could use that with the stack is if i used the non-standard alloca |
| 09:54:35 | speachy | braewoods: there are plenty of situations where the structure and the number of elements is known at compile time. |
| 09:55:01 | braewoods | speachy: well... you'd need to create a custom type for that and you wouldn't be using a FAM anymore, no? |
| 09:55:13 | braewoods | unless you're talking about abusing type punning or so |
| 09:55:23 | speachy | so you can just say something like struct foo = { .numelem = 5, .elem[0] = ..., .elem[1] = ... } etc |
| 09:56:14 | speachy | you can't use sizeof(struct foo) of course |
| 09:56:18 | braewoods | direct usage of a FAM though is impossible without dynamic allocation... otherwise you need to abuse type casting from a type that can be resolved at compile time |
| 09:56:29 | braewoods | or something like that |
| 09:57:08 | braewoods | i usually tried to avoid such trickery since it can create issues |
| 09:57:09 | speachy | an example of what I mean: https://git.shaftnet.org/cgit/selphy_print.git/tree/backend_common.h (line 261) |
| 09:58:00 | speachy | and statically instantiated at: https://git.shaftnet.org/cgit/selphy_print.git/tree/backend_mitsu70x.c line 2337 |
| 09:58:03 | braewoods | ok... that can't be statically allocated as it is... |
| 09:58:23 | braewoods | hm. |
| 09:58:40 | speachy | (hmm, I should have made that a const struct..) |
| 10:00 |
| 10:00:59 | speachy | I don't use that FAM element as something that can be resized. (reallocating/resizing thigns is nearly always the wrong approach anyway) |
| 10:01:31 | braewoods | speachy: i stand corrected. i just assumed it couldn't work because most structures are fixed size... |
| 10:01:43 | braewoods | i didn't know you could use it for a dynamic sized static table. |
| 10:02:41 | speachy | If you don't know in advance how many elements are going to be needed, then yes, you'll need to dynamically allocate the structure, and you definitely can't rely on sizeof(...) :) |
| 10:05:00 | braewoods | speachy: int x <:50:>; |
| 10:05:05 | braewoods | speachy: valid C or not? :) |
| 10:06:01 | speachy | I don't think it's valid C<=99, at least. might be valid C++ though. |
| 10:06:15 | braewoods | speachy: it's valid C. |
| 10:06:35 | braewoods | speachy: https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C |
| 10:06:49 | braewoods | a useless and esoteric feature first introduced in ANSI C |
| 10:07:19 | speachy | can't say I've ever seen that construct before. |
| 10:07:19 | braewoods | not surprised you wouldn't know about it per say |
| 10:07:31 | braewoods | speachy: i only know about it because I read the entire ANSI C book |
| 10:07:52 | braewoods | kinda like how the 'auto' keyword is technically a keyword but virtually no one uses it |
| 10:09:14 | braewoods | i've actually considered making a macro for it |
| 10:09:18 | braewoods | #define auto __auto_type |
| 10:09:26 | braewoods | to get C++ type inference in GNU C |
| 10:09:29 | braewoods | lol |
| 10:09:58 | braewoods | speachy: how about... |
| 10:10:03 | braewoods | speachy: int x = (3, 4, 5); |
| 10:10:08 | braewoods | speachy: what value is x? |
| 10:10:21 | speachy | 5. |
| 10:10:25 | braewoods | Correct. |
| 10:10:42 | braewoods | This is stuff i use to test beginners to C in #learnprogramming |
| 10:10:43 | speachy | (that sort of construct is quite often used in loop evaluations |
| 10:10:58 | braewoods | there's not many places you'd want to use the comma operator |
| 10:11:03 | braewoods | not many realize it's even an operator |
| 10:11:12 | speachy | my favorite C question is: what does '++*x++;' do? |
| 10:11:47 | braewoods | well i know *x++ increments the pointer not the underlying value |
| 10:11:59 | braewoods | if i had to guess |
| 10:12:05 | braewoods | though... |
| 10:12:21 | braewoods | i wouldn't know honestly. |
| 10:12:34 | speachy | it's a trick question; the correct answer is "gaaah, don't do that!" |
| 10:12:35 | braewoods | i hate mixing dereference with ++ or −− |
| 10:12:45 | braewoods | due to how weird the precedence is |
| 10:12:58 | braewoods | i often use [0] instead of * just for my sanity if i'm doing anything complex |
| 10:13:17 | braewoods | since []s have precedence that's more intuitive |
| 10:13:38 | braewoods | to get the same with * you need to do |
| 10:13:41 | braewoods | (*x) |
| 10:13:42 | braewoods | or so |
| 10:14:24 | speachy | the dereference is the highest precedence. |
| 10:15:10 | braewoods | speachy: eh? in my experience * is pretty low though... if it was highest I wouldn't need to use ()s |
| 10:15:50 | braewoods | ah. |
| 10:15:53 | braewoods | 2nd highest |
| 10:15:59 | braewoods | []s are in the highest group |
| 10:16:22 | speachy | but the ++ |
| 10:16:37 | braewoods | which is why it increments the pointer prior to dereferencing |
| 10:16:51 | speachy | but yeah, that expression is a doozey |
| 10:17:37 | braewoods | ok, another esoteric feature question |
| 10:17:46 | braewoods | what's this: int (*x)[50]; |
| 10:18:08 | braewoods | i think that's the right syntax |
| 10:19:31 | braewoods | yep it is |
| 10:20:02 | braewoods | speachy: for a more complete example: https://dpaste.com/D7JGV7MU5 |
| 10:20:18 | braewoods | can you name it now? |
| 10:21:03 | speachy | it's a pointer to a pointer. |
| 10:21:12 | braewoods | no, it's a pointer to an array. |
| 10:21:20 | braewoods | believe it or not those are different |
| 10:21:21 | speachy | (well, arrays are pointers) |
| 10:21:54 | amdj | arrays can be treated as pointers but that doesn't mean they are pointers. |
| 10:21:55 | speachy | if you'd left off the * it would still be a pointer. |
| 10:22:36 | speachy | it would just point to the first element of the array insted of pointing at the pointer to the first element of the array. |
| 10:23:03 | braewoods | pointers to arrays are a different language construct. the compiler considers them different at least. |
| 10:23:13 | braewoods | true arrays decay to pointers |
| 10:23:18 | braewoods | but this is different.. |
| 10:23:18 | speachy | (ie; int x[50]; int *y = x ; int **z = x;) |
| 10:23:43 | braewoods | though in practice it's kinda useless |
| 10:23:54 | braewoods | no one uses the pointer to array construct |
| 10:23:54 | speachy | as a static construct it is useless |
| 10:23:55 | amdj | the declaration like that (`int (*x)[50]` vs `int **x') carries array type information. you can treat both objects the same way, but the compiler won't. |
| 10:24:14 | braewoods | indeed. |
| 10:26:44 | braewoods | here's one of my favorite weird constructs C99 introduced |
| 10:26:46 | braewoods | https://dpaste.com/5C78HRKR4 |
| 10:26:53 | braewoods | array parameters |
| 10:27:02 | amdj | I like static. |
| 10:27:05 | speachy | I'm not a fan of using array types as part of an API. |
| 10:27:07 | amdj | (in parameter context) |
| 10:27:21 | braewoods | amdj: what use does it serve? i've only ran into once in stack overflow |
| 10:27:23 | braewoods | but not in real code |
| 10:27:50 | braewoods | all APIs i've seen still do |
| 10:27:56 | braewoods | void* s, size_t n |
| 10:27:58 | braewoods | or so |
| 10:28:12 | amdj | if you put it in your declaration (as opposed to just your definition −− if it's in the definition only, it has no effect, unless the function is internal to that compilation unit), it signals to callers that the argument must be non-null and be an array of at least that many elements. |
| 10:28:38 | braewoods | does it produce meaningful compiler messages? |
| 10:28:44 | amdj | so e.g. static void foo(int a[static 4]) { } int main(void) { int a[] = { 1, 2, 3 }; foo(a); /* warning: callee requires at least 4 elements, only 3 passed */ } |
| 10:29:28 | amdj | I brought this up a few weeks ago on an unrelated article |
| 10:29:31 | amdj | https://news.ycombinator.com/item?id=24459119 |
| 10:29:31 | braewoods | are you sure about that? GCC doesn't seem to warn at all. |
| 10:29:43 | braewoods | using GCC 7 |
| 10:30:12 | amdj | I only build with `clang -Weverything` (which actually does what that implies). gcc may need `-Wall -Wextra`. |
| 10:30:23 | amdj | (which still doesn't enable all diagnostics) |
| 10:30:42 | speachy | ... and also an appropriate -std=... |
| 10:30:54 | amdj | clang and gcc default to C99 these days unless you have some ancient version. |
| 10:31:00 | amdj | GCC 10 defaults to C11 I think. |
| 10:31:43 | braewoods | nothing on gcc 7 |
| 10:31:46 | braewoods | i'll try Focal |
| 10:32:57 | braewoods | just uh thought the construct was useless since no warnings were ever produced |
| 10:33:16 | amdj | yeah looks like gcc doesn't diagnose it. |
| 10:33:17 | amdj | that's annoying. |
| 10:33:34 | amdj | https://paste.debian.net/plainh/387d8d9d |
| 10:33:48 | *** | Saving seen data "./dancer.seen" |
| 10:34:03 | amdj | (gcc 9) |
| 10:34:09 | amdj | 10 might do it. I don't have it. |
| 10:34:20 | braewoods | you use debian? |
| 10:34:27 | amdj | linux mint |
| 10:34:31 | braewoods | the debian edition? |
| 10:34:34 | amdj | no |
| 10:34:34 | braewoods | or the regular? |
| 10:34:41 | braewoods | ok. |
| 10:34:43 | amdj | I have gcc-10 package |
| 10:34:45 | amdj | trying that now |
| 10:35:12 | amdj | aaron@tornado:~$ gcc-10 -Wall -Wextra -Wpedantic demo.c -o demo |
| 10:35:12 | amdj | aaron@tornado:~$ |
| 10:35:12 | amdj | nada. |
| 10:35:16 | amdj | how useless. |
| 10:35:19 | | Quit massiveH (Quit: Leaving) |
| 10:35:23 | amdj | lesson learned: just use clang. |
| 10:35:23 | braewoods | weird. |
| 10:35:40 | braewoods | i still prefer gcc but for some features... |
| 10:35:45 | braewoods | it seems clang is better |
| 10:36:00 | amdj | works even without any -W |
| 10:36:13 | braewoods | apparently -Warray-bounds works differently |
| 10:36:15 | amdj | https://paste.debian.net/plainh/27a917b6 |
| 10:37:17 | amdj | so anyway if you write some function that iterates over an array at least n times or writes at least n elements to an array argument, declaring it [static n] signals to the compiler to diagnose when it detects that a too-small array is passed, which can compile-time catch some things that would be a run-time buffer overrun. |
| 10:37:39 | amdj | (even across compilation units) |
| 10:37:49 | amdj | (and without LTO) |
| 10:38:59 | braewoods | seems it was fixed... |
| 10:39:01 | braewoods | in GCC 11 |
| 10:39:04 | braewoods | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584 |
| 10:39:19 | amdj | it also signals that the array argument should never be null which means the optimiser can elide a if (arg == NULL) { } branch. |
| 10:39:32 | amdj | whether you consider this a feature or not is up to you ... |
| 10:39:45 | braewoods | i can see one obvious use... |
| 10:39:54 | braewoods | declaring what kind of pointer you're wanting |
| 10:40:00 | braewoods | in terms of |
| 10:40:09 | braewoods | number of elements and that it is non-null |
| 10:40:16 | amdj | yes it does that. |
| 10:40:24 | braewoods | e.g., |
| 10:40:28 | braewoods | int arr[static 1] |
| 10:40:40 | amdj | so for example as opposed to __attribute__((__nonnull__)) you can use ..... yes that instead of `int *arr' |
| 10:40:53 | braewoods | and it's standard |
| 10:40:55 | braewoods | so |
| 10:41:01 | braewoods | no extensions required |
| 10:41:04 | amdj | well gcc and clang both support the nonnull attribute. |
| 10:41:08 | braewoods | indeed |
| 10:41:11 | braewoods | but in theory |
| 10:41:13 | braewoods | portable |
| 10:41:18 | braewoods | more portable |
| 10:41:27 | braewoods | i prefer standard features whenever possible myself |
| 10:41:43 | braewoods | if you later need to port to a different compiler |
| 10:41:46 | braewoods | it can make your life a lot easier |
| 10:41:50 | amdj | clang supports some pretty fantastic function attributes |
| 10:42:01 | braewoods | though i can't see anyone needing to use anything besides gcc / clang |
| 10:42:06 | braewoods | especially in C land |
| 10:42:14 | braewoods | last I checked MSVC sucks at C anyway |
| 10:42:22 | braewoods | they prefer to focus on C++ |
| 10:42:34 | speachy | isn't the current iteration of MSVC++ now an LLVM wrapper anyway? |
| 10:42:39 | braewoods | no idea |
| 10:42:44 | braewoods | if it is, why do they bother? |
| 10:42:48 | amdj | static void foo(int a)__attribute__((__diagnose_if__(!a, "bar", "error"))); /* ... */ int main(void) { foo(NULL); } -> error: bar (compilation terminated) |
| 10:43:03 | amdj | (clang only) |
| 10:43:16 | speachy | backwards compatibility with their cmdline syntax and "features" |
| 10:43:29 | braewoods | speachy: have you tried C99 variadic macros? |
| 10:43:39 | braewoods | i've found them useful for replacing some types of variadic functions |
| 10:43:46 | speachy | yep, pretty sure we use them in rockbox too |
| 10:44:14 | braewoods | i wrote a few hacks to use thm |
| 10:44:18 | braewoods | them |
| 10:44:34 | braewoods | like a macro that counts the number of variable arguments you pass |
| 10:44:45 | braewoods | it could support up to 63 arguments since the standard guarantees up to 127 |
| 10:45:51 | braewoods | it was an alternative to needing a sentinel value to terminate the argument list I had turned into an array thanks to compound literals |
| 10:46:13 | braewoods | instead i could pass the size eliminating the need for sentinel values |
| 10:46:15 | speachy | I try not to be terribly clever in my code constructs. |
| 10:46:19 | braewoods | lol |
| 10:46:23 | braewoods | i understand |
| 10:46:29 | speachy | becasuse I'm by definition not going to be clever enough to debug them. |
| 10:46:40 | braewoods | i just thought it was impressive what you could do with the CPP |
| 10:46:56 | braewoods | how many layers of macro hacks you need to get certain stuff done |
| 10:47:23 | amdj | gcc's preprocessor is turing complete :) |
| 10:47:24 | braewoods | P99 is amusing but i could never use it in a project. |
| 10:47:33 | braewoods | QPL is a bad license |
| 10:48:25 | | Quit kugel (Ping timeout: 240 seconds) |
| 10:48:56 | braewoods | oh |
| 10:49:00 | braewoods | they've relicensed it |
| 10:49:02 | braewoods | to Apache |
| 10:51:33 | | Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) |
| 10:51:33 | | Quit kugel (Changing host) |
| 10:51:33 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 10:53:56 | amdj | sorry, meant `int *a' in my example above. missed the * |
| 10:54:19 | amdj | that would still work out though along with a diagnostic for converting a pointer to an integer. |
| 10:58:13 | braewoods | amdj: lol. if i use '&' to get a pointer to a scalar the array check doesn't even run. |
| 10:59:17 | braewoods | apparently pointers don't get checked |
| 10:59:23 | braewoods | only if it was an actual array |
| 10:59:46 | amdj | yeah but that just goes back to the whole "arrays aren't actually pointers" thing |
| 10:59:53 | braewoods | indeed but in practice |
| 11:00 |
| 11:00:06 | braewoods | a pointer to a scalar is no different from an array of 1 element |
| 11:00:29 | braewoods | just amusing more than anything i guess |
| 11:00:36 | amdj | :) |
| 11:00:44 | braewoods | to use this i'd basically have to use an array for everything |
| 11:01:05 | braewoods | which is impractical... dynamic arrays always accessed through a pointer |
| 11:01:24 | braewoods | so yea |
| 11:01:27 | braewoods | limited utility |
| 11:01:45 | braewoods | seems mainly useful for when you're writing to a fixed size array |
| 11:01:52 | braewoods | of up to a certain size |
| 11:02:05 | braewoods | i rarely need to do that |
| 11:02:20 | braewoods | no wonder i never see this in real code |
| 11:02:45 | amdj | yeah, like, if you're writing a function to hash something, then you would want it to be e.g. [static 32] for SHA2-256. because if you pass a smaller buffer it will blow up. or run towers of hanoi. or any other undefined behaviour. so you'd want a diagnostic if you pass an unsigned char[20]. |
| 11:05:48 | | Quit petur (Quit: Connection reset by beer) |
| 11:06:08 | amdj | (if you don't get the reference: https://feross.org/gcc-ownage/ ) |
| 11:08:23 | amdj | a lot of people don't know you can also include all the other qualifiers inside the [] as well |
| 11:08:31 | amdj | e.g. static void foo(int a[const restrict static 5]) |
| 11:08:47 | braewoods | ... |
| 11:08:57 | braewoods | seriously? restrict isn't even valid for non-pointer types... |
| 11:09:15 | amdj | yeah but arrays as function parameters decay to pointers as I'm sure you know. |
| 11:09:28 | braewoods | but in that context it looks like it applies to the 5 |
| 11:09:39 | braewoods | normally restrict is applied to the type |
| 11:09:44 | braewoods | not inside []s |
| 11:10:04 | braewoods | for that matter almost no one uses restrict either |
| 11:10:13 | braewoods | then again i can't see many places where it's useful |
| 11:10:20 | amdj | nah, in *practice* static void foo(int *restrict a, int *restrict b) is equivalent to static void foo(int a[restrict 1], int b[restrict 1]) |
| 11:10:49 | amdj | I guess you could even take the 1 out. |
| 11:11:22 | amdj | likewise static void foo(int a[const 1]) is in practice the same as static void foo(int *const a) |
| 11:12:02 | braewoods | but very few people use []s in array parameters |
| 11:12:09 | braewoods | since they decay to pointers in most contexts |
| 11:12:15 | amdj | you just get diagnostics for the array variety if you pass other sized arrays (again going back to how the compiler treats array declarations differently to pointers) |
| 11:12:20 | braewoods | static is the only case where the compiler actually cares |
| 11:12:28 | braewoods | that i can tell |
| 11:13:40 | amdj | magical funtime useless totally over-the-top edition: static void foo(int a[volatile const restrict static 5]) |
| 11:13:51 | amdj | :D |
| 11:16:44 | amdj | (if you don't believe me: https://paste.debian.net/plainh/a6cdbe79 ) |
| 11:18:16 | amdj | yeah not every qualifier will have an effect (e.g. restrict does nothing here because there's only one function parameter anyway) but they're all legal. |
| 11:19:47 | amdj | I guess it might be nice to get diagnostics for unused qualifiers ... |
| 11:20:05 | braewoods | _Generic is pretty fun |
| 11:20:15 | braewoods | it has potential |
| 11:20:29 | braewoods | but PITA at times... |
| 11:20:43 | braewoods | makes me feel like it was intended to be used with some kind of generated headers |
| 11:20:56 | braewoods | e.g., to simulate overloading |
| 11:21:07 | amdj | I haven't played around with generics |
| 11:21:27 | braewoods | it basically lets you return some type of value at compile time based on the type of an expression |
| 11:21:36 | braewoods | it can be nearly anything |
| 11:21:53 | braewoods | integers (maybe mapping types to an enum) |
| 11:22:08 | braewoods | string literals too |
| 11:22:17 | _bilgus__ | speachy lua doesn't use its own alloc it uses the implementation on device and yes pretty sure TLSF does some pooling but I'm not sure how sophisticated it is |
| 11:22:57 | braewoods | but i mainly see it used to map the type to the appropriate functions |
| 11:23:26 | braewoods | since you can use it to choose a function by name |
| 11:23:35 | braewoods | and then reconstruct the function call |
| 11:23:41 | braewoods | via macro substitution |
| 11:28:28 | | Part bonfire ("Leaving") |
| 11:52:20 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 12:00 |
| 12:01:28 | fs-bluebot_ | Build Server message: New build round started. Revision ef34126, 282 builds, 9 clients. |
| 12:05:01 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
| 12:09:25 | | Quit ZincAlloy (Ping timeout: 240 seconds) |
| 12:12:15 | | Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:1809:d12b:b118:9706) |
| 12:13:38 | | Quit _bilgus__ (Ping timeout: 256 seconds) |
| 12:14:28 | | Quit pamaury (Quit: Konversation terminated!) |
| 12:16:22 | fs-bluebot_ | Build Server message: Build round completed after 895 seconds. |
| 12:16:26 | fs-bluebot_ | Build Server message: Revision ef34126 result: All green |
| 12:17:56 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:7813:762c:b17e:d8ff) |
| 12:22:43 | | Quit ZincAlloy (Ping timeout: 272 seconds) |
| 12:23:11 | | Quit _bilgus_ (Remote host closed the connection) |
| 12:25:08 | | Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:1809:d12b:b118:9706) |
| 12:33:49 | *** | Saving seen data "./dancer.seen" |
| 12:40:43 | | Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:fd9f:639a:c778:bcc1) |
| 12:43:27 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:759a:33c4:8b4:3a09) |
| 12:55:38 | | Join sakax [0] (~r0b0t@unaffiliated/r0b0t) |
| 13:00 |
| 13:17:29 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 13:43:02 | | Quit logbot (Remote host closed the connection) |
| 13:54:03 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 14:00 |
| 14:23:34 | speachy | The pine64 conversaion progressed further, btw. They're going to see if there's an existing case design they can purchase/reuse, and see what happens from there. |
| 14:33:53 | *** | Saving seen data "./dancer.seen" |
| 14:46:59 | _bilgus_ | cool with buttons?! |
| 14:47:20 | speachy | wasn't explicitly stated but yes, I believe so. |
| 14:50:05 | speachy | full conversation so far: www.shaftnet.org/~pizza/rb-p64.mbox |
| 14:54:23 | | Quit asaba (Quit: Relay server offline) |
| 14:54:46 | | Join asaba [0] (~asaba@103.113.159.184) |
| 15:00 |
| 15:22:44 | _bilgus_ | sounds juicy :) |
| 15:32:39 | speachy | I'm cautiously optimistic. The odds are good they'll be able to source a suitable case. My main concern is that we'll end up with vast overkill for a SoC. |
| 15:34:09 | speachy | Personally I'd prefer a modern MCU with a few megs of external DRAM over a multicore Cortex-A SoC with a couple hundred megs of DRAM. Though the latter is likely to be cheaper. |
| 15:37:16 | speachy | the overall HW design in that series of Zishan DSD players would be perfect; it only needs a couple of extra buttons and to swap that CPLD with external DRAM. |
| 15:42:01 | | Nick mendelmunkis is now known as mendel_munkis (~mendelmun@65-128-170-32.mpls.qwest.net) |
| 15:42:49 | mendel_munkis | in theory I would love to help write that port, in practice I would probably cause more bugs than I fixed. |
| 15:42:54 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 16:00 |
| 16:07:23 | | Quit livvy (Ping timeout: 240 seconds) |
| 16:18:39 | | Join MrZeus__ [0] (~MrZeus@2a02:c7f:70d0:6a00:fd9f:639a:c778:bcc1) |
| 16:23:28 | | Join tobbez_ [0] (tobbez@sagiri.wrya.net) |
| 16:25:55 | | Quit sh4 (Ping timeout: 244 seconds) |
| 16:25:55 | | Quit MrZeus_ (Ping timeout: 244 seconds) |
| 16:25:55 | | Quit tobbez (Ping timeout: 244 seconds) |
| 16:25:55 | | Quit ecs (Ping timeout: 244 seconds) |
| 16:25:55 | | Nick tobbez_ is now known as tobbez (tobbez@sagiri.wrya.net) |
| 16:26:34 | | Join ecs [0] (esawady@d2evs.net) |
| 16:30:23 | | Join sh4 [0] (shapeless@unaffiliated/sh4) |
| 16:33:56 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:10:55 | speachy | _bilgus_: here's my rough list of desired HW features in a Rockbox DAP: http://www.shaftnet.org/~pizza/rb-wishlist.txt |
| 17:11:11 | speachy | suggestions/corrections/alterations welcome. |
| 17:11:44 | mendel_munkis | Speachy: the first correction is not to 404. |
| 17:12:09 | speachy | moved into place, d'oh |
| 17:17:43 | mendel_munkis | has there been any work on bare metal bluetooth support? |
| 17:17:43 | | Quit lebellium (Quit: Leaving) |
| 17:18:21 | speachy | no, because we have no suitable hardware platform for it. |
| 17:19:05 | speachy | (I'd like a native X1000 port to the Rocker/X3ii/etc, after which a native BT stack port would be worth undertaking) |
| 17:19:16 | mendel_munkis | I didn't think so. |
| 17:22:04 | mendel_munkis | You say more than 64mb ram is wasted on a bare metal port. I once or twice hit ram exhaustion on Fuze+ |
| 17:23:10 | speachy | ... playing games or otherwise mucking about with plugins, I presume? |
| 17:23:29 | mendel_munkis | of course. |
| 17:23:53 | speachy | I mean, all else being equal more is better, but these MCUs tend to use older RAM types which are physically larger and more power hungry than more modern options. |
| 17:23:53 | mendel_munkis | I just think that a end user can be expected to use up to 128M |
| 17:24:25 | speachy | ie double the RAM, it's going to have a noticable impact on size/price/battery life |
| 17:26:40 | speachy | the max depends on the exact MCU and memory controller, but I think the largest SDRAM part one can get is 512MBit (ie 64MB) |
| 17:28:16 | speachy | and if you try to shove two of 'em on there you're probably going to find it overall cheaper to use a DDR-capable "full CPU" SoC. |
| 17:29:25 | mendel_munkis | maybe I'm wrong. I don't know too many people who use rockbox and my build is heavily modified so something could have been sucking ram without my realizing |
| 17:30:57 | speachy | (I'd be shocked if the X1000E that has 64MB embedded into the package costs more than a high-end STM32F7 with 64MB SDRAM) |
| 17:33:12 | speachy | that 64MB SDRAM alone is $13.54 by itself. |
| 17:33:51 | speachy | (whereas the same thing in DDR2 is $5.41) |
| 17:37:20 | speachy | and what I think is the minimal STM32H7 part to drive what I'd want is $6.84. |
| 17:38:59 | speachy | (in large quantities the prices will go down, but nearly $20 for your MCU + RAM starts you off in a shitty position. |
| 17:39:07 | mendel_munkis | If it's actually cheaper to get a better processor why go with a lower end one? |
| 17:39:08 | | Quit MrZeus__ (Read error: Connection reset by peer) |
| 17:39:28 | speachy | (in 2500K quantities, you're looking at ~$13.50 for the pair) |
| 17:39:55 | speachy | software complexity, lack of hardware peripherals that do what you want, etc |
| 17:40:37 | | Join MrZeus__ [0] (~MrZeus@90.203.212.4) |
| 17:40:48 | mendel_munkis | I guess I'll leave the design to people who actually have some clue what they are doing. |
| 17:41:37 | speachy | one of the reason the ingenic parts were so widely used is they embedded the DRAM into the package, enabling smaller pincount and PCBs. |
| 17:41:46 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 17:42:36 | speachy | we don't truly need realtime performance, but consider the overall system responsiveness of the Rocker vs the X3ii. The latter is half the raw speed yet is far more responsive and capable. |
| 17:42:58 | speachy | (mostly due to really crappy OS integration and overhead in the former) |
| 17:50:25 | | Quit sakax (Quit: Leaving) |
| 18:00 |
| 18:00:43 | speachy | going through this exercise pretty much demonstrates that an MCU-based platform isn't economically viable. |
| 18:01:43 | speachy | (general-purpose MCU, that is. the various ASICs like the PPs or the AS3525 technically had pretty-high-end MCUs in them..) |
| 18:10:31 | | Quit ZincAlloy (Quit: Leaving.) |
| 18:13:26 | speachy | _bilgus_: BTW, I don't know if I mentioned it but the Rocker is on its way to you. Post office said it will be there by Thursday. |
| 18:18:37 | genevino | fwiw don't start playing the untangle game on rockbox, it's highly addictive. |
| 18:19:24 | genevino | :) |
| 18:24:25 | | Quit pamaury (Ping timeout: 240 seconds) |
| 18:25:04 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 18:29:17 | | Quit petur (Quit: Leaving) |
| 18:33:05 | | Quit pamaury (Ping timeout: 240 seconds) |
| 18:33:59 | *** | Saving seen data "./dancer.seen" |
| 18:54:57 | fs-bluebot_ | Build Server message: New build round started. Revision c6f66cf, 282 builds, 9 clients. |
| 19:00 |
| 19:10:30 | fs-bluebot_ | Build Server message: Build round completed after 932 seconds. |
| 19:10:44 | fs-bluebot_ | Build Server message: Revision c6f66cf result: All green |
| 19:10:45 | fs-bluebot_ | Build Server message: New build round started. Revision 914114f, 282 builds, 9 clients. |
| 19:23:50 | fs-bluebot_ | Build Server message: Build round completed after 786 seconds. |
| 19:23:51 | fs-bluebot_ | Build Server message: Revision 914114f result: All green |
| 19:34:08 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 19:35:23 | | Join fs-bluebot [0] (~fs-bluebo@55d418c6.access.ecotel.net) |
| 19:37:24 | | Quit bluebrother^ (Ping timeout: 260 seconds) |
| 19:37:25 | | Quit fs-bluebot_ (Ping timeout: 240 seconds) |
| 19:41:07 | _bilgus_ | speachy I'll ask my mom to keep her eye out for it probably grab it sunday then |
| 19:41:45 | speachy | tweaked the WPS keymap a little just now |
| 19:42:06 | speachy | tbh the whole keymap really should be gone over. I'd intended to do that as part of the manual update |
| 19:42:31 | speachy | but for some reason I keep getting distracted with new hardware and their bugs.. |
| 19:49:54 | braewoods | speachy: https://assets.amuniversal.com/e55eaa906d5001301d7a001dd8b71c47 |
| 19:49:55 | braewoods | lol |
| 19:50:54 | _bilgus_ | speach looks good at first glance at least hardware wise |
| 19:56:29 | __builtin | genevino: hehe :) |
| 19:57:01 | __builtin | that one and cube are my favorites |
| 20:00 |
| 20:13:30 | * | __builtin has been meaning to clean up that SDL2 port eventually |
| 20:13:56 | __builtin | although my free time has all but dried up recently... |
| 20:15:31 | braewoods | __builtin: what's the benefit of SDL2 port? |
| 20:15:47 | braewoods | most of the time it's used for desktop stuff so... |
| 20:16:03 | braewoods | but why would i want to use rockbox there when there's plenty of native players? |
| 20:16:38 | __builtin | SDL is nice to quickly port over PC software |
| 20:16:49 | __builtin | we have an SDL1.2 port that hosts Quake, Duke3D and Wolf3D |
| 20:16:56 | __builtin | but most recent stuff runs on SDL2 |
| 20:17:20 | __builtin | (I'm specifically looking at a port of SDLPoP, a prince of persia remake) |
| 20:17:54 | __builtin | also, porting SDL2 was surprisingly easy because I'd already worked out most of the kinks with SDL1.2 |
| 20:19:01 | __builtin | g#2634 if you're interested |
| 20:19:58 | __builtin | I've gotten SDLPoP to boot and start gameplay, but something's locking up at that point |
| 20:22:28 | braewoods | i see |
| 20:24:11 | | Quit MrZeus__ (Ping timeout: 240 seconds) |
| 20:34:02 | *** | Saving seen data "./dancer.seen" |
| 20:37:12 | speachy | __builtin: what target? |
| 20:37:25 | * | braewoods paints a bullseye on the wall. |
| 20:37:28 | braewoods | "That target!" |
| 20:37:37 | _bilgus_ | speachy re 2808 I'd as soon put it in the context menu |
| 20:38:25 | speachy | _bilgus_: pitch adjustment is already in the context menu |
| 20:39:19 | speachy | __builtin: well, there's your problem, you're trying to run PoP on a target that can't fight back |
| 20:39:51 | braewoods | lol |
| 20:40:09 | __builtin | ipod6g |
| 20:40:24 | __builtin | I've only really tested sdl on the 6g, too |
| 20:40:26 | speachy | restructured the wishlist a bit, added physical sizing and more comments |
| 20:41:00 | mendel_munkis | doesn't bluebot usually callout gerrit links? |
| 20:41:11 | __builtin | it's supposed to |
| 20:41:19 | braewoods | maybe it's feeling blue today |
| 20:41:22 | speachy | wish I could find pricing info on the ingenic SoCs. |
| 20:41:36 | speachy | bluebot hasn't called this stuff out for at least a few days now |
| 21:00 |
| 21:39:15 | _bilgus_ | -Weeks- |
| 21:39:44 | _bilgus_ | well going on to weeks its been a little over a week |
| 21:41:37 | | Quit kugel (Ping timeout: 264 seconds) |
| 21:44:24 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 21:53:57 | | Quit CommunistWitchDr (Quit: Fuck this, I'm out) |
| 21:55:42 | | Join CommunistWitchDr [0] (quassel@024-217-039-226.res.spectrum.com) |
| 22:00 |
| 22:34:05 | *** | Saving seen data "./dancer.seen" |
| 22:36:11 | | Quit kugel (Ping timeout: 260 seconds) |
| 22:49:01 | | Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) |
| 22:49:01 | | Quit kugel (Changing host) |
| 22:49:01 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 22:52:13 | | Quit ac_laptop (Ping timeout: 260 seconds) |
| 22:55:52 | | Quit kugel (Ping timeout: 246 seconds) |
| 22:59:22 | | Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) |
| 22:59:22 | | Quit kugel (Changing host) |
| 22:59:22 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 22:59:40 | speachy | %#%#.. the Hifiwalker H2 purchase didn't go thorugh. But I found another seller that has three of 'em for only $50. |
| 23:00 |
| 23:00:41 | speachy | (2 available now, heh.. another has a open box model for $100, and still shrinkwrapped they're easy to find for $120. |
| 23:05:55 | | Quit TheSeven (Ping timeout: 240 seconds) |
| 23:06:16 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 23:26:56 | | Quit kugel (Ping timeout: 258 seconds) |
| 23:28:55 | | Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) |
| 23:28:55 | | Quit kugel (Changing host) |
| 23:28:55 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 23:29:10 | | Quit t0mato (Quit: Ping timeout (120 seconds)) |
| 23:40:30 | | Join t0mato [0] (~t0mato@193.32.127.158) |
icon identifies that the person is a core developer (has commit access).