You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(5) |
2
(3) |
3
(1) |
4
(4) |
5
(1) |
6
(11) |
7
(5) |
|
8
|
9
(6) |
10
(2) |
11
(10) |
12
|
13
|
14
(4) |
|
15
(7) |
16
(1) |
17
(3) |
18
|
19
|
20
|
21
(1) |
|
22
(1) |
23
|
24
|
25
|
26
|
27
|
28
(4) |
|
29
|
30
|
31
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2002-12-01 19:52:18
|
> I did see a problem though. I get this if I try to start OO under V in > 2.5: > > ==15504== Nulgrind, a binary JIT-compiler for x86-linux. > ==15504== Copyright (C) 2002, and GNU GPL'd, by Nicholas Nethercote. > ==15504== Using valgrind-1.9.1, a program instrumentation system for > x86-linux. ==15504== Copyright (C) 2000-2002, and GNU GPL'd, by Julian > Seward. ==15504== Estimated CPU clock rate is 1848 MHz > ==15504== For more details, rerun with: -v > ==15504== > > valgrind: vg_scheduler.c:475 (vgPlain_save_thread_state): Assertion > `(void*)vgPlain_threads[tid].ldt == (void*)vgPlain_baseBlock[vgOff_ldt]' > failed. Urr. What distro are you running (== what infrastructure do I need in order to run with a 2.5 kernel?) > > My vague and half-baked plan was to figure out a minimal extension to > > ucode which would allow MMX (MMX, not SSE* or 3DNow!) insns to be > > expressed. I would add GETMMX/PUTMMX to copy a MMX reg to/from a pair of > > TempRegs, and then there is the question of the minimal set of extra uops > > needed to support the packed add/shuffle/etc, whatever that is needed. > > If you want to occupy your feverish imagination considering this, that > > would be cool; I'd like to ship MMX support if possible. It's going to > > have to happen sometime, and the lack of it is more and more a problem. > > I think a good first step would be to parse the MMX/SSE/3Dnow > instructions just enough to be able to skip them, and emit illegal > instructions. That way the executing binary will behave more like a > pre-MMX P5, and apps which want to see SIGILLs will get them. > > Actually emulating the instructions is much harder. I think we're going > to get more bang-for-effort from improving flag handling at the moment. Well, I'd like to deliver the MMX functionality, even if the result is slow. You'll see I just committed a simple hack which seems to substantially mitigate the INCEIP thing; it's a combination of your partial-write idea and my always-write-never-add idea. Unfortunately failed to mention in the commit message that an intended side effect of the change is that INCEIPs no longer change the host condition codes, so that lazy eflags updating, which I think will be helpful, is assisted. I'm contemplating doing a thing similar to your lazy FPU save/restore. Except it needs to be a marginally cleverer; instead of saying simply "the most recent %EFLAGS state is in memory or in the host %eflags", it is helpful to distinguish three cases: most recent in memory, most recent in %eflags, and both of the above (%flags == memory value). This 3rd option allows copy-backs to be NOPd if %eflags hasn't changed. (think: %eflags is a write-back cache for %EFLAGS, so it's useful to have a dirty bit). J |
|
From: Jeremy F. <je...@go...> - 2002-12-01 17:47:58
|
On Sun, 2002-12-01 at 02:31, Julian Seward wrote:
> > V refuses to configure on 2.5, but it seems to work fine if I hack the
> > config script. Is there any particular reason it wouldn't work with
> > 2.5?
>
> Not afaik -- I just have never tried it -- I don't have a 2.5 install.
> Do you know if 2.5 will work on VMware?
Don't know, but I suspect it would work.
I did see a problem though. I get this if I try to start OO under V in
2.5:
==15504== Nulgrind, a binary JIT-compiler for x86-linux.
==15504== Copyright (C) 2002, and GNU GPL'd, by Nicholas Nethercote.
==15504== Using valgrind-1.9.1, a program instrumentation system for x86-linux.
==15504== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==15504== Estimated CPU clock rate is 1848 MHz
==15504== For more details, rerun with: -v
==15504==
valgrind: vg_scheduler.c:475 (vgPlain_save_thread_state): Assertion `(void*)vgPlain_threads[tid].ldt == (void*)vgPlain_baseBlock[vgOff_ldt]' failed.
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==15504== at 0x40A62A6B: pthread_create (vg_libpthread.c:691)
==15504== by 0x406340AF: oslCreateThread (in /usr/lib/OpenOffice.org1.0/program/libsal.so.3.0.1)
==15504== by 0x40634192: osl_createSuspendedThread (in /usr/lib/OpenOffice.org1.0/program/libsal.so.3.0.1)
==15504== by 0x4184F85E: store::OStorePageDaemon::insert(store::OStorePageBIOS*) (in /usr/lib/OpenOffice.org1.0/program/libstore.so.3.0.1)
Thread 2: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==15504== at 0x0: ???
Please report this bug to: js...@ac...
> My vague and half-baked plan was to figure out a minimal extension to ucode
> which would allow MMX (MMX, not SSE* or 3DNow!) insns to be expressed.
> I would add GETMMX/PUTMMX to copy a MMX reg to/from a pair of TempRegs, and
> then there is the question of the minimal set of extra uops needed to support
> the packed add/shuffle/etc, whatever that is needed. If you want to occupy
> your feverish imagination considering this, that would be cool; I'd like to
> ship MMX support if possible. It's going to have to happen sometime, and the
> lack of it is more and more a problem.
I think a good first step would be to parse the MMX/SSE/3Dnow
instructions just enough to be able to skip them, and emit illegal
instructions. That way the executing binary will behave more like a
pre-MMX P5, and apps which want to see SIGILLs will get them.
Actually emulating the instructions is much harder. I think we're going
to get more bang-for-effort from improving flag handling at the moment.
J
|
|
From: Julian S. <js...@ac...> - 2002-12-01 10:23:53
|
> V refuses to configure on 2.5, but it seems to work fine if I hack the > config script. Is there any particular reason it wouldn't work with > 2.5? Not afaik -- I just have never tried it -- I don't have a 2.5 install. Do you know if 2.5 will work on VMware? > Also, what's the state of working with the Nvidia drivers? I know one > of the hopes of the segment stuff was making them work, but it still > seems to die on MMX/SSE instructions. Is it that it assumes it will get > a SIGILL if it tries to use SSE on a CPU which doesn't have it? The seg-override stuff is in, but now it seems we need MMX at least. I've been thinking about that a bit. The problem is that MMX has a lot of arithmetic insns (packed add etc) and we need to do a good job in the value-tracking stuff for memcheck. People tell me that uninitialised data is routinely copied via the MMX regs, so the FPU hack (pretend that FPU state is fully defined, and complain about undefinededness at FPU loads) won't work here. My vague and half-baked plan was to figure out a minimal extension to ucode which would allow MMX (MMX, not SSE* or 3DNow!) insns to be expressed. I would add GETMMX/PUTMMX to copy a MMX reg to/from a pair of TempRegs, and then there is the question of the minimal set of extra uops needed to support the packed add/shuffle/etc, whatever that is needed. If you want to occupy your feverish imagination considering this, that would be cool; I'd like to ship MMX support if possible. It's going to have to happen sometime, and the lack of it is more and more a problem. J |
|
From: Jeremy F. <je...@go...> - 2002-12-01 06:50:01
|
V refuses to configure on 2.5, but it seems to work fine if I hack the
config script. Is there any particular reason it wouldn't work with
2.5?
Also, what's the state of working with the Nvidia drivers? I know one
of the hopes of the segment stuff was making them work, but it still
seems to die on MMX/SSE instructions. Is it that it assumes it will get
a SIGILL if it tries to use SSE on a CPU which doesn't have it?
J
|
|
From: Julian S. <js...@ac...> - 2002-12-01 02:02:50
|
> Great. How about the multiply patch? Maybe, but is not high priority. We'll see. > > chainings, # unchainings, and # of jumps via the dispatcher. It gives a > > worst-case indirect count of about 16% for KDE apps. > > Statically or dynamically? Dynamically. > > * you had VG_MAX_JUMPS set to 4; almost all bbs have 2 or less > > jumps. Is there a reason for having it at 4? I changed it to 2. > > Seems to work; it that OK ? Saved 1 word per TCEntry compared with 4. > > Initially it wouldn't work unless every BB had VG_MAX_JUMPS or fewer > jumpsites. I added the sanity check to generate the fallback path later > on. Ha, good point. > > Next on my hit list is 51-kill-inceip. > > So you've decided to go with the SYNCEIP idea? Well, something definitely needs to be improved here, and SYNCEIP seems a plausible start point, so I want to look at it. J |