Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2021-03-24

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:07fs-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:39braewoods_bilgus_: weird indeed
05:49:09braewoodson the brightside it may just be that this target is more picky?
05:49:26braewoodseven 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:11speachy_bilgus_: is it really ARM-specific, or unique to whatever DMA controller the H10 uses? (The PP series, I suppose?)
06:46:48speachyI mean, is it just a massive coincidence that all of the other PP targets (ipods!) work?
06:48:01speachyor I guess the alignment attr was lost when you did the viewport rewrite?
06:55:32braewoodsone way to find out
06:55:41braewoodscheck how it worked in the old code
07:00
07:03:15speachypre-rewrite it wasn't aligned either.
07:04:17braewoodsboggle
07:15:04speachystranger things have JustWorked(tm) until they didn't.
07:15:41speachyanyway. I suppsoe this "fix" is, at worst, a harmless no-op.
07:16:08braewoodsit's also possible it just happened to be aligned before by pure chance
07:16:41braewoodstime to look into it a bit
07:17:26braewoodsDMA is usually part of the cpu from what i recall
07:19:46braewoods_bilgus_: it may just be specific to the H10
07:19:51braewoodsif so just enable for both H10 ports
07:20:02braewoodssince i assume both would have the same issue
07:20:57speachybraewoods: Where this gets odd is that the H10 uses the same SoC as many iPods.
07:21:06braewoodsindeed
07:21:22speachyand if those were broken, we'd hear a _lot_ of complaints. :)
07:31:26speachyso, g#3254 is a fix for something that's annoyed me as long as I can recall
07:31:28fs-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:43speachyI _think_ it's safe.
07:32:15speachyadds a dependency on 'diff' but if that's not present it'll effectively fall back to the old behavior.
07:32:45braewoodsyou know what you could use instead of diff?
07:32:46braewoodscmp
07:33:07braewoodsit's for binary files but identical files will compare the same regardless
07:33:21speachyit's part of diffutils so
07:33:32speachy... so just as likely to be present (or not) as diff
07:33:46braewoodsoh
07:33:58braewoodsi thought it was part of coreutils
07:34:07braewoodssilly me
07:40:06braewoodsspeachy: you can use cksum or sum and compare those string outputs
07:40:11braewoodsif you think it matters that much
07:40:22braewoodsbut it shouldn't
07:40:27braewoodspretty much everyone should have diff
07:40:41speachythe advantage of cksum is that it's coreutils.
07:40:45braewoodsyea
07:40:48braewoodssame with sum
07:41:01braewoodsi also learned about cal commnad
07:41:04braewoodsawhile back
07:41:06speachybut it makes the code more complicated as I have to capture two sets of output and compare the results explicitly.
07:41:20braewoodsjust use cmp -s then
07:41:28braewoodsit doesn't produce output
07:41:49braewoodsi used to use it a lot
07:41:52speachycmp -s and diff -u are functionally equivalent
07:41:55speachydiff -q
07:41:58braewoodsoh
07:41:59braewoodsi see
07:42:16speachyie 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:28braewoodsspeachy: i was looking at modern USB connectors. wow they're such a complex soup now.
08:26:34braewoods2.0 just had 4 pins
08:26:42braewoods3.0 had 9 pins or so
08:26:48braewoodsthen type c introduce 3 more
08:27:05***No seen item changed, no save performed.
08:33:42speachyand then mirrors them
08:39:34braewoodsjust wiring usb today is rather daunting
08:39:51braewoodsso i probably won't be making any custom cables unless it doesn't require modern USB features
08:42:10braewoodsand some of the new pins have tx/rx lines so i'm thinking to myself
08:42:41braewoodsdid they reinvent ethernet / serial in the wiring?
08:42:59braewoodsrs232 or w/e
08:46:22speachyUSB-C has a few extra signaling/sense lines but they doubled everything in order to make it reversible.
08:46:49speachylater 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:30braewoodsspeachy: from what i can tell that's mainly used for negotiating the VCC voltage
08:59:36braewoodsfor USB PD
09:00
09:00:03braewoodsi needed to run a cable for an internal usb type c female port
09:00:07braewoodsfor PD only
09:00:09 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-916e-5a4e-8124-fcb4.res6.spectrum.com)
09:00:22braewoodsi ended up deciding a panel mount extension cable was the best way
09:00:32braewoodssince wiring for PD seemed rather involved
09:00:47braewoodsand i could find no easy ways to solder to a male connector internally
09:01:11braewoodsthey 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:40braewoodsmaybe the issue is variations in chips
09:03:50braewoodseven though it's only supposed to be 8
09:03:54braewoodserr
09:03:57braewoods4
09:04:34braewoodslucky 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:51braewoodshard to know
09:05:06braewoodswe 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:28braewoodssince type C is rounded i can use a drill to cut out the sides and then work my way over
09:06:59braewoodsno 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:39braewoodsyea, i originally tried running a regular cable but i realized my cable gland won't fit over one or seal right
09:08:56braewoodsthe connector is just too wide relative to the cable's size
09:09:12braewoodsunless the 5A cables are thick enough...
09:09:19braewoodsi 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:45braewoodsspeachy: it would be interesting to support dual devices for ATA targets with software USB stack...
11:54:53braewoodsbut i doubt many would use it
11:55:09braewoodsbut 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:22speachybraewoods: assuming the actual controllers supported the master/slave distinction, there's still the problem of physically fitting them in the case.
14:10:58speachymakes 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:04fs-bluebot_Build Server message: New build round started. Revision ffee661ab7, 293 builds, 10 clients.
14:27:10***Saving seen data "./dancer.seen"
14:27:15speachyanyone think of a reason to not merge g#3254?
14:27:17fs-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:29braewoods_bilgus_: ah, good
14:32:24 Quit Saijin_Naib (Read error: Connection reset by peer)
14:33:48fs-bluebot_Build Server message: Build round completed after 705 seconds.
14:33:54fs-bluebot_Build Server message: Revision ffee661ab7 result: 4 errors 0 warnings
14:34:47braewoods_bilgus_: something broke?
14:36:27_bilgus_yep
14:37:19_bilgus_uh oh
14:37:46braewoodswhere 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:29speachybraewoods: 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:00braewoodswas it that close to the limit before?
14:40:08_bilgus_clearly
14:40:28braewoodsmaybe 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:45speachyI 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:15braewoodsit 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:09braewoodswe 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:17braewoods_bilgus_: how would we find out?
14:42:24_bilgus_map file
14:42:30_bilgus_it shows the addresses
14:42:34braewoodsi see
14:42:42speachy_bilgus_: even when it doesn't successfully link?
14:43:10braewoodsit 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:21speachywell, one option is to slightly shrink the global stack
14:45:36speachyand then look at the map
14:46:08fs-bluebot_Build Server message: New build round started. Revision ed99b305a9, 293 builds, 10 clients.
14:46:30speachybraewoods: 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:03braewoodsspeachy: 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:33fs-bluebot_Build Server message: Build round completed after 625 seconds.
14:56:36fs-bluebot_Build Server message: Revision ed99b305a9 result: All green
14:56:37fs-bluebot_Build Server message: New build round started. Revision a53864ed4a, 293 builds, 10 clients.
15:00
15:10:09fs-bluebot_Build Server message: Build round completed after 812 seconds.
15:10:12fs-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:26braewoodsi 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:52braewoodsbut in my experience i've never known a viewport to have more 32k pixels in either direction
16:57:00braewoodsso 32 bits seems a bit excessive for that
17:00
17:08:26speachyyeah, seems that x/y/w/h could get cut down to shorts, flags and fonts too. drawmode might take some rejiggering.
17:08:31speachybut.
17:08:55braewoodspart of the issue is wasted memory on alignment
17:08:56speachyon the x3 (mips), changing those things to shorts actually makes the code size go up.
17:09:15speachywith no reduction in RAM use.
17:09:36speachylet's see what the mini2g does.
17:10:34speachywent up slightly there too.
17:10:48braewoodshm
17:11:05speachy(by 48 bytes)
17:11:13speachythat's purely changing the struct viewport
17:11:56speachycould be the compiler is not packing the structure, prefering to align everything to 32-bit native.
17:12:12braewoodsgcc lacks -Wpadding in the release we use
17:12:15braewoodsso hard to know
17:12:55speachywe have it optimizing for code size right now
17:13:29speachyrebuilding it for the m5 (m68k)
17:13:52speachyheh, moving to shorts, and it no longer fits in IRAM (by 16 bytes from whatever it used to be)
17:14:11braewoodsprobably would need to reorder the struct
17:14:16braewoodslet me check something
17:14:43braewoodsno... it shouldn't need to align for that
17:15:01braewoodsgoing from 4 4s to 4 2s
17:15:12braewoodsstill 4 byte aligned
17:15:38speachyit makes the code larger, and we put the LCD code into IRAM as it's so performance critical
17:16:02braewoodswhy would the viewport pointer care about the alignment...
17:16:15braewoodsit's a mystery to me
17:17:34speachyunique LCD driver code in the h10 port.
17:17:42speachydoing something the other PP targets don't.
17:19:16speachythe M5 has that external lcd IIRC?
17:19:33braewoodsthe remote?
17:19:43braewoodsno idea if it does
17:19:44braewoodslet's check
17:20:52braewoodsit does have one
17:22:37speachyyeah... it has the framebuffers for both the main screen and external screen in iram
17:25:43speachyIRAM on the m5 is _completely_ full.
17:27:36speachyit'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:47speachyto make it fit last time I shrank the general stack a little.
17:30:30speachy8K total for framebuffers, 9K for the codec stack, 4.3K for audio mixing buffers.. 2.6K for thread structures..
17:30:53speachyJust shy of 8K for the main stack
17:33:38braewoodsfunny thing is stacks are usually larger than strictly required
17:33:40braewoodsso
17:33:45braewoodsbut yea
17:34:01braewoodsit's not like we're oozing memory here
17:34:38braewoodsno idea if we really need to waste memory on alignment for all targets for the lcd
17:34:53speachyI 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:12speachyI really doubt it, or else we'd be broken badly on the other PP targets.
17:35:16braewoodsoption 3 is reduce waste
17:35:36braewoodsbut i can't see anywhere to do that
17:35:54speachythe coldfire stuff is the second-most optimized port we have. well, most-optimized now that archos are gone.
17:37:59speachywe have asm-optimized H10 lcd routines
17:38:06speachyso tbh it's most likely an issue with those.
17:38:35speachywas yours the 10GB or 20GB version?
17:38:40braewoods20GB
17:38:52braewoodsthe 5/6GB wasn't upgradeable really
17:39:22braewoodsused some obscure seagate flex interfare for which no adapters exist
17:39:59braewoodsdoes anyone here know the ASM well enough to dig into it?
17:40:15braewoodsi sent my unit to bilgus
17:40:19braewoodsso i don't have it right now
17:41:02speachyit appears to mostly consist of optimized YUV/RGB conversion
17:41:28speachyoperating on raw byte arrays
17:41:49braewoodsit makes me wonder why alignment fixed the problem
17:42:17speachyprobably because it padded something else out that was trashing our pointer.
17:42:31speachyie classic buffer overrun
17:42:45braewoodsthat could explain it too
17:42:55braewoodsi can see no logical explaination for it all
17:43:24braewoods_bilgus_: maybe we should try an experiment. see if the unused padding is written to or so
17:43:39braewoodsthat might reveal an overrun
17:44:35braewoodsspeachy: it's a shame we don't have the same debugging tools we have for desktop use
17:44:55braewoodsanyway
17:45:04braewoodsif we did i could just use valgrind :D
17:46:01speachyright before it is cpu_reply/cpu_message, used only in the ROLO code
17:46:57braewoodsi wonder if there's some way we can find out if the VP is being corrupted during boot
17:47:54speachyhis patch also changed the initialization of lcd_current_viewport
17:48:03speachycould be a run-of-the-mill null pointer dereference.
17:48:21speachysince it was explicitly null-initialized prior to his realignment patch.
17:49:13speachyin other words something is trying to hit the lcd prior to it being properly initialized, following a pointer into oblivion.
17:52:11speachyprobably 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:05braewoodsi never looked into it, but can the compiler reorder where global variables are stored?
19:10:12braewoodsi 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:27braewoodsso this isn't about alignment of the pointer but the data pointed to
19:11:29braewoods?
19:11:42_bilgus_I want to see if I can force alignment with padding in the struct directly
19:11:56braewoodswhich 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:24braewoodsi 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:41braewoodsstruct viewport has no structs
19:13:51braewoodserr unions
19:14:13_bilgus_lcd_framebuffer_default
19:16:53braewoodswhy would this cause alignment
19:17:05braewoodsthe union has all pointers
19:17:28 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
19:17:34braewoodsin fact all these types should be the same size
19:17:44 Quit St3ak (Client Quit)
19:17:53braewoodsthe union of data pointers
19:18:02braewoodsthe function pointer
19:18:10braewoodsptrdiff_t and size_t
19:18:22 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
19:18:45braewoodsrockbox has no 64 bit targets so i can't see how this would be an issue
19:18:57braewoodsand 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:15braewoods_bilgus_: go ahead and try
19:22:29braewoodsi just can't see why it would
19:26:21speachyunaligned pointers are a problem for armv4 and mips. not sure about m68k/coldfire.
19:26:45speachyarmv6 and up can deal with unalighed pointers/data, but at the cost of atomicity.
19:27:05speachy(wait, I think v7 and v8 can deal just fine regardless)
19:27:26speachy(however, v6m/v7m/v8m definitely need things aligned properly. Ie cortex-m)
19:34:55braewoodsspeachy: i was actually thinking in terms of the pointer itself being aligned vs the address it points to
19:35:10speachythat's what I meant
19:35:21 Quit jschwart (Read error: Connection reset by peer)
19:35:27braewoodsi guess i'm getting confused then
19:35:40braewoodsthere's 3 areas here, the pointer's allocated storage
19:35:49braewoodsthe allocated storage it points to
19:36:01braewoods and the actual addresses, but those shouldn't be misaligned because they'd point wrong
19:36:49speachythere are only two things, the address of the pointer itself, and the pointer's target
19:37:30braewoodsi've never had to think much about alignment before
19:37:35braewoodsso i guess that's why
19:37:44braewoods99% of the time GCC just deals with it automatically
19:37:48braewoodsor so
19:38:15braewoodsbut then this isn't a hosted implementation
19:39:38braewoodsi'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:58speachywhen 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:18speachys/pointer/target/
19:42:01speachybut yeah, the compiler by default will automatically pad structures for most efficient (and legal) access.
19:43:06speachybut 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:55braewoodsspeachy: in any case i'll test the YH-925 if i ever find a drive it likes lol
21:58:05braewoodsmake 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

Previous day | Next day