[fetter-devel] wrong code generated

[Rayiner Hashem]

> Sounds like CFFI needs an extension. What are other FFIs such as
> AllegroCL and CLisp doing?

AllegroCL appears to have a long-long type that does the right thing.

> Will such a creature actually only work on a 64-bit system?

On a 64-bit system, "long long" can usually be mapped to the system's
"long" type (which, in most OSs, is 64-bits). On Win64, the "long"
type is still 32-bits, but from C-FFI's point of view, its still
fairly simple to map it to an _int64 or whatever, since it'll still be
a single machine word.

> If not, what
> do they become on 32-bit systems?

They become a pair of words, stored in a pair of registers. For
example, it'll be stored in EAX:EDX, then when it needs to be written
to memory, two MOVDs will be issued, one for each register.

> Can they be treated benignly as 32-bit
> longs on 32-bit systems, failing only where runtime values actually
> exceed 32 bits?

It depends on the architecture, but at least on x86-32, the fact that
arguments are passed on the stack will cause the FFI to have the wrong
offsets for every parameter after the "long long".

> I am just hunting around for some imperfect solution
> that fails no more often than would using the library on a 32-but system
> even from a C client application.

The C client apps won't fail, simply because the compiler understands
that "long longs" have to be treated specially. There are some hacks
that could be done (transforming a single argument of type long long
to a pair of arguments of type long), but they still can't handle
return values properly (since there is no way to tell the FFI that a
value is returned in two registers, not one).

That said, I wonder if its worth more than just failing gracefully in
this case. "Long long" is new to C99. Does that much code use it?

>
>
> --
> Kenny
>
> Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
>
> "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it."
>     Elwood P. Dowd, "Harvey", 1950
>
>
>
>