Re: Stack calibration

[ludo@gnu.org (Ludovic Courtès)]

Hello,

"Neil Jerram" <neiljerram@googlemail.com> writes:

>>> +  SCM_VALIDATE_INT_COPY (1, d1, y1);
>>> +  SCM_VALIDATE_INT_COPY (2, d2, y2);
>>> +
>>> +  calibrated_m = ((double) (y2 - y1)) / (x2 - x1);
>>> +  calibrated_c = ((double) y2) - calibrated_m * x2;
>>
>> Shouldn't it be:
>>
>>  calibrated_c = y1 - x1;
>
> No, don't think so!  My model equation is y = mx + c, so c = y - mx.

Hmm, OK.

>> Could it be moved to a `%print-stack-calibration' function that we'd use
>> for troubleshooting?
>
> Yes.  In the attached patch, I've left this out completely, but I
> think we should add it back in as %get-stack-calibration.

Yes.

> I've done this part a bit differently - see the libguile/Makefile.am
> changes - because I couldn't see exactly how the recursive make
> approach would work.  If you think recursive make would be
> significantly better, can you describe or propose the detailed changes
> that would be needed?

Your proposition looks very good actually.  I suppose the generated
makefile doesn't require recompilation of all `.lo' files to go from
`libuguile' to `libguile', right?

I'm not sure about cross-compilation (Dale Smith had also raised this
issue on IRC some time ago).  IIUC, the user is expected to provide a
`UGUILE_FOR_BUILD' at configure-time, which is then used to run
`calibrate.scm'; however, `UGUILE_FOR_BUILD' runs on the host, not the
target system, so the generated file will be erroneous, right?

Thus, when cross-compiling, shouldn't we avoid stack calibration
altogether and simply emit a warning a configure-time, for instance?

At any rate, it's not a problem when cross-compiling with tools like
Scratchbox, which actually "hide" the fact that we're cross-compiling
and can run executables for the target system through an emulator.

Thanks for your work!

Ludo'.