IRC channel logs

2021-12-12.log

back to list of logs

<oriansj>hmm it looks like I never actually implemented memchr
<oriansj>for string.h
<oriansj>stikonas: you previously mentioned how you wanted to unify the Linux files using #ifdefs for M2libc
<oriansj>I guess no one used it, so it is probably safe to remove until we need to add it
<oriansj>here was my thought; rename from $ARCH/Linux/name.h to $ARCH/Linux/name.c and have a new name.h in the root directory with uses the arch to #include <$ARCH/Linux/name.c>
<oriansj>first half of M2libc update is done, need to think more clearly about the arch specific bits
<Hagfish> https://www.techradar.com/news/computing/moore-s-law-how-long-will-it-last-1226772 (published in 2014)
<Hagfish>"I pick about 2020 as the earliest we could call [Moore's Law] dead," said DARPA Director and Pentium processor architect Robert Colwell, when he spoke at the Hot Chips conference in 2013. "And I'm picking 7nm. You could talk me into 2022. You might even be able to talk me into 5nm. But you're not going to talk me into 1nm. I think physics dictates against that."
<stikonas>oriansj: yes, I think that way of doing arch specific bits should work
<stikonas>we might need to keep some preprocessor support in M2-Planet for it to work
<stikonas>but I think it's fine
<oriansj>Hagfish: I think the general agreement about moore's law is that it is about the number of transistors per dollar, which can continue to go up with yield improvements, density improvements, new multilayer technologies and 3D packing. The final area will just be those businesses cutting costs by elimination of staff
<oriansj>stikonas: yeah, just #define #ifdef and #ifndef should be sufficient in M2-Planet; which will certainly simplify things
<stikonas[m]>It will also reduce size of m2-planet a bit, now we are already starting to hit qemu crashes on aarch64
<stikonas[m]>Although, those should be properly solved in M0 by implementing scratch
<stikonas[m]>Well, first victim of Moore's law breaking was that frequency stopped increasing but despite that, performance still increases, just in other ways
<stikonas[m]>I guess we are already close to physical limits of CPU frequency
<stikonas[m]>If you take, e.g. 5Ghz, then in one cycle, light can only travel 6cm
<stikonas[m]>So close to CPU size
<oriansj>true M0 was just a rough approximation designed to be quickly implemented and some refinements probably will be needed
<stikonas>well, on riscv I used scratch for strings and it was fairly simple
<stikonas>ir was a fairly small diff: https://github.com/oriansj/stage0-posix/commit/d203bcc811afd0490013f973520885b353aaee4c#diff-0f88b5ad79a676522450321d75ae24cfb525a31016a8023405068f4c296df444
<stikonas>and ClearScratch taken from other files (I think hex2)
<oriansj>well yes, the problem is always getting the time to do these extras
<oriansj>but they do make wonderful easy tasks for new people who want to get their hands dirty on the low level work
<oriansj>stikonas: thanks for sorting out the multi-arch solution for M2libc when you did mes-m2 multi-arch
<stikonas[m]>You mean kaem files?
<stikonas[m]>I don't remember now what else I did...
<oriansj>stikonas: your mes.c work; you'll see it in the new sys/stat.h once it is up
<oriansj>and commit for M2libc is now up
<oriansj>now just to find time to do the M2-Mesoplanet #include support and the most requested feature will finally be done