Re: Innovative Systems FPE...

[DaveSchmenk <dschmenk@gmail.com>]

On Aug 17, 11:12 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> mdj wrote:

[snip]

> >>>>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 ;-)
>
> >>I guess I don't see any "backwardness".  Little-endian has always seemed
> >>"backward" to me, since in "real life" we always write numbers big-
> >>endian.  (And the 68881 supports packed BCD extended FP numbers!)
>
> > My mental model of (computer) memory runs either left-right or bottom-
> > up so it feels natural to me to place higher order bytes in higher
> > order addresses. So if you consider for example addition on an
> > arbitrary length number, the code looks more 'right' to me in little-
> > endian. It's also a much more 'natural' fit for evolved architectures
> > where the word size has been increased through several generations.
>
> Interesting.  I often envision it with increasing addresses going
> down, as in a code listing or a memory dump--and, of course, left-
> to-right within a line.
>
> About the only time I might consider addresses to increase going "up"
> would be a graphical memory map, but even then, I usually rotate it
> so that addresses increase from left-to-right.  ;-)
>

I once had to deal with big endian graphics hardware connected to a
little endian machine.  I swore I'd never deal with a big endian
machine again after that. Graphics hardware seems to be the worst when
it comes to mixing byte and bit ordering into the least convenient
format.

> Of course, ever since elementary school, numbers have been written
> left-to-right and arithmetic operations have proceeded from right-
> to-left and top-to-bottom.  ;-)
>
> As an aside, I once programmed extensively on a machine (B3500) that
> was a storage-to-storage BCD machine with variable field lengths.  It
> addressed all fields in memory by their lowest-addressed digit, which
> was the most significant digit, and even did all arithmetic from left-
> to-right.
>
> This sounds quite difficult until you realize that a carry out from a
> later (lower-significance) digit can only propagate through a contiguous
> string of 9s, so it is only necessary to keep a count of how many such
> 9s would have been produced until a digit less than 9 is produced, when
> all the delayed result digits can be written as either 9, if no carry,
> or 0 with the previous result incremented by one, if a carry occurred.
>
> > That said, I would happily agree that if one has the luxury of
> > designing a modern processor from scratch, I would favour big-endian
> > representation ;-)
>
> On the occasions when I've been able to do that, I did!
>

I'm curious as to why?  I always preferred least significant values in
lower addresses.  Whenever dealing with smaller or larger sizes than
the native register width, little endian seams more natural to me.


[snip]

>
> Compared to what it might have been, yes.  But no one seems too upset
> by the speed of recalculates in the Appleworks spreadsheet, so, as they
> say, "good enough is good enough".  ;-)
>
> It would be painful in an FP-intensive Pascal program, but I'm guessing
> that there weren't too many of those.  ;-)

Although I think Pascal uses something close to the IEEE format, not
the AppleSoft format.

>
> >>>>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...
>
> >>It's not too bad, since it's just replicating sign bits in front of
> >>the sign to get the correct exponent length.  Then there's a small
> >>"excess" adjustment.
>
> >>The biggest problem is that the IEEE sign of the mantissa is stored
> >>ahead of the exponent instead of in place of the implicit bit of the
> >>mantissa.  That requires a shift of the mantissa.  ;-(
>
> > I have never understood why that was the case - perhaps a result of
> > never having designed a hardware FP multiply circuit ...
>
> IEEE floating-point was definitely *not* designed with much hardware
> input!  Kahan was a mathematician, and, like many others, just assumed
> that Moore's "Law" would take care of all the heavy lifting.  In fact,
> it took a decade to learn tricks to permit *fast* IEEE FP, as opposed
> to the heavily microprogrammed "hardware" of FP coprocessors.

The only reason I could think of for putting the sign in the MSB was
to do "quick and dirty" tests using integer registers for greater-than-
zero, zero, and less-than-zero. As for hardware multipliers, they
could care less where the bits are - it's all just wires to them.

>
> >>As I'm considering how to exploit the FPE from Applesoft, however,
> >>I find myself leaning toward simply CALLing small chunks of slow FP
> >>computation (involving functions, etc.)--that would be both fast and
> >>easy, with a small number of conversions from/to Applesoft format only
> >>on entry and exit.
>
> >>This would be a natural for matrix operations.  ;-)
>
> > A comprehensive solution would begreat to have 'in theory' but since
> > any application that depended upon the additional speed is not
> > 'portable' in practice I think your solution is more than adequate.
>
> > Sounds like a lot of fun to play with!
>
> Just as I'd hoped.  ;-)
>
> -michael
>
> NadaNet and AppleCrate II: parallel computing for Apple II computers!
> Home page:http://home.comcast.net/~mjmahon
>
> "The wastebasket is our most important design
> tool--and it's seriously underused."

Do you have a purpose for your code?  Ray tracing in AppleSoft (oh,
the pain)?

Dave...