C90 long long

[Bartc]

From an article about implementing a C99 to C90 translator...

How does someone use integer arithmetic of at least 64 bits, and write in
pure C90?

As I understand C90 (the standard is very elusive), long int is guaranteed
to be at least 32 bits only.

So, do people rely on their known compiler limits, use clunky emulations, or
do not bother with 64 bits when writing ultra-portable code?

--
Bart

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: C90 long long

On Sun, 06 Apr 2008 15:37:28 +0000, Bartc wrote:

From an article about implementing a C99 to C90 translator...
>
How does someone use integer arithmetic of at least 64 bits, and write
in pure C90?
>
As I understand C90 (the standard is very elusive), long int is
guaranteed to be at least 32 bits only.

Correct. And as long int is the widest type, C90 does not guarantee the
presence of any 64-bit integer type.

So, do people rely on their known compiler limits, use clunky
emulations, or do not bother with 64 bits when writing ultra-portable
code?

People do whatever works best for their situation. Sometimes, that may
involve redefining the problem to fit 32-bit arithmetic (or floating-
point). Sometimes, that may be to rely on long being 64 bits. Sometimes,
that may be to use implementation extensions. In any case, it's very much
the same as how C90 programs have to deal with complex arithmetic. The
language and library don't provide any possibility, so portable programs
have no choice but to implement it themselves.

[Barry Schwarz]

Re: C90 long long

On Sun, 06 Apr 2008 15:37:28 GMT, "Bartc" <bc@freeuk.comw rote:

>From an article about implementing a C99 to C90 translator...
>
>How does someone use integer arithmetic of at least 64 bits, and write in
>pure C90?
>
>As I understand C90 (the standard is very elusive), long int is guaranteed
>to be at least 32 bits only.
>
>So, do people rely on their known compiler limits, use clunky emulations, or
>do not bother with 64 bits when writing ultra-portable code?

Many use a "big number library" that simulates arithmetic on very wide
integers. I think Richard Heathfield put one on the web and google
can probably find you others.


Remove del for email

[jacob navia]

Re: C90 long long

Barry Schwarz wrote:

On Sun, 06 Apr 2008 15:37:28 GMT, "Bartc" <bc@freeuk.comw rote:
>

>>From an article about implementing a C99 to C90 translator...
>How does someone use integer arithmetic of at least 64 bits, and write in
>pure C90?
>>
>As I understand C90 (the standard is very elusive), long int is guaranteed
>to be at least 32 bits only.
>>
>So, do people rely on their known compiler limits, use clunky emulations, or
>do not bother with 64 bits when writing ultra-portable code?

>
Many use a "big number library" that simulates arithmetic on very wide
integers. I think Richard Heathfield put one on the web and google
can probably find you others.
>
>
Remove del for email

That GUARANTEES that the software will run VERY slowly using
ALL the CPU for nothing. Heathfield's big numbers use characters
as the base representation.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

Re: C90 long long

Barry Schwarz said:

<snip>

Many use a "big number library" that simulates arithmetic on very wide
integers.

Right.

I think Richard Heathfield put one on the web

Actually, no, I haven't. I've got one, but I haven't published it.

As Mr Navia notes elsethread, it uses an array of unsigned char to store
the data. He seems to think that this "GUARANTEES that the software will
run VERY slowly using ALL the CPU for nothing". It doesn't, of course.
Nevertheless, performance was not my highest priority. Those who want a
super-fast bignum library would be well advised to use GMP or Miracl.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Re: C90 long long

jacob navia <jacob@nospam.c omwrites:

Bartc wrote:

>From an article about implementing a C99 to C90 translator...
>>

>
Interesting interesting.
>
And when you are going to do a C89 to K&R translator?

It's been done; google "ansi2knr". Though as I recall it's not a
complete translator; mostly it converts prototypes to old-style
function declarations.

The point, of course, is that a C89 to K&R translator, though it was
quite useful years ago, is no longer of much interest today, since the
C89 standard is almost universally supported (it would be difficult to
find a platform that has a K&R compiler but no C89 compiler). This is
not yet the case for C99, a fact that you insist on ignoring, even
though your own lcc-win doesn't support the full language.

A C99 compiler that uses C89 as its intermediate language might be a
very useful thing. If it managed to generate portable C89 code, it
could even permit the use of C99 on platforms where no C99 compiler
yet exists (something I would think you'd welcome).

I suspect that modifying an existing C89 compiler to handle C99 would
be easier than writing a complete translator (but the latter would
potentially only have to be done once for all target platforms).

How does someone use integer arithmetic of at least 64 bits, and
write in pure C90?

>
There is no 64 bit arithmetic in C89. And you will have to do it
yourself!

Yes, that's probably one of the more difficult aspects of translating
C99 to C89. A quibble, though: C89 has no *guaranteed* 64-bit
arithmetic; it's perfectly legal to make long 64 bits.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Re: C90 long long

Richard Heathfield wrote:

Barry Schwarz said:
>
<snip>
>

>Many use a "big number library" that simulates arithmetic on very wide
>integers.

>
Right.
>

>I think Richard Heathfield put one on the web

>
Actually, no, I haven't. I've got one, but I haven't published it.
>
As Mr Navia notes elsethread, it uses an array of unsigned char to store
the data. He seems to think that this "GUARANTEES that the software will
run VERY slowly using ALL the CPU for nothing". It doesn't, of course.
Nevertheless, performance was not my highest priority. Those who want a
super-fast bignum library would be well advised to use GMP or Miracl.
>

Using a char to store bignum data is like using a scooter to
move a 38 ton trailer.

It will work of course, and the 38 ton trailer will have a cruising
speed of several centimeters/hour...

Who cares?

That solution is PORTABLE. You can carry a scooter anywhere, they
are standard solutions, etc.


Portability means very often that you make mediocre software
that runs anywhere because it never uses the hardware/OS to
its maximum possibilities but just uses the least common
denominator of each one.

This is fine if you do not care about usability or similar problems.
GUIs?

Not portable. The command line is portable. Use the command line

Network?
Not portable...

Etc.

But this is more a philosophical question. Heathfield's viewpoint
is perfectly acceptable if you say:

Usability is less valuable than portability.
As he said, performance wasn't a concern for his software.
Portability was.

Result?

A mediocre but perfectly portable software.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Richard]

Re: C90 long long

jacob navia <jacob@nospam.c omwrites:

Richard Heathfield wrote:

>Barry Schwarz said:
>>
><snip>
>>

>>Many use a "big number library" that simulates arithmetic on very wide
>>integers.

>>
>Right.
>>

>>I think Richard Heathfield put one on the web

>>
>Actually, no, I haven't. I've got one, but I haven't published it.
>>
>As Mr Navia notes elsethread, it uses an array of unsigned char to
>store the data. He seems to think that this "GUARANTEES that the
>software will run VERY slowly using ALL the CPU for nothing". It
>doesn't, of course. Nevertheless, performance was not my highest
>priority. Those who want a super-fast bignum library would be well
>advised to use GMP or Miracl.
>>

>
Using a char to store bignum data is like using a scooter to
move a 38 ton trailer.
>
It will work of course, and the 38 ton trailer will have a cruising
speed of several centimeters/hour...
>
Who cares?
>
That solution is PORTABLE. You can carry a scooter anywhere, they
are standard solutions, etc.
>
>
Portability means very often that you make mediocre software
that runs anywhere because it never uses the hardware/OS to
its maximum possibilities but just uses the least common
denominator of each one.
>
This is fine if you do not care about usability or similar problems.
GUIs?
>
Not portable. The command line is portable. Use the command line
>
Network?
Not portable...
>
Etc.
>
But this is more a philosophical question. Heathfield's viewpoint
is perfectly acceptable if you say:
>
Usability is less valuable than portability.
As he said, performance wasn't a concern for his software.
Portability was.
>
Result?
>
A mediocre but perfectly portable software.

And guess what? Most of the blowhards in this group write SW which never
gets ported anywhere anyway.

[Morris Dovey]

Re: C90 long long

Richard wrote:

And guess what? Most of the blowhards in this group write SW which never
gets ported anywhere anyway.

Umm - before you make a statement like that you might want to
check with some of those blowhards who make some of their C
source code available for free download...

....and on the other hand, you might prefer to not know.

;-)

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA

http://www.iedu.com/DeSoto/

[Bartc]

Re: C90 long long


"Bartc" <bc@freeuk.comw rote in message
news:Y66Kj.3256 $yD2.2536@text. news.virginmedi a.com...

From an article about implementing a C99 to C90 translator...
>
How does someone use integer arithmetic of at least 64 bits, and write in
pure C90?
>
As I understand C90 (the standard is very elusive), long int is guaranteed
to be at least 32 bits only.
>
So, do people rely on their known compiler limits, use clunky emulations,
or do not bother with 64 bits when writing ultra-portable code?

OK, so for this to be practical, such a translator needs to know the
capabilities of a C90 installation. If it has 64+ bit ints, then use them,
otherwise make other arrangements. A pure translator would be of academic
interest only.

Attend to 1000 other details and such a translator may be feasible.

(Note: I am not creating such a software, just interested in the issues.)

--
Bart

[Keith Thompson]

Re: C90 long long

jacob navia <jacob@nospam.c omwrites:

Bartc wrote:

>OK, so for this to be practical, such a translator needs to know the
>capabilities of a C90 installation. If it has 64+ bit ints, then use
>them, otherwise make other arrangements. A pure translator would be
>of academic interest only.
>>
>Attend to 1000 other details and such a translator may be feasible.
>>
>(Note: I am not creating such a software, just interested in the issues.)
>>

>
>
The bad news is that you will need:
>
o alloca() for implementing VLA arrays.

[snip]

No, the usual behavior of alloca() (space is deallocated on return
from the calling function) is incompatible with the requirements for
VLAs. For example, given this:

for (int i = 1; i <= 1000; i ++) {
int vla[i];
// ...
}

an alloca-based implementation would allocate space for all 1000
instances of ``vla'' before deallocating any of them. I suppose you
could argue that the standard doesn't actually require that the
storage be physically deallocated on leaving the object's scope, but
it would be a seriously flawed implementation.

If you have an alloca()-like function that frees the storage on exit
from the scope, then that's not a problem (though it wouldn't satisfy
the usual, somewhat informal, requirements for alloca()).

(Didn't we discuss this just recently?)

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Re: C90 long long

Flash Gordon said:

<snip>

Richard has on more than one occasion explicitly recommended using other
bignum libraries if you want one with high performance.

Right. In fact, I explicitly recommend using other bignum libraries even if
you *don't* care about performance, because *my* bignum library is not
generally available, so you can't use it even if you want to.

He even provided
such recommendations in the post you responded to.

Right.

[A troll said]

>And guess what? Most of the blowhards in this group write SW which never
>gets ported anywhere anyway.

>
Where is your proof that people have been lying when they have been
talking about the porting of their SW that occurs in real life?

You're arguing with a troll, remember. They don't need proof. They don't
even need evidence. They just need a good supply of mud.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Re: C90 long long

jacob navia said:

Richard Heathfield wrote:

>Barry Schwarz said:
>>
><snip>
>>

>>Many use a "big number library" that simulates arithmetic on very wide
>>integers.

>>
>Right.
>>

>>I think Richard Heathfield put one on the web

>>
>Actually, no, I haven't. I've got one, but I haven't published it.
>>
>As Mr Navia notes elsethread, it uses an array of unsigned char to store
>the data. He seems to think that this "GUARANTEES that the software will
>run VERY slowly using ALL the CPU for nothing". It doesn't, of course.
>Nevertheless , performance was not my highest priority. Those who want a
>super-fast bignum library would be well advised to use GMP or Miracl.
>>

>
Using a char to store bignum data is like using a scooter to
move a 38 ton trailer.

If you say so. In my experience, the performance is perfectly acceptable in
those situations where I need bignums - and, if ever the performance
*isn't* acceptable to me, there are other options available to me, such as
the ones I mentioned in my earlier article.

It will work of course, and the 38 ton trailer will have a cruising
speed of several centimeters/hour...

Fine, if you say so - but that's *my* problem, right? Nobody else's. I'm
not advocating that anyone else should use this software. For the record,
however, yes, my bignum library is significantly slower than GMP (it takes
about 20 times as long as GMP to calculate factorials, for instance). So
what?

Who cares?
>
That solution is PORTABLE. You can carry a scooter anywhere, they
are standard solutions, etc.

That's a large part of it, yes. Licensing is another issue.

Portability means very often that you make mediocre software
that runs anywhere because it never uses the hardware/OS to
its maximum possibilities but just uses the least common
denominator of each one.

That's one way to do portability (although the result need *not* be
mediocre - the fact that it usually *is* mediocre says a lot more about
programmers than it does about portability). Another way is to recognise
the reality that some code is portable and some isn't, and generally the
parts that are portable can easily be isolated from those that aren't.

This is fine if you do not care about usability or similar problems.

If I thought you were genuinely interested in learning how to solve these
problems, I would continue to explain.

But this is more a philosophical question. Heathfield's viewpoint
is perfectly acceptable if you say:
>
Usability is less valuable than portability.

If it won't port to the user's system, how can it be called usable? Duh.

As he said, performance wasn't a concern for his software.

I said no such thing. In the very article to which you replied, I said:
"Neverthele ss, performance was not my highest priority." There is a major
semantic difference between "is not the highest priority" and "is not a
concern". You often misinterpret people (especially me) in this way. That
is either deliberate or accidental. If it is deliberate, then you are
trolling. If it is accidental, then you need to learn to read for
comprehension before trying to argue with those who can already do so.

Portability was.
>
Result?
>
A mediocre but perfectly portable software.

Please explain how a program that *doesn't work* on the target platform is
superior to one that does.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bartc]

Re: C90 long long

Richard Heathfield wrote:

jacob navia said:

[big num stuff]

>It will work of course, and the 38 ton trailer will have a cruising
>speed of several centimeters/hour...

>
Fine, if you say so - but that's *my* problem, right? Nobody else's.
I'm not advocating that anyone else should use this software. For the
record, however, yes, my bignum library is significantly slower than
GMP (it takes about 20 times as long as GMP to calculate factorials,
for instance). So what?

How long does it take to calculate 5^(4^(3^(2^1))) ? (Ie. raising to the
power.)

This came up in comp.programmin g a few weeks back. I knocked up a quick
library that used byte arrays and stored a single decimal digit in each
byte. And that was in interpreted code! (Only add unsigned and multiply by
single digit were compiled.)

This took some 15 minutes to calculate the 183000-digit result (on a slowish
Pentium cpu).

Just interested in how much extra work is needed...

--
Bart

[jacob navia]

Re: C90 long long

Bartc wrote:

Richard Heathfield wrote:

>jacob navia said:

>
[big num stuff]
>

>>It will work of course, and the 38 ton trailer will have a cruising
>>speed of several centimeters/hour...

>Fine, if you say so - but that's *my* problem, right? Nobody else's.
>I'm not advocating that anyone else should use this software. For the
>record, however, yes, my bignum library is significantly slower than
>GMP (it takes about 20 times as long as GMP to calculate factorials,
>for instance). So what?

>
How long does it take to calculate 5^(4^(3^(2^1))) ? (Ie. raising to the
power.)
>
This came up in comp.programmin g a few weeks back. I knocked up a quick
library that used byte arrays and stored a single decimal digit in each
byte. And that was in interpreted code! (Only add unsigned and multiply by
single digit were compiled.)
>
This took some 15 minutes to calculate the 183000-digit result (on a slowish
Pentium cpu).
>
Just interested in how much extra work is needed...
>

The french package "pari" calculates that in around 0.5 seconds
(In a dual core amd)

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32