C / asm / long ints

[stevenj]

Myes. But are _much_ larger floating-point numbers really that much
faster than appropriately handled integers? Even if you don't have these
much larger FPs yet, and will have to emulate them? Don't get me wrong,
I see the value of the method, but I'm not so sure of its value to the
OP, who probably will have the same problems handling extended-precision
FPs that he has handling extended-size integers.

Apparently yes. Look at the source code of many major
arbitrary-precision arithmetic packages and you will see that they use
floating-point FFTs.

You typically just use double precision, which has a 53-bit
significand. The question is, how many integer bits do you pack into
each double-precision element? For an FFT up to size size 2^19 =
524288 or so, it is sufficient to use 12 bits per double if I remember
correctly (and this may be too conservative, as FFT roundoff errors
generally grow at most logarithmically with transform size).

Steven

 

[stevenj]

Don't get me wrong,
I see the value of the method, but I'm not so sure of its value to the
OP, who probably will have the same problems handling extended-precision
FPs that he has handling extended-size integers.

After going back and reading the original post, by the way, I'm not
sure anything can help the OP.

Remember, the OP was going to use the GMP library but he had problems
compiling it because "some header files were not found," so his
proposed solution was to rewrite GMP in assembly! Only he doesn't know
how to interface C and asm. We are not talking about a reasonable
person here.

Regards,
Steven G. Johnson

 

[Chris Thomasson]

Oh, are they?

Most of the time, they are. So, IMHO, I would define an ABI that does it
this way first...

If I designed my ABI to follow some other calling convention, then you, and
most other programmers could not use my library...

You can use it now because it sticks to the normal C calling convention for
most C compilers on the architectures I am targeting; why would I want to do
it another way?

 

[CBFalconer]

Most of the time, they are. So, IMHO, I would define an ABI that
does it this way first...

If I designed my ABI to follow some other calling convention,
then you, and most other programmers could not use my library...

You can use it now because it sticks to the normal C calling
convention for most C compilers on the architectures I am
targeting; why would I want to do it another way?

Sounds as if your 'libraries' are available only in binary form.
This is the antithesis of portability. The calling conventions are
the province of the compiler, not the library. If you must hide
your source, rather than depending on copyright, consider using
cloaked source.

 

[Jordan Abel]

Sounds as if your 'libraries' are available only in binary form.
This is the antithesis of portability. The calling conventions are
the province of the compiler, not the library. If you must hide
your source, rather than depending on copyright, consider using
cloaked source.

I believe we were talking in libraries written and maintained in
a language other than C, though, namely x86 assembly language. In that
case, you can't rely on the C compiler to recompile it to different
calling conventions even if you DO have the source.

 

[Chris Thomasson]

2006-11-02 <[email protected]>,
CBFalconer wrote:
[...]

I believe we were talking in libraries written and maintained in
a language other than C, though, namely x86 assembly language.
Yup.




In that case, you can't rely on the C compiler to recompile it to
different
calling conventions even if you DO have the source.

Indeed...

 

[CBFalconer]

2006-11-02 <[email protected]>,
CBFalconer wrote:
[...]

I believe we were talking in libraries written and maintained in
a language other than C, though, namely x86 assembly language.
Yup.

In that case, you can't rely on the C compiler to recompile it to
different
calling conventions even if you DO have the source.

Indeed...

I wrote nothing of what you quoted. Please take more care with
attributions.

 

[Chris Thomasson]

I wrote nothing of what you quoted. Please take more care with

attributions.

Sorry about that.

 

[Keith Thompson]

Sorry about that.

Taking more care with attributions doesn't mean dropping them altogether.

 

[Jordan Abel]

Taking more care with attributions doesn't mean dropping them altogether.

Though he wouldn't have been the first on this group to have reached
that conclusion.

 

[Keith Thompson]

Though he wouldn't have been the first on this group to have reached
that conclusion.

Unfortunately, that's true.

 

[av]

Oh, are they? That'll be news to the ISO C Standard, which allows
implementations to pull any trick they like to speed up function calls.

And that's important; if you want an assembly function to speed up the
program, you really don't want to use the slowest way available to call
that function.

in how i see it, it is wrong have not standard way to call a function
in assembly

 

[Guest]

in how i see it, it is wrong have not standard way to call a function
in assembly

Why? What drawbacks are there to using nonstandard ways to call
functions in assembly, when those functions themselves are already not
covered by the C standard?