🚀 go-pugleaf

In article <832@dms.UUCP> albaugh@dms.UUCP (Mike Albaugh) writes:
> ,,,
>	So, where did I go wrong, or should I say, where do I find
>that blazing Binary->BCD routine? :-)
>

I'm afraid I can't state specifics, but the large A Series stuff (A12/15/17)
does it with a fair amount of silicon and not very much microcode.  There
is a raging and recurring debate between the A Series types (including
myself) and the V Series types (V Series stuff is DECIMAL, including
addressing and peripherals, at least historically) about decimal arithmetic
vs convert in / binary ops / convert out.  All I can say is that with the
proper amount of silicon, OUR method beats THEIR method.  

Also keep in mind that with decimal/binary convert ops, all of the binary 
arithmetic ops, library routines, etc, etc, can be brought to bear.  The 
real trick, as has already been mentioned, is to make the convert ops as 
fast as possible.  Unfortunately this is not something I can discuss in 
such a forum.  We have to keep our engineering advantages, where they exist.

....

Adding fuel to a different fire, while our instruction set includes a lot
of ops, many are special ops for the operating system and many more are
string manipulation ops.  None the less, we have 1 unprotected (vanilla)
load op, two unprotected (vanilla) store ops, 3 array reference generations
ops, 1 each of add, subtract, mulitply, divide, remainder divide, integer
divide, integerize (rounded), integerize (truncated), 1 BCD convert in and
2 (I think) BCD convert out ops.  Pretty reduced, I'd say.  And this is an
instruction set that has been around in pretty much the same form for 20
years.

One other nice thing:  our integers data type is actually a subset of our
floating data type.  All of the arithmetic ops work against either floating
or integer, single or double precision data.

Barry Traylor
Unisys A Series Engineering
Paoli, Pa
barry@prc.unisys.com