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: Carl E. L. <ce...@li...> - 2012-01-11 18:54:00
|
Julian, Florian and Christian: I would like to thank you for your responses and time to review the proposal. It has been valuable to help us meet the two primary goals of the proposal. The first goal is to identify the minimal set of Iops that are needed by both POWER, s390 and hopefully additional future architectures. The second goal is to identify areas where architecture specific additions may be needed in the future. I would like to focus at this point on the common issues between POWER and the s390 architectures and just note where we have s390 specific additions that may be needed in the future. I would also like to defer the s390 specific Iop additions to later when the s390 team is ready to add the DFP support to Valgrind. The following is a combined response to the various responses I received from the three of you. On Tue, 2011-12-27 at 23:17 +0100, Julian Seward wrote: > Thanks for making a plausible looking proposal. Looks like it's > heading in the right direction. There are some details to iron > out, though. Please look at all of them. > > Comments in order of reading the doc: > > General: how much has this been checked out by the s390 folks > (Florian, Christian, Divya) ? They have reviewed it at a high level. They have not gotten into the details as they are not currently working on the Valgrind DFP support. They seem to be happy with the minimal set of Iops proposed. However, there are a couple of s390 instructions that may need additional Iops to be added. I put TBD in the iop name for these s390 instructions. There was some discussion of this in the replies by Christian Borntraeger and Florian Krohm. There are some specific s390 issues that I would like to defer to later as mentioned above. My comments below should make it clear what I think we can defer until later. > > General: please give a reference, including URL, to a publically available > standard that defines the basic arithmetic (IEEE 754-2008 ?) I will add the public links to the two ISA documents. I have them. > > > > The IBM Power and s390 systems support 32-bit, 64-bit and 128-bit > > decimal floating point (DFP) numbers. The DFP instructions use the > > existing floating point registers. The DFP 128-bit operands are stored in > > registers i and i+1 where i must be even. For example the DFP 128-bit add > > is done as follows: > > > > lfd 12,48(31) // load the upper 64 bits of the first 128 value > > in reg 12 lfd 13,56(31) // load the lower 64 bits of the first 128 > > value in reg 13 addi 0,31,64 > > mr 9,0 > > lfd 0,0(9) // load the upper 64 bits of the 128 second value > > in reg 0 lfd 1,8(9) // load the lower 64 bits of the 128 second > > value in reg 1 daddq 0,12,0 // do the add of the 128 DFP numbers, > > result is stored in // registers 0 and 1. Note, registers 1 and 13 are > > not // explicitly listed but are implied > > It feels like there's possible some confusion between types in the IR > (that is, IRType) and how values are represented in ppc registers. These > concepts are distinct, and are related only in the sense that it is necessary > to choose types that don't cause the ppc->IR and IR->ppc translations to > be inefficient. > > AFAICS (also, from reading the rest of the doc) you want three new types, > Ity_D32, Ity_I64 and Ity_D128. (yes? that sounds right to me) The addition of new types is not required. In the proposal the type D32, D64 and D128 was used to make it clear that the Iops operate on DFP values stored in a floating point registers. From an implementation standpoint, the Iops can be implemented using the existing F32, F64 and F128 types. I did a proof of concept implementation for a couple of Iops by explicitly adding the D64 and D128 types. I have implemented most of the 49 POWER instructions just using the existing floating point types. Adding the DFP types requires adding more code to handle unop, binop, triops of DFP values. If the Iops are implemented using the F32, F64 and F128 types, then the existing code to handle the various unop, binop and triop cases can be leveraged minimizing the amount of additional code. For example, we don't need new binop code to handle two DFP operands, we just leverage the existing binop code that handles two floating point operands. Not adding DFP types will minimize the amount of additional code that is functionally similar to existing code. Adding the DFP type may provide additional capability for type checking. I am not sure how much value there is in this additional type checking capability. Input on this point from the community would be good. If there is value in adding the DFP type, I am willing to change my preliminary POWER7 implementation to add the DFP types rather then using the floating point types as I currently have. Having the DFP type may make the overall code clearer then having Iops with the D32, D64 and D128 in the name but actually operate on F32, F64 and F128 values. Thoughts on adding DFP type? > > Note that many of the back ends already convert F32-typed expression > trees into 64-bit floating point code (eg, the host_ppc_isel.c) so > doing so for D32 would be considered "normal". > > > > > Notation Description > > > > -------------------------------------------------------------------------- > > - DFP: Decimal Floating Point number possibly 32-bit, 64-bit, or > > 128-bit format > > > > D32: 32-bit decimal floating point format These values > > use F64 registers. The D32 term is used to distinguish the value from the > > standard 32-bit floating point value. > > > > D64: 64-bit decimal floating point format. These values > > use F64 registers. The D64 term is used to distinguish the value from the > > standard 64-bit floating point value. > > > > D128: 128-bit decimal floating point format. These > > values use a pair of two 64 bit floating point registers (F64). The > > instruction only references the first register of the register pair. The > > second register is implied. > > As per comments above, the comments re the PPC register layouts isn't > directly relevant to what you need in the IR. (I don't care; I just want > to be sure we have our concepts straight here) Correct, the actual layout of the DFP value in a register is not relevant, POWER and s390 follow the IEEE 754-2008 specification. I wanted to make it clear from the Iop name that the register value being operated on by the Iop was assumed to be in the DFP format. Hence the use of DFP in the Iop name. As mentioned above, the actual types expected by the Iop could be either the traditional floating point type or a DFP type if it is decided that we should really add the DFP types to Valgrind. > > > > IRRoundingMode(I32): Indicates the I32 argument is used > > to hold the bits that specify the rounding mode to be used by the > > instruction. Comment from Florian Krohm: > IEEE Std 754-2008 says (4.3.3) that > > A decimal format implementation of this standard shall provide > roundTiesToAway as a user-selectable rounding-direction attribute. > > with: > > roundTiesToAway, the floating-point number nearest to the infinitely > precise result shall be delivered; if the two nearest floating-point > numbers bracketing an unrepresentable infinitely precise result are > equally near, the one with larger magnitude shall be delivered. > > We probably should extend IRRoundingMode accordingly. > >s930 DFP actually has 9 rounding modes > > According to FPC setting > Round toward 0 > Round away from 0 > Round toward +inf > Round toward -inf > Round to nearest with ties away from 0 > Round to nearest with ties to even > Round to nearest with ties toward 0 > Round to prepare for shorter precision > > We can handle the unsupported ones as we do for binary floating > point and map them to Irrm_NEAREST until problems arise. The POWER7 and s390 machines support the additional four rounding modes for DFP (total of 8 not 9 modes) in the IEEE specification. After some thought, I think it would be better to explicitly change the rounding mode specifier from IRRoundingMode(I32) to IRRoundingModeDFP(I32). The concern is if we extend the existing rounding mode specifier then there will be rounding modes for which the existing binary floating point instructions are not specified to support. Yes, it is some replication of code to create a second super-set of rounding modes for DFP but from an overall consistency, clarity and accuracy standpoint I think it might be best. >From the specification, we will then need support at least the roundTiesToAway mode. The additional modes could be added as needed in the future. What are your thoughts on creating a separate DFP rounding mode specifier? The decision of which additional rounding modes will be supported by s390 can be deferred to when the architecture specific support is added to Valgrind. > > Fine; as per existing code. > > > > IRRoundingExceptionModes(I32): Indicates the I32 argument is used > > to hold the bits that specify the rounding mode and the bits that specify > > the exception mode to be used by the instruction. The s390 instructions > > specify both modes whereas POWER does not specify either mode. > > Hmm. Have you read (in detail) the limitations re floating point > described at > http://valgrind.org/docs/manual/manual-core.html#manual-core.limits > > The point is that IR and Valgrind generally doesn't provide support > for non-default exception modes, and silently assumes that exceptions > are to be fixed up using the default IEEE fixup actions. So there's > no point at the moment in adding exception action information into > the IR. None of the other front ends (xxx_to_IR.c) do it. OK, I had not specifically read the document above but was aware that Valgrind only had limited rounding and exception support. I included the full rounding and exception support for completeness. I thought it better to include it at this point then to gloss over it. I added a comment to the document ahead of the field definitions to that effect. So, if there is no chance that the exception support will be added then we can just drop the exception specification part. Thoughts? > > > > IRRoundingModeAndEponent(I32): Indicates the I32 argument will > > contain bits to specify the rounding mode. POWER also has bits to specify > > the desired exponent. The s390 instructions only specify the rounding > > mode. > > Euh, can you elaborate on the encoding/meaning of "desired exponent" ? > Sounds a bit like wiring a POWER-ism into the IR spec, which isn't good. The POWER instruction includes an immediate value specifing the exponent value. For example if you are doing U.S. dollars you can set the exponent to 2 so the number will be in the standard form of dollars and cents, i.e. $234.99. This is useful if you are calculating interest or taxes in U.S dollars. The process of adjusting the exponent to a specific value, either immediate or as the quantum of a value in a specified register is referred to as quantizing the number. The immediate exponent value in the instruction is specific to the POWER processor. I have spent some time reconsidering this. We really don't need it so I will remove the IRRoundingModeAndEponent(I32). This is related to the discussion below about the quantize instructions. I had specified a quantize immediate Iop. This is a bit redundant. > > > > ARITHMETIC INSTRUCTIONS > > ----------------------- > > IRRoundingMode(I32) X D64 X D64 -> D64 > > Iop_AddD64, Iop_SubD64, Iop_MulD64, Iop_DivD64 > > > > IRRoundingMode(I32) X D128 X D128 -> D128 > > Iop_AddD128, Iop_SubD128, Iop_MulD128, Iop_DivD128 > > fine > > > > FORMAT CONVERSION INSTRUCTIONS > > ------------------------------ > > InvOperationModes(I32) x D32 -> D64 > > Iop_D32toD64 > > what's InvOperationModes? It's not specified anywhere in your doc. InvOperationModes(I32): Specifies the handling of the SNaN and infinity. The field specifies the IEEE invalid operation exception control. These bits are only specified on the IBM s390 architecture. Comment from Florian: > You did not describe InvOperationModes. But looking at insn LDETR > (which is D32 -> D64 conversion) I gather that InvOperationModes > controls whether or not the IEEE-invalid-operation-exception is > delivered. It's essentially a Boolean value. I propose to ignore it > and deliver the exception unconditionally (which is what we do for > binary floating point). Julian do you agree we should remove the InvOperationModes(I32) from the Iop specification? I am OK with it. > > > InvOperationModes(I32) x D64 -> D128 > > Iop_D64toD128 > > ditto > > > IRRoundingExceptionModes(I32) x D64 -> D32 > > Iop_RoundD64toD32 > > > > IRRoundingExceptionModes(I32) x D128 -> D64 > > Iop_RoundD128toD64 > > > > IRRoundingExceptionModes(I32) x I64 -> D64 > > Iop_I64StoD64 > > ok Comment from Florian: > These two should be renamed to Iop_D64toD32 and Iop_D128toD64 for > symmetry in naming with binary floating point ops. I disagree. The drsp instruction is analogous to the binary FP frsp instruction, which (for ppc64) uses the Iop Iop_RoundF64ToF32. The distinction is that an Iop that does not have "Round" in the name is a conversion from one general type (i.e., floating point) to a different general type (i.e., integer); whereas an Iop that *does* have "Round" in the name is a narrowing of the same general type. Comment from Florian: > For s390 we also need: > IROp description s390 insn > Iop_I64StoD128 IRRoundingMode(I32) x signed I64 -> D128 CXGTR > Iop_I32StoD64 signed I32 -> D64 CDFTR > Iop_I32StoD128 signed I32 -> D128 CXFTR > Iop_I64UtoD64 IRRoundingMode(I32) x unsigned I64 -> D64 CDLGTR > Iop_I64UtoD128 IRRoundingMode(I32) x unsigned I64 -> D128 CXLGTR > Iop_I32UtoD64 unsigned I32 -> D64 CDLFTR > Iop_I32UtoD128 unsigned I32 -> D128 CXLFTR > > We need both: conversion to signed and unsigned int > > IROp description s390 insn > Iop_D64toI64S IRRoundingMode(I32) x D64 -> signed I64 CGDTR(A) > Iop_D128toI64S IRRoundingMode(I32) x D128 -> signed I64 CGXTR(A) > Iop_D64toI32S IRRoundingMode(I32) x D64 -> signed I32 CFDTR > Iop_D128toI32S IRRoundingMode(I32) x D128 -> signed I32 CFXTR > Iop_D64toI64U IRRoundingMode(I32) x D64 -> unsigned I64 CLGDTR > Iop_D128toI64U IRRoundingMode(I32) x D128 -> unsigned I64 CLGXTR > Iop_D64toI32U IRRoundingMode(I32) x D64 -> unsigned I32 CLFDTR > Iop_D128toI32U IRRoundingMode(I32) x D128 -> unsigned I32 CLFXTR > > Note, the new IRops for conversion to 32-bit wide results and from D128. Comment from Christian Borntraege: > > 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. These conversion modes are specifically support by s390 but not POWER. POWER supports a subset of the conversions supported by s390. This is one of the areas where I feel we should defer the decision on adding more Iops, using a helper function or emulating these conversions with the subset of conversions that have been proposed until the s390 team is ready to add the s390 support to Valgrind. This is beyond the scope of what is needed for me to add the POWER support. But I think it is important that the issue has been raised to understand the full scope of what is needed by both architectures. > > IRRoundingExceptionModes(I32) x D64 -> I64 > > Iop_D64toI64 > > this is underspecified .. you need to decide whether that's a > conversion to signed or unsigned I64 (or maybe you need both) > and call them Iop_D64toI64S or Iop_D64toI64U respectively. > (I think you comment about this further down in the doc.) > I mention this partly because sorting out such ambiguity in the > past for the Fxx->Ixx conversions required a lot of hoop > jumping, so we might as well get it straightened out up front. OK, should be convert to signed integer. Changed the name to Iop_D64toI64S. > > > > ROUNDING INSTRUCTIONS > > ----------------------- > > IRRoundingMode(I32) x D64 -> D64 > > Iop_RoundD64 > > > > IRRoundingMode(I32) x D128 -> D128 > > Iop_RoundD128 > > ok > Comment from Florian: > These should be named Iop_RoundD64toInt and Iop_RoundD128toInt for > symmetry in naming with binary floating point ops. I am OK with the name change. Comments? > > > > COMPARE INSTRUCTIONS > > ----------------------- > > D64 x D64 -> IRCmpF64Result(I32) > > Iop_CmpD64 > > > > D128 x D128 -> IRCmpF64Result(I32) > > Iop_CmpD128 > > ok Comment from Florian: > OK. I would use IRCmpD64Result and IRCmpD128Result. That allows > us to use a different encoding, which may be desirable. I am OK with the name change. Comments? Thoughts? > > > > D64 x D64 -> 1 if the condition is TRUE, 0 otherwise > > Iop_CmpEQD64, Iop_CmpLTD64, Iop_CmpGTD64 > > > > D128 x D128 -> 1 if the condition is TRUE; 0 otherwise; > > Iop_CmpEQD128, Iop_CmpLTD128, Iop_CmpGTD128 > > why are these 6 necessary? Isn't their functionality a subset of > Iop_CmpD64 and Iop_CmpD128 ? Sorry, they were in there but I removed them as they were not needed. I took them out of the detailed description below but missed removing all of them from the summary list. > > > > QUANTIZE AND ROUND INSTRUCTIONS > > ------------------------------- > > IRRoundingMode(I32) x D64-> D64 > > Iop_QuantizeID64, > > > > IRRoundingMode(I32) x D128-> D128 > > Iop_QuantizeID128 > > > > IRRoundingMode(I32) x D64 x D64 -> D64 > > Iop_QuantizeD64 > > > > IRRoundingMode(I32) x D128 x D128 -> D128 > > Iop_QuantizeD128 > > I'm not clear what the ID vs D signifies in these names. Can > they instead be called Iop_Quantize{Un,Bin}{D64,D128} to denote > unary vs binary ness (ignoring the rounding mode arg which is > present in all 4 cases). > The first two with the I are for immediate value of the exponent for the quantization operation. Remember above, I had the IRRoundingModeAndEponent(I32) specification. It was also there for specifying the immediate value. I didn't realize that I had a redundant way of specifying the immediate exponent value. So, as said above, we drop IRRoundingModeAndEponent(I32) specification. > What is quantization, anyway (in the context of DFP I mean)? > Does it have any analogue in traditional IEEE754 FP ? Quantization is the process of rounding a number to a specified exponent as mentioned earlier. For example, the U.S. specifies a dollar amount with at most two fractional digits, for example $12.98. When doing a computation involving money, the quantization instruction would be used to round the result to two fractional digits. The immediate value to specify the desired exponent is specific to POWER. Both s390 and POWER have instructions for changing the exponent of (quantizing) a value in register A to match the exponent of a value in register B. I think we should remove the Iops Iop_QuantizeID64 and Iop_QuantizeID128 for specify an immediate exponent. For the POWER instruction that specifies the immediate exponent, I can just generate a DFP number with the desired exponent and pass that as the value in register B as the target exponent. This will help minimize the number of new Iops. > > > IRRoundingMode(I32) x D64 x D64 -> D64 > > Iop_SignificanceRoundD64 > > > > IRRoundingMode(I32) x D128 x D128 -> D128 > > Iop_SignificanceRoundD128 > > > > > > EXTRACT AND INSERT INSTRUCTIONS > > ------------------------------- > > D64 -> I64 > > Iop_ExtractExpD64 > > > > D128 -> I64 > > Iop_ExtractExpD128 > > The exponent really needs 64 bits? Can it be 32 bits? That > might allow for more efficient code generation for 32 bit targets. The biased exponent could be stored as a 32 bit biased integer. The functionality of the specific instruction that this Iop was intended for specifies the exponent will be stored in a floating point register in a signed integer format. I agree we can make the target be I32 and then just handle the I32 to I64 conversion as needed for the specific instruction. The exponent for any DFP number will easily fit in less then 31 bits. I will change the above two Iops to return an I32 value. Comment from Florian: > 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, the libdfp and binutils use them. > > > I64 x I64 -> D64 > > Iop_InsertExpD64 > > > > I64 x I128 -> D128 > > Iop_InsertExpD128 > > ditto comment ditto above that we do need these Iops for instructions that are used. > > > SHIFT SIGNIFICAND INSTRUCTIONS > > ------------------------------- > > U16 x D64 -> D64 > > Iop_ShlD64, Iop_ShrD64 > > > > U16 x D128 -> D128 > > Iop_ShlD128, Iop_ShrD128 > > two things: (1) does the shift amount need to be 16 bits? > For all the other shifting style ops we have, the shift amount > is encoded in 8 bits (Ity_I8) and I would prefer to stick with > that for consistency, if possible. (2) pls put the shift amount > as the second argument, not the first, as that too is consistent > with all other shift ops we have (eg, Iop_Shr64) OK, changed shift to U8 and made it D64 x U8 -> D64; D128 x U8 -> D128 > > --------------- > > > This section give the detailed mapping of Power and s390 > > instructions to the proposed DFP Iops or how they would be implemented > > with the existing Iops and the proposed DFP Iops. > > I'll comment on this second half of the proposal tomorrow. > > J > I have not seen any additional comments. It is probably best to focus on resolving the above issues first as the second part is just a more detailed discussion of the above summary of the Iops. Once we have agreement on the above discussion points, I will update and post version 2 of the proposal. Carl Love |
|
From: <sv...@va...> - 2012-01-11 11:39:13
|
Author: bart
Date: 2012-01-11 11:34:23 +0000 (Wed, 11 Jan 2012)
New Revision: 12327
Log:
configure.in: Make compiler version check more robust
Modified:
trunk/configure.in
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2012-01-08 21:01:02 UTC (rev 12326)
+++ trunk/configure.in 2012-01-11 11:34:23 UTC (rev 12327)
@@ -106,13 +106,19 @@
# Debian Linux: gcc (Debian 4.3.2-1.1) 4.3.2
# openSUSE: gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]
# Exherbo Linux: x86_64-pc-linux-gnu-gcc (Exherbo gcc-4.6.2) 4.6.2
+# MontaVista Linux for ARM: arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q1-203) 4.3.3
# OS/X 10.6: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
# OS/X 10.7: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
# Clang: clang version 2.9 (tags/RELEASE_29/final)
#
-[gcc_version=`${CC} --version \
- | $SED -n -e 's/[^ ]*gcc[^ ]* ([^)]*) \([0-9.]*\).*$/\1/p' \
- -e 's/[^ ]*clang version \([0-9.]*\).*$/\1/p'`]
+[
+ gcc_version=`${CC} -dumpversion 2>/dev/null`
+ if test "x$gcc_version" = x; then
+ gcc_version=`${CC} --version \
+ | $SED -n -e 's/[^ ]*gcc[^ ]* ([^)]*) \([0-9.]*\).*$/\1/p' \
+ -e 's/[^ ]*clang version \([0-9.]*\).*$/\1/p'`
+ fi
+]
is_clang="notclang"
if test "x`${CC} --version | head -n 1 | $SED 's/\(clang\) version.*/\1/'`" = "xclang" ; then
|