Re: Innovative Systems FPE...

[mdj <mdj.mdj@gmail.com>]

On Aug 14, 4:36 am, "Michael J. Mahon" <mjma...@aol.com> wrote:

> >>All things considered, I think I can make this much simpler, faster,
> >>and smaller, all at once.
>
> > It sounds like it! Strange, with that much glue logic you'd think
> > you'd handle endianness translation in hardware ...
>
> Since the card cannot directly access memory, it depends on 6502
> instructions to move data, so endianness is intrinsically a decision
> of the 6502 load/unload code.

Right. I was considering that they may have mapped the register
directly to the IO space, which would then have endianness
implications....

> >>>>Upon reviewing the macros converted for Merlin, it's apparent
> >>>>that they were never used or tested, since they have numerous
> >>>>errors.  They also suffer from the delusion that floating-point
> >>>>numbers should be represented in little-endian form on the 6502,
> >>>>which Applesoft contradicts.
>
> >>>Curious, since the 68k is big-endian, but I suppose you can load the
> >>>registers more quickly on an 816 that way...
>
> >>Since the 65816 has no notion of the meaning of floating point data,
> >>that choice is arbitrary.  Did Apple choose little-endian representation
> >>for SANE FP numbers?
>
> > It's little, and the call interface is essentially push two addresses
> > onto the stack plus an operand code and call the entry point.
>
> > I suspect that this allows some slight optimisations since in little
> > endian the floating point mantissa has the same address as an integer
> > type does, though I admit this is 'gut feel'
>
> Actually, I doubt it.
>
> The only data endianness "enforced" by the 6502 is that involved in
> indirect addressing, which has nothing to do with FP.

True. Since access to FP data is likely to be indirect in code, I was
considering there may be differences in type conversion situations.
Consider for instance the conversion of an integer to a single
precision float can be a no-op if the high order byte is zero, which
can be done quickly in big endian if you can avoid initializing an
index register. Of course that applies only to the C02 and 816...

Of course, little endian in software is faster on an 816 due to being
able to exploit 16 bit addition/subtraction, although this is a very
small gain in practice I'd imagine.

> Many FP implementations choose big-endian just because it's a lot
> easier to visualize the shifts, etc., than in little-endian mode.  ;-)

;-) If one is prepared to visualise memory addresses bassackwards I
agree ;-)

> >>>>Does anyone know how many of these things were made, and if
> >>>>anyone ever used one successfully with a //e?  My serial number
> >>>>is 890005, so I'm guessing they weren't very popular.  ;-)
>
> >>>>I'm making progress, but feel like completely redesigning
> >>>>the macros to use a small runtime FPE package.  A further
> >>>>out possibility is making an interface to Applesoft, since
> >>>>the 12MHz 68881 clock compensates for the relatively weird
> >>>>dance one must do with the 6502 to load operands, perform
> >>>>instructions, and store results.
>
> >>>>This might be a more interesting thing to do if there were
> >>>>more of them in use...
>
> >>>Well, if you managed to make a patchset for Applesoft and somebody
> >>>wanted to produce some , it'd be a mighty fine accelerator
> >>>companion... How complex is the board ?
>
> >>Simply complex.  ;-)  It's basically a 68881 and a Xylinx XC2064
> >>glue chip (plus a TTL transceiver).
>
> >>Looking over the Applesoft listing, I see a lot of "fiddling" with
> >>the floating-point accumulator, so it would be difficult to simply
> >>map FAC and ARG to 68881 registers.
>
> >>The easy way (?) would be to convert Applesoft's FAC and ARG into
> >>and out of the 68881 on pretty much every operation worth speeding
> >>up (multiply, divide, math functions, BCD conversions), which would
> >>require a lot of annoying movement of data...
>
> > Right. A 'good' card would have a mode that presented Applesoft
> > compatible registers (didn't the older ones do that ?) but I suspect
> > optimising for SANE was the first order of business.
>
> Since the 68881 and all contemporary FP coprocessors directly
> implemented IEEE FP, which SANE is a software implementation of,
> it was natural to use IEEE formats.
>
> I don't know of any coprocessor that implemented Applesoft-format
> FP numbers, except possibly by a software patch.  Certainly no
> hardware ever did!
>
> It would be possible to load/unload memory values to/from a buffer
> register in the "glue" logic, which would then transform them on
> their way to the coprocessor, but that would be much more complex
> logic for the time, and would specialize the interface.
>
> Maybe FP coprocessor card makers figured that if you were using
> Applesoft, you weren't too interested in speed.  ;-)  But that could
> certainly be said for those using SANE--it's slow as molasses!

I guess on reflection it doesn't make much sense to optimise the
hardware for Applesoft ...

Considering SANE only implements 80bit precision as an arithmetic type
(all others are storage only) one wonders how they used 8k of memory
and still managed to be slow ...

> I'm going to be looking at conversion of IEEE to/from Applesoft format,
> and I expect it to involve a shift and a little bit fiddling, but not
> too much to do on-the-fly.

The main pain comes from dealing with sign extension of the exponent
when moving to/from the larger double (or extended) precision
representation...

Matt