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: Jeremy F. <je...@go...> - 2002-12-04 21:53:11
|
On Wed, 2002-12-04 at 12:52, Julian Seward wrote:
> On contemplation, that solution seems to be good to me. It would more or
> less remove the flag-move overhead for the bog-standard ALU ops -- those
> which set exactly OSZACP. Inc, dec, neg and not will still have to go
> via the expensive route, but hopefully they are not so common.
Yes. From looking at generated code, INC and DEC are the only even
vaguely common instructions which hit this, and they aren't that common.
Separating out D was reasonably easy. It complcates the implementation
of GETF/PUTF, but those are very rare (they're only used for pushf/popf,
and I couldn't find any instances of those being used in real programs;
I had to write a specific test; I guess that's why they're implemented
so slow in real silicon).
> I'm trying to approach a new-code freeze for 2.0. I'd like to take
> 44-symbolic-addr and its dependent 45-memcheck-symaddr. How stable
> is 44 -- is it good enough to ship?
It works for me. The main limitation is the lack of DWARF2 support. I
looked at it the other day, but it is fairly complex (I'll need to
implement or steal a forth interpreter for it). Oh, there is a #define
LAZYSIG 1 which should probably be 0 (it affects whether SIGSEGV is
caught for the whole tracing process or just for each pointer
dereference - at present it is disabled all the time, but this means
that any bugs turn into a silent sulk rather than a useful symptom).
> If this flags stuff can be bought to successful conclusion within the
> next week or so, that would be great to ship too.
That's what I'm currently working on. I think there's an issue around
string ops (which UInstrs are supposed to change Simd flags, and which
aren't?), but I'll send something more detailed later.
J
|
|
From: Julian S. <js...@ac...> - 2002-12-04 20:45:12
|
> I think D is special, and we should treat is as such. As far as I know, > the only instructions which use D are the string instructions, and the > only instructions which change it are STD/CLD. If that's the case, then > we can treat D as a special case. We needn't even store it in EFLAGS; > we just need a bit of state which which we inspect in the code we > generate for string instructions, and which STD/CLD can change. The only > slightly tricky thing about that is making sure that we insert the D > state back into EFLAGS when returning to native execution. > > Of course this doesn't work for other flags. NEG only touches C, so if > we generate: > > neg %eax > pushfl; pop 32(%ebp) > > we'll put random crap into the OSZAP flag state if eflags doesn't > already contain EFLAGS. > > The simple solution is to make all instructions which don't update all > the flags be said to use the flags they leave untouched, which would > generate a flags get. Since many instructions do touch all the flags > except D, this wouldn't be too bad in combination with the suggestion > above. On contemplation, that solution seems to be good to me. It would more or less remove the flag-move overhead for the bog-standard ALU ops -- those which set exactly OSZACP. Inc, dec, neg and not will still have to go via the expensive route, but hopefully they are not so common. I'm trying to approach a new-code freeze for 2.0. I'd like to take 44-symbolic-addr and its dependent 45-memcheck-symaddr. How stable is 44 -- is it good enough to ship? I'll also take 55-ac-clientreq (non-controversial). If this flags stuff can be bought to successful conclusion within the next week or so, that would be great to ship too. J |
|
From: Jeremy F. <je...@go...> - 2002-12-04 01:27:12
|
On Tue, 2002-12-03 at 16:41, Julian Seward wrote:
> Hi. Let me say at the outset that I think your patch (62-) is a much
> better solution than mine; it makes it less likely to get things wrong
> later on, and extends naturally to skins. So I like that.
Thanks.
> And the performance improvements really are excellent.
>
> However -- I'm getting almost all progs segfault at exit, if not before.
Yes, I'm still working on that (the patch I mailed you was more a sketch
than working; there some stuff on my site which works a little better,
but is still pretty buggy). It works fine with --skin=none, but there's
some problems with memcheck. One thing I'm still working on is what
flags state a helper function expects as input and generates as output.
Also, in that patch I kind of conflated two distinct notions. There's
the upd_cc flag, which means (if false) "we're running this instruction
with the intent that it update the simulated CPU state, but we don't
care about the eflags state changes it makes, because they're
overwritten before they're inspected". And there's the first argument
to VG_(new_emit) which means "this instruction does/does not affect the
simulated CPU's flags".
The way its currently implemented, if an instruction has upd_cc false
(ie, don't care about flags state), it ends up saving the simd flags
state so that it isn't affected by the instruction. I'm wondering how
much this actually happens in practice, and whether its worth adding
another flag argument to all those functions.
> The SUBL is the first simd-flag-affecting fn in the block. So I see what your
> scheme does is to note that we are setting the simd flags here, so it lets
> the generated subl set %eflags; the Jleo then copies this to %EFLAGS with
> pushfl ; popl 32(%ebp).
>
> Problem is (according to my analysis) is that subl sets O S Z A C and P, but
> it doesn't set D (the string-op direction flag). Result is that the
> subsequent %EFLAGS := %eflags copy means that the sim'd flags state winds
> up holding the real machine'd D-flag state prior to the subl, which is
> unknown to us.
>
> Am I missing something here? I'd love to be, considering the speed gains :)
Ah, yes, I remember your concern over D.
I think D is special, and we should treat is as such. As far as I know,
the only instructions which use D are the string instructions, and the
only instructions which change it are STD/CLD. If that's the case, then
we can treat D as a special case. We needn't even store it in EFLAGS;
we just need a bit of state which which we inspect in the code we
generate for string instructions, and which STD/CLD can change. The only
slightly tricky thing about that is making sure that we insert the D
state back into EFLAGS when returning to native execution.
Of course this doesn't work for other flags. NEG only touches C, so if
we generate:
neg %eax
pushfl; pop 32(%ebp)
we'll put random crap into the OSZAP flag state if eflags doesn't
already contain EFLAGS.
The simple solution is to make all instructions which don't update all
the flags be said to use the flags they leave untouched, which would
generate a flags get. Since many instructions do touch all the flags
except D, this wouldn't be too bad in combination with the suggestion
above.
The complex solution is to change the uses/sets flags into actual
FlagSets, and manage things on a per-flag level rather than all flags.
I don't think it helps at all, since we can't generate a partial flags
get/put anyway.
J
|
|
From: Julian S. <js...@ac...> - 2002-12-04 00:34:39
|
Hi. Let me say at the outset that I think your patch (62-) is a much
better solution than mine; it makes it less likely to get things wrong
later on, and extends naturally to skins. So I like that.
And the performance improvements really are excellent.
However -- I'm getting almost all progs segfault at exit, if not before.
I ran my canonical inner-loop program and looked at the code. I'm worried
by this:
47: SUBL $0x3E7, %eax (-wOSZACP) [------]
159: 81 E8 E7 03 00 00
subl $0x3E7, %eax
48: INCEIPo $6 [------]
165: C6 45 24 37
movb $0x37, 0x24(%ebp)
49: Jleo $0x8048508 (-rOSZACP) [------]
169: 9C 8F 45 20
pushfl ; popl 32(%ebp)
173: 7F 0D
jnle-8 %eip+13
175: B8 08 85 04 08
movl $0x8048508, %eax
180: 89 45 24
movl %eax, 0x24(%ebp)
183: 0F 0B 0F 0B 90
ud2; ud2; nop
50: JMPo $0x8048539 ($2) [------]
188: B8 39 85 04 08
movl $0x8048539, %eax
193: 89 45 24
movl %eax, 0x24(%ebp)
196: 0F 0B 0F 0B 90
ud2; ud2; nop
The SUBL is the first simd-flag-affecting fn in the block. So I see what your
scheme does is to note that we are setting the simd flags here, so it lets
the generated subl set %eflags; the Jleo then copies this to %EFLAGS with
pushfl ; popl 32(%ebp).
Problem is (according to my analysis) is that subl sets O S Z A C and P, but
it doesn't set D (the string-op direction flag). Result is that the
subsequent %EFLAGS := %eflags copy means that the sim'd flags state winds
up holding the real machine'd D-flag state prior to the subl, which is
unknown to us.
Am I missing something here? I'd love to be, considering the speed gains :)
J
|