--- Log for 24.03.121  Server: beckett.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 18 days and 7 hours ago

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.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.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.23.48 Quit    ac_laptop (Ping timeout: 245 seconds)
04.26.59 ***     Saving seen data "./dancer.seen"
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.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.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.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.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.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.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.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.30.10 #       <_bilgus_> that would be nice with cf cards topping out at 128gb for $$
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.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.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.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.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.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.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.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.27.18 ***     Saving seen data "./dancer.seen"
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