[CCC DEV] convert.module and friends question

[Adam Sampson]

Matt Jadud <jadudm at gmail.com> writes:

> What is involved in updating libraries like "convert" to work on the
> AVR? Looking at "convert," it seems like 32-bit INTs are expected. Do
> I carefully go through and annotate things correctly (so that INTs are
> INT32s where they should be INT32s?). This seems like the wrong way to
> do it.

That's probably the right way to do it (you're definitely correct in
thinking that occam code should use INT32 when it wants a 32-bit
integer!), but it may require a heroic amount of effort, since
REAL32TOSTRING uses LONGDIV...

In terms of code for actually printing stuff, I'd recommend using the
fairly comphrensive facilities that useful.module provides rather than
inventing another API. You can say things like:

  trace.srn ("X is ", x)

(where the "srn" bit is very approximately a format string for "string,
REAL32, newline" -- more documentation can be found in the usual place
at http://occam-pi.org/occamdoc/useful.html). Note that the "r"
formatter is implemented using the course library's copy of
REAL32TOSTRING rather than convert's version, which is similarly stubbed
out to CAUSEERROR () on 16-bit platforms.

A quick fix for now would be to add an FFI call that wraps up
snprintf(buf, sizeof buf, "%f", value), and make REAL32TOSTRING call
that. The formatting won't be quite the same as REAL32TOSTRING, but
it'll be close enough.

A lower-tech approach, if you have a reasonable idea of how big the
numbers you're going to be dealing with are, is to write something that
(for example) multiplies by 1000, converts the result to a 32-bit
integer, then prints it putting a decimal point three digits from the
end...

-- 
Adam Sampson <ats at offog.org>                         <http://offog.org/>