[clean-list] htoclean sorrows

[John van Groningen]

Matthew Bromberg wrote:
>Does using MS link.exe as the linker affect the :V:  argument for passing around states?

No.

> I start getting #NAN#s out of my code when I attempt to
>add the extra state variable like this:
>
>..
>
>:: *State :== Int;
>
>cblas_daxpy :: !Int !Real !{#Real}  !Int !{#Real} !Int !State -> State cblas_daxpy a0 a1 a2 a3 a4 a5 a6 = code {
>   ccall cblas_daxpy "IRAIAI:V:I"
>}
>...

This happens because of bug in the ccall. This occurs if a real is passed
as a normal argument (an R before the first : ) and an integer as a state
argument (an I after the second : ). You can work around this bug by using
a Real as state, so:

:: *State :== Real;

cblas_daxpy :: !Int !Real !{#Real}  !Int !{#Real} !Int !State -> State
cblas_daxpy a0 a1 a2 a3 a4 a5 a6 = code {
   ccall cblas_daxpy "IRAIAI:V:R"
}

I will try to put a new codegenerator without this bug on our web site tomorrow.

>Perhaps I'll just go back to treating void returns as an Int.  For most implementations an Int return should be a value in a register and should not
>affect the stack.

That's right.

>The convention changes dramatically however if you try to return a large structure.  Also I find FFI a lot easier when I simply include the abc code specification rather than go through htoclean.  Should I expect this specification to change as far as the ccall instruction is concerned?

No.

Kind regards,

John van Groningen