On Wednesday, July 14, 2021 at 3:10:01 AM UTC+1, MitchAlsup wrote:

> > although i probably have some details a bit fuzzy, is this basically how VVM works?
> <
> Tolerably good guess.

awesome. ok now i am impressed. only frickin took me 2 years to grok.

so i would say, in conclusion, the code is so short and so effective there is no need for strlen op, strcpy etc.

> Precisely! Now go figure out how you don't need that instruction, either.

yehyeh, that's the hard part. i only just grokked Vertical-First Vectorisation, last week, the implications will take a while to propagate, after 3 years of studying Horizontal-first.

due to time constraints i may have to go with that "hint" idea, that rather than the arch automatically working out the number of safe parallel elements, the compiler tells you.

yes, i know, memory aliasing's a pain. haven't got my head round it yet.

l.

On 7/12/2021 6:55 PM, luke.l...@gmail.com wrote:
> On Tuesday, July 13, 2021 at 2:29:36 AM UTC+1, Stephen Fuld wrote:
>
>> First of all, you messed up the attributions. The comments above are
>> Thomas Koenig's, not mine.
>
> apologies, i am using a very small device and the google groups interface is awesomely dire. it converts HTML formatted reply indentation into "nothingness" (i.e. ignores them entirely). this ignoringness basically removes one level of reply attribution, without people's knowledge or consent. it's done it again to my replies.
>
> your replies are now attributed to me, thanks to google . if you were to switch to plaintext replies rather than "rich text" it would not mess up.

I am using Thunderbird (latest version). There is an option in the
account compose options to use HTML. I do NOT have that checked. Other
than that, I don't know how to do what you want me to. If anyone can
help, please do. But I should note that I think others in this group
use Google groups, and, in general, no one else does what your system does.

I am willing to experiment, but I don't know what to try.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 7/13/2021 7:00 PM, MitchAlsup wrote:
> On Tuesday, July 13, 2021 at 7:37:27 PM UTC-5, Ivan Godard wrote:
>> On 7/13/2021 9:12 AM, MitchAlsup wrote:
>>> On Monday, July 12, 2021 at 10:22:13 PM UTC-5, Stefan Monnier wrote:
>>>>>>> it isn't going away.
>>>> Agreed, tho zero-terminated strings are rarely important for performance
>>>> nowadays I'd think.
>>>>>> bit integer added to every string. a zero byte string (empty) is
>>>>>> therefore 2 bytes. second: if strings are over 65535 bytes *you can't
>>>>>> have them* you are forced to use a 4 byte length encoder, now you have a
>>>>>> *4* byte overhead for short strings...
>>>> Nowadays you have to accommodate strings longer than 4GB, so you'll want
>>>> 64bit for the length. In Emacs, a string object comes with 2
>>>> length fields, both of them `ptrdiff_t` (one of them is for the length
>>>> in bytes, the other for the length in "characters").
>>>>
>>>> We haven't made effort to assess whether it was the optimal/best choice,
>>>> but small strings are never the dominant factor is total heap size.
>>>>> in storage space, yes. in terms of implementing in hardware, as a special
>>>>> microcoded operation, quite risky. if the hardware microcode could be
>>>>> *defined* (a la Transmeta) i would say that was a route worth pursuing.
>>>> Agreed, I don't see much need for special hardware support for string
>>>> processing (whether zero-terminated or with a specified length).
>>>> If it's a significant part of your total processing time, there's a good
>>>> chance that the better way to speed it up is to use a different
>>>> representation rather than to try and squeeze a few extra percents from
>>>> the hardware.
>>> <
>>>>> typical implementations of FP to INT rounding are FORTY FIVE
>>>>> instructions and involve FIVE branches.
>>> <
>>> A) There are 48 ways to do {float,double}FP<->INT{signed,unsigned}
>>> B) there are instructions in My 66000 to do any and all of them.
>> 48 ways? Two FP radices, five FP rounding modes, two int signednesses, 4
>> integer overflow behavior. That's 80. If you are changing width in the
>> process (we don't) then it's 4 FP widths X 4 integer widths, which
>> explodes to much more than 48 and even if only {float, double}->single
>> sized int it runs the count to 160 cases. You are probably not dealing
>> with decimal, so we're back to 80, but not 48.
>>
>> How do you get 48?
> <
> There are 5 ways to round Double into UnSigned, Signed, or Float; each.
> There are 5 ways to round Float into UnSigned or Signed; each.
> There are 5 ways to round UnSigned into Double or Float; each
> There are 5 ways to round Signed into Double or Float; each
> And there are assignment conversions:
> UnSigned = Signed,
> Signed = UnSigned , and
> Double = Float.
> <
> 15+10+10+10+3 = 48
> <
> The singed = unsigned is not a MOV saturating at SPOSMAX
> The unsigned = signed is not a MOV saturating negatives to zero.
>

So you ignore integer overflow behavior, float to double, short float,
long float, and decimal. While you can get away without the rest (most
do), I think you need float to double.

On 2021-07-14, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
> On 7/12/2021 6:55 PM, luke.l...@gmail.com wrote:
>> On Tuesday, July 13, 2021 at 2:29:36 AM UTC+1, Stephen Fuld wrote:
>>
>>> First of all, you messed up the attributions. The comments above are Thomas
>>> Koenig's, not mine.
>>
>> apologies, i am using a very small device and the google groups interface is
>> awesomely dire. it converts HTML formatted reply indentation into
>> "nothingness" (i.e. ignores them entirely). this ignoringness basically
>> removes one level of reply attribution, without people's knowledge or
>> consent. it's done it again to my replies.
>>
>> your replies are now attributed to me, thanks to google . if you were to
>> switch to plaintext replies rather than "rich text" it would not mess up.
>
> I am using Thunderbird (latest version). There is an option in the account
> compose options to use HTML. I do NOT have that checked. Other than that, I
> don't know how to do what you want me to. If anyone can help, please do.
> But I should note that I think others in this group use Google groups, and,
> in general, no one else does what your system does.

I use https://usenet-news.net/
slrn+vim on macOS :P

--
bmaxa now listens Ob-Neob Radio

Stephen Fuld [2021-07-13 21:58:53] wrote:
> I am using Thunderbird (latest version). There is an option in the account
> compose options to use HTML. I do NOT have that checked. Other than that,
> I don't know how to do what you want me to. If anyone can help, please do.
> But I should note that I think others in this group use Google groups, and,
> in general, no one else does what your system does.
>
> I am willing to experiment, but I don't know what to try.

FWIW, your messages look fine from my end (no HTML, proper quoting, ...).

Stefan

On 14/07/2021 15:35, Stefan Monnier wrote:
> Stephen Fuld [2021-07-13 21:58:53] wrote:
>> I am using Thunderbird (latest version). There is an option in the account
>> compose options to use HTML. I do NOT have that checked. Other than that,
>> I don't know how to do what you want me to. If anyone can help, please do.
>> But I should note that I think others in this group use Google groups, and,
>> in general, no one else does what your system does.
>>
>> I am willing to experiment, but I don't know what to try.
>
> FWIW, your messages look fine from my end (no HTML, proper quoting, ...).
>
>

I concur - looking at the source for your messages, they are all
absolutely fine.

Google groups doesn't need HTML posts or anything else in order to screw
up formatting, attributions, indentation, paragraph separation, code
snippets and every thing else. Perhaps they have even found a way to
make it do different bad things when you are using a small device rather
than a computer.

Ivan Godard wrote:
> On 7/13/2021 7:00 PM, MitchAlsup wrote:
>> On Tuesday, July 13, 2021 at 7:37:27 PM UTC-5, Ivan Godard wrote:
>>> How do you get 48?
>> <
>> There are 5 ways to round Double   into UnSigned,   Signed, or Float;
>> each.
>> There are 5 ways to round Float    into UnSigned or Signed; each.
>> There are 5 ways to round UnSigned into Double   or Float; each
>> There are 5 ways to round Signed   into Double   or Float; each
>> And there are assignment conversions:
>>     UnSigned = Signed,
>>     Signed   = UnSigned , and
>>     Double   = Float.
>> <
>> 15+10+10+10+3 = 48
>> <
>> The singed = unsigned is not a MOV saturating at SPOSMAX
>> The unsigned = signed is not a MOV saturating negatives to zero.
>>
>
> So you ignore integer overflow  behavior, float to double, short float,
> long float, and decimal. While you can get away without the rest (most
> do), I think you need float to double.

Do you?

double float2double(float x)

is basically a zero-extend/NOP (except when presented with a subnormal
float input) which just pads the exponent field from 8 to 11 bits
(adding (1023-127) to it) and adds 30 zero bits to the mantissa.

The key here is that there are no way this can generate any kind of
exception afaik?

The subnormal input will just be normalized.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen wrote:
> Ivan Godard wrote:
>> On 7/13/2021 7:00 PM, MitchAlsup wrote:
>>> On Tuesday, July 13, 2021 at 7:37:27 PM UTC-5, Ivan Godard wrote:
>>>> How do you get 48?
>>> <
>>> There are 5 ways to round Double into UnSigned, Signed, or Float;
>>> each.
>>> There are 5 ways to round Float into UnSigned or Signed; each.
>>> There are 5 ways to round UnSigned into Double or Float; each
>>> There are 5 ways to round Signed into Double or Float; each
>>> And there are assignment conversions:
>>> UnSigned = Signed,
>>> Signed = UnSigned , and
>>> Double = Float.
>>> <
>>> 15+10+10+10+3 = 48
>>> <
>>> The singed = unsigned is not a MOV saturating at SPOSMAX
>>> The unsigned = signed is not a MOV saturating negatives to zero.
>>>
>>
>> So you ignore integer overflow behavior, float to double, short
>> float, long float, and decimal. While you can get away without the
>> rest (most do), I think you need float to double.
>
> Do you?
>
> double float2double(float x)
>
> is basically a zero-extend/NOP (except when presented with a subnormal
> float input) which just pads the exponent field from 8 to 11 bits
> (adding (1023-127) to it) and adds 30 zero bits to the mantissa.
>
> The key here is that there are no way this can generate any kind of
> exception afaik?
>
> The subnormal input will just be normalized.
>
> Terje
>

Convert double/single source might be a signalled Nan.

Convert double to single might overflow exponent or underflow.
On x86/x64 those can trigger exceptions.

On Wednesday, July 14, 2021 at 1:49:09 AM UTC-5, Ivan Godard wrote:
> On 7/13/2021 7:00 PM, MitchAlsup wrote:
> > On Tuesday, July 13, 2021 at 7:37:27 PM UTC-5, Ivan Godard wrote:
> >> On 7/13/2021 9:12 AM, MitchAlsup wrote:
> >>> On Monday, July 12, 2021 at 10:22:13 PM UTC-5, Stefan Monnier wrote:
> >>>>>>> it isn't going away.
> >>>> Agreed, tho zero-terminated strings are rarely important for performance
> >>>> nowadays I'd think.
> >>>>>> bit integer added to every string. a zero byte string (empty) is
> >>>>>> therefore 2 bytes. second: if strings are over 65535 bytes *you can't
> >>>>>> have them* you are forced to use a 4 byte length encoder, now you have a
> >>>>>> *4* byte overhead for short strings...
> >>>> Nowadays you have to accommodate strings longer than 4GB, so you'll want
> >>>> 64bit for the length. In Emacs, a string object comes with 2
> >>>> length fields, both of them `ptrdiff_t` (one of them is for the length
> >>>> in bytes, the other for the length in "characters").
> >>>>
> >>>> We haven't made effort to assess whether it was the optimal/best choice,
> >>>> but small strings are never the dominant factor is total heap size.
> >>>>> in storage space, yes. in terms of implementing in hardware, as a special
> >>>>> microcoded operation, quite risky. if the hardware microcode could be
> >>>>> *defined* (a la Transmeta) i would say that was a route worth pursuing.
> >>>> Agreed, I don't see much need for special hardware support for string
> >>>> processing (whether zero-terminated or with a specified length).
> >>>> If it's a significant part of your total processing time, there's a good
> >>>> chance that the better way to speed it up is to use a different
> >>>> representation rather than to try and squeeze a few extra percents from
> >>>> the hardware.
> >>> <
> >>>>> typical implementations of FP to INT rounding are FORTY FIVE
> >>>>> instructions and involve FIVE branches.
> >>> <
> >>> A) There are 48 ways to do {float,double}FP<->INT{signed,unsigned}
> >>> B) there are instructions in My 66000 to do any and all of them.
> >> 48 ways? Two FP radices, five FP rounding modes, two int signednesses, 4
> >> integer overflow behavior. That's 80. If you are changing width in the
> >> process (we don't) then it's 4 FP widths X 4 integer widths, which
> >> explodes to much more than 48 and even if only {float, double}->single
> >> sized int it runs the count to 160 cases. You are probably not dealing
> >> with decimal, so we're back to 80, but not 48.
> >>
> >> How do you get 48?
> > <
> > There are 5 ways to round Double into UnSigned, Signed, or Float; each.
> > There are 5 ways to round Float into UnSigned or Signed; each.
> > There are 5 ways to round UnSigned into Double or Float; each
> > There are 5 ways to round Signed into Double or Float; each
> > And there are assignment conversions:
> > UnSigned = Signed,
> > Signed = UnSigned , and
> > Double = Float.
> > <
> > 15+10+10+10+3 = 48
> > <
> > The singed = unsigned is not a MOV saturating at SPOSMAX
> > The unsigned = signed is not a MOV saturating negatives to zero.
> >
> So you ignore integer overflow behavior, float to double, short float,
> long float, and decimal. While you can get away without the rest (most
> do), I think you need float to double.
<
Float to Double exists:: I counted the encoding again and came up with 48
again, and found (double)Rd=(float)Rs1, but I don't see how it did not get
accounted for int the "5 ways" above.

There is no HW support for short floats or long doubles or decimal

On Wednesday, July 14, 2021 at 11:25:13 AM UTC-5, EricP wrote:
> Terje Mathisen wrote:
> > Ivan Godard wrote:
> >> On 7/13/2021 7:00 PM, MitchAlsup wrote:
> >>> On Tuesday, July 13, 2021 at 7:37:27 PM UTC-5, Ivan Godard wrote:
> >>>> How do you get 48?
> >>> <
> >>> There are 5 ways to round Double into UnSigned, Signed, or Float;
> >>> each.
> >>> There are 5 ways to round Float into UnSigned or Signed; each.
> >>> There are 5 ways to round UnSigned into Double or Float; each
> >>> There are 5 ways to round Signed into Double or Float; each
> >>> And there are assignment conversions:
> >>> UnSigned = Signed,
> >>> Signed = UnSigned , and
> >>> Double = Float.
> >>> <
> >>> 15+10+10+10+3 = 48
> >>> <
> >>> The singed = unsigned is not a MOV saturating at SPOSMAX
> >>> The unsigned = signed is not a MOV saturating negatives to zero.
> >>>
> >>
> >> So you ignore integer overflow behavior, float to double, short
> >> float, long float, and decimal. While you can get away without the
> >> rest (most do), I think you need float to double.
> >
> > Do you?
> >
> > double float2double(float x)
> >
> > is basically a zero-extend/NOP (except when presented with a subnormal
> > float input) which just pads the exponent field from 8 to 11 bits
> > (adding (1023-127) to it) and adds 30 zero bits to the mantissa.
> >
> > The key here is that there are no way this can generate any kind of
> > exception afaik?
> >
> > The subnormal input will just be normalized.
> >
> > Terje
> >
<<<<<<<
> Convert double/single source might be a signalled Nan.
>
> Convert double to single might overflow exponent or underflow.
> On x86/x64 those can trigger exceptions.
<<<<<<<
Yes, any reasonable HW must perform these "little diversions" within the
name of convert...........

MitchAlsup wrote:
> On Wednesday, July 14, 2021 at 11:25:13 AM UTC-5, EricP wrote:
> <<<<<<<
>> Convert double/single source might be a signalled Nan.
>>
>> Convert double to single might overflow exponent or underflow.
>> On x86/x64 those can trigger exceptions.
> <<<<<<<
> Yes, any reasonable HW must perform these "little diversions" within the
> name of convert...........

I didn't want the possibility of FP stores to throw conversion exceptions
as the x86 can do. That gets into nasty things like the LSQ having to
sync with and query the FPU control register trap flags.

If a down-convert store of fp64 to fp32 or fp16 value overflows then
it saturates to the max value representable at the dest size
(it could saturate to infinity but that didn't seem correct),
or underflows to zero.

If one doesn't want that behavior then one does a down-conversion check
beforehand which may trigger exceptions.

On 7/14/2021 1:17 PM, EricP wrote:
> MitchAlsup wrote:
>> On Wednesday, July 14, 2021 at 11:25:13 AM UTC-5, EricP wrote:
>> <<<<<<<
>>> Convert double/single source might be a signalled Nan.
>>> Convert double to single might overflow exponent or underflow. On
>>> x86/x64 those can trigger exceptions.
>> <<<<<<<
>> Yes, any reasonable HW must perform these "little diversions" within the
>> name of convert...........
>
> I didn't want the possibility of FP stores to throw conversion exceptions
> as the x86 can do. That gets into nasty things like the LSQ having to
> sync with and query the FPU control register trap flags.
>
> If a down-convert store of fp64 to fp32 or fp16 value overflows then
> it saturates to the max value representable at the dest size
> (it could saturate to infinity but that didn't seem correct),
> or underflows to zero.
>
> If one doesn't want that behavior then one does a down-conversion check
> beforehand which may trigger exceptions.
>
>

Why not explicitly down-convert always? The program asked for it, after all.

On Wednesday, July 14, 2021 at 5:25:13 PM UTC+1, EricP wrote:

> Convert double/single source might be a signalled Nan.
>
> Convert double to single might overflow exponent or underflow.
> On x86/x64 those can trigger exceptions.

https://libre-soc.org/openpower/sv/int_fp_mv/

there's 4 main types (different rules)
* rust / llvm / java / SPIR-V - these are saturated without error
* standard IEEE754 conversion - provided by almost all languages and all CPUs
* x86 and Power ISA "saturation with NaN converted to minimum valid integer"
* the borked-in-the-brain, utterly-insane, javascript "modulo 2^32 / 2^64" conversion

l.

On 7/14/2021 1:44 PM, luke.l...@gmail.com wrote:
> On Wednesday, July 14, 2021 at 5:25:13 PM UTC+1, EricP wrote:
>
>> Convert double/single source might be a signalled Nan.
>>
>> Convert double to single might overflow exponent or underflow.
>> On x86/x64 those can trigger exceptions.
>
> https://libre-soc.org/openpower/sv/int_fp_mv/
>
> there's 4 main types (different rules)
> * rust / llvm / java / SPIR-V - these are saturated without error
> * standard IEEE754 conversion - provided by almost all languages and all CPUs
> * x86 and Power ISA "saturation with NaN converted to minimum valid integer"
> * the borked-in-the-brain, utterly-insane, javascript "modulo 2^32 / 2^64" conversion
>
> l.
>

These are actually two distinct steps, which may be combined for
encoding reasons.

The first step is converting the FP to another FP that has an integral
value, using the governing rounding rules. This is an IEE standard
operation; not that the result has no fraction part, but the exponent
may cause the integral value represented to be larger than that
representable in an integer of the same size. This step can raise
inexact if the argument was not already integral, and for some rounding
modes and maximal FP arguments can raise FP overflow with saturation to
infinity. A signalling NaN should signal.

The second step is to convert the integral FP value to an integer value,
which may overflow. This step should the same overflow detection and
reporting mechanism used for any other integer overflows in the ISA. A
quiet NaN should raise whatever integer invalid-datum exception is
defined by the ISA. Most ISAs have no such excepton, for a NaN would be UB.

On Wednesday, July 14, 2021 at 3:17:51 PM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Wednesday, July 14, 2021 at 11:25:13 AM UTC-5, EricP wrote:
> > <<<<<<<
> >> Convert double/single source might be a signalled Nan.
> >>
> >> Convert double to single might overflow exponent or underflow.
> >> On x86/x64 those can trigger exceptions.
> > <<<<<<<
> > Yes, any reasonable HW must perform these "little diversions" within the
> > name of convert...........
<
I'm lost::
<
> I didn't want the possibility of FP stores to throw conversion exceptions
> as the x86 can do. That gets into nasty things like the LSQ having to
> sync with and query the FPU control register trap flags.
<
We were talking about the CVT instruction not the ST instruction.
<
>
> If a down-convert store of fp64 to fp32 or fp16 value overflows then
> it saturates to the max value representable at the dest size
> (it could saturate to infinity but that didn't seem correct),
> or underflows to zero.
<
CVT should operate under the guise of "value that best represents the operand".
This could be Infnity, denorm, zero, or QNaN.
>
> If one doesn't want that behavior then one does a down-conversion check
> beforehand which may trigger exceptions.
<
Which is why we were talking about the CVT instruction and not the ST instruction.

On Wednesday, July 14, 2021 at 4:22:50 PM UTC-5, Ivan Godard wrote:
> On 7/14/2021 1:44 PM, luke.l...@gmail.com wrote:
> > On Wednesday, July 14, 2021 at 5:25:13 PM UTC+1, EricP wrote:
> >
> >> Convert double/single source might be a signalled Nan.
> >>
> >> Convert double to single might overflow exponent or underflow.
> >> On x86/x64 those can trigger exceptions.
> >
> > https://libre-soc.org/openpower/sv/int_fp_mv/
> >
> > there's 4 main types (different rules)
> > * rust / llvm / java / SPIR-V - these are saturated without error
> > * standard IEEE754 conversion - provided by almost all languages and all CPUs
> > * x86 and Power ISA "saturation with NaN converted to minimum valid integer"
> > * the borked-in-the-brain, utterly-insane, javascript "modulo 2^32 / 2^64" conversion
> >
> > l.
> >
> These are actually two distinct steps, which may be combined for
> encoding reasons.
>
> The first step is converting the FP to another FP that has an integral
> value, using the governing rounding rules.
<
The first step is converting the FP to another FP that has no fractional
significance, using the governing rounding rules.
<
> This is an IEE standard
> operation; not that the result has no fraction part, but the exponent
> may cause the integral value represented to be larger than that
> representable in an integer of the same size. This step can raise
> inexact if the argument was not already integral, and for some rounding
> modes and maximal FP arguments can raise FP overflow with saturation to
> infinity. A signalling NaN should signal.
>
> The second step is to convert the integral FP value to an integer value,
> which may overflow. This step should
<
?contain?
<
> the same overflow detection and
> reporting mechanism used for any other integer overflows in the ISA. A
> quiet NaN should raise whatever integer invalid-datum exception is
> defined by the ISA. Most ISAs have no such excepton, for a NaN would be UB.

On Tuesday, July 13, 2021 at 9:00:11 PM UTC-5, MitchAlsup wrote:
> On Tuesday, July 13, 2021 at 7:37:27 PM UTC-5, Ivan Godard wrote:
> > On 7/13/2021 9:12 AM, MitchAlsup wrote:
> > > On Monday, July 12, 2021 at 10:22:13 PM UTC-5, Stefan Monnier wrote:
> > >>>>> it isn't going away.
> > >> Agreed, tho zero-terminated strings are rarely important for performance
> > >> nowadays I'd think.
> > >>>> bit integer added to every string. a zero byte string (empty) is
> > >>>> therefore 2 bytes. second: if strings are over 65535 bytes *you can't
> > >>>> have them* you are forced to use a 4 byte length encoder, now you have a
> > >>>> *4* byte overhead for short strings...
> > >> Nowadays you have to accommodate strings longer than 4GB, so you'll want
> > >> 64bit for the length. In Emacs, a string object comes with 2
> > >> length fields, both of them `ptrdiff_t` (one of them is for the length
> > >> in bytes, the other for the length in "characters").
> > >>
> > >> We haven't made effort to assess whether it was the optimal/best choice,
> > >> but small strings are never the dominant factor is total heap size.
> > >>> in storage space, yes. in terms of implementing in hardware, as a special
> > >>> microcoded operation, quite risky. if the hardware microcode could be
> > >>> *defined* (a la Transmeta) i would say that was a route worth pursuing.
> > >> Agreed, I don't see much need for special hardware support for string
> > >> processing (whether zero-terminated or with a specified length).
> > >> If it's a significant part of your total processing time, there's a good
> > >> chance that the better way to speed it up is to use a different
> > >> representation rather than to try and squeeze a few extra percents from
> > >> the hardware.
> > > <
> > >>> typical implementations of FP to INT rounding are FORTY FIVE
> > >>> instructions and involve FIVE branches.
> > > <
> > > A) There are 48 ways to do {float,double}FP<->INT{signed,unsigned}
> > > B) there are instructions in My 66000 to do any and all of them.
> > 48 ways? Two FP radices, five FP rounding modes, two int signednesses, 4
> > integer overflow behavior. That's 80. If you are changing width in the
> > process (we don't) then it's 4 FP widths X 4 integer widths, which
> > explodes to much more than 48 and even if only {float, double}->single
> > sized int it runs the count to 160 cases. You are probably not dealing
> > with decimal, so we're back to 80, but not 48.
> >
> > How do you get 48?
> <
> There are 5 ways to round Double into UnSigned, Signed, or Float; each.
> There are 5 ways to round Float into UnSigned or Signed; each.
> There are 5 ways to round UnSigned into Double or Float; each
> There are 5 ways to round Signed into Double or Float; each
> And there are assignment conversions:
> UnSigned = Signed,
> Signed = UnSigned , and
> Double = Float.
> <
> 15+10+10+10+3 = 48
> <
> The singed = unsigned is not a MOV saturating at SPOSMAX
> The unsigned = signed is not a MOV saturating negatives to zero.
<
<
Also note:
There are 12=2×6 ways to round a {double, float} to the same container.
<
{I.e. get rid of the fractional significance.}
<
These do not convert between types, but round within a single type and use
an instruction spelled RND rather than CVT.

MitchAlsup wrote:
> On Wednesday, July 14, 2021 at 3:17:51 PM UTC-5, EricP wrote:
>> MitchAlsup wrote:
>>> On Wednesday, July 14, 2021 at 11:25:13 AM UTC-5, EricP wrote:
>>> <<<<<<<
>>>> Convert double/single source might be a signalled Nan.
>>>>
>>>> Convert double to single might overflow exponent or underflow.
>>>> On x86/x64 those can trigger exceptions.
>>> <<<<<<<
>>> Yes, any reasonable HW must perform these "little diversions" within the
>>> name of convert...........
> <
> I'm lost::
> <

I'm just muddying the waters a bit I suppose.

For example, to contrast Intel's FP approach with one FADD instruction,
vs Alpha's 4 FADDx instructions (one for each data type).

The design consequences propagate to the store instruction
when one tries to store an fp64 register value to 32-bit memory.

>> I didn't want the possibility of FP stores to throw conversion exceptions
>> as the x86 can do. That gets into nasty things like the LSQ having to
>> sync with and query the FPU control register trap flags.
> <
> We were talking about the CVT instruction not the ST instruction.
> <

As I mentioned the x86 FP store does do a convert which can cause
exceptions if one stores an fp64 to 32-bit memory operand.

>> If a down-convert store of fp64 to fp32 or fp16 value overflows then
>> it saturates to the max value representable at the dest size
>> (it could saturate to infinity but that didn't seem correct),
>> or underflows to zero.
> <
> CVT should operate under the guise of "value that best represents the operand".
> This could be Infnity, denorm, zero, or QNaN.

As I mentioned, Intel FP store can do a conversion and can trap.

Alpha, in contrast, does a straight forward bit-wise transform on the
value to be stored. It is your responsibility to make sure the the
value in the source register was the correct data type to begin with.
(chops high order bits off the exponent, low order bit off mantissa,
packs remaining bits together.)
(Alpha also has multiple memory formats to deal with:
VAX 32-bit F, VAX 64-bit G (both weirdo middle endian layout)
IEEE 32-bit S, IEEE 64-bit T.)

>> If one doesn't want that behavior then one does a down-conversion check
>> beforehand which may trigger exceptions.
> <
> Which is why we were talking about the CVT instruction and not the ST instruction.

I'm pointing out that when one stores an fp64 to fp32 memory
there is a down-conversion taking place.
That conversion can be done like Intel (with traps),
like Alpha (with bit truncates), or maybe with saturates.

Intel has one FADD instruction that generates the same output results.

Alpha has an FADDx instruction for each data type F, G, S, T.
If you are going to store an 'S' 32-bit IEEE type then the last
instruction had to generate an S type into the dest register.
The FP store instruction STF assumes the source register contains an
F data type and therefore the stores' conversion to 32-bits "works".

On Tue, 13 Jul 2021 21:58:53 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

>I am using Thunderbird (latest version). There is an option in the
>account compose options to use HTML. I do NOT have that checked. Other
>than that, I don't know how to do what you want me to. If anyone can
>help, please do. But I should note that I think others in this group
>use Google groups, and, in general, no one else does what your system does.
>
>I am willing to experiment, but I don't know what to try.

*Disclaimer* I have never played with these settings.

In the general Options under Composition there is a "Send Options"
button. It allows you to declare mail domains that expect messages to
be in plain text. Also you can control what to do when a message has
multiple recipients that expect different formats.

Perhaps if you set Google / Gmail as a text domain? But you probably
would have to prevent TBird from also sending in HTML format.

George

On 15/07/2021 14:48, George Neuner wrote:
> On Tue, 13 Jul 2021 21:58:53 -0700, Stephen Fuld
> <sfuld@alumni.cmu.edu.invalid> wrote:
>
>> I am using Thunderbird (latest version). There is an option in the
>> account compose options to use HTML. I do NOT have that checked. Other
>> than that, I don't know how to do what you want me to. If anyone can
>> help, please do. But I should note that I think others in this group
>> use Google groups, and, in general, no one else does what your system does.
>>
>> I am willing to experiment, but I don't know what to try.
>
> *Disclaimer* I have never played with these settings.
>
> In the general Options under Composition there is a "Send Options"
> button. It allows you to declare mail domains that expect messages to
> be in plain text. Also you can control what to do when a message has
> multiple recipients that expect different formats.
>
> Perhaps if you set Google / Gmail as a text domain? But you probably
> would have to prevent TBird from also sending in HTML format.
>

That all applies to email, not Usenet. When you post to a newsserver,
you are not sending to google or a gmail account.

His posts are in plain text, not HTML - there is nothing wrong with his
settings as far as I can see. It is google groups that is broken.

On Thursday, July 15, 2021 at 4:27:48 AM UTC+1, EricP wrote:

> Alpha, in contrast, does a straight forward bit-wise transform on the
> value to be stored. It is your responsibility to make sure the the
> value in the source register was the correct data type to begin with.
> (chops high order bits off the exponent, low order bit off mantissa,
> packs remaining bits together.)

Power ISA likewise. Single precision takes place *at* single precision, the bits are simply distributed over 64 bit *as if* and in identical format to FP64. to the extent that, should a decision be made to use FP64 operations they may do so *without conversion*.

the only conversion needed is FP64-to-FP32 in order to round and check range, but the other way FP32-to-5l64 is nevrr needed.

LDST for FP32 knows exactly what to do: transfer the appropriate bits to/from the 64 bit FPR reg. no conversion needed there either.

it is very elegant, a little weird, and takes getting used to.

l.

On Thursday, July 15, 2021 at 2:44:59 PM UTC+1, David Brown wrote:

> His posts are in plain text, not HTML - there is nothing wrong with his
> settings as far as I can see. It is google groups that is broken.

you can see online what happened:

https://groups.google.com/g/comp.arch/c/0n9Ko6wjmHU/m/KNjd3pSKAAAJ

steven replied to me, but look carefully: my text starting "MSRPC" is not properly indented, it appears in a subtly different font and colour.

replying to that, google groups via a mobile chrome browser was unable to cope, and crushed the indentation.

i suspect therefore it is a unique interaction: not one factor but two.

i find there is no problem with indentation replying to *anyone else's* messages: it appears to be a unique interaction between Thunderbird and google groups when used with chrome on mobile.

l.

On 7/15/2021 6:53 AM, luke.l...@gmail.com wrote:
> On Thursday, July 15, 2021 at 2:44:59 PM UTC+1, David Brown wrote:
>
>> His posts are in plain text, not HTML - there is nothing wrong with his
>> settings as far as I can see. It is google groups that is broken.
>
> you can see online what happened:
>
> https://groups.google.com/g/comp.arch/c/0n9Ko6wjmHU/m/KNjd3pSKAAAJ
>
> steven replied to me, but look carefully: my text starting "MSRPC" is not properly indented, it appears in a subtly different font and colour.
>
> replying to that, google groups via a mobile chrome browser was unable to cope, and crushed the indentation.
>
> i suspect therefore it is a unique interaction: not one factor but two.
>
> i find there is no problem with indentation replying to *anyone else's* messages: it appears to be a unique interaction between Thunderbird and google groups when used with chrome on mobile.

Thanks to all who replied. I agree with David that the options George
referred to are for e-mail, not newsgroups. And for newsgroups, there
is no "domain" to put in the text list.

Luke may be right that it is some weird interaction. Can someone else
using Thunderbird reply so Luke can see test his hypothesis?

In the mean time, since no one else seems to have a problem with my
posts, and there isn't an obvious change to make, I am not going to
change anything. But I will double check any of Luke's replies to my
posts to see if the attributions are correct.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Thursday, July 15, 2021 at 8:46:47 AM UTC-5, luke.l...@gmail.com wrote:
> On Thursday, July 15, 2021 at 4:27:48 AM UTC+1, EricP wrote:
>
> > Alpha, in contrast, does a straight forward bit-wise transform on the
> > value to be stored. It is your responsibility to make sure the the
> > value in the source register was the correct data type to begin with.
> > (chops high order bits off the exponent, low order bit off mantissa,
> > packs remaining bits together.)
> Power ISA likewise. Single precision takes place *at* single precision, the bits are simply distributed over 64 bit *as if* and in identical format to FP64. to the extent that, should a decision be made to use FP64 operations they may do so *without conversion*.
>
> the only conversion needed is FP64-to-FP32 in order to round and check range, but the other way FP32-to-5l64 is nevrr needed.
<
FP32-FP64 one only has to worry about denorms becoming norms.
>
> LDST for FP32 knows exactly what to do: transfer the appropriate bits to/from the 64 bit FPR reg. no conversion needed there either.
>
> it is very elegant, a little weird, and takes getting used to.
>
> l.

On 15/07/2021 16:57, Stephen Fuld wrote:
> On 7/15/2021 6:53 AM, luke.l...@gmail.com wrote:
>> On Thursday, July 15, 2021 at 2:44:59 PM UTC+1, David Brown wrote:
>>
>>> His posts are in plain text, not HTML - there is nothing wrong with his
>>> settings as far as I can see. It is google groups that is broken.
>>
>> you can see online what happened:
>>
>> https://groups.google.com/g/comp.arch/c/0n9Ko6wjmHU/m/KNjd3pSKAAAJ
>>
>> steven replied to me, but look carefully: my text starting "MSRPC" is
>> not properly indented, it appears in a subtly different font and colour.
>>
>> replying to that, google groups via a mobile chrome browser was unable
>> to cope, and crushed the indentation.
>>
>> i suspect therefore it is a unique interaction: not one factor but two.
>>
>> i find there is no problem with indentation replying to *anyone
>> else's* messages: it appears to be a unique interaction between
>> Thunderbird and google groups when used with chrome on mobile.
>
>
> Thanks to all who replied.  I agree with David that the options George
> referred to are for e-mail, not newsgroups.  And for newsgroups, there
> is no "domain" to put in the text list.
>
> Luke may be right that it is some weird interaction.  Can someone else
> using Thunderbird reply so Luke can see test his hypothesis?
>
> In the mean time, since no one else seems to have a problem with my
> posts, and there isn't an obvious change to make, I am not going to
> change anything.  But I will double check any of Luke's replies to my
> posts to see if the attributions are correct.
>

I've looked a bit closer now - it was helpful that Luke pointed out
exactly which part he had written but which appeared as /your/ text in
your post.

There is nothing wrong with your Thunderbird settings. But you made an
error when replying to Luke. You were trying to snip some of his reply,
including the start of the paragraph containing "MSRPC...", and only
keeping that part. Unfortunately, you also deleted the ">" indent
symbol and thus the bit you left was formatted as coming from you, not Luke.

So nothing dramatic or complicated is going on - you just deleted a
character too much.

Of course, the blame still lies with the idiotic and broken google
groups - if it followed Usenet standards and got its line lengths and
paragraphs formatted correctly, you would not have been faced with a
single big line but a proper quoted paragraph, and you'd have seen the
mistake immediately.

Luke, if at all possible, /please/ get a proper newsreader and proper
newsserver. (I realise it may not be possible.)