[FFmpeg-devel-irc] IRC log for 2010-07-04

[irc at mansr.com]

[15:55:42] * Terminating due to: TERM
[15:55:54] * /join #ffmpeg-devel ...
[15:55:56] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged.
[15:55:56] *** TOPICINFO: peloverde!~alex at cpe-173-88-148-20.neo.res.rr.com, 1276886498
[16:26:35] <lu_zero> fun
[16:26:47] <lu_zero> Input #0, mpeg, from 'audi/Auditorium_20100703.141019_1.mpg':
[16:26:47] <lu_zero>   Duration: 02:01:37.46, start: 0.516000, bitrate: 669 kb/s
[16:26:47] <lu_zero>     Stream #0.0[0x1c0]: Audio: mp2, 48000 Hz, 1 channels, s16, 64 kb/s
[16:26:47] <lu_zero>     Stream #0.1[0x1e0]: Video: [0][0][0][0] / 0x0000, 90k tbn
[16:27:13] <lu_zero> that is a file mplayer can play
[16:27:18] <lu_zero> and that's produced by ffmpeg...
[16:34:31] <lu_zero> happened to anybody before?
[16:35:13] <kshishkov> sounds like an awnser to metaphysical question "Can FFmpeg create file it cannot read?"
[16:39:56] <lu_zero> kshishkov: obviously that happens when you are in hurry and you obviously discover that the original isn't available anymore
[16:44:58] <lu_zero> I wonder how/why mplayer can play it w/out any issue
[16:45:14] <mru> it's obviously cheating
[16:49:50] <lu_zero> mru: still I wonder how
[16:50:06] * lu_zero is trimming the file randomly just to see what's wrong
[16:52:35] <lu_zero> mru: want to have a look?
[16:52:42] <mru> not really :-)
[16:52:57] <lu_zero> -_-
[16:58:53] * lu_zero hugs mencoder
[17:20:07] <mru> hmm, looks like swscale/altivec is busted somehow
[17:21:28] <lu_zero> how so?
[17:21:43] <mru> random results in make test
[17:21:56] <mru> valgrind spews warnings
[17:22:06] <mru> and disabling altivec in swscale makes it all work
[17:22:15] <kshishkov> alignment?
[17:22:32] <mru> valgrind still spews warnings
[17:22:36] <mru> but not quite as many
[17:25:45] <CIA-99> ffmpeg: ramiro * r24040 /trunk/doc/APIchanges:
[17:25:45] <CIA-99> ffmpeg: APIchanges: fix revision number and commit date for change of all occurences
[17:25:45] <CIA-99> ffmpeg: of "inofficial" to "unofficial".
[17:29:45] <DonDiego> make: *** No rule to make target `libavcodec/colorspace.h', needed by `libavfilter/vf_pad.o'.  Stop.
[17:30:02] <mru> it was moved
[17:30:04] <iive> DonDiego: make distclean?
[17:30:10] <mru> make clean is enough
[17:30:29] <mru> or find -name '*.d' | xargs grep -Fl colorspace.h | xargs rm
[17:31:13] <DonDiego> mru: i fixed that in mplayer by adding -MP to CFLAGS
[17:31:29] <DonDiego> i know how to work around the problem :)
[17:31:35] <DonDiego> i want to fix it for good
[17:32:35] <mru> will that mess with version.h generation?
[17:32:58] <kshishkov> "i fixed that in mplayer by adding -MP" - so add -FF here
[17:33:54] <DonDiego> kshishkov: :)
[17:33:57] <_av500_> DonDiego: did u know the german soccer team uses git for their game strategy plans..
[17:34:18] <DonDiego> no football jokes please
[17:34:41] <DonDiego> i'm surprised i did not wake up with the world's largest hangover...
[17:34:56] <DonDiego> mru: how should that mess with version.h?
[17:34:58] <_av500_> DonDiego: i just had to sc...
[17:35:18] <mru> DonDiego: it adds dummy rules for headers to stop make trying to remake them
[17:35:31] <mru> we _want_ it to remake version.h from time to time
[17:35:31] <DonDiego> yes, i know what the option does
[17:35:35] <kshishkov> _av500_: I'd Argentina to win - less noise from German fans later
[17:36:13] <DonDiego> but only if version.h does not exist
[17:36:22] <DonDiego> and there is an explicit rule for version.h already
[17:36:45] <DonDiego> explicit target
[17:36:51] <mru> besides, there's bound to be at least one compiler that fucks up totally with that flag
[17:37:07] <DonDiego> it works fine for gcc
[17:37:16] <mru> all versions?
[17:37:20] <DonDiego> and it's gcc-specific anyway i thought..
[17:37:36] <mru> then we should find a solution that isn't gcc-specific
[17:37:54] <DonDiego> it works fine even with 2.95 i think
[17:38:25] <DonDiego> the dependency generation as compilation sideeffect we only do for gcc
[17:38:35] <mru> and armcc
[17:38:38] <mru> and tms470
[17:38:44] <DonDiego> so adding -MP there should not adversely affect it..
[17:38:52] <DonDiego> well, test those compilers then :)
[17:39:07] <DonDiego> if it does not work, we add different flags..
[17:39:07] <mru> tms470 support is a huge hack
[17:41:57] * mru would like to fix some actual bugs now
[17:42:02] <mru> crashers
[17:42:27] <mru> I have some magnificent ppc asm to commit
[17:42:58] <DonDiego> :)
[17:43:09] <DonDiego> let me quickly paste you the patch i have in mind..
[17:43:24] <DonDiego> http://pastebin.org/383062
[17:44:00] <DonDiego> ok to commit?
[17:44:02] <mru> no
[17:44:16] <mru> ok, I promise I'll fix it
[17:44:21] <mru> but not _right now_
[17:44:30] <mru> I'm in the middle of something else
[17:45:43] <DonDiego> fine, but why do you oppose the patch?
[17:45:49] <DonDiego> i cannot see it do any harm..
[17:46:10] <mru> wrong burden of proof
[17:46:24] <mru> I don't see any evidence it might _not_ cause subtle damage
[17:46:36] <mru> and it only works with some gcc versions
[17:52:14] <mru> DonDiego: try this: http://pastebin.ca/1894486
[17:54:24] <DonDiego> which gcc versions does it not work with?
[17:54:41] <mru> there's an if ! gcc2 right above the line you patched
[17:55:26] <mru> and I think my suggestion is more elegant assuming it works as intended
[17:55:49] <DonDiego> gcc 2.x does not suffer from the problem
[17:55:57] <mru> which problem?
[17:56:09] <DonDiego> because we do not make it generate deps as sideeffect of compilation
[17:56:19] <mru> close enough
[17:56:20] <DonDiego> the renamed header problem
[17:56:26] <mru> we create the deps in the same make rule
[17:57:16] <mru> so from make's point of view, it might as well be done by gcc
[17:57:28] <mru> did you try my patch?
[17:58:55] <DonDiego> i'm compiling with it right now
[17:59:07] <DonDiego> seems to work fine
[17:59:54] <mru> Yuvi: I have patches for you
[18:01:19] <mru> Yuvi: http://git.mansr.com/?p=gas-preprocessor;a=summary
[18:03:46] <Yuvi> mru: oops on breaking ppc comments, applied them
[18:06:44] <DonDiego> make: *** No rule to make target `/tests/fate.mak'.  Stop.
[18:07:01] <DonDiego> mru: this is the reason the documentation generation was failing..
[18:07:49] <mru> no configure?
[18:07:55] <DonDiego> i.e. a plain "make documentation" was failing in this way
[18:08:08] <DonDiego> no, i just touched config.mak
[18:08:18] <mru> ok, makes sense
[18:08:36] <mru> make SRC_PATH_BARE=. documentation
[18:08:47] <DonDiego> running configure takes time :)
[18:09:03] <DonDiego> but i guess running it is the more robust solution...
[18:09:15] <DonDiego> so let's waste those precious cycles..
[18:12:05] <clundquist> $ ./configure
[18:12:05] <clundquist> $ make -j
[18:12:39] <clundquist> make -j might own your system with < 4 GB ram
[18:13:10] <mru> such systems still exist?
[18:13:20] <clundquist> mostly laptops
[18:13:25] <mru> mine has 8G
[18:14:03] <clundquist> I have a Pentium D box
[18:14:07] <clundquist> that doesn't like > 2GB
[18:14:28] <mru> lol
[18:14:58] * kshishkov got a Gdium
[18:15:16] <clundquist> but the dual quad core xeon with 48GB ram next to it makes up for it
[18:15:27] <kshishkov> and somebody at Intel decided to cut memory lanes on Atom so it does not support more than 1G
[18:15:36] <clundquist> i heard that
[18:15:39] <clundquist> it makes me sad
[18:15:49] <DonDiego> janneg: latm progress? :)
[18:16:02] <elenril> meh, 640kB should be enough for everyone
[18:16:24] <DonDiego> mru: your patch for the moved headers worked for me, please commit it
[18:16:36] <mru> it's in the queue
[18:17:44] <clundquist> Elenril, only with ex. Vi uses more
[18:17:58] <mru> cat ftw
[18:18:12] <elenril> use butterflies
[18:18:36] * elenril thinks cats are overrated
[18:19:48] <mru> they think the same of you
[18:20:01] * elenril noticed
[18:20:24] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/CatsAreMean
[18:21:39] * kshishkov thinks the best way to get along with cats and children is to ignore them
[18:22:27] <mru> no, you have the cats scratch the children
[18:22:30] <mru> works every time
[18:26:55] <DonDiego> praise for ffmpeg: http://lwn.net/Articles/394714/
[18:26:56] <DonDiego> :)
[18:34:31] <CIA-99> ffmpeg: mru * r24041 /trunk/common.mak: Stop make complaining about moved/deleted headers
[18:34:31] <CIA-99> ffmpeg: mru * r24042 /trunk/libavcodec/ppc/asm.S: PPC: add some asm support macros
[18:34:31] <CIA-99> ffmpeg: mru * r24043 /trunk/libavcodec/ppc/fft_altivec_s.S: PPC: gas-preprocessor handles m[ft]spr shorthands
[18:34:31] <CIA-99> ffmpeg: mru * r24044 /trunk/libavcodec/ppc/ (fft_altivec.c fft_altivec_s.S): (log message trimmed)
[18:34:31] <CIA-99> ffmpeg: PPC: convert Altivec FFT to pure assembler
[18:34:31] <CIA-99> ffmpeg: On PPC a leaf function has a 288-byte red zone below the stack pointer,
[18:34:32] <CIA-99> ffmpeg: sparing these functions the chore of setting up a full stack frame.
[18:34:32] <CIA-99> ffmpeg: When a function call is disguised within an inline asm block, the
[18:34:33] <CIA-99> ffmpeg: compiler might not adjust the stack pointer as required before a
[18:34:33] <CIA-99> ffmpeg: function call, resulting in the red zone being clobbered.
[18:44:14] <mru> fuck
[18:57:48] <lu_zero> Rathann: hi
[18:57:58] <Rathann> hey
[18:58:31] * Rathann waves
[19:00:23] <spaam> mru: what did you do this time?
[19:00:32] <lu_zero> regarding nemesi
[19:00:40] <mru> DonDiego rushed me into doing a commit that broke stuff
[19:00:49] <mru> lu_zero: I always read that as nemesis
[19:00:54] <spaam> mru: slap him :)
[19:01:02] <lu_zero> mru: nemesis will be something else
[19:01:10] <DonDiego> hmm?
[19:01:19] <mru> hardcoded tables broke with the header fix
[19:01:21] * lu_zero is still thinking about actually working on eris
[19:01:31] <mru> would have broken the same way with the gcc flag
[19:01:39] <DonDiego> hmmm
[19:02:19] <Rathann> lu_zero: by the way, is nemesi development stalled? latest git snapshot doesn't build against netembryo-0.1.1
[19:03:20] <mru> DonDiego: what is the purpose of that empty line in the changelog?
[19:03:31] <CIA-99> ffmpeg: michael * r24045 /trunk/Changelog:
[19:03:31] <CIA-99> ffmpeg: r24021 which i have approved did by mistake remove a empty line that had a purpose.
[19:03:31] <CIA-99> ffmpeg: This reverts the mistake.
[19:03:31] <CIA-99> ffmpeg: mru * r24046 /trunk/libavcodec/Makefile:
[19:03:31] <CIA-99> ffmpeg: Fix build with hardcoded tables
[19:03:32] <CIA-99> ffmpeg: The recently added dummy rule for missing headers took precedence
[19:03:33] <CIA-99> ffmpeg: over the tablegen rules. Listing the generated headers explicitly
[19:03:33] <CIA-99> ffmpeg: overrides this. A cleaner solution would be preferable.
[19:04:01] <lu_zero> Rathann: netembryo-2 was something that got merged back in feng
[19:04:11] <Rathann> ah
[19:04:20] <lu_zero> and I have halfway done the proto for having sctp in ffmpeg
[19:04:26] <lu_zero> (and then dccp)
[19:05:24] <Rathann> nice
[19:05:46] <lu_zero> j0sh_ is doing something quite good in ffmpeg about rtsp
[19:06:21] <lu_zero> and mplayer and vlc can already use ffrtsp somehow
[19:07:05] <Rathann> does anything support ASF over RTSP?
[19:07:28] <Rathann> because live555 doesn't, apparently
[19:07:39] <wbs> ffrtsp supports it
[19:08:12] <Rathann> hmm
[19:08:47] <lu_zero> Rathann: so ffrtsp is getting quite good as replacement
[19:09:07] <lu_zero> now I'd spend some time figuring out how to increase startup speed and resilience
[19:09:14] <lu_zero> (post esof)
[19:09:28] <Rathann> so does this stream work for anyone? rtsp://melpomene.mmedia.upv.es/RETRANS_PR_01
[19:09:44] <Rathann> for me ffplay either segfaults or hangs
[19:10:23] <lu_zero> nice experience of the day: "10% packet loss on a 100mbit link will kill your 300kbit tcp encapsulated slowly and surely =_="
[19:10:27] <lu_zero> Error: Client error. Reply was: 406 Not Acceptable
[19:10:29] <lu_zero> from nemesi
[19:10:38] <kierank> has jruggles been around today at all?
[19:11:10] <lu_zero> ff_wms_parse_sdp_a_line
[19:11:13] <lu_zero> crap
[19:11:20] <Rathann> lu_zero: yeah, I got that too later last night, but the first result was a segfault
[19:12:01] <Rathann> ha, strange
[19:12:18] <Rathann> first time it segfaults, subsequent tries get 406 Not acceptable
[19:12:48] <Rathann> too bad I wasn't running under gdb
[19:13:31] <lu_zero> oh well
[19:13:45] * lu_zero has those 15gb of files to upload & convert
[19:14:21] <lu_zero> libavformat/rtpdec_asf.c:114 if you are curious
[19:17:45] <Rathann> thanks, but not really - I was just trying to help someone in #mplayer
[19:19:42] <lu_zero> Rathann: could you add it in a bug and put me in nosy and BBB ref devel?
[19:21:39] <Rathann> sure, but not right now
[19:26:39] <lu_zero> rt->asf_ctx is null here...
[19:27:01] <wbs> asfdec doesn't understand the asf header
[19:27:50] <wbs> asfdec.c:284, the first stream has an unrecognized guid
[19:27:59] <Rathann> well, this stream url was in an asx playlist and it originally said mms:// not rtsp://
[19:28:46] <Rathann> http://melpomene.mmedia.upv.es/RETRANS_PR_01.asx
[19:28:58] <Rathann> this is the original url posted by a user
[19:29:21] <Rathann> he said it works with Windows Media Player
[19:30:04] <lu_zero> http://pastie.org/1030328 avoids the segfault but doesn't make it working
[19:36:17] * Rathann compiles current SVN
[19:36:39] <clundquist> Rathann: make -j
[19:36:43] <clundquist> makes it go
[19:36:50] <clundquist> (faster)
[19:43:11] <mru> ah, -j is a magic go-faster flag?
[19:48:04] <mru> thresh: ping
[19:50:41] <lu_zero> usually could be a short way to enjoy a forkbomb-alike situation
[19:51:29] <clundquist> yes, i heard you liked make threads
[19:51:35] <clundquist> so i put make threads in your make threads
[19:52:18] <clundquist> $ make --help
[19:52:19] <clundquist> <cut>
[19:52:19] <clundquist> -j [N], --jobs[=N]          Allow N jobs at once; infinite jobs with no arg.
[19:53:12] <lu_zero> -j -l [something] might be better...
[19:53:18] <mru> yeah
[19:55:27] <Rathann> lu_zero: confirmed, it fixes the segfault (no surprise, fix is obvious)
[19:55:37] <Rathann> but yeah, it doesn't work still
[19:56:49] <Rathann> http://ffmpeg.pastebin.com/1krQdrXM
[19:57:01] <lu_zero> I know
[19:57:09] <lu_zero> probably it's worth adding it
[19:57:32] <lu_zero> wbs: opinions?
[19:57:49] * Rathann afk -> food
[19:58:12] <lu_zero> Rathann: btw we were wondering where you were last weekend
[20:03:17] <CIA-99> ffmpeg: mru * r24047 /trunk/doc/general.texi: Mention gas-preprocessor in documentation
[20:07:05] <mru> DonDiego: if you could install the gas-preprocessor and try ffmpeg on your mac, that would be great
[20:07:20] <mru> or anyone else with a ppc-mac
[20:12:18] <thresh>  /away
[20:12:19] <thresh> err
[20:12:25] <thresh> mru: pong
[20:12:40] <mru> thresh: you dabble in distro stuff, right?
[20:16:26] <thresh> mru: kind of, yes
[20:16:59] <mru> how do you deal with apps using mmx and such?
[20:18:02] <mchinen> Is it a bad idea to send a ping a day to the ML if my patch hasn't been commented on?  I'm afraid it gets lost in the storm of 50 updated threads a day
[20:18:26] <mru> a ping a day keeps the reviewer away
[20:18:40] <Dark_Shikari> s/away/awake
[20:19:28] <thresh> mru: -march=i586 -mtune=i686 for i586 arch
[20:19:45] <mru> well, d'oh
[20:19:52] <mru> what about, say core2?
[20:20:23] <thresh> we don't distinguish between those in repository; if user knows what he wants, he'll rebuild; rpm allows tuning that.
[20:20:56] <thresh> we only have i586, x86_64 and some parts in ppc and arm (unfinished yet)
[20:22:57] <mru> so you'd be shedding tears if we made ffmpeg use mmx here and there by default?
[20:23:35] <clundquist> lol
[20:23:40] <thresh> i wouldnt probably care a lot since i --enable-mmx by default
[20:23:48] <thresh> (and I never received any complaints)
[20:24:03] <clundquist> mmx + arm?
[20:24:18] <thresh> I don't care for arm as the port is still unofficial
[20:24:26] <lu_zero> mru: ld.so cpufeature load paths shouldn't save the day?
[20:24:38] <thresh> once they try to merge, I will happily fix my stuff.
[20:26:12] <mru> thresh: --enable-mmx _is_ the default
[20:26:35] <Dark_Shikari> mru: but only for autoloaded stuff
[20:26:41] <Dark_Shikari> we still don't use inline mmx by default
[20:26:42] <Dark_Shikari> in fact
[20:26:45] <Dark_Shikari> we don't even use inline CMOV by default
[20:26:52] <Dark_Shikari> which is IMO insanely retarded
[20:26:59] <Dark_Shikari> we don't even use march=i686 by default to let gcc generate cmovs
[20:27:05] <mru> that's what I'm getting at
[20:27:07] <Dark_Shikari> this kills performance in a lot of code
[20:27:09] <thresh> mru: then I don't get what you mean
[20:27:10] <Dark_Shikari> e.g. cabac
[20:27:15] <Dark_Shikari> i.e. the _default_ configuration is _shit_+
[20:27:28] <Dark_Shikari> imo we should do what x264 does.
[20:27:29] <mru> thresh: --enable-mmx turns on runtime-optional mmx code
[20:27:35] <mru> we'd like to turn on some more
[20:27:48] <mru> inline mmx/sse that can't be disabled at runtime
[20:27:57] <Dark_Shikari> sse maybe not
[20:27:57] <Dark_Shikari> mmx, yes
[20:28:00] <thresh> I'm actually not sure someone still uses truly-i586 machines, only geode comes to mind?
[20:28:11] <Dark_Shikari> imo cmov is more important
[20:28:21] <mru> that too
[20:28:26] <mru> it's all in the same bucket
[20:39:36] <CIA-99> ffmpeg: mru * r24048 /trunk/libavutil/aes.c: aes: fix array index out of bounds warning
[20:40:32] <Rathann> I guess Pentium Pro is also rather an ancient museum exhibit
[20:40:48] <mru> it's old and there never were all that many of them
[20:40:48] <Dark_Shikari> even the pentium did mmx
[20:40:55] <mru> ppro didn't have mmx
[20:41:02] <mru> p2 is ppro+mmx more or oless
[20:41:04] <thresh> pentium didnt have mmx either
[20:41:13] <mru> pentium mmx did :-)
[20:41:46] <Rathann> mru: I don't suppose there are any users of FFmpeg with a PPro
[20:41:47] <Dark_Shikari> I had a pentium 1 166 mmx
[20:41:51] <Dark_Shikari> Rathann: michael probably
[20:41:59] <Rathann> hah
[20:42:06] <Rathann> yeah, that's possible
[20:52:40] * Compn has a 486 somewhere
[20:53:47] <siretart> thresh: see https://bugs.edge.launchpad.net/ubuntu/+source/ffmpeg/+bug/386397
[20:53:55] <siretart> there are such users. they even report bugs!
[20:55:04] <Dark_Shikari> has someone on a pentium 1 complained about x264 yet?
[20:55:24] <mru> they're still waiting for the first frame to finish
[20:55:42] <Dark_Shikari> oh, but x264 fails on init now
[20:55:56] <mru> but 5 years ago it didn't :-)
[20:56:00] * elenril installs git on his p-1
[20:56:08] <elenril> configure might be finished by morning
[20:56:20] <Rathann> lu_zero: issue 2070
[20:59:53] <CIA-99> ffmpeg: stefano * r24049 /trunk/ (doc/ffmpeg-doc.texi ffmpeg.c):
[20:59:53] <CIA-99> ffmpeg: Update help message for the -pad* options, as they have been removed,
[20:59:53] <CIA-99> ffmpeg: and update the manual page accordingly.
[20:59:53] <CIA-99> ffmpeg: Based on a patch by John Calcote $(echo "<kpio.dbmdpuf at hnbjm.dpn>" | tr "b-za" "a-z").
[20:59:53] <CIA-99> ffmpeg: stefano * r24050 /trunk/ffmpeg.c: Make opt_pad() print more information.
[21:00:18] <thresh> siretart: :-)
[21:22:26] <mru> hmm, looking at that bug report
[21:22:38] <mru> it's tripping on a movntq instruction
[21:22:59] <mru> is that not part of original mmx?
[21:23:54] <Dark_Shikari> yes it is
[21:23:56] <Dark_Shikari> according to nasm manual
[21:24:09] <Dark_Shikari> oh wait, no
[21:24:12] <Dark_Shikari> it's MMXEXT
[21:24:40] <Dark_Shikari> i.e. added in pentium 3
[21:24:46] <mru> that means there's either a bug in one of the swscale functions or detection isn't working right
[21:25:09] <mru> maybe his build was without runtime detection in swscale
[21:30:10] <iive> mmx ext is detected differently on intel and amd cpu's
[21:30:19] <ohsix> its a separate feature bit sometimes people don't test for; had a problem with pulseaudio on a k6-2 because of mmxext :]
[21:30:38] <mru> but we are ffmpeg, we do things right
[21:30:41] <mru> or try to
[21:31:21] <Dark_Shikari> and we do
[21:31:25] <Dark_Shikari> we do test mmxext separately
[21:31:26] <Dark_Shikari> and properly
[21:31:27] <siretart> mru: yes, that build was not runtime cpudetection enabled. the fix for that bug was to enable it
[21:31:29] <Dark_Shikari> and have done so for 10+ years
[21:32:04] <ohsix> cmov has one too; don't remember what problme i had there on the k6-2, there were a bunch of things like that
[21:36:16] <ohsix> fun times
[21:37:00] <DonDiego> mchinen: yes, ping that bug report
[21:37:03] <DonDiego> erm
[21:37:09] <DonDiego> ping that patch i mean
[21:42:47] <Rathann> lu_zero: are you going to commit your fix for that segfault?
[21:42:51] <Rathann> or should I?
[22:22:20] <lu_zero> Rathann: I'd rather know ronald's opinion ^^
[22:22:57] <Rathann> sure
[22:47:16] <mru> xchg   %ax,%ax
[22:47:18] <mru> wtf?
[22:47:22] <Dark_Shikari> that's a nop
[22:47:32] <mru> yes, exactly
[22:47:39] <Dark_Shikari> but what's the wtf about
[22:47:39] <mru> doesn't seem very useful
[22:47:44] <Dark_Shikari> that's a very standard way of doing a nop
[22:48:01] <mru> is it normal to have nops in compiled code?
[22:48:10] <Dark_Shikari> Of course
[22:48:17] <Dark_Shikari> compilers like to align functions to 16 byte boundaries
[22:48:17] <mru> what the hell for?
[22:48:21] <Dark_Shikari> and sometimes loops
[22:48:32] <Dark_Shikari> accordingly, they use the fewest instructions possible to pad out the space in between
[22:48:53] <mru> blegh, variable-length instructions
[22:49:04] <hyc> blegh, x86...
[22:49:21] <mru> that follows
[22:49:52] <Dark_Shikari> even thumb-2 has variable-length instructions =p
[22:50:04] <mru> sure, but only two lengths
[22:50:08] <mru> and it's buggy as hell
[22:50:09] <Dark_Shikari> lol
[22:50:12] <Dark_Shikari> Isn't that just gcc?
[22:50:13] <mru> in some implementations at least
[22:50:23] <mru> some HARDWARE is buggy as hell
[22:50:26] <mru> cortex-a8
[22:50:34] <mru> with thumb2
[22:50:36] <hyc> fun, hadn't heard that
[22:50:57] <mru> there are workarounds for most of them
[22:51:24] <hyc> workarounds .. then do you lose the size advantage of using thmub2 in the first place?
[22:51:34] <mru> my favourite is the one when a 32-bit branch instructions straddles a page boundary
[22:52:01] <Dark_Shikari> I think an arch with 2/4/8-byte instructions would be good
[22:52:11] <Dark_Shikari> with no stupid prefixes like x86
[22:52:13] <mru> and the predicted destination is in the same page as the first half, but the actual destination isn't
[22:52:17] <Dark_Shikari> you'd have the flexibility of x86 without nearly as much complexity
[22:52:18] <mru> or something like that
[22:52:29] <hyc> sounds just like an old 6502 bug
[22:52:41] <mru> hardly
[22:52:51] <mru> this bug is in the cache/tlb/mmu
[22:52:53] <hyc> which I recall game programmers used to obfuscate their code
[22:53:03] <mru> which the 6502 doesn't have
[22:53:24] <hyc> still, same effect, crossing a page boundary, the real destination was in the first page
[22:54:27] <mru> there's another one where the code at the virtual address of the predicted target of a branch has been replaced since last time
[22:54:42] <mru> either through codegen or mmu operations
[22:54:48] <hyc> Dark_Shikari: kinda like M68020. at least all their instructions were multiple of 16 bits
[22:54:51] <mru> it can start executing in the wrong arm/thumb state
[22:55:30] <mru> one workaround is to flush the branch target buffer on context switches
[22:56:12] <mru> to do that you need to set a control bit to make that flush operation actually do anything
[22:56:25] <mru> but if that bit is set, another bug kicks in
[22:56:51] <mru> which does something nasty in some weird corner-case
[22:57:12] <mru> to workaround for _that_ bug is to clear an obscure debug register during bootup
[22:57:18] <hyc> so your workarounds need workarounds? yeesh
[22:57:33] <mru> the catch is you can only write to that register in secure mode
[22:57:44] <mru> and on your average omap3, only the mask rom executes in secure mode
[22:58:00] <mru> so tough luck setting that bit
[22:58:00] <hyc> meaning you can't run the workaround at all
[22:58:15] <mru> you can, for a while :-)
[22:58:30] <mru> it's much simpler to just not run any thumb2 code
[22:58:50] <mru> or use a newish core revision where those bugs are fixed
[22:59:10] <hyc> so there are fixed A*s, this isn't just an A9 fix?
[22:59:13] <hyc> A8s
[22:59:26] <mru> current revision is r3p2
[22:59:37] <mru> but there are millions of r1p3 in the field
[22:59:49] <hyc> hmm I wonder what mine are
[22:59:59] <mru> which chip?
[23:00:05] <hyc> omap3530
[23:00:20] <mru> then it's most likely r1p3
[23:00:32] <mru> the dm3750 has an r3p2
[23:00:48] <mru> and the first batches of 3530 were r1p1
[23:01:09] <mru> or p2, I forget which
[23:02:52] <mru> hehe, nice one:  VCVT.f32.u32 can return the wrong result for the input 0xfff_ff01
[23:02:53] <hyc> cat /proc/cpuinfo says revision 3
[23:03:58] <mru> what does the second line of kernel log say?
[23:04:02] <mru> something like
[23:04:04] <mru> CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d
[23:04:44] <mru> that's an r1p3
[23:04:49] <mru> the r3p2 says this:
[23:04:51] <mru> CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[23:05:10] <hyc> CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7). cr=10c53c7f
[23:05:55] <hyc> ok, so r1p3
[23:06:18] <mru> why do you have strict alignment checking enabled?
[23:07:07] <hyc> eh? hellefino
[23:07:22] <mru> see the 'f' at the end of your line?
[23:07:50] <hyc> yep
[23:08:01] <hyc> who inits that? the uboot?
[23:09:45] <mru> look in your /proc/cpu/alignment
[23:10:13] <hyc> all xeros
[23:10:15] <hyc> zeros
[23:10:20] <roxfan> mru: xchg %ax,%ax is probably a 66 90 (nop with size override prefix)
[23:10:57] <roxfan> a "normal" nop would be xchg %eax,%eax (assuming 32-bit mode)
[23:12:35] <mru> wouldn't a "normal" nop be "nop"?
[23:12:39] <mru> aka 0x90
[23:12:48] <mru> oh wait, that would make sense
[23:12:50] <mru> can't have that
[23:14:00] <roxfan> 0x90 does mean xchg eax,eax, but the cpu treats it as a nop
[23:14:19] <hyc> lol
[23:14:32] <hyc> where's the HCF opcode
[23:14:35] <roxfan> arm also used mov r8, r8 (or mov r0, r0 for thumb) as a nop until v6 or so
[23:14:53] <roxfan> now they have a separate "architectural nop"
[23:14:57] <mru> old arm didn't have a dedicated nop
[23:15:13] <mru> you could use whatever instruction without side-effects
[23:15:41] <mru> and a disassembler would always tell you what it really was
[23:16:18] <hyc> so aside from patching code, when would you need it
[23:16:33] <hyc> on MIPS you always needed to fill branch delay slots
[23:16:38] <mru> apparently x86 runs better with padding
[23:16:50] <Dark_Shikari> it makes sense to have nop overlap a real but useless instruction
[23:16:52] <Dark_Shikari> to save space
[23:17:03] <Dark_Shikari> e.g. just say "xchg eax, eax is nop"
[23:17:22] <mru> that will put a false dependency on the register
[23:17:31] <mru> unless you have special wiring to avoid that
[23:17:55] <Dark_Shikari> you have to have special wiring to deal with nops anyways
[23:18:00] <Dark_Shikari> if only to say "this is a nop"
[23:18:20] <mru> much less
[23:19:05] <mru> early arm was a bit funny in many ways though
[23:19:18] <mru> you know how most instructions are conditional?
[23:19:26] <iive> somebody once pointed me out that amd handle nop's specially and the paper also suggested similar nops of different sizes.
[23:19:40] <mru> well, armv3 and earlier had a 'never' code for the condition field
[23:20:05] <Dark_Shikari> lol
[23:20:32] <roxfan> "had
[23:20:34] <roxfan> "?
[23:20:44] <mru> in v4 they changed it
[23:20:45] <roxfan> it's still there...
[23:20:47] <roxfan> oh?
[23:21:02] <hyc> now it's "sometimes"
[23:21:03] <mru> there's a 4-bit condition field
[23:21:19] <mru> 0xe means always for instance
[23:21:22] <mru> 0xf was never
[23:21:35] <mru> now 0xf means the rest of the instruction is interpreted differently
[23:21:55] <mru> so what used to be 'add never' now could be anything
[23:22:41] <mru> it was just a way to extend the opcode space
[23:22:49] <Dark_Shikari> hey just like x86
[23:22:51] <roxfan> hmm indeed
[23:22:53] <roxfan> "Other encodings in this space are UNDEFINED in ARMv5 and above.
[23:22:53] <roxfan> All encodings in this space are UNPREDICTABLE in ARMv4 and ARMv4T."
[23:22:53] <mru> no
[23:23:04] <mru> x86 addes prefixes making the new instructions longer
[23:23:10] <roxfan> i didn't know it happened back in v4
[23:23:21] <Dark_Shikari> mru: no, it uses existing prefixes and sticks shit after them
[23:23:25] <Dark_Shikari> just like here, you have a 4-bit prefix
[23:23:33] <mru> no, it's not a prefix
[23:23:41] <mru> every instruction is 32 bits
[23:23:51] <Dark_Shikari> ok, so it's a prefix, but everything has to have it =p
[23:24:05] <mru> if the top 4 bits != 0xf it's a regular conditional instruction
[23:24:17] <mru> if they are 0xf it's a different instruction
[23:24:27] <mru> you could say the same about any part of the opcode
[23:24:29] <Dark_Shikari> so the "different instructions" can't be conditional
[23:24:35] <mru> right
[23:25:07] <mru> but throwing away 2^28 opcodes on nops is a waste
[23:25:41] <roxfan> btw speaking of nops: http://www.rhinocerus.net/forum/lang-asm-x86/255833-multi-byte-nop-s.html http://www.symantec.com/connect/blogs/x86-fetch-decode-anomalies
[23:29:05] <mru> sorry, it was armv3 that did away with the never code