[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Innovative Systems FPE...

DaveSchmenk wrote:

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.


A mixed-endian environment is always a problem...


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.


A study of comparative computer architectures reveals something about
endianness and why particular choices are made.

As was noted earlier, any architecture that starts with a small "word"
length, like 8 bits, finds a need to deal with larger numbers, and
does that by using multiple-precision representation for numbers.  It
is "natural" to do multiple-precision arithmetic from low- to high-
significance, so little-endianness at the level of multi-byte numbers
arises.  Interestingly, it is quite unusual to represent the bits
within a word as little-endian--they always have their most significant
bit at the left end, just as we always write numbers that way.

Architectures that start with large words, 32-bits and above, often
choose big-endian forms, since most data they process fits within a
single storage access.

It is certainly possible to twiddle the bytes on the way from memory
into the processor, and in fact, several modern architectures, facing
the inevitability of dealing with the predominant Intel architecture,
have arranged to handle both big-endian and little-endian data with
almost equal facility (at a small extra cost).

So the key is how much of a role multi-word arithmetic plays in a
system.  If it is frequent, the system tends toward little-endianness.
If the word is long enough that multi-word arithmetic is rare, then
big-endianness is often preferred.

Of course, we've been talking about addressing endianness.  There's
also "time-endianness" having to do with how data is transferred when
it is wider than the datapath over which it is being transferred.  But
that's a topic of more interest to hardware designers...

Danny Cohen wrote a great article on endianness in 1980: "On Holy Wars
and a Plea for Peace":

http://www.ietf.org/rfc/ien/ien137.txt


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.


Right.  We were talking about IEEE format here--like Appleworks, which
uses SANE (IEEE).


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.


There is a longstanding tradition in large-word machines, of putting
the mantissa sign first, then the excess-representation exponent, then
the mantissa.  This format allows a standard integer compare to compare
two floating-point numbers.  It also allows a comparison to finish early
as soon as a bit difference is detected.

My comment about IEEE FP speed and complexity is more general than sign
notation, having much to do with all intermediate computation being done
in extended format and a rich repertoire of difficult features, like
having to correctly deal with denormalized numbers.

From the point of view of the 6502, Applesoft's choice of putting the
mantissa sign in the place of the implicit 1 (the high bit of the
mantissa) makes handling very simple, since the sign can be separated
out and replaced with the implicit 1 and arithmetic can proceed without
any shifting or other preparation.  The exponent is complete in its
byte, so again, no other preparation.


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


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


Actually, my purpose is just to learn more about the 68881 and to
see how much practical speed a 12MHz 68881 can deliver to an Apple II.
Ease-of-use and space efficiency are also interesting to study.

-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."