01:56 <zmatt> I do stlil wonder why the heck the AM335x BSDL file refers to it as the "TI F781962A Fixed & Floating Point DSP"

03:13 <set_> @zmatt: When you said, circa '19, "I do not know about ascii and do not ask," were you saying to use wc instead in C/C++?

03:15 <set_> I have been reviewing, no heavy research here, C/C++ and I have been seeing a lot of people seemingly having trouble with wide characters. % is how I perceive the use of std I/O E in C/C++ to be called when using wc.

03:16 <set_> Does that sound correct?

03:19 <set_> I know it is past 10:00. I just wanted to reiterate that changes take place. I see the wc in future specs. of C/C++ do not know of what they will do just yet. "Workin w/ streams!"

03:22 <set_> Look!

03:22 <set_> ::: https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Wide-Character-Constants.html

03:35 <set_> Anyway, I read and learn. I try to apply still with specific boards from beagleboard.org. Heads up!

03:36 <set_> So, 0b instead of hexadecimal types like 0x are a GNU extension!

03:36 <set_> Yes!

03:36 <set_> Party in my mind!

04:24 <zmatt> set_: I have no idea what you're talking about

04:24 <zmatt> ignore "wide chars", they're an obsolete mistake

04:34 <zmatt> the only reason to ever touch wchar_t/wstring is if you have to deal with a legacy codebase that uses them... even Windows has proper UTF-8 support if I understand correctly (since Windows 10 May 2019 Update)

04:37 <zmatt> and if you do still need UTF-16 for something then u16string is the proper type for that, the meaning of wstring is platform-dependent making it particularly useless

05:16 <set_> oh

13:51 <Guest17>  zmatt the cpu not having a data prefetcher sounds *really* highky unlikely to me. It is not uncommon for this to barely be documented

13:52 <Guest17> zmatt yes I initialized the array with values, invalidated the entire cache via a syscall to go to my own kernel space driver where I invalidate everything and then traverse it in userspace

13:53 <Guest17> zmatt exactly this: https://pastebin.com/fHTYMxdU

13:55 <Guest17> zmatt if you don't know, do you know about anybody in this room who would be able to provide some input?

18:35 <zmatt> Guest17: no I would definitely expect such a thing to be documented in the TRM, especially for these older ARM cores

18:36 <zmatt> e.g. the Cortex-A9 TRM does have a documented prefetcher

18:37 <zmatt> https://developer.arm.com/documentation/ddi0388/i/level-1-memory-system/data-prefetching/data-prefetching

18:39 <zmatt> the Cortex-A15 TRM has it too: https://developer.arm.com/documentation/ddi0438/i/level-2-memory-system/l2-cache-prefetcher

18:40 <zmatt> the Cortex-A7 TRM documents auto-prefetching

18:40 <zmatt> the Cortex-A5 TRM too

18:41 <zmatt> ditto Cortex-A17 and -A53

18:47 <zmatt> I'm pretty sure the lack of mention of such a thing in the Cortex-A8 TRM is simply because it doesn't have it

18:50 <zmatt> the -A8 is the oldest ARM Cortex-A processor, uses in-order execution, static scheduling, no speculative execution

18:53 <zmatt> I think the only speculation it does is branch prediction and speculative instruction prefetch

19:12 <zmatt> to put it in perspective... the processor family before the Cortex-A8 was the ARM11, which were ARM Architecture v6 ... which doesn't even mention the possibility of automatic/speculative data prefetching

19:12 <zmatt> in the architecture reference manual

19:23 <zmatt> in that era "prefetching" almost exclusively refers to instruction prefetch. the only data prefetch is the optional "Prefetch Data Range" instruction (which either loads a range or cache either synchronously or asynchronously, and in the latter case you can query its completion or cancel it, so it's kinda like a basic precursor of the Cortex-A8's PLE)

19:23 <zmatt> *which loads a range into cache

20:28 <Guest17> zmatt didn't know this history. Helps to put things in perspective, thanks!

20:29 <Guest17> Hopefully the raspberry p3 model B has a data prefetcher and does some speculative execution, this would allow me to at least go forward

20:29 <Guest17> otherwise I'll have to order a new board with another chip and I'll probably loose a week or 2