00:07:04 | _bilgus_ | braewoods, turns out the issue is IDATA_ATTR I can't figure out what the issue is only that it makes the display flaky AF |
00:08:31 | _bilgus_ | and it does indeed initialize properly −− and the same memory loation is not getting stomped by a stackovfl |
00:09:45 | | Quit J_Darnley (Ping timeout: 272 seconds) |
00:12:42 | _bilgus_ | oh maybe the issue is that we are trying to copy data to the address I bet something is copying data to the pointer |
00:13:10 | _bilgus_ | instead of the region pointed |
00:26:54 | *** | Saving seen data "./dancer.seen" |
00:30:24 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
00:34:43 | _bilgus_ | yep I'm stumped thats not the case either |
00:56:53 | _bilgus_ | Well apparently it needs to be an address divisible by 8 |
01:00 |
01:34:05 | _bilgus_ | g#3253 |
01:34:07 | fs-bluebot_ | Gerrit review #3253 at https://gerrit.rockbox.org/r/c/rockbox/+/3253 : lcd framebuffer - Bugfix ensure proper alignment by William Wilgus |
02:00 |
02:26:56 | *** | No seen item changed, no save performed. |
02:35:14 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
02:35:14 | | Quit pixelma (Quit: .) |
02:37:41 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
02:37:41 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
03:00 |
03:23:48 | | Quit ac_laptop (Ping timeout: 245 seconds) |
04:00 |
04:26:59 | *** | Saving seen data "./dancer.seen" |
05:00 |
05:30:14 | | Quit dweeber (Ping timeout: 256 seconds) |
05:48:39 | braewoods | _bilgus_: weird indeed |
05:49:09 | braewoods | on the brightside it may just be that this target is more picky? |
05:49:26 | braewoods | even so alignment on 8 won't break it for stuff that onlys 4 |
06:00 |
06:27:03 | *** | Saving seen data "./dancer.seen" |
06:46:11 | speachy | _bilgus_: is it really ARM-specific, or unique to whatever DMA controller the H10 uses? (The PP series, I suppose?) |
06:46:48 | speachy | I mean, is it just a massive coincidence that all of the other PP targets (ipods!) work? |
06:48:01 | speachy | or I guess the alignment attr was lost when you did the viewport rewrite? |
06:55:32 | braewoods | one way to find out |
06:55:41 | braewoods | check how it worked in the old code |
07:00 |
07:03:15 | speachy | pre-rewrite it wasn't aligned either. |
07:04:17 | braewoods | boggle |
07:15:04 | speachy | stranger things have JustWorked(tm) until they didn't. |
07:15:41 | speachy | anyway. I suppsoe this "fix" is, at worst, a harmless no-op. |
07:16:08 | braewoods | it's also possible it just happened to be aligned before by pure chance |
07:16:41 | braewoods | time to look into it a bit |
07:17:26 | braewoods | DMA is usually part of the cpu from what i recall |
07:19:46 | braewoods | _bilgus_: it may just be specific to the H10 |
07:19:51 | braewoods | if so just enable for both H10 ports |
07:20:02 | braewoods | since i assume both would have the same issue |
07:20:57 | speachy | braewoods: Where this gets odd is that the H10 uses the same SoC as many iPods. |
07:21:06 | braewoods | indeed |
07:21:22 | speachy | and if those were broken, we'd hear a _lot_ of complaints. :) |
07:31:26 | speachy | so, g#3254 is a fix for something that's annoyed me as long as I can recall |
07:31:28 | fs-bluebot_ | Gerrit review #3254 at https://gerrit.rockbox.org/r/c/rockbox/+/3254 : build: Don't overwrite autoconf.h unless it has actually changed by Solomon Peachy |
07:31:43 | speachy | I _think_ it's safe. |
07:32:15 | speachy | adds a dependency on 'diff' but if that's not present it'll effectively fall back to the old behavior. |
07:32:45 | braewoods | you know what you could use instead of diff? |
07:32:46 | braewoods | cmp |
07:33:07 | braewoods | it's for binary files but identical files will compare the same regardless |
07:33:21 | speachy | it's part of diffutils so |
07:33:32 | speachy | ... so just as likely to be present (or not) as diff |
07:33:46 | braewoods | oh |
07:33:58 | braewoods | i thought it was part of coreutils |
07:34:07 | braewoods | silly me |
07:40:06 | braewoods | speachy: you can use cksum or sum and compare those string outputs |
07:40:11 | braewoods | if you think it matters that much |
07:40:22 | braewoods | but it shouldn't |
07:40:27 | braewoods | pretty much everyone should have diff |
07:40:41 | speachy | the advantage of cksum is that it's coreutils. |
07:40:45 | braewoods | yea |
07:40:48 | braewoods | same with sum |
07:41:01 | braewoods | i also learned about cal commnad |
07:41:04 | braewoods | awhile back |
07:41:06 | speachy | but it makes the code more complicated as I have to capture two sets of output and compare the results explicitly. |
07:41:20 | braewoods | just use cmp -s then |
07:41:28 | braewoods | it doesn't produce output |
07:41:49 | braewoods | i used to use it a lot |
07:41:52 | speachy | cmp -s and diff -u are functionally equivalent |
07:41:55 | speachy | diff -q |
07:41:58 | braewoods | oh |
07:41:59 | braewoods | i see |
07:42:16 | speachy | ie generating an error return code if the files differ |
07:52:55 | | Join dweeber [0] (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net) |
08:00 |
08:26:28 | braewoods | speachy: i was looking at modern USB connectors. wow they're such a complex soup now. |
08:26:34 | braewoods | 2.0 just had 4 pins |
08:26:42 | braewoods | 3.0 had 9 pins or so |
08:26:48 | braewoods | then type c introduce 3 more |
08:27:05 | *** | No seen item changed, no save performed. |
08:33:42 | speachy | and then mirrors them |
08:39:34 | braewoods | just wiring usb today is rather daunting |
08:39:51 | braewoods | so i probably won't be making any custom cables unless it doesn't require modern USB features |
08:42:10 | braewoods | and some of the new pins have tx/rx lines so i'm thinking to myself |
08:42:41 | braewoods | did they reinvent ethernet / serial in the wiring? |
08:42:59 | braewoods | rs232 or w/e |
08:46:22 | speachy | USB-C has a few extra signaling/sense lines but they doubled everything in order to make it reversible. |
08:46:49 | speachy | later versions of the spec take advantage of the doubled-everything to provide considerably more bandwidth. |
08:55:44 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
08:59:30 | braewoods | speachy: from what i can tell that's mainly used for negotiating the VCC voltage |
08:59:36 | braewoods | for USB PD |
09:00 |
09:00:03 | braewoods | i needed to run a cable for an internal usb type c female port |
09:00:07 | braewoods | for PD only |
09:00:09 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-916e-5a4e-8124-fcb4.res6.spectrum.com) |
09:00:22 | braewoods | i ended up deciding a panel mount extension cable was the best way |
09:00:32 | braewoods | since wiring for PD seemed rather involved |
09:00:47 | braewoods | and i could find no easy ways to solder to a male connector internally |
09:01:11 | braewoods | they usually lacked the CC1 or CC2 pins |
09:02:54 | _bilgus_ | braewoods i've run into this 8 byte alignment bug several times with arm |
09:03:09 | _bilgus_ | i'n several places and situs as well |
09:03:40 | braewoods | maybe the issue is variations in chips |
09:03:50 | braewoods | even though it's only supposed to be 8 |
09:03:54 | braewoods | err |
09:03:57 | braewoods | 4 |
09:04:34 | braewoods | lucky me that it's easier to cut out a hole for type c than type A |
09:04:42 | _bilgus_ | it could also be a gcc bug |
09:04:51 | braewoods | hard to know |
09:05:06 | braewoods | we should probably upgrade the toolchain again after the next stable release |
09:05:34 | _bilgus_ | i'm gonna align them all though it should be slightly faster at bst and exactly the same with a bit of waste |
09:05:49 | _bilgus_ | at worst |
09:06:28 | braewoods | since type C is rounded i can use a drill to cut out the sides and then work my way over |
09:06:59 | braewoods | no corners to cut out too |
09:07:02 | _bilgus_ | yeah some of those diamond burrs on a dremel |
09:07:15 | _bilgus_ | thats a good point |
09:07:38 | _bilgus_ | USB-C −− Now Hacker Friendly! |
09:08:39 | braewoods | yea, i originally tried running a regular cable but i realized my cable gland won't fit over one or seal right |
09:08:56 | braewoods | the connector is just too wide relative to the cable's size |
09:09:12 | braewoods | unless the 5A cables are thick enough... |
09:09:19 | braewoods | i tested with 3A cables |
10:00 |
10:20:16 | | Quit mikroflops (Ping timeout: 240 seconds) |
10:20:59 | | Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) |
10:27:07 | *** | Saving seen data "./dancer.seen" |
10:27:42 | | Quit massiveH (Quit: Leaving) |
10:29:27 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
11:00 |
11:52:08 | | Quit daswf852 (Ping timeout: 245 seconds) |
11:54:45 | braewoods | speachy: it would be interesting to support dual devices for ATA targets with software USB stack... |
11:54:53 | braewoods | but i doubt many would use it |
11:55:09 | braewoods | but i see CF adapters that can take 2 cards, one for master and one for slave |
12:00 |
12:06:22 | | Join daswf852 [0] (~daswf852@unaffiliated/dwf) |
12:27:09 | *** | Saving seen data "./dancer.seen" |
12:28:18 | | Quit J_Darnley (Ping timeout: 265 seconds) |
12:30:18 | | Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) |
12:47:48 | | Quit M-iam-some0nee[m (Ping timeout: 260 seconds) |
12:50:46 | | Join M-iam-some0nee[m [0] (m-iam-some@gateway/shell/matrix.org/x-nelgeyqrtkabkbzj) |
13:00 |
13:30:10 | _bilgus_ | that would be nice with cf cards topping out at 128gb for $$ |
14:00 |
14:00:22 | | Quit emacsomancer (Quit: WeeChat 3.0.1) |
14:01:26 | | Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) |
14:07:52 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
14:10:22 | speachy | braewoods: assuming the actual controllers supported the master/slave distinction, there's still the problem of physically fitting them in the case. |
14:10:58 | speachy | makes far more economic sense to use SD card adapters instead.. |
14:16:14 | _bilgus_ | braewoods, ROLO works for the h10 now as well |
14:22:04 | fs-bluebot_ | Build Server message: New build round started. Revision ffee661ab7, 293 builds, 10 clients. |
14:27:10 | *** | Saving seen data "./dancer.seen" |
14:27:15 | speachy | anyone think of a reason to not merge g#3254? |
14:27:17 | fs-bluebot_ | Gerrit review #3254 at https://gerrit.rockbox.org/r/c/rockbox/+/3254 : build: Don't overwrite autoconf.h unless it has actually changed by Solomon Peachy |
14:29:29 | braewoods | _bilgus_: ah, good |
14:32:24 | | Quit Saijin_Naib (Read error: Connection reset by peer) |
14:33:48 | fs-bluebot_ | Build Server message: Build round completed after 705 seconds. |
14:33:54 | fs-bluebot_ | Build Server message: Revision ffee661ab7 result: 4 errors 0 warnings |
14:34:47 | braewoods | _bilgus_: something broke? |
14:36:27 | _bilgus_ | yep |
14:37:19 | _bilgus_ | uh oh |
14:37:46 | braewoods | where even are the build logs? |
14:37:52 | _bilgus_ | i audio m5 `IRAM' overflowed by 48 bytes |
14:38:09 | _bilgus_ | build.rockbox.org |
14:38:29 | speachy | braewoods: https://build.rockbox.org/dev.cgi |
14:39:43 | _bilgus_ | hmm I'm gonna have to revert this for now till I can look at it closely |
14:40:00 | braewoods | was it that close to the limit before? |
14:40:08 | _bilgus_ | clearly |
14:40:28 | braewoods | maybe we can consolidate memory storage to reduce waste to padding |
14:40:31 | _bilgus_ | figure that 32 byte alignment could potentially consume 64 bytes |
14:40:45 | speachy | I recall having to play games with the M5 in the past to keep it building |
14:40:52 | _bilgus_ | it only needs 8 but the 32 byte one is what is already existing |
14:41:15 | braewoods | it would be nice if the IRAM segments could tell us how much is wasted on padding |
14:41:43 | _bilgus_ | and that will be my ultimate fix most likely but I just don't have the time ATM to test so i'll revert and revisit it tonight |
14:42:09 | braewoods | we may have to drop some of these old ports if they're limiting our ability to fix stuff |
14:42:10 | _bilgus_ | they do |
14:42:17 | braewoods | _bilgus_: how would we find out? |
14:42:24 | _bilgus_ | map file |
14:42:30 | _bilgus_ | it shows the addresses |
14:42:34 | braewoods | i see |
14:42:42 | speachy | _bilgus_: even when it doesn't successfully link? |
14:43:10 | braewoods | it may be a good idea to go through the compiled code and see if we can reduce our IRAM requirements somehow |
14:43:19 | _bilgus_ | yeah probably not is't the map file after that step |
14:45:19 | _bilgus_ | well we can always kick the current fb out of iram |
14:45:21 | speachy | well, one option is to slightly shrink the global stack |
14:45:36 | speachy | and then look at the map |
14:46:08 | fs-bluebot_ | Build Server message: New build round started. Revision ed99b305a9, 293 builds, 10 clients. |
14:46:30 | speachy | braewoods: the m68k coldfire parts don't have a data cache, so IRAM makes a huge difference. |
14:46:47 | _bilgus_ | I'll look at it this eve and decide what to do |
14:47:03 | braewoods | speachy: i was just thinking if we could reduce waste or so |
14:49:01 | | Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be) |
14:49:27 | | Quit J_Darnley (Ping timeout: 258 seconds) |
14:49:51 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-4c82-9f74-1509-a3ce.res6.spectrum.com) |
14:49:58 | | Quit Saijin_Naib (Read error: Connection reset by peer) |
14:50:06 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-4c82-9f74-1509-a3ce.res6.spectrum.com) |
14:56:33 | fs-bluebot_ | Build Server message: Build round completed after 625 seconds. |
14:56:36 | fs-bluebot_ | Build Server message: Revision ed99b305a9 result: All green |
14:56:37 | fs-bluebot_ | Build Server message: New build round started. Revision a53864ed4a, 293 builds, 10 clients. |
15:00 |
15:10:09 | fs-bluebot_ | Build Server message: Build round completed after 812 seconds. |
15:10:12 | fs-bluebot_ | Build Server message: Revision a53864ed4a result: All green |
15:20:57 | | Quit braewoods (Quit: WeeChat 2.8) |
15:26:42 | | Join braewoods [0] (~braewoods@learnprogramming/staff/braewoods) |
15:43:48 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
15:44:27 | | Quit jdarnley (Ping timeout: 256 seconds) |
16:00 |
16:27:11 | *** | Saving seen data "./dancer.seen" |
16:27:43 | | Quit CR0W (Ping timeout: 260 seconds) |
16:28:39 | | Join CR0W [0] (~narf@rrcs-67-53-148-69.west.biz.rr.com) |
16:28:40 | | Quit CR0W (Changing host) |
16:28:40 | | Join CR0W [0] (~narf@unaffiliated/em64t) |
16:56:26 | braewoods | i can't help but think we could save some memory by cutting down the lcd viewport struct but int usage is everywhere already |
16:56:52 | braewoods | but in my experience i've never known a viewport to have more 32k pixels in either direction |
16:57:00 | braewoods | so 32 bits seems a bit excessive for that |
17:00 |
17:08:26 | speachy | yeah, seems that x/y/w/h could get cut down to shorts, flags and fonts too. drawmode might take some rejiggering. |
17:08:31 | speachy | but. |
17:08:55 | braewoods | part of the issue is wasted memory on alignment |
17:08:56 | speachy | on the x3 (mips), changing those things to shorts actually makes the code size go up. |
17:09:15 | speachy | with no reduction in RAM use. |
17:09:36 | speachy | let's see what the mini2g does. |
17:10:34 | speachy | went up slightly there too. |
17:10:48 | braewoods | hm |
17:11:05 | speachy | (by 48 bytes) |
17:11:13 | speachy | that's purely changing the struct viewport |
17:11:56 | speachy | could be the compiler is not packing the structure, prefering to align everything to 32-bit native. |
17:12:12 | braewoods | gcc lacks -Wpadding in the release we use |
17:12:15 | braewoods | so hard to know |
17:12:55 | speachy | we have it optimizing for code size right now |
17:13:29 | speachy | rebuilding it for the m5 (m68k) |
17:13:52 | speachy | heh, moving to shorts, and it no longer fits in IRAM (by 16 bytes from whatever it used to be) |
17:14:11 | braewoods | probably would need to reorder the struct |
17:14:16 | braewoods | let me check something |
17:14:43 | braewoods | no... it shouldn't need to align for that |
17:15:01 | braewoods | going from 4 4s to 4 2s |
17:15:12 | braewoods | still 4 byte aligned |
17:15:38 | speachy | it makes the code larger, and we put the LCD code into IRAM as it's so performance critical |
17:16:02 | braewoods | why would the viewport pointer care about the alignment... |
17:16:15 | braewoods | it's a mystery to me |
17:17:34 | speachy | unique LCD driver code in the h10 port. |
17:17:42 | speachy | doing something the other PP targets don't. |
17:19:16 | speachy | the M5 has that external lcd IIRC? |
17:19:33 | braewoods | the remote? |
17:19:43 | braewoods | no idea if it does |
17:19:44 | braewoods | let's check |
17:20:52 | braewoods | it does have one |
17:22:37 | speachy | yeah... it has the framebuffers for both the main screen and external screen in iram |
17:25:43 | speachy | IRAM on the m5 is _completely_ full. |
17:27:36 | speachy | it's 50KB in size. 10KB of which is used by code, the rest is data structures (stacks and framebuffers being the largest single users) |
17:27:47 | speachy | to make it fit last time I shrank the general stack a little. |
17:30:30 | speachy | 8K total for framebuffers, 9K for the codec stack, 4.3K for audio mixing buffers.. 2.6K for thread structures.. |
17:30:53 | speachy | Just shy of 8K for the main stack |
17:33:38 | braewoods | funny thing is stacks are usually larger than strictly required |
17:33:40 | braewoods | so |
17:33:45 | braewoods | but yea |
17:34:01 | braewoods | it's not like we're oozing memory here |
17:34:38 | braewoods | no idea if we really need to waste memory on alignment for all targets for the lcd |
17:34:53 | speachy | I mean, sure, we can shrink that stack slightly to make things fit again but it's still a bandaid. the only other alternative is to pick something to kick out of IRAM (and take the performance hit of doing so) |
17:35:12 | speachy | I really doubt it, or else we'd be broken badly on the other PP targets. |
17:35:16 | braewoods | option 3 is reduce waste |
17:35:36 | braewoods | but i can't see anywhere to do that |
17:35:54 | speachy | the coldfire stuff is the second-most optimized port we have. well, most-optimized now that archos are gone. |
17:37:59 | speachy | we have asm-optimized H10 lcd routines |
17:38:06 | speachy | so tbh it's most likely an issue with those. |
17:38:35 | speachy | was yours the 10GB or 20GB version? |
17:38:40 | braewoods | 20GB |
17:38:52 | braewoods | the 5/6GB wasn't upgradeable really |
17:39:22 | braewoods | used some obscure seagate flex interfare for which no adapters exist |
17:39:59 | braewoods | does anyone here know the ASM well enough to dig into it? |
17:40:15 | braewoods | i sent my unit to bilgus |
17:40:19 | braewoods | so i don't have it right now |
17:41:02 | speachy | it appears to mostly consist of optimized YUV/RGB conversion |
17:41:28 | speachy | operating on raw byte arrays |
17:41:49 | braewoods | it makes me wonder why alignment fixed the problem |
17:42:17 | speachy | probably because it padded something else out that was trashing our pointer. |
17:42:31 | speachy | ie classic buffer overrun |
17:42:45 | braewoods | that could explain it too |
17:42:55 | braewoods | i can see no logical explaination for it all |
17:43:24 | braewoods | _bilgus_: maybe we should try an experiment. see if the unused padding is written to or so |
17:43:39 | braewoods | that might reveal an overrun |
17:44:35 | braewoods | speachy: it's a shame we don't have the same debugging tools we have for desktop use |
17:44:55 | braewoods | anyway |
17:45:04 | braewoods | if we did i could just use valgrind :D |
17:46:01 | speachy | right before it is cpu_reply/cpu_message, used only in the ROLO code |
17:46:57 | braewoods | i wonder if there's some way we can find out if the VP is being corrupted during boot |
17:47:54 | speachy | his patch also changed the initialization of lcd_current_viewport |
17:48:03 | speachy | could be a run-of-the-mill null pointer dereference. |
17:48:21 | speachy | since it was explicitly null-initialized prior to his realignment patch. |
17:49:13 | speachy | in other words something is trying to hit the lcd prior to it being properly initialized, following a pointer into oblivion. |
17:52:11 | speachy | probably by something trying to hit the framebuffer data by calling FBADDR() before lcd_current_viewport is properly initialized. |
18:00 |
18:27:12 | *** | Saving seen data "./dancer.seen" |
18:27:32 | | Quit lebellium (Quit: Leaving) |
18:37:35 | | Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) |
18:38:40 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
18:39:13 | | Quit St3ak (Client Quit) |
18:40:45 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
18:41:34 | | Quit St3ak (Client Quit) |
18:43:52 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
18:44:24 | | Quit St3ak (Client Quit) |
19:00 |
19:08:22 | | Quit koniu (Remote host closed the connection) |
19:08:55 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
19:09:30 | _bilgus_ | speachy, braewoods I tried making buffers and a few ints on each side of the pointer to see if that was happening |
19:10:05 | braewoods | i never looked into it, but can the compiler reorder where global variables are stored? |
19:10:12 | braewoods | i know it can't reorder struct fieldds |
19:10:22 | _bilgus_ | not after the map is writtn I don't think |
19:11:08 | _bilgus_ | but I *THINK* what is happening here is that it no longer has proper alignment because of the union |
19:11:27 | braewoods | so this isn't about alignment of the pointer but the data pointed to |
19:11:29 | braewoods | ? |
19:11:42 | _bilgus_ | I want to see if I can force alignment with padding in the struct directly |
19:11:56 | braewoods | which union? |
19:12:10 | _bilgus_ | the buffer union inside the vp struct |
19:12:51 | _bilgus_ | gcc is supposed to infer alignment something like 1 byte 2 byte and 4 byte and then based on the largest item in the struct |
19:13:07 | _bilgus_ | 4byte alignment for ints |
19:13:24 | braewoods | i don't see where there's a union fori t |
19:13:38 | _bilgus_ | but I have run into this with buffers in lua when using a struct with an anon union |
19:13:41 | braewoods | struct viewport has no structs |
19:13:51 | braewoods | err unions |
19:14:13 | _bilgus_ | lcd_framebuffer_default |
19:16:53 | braewoods | why would this cause alignment |
19:17:05 | braewoods | the union has all pointers |
19:17:28 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
19:17:34 | braewoods | in fact all these types should be the same size |
19:17:44 | | Quit St3ak (Client Quit) |
19:17:53 | braewoods | the union of data pointers |
19:18:02 | braewoods | the function pointer |
19:18:10 | braewoods | ptrdiff_t and size_t |
19:18:22 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
19:18:45 | braewoods | rockbox has no 64 bit targets so i can't see how this would be an issue |
19:18:57 | braewoods | and if it ever did it'd be arm64 most likely |
19:20:54 | _bilgus_ | well you show me otherwise I suppose but its always the arm targets that care |
19:22:15 | braewoods | _bilgus_: go ahead and try |
19:22:29 | braewoods | i just can't see why it would |
19:26:21 | speachy | unaligned pointers are a problem for armv4 and mips. not sure about m68k/coldfire. |
19:26:45 | speachy | armv6 and up can deal with unalighed pointers/data, but at the cost of atomicity. |
19:27:05 | speachy | (wait, I think v7 and v8 can deal just fine regardless) |
19:27:26 | speachy | (however, v6m/v7m/v8m definitely need things aligned properly. Ie cortex-m) |
19:34:55 | braewoods | speachy: i was actually thinking in terms of the pointer itself being aligned vs the address it points to |
19:35:10 | speachy | that's what I meant |
19:35:21 | | Quit jschwart (Read error: Connection reset by peer) |
19:35:27 | braewoods | i guess i'm getting confused then |
19:35:40 | braewoods | there's 3 areas here, the pointer's allocated storage |
19:35:49 | braewoods | the allocated storage it points to |
19:36:01 | braewoods | and the actual addresses, but those shouldn't be misaligned because they'd point wrong |
19:36:49 | speachy | there are only two things, the address of the pointer itself, and the pointer's target |
19:37:30 | braewoods | i've never had to think much about alignment before |
19:37:35 | braewoods | so i guess that's why |
19:37:44 | braewoods | 99% of the time GCC just deals with it automatically |
19:37:48 | braewoods | or so |
19:38:15 | braewoods | but then this isn't a hosted implementation |
19:39:38 | braewoods | i'm kinda glad the iaudio m5 isn't a software usb target or i'd have to worry about this crap when i'm developing MTP support |
19:40:08 | | Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567) |
19:40:58 | speachy | when the CPU does a load, typically it supports applying a fixed offset to that load. Handing it an unaligned pointer can work out fine if the offset you supply "corrects" the alignment. :) |
19:41:18 | speachy | s/pointer/target/ |
19:42:01 | speachy | but yeah, the compiler by default will automatically pad structures for most efficient (and legal) access. |
19:43:06 | speachy | but most of us got badly spoiled by x86's CISC-y nature that could handle unalgined anything. Not necessarily efficiently, but it would _work_. |
20:00 |
20:03:25 | | Quit Strife89 (Ping timeout: 256 seconds) |
20:05:45 | | Join Strife89 [0] (~quassel@adsl-74-250-152-139.ags.bellsouth.net) |
20:27:14 | *** | Saving seen data "./dancer.seen" |
20:27:55 | | Quit koniu (Ping timeout: 268 seconds) |
20:31:45 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
20:54:49 | | Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) |
21:00 |
21:40:27 | | Quit Strife89 (Quit: No Ping reply in 180 seconds.) |
21:40:43 | | Join Strife89 [0] (~quassel@adsl-74-250-152-139.ags.bellsouth.net) |
21:43:04 | | Quit ac_laptop (Ping timeout: 258 seconds) |
21:57:55 | braewoods | speachy: in any case i'll test the YH-925 if i ever find a drive it likes lol |
21:58:05 | braewoods | make sure that port is still working under RB |
22:00 |
22:27:18 | *** | Saving seen data "./dancer.seen" |
23:00 |
23:15:08 | | Join f1reflyylmao [0] (~f1refly@2a01:c23:9008:6000:43b:fd9:b14e:ec99) |
23:17:21 | | Quit f1refly (Ping timeout: 264 seconds) |
23:17:21 | | Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c23:9008:6000:43b:fd9:b14e:ec99) |
23:39:54 | | Quit cockroach (Quit: leaving) |
23:41:15 | _bilgus_ | speachy you still get a map fileeven if the stack doesn't fit |