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
|
2
(1) |
3
(5) |
4
(4) |
5
(1) |
6
|
7
|
|
8
(2) |
9
(12) |
10
|
11
(2) |
12
(16) |
13
(3) |
14
(13) |
|
15
(20) |
16
(19) |
17
(13) |
18
(20) |
19
(17) |
20
(17) |
21
(14) |
|
22
(13) |
23
(14) |
24
(15) |
25
(14) |
26
(14) |
27
(13) |
28
(2) |
|
29
(16) |
30
(3) |
31
(20) |
|
|
|
|
|
From: Christian B. <bor...@de...> - 2012-01-04 19:14:33
|
> The PFPO insn is used to convert between binary floating point and > decimal floating point. Since we have 3 formats each, that makes 9 > conversion ops for each direction: > > Iop_D32toF32 IRRoundingMode(I32) x D32 -> F32 > Iop_D32toF64 IRRoundingMode(I32) x D32 -> F64 > Iop_D32toF128 IRRoundingMode(I32) x D32 -> F128 > Iop_D64toF32 IRRoundingMode(I32) x D64 -> F32 > Iop_D64toF64 IRRoundingMode(I32) x D64 -> F64 > Iop_D64toF128 IRRoundingMode(I32) x D64 -> F128 > Iop_D128toF32 IRRoundingMode(I32) x D128 -> F32 > Iop_D128toF64 IRRoundingMode(I32) x D128 -> F64 > Iop_D128toF128 IRRoundingMode(I32) x D128 -> F128 > > Iop_F32toD32 IRRoundingMode(I32) x F32 -> D32 > Iop_F32toD64 IRRoundingMode(I32) x F32 -> D64 > Iop_F32toD128 IRRoundingMode(I32) x F32 -> D128 > Iop_F64toD32 IRRoundingMode(I32) x F64 -> D32 > Iop_F64toD64 IRRoundingMode(I32) x F64 -> D64 > Iop_F64toD128 IRRoundingMode(I32) x F64 -> D128 > Iop_F128toD32 IRRoundingMode(I32) x F128 -> D32 > Iop_F128toD64 IRRoundingMode(I32) x F128 -> D64 > Iop_F128toD128 IRRoundingMode(I32) x F128 -> D128 If you look at pfpo, then the instruction has the same tricky behaviour as EXecute. Since a self checking prefix and 18 Iops is pretty expensive I think that pfpo qualifies for a helper. |
|
From: Carl E. L. <ce...@li...> - 2012-01-04 16:43:11
|
On Wed, 2012-01-04 at 10:23 -0500, Florian Krohm wrote:
> On 12/29/2011 11:15 AM, Florian Krohm wrote:
>
> >>
> >> QUANTIZE AND ROUND INSTRUCTIONS
> >> -------------------------------
> >> EXTRACT AND INSERT INSTRUCTIONS
> >> -------------------------------
> >
> > Do we need to support these at all? In other words, does GCC issue these
> > or do they show up in hand crafted assembler shipped with GCC/GLIBC?
> > I don't know but will find out (for s390).
> >
>
> Yes, we need to support them. They are used in libdfp.
>
> s390 also has an "extract significance" opcode which extracts the
> significant digits of a DFP number and converts them to a signed 64-bit
> integer. It's also used in libdfp.
>
> Iop_ExtractSigD64 D64 -> I64
> Iop_ExtractSigD128 D128 -> I64
These two were included in the proposal as TBD Specifically, s390
instructions ESDTR and ESXTR. Not sure if the instruction can be easily
emulated with existing Iops and the proposed Iops or not. I left this
to the s390 team to make the call. The question is, can they be easily
emulated or not? I have not tried to do it yet. Although POWER doesn't
have this instruction, we could do a proof of concept implementation for
Power to see how hard it would be to emulate. I could take a look at
this once I finish the initial implementation of the other POWER
instructions. I think I have about 5 more to do to finish off the 49
POWER instructions. Let me know if you think it would be worth doing a
proof of concept implementation on Power so we can decide if we really
need the Iops or not.
>
> >>
> >> FORMAT CONVERSION INSTRUCTIONS
> >> Iop s390 Power Description of instruction,
> > implementation
> >> opcode opcode details
> >>
> >> ---------------------------------------------------------------------
> >> TBD
> >> PFPO
> >> The PFPO instruction operation is
> >
> > To be done....
> >
>
> The PFPO insn is used to convert between binary floating point and
> decimal floating point. Since we have 3 formats each, that makes 9
> conversion ops for each direction:
>
> Iop_D32toF32 IRRoundingMode(I32) x D32 -> F32
> Iop_D32toF64 IRRoundingMode(I32) x D32 -> F64
> Iop_D32toF128 IRRoundingMode(I32) x D32 -> F128
> Iop_D64toF32 IRRoundingMode(I32) x D64 -> F32
> Iop_D64toF64 IRRoundingMode(I32) x D64 -> F64
> Iop_D64toF128 IRRoundingMode(I32) x D64 -> F128
> Iop_D128toF32 IRRoundingMode(I32) x D128 -> F32
> Iop_D128toF64 IRRoundingMode(I32) x D128 -> F64
> Iop_D128toF128 IRRoundingMode(I32) x D128 -> F128
>
> Iop_F32toD32 IRRoundingMode(I32) x F32 -> D32
> Iop_F32toD64 IRRoundingMode(I32) x F32 -> D64
> Iop_F32toD128 IRRoundingMode(I32) x F32 -> D128
> Iop_F64toD32 IRRoundingMode(I32) x F64 -> D32
> Iop_F64toD64 IRRoundingMode(I32) x F64 -> D64
> Iop_F64toD128 IRRoundingMode(I32) x F64 -> D128
> Iop_F128toD32 IRRoundingMode(I32) x F128 -> D32
> Iop_F128toD64 IRRoundingMode(I32) x F128 -> D64
> Iop_F128toD128 IRRoundingMode(I32) x F128 -> D128
Again, the s390 PFPO instruction is in the proposal. It was left as a
TBD for the s390 team to decide on the needed Iops. Not sure that you
really need to introduce an Iop for everyone of these. If you
introduced just the Iop_D128toF128,
you could then emulate the other conversions using this Iop. For
example, if you had a D32 you would use the existing Iops to convert it
to a D128, then use the Iop_D128toF128 to convert it and then narrow the
result to the desired size.
You could do something similar with the float to DFP. Does that seem
reasonable?
The question is, what is the minimum number of Iops that really need to
be introduced?
Thoughts?
Carl Love
>
> I haven't studied the details of the formats so I'm not sure that a
> rounding mode is needed for some of the conversions. PFPO allows the
> specification of a rounding mode in all cases but that doesn't mean it's
> needed..
> Anybody has insight into this?
>
> The s390 maintainer for GCC confirmed that these conversions are in fact
> all used.
>
> Florian
>
|
|
From: Florian K. <br...@ac...> - 2012-01-04 15:23:44
|
On 12/29/2011 11:15 AM, Florian Krohm wrote:
>>
>> QUANTIZE AND ROUND INSTRUCTIONS
>> -------------------------------
>> EXTRACT AND INSERT INSTRUCTIONS
>> -------------------------------
>
> Do we need to support these at all? In other words, does GCC issue these
> or do they show up in hand crafted assembler shipped with GCC/GLIBC?
> I don't know but will find out (for s390).
>
Yes, we need to support them. They are used in libdfp.
s390 also has an "extract significance" opcode which extracts the
significant digits of a DFP number and converts them to a signed 64-bit
integer. It's also used in libdfp.
Iop_ExtractSigD64 D64 -> I64
Iop_ExtractSigD128 D128 -> I64
>>
>> FORMAT CONVERSION INSTRUCTIONS
>> Iop s390 Power Description of instruction,
> implementation
>> opcode opcode details
>>
>> ---------------------------------------------------------------------
>> TBD
>> PFPO
>> The PFPO instruction operation is
>
> To be done....
>
The PFPO insn is used to convert between binary floating point and
decimal floating point. Since we have 3 formats each, that makes 9
conversion ops for each direction:
Iop_D32toF32 IRRoundingMode(I32) x D32 -> F32
Iop_D32toF64 IRRoundingMode(I32) x D32 -> F64
Iop_D32toF128 IRRoundingMode(I32) x D32 -> F128
Iop_D64toF32 IRRoundingMode(I32) x D64 -> F32
Iop_D64toF64 IRRoundingMode(I32) x D64 -> F64
Iop_D64toF128 IRRoundingMode(I32) x D64 -> F128
Iop_D128toF32 IRRoundingMode(I32) x D128 -> F32
Iop_D128toF64 IRRoundingMode(I32) x D128 -> F64
Iop_D128toF128 IRRoundingMode(I32) x D128 -> F128
Iop_F32toD32 IRRoundingMode(I32) x F32 -> D32
Iop_F32toD64 IRRoundingMode(I32) x F32 -> D64
Iop_F32toD128 IRRoundingMode(I32) x F32 -> D128
Iop_F64toD32 IRRoundingMode(I32) x F64 -> D32
Iop_F64toD64 IRRoundingMode(I32) x F64 -> D64
Iop_F64toD128 IRRoundingMode(I32) x F64 -> D128
Iop_F128toD32 IRRoundingMode(I32) x F128 -> D32
Iop_F128toD64 IRRoundingMode(I32) x F128 -> D64
Iop_F128toD128 IRRoundingMode(I32) x F128 -> D128
I haven't studied the details of the formats so I'm not sure that a
rounding mode is needed for some of the conversions. PFPO allows the
specification of a rounding mode in all cases but that doesn't mean it's
needed..
Anybody has insight into this?
The s390 maintainer for GCC confirmed that these conversions are in fact
all used.
Florian
|
|
From: <sv...@va...> - 2012-01-04 01:39:38
|
Author: florian
Date: 2012-01-04 01:34:53 +0000 (Wed, 04 Jan 2012)
New Revision: 2236
Log:
Add a comment about setting aside a register for VG_(dispatch_ctr)
on s390.
Modified:
trunk/priv/host_s390_defs.c
Modified: trunk/priv/host_s390_defs.c
===================================================================
--- trunk/priv/host_s390_defs.c 2011-12-18 15:51:54 UTC (rev 2235)
+++ trunk/priv/host_s390_defs.c 2012-01-04 01:34:53 UTC (rev 2236)
@@ -144,7 +144,12 @@
Otherwise, they are available to the allocator */
(*arr)[i++] = mkHReg(10, HRcInt64, False);
(*arr)[i++] = mkHReg(11, HRcInt64, False);
- /* GPR12 is not available because it caches VG_(dispatch_ctr) */
+ /* GPR12 is not available because it caches VG_(dispatch_ctr).
+ Setting aside a register for the counter gives slightly better
+ performance - most of the time. From the 10 tests in "make perf"
+ 8 run faster with a max observed speedup of 2.6% for bz2. ffbench
+ is the counter example. It runs 1.3% faster without the dedicated
+ register. */
/* GPR13 is not available because it is used as guest state pointer */
/* GPR14 is not available because it is used as link register */
/* GPR15 is not available because it is used as stack pointer */
|