Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #107267 > unrolled thread

How to create a 128 bit type in C

Back to article view | Back to comp.lang.c

Contents

  How to create a 128 bit type in C acidlategamer@gmail.com - 2017-03-28 08:26 -0700
    Re: How to create a 128 bit type in C BartC <bc@freeuk.com> - 2017-03-28 16:42 +0100
      Re: How to create a 128 bit type in C acidlategamer@gmail.com - 2017-03-28 09:15 -0700
        Re: How to create a 128 bit type in C BartC <bc@freeuk.com> - 2017-03-28 19:15 +0100
    Re: How to create a 128 bit type in C Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2017-03-28 17:44 +0200
    Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-28 16:29 +0000
      Re: How to create a 128 bit type in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-28 10:52 -0700
        Re: How to create a 128 bit type in C Ike Naar <ike@iceland.freeshell.org> - 2017-03-28 17:55 +0000
          Re: How to create a 128 bit type in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 20:17 +0200
            Re: How to create a 128 bit type in C David Brown <david.brown@hesbynett.no> - 2017-03-28 21:17 +0200
        Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-28 18:09 +0000
      Re: How to create a 128 bit type in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 19:52 +0200
        Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-28 18:11 +0000
          Re: How to create a 128 bit type in C BartC <bc@freeuk.com> - 2017-03-28 19:21 +0100
            Re: How to create a 128 bit type in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 20:29 +0200
              Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-28 18:55 +0000
                Re: How to create a 128 bit type in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 21:04 +0200
            Re: How to create a 128 bit type in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-28 12:13 -0700
              Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 16:14 -0500
                Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 13:13 +0000
                  Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 00:12 -0500
                    Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:36 +0000
                      Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 12:41 -0500
                        Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 17:55 +0000
                        Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 17:59 +0000
                          Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-04-01 00:42 -0500
                            Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-04-03 13:37 +0000
                              Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-04-03 17:38 -0500
                                Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-04-03 17:49 -0500
                                  Re: How to create a 128 bit type in C Keith Thompson <kst-u@mib.org> - 2017-04-03 17:43 -0700
                                    Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-04-03 20:39 -0500
                                Re: How to create a 128 bit type in C Richard Heathfield <rjh@cpax.org.uk> - 2017-04-04 07:00 +0100
          Re: How to create a 128 bit type in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 20:28 +0200
            Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 16:37 -0500
              Re: How to create a 128 bit type in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 23:56 +0200
                Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 18:36 -0500
                  Re: How to create a 128 bit type in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 01:43 +0200
                    Re: English grammar, nonrestrictive clause Noob <root@127.0.0.1> - 2017-03-31 21:24 +0200
                      Re: English grammar, nonrestrictive clause jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-31 21:51 +0200
                        Re: English grammar, nonrestrictive clause Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-01 12:34 +0100
              Re: How to create a 128 bit type in C supercat@casperkitty.com - 2017-03-28 15:11 -0700
                Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 19:30 -0500
              Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 13:19 +0000
                Re: How to create a 128 bit type in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-29 14:42 +0100
                  Re: How to create a 128 bit type in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 15:12 +0000
                  Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 00:26 -0500
                Re: How to create a 128 bit type in C Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 00:42 -0500
        Re: How to create a 128 bit type in C Keith Thompson <kst-u@mib.org> - 2017-03-28 11:40 -0700
        Re: How to create a 128 bit type in C Keith Thompson <kst-u@mib.org> - 2017-03-28 11:40 -0700
          Re: How to create a 128 bit type in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 20:48 +0200
            Re: How to create a 128 bit type in C Keith Thompson <kst-u@mib.org> - 2017-03-28 12:05 -0700
              Re: How to create a 128 bit type in C Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 20:13 +0100
                Re: How to create a 128 bit type in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 21:43 +0200
                  Re: Thunderbird charset Noob <root@127.0.0.1> - 2017-03-31 21:38 +0200
      Re: How to create a 128 bit type in C David Brown <david.brown@hesbynett.no> - 2017-03-28 21:19 +0200
    Re: How to create a 128 bit type in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-28 18:15 +0100
    Re: How to create a 128 bit type in C Barry Schwarz <schwarzb@dqel.com> - 2017-03-28 10:27 -0700
    Re: How to create a 128 bit type in C "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-03-28 14:16 -0700
    Re: How to create a 128 bit type in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-28 17:38 -0700
    Re: How to create a 128 bit type in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-30 05:19 -0700
      Re: How to create a 128 bit type in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-30 05:32 -0700
        Re: How to create a 128 bit type in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-30 05:40 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#107335

On Tuesday, March 28, 2017 at 4:36:35 PM UTC-5, robert...@yahoo.com wrote:
> And while x86-64 can handle multiple precision code fairly well, a lot
> of RISCs and other machines make it rather more tedious.  Lack of a
> carry flag or double width multiplication are common.  Both can
> obviously be worked around, but the difference between
> (mov/add/mov/adc/mov/adc/mov/adc) to implement a quad add on x86 and
> what you have to do on Alpha (without a carry flag) is pretty
> substantial.

On systems that lack add-with-carry, it's tough to get a correct carry
out of the second word in both cases where the second word of an input
operand has all bits set and there's a carry out of the first word.

For applications which need to yield an arithmetically correct result
if no overflow occurred, or report that an overflow occurred if the
result would not be arithmetically correct, but which are not required
to report overflows that don't end up affecting the results, it may be
helpful to have a type which could, at the compiler's leisure, either
keep some precision beyond a normal type or truncate such precision and
set an error flag if doing so would change the value.  If a compiler
defined its semantics in such fashion and code did something like:

    int x=(y+z)/2;

having a compiler do an add followed by a rotate right through carry may
be cheaper than checking whether the addition overflowed and trapping if
so.  Likewise, when adding a bunch of numbers it may be easier to do an
extended-precision add and then check whether the result is in range of
the target type, than to check for overflow after every step.  Some
platforms are good at overflow checking and bad at multi-precision math,
while others handle multi-precision math well but aren't as good at
overflow checking.  Letting a compiler pick which approach would be better
in any given situation would allow the required semantics to be achieved
more quickly than if the programmer had to force it.

[toc] | [prev] | [next] | [standalone]

#107347

On Tue, 28 Mar 2017 15:11:43 -0700 (PDT), supercat@casperkitty.com
wrote:

>On Tuesday, March 28, 2017 at 4:36:35 PM UTC-5, robert...@yahoo.com wrote:
>> And while x86-64 can handle multiple precision code fairly well, a lot
>> of RISCs and other machines make it rather more tedious.  Lack of a
>> carry flag or double width multiplication are common.  Both can
>> obviously be worked around, but the difference between
>> (mov/add/mov/adc/mov/adc/mov/adc) to implement a quad add on x86 and
>> what you have to do on Alpha (without a carry flag) is pretty
>> substantial.
>
>On systems that lack add-with-carry, it's tough to get a correct carry
>out of the second word in both cases where the second word of an input
>operand has all bits set and there's a carry out of the first word.


Clumsy and with excessive overhead, but not actually tough.  On Alpha,
for example, you'd do something like:

;$1=carry in/out
;$2=A (in)
;$3=B (in)
;$4=sum (out)
;$5=work

  addq $2,$3,$4
  cmplt $4,$3,$5
  addq $1,$4,$4
  cmplt $4,$1,$1
  bis $1,$5,$5


On S/360 it was really painful, since the only way you could really do
this was to do a conditional branch after each add:

;R1=carry in/out
;R2=A (in)
;R3=B (in)
;R4=sum (out)
;R5=work
;R6=1 (constant)

  XR R5,R5 ;zero R5
  LR R4,R2
  ALR R4,R3
  BC 6, NC1 ;branch no carry
  LR R5,R6
NC1:
  ALR R4,R1
  BC 6, NC2 ;branch no carry
  OR R5,R6
NC2:
  LR R1,R5

Not actually difficult, just really painful.

The alternative of retrieving the condition code value and processing
that was even worse, because the only way to do that was to issue a
subroutine call instruction (which returned in in the high byte of the
return address register (that would have looked like the following IPM
based sample, but with the IPMs replaced with a subroutine call to the
following instruction - IOW "BALR Rx,0").

Somewhere at or just before the start of the 31-bit (XA) era a
specific instruction to do that was added (insert program mask).  At
least theoretically you could do a shift and mask on that, and end up
with something like:

;R1=carry in/out
;R2=A (in)
;R3=B (in)
;R4=sum (out)
;R5=work
;R6=1 (constant)

  LR R4,R2
  AR R4,R3
  IPM R5  ;it's either bit 2 or 3 that ends up indicating carry
  SRL R5,28 ;a shift count of 28 is correct for bit 3
  AR R4,R1
  IPM R1
  SRL R1,28
  OR R1,R5
  NR R1,R6
 
That's still ugly as sin, but at least it avoids *two* conditional
branches.

It was always tempting to do this with halfword sized limbs instead.
On S/370 and later, 24-bit limbs were plausible too.

Now, of course, you can do it in a single instruction.


>For applications which need to yield an arithmetically correct result
>if no overflow occurred, or report that an overflow occurred if the
>result would not be arithmetically correct, but which are not required
>to report overflows that don't end up affecting the results, it may be
>helpful to have a type which could, at the compiler's leisure, either
>keep some precision beyond a normal type or truncate such precision and
>set an error flag if doing so would change the value.  If a compiler
>defined its semantics in such fashion and code did something like:
>
>    int x=(y+z)/2;
>
>having a compiler do an add followed by a rotate right through carry may
>be cheaper than checking whether the addition overflowed and trapping if
>so.


Assuming there *is* a rotate through carry.


>  Likewise, when adding a bunch of numbers it may be easier to do an
>extended-precision add and then check whether the result is in range of
>the target type, than to check for overflow after every step.  Some
>platforms are good at overflow checking and bad at multi-precision math,
>while others handle multi-precision math well but aren't as good at
>overflow checking.  Letting a compiler pick which approach would be better
>in any given situation would allow the required semantics to be achieved
>more quickly than if the programmer had to force it.


In many respects Cobol did that approximately right.  You could
generally ask for over (really out-of-range) checking on any
computation, and it was up to the compiler to figure out how to do it:

  compute x = (y+z)/2
    on size error
      ...error handling code...

As a general concept, it would trigger the on size error clause when
the result would not fit in the destination.  And in general the
assumption was that the result *would* be computed correctly (subject
to the as-if rule, of course).  So if you defined X as a two (decimal)
digit field, and y and z as 18 digits, you'd expect the result to be
equivalent to computing a 19 digit sum, dividing that by two, and then
checking if that results fits in two digits.

You could omit the on size error clause, and then you'd usually get
some sort of odd truncation, often depending on the formats of the
types being used (for example if x and the intermediate result were
binary, you might just end up with the low 16 bits of the results in
x, despite that being rather out of range)..  Note that the original
Cobol spec allowed only decimal truncation, except that was ignored by
basically everyone as the overhead was too high - newer versions
explicitly allow other truncations modes.

[toc] | [prev] | [next] | [standalone]

#107381

Robert Wessel <robertwessel2@yahoo.com> writes:
>On Tue, 28 Mar 2017 20:28:22 +0200, jacobnavia

>>Gcc implemented that first?
>
>
>No, I suspect 128 bit types, at least for intermediates, were first
>implemented by Cobol compilers in the early sixties, or before.

Those systems (1401, 360/xx, Electrodata 220, Burroughs B2500)
used BCD representation, so no, they didn't used 128-bit types.
The B2500 could operate on up to 100 digit fields (400 bits)
using a single arithmetic instruction.

The 360 did support 128-bit binary floating point, but that
wouldn't have been used by COBOL.

[toc] | [prev] | [next] | [standalone]

#107386

scott@slp53.sl.home (Scott Lurndal) writes:
<snip>
> The 360 did support 128-bit binary floating point, but that
> wouldn't have been used by COBOL.

I can't find any reference to it in the "IBM System/360 Principles of
Operation".  Many some of the later models?

(In fact, the original 360 did not even have truly binary floating
point.  It had hexadecimal floating-point.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#107395

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
><snip>
>> The 360 did support 128-bit binary floating point, but that
>> wouldn't have been used by COBOL.
>
>I can't find any reference to it in the "IBM System/360 Principles of
>Operation".  Many some of the later models?

 IIRC, the higher end models like the /85, /195 did.  It was
emulated in software on other models.

[toc] | [prev] | [next] | [standalone]

#107452

On Wed, 29 Mar 2017 14:42:23 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>scott@slp53.sl.home (Scott Lurndal) writes:
><snip>
>> The 360 did support 128-bit binary floating point, but that
>> wouldn't have been used by COBOL.
>
>I can't find any reference to it in the "IBM System/360 Principles of
>Operation".  Many some of the later models?
>
>(In fact, the original 360 did not even have truly binary floating
>point.  It had hexadecimal floating-point.)


Quad precision HFP was optional (but not officially part of the ISA)
on at least some S/360s, and became an optional part of the ISA with
S/370, and was implemented on many S/370 systems.  Quad division was
not architected, nor supported on any machine I know of.  I'm not sure
exactly when quad HFP became standard on machines (I think everything
in the post S/370 generation - 4300s, 3030s, implemented quad), but
with the transition to XA (the 31 bit architecture), quad precision
HFP, including quad divide, became a base part of the ISA.

Binary FP became a standard feature on the 9672 G5's, the single
biggest motivation was Java support.  The 9672's are the predecessors
of the current 64-bit zArch systems (the first such system, the z900,
was effectively the G7, the most current system, z13, gets the "13" in
its name from being the 13th generation in that line - IOW the G13).

[toc] | [prev] | [next] | [standalone]

#107453

On Wed, 29 Mar 2017 13:19:46 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>>On Tue, 28 Mar 2017 20:28:22 +0200, jacobnavia
>
>>>Gcc implemented that first?
>>
>>
>>No, I suspect 128 bit types, at least for intermediates, were first
>>implemented by Cobol compilers in the early sixties, or before.
>
>Those systems (1401, 360/xx, Electrodata 220, Burroughs B2500)
>used BCD representation, so no, they didn't used 128-bit types.
>The B2500 could operate on up to 100 digit fields (400 bits)
>using a single arithmetic instruction.
>
>The 360 did support 128-bit binary floating point, but that
>wouldn't have been used by COBOL.


While the Cobol on S/360 certainly supported decimal, you could also
define a field as being binary ("USAGE COMP").  It still supported the
usual 18 decimal digit (scaled) numbers.  While that required only a
64-bit storage format, the accuracy requirements demanded larger
intermediate results.

In fact they *also* required larger intermediates for pure decimal,
and the Cobol compiler had to implement a multiple-precision library
for that, even in decimal.  While the decimal addition and subtraction
instructions can handle 31 digit numbers, multiplication and division
have restrictions on S/360 (and still do), that prevents single
instructions from handling 18 digit numbers in an unrestricted way.

For example, a multiplier cannot be longer than 15 digits, and the
value in the multiplicand is limited by the physical size of the
multiplier - if you had a 7 byte (15 digit) multiplier, the
multiplicand has to start with seven bytes of zeros, limiting it to 17
digits.  The rules are even more peculiar for decimal division (not
least because both the quotient and remainder have to end up fitting
in a single 16 byte result field).

[toc] | [prev] | [next] | [standalone]

#107297

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 28/03/2017 à 18:29, Scott Lurndal a écrit :
>> acidlategamer@gmail.com writes:
>>> Today a friend of mine asked this to me
>>> create a 128 bit type and you are given two 64 bit int type. One is
>>> sint64_t and one is uint64_t
>>>
>>
>> Personally, I'd either use the GCC extension int128_t/uint128_t or
>> use the gnu multiprecision library rather than reinventing the wheel.
>>
>
> 128 bit integers are not a gcc extension. Lcc-win has that too.

Then they're also an lcc-win extension.

BTW, glibc's <stdint.h> doesn't define int128_t or uint128_t.  gcc
predefines, *on some systems*, types `__int128` and `unsigned __int128`.
There are no integer constants of those types, and intmax_t and
uintmax_t are still 64 bits (which I consider unfortunate).

(Apparently there are some ABI issues that prevented them from treating
them as integer types and adjusting [u]intmax_t accordingly.)

> But the advantage of reinventing wheels is that you learn how wheels are 
> done and how they work...

Yes, whether it makes sense to reinvent the wheel depends very much on
what your actual goal is.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#107298

jacobnavia <jacob@jacob.remcomp.fr> writes:
[snip]

jacob, FYI:

> Content-Type: text/plain; charset=windows-1252; format=flowed

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#107300

Le 28/03/2017 à 20:40, Keith Thompson a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
> [snip]
>
> jacob, FYI:
>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>

You can't get rid of windows. I posted that in a mac, running OS X. I 
told thunderbird to put utf8, but somehow, windows keeps coming back and 
I do not feel like trying to debug this stuff.

Windows, like many other nasty things, keeps coming back to you through 
I do not know what backdoors.

I can't change that right now.

[toc] | [prev] | [next] | [standalone]

#107307

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 28/03/2017 á 20:40, Keith Thompson a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> [snip]
>>
>> jacob, FYI:
>>
>>> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> You can't get rid of windows. I posted that in a mac, running OS X. I 
> told thunderbird to put utf8, but somehow, windows keeps coming back and 
> I do not feel like trying to debug this stuff.
>
> Windows, like many other nasty things, keeps coming back to you through 
> I do not know what backdoors.
>
> I can't change that right now.

Understood.  I've gotten pretty tired of dealing with this myself.
I've just implemented a crude workaround that should at least let
me deal with accented characters correctly.  (Universal UTF-8 is
the worst possible solution to all this, except for all the others.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#107309

On 28/03/17 20:05, Keith Thompson wrote:
<snip>
> I've just implemented a crude workaround that should at least let
> me deal with accented characters correctly.  (Universal UTF-8 is
> the worst possible solution to all this, except for all the others.)

You seem to have succeeded in switching to UTF-8.

I've told Thunderbird in no uncertain terms to use UTF-8, but it's still 
using windows-1252. Sometimes I just want to take Thunderbird and 
Firefox out to the bonfire, because they are the worst newsreader and 
browser imaginable (except for all the others).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#107317

Le 28/03/2017 à 21:13, Richard Heathfield a écrit :
> On 28/03/17 20:05, Keith Thompson wrote:
> <snip>
>> I've just implemented a crude workaround that should at least let
>> me deal with accented characters correctly.  (Universal UTF-8 is
>> the worst possible solution to all this, except for all the others.)
>
> You seem to have succeeded in switching to UTF-8.
>
> I've told Thunderbird in no uncertain terms to use UTF-8, but it's still
> using windows-1252. Sometimes I just want to take Thunderbird and
> Firefox out to the bonfire, because they are the worst newsreader and
> browser imaginable (except for all the others).
>

But isn't the mail in /var/spool/mail somewhere?

My service provider is running linux, and there are some hookups in the 
linux mail software to add a filter. Then you can parse the headers and 
force utf8 or whatever...

But that is a lot of work and doesn't patch thunderbird. Is there 
anywhere the source code of thunderbird?

if (isWindowsCharset(message)) {
     SetUtf8Charset(message);
}

somewhere?

[toc] | [prev] | [next] | [standalone]

#107550 — Re: Thunderbird charset

On 28/03/2017 21:43, jacobnavia wrote:

> But that is a lot of work and doesn't patch thunderbird. Is there 
> anywhere the source code of thunderbird?
> 
> if (isWindowsCharset(message)) {
>      SetUtf8Charset(message);
> }
> 
> somewhere?

Possible candidates in about:config

1) intl.fallbackCharsetList.ISO-8859-1
2) mailnews.force_charset_override
3) mailnews.reply_in_default_charset
4) mailnews.send_default_charset

comment for 1)
fallback charset list for Unicode conversion (converting from Unicode) currently used for mail send only to handle symbol characters ...

comment for 2)
ignore specified MIME encoding and use the default encoding for display

So best option seems to be #3 and #4
I have them set to ISO-8859-15

[toc] | [prev] | [next] | [standalone]

#107313

On 28/03/17 18:29, Scott Lurndal wrote:
> acidlategamer@gmail.com writes:
>> Hi all,
>>
>> Today a friend of mine asked this to me
>> create a 128 bit type and you are given two 64 bit int type. One is sint64_t and one is uint64_t
>>
>
> Personally, I'd either use the GCC extension int128_t/uint128_t or
> use the gnu multiprecision library rather than reinventing the wheel.
>

The gnu gmp library is massively over the top for a single 128 bit type 
- it will probably be a good deal more work trying to figure out how to 
use it than to make your own struct of two 64-bit ints.

But if you can use a 64-bit gcc, and thus use __int128, your work is 
done.  The same applies with Jacob's compiler, which I believe has 128 
bit types.

[toc] | [prev] | [next] | [standalone]

#107281

acidlategamer@gmail.com writes:

> Today a friend of mine asked this to me create a 128 bit type and you
> are given two 64 bit int type. One is sint64_t and one is uint64_t
>
> I said I can create it like this,
>
> struct int128_t{
>                    sint64_t sint;
>                    uint64_t uint;
> }a, b;
> now he said to compare two such types in this function
> a == b, return 0
> a > b, return 1
> a < b return -1

<snip>
> Anyone can think of any way?

One option: treat the numbers as two unsigned 64-bit ints and compare as
normal, but, on return, if the top bits of the two high words differ,
invert the result.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#107282

On Tue, 28 Mar 2017 08:26:51 -0700 (PDT), acidlategamer@gmail.com
wrote:

>Hi all,
>
>Today a friend of mine asked this to me
>create a 128 bit type and you are given two 64 bit int type. One is sint64_t and one is uint64_t
>
>I said I can create it like this,
>
>struct int128_t{
>                   sint64_t sint;
>                   uint64_t uint;
>}a, b;
>now he said to compare two such types in this function
>a == b, return 0
>a > b, return 1
>a < b return -1
>
>I could not think of how to do it, because I couldn't think how negative numbers How will I do it
>a.sint = -21;   
>a.unit = 245;
>In this case resulting number will be a 128 bit number combined, but what the number will be is not easy to deduce. So I gave up thinking.
>
>Anyone can think of any way?

Before deciding how to represent the value, let's agree on what the
value is.  As a starting point, let's simplify the problem to
representing a 16-bit signed my_int given an 8-bit schar and uchar.

If schar is non-negative, it seems pretty straight forward that the
value represented is ARITHMETICALLY schar*2^8+uchar (those are not C
operators).  So (0,5) is 5 while (1,7) is 263.

Now, what value does (-1,1) represent.  And that value cannot depend
on bit patterns.  It is the same value whether you are 2-complement,
1-complement, signed magnitude, roman numeral, etc.  An even simpler
question: how do you represent -1 or -257?

Maybe using an schar and a uchar in the representation is not the
solution.  How about

typedef struct{
     bool sign;
     uchar high;
     uchar low;} my_int;

Now you can represent every arithmetic value from -(2^16-1) to
(2^16-1).  And you get to decide if the structure with (1,0,0)
represents -0, -(2^16), or 2^16.

You can also establish the convention that given a negative schar and
any uchar, the actual value represented is -((|schar|-1)*2^8+uchar).
This answers the above questions:  (-1,1) is -1; -5 is represented as
(-1,5); and -257 is represented as (-2,1).  And (-1,0) represents
whatever convention you establish.

And since initializing a negative value using normal C declaration
syntax would be a pain, you create a function 
   my_int set_my_int(schar, uchar);
to compute the three values needed and use it in a declaration or
statement with
   my_int x = set_my_int(-2,1);
or
   y = set_my_int(1,7);

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#107331

On 3/28/2017 8:26 AM, acidlategamer@gmail.com wrote:
> Hi all,
>
> Today a friend of mine asked this to me
> create a 128 bit type and you are given two 64 bit int type. One is sint64_t and one is uint64_t
>
> I said I can create it like this,
>
> struct int128_t{
>                    sint64_t sint;
>                    uint64_t uint;
> }a, b;
> now he said to compare two such types in this function
> a == b, return 0
> a > b, return 1
> a < b return -1
>
> I could not think of how to do it, because I couldn't think how negative numbers How will I do it
> a.sint = -21;
> a.unit = 245;
> In this case resulting number will be a 128 bit number combined, but what the number will be is not easy to deduce. So I gave up thinking.
>
> Anyone can think of any way?
>

Fwiw, check this out:

https://groups.google.com/d/topic/comp.lang.asm.x86/FScbTaQEYLc/discussion

Atomic 63 bit counter!  ;^)

[toc] | [prev] | [next] | [standalone]

#107348

On Tuesday, March 28, 2017 at 11:27:01 AM UTC-4, acidla...@gmail.com wrote:
> Hi all,
> 
> Today a friend of mine asked this to me
> create a 128 bit type and you are given two 64 bit int type. One is sint64_t and one is uint64_t
> 
> I said I can create it like this,
> 
> struct int128_t{
>                    sint64_t sint;
>                    uint64_t uint;
> }a, b;
> now he said to compare two such types in this function
> a == b, return 0
> a > b, return 1
> a < b return -1
> 
> I could not think of how to do it, because I couldn't think how negative numbers How will I do it
> a.sint = -21;   
> a.unit = 245;
> In this case resulting number will be a 128 bit number combined, but what the number will be is not easy to deduce. So I gave up thinking.
> 
> Anyone can think of any way?

There's a quad-double hardware library that uses the FPU with 256 bits
of precision, including a mantissa that exceeds 128 bits, meaning you
could use it for both floating point and integer operations.

    Double-double, and Quad-double:
    http://crd-legacy.lbl.gov/~dhbailey/mpdist/

    Direct link:
    http://crd.lbl.gov/~dhbailey/mpdist/qd-2.3.17.tar.gz

It's C++, but you can create a thin wrapper for it if you can't use
a C++ compiler and link in your C code.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#107473

On Tuesday, March 28, 2017 at 12:27:01 PM UTC-3, acidla...@gmail.com wrote:
> Hi all,
> 
> Today a friend of mine asked this to me
> create a 128 bit type and you are given two 64 bit int type. One is sint64_t and one is uint64_t


Once I did some functions to work with variable number of bits.
It's is C++ but can be easily adapted to C. 

http://thradams.com/mathlib.htm

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web