On Apr 4, 3:53 am, "Ed" <nos...@[EMAIL PROTECTED]
> wrote:
> "Bruce McFarling" <agil...@[EMAIL PROTECTED]
> wrote in message
> > That was not from an implementers perspective, and not referring
> > to patching MAX-FLOAT-DIGITS. It was referring to source that
> > is written without the proposed system, and applying a patch with
> > a prelude file that is written using the information provided by
> > the proposal, including the information returned by
> > MAX-FLOAT-DIGITS.
> Ok. I take it such a prelude would redefine REPRESENT and
> include it's own local buffer etc? It sounds do-able.
Yes, it would redefine REPRESENT, inside the private 'tools' wordlist
for into which the original application is being defined.
> My own feeling is that such measures won't be needed. I
> surveyed as much code as I could find which used REPRESENT.
> What usage I saw (and there wasn't much) had REPRESENT
> work with buffers of at least 18 chars.
I wasn't worrying about it being a problem with a desktop application,
more for a microcontroller.
However, thinking it through, if it was a microcontroller that used a
32 bit IEEE SPI floating point coprocessor and has been moved to a
soft core of the controller and an IEEE floating point soft core, it
will not be using REPRESENT, it will have been using the higher level
formatted floating point functions in the, eg, uM-FPU, and so its the
replacement for that higher level formatted floating point function
that will be written using REPRESENT.
So, no, its unlikely to be an issue there either.
|
