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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#107451

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

>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>>*Mostly that's independent of the internal format of the type - if you
>>define your 18 decimal digit field as having a binary format, you'll
>>get a 64-bit format on most machines.  Or if you specify a BCD-ish
>>format, you'll usually get 9 or 10 bytes, depending on the
>>implementation and whether or not the field is signed.
>
>If you use this architecture <http://vseries.lurndal.org/doku.php>,
>you'll find support for 100 digit decimal fields built-in (including
>addressing to the digit/nibble) (and no concept of word size).


Yes, which I why I said "most" and "usually".  IBM's 1401 considerably
pre-dates the rubs-rough medium systems, and had some similar features
(and also had a Cobol compiler).  The Burroughs systems have the
advantage of having existed (outside of emulation and museums) much
more recently than 1401s.

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

#107488

Robert Wessel <robertwessel2@yahoo.com> writes:
>On Wed, 29 Mar 2017 13:13:22 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>>*Mostly that's independent of the internal format of the type - if you
>>>define your 18 decimal digit field as having a binary format, you'll
>>>get a 64-bit format on most machines.  Or if you specify a BCD-ish
>>>format, you'll usually get 9 or 10 bytes, depending on the
>>>implementation and whether or not the field is signed.
>>
>>If you use this architecture <http://vseries.lurndal.org/doku.php>,
>>you'll find support for 100 digit decimal fields built-in (including
>>addressing to the digit/nibble) (and no concept of word size).
>
>
>Yes, which I why I said "most" and "usually".  IBM's 1401 considerably
>pre-dates the rubs-rough medium systems, and had some similar features
>(and also had a Cobol compiler).  The Burroughs systems have the
>advantage of having existed (outside of emulation and museums) much
>more recently than 1401s.

Actually the 1401 was first shipped in 1960, while the Electrodata
220 (the predecessor to the Burroughs B200 (1961) and Burroughs B2500 (1967))
was already shipping (and the 202 had been shipping for 6 years at
that point).  The're all BCD machines.

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

#107503

On Thu, 30 Mar 2017 13:36:30 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>>On Wed, 29 Mar 2017 13:13:22 GMT, scott@slp53.sl.home (Scott Lurndal)
>>wrote:
>>
>>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>>
>>>>*Mostly that's independent of the internal format of the type - if you
>>>>define your 18 decimal digit field as having a binary format, you'll
>>>>get a 64-bit format on most machines.  Or if you specify a BCD-ish
>>>>format, you'll usually get 9 or 10 bytes, depending on the
>>>>implementation and whether or not the field is signed.
>>>
>>>If you use this architecture <http://vseries.lurndal.org/doku.php>,
>>>you'll find support for 100 digit decimal fields built-in (including
>>>addressing to the digit/nibble) (and no concept of word size).
>>
>>
>>Yes, which I why I said "most" and "usually".  IBM's 1401 considerably
>>pre-dates the rubs-rough medium systems, and had some similar features
>>(and also had a Cobol compiler).  The Burroughs systems have the
>>advantage of having existed (outside of emulation and museums) much
>>more recently than 1401s.
>
>Actually the 1401 was first shipped in 1960, while the Electrodata
>220 (the predecessor to the Burroughs B200 (1961) and Burroughs B2500 (1967))
>was already shipping (and the 202 had been shipping for 6 years at
>that point).  The're all BCD machines.


While I can't speak to the Electrodata 220, the Burroughs B200 did not
support the ~100 digit decimal fields that the later Burroughs 2500
systems did.  The B200 coded the length of both fields in arithmetic
instructions as 1-12 digits.

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

#107504

Robert Wessel <robertwessel2@yahoo.com> writes:
>On Thu, 30 Mar 2017 13:36:30 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>>On Wed, 29 Mar 2017 13:13:22 GMT, scott@slp53.sl.home (Scott Lurndal)
>>>wrote:
>>>
>>>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>>>
>>>>>*Mostly that's independent of the internal format of the type - if you
>>>>>define your 18 decimal digit field as having a binary format, you'll
>>>>>get a 64-bit format on most machines.  Or if you specify a BCD-ish
>>>>>format, you'll usually get 9 or 10 bytes, depending on the
>>>>>implementation and whether or not the field is signed.
>>>>
>>>>If you use this architecture <http://vseries.lurndal.org/doku.php>,
>>>>you'll find support for 100 digit decimal fields built-in (including
>>>>addressing to the digit/nibble) (and no concept of word size).
>>>
>>>
>>>Yes, which I why I said "most" and "usually".  IBM's 1401 considerably
>>>pre-dates the rubs-rough medium systems, and had some similar features
>>>(and also had a Cobol compiler).  The Burroughs systems have the
>>>advantage of having existed (outside of emulation and museums) much
>>>more recently than 1401s.
>>
>>Actually the 1401 was first shipped in 1960, while the Electrodata
>>220 (the predecessor to the Burroughs B200 (1961) and Burroughs B2500 (1967))
>>was already shipping (and the 202 had been shipping for 6 years at
>>that point).  The're all BCD machines.
>
>
>While I can't speak to the Electrodata 220, the Burroughs B200 did not
>support the ~100 digit decimal fields that the later Burroughs 2500
>systems did.  The B200 coded the length of both fields in arithmetic
>instructions as 1-12 digits.

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

#107507

Robert Wessel <robertwessel2@yahoo.com> writes:
>On Thu, 30 Mar 2017 13:36:30 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>Robert Wessel <robertwessel2@yahoo.com> writes:

>>>
>>>Yes, which I why I said "most" and "usually".  IBM's 1401 considerably
>>>pre-dates the rubs-rough medium systems, and had some similar features
>>>(and also had a Cobol compiler).  The Burroughs systems have the
>>>advantage of having existed (outside of emulation and museums) much
>>>more recently than 1401s.
>>
>>Actually the 1401 was first shipped in 1960, while the Electrodata
>>220 (the predecessor to the Burroughs B200 (1961) and Burroughs B2500 (1967))
>>was already shipping (and the 202 had been shipping for 6 years at
>>that point).  The're all BCD machines.
>
>
>While I can't speak to the Electrodata 220, the Burroughs B200 did not
>support the ~100 digit decimal fields that the later Burroughs 2500
>systems did.

I don't believe that I claimed such, above, only that there was
a predecessor of the B2500 contemporaneously with the 1401.

FWIW, the penultimate member of the medium systems, the B4955,
is up and running at the LCC.

And, I'm not familiar with the phrase 'rubs-rough' - what does
that conote with respect to medium systems?

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

#107553

On Thu, 30 Mar 2017 17:59:49 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>>On Thu, 30 Mar 2017 13:36:30 GMT, scott@slp53.sl.home (Scott Lurndal)
>>wrote:
>>
>>>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>>>>
>>>>Yes, which I why I said "most" and "usually".  IBM's 1401 considerably
>>>>pre-dates the rubs-rough medium systems, and had some similar features
>>>>(and also had a Cobol compiler).  The Burroughs systems have the
>>>>advantage of having existed (outside of emulation and museums) much
>>>>more recently than 1401s.
>>>
>>>Actually the 1401 was first shipped in 1960, while the Electrodata
>>>220 (the predecessor to the Burroughs B200 (1961) and Burroughs B2500 (1967))
>>>was already shipping (and the 202 had been shipping for 6 years at
>>>that point).  The're all BCD machines.
>>
>>
>>While I can't speak to the Electrodata 220, the Burroughs B200 did not
>>support the ~100 digit decimal fields that the later Burroughs 2500
>>systems did.
>
>I don't believe that I claimed such, above, only that there was
>a predecessor of the B2500 contemporaneously with the 1401.


While the B200 was a predecessor, it is not usually considered one of
the Burroughs "Medium" systems, and those are the ones with the
100-digit decimal arithmetic support.


>FWIW, the penultimate member of the medium systems, the B4955,
>is up and running at the LCC.
>
>And, I'm not familiar with the phrase 'rubs-rough' - what does
>that conote with respect to medium systems?


It's an affectionate anagram of Burroughs.  Is the problem that I'm
old enough to actually remember that?   :-(

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

#107668

Robert Wessel <robertwessel2@yahoo.com> writes:

>>FWIW, the penultimate member of the medium systems, the B4955,
>>is up and running at the LCC.
>>
>>And, I'm not familiar with the phrase 'rubs-rough' - what does
>>that conote with respect to medium systems?
>
>
>It's an affectionate anagram of Burroughs.  Is the problem that I'm
>old enough to actually remember that?   :-(

Hmm.  I spent 14 years at Burroughs, seven in the Medium Systems MCP group,
and I don't recall ever hearing that one.

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

#107704

On Mon, 03 Apr 2017 13:37:48 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>>>FWIW, the penultimate member of the medium systems, the B4955,
>>>is up and running at the LCC.
>>>
>>>And, I'm not familiar with the phrase 'rubs-rough' - what does
>>>that conote with respect to medium systems?
>>
>>
>>It's an affectionate anagram of Burroughs.  Is the problem that I'm
>>old enough to actually remember that?   :-(
>
>Hmm.  I spent 14 years at Burroughs, seven in the Medium Systems MCP group,
>and I don't recall ever hearing that one.


Hmmm.  It may have been regional (US? Midwest? Chicago?), but it was a
reasonably well know nickname for us, not that we used it that often,
most of the crowd I hung around with was IBM.  I'm pretty sure I even
saw it in print at least a couple of times, probably in Computerworld
or Datamation or some-such.

I remember the first time I was talking to some (IBM) mainframe users
in Europe, and they were telling us something about their experience
with "kicks"?  Eh?  What now?  For whatever reason, it's almost
universal to call CICS that outside the US, and almost universal to
call it cee-eye-cee-ess in the US.

Also, we didn't generally use the many less-than-respectful nicknames
for IBM in front of IBMers either, so you may have been sheltered on
that front.

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

#107707

On Mon, 03 Apr 2017 17:38:43 -0500, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Mon, 03 Apr 2017 13:37:48 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>>>FWIW, the penultimate member of the medium systems, the B4955,
>>>>is up and running at the LCC.
>>>>
>>>>And, I'm not familiar with the phrase 'rubs-rough' - what does
>>>>that conote with respect to medium systems?
>>>
>>>
>>>It's an affectionate anagram of Burroughs.  Is the problem that I'm
>>>old enough to actually remember that?   :-(
>>
>>Hmm.  I spent 14 years at Burroughs, seven in the Medium Systems MCP group,
>>and I don't recall ever hearing that one.
>
>
>Hmmm.  It may have been regional (US? Midwest? Chicago?), but it was a
>reasonably well know nickname for us, not that we used it that often,
>most of the crowd I hung around with was IBM.  I'm pretty sure I even
>saw it in print at least a couple of times, probably in Computerworld
>or Datamation or some-such.
>
>I remember the first time I was talking to some (IBM) mainframe users
>in Europe, and they were telling us something about their experience
>with "kicks"?  Eh?  What now?  For whatever reason, it's almost
>universal to call CICS that outside the US, and almost universal to
>call it cee-eye-cee-ess in the US.
>
>Also, we didn't generally use the many less-than-respectful nicknames
>for IBM in front of IBMers either, so you may have been sheltered on
>that front.


And I found at least one reference on the 'net:

https://issuu.com/maddrake/docs/expert_c_programming_deep_c_secrets/222

So I'm not imagining it.

And does that link restore topicality?

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

#107711

Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> And I found at least one reference on the 'net:
>
> https://[DELETED]/expert_c_programming_deep_c_secrets/222
>
> So I'm not imagining it.
>
> And does that link restore topicality?

That link appears to be to a pirated copy of Peter Van Der Linden's book
"Expert C Programming, Deep C Secrets".  I have a paper copy of the same
book, and I'm fairly sure it includes a copyright notice, which was
omitted from this online copy.  I'm not aware of a legitimate free
electronic version.  (It's available as a Kindle e-book for $19.24.)

-- 
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]

#107713

On Mon, 03 Apr 2017 17:43:40 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>[...]
>> And I found at least one reference on the 'net:
>>
>> https://[DELETED]/expert_c_programming_deep_c_secrets/222
>>
>> So I'm not imagining it.
>>
>> And does that link restore topicality?
>
>That link appears to be to a pirated copy of Peter Van Der Linden's book
>"Expert C Programming, Deep C Secrets".  I have a paper copy of the same
>book, and I'm fairly sure it includes a copyright notice, which was
>omitted from this online copy.  I'm not aware of a legitimate free
>electronic version.  (It's available as a Kindle e-book for $19.24.)


Well, that's embarrassing.  I only looked at the one page with the
quote I found with a search.

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

#107724

On 03/04/17 23:38, Robert Wessel wrote:
<snip>
>
> I remember the first time I was talking to some (IBM) mainframe users
> in Europe, and they were telling us something about their experience
> with "kicks"?  Eh?  What now?  For whatever reason, it's almost
> universal to call CICS that outside the US, and almost universal to
> call it cee-eye-cee-ess in the US.

Concur. I never heard it pronounced in any other way than "kicks" by 
British programmers, but US programmers (and you do occasionally get 
them in Rightpondia) invariably pronounced each letter separately.

> Also, we didn't generally use the many less-than-respectful nicknames
> for IBM in front of IBMers either, so you may have been sheltered on
> that front.

In Rightpondia at least, employees of Andersen Consulting were often 
called "androids". Whether it was because Andersen could identify and 
reject people with personalities at the hiring stage, or whether their 
employees just hid those personalities very, very carefully, I don't 
know, but "android" was a common term of art. Or "droid" for short. 
(Star Wars related nicknames were not particularly unusual at the time.) 
They are typically of medium height, medium weight, medium build, and... 
well, they're just generally medium, and about as colourful as a 
pavement (sidewalk).

In the late 1990s, I was working at MumbleCo, alongside a few MumbleCo 
employees, several other independent contractors, and a whole bunch of 
"droids". I should point out here that I'm rather taller than average, 
and also that I have never been a great fan of the barber, as a result 
of which I had acquired my own SW nickname.

One day, there was a technical disagreement between myself and one of 
the Andersen people, which was resolved in my favour by the project 
manager. The Andersen chap complained that this was always the way these 
arguments seemed to go.

One of my fellow indies immediately responded with: "That's because 
droids don't rip people's arms out when they lose. Wookies have been 
known to do that."

-- 
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]

#107295

Le 28/03/2017 à 20:11, Scott Lurndal a écrit :

>>
>> 128 bit integers are not a gcc extension. Lcc-win has that too.
>
> Ok.  They're a gcc extension that has been adopted by icc, pgi,
> clang and lcc-win.
>

Yes, and I think that the last entry of that list is important.

You wonder why?

Because it is a good implementation, nicely wown into the language.

And those compilers in the list, by the way, took 128 bit integers from 
the hardware. A 64 bit hardware can do easily 128 bit arithmetic. Much 
more easily than 32 bit hardware, you did not notice?

128 bit types became feasible with 64 bit OS and software. Gcc 
implemented that, I haven't looked into their software. I ported the 64 
bit software to 128 from my implementation of long long in lcc-win 32 
bits. The same code, running in registers twice as wide and with a 128 
bit operation of mult, and div become feasible in x86 asm software.

Gcc implemented that first?

Maybe, I did not follow the history of that to /that/ level of detail.

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

#107333

On Tue, 28 Mar 2017 20:28:22 +0200, jacobnavia
<jacob@jacob.remcomp.fr> wrote:

>Le 28/03/2017 à 20:11, Scott Lurndal a écrit :
>
>>>
>>> 128 bit integers are not a gcc extension. Lcc-win has that too.
>>
>> Ok.  They're a gcc extension that has been adopted by icc, pgi,
>> clang and lcc-win.
>>
>
>Yes, and I think that the last entry of that list is important.
>
>You wonder why?
>
>Because it is a good implementation, nicely wown into the language.
>
>And those compilers in the list, by the way, took 128 bit integers from 
>the hardware. A 64 bit hardware can do easily 128 bit arithmetic. Much 
>more easily than 32 bit hardware, you did not notice?


I have to disagree.  Other than division, both double and quad
precision integer operations are pretty trivial to implement.  Yes,
double precision is a bit easier, but not enough that it should bother
anyone.  Multiple precision division is a PITA no matter what,
especially if you'd like it to perform well.

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.  And to not pick on RISCs excessively, S/360 and its
descendents did have a carry as a resulting condition from the
unsigned add instruction (Add Logical - AL), but it isn't a
conventional carry flag, and there was no add-with-carry instruction
until fairly recently - so it was a right pain there too.  But the
difference between implementing double and quad precision is not that
big.


>128 bit types became feasible with 64 bit OS and software. Gcc 
>implemented that, I haven't looked into their software. I ported the 64 
>bit software to 128 from my implementation of long long in lcc-win 32 
>bits. The same code, running in registers twice as wide and with a 128 
>bit operation of mult, and div become feasible in x86 asm software.
>
>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.
Multiple precision integer arithmetic is far older than that, but I
suspect the early Cobol compilers were the first to build them into a
language in some fashion, although I would not be surprised if
something like FLOW-MATIC did it earlier.

I am curious, however: I believe you have both a 32-bit and 64-bit
compiler for x86, do you implement the 128 bit type for both?  Same
question for the ARM port(s) I believe your working on.

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

#107334

Le 28/03/2017 à 23:37, Robert Wessel a écrit :
> I am curious, however: I believe you have both a 32-bit and 64-bit
> compiler for x86, do you implement the 128 bit type for both?

I did a 32 bit hardware implementation of 128 bit arithmetic but it is 
very slow of course... I did not pursue that in 32 bits. For the same 
reasons that I do not implement 256 bit integers with 64 bit software.


Same
> question for the ARM port(s) I believe your working on.

ARM64 has no 128 bit mult/div. It has UMULH/SMULH, that returns the high 
word of the multiplication though, so it is quite feasible. But I have 
only managed to compile the source of the lcc compiler with itself 
yesterday. It is a big work. 128 bit math can wait for a while

:-)

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

#107344

On Tue, 28 Mar 2017 23:56:32 +0200, jacobnavia
<jacob@jacob.remcomp.fr> wrote:

>Le 28/03/2017 à 23:37, Robert Wessel a écrit :
>> I am curious, however: I believe you have both a 32-bit and 64-bit
>> compiler for x86, do you implement the 128 bit type for both?
>
>I did a 32 bit hardware implementation of 128 bit arithmetic but it is 
>very slow of course... I did not pursue that in 32 bits. For the same 
>reasons that I do not implement 256 bit integers with 64 bit software.


I would generally expect that, relative to a double implementation, a
quad implementation to do twice the amount of work for things like
addition, and four times for multiplication or division.  Things like
base conversions (strtoX/printf) would fall somewhere between those
limits.  That hardly seems objectionable give the increase in the
sizes.

But the utility of those would be high, at least for some
applications, and doubtless built-in support would be faster than
having to implement it via a bignum-like library.


>
>Same
>> question for the ARM port(s) I believe your working on.
>
>ARM64 has no 128 bit mult/div. It has UMULH/SMULH, that returns the high 
>word of the multiplication though, so it is quite feasible. But I have 
>only managed to compile the source of the lcc compiler with itself 
>yesterday. It is a big work. 128 bit math can wait for a while


Are you only doing an ARM64 port?

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

#107346

Le 29/03/2017 à 01:36, Robert Wessel a écrit :
> Are you only doing an ARM64 port?

Yes, of course, and that leaves no room for doing anything else for the 
time being. I was very happy I could compile the compiler with itself 
and generate a running executable... 75 kloc, quite a big deal for the 
code generator... And it worked.

Now I am turning the optimizer on (register variables) what dramatically 
improves the naive code. But is more tricky, but produces code that is 
8645 times faster in a 64 bit arithmetic benchmark.

In the matrix multiplication benchmark, I am getting quite a speed 
boost, arriving at 56 seconds with gcc -O2 arriving at 45.

But it is not working yet for all programs, there are quite a few 
problems to solve before I get high quality code.

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

#107548 — Re: English grammar, nonrestrictive clause

On 29/03/2017 01:43, jacobnavia wrote:

> I am turning the optimizer on, what improves the naive code.

***which*** improves ...

http://www.quickanddirtytips.com/education/grammar/which-versus-that-0

"what" is NEVER correct in that situation, except in
the *informal* idiom "what with".

https://dictionary.cambridge.org/dictionary/english/what-with

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

#107551 — Re: English grammar, nonrestrictive clause

Le 31/03/2017 à 21:24, Noob a écrit :
> On 29/03/2017 01:43, jacobnavia wrote:
>
>> I am turning the optimizer on, what improves the naive code.
>
> ***which*** improves ...
>

Thanks, I wasn't aware of that.

> http://www.quickanddirtytips.com/education/grammar/which-versus-that-0
>
> "what" is NEVER correct in that situation, except in
> the *informal* idiom "what with".
>
> https://dictionary.cambridge.org/dictionary/english/what-with
>

Good explanations. I should use which when the information can be left 
out without changing the meaning of the sentence.

I am turning the optimizer on

the rest can be left out, "which" is necessary, not that.

Thanks again.

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

#107577 — Re: English grammar, nonrestrictive clause

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 31/03/2017 à 21:24, Noob a écrit :
>> On 29/03/2017 01:43, jacobnavia wrote:
>>
>>> I am turning the optimizer on, what improves the naive code.
>>
>> ***which*** improves ...
>
> Thanks, I wasn't aware of that.

But it's a "good" error in that it has entered the language when used
for comic effect.  Look up "the play what I wrote" to find out more.

<snip>
-- 
Ben.

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

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

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

csiph-web